Agile software development follows an iterative method with the goal of providing working software to stakeholders at the end of each iteration. By providing a view of the software at the end of each iteration, each team member gets to see what the others have done and if the team has moved forward towards its final goal of delivering the software. I think that this process helps to build what I call Agile trust – the confidence throughout the process, not only for the stakeholders that the product is moving in the right direction, but also for the development team that they have understood the requirements well.
As a QA on an Agile team, providing confidence to stakeholders on a product in development requires consistent performance throughout these five phases of the lifecycle.
- Requirement analysis phase: During requirement analysis, the QA needs to join or review the breakdown of requirements to thoroughly understand the existing functionalities or features.
- Test case creation phase: It’s becoming more and more popular that development is driven by testing, i.e. Test Driven Development. So to do this, we provide a detailed list of checkpoints based on the business logic combined with test case analysis from a QA point of view. Then, not only the PO, but also developers, can refer to this during implementation.
- Test case execution phase: After interaction between QA and developers in the previous period, as QA, we get a working product for testing. At this time, based on our list of business logic checkpoints from the earlier stage (above), we can identify any inconsistencies between requirements and implementation. If we find many defects during this phase, it’s considered a good thing because it is early in the cycle, thus providing the confidence that development is moving in the right direction and developing the features correctly.
- System testing phase: QA should not just test the new functionality in this period. Rather, we must test old and new. After new feature testing is completed, we may get a new software build with fixed defects. So, after we retest the product and verify that the defects no longer exist, confidence is generated in the ongoing product development.
- Test case and defect review phase: Test cases/code review is usually considered a boring period for QA. However, in my opinion, this provides a time for real learning – we are able to review what we learned and document it for future improvements. This includes items such as test cases that need to be changed, defects that should be used to generate test cases, and features that end up working differently than we originally thought from earlier in the second phase. As part of our QA retrospective, we discuss these things amongst our team, and it proves very useful in training new team members as well. This makes us all more efficient and much faster for the next round.
When the software test team is able to carry out these tasks not only with expertise, but also with passion, we go far in developing trust within our small QA team and within the entire development team. Stakeholders and our team mates have the confidence in us that we can do the job and that we are improving ourselves, as well as the overall quality of the product. There is trust in the Agile process and in the Agile principles, and more importantly, trust exists between stakeholders and the development team. That’s true Agile trust.