Testers Early On: What Does QA Do On Day 1?
I am so tired of hearing people say that we do not need testers early in a project or early in a sprint because there is nothing for them to do until dev has finished some work.
There seems to be some mistaken idea that the sole value of testers is to validate the output of development, that testers are blocked until development completes a feature and “delivers it to QA”, that they are helpless until they have something to test.
Too often I have seen a delivery workflow where testers do not engage until after a developer declares something to be “dev complete” or “ready for QA”. When a tester is often given the authority to pass or fail a developer’s changes the developers are usually asked to work blindly, not only starting but also finishing their work uncertainly, before even knowing what the true acceptance criteria are.
When you think about it, that is a recipe for rework.
"The job of a tester is not to execute tests. The job of testers in a team is to design the tests. @SMRobson #CukeUpAU
— Em Campbell-Pretty (@PrettyAgile) November 18, 2015So what would testers do at the begining of a sprint?
Here are some ideas:
- review and validate the quality of the requirements;
- draft acceptance criteria;
- define test scenarios;
- pair with developers;
the Two Questions
I often ask developers two questions about any piece of work in progress:
- How will you know when you are done?
- How will you know that it works?
If you do not have clear and ready answers to both of those questions, is it responsible to be adding or changing code?
the two Three Questions
Depending on the answers to the first two questions I sometimes follow with a third:
- How will you know that you have not broken anything else?
This leads naturally to automated tests and how we can lean on an automated test suite to detect unintended side effects of making a change.