Why is QA important? This is a cautionary tale. Having no defined QA process is a disaster waiting to happen. It won’t just occur once, it will constantly keep occurring. The only thing that will change is the severity of the disaster. Sometimes you’ll have a mini-disaster and other times you’ll bring down the entire production environment. Enough of the gloomy intro, let’s look at the tale from the IT crypt that I’ve actually been a part of.

I’ve worked for a company that had no QA process whatsoever. It was left up to the developer to decide how much QA needs to be done on each task. Considering that each developer was overtasked, there was no QA done. I was the only developer on the team that actually did any form of testing, but that was only on my tasks.

It got so bad with the client demos that each developer was required to demo their portion of the project.

I hope that you’re understanding that I was not having a fun time working here. I wanted to be a developer to hide behind the curtain and not communicate with the client anymore, and here I was getting thrown back into it.

In the next company meeting, I brought it up for everyone to hear, “we need a QA process, otherwise we’re going to keep our clients forever frustrated.”

It was embarrassing for the company to pull up an application that worked earlier that day and was completely down during the demo. There was no such thing as a code-freeze. There was a time when a developer pushed code during the meeting and changed the look of the website while the project manager was demoing the application.

I wasn’t fully prepared for the response that I received from my company.

“If you think you can save the company money then you come up with the process and be in charge of it.”

It wasn’t what was said but how it was said. It’s all about the tone sometimes.

This wasn’t rocket science, but it was a new concept to them. I have no idea who bewitched their minds to believe that no QA would save the company money.

“Not a problem. We can start off with a small QA process and incrementally increase the amount of testing that we’re doing. That way nobody’s going to feel overwhelmed,” I replied.

Once I started working on the process, my boss stated that I should only implement this on the projects that I was a part of. And I did.

It was a simple checklist. I listed out all of the core functionality of the application and the acceptance criteria of the new task. FYI, the acceptance criteria were not included in the task so I had to use my best judgment. It was something that I requested for but could not get. Did you honestly believe that we had a Business Analyst when we weren’t even doing QA?

Each task that was pushed to the development environment was briefly checked to make sure that it worked. The core functionality of the application was also smoke-tested before we moved to the next task.

There was a code freeze implemented the day before the demo. After the code-freeze, a quick smoke-regression-test was done to make sure that the application still functioned. Nobody was allowed to merge the code into that branch until the code-freeze was lifted.

This added 10s of minutes to the overall development. Each application that I worked on was flowing significantly smoother than the ones that had no QA. Who would have guessed? And, productivity actually increased.

The Demo That Changed It All

Applications that had the QA process implemented were demoed by the PM. He didn’t need us anymore since he knew that the application would work fine.

And then it happened. It was one of the cringiest things that I’ve ever heard. I happened to be in office during the time of the demo. This particular client has spent over a million so far in development cost. During the call, the application crashed. The client was audibly upset. When the developer reverted the changes, he took it back to a state that the client was not happy with. They requested for the changes and now it looked like no work was done.

That was the straw that broke the camels back. The client tore into the team for a good half-hour. They threatened to go with a different company and to sue for the work that they were charged for but had not been delivered on.

After the meeting, the owner of the company was not happy. He questioned my boss extensively. How could he let this happen? That day, my boss resigned.

The project manager and the owner of the company spoke and the PM started mentioning the QA process. They brought me in to elaborate on the specifics. I gave them the high-level cliff-notes summary and then went into specifics since they were eager to learn more. They could not afford to make this mistake again. It literally could cost them millions.

The next day I was approached by the owner who offered me a promotion. I moved out of development and into management. My first task was to repair the relationship with the client.

I implemented the QA process with the team and made sure that there was a code-freeze prior to our next demo. Before presenting the changes, I outlined the work that has been done and walked them through our newly implemented QA process. The demo went great and the relationship was mended.

We hired a QA engineer and expanded our testing. When possible, unit tests were implemented to help automate some of the testing. We even got a BA and documented proper requirements with acceptance criteria for each task.

Whenever I’ve moved companies from that point on, I’ve always made sure to tackle QA first. Sometimes communicating the importance of it to the team can be challenging. Actions speak louder than words. Start small and work your way up. By the end, you may just have a QA team, and the organization will understand its importance.