Project managers (PMs), team leaders, and product managers in software development are BUSY. It’s difficult to get all the plates they spin into one sentence, let alone a paragraph. To oversimplify, these roles orchestrate moving projects forward, navigating bottlenecks, stalls, and communication breakdowns, while being accountable to stakeholders, both technical and non — think CTOs and CFOs.
In addition to often mind-boggling responsibilities, PMs, product managers, and team leaders can land in the hot seat as the interface between stakeholders and developer teams. Experienced PMs may understand that bringing QA testing into early planning and budgets can set the stage for a smoother ride and better outcome, but convincing financial stakeholders of the additional expense might be challenging — particularly non-tech players looking to shave costs.
Making a logical case for QA, backed by facts, is a step towards getting buy-in from fiscal decision-makers with short attention spans. Below are six talking points (and one fallacy rebuttal) for a meaningful conversation about independent QA testing in software development life cycles (SDLCs).
1. Money.
Stakeholders may be most susceptible to influence when we start talking about costs. Help them understand that introducing QA testing into an SDLC can significantly reduce costs associated with fixing bugs and defects, especially when compared to the cost of addressing these issues at later stages.
The Systems Sciences Institute at IBM reported that it costs about six times more to fix a bug found during implementation than during design. Moreover, the cost to fix bugs found during the testing phase could be 15 times more than the cost of fixing those identified during design.
There are other direct and indirect costs associated with failure to onboard independent testing, but the fact of the matter is that the longer a bug stays within the SDLC, the more expensive it is to fix. Good QA also contributes to projects staying on-budget. From a fiscal perspective, it might be wiser to hold out for additional funding for QA rather than launch into the breach without it and blow resources trying to clean up later. And nobody likes implementing unplanned changes or pushing hotfixes in a live production environment.
2. Time.
Almost inseparable from money, time is of equal weight in consideration when it comes to SDLCs. Failure to address critical bugs can derail the release timeline (and budget). Introducing testing early in the SDLC prevents compounding errors, which can escalate in complexity, cost, and time. Good QA testing goes a long way towards maintaining schedules and budgets within the project scope, and contributes to better outcomes.
3. Predictability.
QA testing fosters a predictable and controlled development environment, enabling better project planning and resource allocation, again contributing to products delivered on-time and on budget. When capturing quality metrics, it is important to have a level of consistency present in your reports. Execs do not like surprises and predictability goes a long way towards preserving everyone’s mental hygiene and happiness, resulting in healthy, sustainable SDLC cultures.
4. Quality.
Does anyone really want to launch a low-quality product? QA testing brings a product into alignment with specified requirements and standards, resulting in a better product. A quality-focused culture leads to an environment of checks and balances. This transforms organizations, and extrapolates to higher product adoption rates. According to one research study, “Quality requires a commitment, particularly from top management. Close cooperation of management and staff is required in order to make it happen.” Quality flows organically into the next topic.
5. User Experience and Brand Perception.
Poor quality directly impacts user perception of a brand, and in this age of online product reviews, news of dissatisfaction spread fast. Consumers, both direct-to-consumer and B2B, research products prior to purchase, especially expensive ones. Consumers are also quick to digitally broadcast their unhappiness. A glitchy product launch can quickly rebound to negative brand perception, which is another source of indirect cost — from a marketing and communications perspective, it’s expensive to repair a damaged brand and overcome bad optics. Poor UX also means high churn rates.
6. Market Competitiveness.
In competitive markets, software quality can be a key differentiator. Investing in QA testing early and throughout an SDLC can result in a product that rises above competitors in terms of quality, reliability, and UX. Falling behind competitors can extrapolate to loss of market share. This may vary by market, but it can give a critical edge in highly competitive sectors.
Any one of the above truths should be enough to persuade stakeholders, but they may argue, “Why can’t the developers do their own testing?” That’s a topic for another blog, but a PM needs an immediate rebuttal.
Here’s why SDLCs need dedicated QA test engineers:
Experience: Developer mindset is one thing — QA testing is another. QA test engineering and software engineering are different disciplines with different accumulated practical experience. A skilled QA engineer begins with a clear understanding of the most typical bugs. A developer is not thinking in those terms. You want skilled, experienced, dedicated QA engineers on your team. Aside from that, testing is simply not good use of a developer’s time.
Mindset: Developers are thinking about how to create an application — test engineers are thinking about how to break it in order to find the flaws that an end user would encounter. Generally speaking, developers use code for problem-solving rather than thinking from the user perspective — independent testing acts as a advocate for end users who ultimately determine the success or failure of a product in the marketplace.
Natural human bias: A.K.A “cognitive bias.” This is absolutely, positively unavoidable, period, and must be accounted for. Also called “confirmation bias,” it is the tendency to, “Verify one’s own hypothesis rather than refute it.” This is a hard-wired behavior — a fact of life like changing seasons.
These structured, logical points can provide meaningful leverage when making the case for QA testing in SDLCs. In the best of all worlds, PMs and product managers in planning stages have the opportunity to successfully make the case for early testing. Good luck, and may your SDLCs be ever in flow.
