If you’re a digital agency or contractor, you don’t want a client to be your quality assurance (QA) tester. Let’s unpack the implications using a scenario you may recognize so you can understand why.
A client has contracted with a digital agency for projects that include a website overhaul and an application development. The agency has provided documentation for steps and timelines.
The client, now the stakeholder, attends kickoff meetings to determine objectives, strategies, etc. The project manager (PM) assigns client exhaustive, time consuming questions necessary for a project roadmap. For less experienced clients, the complexity of turning their vision into reality may now be coming into focus.
Moving into execution, the stakeholders find themselves on a tight schedule of comp reviews, feedback, and approvals in addition to the demands of their regular business. Our client stakeholders may discover (often the hard way) that if they fall behind, costs can go up.
Hopefully a skilled PM or account exec has been diplomatically managing the relationship, hand-holding through tight deadlines, boosting wavering confidence, patiently explaining the purpose of demands, and nursing stakeholders through unexpected delays or costs. Comps are approved, dev teams are generally on-target (in the best of all possible worlds), and communications are reasonably productive. After months, or even a year or more of work, it’s time for pre-launch reviews.
QA Testing?
Throughout the project life cycle, who has been doing QA and UX testing? A staff member? Have the devs been doing their own testing, audits, and verifications? Have they been running tests simultaneous to work? Has the website been fully verified and functionally audited from top to bottom? Is the application code glitch and bug-free? Is every redirect in place? Has domain authority been preserved? Has all this been addressed prior to final reviews? If it’s software or an app, is it ready for market?
Some former developers who become test engineers say that they are amazed at things they missed prior to entering the QA field. QA testing is a discipline — an experienced testing engineer can look at the whole of the software product and quickly know what is needed. Untrained reviewers can miss critical issues due to a lack of product knowledge, and even developers may have a deep knowledge of the app at the code level, but this does not directly translate into being a subject matter expert (SME) of the functionality across the entirety of the application.
Everyone brings unconscious bias to what they produce. It’s not about incompetence or a lack of professionalism; it’s that as humans, we cannot see our own biases like we cannot see the backs of our own heads. There will be bugs. When clients discover them first, they’re doing your QA testing.
The Client’s POV
Whether they have a history with agency/contractor projects or not, clients have been throwing resources at the project, and by now, are likely feeling fatigue. There’s been frustration, stress, and likely more money and time spent than anticipated. Will they now discover inconsistent functionality? Sketchy UX? Broken forms? Redirects? With each unwelcome discovery, confidence will erode and aggravation will accumulate, even if the PM has prepared the players in advance. There is no way to eliminate human emotions, with all their contradictions, from the process.
From the developer’s point of view, it may be that problems the client is finding are ‘no big deal,’ and fixable, but it’s in an agency or contractor’s best interest to minimize client stress and give them the best possible experience with their new website, application, software, etc. because perception is reality. It’s also good business to continually reinforce the client’s confidence in the agency’s expertise and abilities, because generally speaking, it’s easier to keep a client than it is to replace them.
The Same Scenario With QA
Imagine that we have the same client/agency scenario, only QA testing is onboarded early into the project timeline. Strategic communications channels have been established and the QA engineer(s) have set up test cycles to receive, test, observe, and report, establishing a rhythm that contributes to predictable outcomes. Activities and results are measurable, the team and client know what to expect, and everyone has visibility at any given time.
When testing is integrated at early stages of a project, the chances of staying on target increase dramatically, and on-schedule deliveries throughout the software development lifecycle (SDLC) or project reassures the client that the vendor is trustworthy and reliable.
Budgeting for QA Testing
Project managers and clients may choose to save resources by leaving QA testing out of the budget, but a mountain of accumulated evidence shows that it’s more expensive to fix problems later than to find and resolve them while the SDLC is in flight. According to the IBM Systems Science Institute, the cost of fixing a bug after product release is four to five times higher than one discovered during development. Everybody hates budget surprises, but with planned QA testing, agencies can avoid passing the costs of unexpected fixes to clients or absorbing them to preserve relationships.
Testing allows an agency to present a polished product that aligns with the client’s vision and intention, and fosters a better overall UX/CX experience. QA also positions the vendor with the client for a long-term maintenance relationship, or as a trusted partner on new projects.
Moving forward, consider including QA testing in project planning budgets. An agency has everything to gain, and little to lose by using testing to cultivate positive client experiences and project outcomes.