I came to the Agile development world with a background in testing in big Waterfall projects. The transition was an interesting process.
I was used to being the Test Manager, the testing expert, the person responsible for making sure we shipped a quality product. Customers and Project Managers insisted on documentation and we delivered it. I was in charge of making sure every test was planned, documented and reviewed. My team would wait for the developers to deliver something to test. We would run our tests and then report back.
Then I joined an Agile team where delivering a high quality product is the responsibility of the whole team and no longer a task left to a separate test team to enforce. No one wanted documentation. I found myself working with developers who took responsibility for proving that the code was high quality. They wrote comprehensive unit tests and automated the acceptance tests. They cared about quality software and would challenge me when I spoke about testing. This left me questioning my role on the team.
So, what can a tester do to help a team build high-quality software if developers are capable of testing, the regression tests are automated and no one is asking for documentation?
Fundamentally, testing must be seen as an integral part of any Agile team’s activities. The testers should never be separated from the Agile team and testing regarded as an isolated activity.
Any of the following approaches can be successful:
- Testers as part of an Agile team
- A test team acts as an advisor to Agile teams, leaving the Agile team to do their own testing, possibly assisting with testing as required.
- Teams with no specialised test resources who handle testing themselves
An Agile team can work without a specialised tester, but I believe a team member who has a focus and interest in testing has a lot to offer the team. A team member with a knowledge and commitment to implementing good test practices will be an asset. Skilled testers will be able to stress the application and raise questions about how it will be used when released.
Most importantly, the tester should be an advocate for good testing practices in the team and the organisation. The tester is no longer the sole owner of any testing process and has to work with the team to find the best way to deliver quality software. Testers need a broad skill base and be willing to do whatever activities are required by the team. They need to be delivering added value when there are no stories ready for testing.
Here’s how an experienced tester can add value to an Agile team:
- Provide assistance in writing test cases and developing team testing skills. Other team members will have varied levels of testing skills and knowledge. Pairing to write acceptance tests can be a valuable exercise for everyone.
- Approach stories differently to a developer. Developers have an understandable focus on how a story is to be implemented. The tester should be thinking about the business context and be willing to provide feedback to the Product Owner/ Business Analyst. Testing gives opportunities to work across the whole of a product and move the focus away from single stories.
- Add value by doing some lightweight test planning. This doesn’t mean the traditional formal test plan. However it is a valuable exercise to take time to consider all testing activities that might be required to deliver the product. The project backlog is typically focused on basic functionality. As a tester you need to look outside the current sprint and consider the bigger picture. Performance, accessibility, compatibility, security requirements are all areas that should be considered early in development and informed decisions made about prioritising work in these areas.
- Provide guidance on how much testing is required. Emphasising the importance of testing can be interpreted to mean that more testing is always better. Experienced testers know that you can never test everything and that cost vs benefit of any testing activity needs to be considered.
- Provide a focus on testing during planning. Any estimate of effort must include testing and small code changes can have serious consequences. A tester will bring a focus on whether the acceptance criteria are testable and if testable, how difficult will they be to test.
It’s been an interesting journey so far, and I actually think this is a much better way to work. I’m looking forward to how the role of testers continues to evolve.