The QA discipline transformation is here, are you ready to leverage it?

When I first started writing code, I had a few Rockstar QAs on my team. I remember once I told them that I am done with the feature they could guess what could be the possible scenarios I had missed. It was surprising for me to know that they were able to do it with other senior developers as well. They understood the developer as a person. His or her view of understanding the system and coupled it with their analytical skills and domain understanding. The output was a great quality product.

As development changed, so did the QA. Having witnessed the rise of automation, testing frameworks, test suites, and a range of tools to improve the quality and complement the skill of the QA discipline.

A few years back when I got to know that major tech companies are moving away from having a dedicated QA team for product development and are going to institute everyone as engineers, I welcomed the move. I had a network that was part of these kinds of product teams that reacted in mixed reviews about this change. But, they knew, that was the future.

The QA discipline and Dev discipline came together and became the software engineers. In our consulting world working with companies that have a lot of development going on, it was hard to bring a radical change like that right away. The skill of Manual QA with respect to Domain and edge cases which are pretty common in health care systems was tough to replace. But we wanted to innovate in this space.

How can we bring in the expertise of QA on the domain aspects coupled with the discipline of software engineers?

We started evangelizing our QA tech capabilities and got into engagements that were just QA-related. We built a sales force QA automation framework from scratch. We built a regression suite enhancer for a health care customer. We employed a layer-driven data set validation framework for another client. This gave us insight into how we can elevate the QA discipline.

We crafted the technology stack and defined development guidelines for this discipline. We employed all the required processes of CI-CD, code reviews, design change requests, etc in these platforms. We retained the manual QA muscle with brainstorming sessions and test scenario war rooms.

The work is still in progress to formalize it, but these insights motivated us to get the Dev and QA together as software engineers and under one hierarchy delivering a different value to the project. We have seen cross-pollination happening. People move from one project to another, one responsibility to another. Very soon we will see Full-stack engineers 🙂