Test Strategy in an Agile Scrum project
In a traditional waterfall project, it is a common practice to create test strategy and test plan documents before commencing the test design and execution activities. In Agile, development teams focus on building working software over comprehensive documentation, which reduces the overall need for documenting in testing.
However, it does not mean that Agile projects do not require test strategy and test planning activities. By general definition…
A test strategy defines the project’s testing guidelines and approach on what and how to test the target application(s), and the objectives of software testing and test coverage are well-defined.
Test planning is more specific to a particular release (or sprint) with specific details on the test schedule and activities.
During the sprint planning meeting, details on feature scope, schedule and priorities are often discussed in detail, and therefore, creating a test plan is mostly up to the respective project’s expectations and the management model. However, there is a general need to align the development team on the testing approach, test processes, and test roles in the project which can be outlined in the Test Strategy document.
Sprint Zero
In Sprint Zero (aka the pre-planning phase in a scrum project), most activities in the development team focus on finalising and implementing the development workflow, continuous integration process, communication, testing and delivery.
For QEs, Sprint Zero also serves as an ideal playground for finalising the test strategy in a new project. With clarity on the project goals and development plans, QEs can call for a “huddle” or “congress” session with fellow developers to ideate on the below item(s):
Importance of Test Automation
Test Automation is a crucial component in agile scrum projects. Functional testing in a project can be broadly split into three categories:
- New feature testing
- Regression testing (re-testing of existing features)
- Confirmation testing (testing of defect fixes)
Ensuring that we develop test automation for all three categories on any test level (unit, integration or UI) would ensure feedback on feature quality over multiple sprints. In agile scrum, regression testing is primarily covered by automation tests as it is inefficient to depend on manual testing to cover existing features and perform impact analysis whenever code changes are made.
Factoring other areas in testing
On top of functional testing, there are other areas of testing (e.g performance testing, security testing, accessibility testing, etc) that Quality engineers (QEs) should factor into the test strategy. In addition to planning, QEs also set the tone for the types of testing required for the project and help align the development team to deliver projects with the required testing factored on a sprint basis.
Team Culture
Testing in agile is always a team effort. Creating a safe space for collaboration (no-blame culture) allows the team to be more open to learning new skills and inquisitive towards other practices in software development.
Through pair-programming and knowledge-sharing, cross-functional teammates learn from each other and have each other’s back leading to a high-performing team who can deliver in any demanding project.
Agile work arrangement
While the test strategy defines the testing approach for the project, we should also clarify the work arrangement for the entire team. QEs need to work with everyone in the team, including the Product Owners (POs). Testing starts early from static testing (of requirements/user stories) until the release of the application. For the majority of the sprint, QEs work with developers in building the product right, and establishing a healthy working relationship with developers would set up the project for success.
Developer buy-in
Crafting the test strategy along with developers helps to get their buy-in to the testing process, and they can also clarify any questions/doubts on the testing approach. Getting everyone on the same page is crucial to make sure that we deliver as a team. Over a period of time, developers’ feedback is also necessary to tweak/update the overall test strategy as the nature of the project changes.
Baking test process in the project workflow
The test strategy document has a direct impact on how development is carried out as Agile methodology is to have the whole development team to work as one. Test-Driven Development (TDD) is a popular example in shifting left of test processes to introduce testing in early phases of development.
In TDD, the tests are written first followed by the coding of modular functions and the feature itself. It is generally understood that developers write the tests in TDD. QEs can also contribute to writing tests, just like how developers can also contribute in writing integration and UI tests with the QEs.
Writing user stories in Behaviour-driven development (BDD) format with Gherkin syntax, allows the team to focus on the expected behaviour of the application, and minimise documentation. As Gherkin syntax is simple and readable in English, it helps the entire project team to collaborate with other stakeholders to define accurate tests focussed on business needs.
When it comes to manual testing in Agile, most QEs employ the use of experience-based testing. When the user story tickets are finalised during sprint planning, QEs can start to plan their testing activities for the sprint. The team can use the sprint board as the source-of-truth for understanding the status of all tickets and ongoing activities in the sprint.
We hope this article has helped you understand how test strategy can play a role in Agile Scrum projects. We would like to emphasise that test strategy is an ongoing activity that needs to be revisited from time-to-time. Agile projects depend on feedback from internal and external sources, and our test strategies should adapt to changes in development strategy and the overall product.
- Merlin 💛
