Agile Testing Myths - Q & A

"Agile is an excellent opportunity for QA to take leadership of the processes. Rather than take a back seat while developers drive the ship, testers can now take the lead".

"Who else is better placed to bridge the gap to understand … what is required, how it can be achieved and how it can be assured prior to deployment? This requires tester to be fluent in agile themselves".

With bold statements like these, I receive quite a few emails from testers with concerns about switching to agile. Continue to see TesterTroubles Q & A.

Do Agile teams need a dedicated tester?
Most definitely - Experienced testers bring something unique to the table. At the very least they: a) are familiar with methods and tools for testing that aren't strictly related to TDD. b) have spent a lot of time thinking about how to break things and where things might be likely to break. c) understand how to think about and communicate about quality.

How do I plan testing with no documentation?
In agile we do have less documentation, but to say NO documentation, is simply not true. Requirement Specs are replaced with a Product Backlog, Functional Specs are replaced with User Stories (bite size) and all other documentation is created as and when it's needed. As for planning your tests, hopefully you'll be involved in the requirement analysis process where you can include your test conditions that form part of the User Story.

I've heard that functionality and designs evolve during the sprint. If this is true, can I still use traditional step by step test scripts?
It is true that in some cases the functionality and design will evolve during the sprint. This would invalidate any step by step test scripts that you might of written. However, the key elements of the requirements should remain as captured in the User Story. With this in mind, I would suggest you focus on writing quality test conditions. If the requirements do change, it's easier to update these as you go along.

My tests are audited before the software is allowed to be release. How will this work in agile?
I suggest using a test management tool if you have a requirement to capture test results for audit purposes. As previously mentioned, this might not included step by step scripts, but should include the all important test conditions along with any data entered. Standard defect tracking tools are still used to assist your auditing.

Is it true that agile testers need to become more technical and fix bugs as and when they find them?
I agree tester should become more technical aware. As for fixing bugs, a tester could probably fix some minor defects (e.g typos). However, I still see this as a developer task.

I already work as a tester in an agile team, and in every sprint the developed code is only released to QA with a couple of sprint days remaining. What changes can be made to improve the process?
You need to ensure the user stories are passed onto QA as soon as development is complete. If you find there's never enough time to complete all the test tasks, you could enforce a code freeze before the end of the sprint and get developers to assist you with your testing. Remember, QA in agile should not just be the responsibility of the tester but all of the team. As long you manage this correctly, I can't see this as being too much of a risk.

How do you see the role of the tester changing?
The role of the tester is still crucial to development success. However, I believe the analytical skills of a tester will be used more as agile matures, where they're involved in the requirement capturing process. In smaller teams, I can see the tester role evolving into a hybrid one where QA, product and project managing become one.