Your MVP Won’t Fly without QA — Here’s Why
Throughout my QA career, I’ve heard more times than I can count that we’re not so important. Quality assurance is a time-sink, an extra cost, a hindrance to the ‘ship fast and break things’ mantra. We’re here to ship things that break less — reliable products that yield life-long customers.
Obviously, you can’t fly a plane without someone having built it first. It’s the same in product development — the devs built the thing so they’re the most important. Right?
Yes and no. Do you want to ‘just’ build something or do you want a product that can truly take flight? And not just launch, but expand features as it flies along the roadmap.
Testing has a variety of ‘clinical’ and dry definitions. We’ll take Lee Copeland’s simple definition: “Testing is the process of comparing ‘what is’ with ‘what ought to be’.”
Here are the standard goals that come to mind when we discuss testing:
- Make sure that all the product or feature requirements are fulfilled.
- Make sure everything works as expected (everything, really?).
- Make sure there are
zeroa minimum number of defects.
So we think it’s important to align our testing goals around this reality:
- Make customers and end-users happy with the product.
- Provide sufficient (and realistic) information to stakeholders about the quality of the product.
- Reduce the risk of non-working functionality to an acceptable level — one that allows the first goal on this list to be reached.
Our QA team aims to fulfill those goals. Clearly, it’s impossible to test everything. There’s always a lack of time — so we balance the minimum threshold of reliable functionality with maximum product development velocity.
To do this, we stay aware of changing product or feature requirements and improvements. We focus on these change areas and select tests to cover these risk zones.
We balance between business and engineering. We put ourselves in the customers’ shoes to be sure that the user flow is smooth but keep in mind the technical risks lurking below the surface.
This is key to predict just how much a tiny business change request can cost.
We have refined this testing process throughout our 11 years of product engineering. It is by no means a one-size-fits-all approach — because different products require a variety of security and complexity.
Following these steps helps maintain a transparent relationship with our clients and teams. And we all learn from mistakes in order to build even better processes and products.
Finally, prioritizing manual testing lets us contribute in a meaningful way to project progress and overall product quality.
Would you like to fly with a pilot who does not understand aircraft mechanics or aerodynamics?
I don't think so — such a pilot is unlikely to inspire confidence in you. It's the same with testing. Knowledge of the tech implementation, system weaknesses and strengths gives a test engineer solid ground.
With this foundation, we can not only test software in the best possible way but also predict and prevent problems. This is key for adding and planning new functionality in growing products.
We pay special attention to the following 🧐
Everyone knows that the sooner you find an issue the cheaper it is to fix. We put time and effort into refining and clarifying requirements with the Business Analysis team to search out and mitigate any discrepancies, inaccuracies or errors.
We check that the logic is correct and care about the user experience. We strive for a smooth user flow and propose improvements in the product’s UX design if we see any difficulties.
Technical implementation & edge cases
We learn as much as we can about all product stack elements — how they are connected and interact with each other. We pay special attention to the peculiarities of 3d party integrations and APIs. We check user flows on edge cases and try to find all the loopholes.
Affected functionality & impact analysis
We know that bugs are a natural element of product development. But we are also aware that a rushed fix can lead to a cascade of changes and new issues. We analyze impacted areas and check that functionality continues to work as expected.
We verify that everything is stored, updated and deleted correctly.
In Paralect everyone knows that we are here not to blame but to help improve product quality with our professional pessimism and skill set. Each team member understands how important it is to discuss questions with colleagues in order to minimize personal biases and find the best solution. Testers are also human — so we also make mistakes.
No objections — scripted testing is a good starting point. But let's keep in mind that "the difference between excellent testing and mediocre testing is how you think". The exploratory approach is complicated but needed to design effective tests. It fosters continuous learning, understanding system interconnections, compiling mental models of a product and experimentation.
Very often — especially in large projects — QA engineers are the people who know the product better than anyone else.
Developers may work only with a specific area and business analysts are busy with elaborating complicated business flows. Your quality assurance team is usually somewhere in the middle, combining business and technical context in their heads and even providing support for customers and back-office staff.
A good QA team helps startups find answers to knotty, complex questions. When these problems are resolved, the team is cleared to move forward on the product roadmap and continue delighting your end-users.
For a deep dive into our Quality Assurance approach, check out this interview or listen to the podcast.