Same reason every author needs an editor.
Same reason why we need peer reviewers in a 360-degree feedback.
No fancy reasons. We all need another pair of eyes to tell our flaws.
Then why am I writing a blog post about it?
Because this question has been raised too many times and it lingered on in my mind. Do we really need QAs?
“We don’t need QAs. If a company like Facebook can pull it without QAs, why can’t we? We can do it with our Agile Programmers.” There is a possibility that you have often heard startup owners talk like this when they are asked how many test engineers they have in their team.
Well, I am not going to go into what happens with these startups. But say it, again- Do we really need QAs?
And, in a single breath, I am going to answer it- YES!
This simple question has opened doors to a lot of raised eyebrows, lots of smirks and lots of hatred. But trust me, I am on your side. The QA side.
All the QAs reading this post can relate to it. Your job title is QA, but they call you a ‘tester’. Your job is to find bugs. But there is so much more that you do. And still, they question your existence!
Allow me to paint a picture of how the world would look like if writing a program and testing it was a one person job-
- Hire coding ninjas who eat, breathe, sleep code.
- Ask them to write the code and a lot of automated tests for every small functionality
- Make them find their own faults
- Ask them to perform more Functional, Acceptance, Regression and Performance Testing.
- Make them write some extra logging and traceability code into the software so that you can easily pinpoint the lines of code which are not functioning as they should.
Do you see where we are headed?
We’re headed towards exhausting the programmer. Granted, developers can test their code, but being a programmer their primary goal is to design something that works. And just as a camel can’t see its hump, the programmers can’t catch their mistakes. Their motivations are much different than testers.
I can’t emphasize more but let me try to rephrase it in a more effective way-
You need constructive as well as destructive perspective
Did someone ask developers “why can’t they write a code without introducing any bugs”? No, right? That’s because producing a flawless working software is near to impossible. Software development is a complex process.
So when programmers write their code, they are more focused on solving the business problem and as the creator, they are always biased towards their own work. Even though developers perform their unit and integration tests, they are less motivated and less apt to discover defects in their own code.
But Quality Analysts have an eagle’s eye when it comes to finding code flaws. And it’s the role of testers to discover flaws in that design. It’s their job to see if the system does as intended. It’s their job to discover the possibility where the user will be stuck. They scout for real-world scenarios where users might face friction.
But that can be done with automatic test cases, no?
I am not against writing automation test cases. But, let’s try to be rational- depending on some code which does what you want it to do can again have some loopholes. That’s why even QAs do both manual and automation testing.
Testing is a cognitive activity. It is not something that can be performed by a machine. So if you write an automated test against a particular case, it will test against that particular test only. So that means you know the result in advance for an automated test case to run. Which is like glamor-testing. You are only doing it to prove that the machine works as per your whims.
However, when humans test, they ask “How do I know this works as it should? Let me tear it down to bits and pieces”. And that’s what brings all the bugs to bend their knee.
To be, or not to be. That is not the question.
The kind of environment in which we work today demands agility in every domain. Be it a programmer or a QA, everyone should know the agile way of things.
The only thing that should matter is that the quality of the product should not be compromised and should delight its end users. For that, I believe, QAs should adopt the Agile methodology and work alongside programmers to speed up the SDLC.
And as QA, I can only say that don’t be stuck with the age-old definition of a tester. Embrace the new definition with grace. You are now a Quality Assurance person.
Good luck with that!