As many manual tests got automated and more programmers start writing tests on their own today, the fair question is: Will the QA role become redundant any time soon?
There are a lot of ongoing debates around this topic. Automated testing is often regarded as a cure-all that solves all QA problems. Many development teams claim that they do great without QA engineers. Companies follow this approach without giving it publicity for obvious reasons, but some of them even boast about it.
Yahoo bragged about successfully eliminating QA at some point. Microsoft and Salesforce were reportedly working without dedicated QA teams too. For Salesforce such practice led to multi-instance core and communities service disruption though, but that’s another story. And for Windows… well, you know the case:
We are not among those who stick to redundant roles. However, we don’t see any reason to talk about eliminating the QA role, rather about transforming it.
Indeed, in some projects due to their scale, domain or context having a full-time QA specialist might be not necessary. But this is rather an exception. Developers and even more so automated tests cannot replace QA engineers. Moreover, there are many benefits in separating dev and QA roles. Here is why:
Different mindsets: Developers write tests to prove their code is correct. Testers – to find how code may fail.
There is a crucial difference in developers’ and testers’ mentality.
Developers have special feelings about the code they write. They know it inside and out. They know the logic behind it. And they can never be impartial about it.
That’s why developers’ tests are often limited. Programmers already know how software should perform and stick to this familiar scope/scenarios while testing. This leads to creating a perfectly accurate but sometimes prone to errors in non-standard situations (missing edge cases) piece of code.
QA engineers, on the other hand, are not attached to code they test. They have no interest in testing it gently. They try out all creative ways of using the software, just like the future users, and find bugs that stay outside of developers’ reach.
As a rule, testers understand business assumptions better and follow specifications more precisely, which is necessary for delivering software that meets business needs.
All this doesn’t mean that one mentality is better than the another. Both are great and needed, as true superpower comes from the synergy between testers and developers.
Distribution of responsibility
Whereas programmers are usually responsible for a certain feature, system, microservice, or simply a piece of code, QA engineers are responsible for the product as a whole. They make sure tests are actual and new bugs and vulnerabilities do not appear after modifications (to different parts of software! by different development teams!) have been applied.
A great example here is the responsibility of performing end-to-end testing of a product based on microservices distributed among various dev teams. Having a QA specialist dedicated to such complex tasks that require the coordination of different teams is crucial.
Not all types of testing can be automated or performed by developers
We are big fans of automation, but let’s be honest – automation cannot cover all the tests as some of them require human cognitive ability and common sense.
Exploratory testing is a good example here. Testers need to use their creativity, experience, analytical skills and be familiar with the logic behind the software in order to find all possible issues. Sometimes it’s intuition and simply a human way of thinking that helps testers accomplish their task. You cannot expect it to be done by a computer.
Another example is already mentioned black-box testing, which isn’t possible without a “fresh” pair of human eyes.
A smart QA tester is the best kind of a rubber duck for a developer
Sorry if this comparison hurts someones’ feeling, but we couldn’t explain the idea better. We all know that software development is mentally heavy and talking to someone about your programming problems is a great way to find a great solution. And let’s be honest, the rubber duck’s role in such discussions is extremely exaggerated.
The situation with QA is similar to safety at work. Safety isn’t the sole responsibility of a Safety Officer – everyone should follow safety rules. If it’s safe at work, it doesn’t mean you can fire the Safety Officer. And people who follow safety instructions cannot replace the Safety Officer.
QA is especially crucial for the ongoing development of products that have been already launched and adopted by real users. Eliminating or moving QA role to someone else means transferring the responsibility of finding bugs on existing users, which is fraught with reputational risks.
We hope you found our arguments interesting. If you disagree or have something else to say – don’t hesitate to leave a message in a comment section below or contact us directly.
