I recently presented on Enterprise Level Integration and System Testing in an Agile Environment at few locations. Whenever I discuss agile testing, I am asked several questions that expose various misunderstandings about agile testing.
Myth–Testers may not get detailed requirement documentation to pursue their testing efforts.
Truth–Agile calls for just enough documentation for the teams to pursue their work. It encourages team members to collaborate and communicate more often, rather than documenting every tiny detail. That being said, it’s the responsibility of all agile team members to make sure they have complete details about the Product Backlog Item aka User Story aka requirements that they are currently working on.
From an Agile testers’ standpoint, they need to make sure they understand the acceptance criteria well enough to proceed with planning and execution of their testing. They should work with their Product Owner to further refine the requirements and add appropriate acceptance criteria ensure completeness of the requirements.
Myth–There is no dedicated testing time compared to traditional projects, and Agile testers will not have enough time to complete testing within the sprint.
Truth–Agile teams should embrace testing early, often, and in parallel with development. Test engineers should collaborate with programmers and test the work as its developed. Collaboration may include swarming with programmers to identify unit testing scenarios, integration, and functional scenarios. Test engineers should start writing tests as soon as the Sprint planning is over and be careful not to wait for the entire product backlog item to be developed and then tested. You will fall into doing a mini-waterfall inside a Sprint cycle.
Myth–Quality of the product is the responsibility of the test engineer in Agile teams.
Truth–The test engineer is not a quality gatekeeper in agile teams. Quality is the responsibility of the whole team, and should be embraced as a team. All the agile team members including the programming and testing team members should work and test together to make sure every completed work is of great quality and is potentially shippable.
Myth–Automation is the only way to incorporate effective testing in agile teams to aid faster feedback.
Truth–Automation takes time and it costs more compared to manual testing. Automation should definitely be a major part of the testing efforts but should NOT be the sole way of testing the product in agile teams. Test specialists should also consider performing manual tests especially if it is a newly developing application. Exploratory testing (manual testing technique) is also one of the best ways to learn and test the application to give feedback, find and react to issues early. One off scenarios and edge case scenarios are suitable for manual testing. You also need to evaluate the cost benefit analysis on automating all the possible tests. Typically regression tests and the existing functionality that have very minimum susceptibility to change are best suited for automation.
Myth–Testing in parallel with development is not possible.
Truth–Many times in agile, due to traditional software development and testing habits, teams end up doing a mini-waterfall cycle inside a sprint. This is will limit the teams ability to complete testing. Testing early, as the product is getting developed, will solve this issue. Test cases can be written day one and discussed with programming resources, and test scenarios can be identified and discussed with the coding specialists. Test specialists can swarm with code specialists on unit test scenarios, integration test scenarios, functional test scenarios, etc., and then they can pair up, which will aid in discussing tests and testing the code developed along the way.
To Conclude–Testing in an agile environment needs a different mindset compared to traditional methods. To be successful, agile test specialists need to have an open mind while working with the rest of their team (and vice versa) in parallel, and strive for quality as a whole team.