A Case for Quality... We Don't Need No Stinkin' QA

After 20 years in quality assurance, I’m still surprised to hear about companies that don’t have formal QA processes. Even more surprising are the companies that say having a QA function is not necessary. Maybe they are a newer tech company with a tiny, tight-knit development team and the software complexity hasn’t reached a level where defects reach a critical mass or perhaps the company doesn’t support a formal process even though it’s happening in some manner. For me, it is akin to saying breathing is not necessary.

In the larger, more complex environments I’ve worked in, testing is a must-have. It is not only an integral part of the software development lifecycle, but a guiding principle for business as a whole. But even in smaller companies, code has bugs. Someone needs to find them. And it’s better to find them sooner rather than later. Quality doesn’t just have to do with testing code, it is really a guiding principle from start to finish during a project. But before I forget, might I mention that the best implementations occur when every level (leadership, management, and team members) of the organization is involved in the process, as it is everyone's responsibility if you want to achieve quality on all fronts. Some ways to ensure quality at every level is by:

Creating healthier relationships between QA and development to break down silos between the two groups
Growing comfortable to questioning, feedback, and even disagreements between team members
Understanding the risks of the project at hand and discussing as a team what the most important goals are for the current week, sprint, etc.

But, back to my main point... Companies may rationalize that they don’t need QA for a variety of reasons. This could include cost, impact to timeline, limited resources, or the inability to see the intrinsic value QA delivers. Let’s dive deeper into some of these reasons while debunking some common myths about QA.

I always have the same answer for this: make time now or be forced to make much more time later. The time you spend preparing for and executing your tests is time better spent than time handling fallout from software that doesn’t work. This may be time spent troubleshooting or fixing production bugs, fielding negative feedback from users, and explaining what happened to management. These are all activities you can prevent with the right investment in a QA practice.Wait, what?!? Oh, you were serious? Unit testing, by definition, is only exercising small pieces of the code. There is no integration with other areas of the software or system. If dev is going strictly by the code it has written, which may or may not be correct based on the understanding of the requirements/acceptance criteria, relying on only unit testing is akin to asking builders to do their own home inspections. There must be checks and balances in place, to independently verify that requirements/acceptance criteria were met and no existing functionality is broken. On an agile team, a developer may perform this testing, but ideally it would be someone other than the person who wrote the code.Do you have money to throw at problems that may surface and cause major issues after go-live? Maybe you don’t want to pay upfront but you will pay later… with higher costs. Late code delivery/releases will cost more in the end. According to the System Sciences Institute at IBM, the cost of a software bug found in the requirements phase is $100. Finding that same bug during QA testing phase has a cost of $1500. If that bug isn’t found until production, the company is looking at a cost of $10,000. Involving QA early and often, and not just in testing, will mitigate many risks of not delivering quality software. Of course, if you are using agile, involving QA early and often should already be built into the process if you are doing it correctly.

Aside from cost, there are many other factors to consider in the test planning process to ensure your test efforts pay off. A few areas to keep take into consideration may include:

Identifying test objectives and scope
Assessing and accounting for risks and contingencies; including technical, environmental, and scheduling risk factors
Determining component/application priorities
Estimating the size/length of the test effort

You probably do, but you just don’t know it! Everyone at your organization has shared responsibility for delivering an outstanding product. Everyone knows what could help it be even better. Your users know the issues that crop up repeatedly after a new build or deploy. The people who handle the production support calls also know the kind of tickets that are opened after a deploy/new build. Sit down with these people and learn the details. Start with those items as the baseline to your regression test suite. Someone can write basic step-by-step tests in excel that can serve as test cases. You don’t have to start with ALM, Jama, and other tools or make a huge investment. You need the right resources with the right experience, to lay that foundation, along with your current team.

Before you are ready to take your QA to the next step, make sure to include the entire organization in the process. This will help to instill quality in your test teams at every level. Some key things to remember when building a quality software QA team is:

Pairing between Dev. and test
Nurturing professionalism within in the team
Growing professionalism with T-Shaped members
Encouraging self-inspection/self-policing

QA is not just one part of the SDLC. QA is a continuous process. They should be involved during requirements all the way through implementation. Agile does this right by generally involving QA people during sprint planning through sprint closure. Waterfall needs to engage QA during project inception as well. During requirements gathering/story pointing, QA should be involved. They should ensure that the requirements are clear and testable. They should be thinking about the data and environmental needs. They should think about whom to involve from UAT. In addition, during Implementation, they should be involved to ensure there weren’t any gaps in the testing.

I think we can agree that everyone wants to deliver a quality product, at least that is what most IT people say. But to do this, every company must have a dedicated QA function. You don’t necessarily need fancy tools or tons of personnel. But you do need personnel who understand how to ensure quality as well as a culture that embraces it. Fit quality in wherever and whenever you can. I can assure you that without QA, there will be costs you cannot afford. I can also assure you that if you look for it, there is tremendous value in QA. And whoever might have said we don’t need no stinkin’ QA, was right. What we need is great QA.

“Quality is the best business plan.” ~John Lasseter

Next up:

Learn more about our software test management training course.

qa process unit testing Testing agile team roles user acceptance testing SDLC shift left qa budget finding bugs in code test case qa process flow regression test suite qa process in agile agile implementation