Interesting article from a Scrum Master at Sky, “So we’re going “No QAs”. How do we get the devs to do enough testing?”.
I find it hard not to agree with a number of points in the article. QAs in my mind are a get out of jail card for engineering to throw code over the wall and run to the next story. Further, its a great excuse to avoid writing tests which a lot of engineer find boring. Finally, its a great reason why TDD, and BDD (my preference) is largely ignored on a lot of projects, allowing engineer to assume the role of a “hacker”.
dedicated QAs allows developers to abdicate the responsibility for quality to someone else
“Hacker” engineer is what a lot of engineers are. They don’t design the solution, or consider how to get to “done”. They write the code, and refactor until though basic minimal manual testing, the solution does the right thing. They then write a few tests, commit, and in their minds, they are done. No QAs forces the engineering team to own responsibility and eat their own cut corners.
Without QAs, the devs have a vested interest in speeding up testing by automation (which pure testers don’t; why would they put themselves out of a job?)
The QA world has gone though various re-branding activities in the last few years. More recently the “Check and Test” re-brand. At the end of the day, a lot of defects are either due to the engineering solution, and lack of appropriate engineering tests (unit, integration, etc), or due to the problem not being fully defined during analysis/discussion of the story.
QAs usually want to hold up a build until every possible test has been run. Unfortunately this isn’t the real world anymore. Its not uncommon to make n releases a day, hour, week. Further, business demands can mean that you need to release with defects, but the defects aren’t business critical. We should also remember that the world isn’t perfect, and we are today, with technology, never going to release defect free software. What is actually more important is having a continuous deployment pipeline that is efficient, so that if we find defects, we can release to resolve the issue.
Which brings us to defects. Defects are defects when the acceptance criteria/tests fail, and the UI doesn’t look like the UX. Are defects really defects when the story didn’t provide the appropriate information? Or are they new features that emerged, that continue to refine the solution. QAs in my view are hung up in defect tracking etc. Maybe some QAs should consider looking for work in the Business Analysis land, or becoming engineers that can improve the standards of code delivered to production. At the end of the day, the solution is only worth something when its in production, and being used. Until that time, its waste, with no payback