Tech startups focus on innovation – solving a problem in a new way using technology. It involves continuous hypothesis testing, rapid testing of new ideas, and a fertile mind.

But when the product takes shape, we often find that novelty has taken a backseat while quality has taken a back seat. And that’s usually fine, since the goal of the early stages is to get the first MVP in place. After that, it’s more about quick reaction than perfection in execution.

However, we realize that the quality issues that have been ignored for a while are reappearing as we begin to stabilize our MVP and get into the expansion that has been made.

The question is, can we find a balance between constant innovation and quality?

W. Edwards Deming says: “You can’t check the quality of a product.” Checking is too late. Instead, quality must be built right into the product.

In this article, we will discuss some tips to help us achieve this without compromising on our continuous innovation journey.

Set your quality goals explicitly for each phase of the product lifecycle

The quality goals in a startup must be clear. You move from the life cycle phase to the product life cycle phase. For example, the quality goal for the POC phase can only be the verification of the hypothesis, and the quality goal of the MVP can be the usability by the core target group.

The mistake often is not articulating your quality goals explicitly and assuming that stakeholders will understand them. Unfortunately, this often leads to different definitions of quality and uncoordinated actions, resulting in wasted work and frustration. Instead, it is crucial to understand and explain to stakeholders that quality is context sensitive. This enables a judicious use of resources, time, effort and costs.

Read our blog: How to Hire a QA Engineer: The Ultimate Guide

Define quality as a guiding principle and not as an inspection glass

Define quality goals to develop a quality strategy that helps guide development efforts. For example, if you’re developing a login page, it’s important to clearly and unambiguously define its characteristics before you even create it. If you want the application to work for specific test data, it pays to define the test data before writing the code.

This does two things:

1. Allows the developers to use the defined test case and test data to test the code by themselves. When the bugs are found, they are fixed without iterations, saving huge rework costs.

2. This forces the business analyst or product owner to clearly define corner cases right from the start. This gives developers more specific instructions and makes it relatively easy to develop the right code. This further reduces rework costs and also reduces development costs.

It also means that the QA resource/team has to work very closely with the development teams and not act as a gatekeeper but as an employee.

This approach is related to the concepts of Test first and Test Driver Development (TDD). The TDD is typically used when this approach is mixed with test automation, which we discuss in the next section.

This can be a paradigm shift for many companies and takes some getting used to at first. But with a little discipline and practice, this skill isn’t too difficult to acquire.

Automate regression testing

A tech startup is about building the product step by step, i.e. following an agile methodology. This proven approach results in better deliveries and faster turnaround times.

However, this poses a quality management problem. The problem is that while the development effort is aimed at working only on the affected modules, the testing has to be repeated for many modules. This is because the modules are linked and it is usually difficult to determine with certainty that changes are not affecting another module.

These problems can occur due to new changes or configuration errors. Therefore, these related modules need to be re-tested to ensure a sustainable level of quality.

This increases the testing effort even with relatively small changes and development sprints. I’m sure you will agree from your experience that the testing phase is the phase with the greatest time pressure.

The only way out is to automate your most frequently run test cases (or regression test suite). The earlier you start, the greater your benefit in the form of saved costs, faster throughput times and a higher level of quality.

Test automation can also be used for the software/features under development and in this case we can call it Test Driven Development (TDD) as described in the previous section.

Use quality management as your approach to collaboration

We are all aware that it takes collaboration to create quality.

What if I say you can use quality management to drive collaboration?

Yes, that is possible.

The approach is called Behavior Driven Development (BDD). Adopting this quality management approach takes your collaboration with business stakeholders, including the product owner, to the next level. It also integrates the test-driven development approach right down to the business owners.

At a very high level, BDD encourages you to define your test cases in language that business owners can understand. Then the tools implementing the BDD approach make it efficient to trace those requirements down to granular test cases and steps to maintain traceability.

When properly applied, this through and through the synergy of the quality approach can help deliver higher quality at a lower cost. The focus of this approach is to involve business stakeholders throughout the development process (even before it begins), thus helping to improve the quality of the product rather than leaving it to inspection at the end.

Read our blog: 9 Reasons to Hire a Software Test Engineer

Make quality an agenda in all your reviews

After all, it is the responsibility of top management to build a culture of quality. If leadership lets the poor quality pass, the rest of the organization is likely to follow suit. As the leader of a tech startup, it’s critical that you put quality on the agenda in all your review meetings.

Quality must be seen as a constraint alongside schedule and cost, and achieving quality goals should be seen as just as important, if not more so, than schedule and budget.

Furthermore, the review should not only look at the number of bugs as a metric, but also at what stage the bug was injected, what caused it, and what is being done to fix the bug and prevent it in the future. Management’s commitment to quality is perhaps the most important ingredient in this entire recipe.

Conclusion

Managing the quality of a product in an ever-changing environment and a continuous development approach can be challenging. However, following best practices, integrating quality throughout the development cycle, and engaging the right stakeholders will help meet higher quality standards.