The Core of Agile Testing

Q： What is the relationship between quality built-in and Agile testing? Can it be separated?

A： I think the built-in quality is at the core of Agile testing.

Ⅰ. Traditional test

Agile testing is relative to traditional testing. Before we talk about agile testing, let's look at traditional testing. Traditional tests typically have the following characteristics:

• Independent testing department: testers and developers are independent and not in the same department
• Testers mainly undertake testing work: functional and non-functional testing, manual and automated testing, smoke testing, regression testing, release testing, etc., which are the tasks of testers.
• Detailed test case documentation: Test case documentation generally requires detailed execution steps.
• Centralized egression testing: there are independent centralized regression testing phases with comprehensive test coverage for all functions.
• Find more Bugs: Testers aim to find more bugs, and some departments even use the number of bugs as a target for performance reviews.

Ⅱ. Agile testing

• Does not stand alone and is not a test type or method.
• Agile testing is not just a tester's job; agile testing is a team activity.
• There is no point in talking about Agile testing without talking about agile development.

Ⅲ. Built-in quality 

Source: www.sohu.com

1. Test shift to the left

Source: http://www.sina.com.cn

1.1 The business value

• Early exposure to requirements allows testers to better understand the business value, which helps with the subsequent series of tests.
• At the same time, testers should consider business value more and provide input from the perspective of business value in each demand link, including assessing end-user behavior, business process, business risk, and other dimensions. Check out my article "How Agile Testing optimizes Business Value."

1.2 User stories

• Independent: Try to avoid dependencies between stories and make them independent of each other. If you encounter two highly dependent user stories, you may need to merge or split them in another way to eliminate dependencies.
• Story is Negotiable, not a signed contract or a requirement the software must fulfill. The story card is a short description of the feature, and the details will be generated during discussions between the customers and the development teams.
• Valuable: Stories should be Valuable to users or customers. Note that some user stories may not bring value to the end-user, such as information configuration stories, which the user does not care about but are valuable to the customer.
• Estimable: The developer may not be able to estimate a story because of a lack of domain or technical knowledge or because the user story is too large. For the former, the business context and corresponding domain knowledge need to be clearly explained to the developers, and developers with relevant skills need to participate in the estimation; If the story is too big, it needs to be further broken down into more minor, measurable levels.
• Small: The story is too big to estimate and may need to be disassembled. Stories are too small to plan and may need to be merged. The size of the story depends on the team, but keep it small.
• Testable: user stories must be Testable, or the developers can't verify their implementation.

2. Continuous testing

The tests move to the left so that the team has a clear and consistent understanding of the requirements to do the right thing; Continuous testing is testing activities throughout the development life-cycle (starting at the far left of the life cycle and continuing into the production environment at the far right) to help quickly gather feedback to get things done right.

Continuous testing includes functional testing, built-in and continuous testing of performance, safety, etc. It can take the form of static analysis, review, or dynamic testing, including various tests executed manually and automated tests executed on the continuous integration pipeline. Let's take a look at the user story life cycle as an example of what continuous testing activities can take place:

Source: http://www.sina.com.cn

2.1 Story analysis

In this stage, we mainly evaluate the separation of the story and the AC (Acceptance Criteria) in the story, including the confirmation of functional and cross-functional requirements, to see if any requirements are missing or inappropriate, and at the same time, we can highlight some points that need special attention in development or later verification.

2.2 Story initiation

Story initiation is the clarification of requirements before developers begin to implement user stories, ensuring that business, development, and testing agree on the requirements to be implemented by the user story, both functional and cross-functional (security, performance, and so on).

2.3 Story development

Developers start developing user stories and perform low-level automated tests (unit tests, interface layer tests, etc.); Testers can start designing test cases and UI layer functionality automation tests and can feed back to the team any user story-related questions they find/think of during test design.

2.4 Story acceptance

Acceptance of story is the part of the acceptance of system implementation after developers develop a user story. This part corresponds to the "story start" and includes verification of functional and cross-functional requirements.

2.5 Story testing

Automate functional tests and run them as needed on the continuous integration pipeline; At the same time, exploratory testing needs to be performed based on the user story.

2.6 Story demonstration

Demonstrate the developed function to the customer, generally in the unit of features, requirements, development or testing personnel can be responsible for the demonstration, to collect customer feedback as soon as possible, is the link of customer acceptance.

3. Test-driven development

3.1 Unit test-driven development (UTDD)

Before writing the product code, write the unit test first, and then drive the product function code by the unit test, mainly to ensure the completeness of the design and better realize the built-in quality. Developers generally implement unit tests. Testers do not participate in the implementation, but they can be reviewed during the story acceptance phase to ensure the effectiveness of unit test coverage.

3.2 Acceptance test-driven development (ATDD)

In addition to unit tests, automated functional acceptance tests can be implemented first. After functional development is complete, all acceptance tests are required to pass. By doing this, you can collect feedback early on using functional automation testing to ensure better that functional requirements are implemented correctly. Acceptance testing can be done in pairs by developers and testers or alone.

When it comes to ATDD, it's easy to think of Behavior Driven Development (BDD), which is often lumped together but worth mentioning again. BDD emphasizes collaboration between different roles, better understanding, and clarification of requirements, and ensuring consistent understanding of requirements. BDD is not about testing; you can do without testing, but you can guide testing, and we can often automate testing in a BDD way. And ATDD is about testing, and there have to be tested. For more on BDD, see my article "What Comes to Mind when You Think of BDD."

Ⅳ Conclusion

Source: www.sohu.com

• The core of Agile testing is quality built-in, and quality built-in is defect prevention.
• Left-shift testing, continuous testing throughout the phases, and test-driven development are vital to the success of build-in quality.

--

Read more：

1. Why Zombie Scrum Teams Don’t Self-Organize Around Challenges
2. 5 Reasons to Move from Jira to ZenTao