While transiting from waterfall to Agile, testers are often not considered in the plan. They are expected to perform similar testing-related activities, with the only difference being that of of timeboxed sprints. Yet simultaneous testing activities are crucial for successful execution of sprints, and they also help identify the development pace of the team.
The initiation of any development project is incomplete without “RTM,” or a Requirement Traceability Matrix, be it in Waterfall or an Agile implementation.
RTM has the intended purpose of mapping all the fixed requirements to identified test scenarios and/or test cases. However, we have ever-changing user stories in Agile projects. How do we ensure that changes are always implemented, mapped, and tracked?
Test backlog creation is an option for identifying and compiling all the testing-related activities. It can extend from the epic to the task levels.
Making the transition
Here are few ways to support a transition from Waterfall RTM to an Agile test backlog:
Create a “test backlog”
A test backlog is a set of test stories written by testers and containing their assumptions, test data requirements, environment specifications, risks, and dependencies. This backlog should be created in collaboration with the product owner. The product owner would in fact create few user stories in advance for the tester to start with, then they can work together in similar, dependent cycles.
Test stories are written for testing the system at various levels and for various types of compliance. These stories should be related to corresponding epics or user stories to ensure mapping. The entry and exit agreements should have references to these test stories to ensure complete coverage. These stories should also identify high-level NFRs (non-functional requirements), testing environment(s), and test data. Also, third-party dependencies identified at this level would help the teams plan their stories in collaboration with external dependencies. These stories would also highlight personas that impact the corresponding epic or user story.
Acceptance criteria makes a base for UAT test cases, but sometimes we overlook other important aspects required to achieve acceptance. These include comments from the product owner during the demo, and nonfunctional requirements around that story. Testers should be sure to include those in their test cases and in acceptance criteria of their test stories, as applicable.
These are the most crucial and sometimes overlooked requirements. Tester should identify each type of NFR associated with each epic, story, and task. The prerequisites for each NFR should be addressed in n-1th sprint for complete testing. Based on the type of application, e.g., financial, e-commerce, or enterprise level, the Definition of Done should be updated with compliance checks, and NFRs should be planned to confirm against those DoD checks.
Test-driven approach (TDD)
Unit and integration testing can be very well tracked and mapped to test stories with the help of a test-driven approach, where each implementation scenario and condition is validated using tests. Test stories would provide conditions and validations to be considered for unit testing and integration testing.
Buddy testing is a form of exploratory testing done on a developer’s machine to confirm unit testing and identify gaps. This helps the tester get a view of what has been developed and enables him to give feedback that might come up as a review comment later. Buddy testing ensures that developer and tester are in sync in terms of understanding, and it helps minimize conflicts (if there are any). Test stories can be updated based on the feedback of real testing done before the code is moved to the testing environment.
Benefits of an Agile test backlog
There are several benefits to this approach:
- In terms of a sprint, stories can be covered in functional as well as non-functional testing.
- Sprints can be planned with more complete considerations about testing requirements.
- Testers know better how much planning they need to do, well ahead of time.
- Developers can go through test stories and pre-verify their stories to prevent defects.
- A backlog of test stories supports a “shift left” approach to testing.