QA in agility
QA usually refers to quality assurance engineers, but I prefer to define QA in agile as quality analyst for the following reasons:
- Quality assurance is more biased towards industry, saying that the people involved in software testing feel more appropriate for quality analysts;
- Quality Assurance engineers still regard testing as the final gatekeeper of software quality, while QA in agile is more of a Recommendation provider than a gatekeeper, calling QA as a quality analyst can better reflect the quality responsibility principles of agile teams;
- Quality analysts pay more attention to business value and business value analysis.
QA and quality analyst are clearly related to testing. QA in agility is related to agile testing. Agile testing is the testing of software in Agile development mode. It requires early testing, frequent testing, and feedback. Agile testing requires the team to be responsible for the quality of software products, rather than a special person with a QA title. In agile, QA can be all teams involved in Agile testing, not necessarily specific full-time testers.
Does that sound special? Is it different from testing personnel in traditional development mode? Don't worry. Let's take a look at how agile QA performs daily work.
Routine Activities of agile QA
From iteration to release, QA activities at various stages of the agile Test life cycle mainly include: test analysis, test automation policy analysis, framework construction, and so on, story test, iterative plan meeting, and customer demonstration, automated maintenance and execution of tests. As shown in:
QA usually does not work in a specific iteration, but works in multiple iterations in parallel at the same time: acceptance testing and exploratory testing should be performed on the story of the current iteration, and testing automation should be achieved through pairing with developers; we also need to pair with the business staff to analyze the story of the next iteration and compile the acceptance criteria and test cases.
In a single iteration, with the story lifecycle, what QA activities are there? The user story lifecycle includes the following stages: story analysis, story plan, story development, story acceptance, story testing/exploratory testing, system testing, and customer demonstration. Throughout the lifecycle of a story, QA plays a role in each stage.
- Story analysis stage: requirement clarification, business scenario and acceptance test confirmation
- Plan the phase: Split the test task and consider the test time and estimation based on each story development estimation.
- Story development stage: Automated Testing with developers and communication with teams to discover problems and defects
- Story acceptance stage: After a developer develops a story, the QA and business analysis personnel must accept the story on the development machine to provide quick feedback; at the same time, the test coverage rate (unit test, component integration test, and function test) should be confirmed and provided for feedback.
- Story test/exploratory test stage: perform automated acceptance test, execute Exploratory Test, emphasize factors that will impede story release, communicate with the team on test coverage rate, and add automated tests for Detected Defects
- System testing and customer demonstration phase: perform end-to-end system testing, perform business or integrated user testing scenarios, and communicate with teams and customers on the quality and stability of features, participate in demonstration of features and features for customers
As mentioned above, in each stage, QA should not only perform independent tests, but also usually have to be paired with different roles, including business analysts, developers, and customers.
- Matching of QA and business analysts: When business analysts analyze user stories, QA should pair with business analysts to compile acceptance criteria. By pairing with business analysts, QA can better understand the domain knowledge and help define suitable test cases; the acceptance test cases added by QA from the test perspective can help the entire team better understand the product functionality.
- Pairing QA with developers: QA and developers can bring different skill sets to the team, recognizing this is very important. As a team, it is best to achieve a common goal by balancing different skill sets. This is an important change in mindset for traditional waterfall teams. Generally, when testing is automated, It is ideal for developers to pair QA with developers. In this way, the quality of automated testing is relatively high, and QA participation with high testing awareness can ensure that automated testing and measurement are part of the real need for testing, the coding capability of developers helps to write simple and maintainable automated test code. On the other hand, QA is paired with developers, and the coding capability will also be improved accordingly. By pairing with QA, the testing awareness will also be enhanced, which is more conducive to the compilation of high-quality product code, it is more conducive to the formation of a full-featured team.
- QA pairing with the customer: the customer is an expert in the business field. Through pairing with the customer, QA can better understand the system from the end user's perspective, so as to define or add more end-to-end test cases; once QA understands the domain knowledge and end user opinions, its business value analysis capability will be improved, and the team can assume the business analysis role as needed; in the User Acceptance Test (UAT) by pairing with the customer, QA helps the customer get familiar with the system and help the customer solve some system problems when necessary.
These daily activities of agile QA do reflect that the daily work content and methods of agile QA are different from those of testers in traditional development modes. The following describes the differences between the two and the QA requirements of agile testing.
What is the difference between agile QA and traditional testers?
Let's look at the differences between agile QA and traditional Testers in terms of team composition, test phase, work style, focus, business knowledge sources, and release plan formulation:
| Traditional testers |
Agile QA |
| Independent Test team |
One member of the Multi-Role Development Team |
| Test started later in the development process |
Testing runs throughout the development flow |
| Usually independent work |
Associate QA with different roles |
| Being treated as the final and only quality assurance |
Focus on and emphasize risks |
| Lack of direct communication with business personnel |
Communicate directly with business personnel |
| No chance to participate in release plan preparation |
Participate in the formulation of release plans |
From the comparison above, we can see that agile QA is special, mainly reflected in:
- Agile QA is a leader rather than a gatekeeper. You need to make your own suggestions at every stage of participation, rather than wait until the development process ends to verify the system. Besides, you need to verify whether the development design meets the requirements, we also need to find out whether the demand can truly reflect the business value and whether there are inappropriate or missing demands. For example, agile QA finds the missing requirements in the story analysis process when working with the business personnel to compile the acceptance criteria, in the process of pairing with the developer, discuss with the developer about the layer at which a test is implemented reasonably.
- Discover risks and communicate with teams and customers. QA participates in the entire development process, and its overall understanding and grasp of the system can be said to be the most comprehensive within the team, so it is easier to see the risks of the system.
- Provide feedback on product quality to the team in a timely manner to facilitate adjustment. At the end of each iteration, QA needs to analyze and calculate the defects of the iteration, and give feedback to the team in a timely manner based on its own understanding of the system quality through testing, discuss and analyze the causes of quality decline to make improvements as soon as possible, or summarize the experience of quality improvement, and encourage the team to make persistent efforts.
- When developing product and version release plans, QA can give some key suggestions from the unique perspective of testers based on their understanding of product quality.
- By participating in each stage of the development process, QA can help the team improve quality internally and integrate quality into product development. For example, the test coverage rate is confirmed in the story acceptance stage.
These particularity also puts forward higher requirements for agile QA, and needs:
- Rich product knowledge and accurate understanding of users' business objectives
- Understanding of the technical knowledge used by different systems and databases
- Communicate effectively with different roles and customers
- Proactively verify the quality objectives and express your thoughts in a timely manner
- Compile a test plan, list the activities to be executed and make estimates
- Ability of automated testing and basic understanding of testing tools
- Share knowledge within the team to help the entire team participate in the test activities.
- Continuous provision and feedback
