Some people consider testers (QA) to be responsible for quality in the entire software development process. It is understandable — the name of the Quality Assurance implies that they are not only responsible for quality, they provide it.
You can't make QA engineers responsible for the entire product. Especially if he can't read code, let alone write it.
QAs definitely are on the last line of quality defense, but they can't provide all the support for the product quality. And shifting the responsibility for quality to QA team is wrong. It is the responsibility of the entire team, from the analysts who describe the requirements, to the support team that gets involved after the release.
Things can go wrong at any stage of the product lifecycle:
- Incomplete requirements are coming from the analyst, and the project goes in the wrong direction from the start;
- A tired manager at the end of the day will agree with a poorly interpreted Definition of Ready for the analyst story;
- Developer may misunderstand what is expected from him;
- Developer may refactor the functionality and forget to tell the QA about it;
- QA engineer, during testing the same functionality, skips the test case because nine times before it has worked correctly;
- DevOps engineer does not run a new script during deployment, as a result, the production does not work correctly;
- Test data and environment on test system does not match production…
This is only part of the reasons, there are many of them, and if in the case of some problems you need to train a QA-engineers, in other cases the QA is definitely not to blame. Problems must be sorted out and solved with the QA team, but you can't blame the problems of the entire product development on a specific stage.
Why do we have QA then?
Paradoxically, they are responsible for quality. Or to be more precise, to improve the level of quality.
Let’s replace Quality Assurance term with Quality Assistance.
It's not my term. As far as I know, this concept was introduced by the guys from Atlassian. For them, Quality Assistance is a set of practices that helps shift the responsibility for quality from testers to the whole team.
There is a huge chasm in skills and areas of responsibility between full-fledged quality assurance and normal testing — reading and writing code, analyzing requirements, understanding business value, setting up processes, going beyond the testing department, etc., etc. Providing quality is impossible if one is only in one stage of development — after writing code and before the release.
To assist quality, minimal testing skills are sufficient, but focused not only on new functionality and regression. During testing we check the expected behavior against the actual behavior, during quality assistance we go beyond that and start touching each product development step. We start asking questions — “Is the expected behavior correct?”, “Is it possible to influence the real behavior before the build arrives in release?”, “How can we help developers produce quality results as early as possible?”
These questions are asked by ordinary testers too, because almost every article teaches you to think in these categories. But these articles usually don't go beyond the testing stage, beyond the role of the tester. I believe that there needs to be a paradigm shift in thinking from quality assurance to quality assistance and not just within the QA team, but the entire team involved in product development.
Materials
- How Google tests software by James Whittaker, Jason Arbon, Jeff Carollo
- Developing quality assistance skills
- Moving from quality assurance to quality assistance
- Shift-left_testing
Buy
me a coffee