I am a Quality Engineer.
I am always asked to discuss Quality Assurance as a process in one of the ‘Unconferences’ that my current organization engages in, might I add, in a very enthusiastic way.

An Unconference is a brilliant concept and it takes us away from the traditional ‘Expert talks and some pretend to listen’ gatherings of interested and uninterested professionals.

So here I am preparing my notes for the ‘The good, the bad, and the ugly side of quality assurance practices.

There is always an ambiguous feeling in my stomach when I am asked to talk about software testing. First of all, I do not like the term. It leaves kind of a bad taste like an afterthought of a software development process. In effect, software testing or Quality Assurance is one of the early steps in a software development lifecycle. It begins with verifying the requirements that are put on the table.

As part of my current assignment, I am supposed to iron out the testing process for a client and stop it from becoming the Titanic that hits the inevitable iceberg of Quality Assurance bad practices. My first thought and the first step I want to take is to turn it into a broader function and call it -
Quality Engineering.

While I evaluate the current QA process, I might as well dive deep into a little bit of nostalgia around the start of my career in Quality Engineering. I have a vivid recollection that it was one of the career choices that was frowned upon as non-technical in a chest-thumping technical field. It looked like an emerging field to be a subset of the business aspect of software development. It was yet to come into prominence.

When I talk about the Quality Assurance process after all these years, it comes as a great surprise to me when I am greeted with similar pain points from a decade ago. Pain points like
- Lack of Detailed Test Case Authoring
- Early Automation and No Traceability
- Lack of Entry and Exit Criteria
- Undistinguished environments
- Undefined Test Approach/Strategy

Oh, to my dismay!!

I am retracing my steps here, but the more I think to myself, the more I begin to ponder that Quality Assurance is more than a process. It is an Engineering in itself, an ever-evolving field that enables a smooth and efficient release of the software.
The engineering process is divided into multiple specializations like

- Product A/B Testing (Product Management)
- Usability Testing (UX/UI)
- Quality Assurance (Test and Deployment)
- Quality Control (Production Support)

As I said I wanted to revisit some of the topics, so I got thinking and decided to write down a few of my thoughts.

Since I am supposed to initiate discussion just about Quality Assurance practices, I thought I can slip in the term Quality Engineering in a way that people begin to talk about it. I think I have seen ‘Inception’ quite a few times for my own liking.
I began to draft the topics and some points to highlight, which, I started right at the beginning - Of my career and of Quality Assurance.

Quality Assurance - The Definition

Quality Assurance can be stated as a process of verifying and validating that the software adheres to

• Technical
• Business
• Functional
• User Requirements

The process makes sure that the end product is usable to the end user.
I think any nuances that we may want to get into can be sufficiently placed into any one of the above broader categories.

I started working with one of the most popular software development methodologies back then called the Waterfall model. My day-to-day looked pretty simple then compared to now, but that’s expected out of a novice. I had to go through the business specifications and functional requirements of either a new feature under development or a change request that was being considered for the next release.

The process can be summarized as -
Read, Analyze, Understand, Build Tests, Gather Test Data, Execute Tests, Raise Bugs, Report Results and Repeat.
It was more of a Black Box.
It sounds simple and effective enough. Each step was followed in sequential order that allowed enough room to document and engage with stakeholders. What it did not allow is the room to go back and forth on even the minor changes be it from business to development.
I think back then we all had some frustrations and anxiety around this irreversible process. As a novice starter, I wanted the room to make mistakes, I wanted to be more Agile.

Quality Assurance in Agile Mode

The need to be more flexible in delivering efficient releases of a product meant that the sequential approach no longer worked to its advantage rather it was more of a hindrance.
A new approach was adopted where the requirements and solutions evolved together while Development and testing teams worked in collaboration. The novelty of going through established specifications was no longer available as an option but Quality Assurance Engineers became part of the evolving requirements, specifications, and development process.

I evolved and learned to ask relevant questions. Questions, one thing I had in me in plenty. I learned to work with still developing features and to write tests that covered the basic behavior of a new feature in conjunction with subsequent other evolving features.
Work was exciting, as I was learning new things while running the testing process in the loop. I realized quickly it is a Continuous loop until the final stage of Deployment is reached and even then you only stop to look back, in retrospection, on petty mistakes. I was evolving as a Quality Engineer. I learned to absorb both business and technical questions that were asked of me.

Testing was no longer a black box full of specifications but a more immersive process of software development. The process turned testing more into a white-box approach.

Evolution of a Quality Engineer

There is always a broader categorization for Quality Assurance Professionals as Testers which essentially limits them from what they really are - Quality Engineers.
The further segregation of testers into manual testers and automation testers takes away the essence of the role of testing. It builds a corporate hierarchy into a functional division of a software development lifecycle.
In effect, I believe that if a quality assurance professional is limited to certain functional aspects of its role, the team effectively loses out on quality at multiple stages in the lifecycle.

I remember when I first started, I struggled to understand the thought process behind some of the business requirements. As I got clarity and became more experienced in the role, I discovered ways to ease the repetitive part of my work using scripts and automated tools.
As I continue to learn more about different aspects of software development, I was a software tester, evolving more into a Quality Engineer who is responsible for quality at different stages of the lifecycle.

The Quality Engineer needs to have a good grasp of multiple aspects of a software development process. Typically Quality Engineer has business and technical understanding that establishes a clear communication line between stakeholders, Product Managers, and Developers.
Software Testers must be allowed to evolve into Quality Engineers.

Quality Engineering as a Team

There is multiple trains of thought to proceed with formulating a quality management team.
The more popular route of testing as you develop, rinse and repeat has been done to such an extent that it seems to be lost in its own maze. The reason to introduce checks along the way in software development is to correct the deviations from the path of agreed-upon specifications.

I believe the more integrated a team has become, it has lost the essence of quality management.
It has become a subsidiary function of development which allows for functionality to be stockpiled up on an already under-tested and unstable developed code. Anything after that is just a process of correcting the margins of deviations, which defeats the intention of having quality checks in the first place.

There arises a need for a dedicated Quality Engineering Team that focuses on the process of Quality management. I cannot stress enough that the focus has to be on the process and the requirements around fulfilling the quality checks and not catering to the pitfalls of the development process.

That being said, there are massive pitfalls to a bad Quality Management Process, which can essentially cause the doom of the whole development process.

Pitfalls of a bad Quality Management Process

I don’t think I can think about quality management and not dive into a bit of a negative scenario.
It is still a major possibility in today’s organizational structure to have a half-baked quality management process.

In a Software Engineering Lifecycle, quality management still falls prey to being a more technically driven phase of the lifecycle than being process-oriented.
A bad quality management process is one that tries to solve the problems posed by adopting tools at an early stage without a clear understanding of the problem statement or the final goal that the tool is trying to reach.
A bad quality management process ends up using resources for the upkeep of the process itself than for the betterment of the quality of the product.
It becomes a subset of the development lifecycle that ends up being an overhead to the process itself. The outcome is a tragic mess of half-baked processes supplemented with ill-defined tools that do not provide any insight into the health of the software.

In conclusion, I can safely say that as I have grown as a Quality Engineer, it has become a major task to keep a team focused on Quality Assurance as a Process and not let it become just a small function of a broader development team. Overall my main consideration is to narrow down on the process that fits a team and then repeat it enough times so that the need for automation tools becomes clearer to work on what it was intended to do in the first place - automate repetitive tasks and not replace Quality Engineers.

In an effort to outline Quality Engineering into small chunks of easily consumable posts, next, I want to cover the different aspects of hiring Quality Engineers in any organization.