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 testingAgile testing is all quality-related activities that accompany an Agile development process and has the following characteristics:
- 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.
So how do you get high-quality software? Famous quality management experts point out: that quality is not detected; the product-produced quality has been warranted. Therefore, software quality cannot be improved through post-test assurance, and quality needs to be built into the software product.
Ⅲ. Built-in qualityThe later a bug is exposed, the more expensive it is to fix; If the defects are prevented less early, the defects will be found more later. Prevention of defects in the early stage will reduce defects exposed later. Therefore, we need to prevent defects in advance rather than find many problems after development is completed, which is built-in quality.
1. Test shift to the leftTest shift to the left requires testing to intervene early on the left side of the software development life cycle, either in the requirements analysis phase or earlier in the Inception phase. Shift to the left of the tester can do together can have mining demand requirements, analysis, clarify requirements, and discussing review requirements, participate in the technical solution, the primary purpose is to use the tester's unique perspective and understanding of the system, each link to make the necessary input, to ensure the consistency between team understanding requirements, to ensure that the team was able to do the right thing.
The value of testers' participation in requirements analysis is mainly reflected in the following two aspects:
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 storiesUser stories are important for delivering business requirements during agile development. There are high requirements for breaking down user stories and describing the acceptance criteria for user stories. Tester participation can help review user stories, improve the quality of the stories, and communicate requirements to the team more precisely. Testers are required to have a thorough understanding of the "INVEST" principles of user story splitting and use them to review 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:
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 developmentTest-driven development is known as TDD. There are two common types of test-driven development, which are:
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."
- 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.