The evolution of QA that finds no bugs 🐛

If you are QA and find no bugs, this is not so bad. It’s time to break the conventional methodologies.

Until a few years ago, the QA was the guy who just planned and performed manual tests based on documentation and requirements, and that only happened in the testing phase.

We see and live an evolution in the role of QA, which becomes much more strategic within the team and close to business and product issues, while still running the tests. Programming skills for creating automated tests and shift-left testing approaches also enter this evolution package.

What triggered the motivation for this changes?

Manual tests focusing on validating requirements, finding bugs and ensuring that nothing has been broken became:

Extremely expensive: Especially when we talk about regression tests, which need to be performed repeatedly, for each delivery, ensuring that nothing breaks the existing system. This test is usually the one that takes the longest running, and time is money 💰

Boring and demotivating. Once again, the repeated execution of the same tests, always in the same way, always in the same phase, generates a certain discomfort, which comes to cause demotivation.

And now about the Evolution

The activities of the QA professional have changed based on a change in the FOCUS of the role

QA is a Mindset

The QA is now part of the team that develops a product. Being involved in the early stages of development or design of the product on the activities varying from involvement in estimates, technical discussions, requirement review’s and mainly evangelising quality.

Traditionally, QA’s were known as the folks who break things, who find bugs, but QA’s role is far more important. It’s not that QA can discover what is wrong, they intimately understand what is right and they unfailingly strive to push the product in that direction which makes them the blockers or bad cops always.

Quality as an activity

With the evolution Quality is no longer a phase. The main objective is to understand the business and prevent defects. The activities start by aligning with the PO on the creation of stories and acceptance criteria, with the help of product/domain knowledge he has.

Test automation

This is the biggest break for the individual who acts as QA. Many IT professionals went to the QA area at some point due to the lack of intimacy with programming, which is the technique responsible for automating the repetitive and high-cost tests. The insertion of software engineering in QA activities contributed to bring Dev’s and QA’s closer together.

We can then say that the new FOCUS of QA is not in finding bugs, but in preventing them from happening, and if they still do, in a controlled time and environment and before it causes negative impacts.

This mindset presented as “new” is not that new. We see a lot of people talking about these practices, great lectures, articles, posts, videos, etc, but we see few QA’s applying these practices on a daily basis, since they are stuck to traditional moulds.

Thank you for reading this far :) Inspired from various sources on the evolution of QA Professionals and some real life incidents 😊