In my previous post on Business Analysts as Specilaist Team members within a Scrum team noted, individual team members may have specialised skills and areas of focus, however accountability to deliver the Sprint work belongs to the Scrum development team as a whole.
The whole team is responsible – whether its support for testing built into the features or more people testing, it is not done until it is done. Testers within a Scrum development team help ensure that the right product is getting created and that the product is being made right.
The tester would support the Product Owner by:
- Writing/reviewing acceptance criteria for each product backlog item (user story)
- Write/review testing scenarios for the user stories
- Meeting with clients and business to establish what is needed, what they are wanting to achieve and how that may impact current systems, processes and users
- Creating test cases
- Automating test cases
- Executing acceptance criteria
- Smoke test UI/regressions (previous sprint).
- Exploratory testing to find bugs that no automated test will ever find
- Pairing on development to improve understanding of the code
Scrum teams are intentionally small. Most have a high ratio of developers to testers. Even though that can account for most of your testing time, successful teams have flexible members and testers should have a willingness to step outside their circle of comfort.
Before the Sprint begins, testers can help the team by validating the product (looking at the design and talking through the feature to make sure it makes sense), identifying product risks and system risks before they become issues and making sure that the feature will support test automation.
During implementation, testers make sure the tests are getting written from the start. The best way to do that is to meet with the developer and product owner before any work is done so that the tester can provide their input for what will be tested and also start working on BDD/TDD scenarios for testing to make sure all acceptance criteria are verified and reflect end user’s behaviour and interaction with the system.
Testers help the team to understand what the system state is at the beginning, the trigger for the test, and the criteria for the test with enough detail to know which business rules are being tested. Writing the code behind the tests, such as step definitions for “Given, When, Then” cucumber scenarios, will help the team get to ‘done’ but also help them understand what is happening when the step runs.
Pairing on development and testing strengthens both team members. With people crossing disciplines, they improve understanding of the product, the code, and what other stakeholders find important.