Quality Assurance should always start with a 'clear enough' idea of what good means for your products.
Developers code, Infrastructure Specialists deploy and Operations maintain but, entirely in my experience and not universally applicable, when s*it hits the fan and production systems behave unfavorably, it's the Business Analyst and/or the Testers who are questioned FIRST (and mostly shot first before being asked what went wrong).
Quality is a multi-headed hydra ...
.. since what is good for the goose may not be relevant for the gander. For instance, the definition (and requirements) of Quality for a paying customer is drastically different than those for a Software Engineer (and there is no prize for guessing which point of view should and likely does drive discussions).
Different strokes for different folks?
A user may consider something a bug and ask for immediate remedy while the delivery team will chalk it up as "yet another feature enhancement sneakily slipped into the backlog by a trickster". Throw in the murmurs of concern emanating from the testers and combine them with the ever-present and always-pressing release schedules and we end up with a pretty-looking product whose real value proposition is hanging by a thread, for under the hood is a mish-mash of problems, which eventually combine like Voltron, and become a cancerous growth, seeping into the products 'bones', hollowing it out and, in dire situations, lead to its demise.
"Enough talk please, show me how to navigate this potential landmine"?
I will remind you that patience is indeed a virtue, but it is, in some cases, also a waste of time. Therefore, I present to you "The Bottom-Up Approach for Quality Assurance".
| Ask yourself if .. | In particular, focus on.. |
|---|---|
| The product/service works at all | Are key features working? Is the product/service technically sound? |
| The product/service works well | Is it being true to established SLAs, SLOs, XLAs and Error Budgets? |
| The product/service is respecting aspects of UX | Is the product/service fulfilling desired usability scenarios? |
| The product/service is providing useful value to users | Can we show that a feature(s) were used to generate some measurable positive outcome for the users? |
| The product/service is providing economic benefits to the organization in some way | Have sales gone up, have complaints gone down, have social media sentiments been trending favorably? |
You don't have to hold hands and sing kumbaya
The consensus-based heuristic proposed here requires a Vulcan-ish 'Vision Meld', without being biased towards one point of view vs another. Rather, this is an opportunity to get your point of view around Quality documented, socialized, and debated (and may the best argument win).
Realize that every member of the UN does not like every other member, but they sit down, talk shop, and make sure the way forward is one that will spread the positive outcomes of their collaboration(s) among all participants. A delivery team, made up of Developers, Testers, Product Owners, DevOps Engineers, etc, arguably is not responsible for world peace, just a good product/service.
The 'Vision Meld' does align cross-functional jargon into some semblance of general applicability (and acceptance between warring teams?) and therefore it makes sense to include as broad a set of perspectives as you are possibly able to accumulate.
Creating a strategic framework such as the one provided here can take a long time to initiate, and even longer to complete but all good things come to those who understand that in our hyper-chaotic world, with end users who are happy to play footsie with the competition at the slightest hint of inconvenience, its time well spent and could be the difference between a thriving business or an IBM (yup, I went there).
I write to remember and if in the process, I can help someone learn about Containers, Orchestration (Docker Compose, Kubernetes), GitOps, DevSecOps, VR/AR, Architecture, and Data Management, that is just icing on the cake.