Traditional QA vs New Age QA

In this article, we are going to learn the new definition of QA. Traditionally, QA is defined or abbreviated as Quality Assurance which means assuring the quality of a product. This was mostly done by validating the product during or at the end of the product development life cycle, depending on the agile methodology used in the organization. But as we evolve into the new age, there needs to be a re-look at the way QA is performed, starting right from the definition.

So to start with, let us look at some statistics, which are published by

https://www.dotcominfoway.com/blog/infographic-why-users-uninstall-your-app

• 50.6% of the customers uninstall apps within 7 days of installation.
• 71% of the customers uninstall apps due to annoying notifications.
• 62% of the customers uninstall apps due to bad experiences with Crashes, Freezes, or Errors.

This definitely raises the question of why these numbers do not look so impressive. It is because, in this new age and life, we humans have lost a bit of patience. We only have the patience to wait a few months for a specific feature to be released. We all want the latest features with the best quality available at the earliest.

It is also well-known that everyone with iPhone does not use Apple Maps; instead, install another famous third-party app – Google Maps. Why do we install another app on our devices (eating away the memory and many more) and not use the default Maps app provided by Apple even after more than 10 years of Apple launching Maps? The answer is Quality. This is where we should also bring the most important end-user hat while testing our product. Before introducing the new definition, let us drill a bit deeper into this topic.

There is always a great discussion on Dev vs. QA, like the picture below.

This is exactly where our new definition is leaning towards.

Personally, I believe that instead of saying Dev vs. QA, we should term Dev and QA. We all should work together, taking combined ownership of the product. We should concentrate on ELIMINATING a potential bug rather than finding it later in the product life cycle.

Now, let us take a look at how we can achieve this. I recommend working with them at the start of building the product, understanding what could go wrong and where it could go wrong, and discussing with all the stakeholders to get the product built right.

There is no secret to it; this is very straightforward, and here is what I recommend:

Get involved in the product as early as possible, and get in touch with the Product and Dev teams before the refinements. Take part in these refinements, thoroughly understand the product, and build the test cases.

Right before the Dev team builds the product, share the test cases with everyone and put it on the User story itself as an Acceptance Criteria. Ensure these test cases go in as Definition of Done for the ticket.

This way, the Dev can check for these cases and would be able to validate them. The QAs need to review the Unit, Integration Test cases, and all the reports. This way, we can advocate product quality better. This is where I would like to introduce the new definition of QA – Quality Advocate. We all should advocate Quality in the entire organization so that we aim to build the product right. By reviewing the Unit tests, we should suggest code changes and be able to make these changes ourselves.

Overall, my suggestion would be to move away from Quality Assurance and to Quality Advocate, bringing the right product in the right manner. Ensure the Definition of Ready and Definition of Done are properly framed and followed up in the entire organization or for the product.

This way, we need not worry about having to spend Friday nights/ holidays thinking about fixing a bug; rather, we can all have a good break together and come back strong. So let us all embrace the new definition of QA, start the concept of Advocacy and enjoy being a Quality Advocate with an ability to learn more technologies and stay relevant for a long time in the Industry.