Managing software quality in an agile world

Tech startups are focused on innovation - solving a problem in a new way using technology. It involves continuous hypothesis testing, trying out new ideas rapidly, and a fertile mind.

But as the product starts to take shape, we often realize that novelty took a front seat while quality took the backseat. And this is usually fine, as the objective of the early stages is to get the first MVP in place. After that, it is all about quick response rather than perfection in execution.

However, we do realize that as we start to stabilize our MVP and get into the expansion made, the quality issues that were ignored for a while start to resurface.

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

W. Edwards Deming says, “You cannot inspect the quality of a product.” The inspection is too late. Instead, you have to build quality right into the product.

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

Set your quality goals for each product lifecycle stage explicitly

The quality goals in a startup need to be straightforward. They will change from the lifecycle stage to the product's lifecycle stage. For example, the quality goal for the POC stage can be only verification of the hypothesis, and the quality goal of the MVP can be usability by the core target audience.

The mistake often is not articulating your quality goals explicitly and assuming that stakeholders will understand. Unfortunately, that often leads to varying definitions of quality and unaligned actions resulting in wasted efforts and frustration. Instead, it is crucial to understand and explain to stakeholders that quality is context-sensitive. That allows for judicious use of resources, time, effort, and cost.

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

Define quality as a guiding light rather than an inspection lens

Define quality goals to devise a quality strategy that helps direct the development efforts. For example, if you are developing a login page, it is essential to define its characteristics clearly and unambiguously before even building it. Likewise, if you want the application to work for specific test data, it pays to define the test data even before you write the code.

This does two things:

1. Allows the developers to use the defined test case and test data to self-test the code. If the defects are found, they get fixed without iterations and save on enormous rework costs.

2. Doing so forces the business analyst or the product owner to define corner cases unambiguously right in the beginning. As a result, the developers get more precise instructions and can develop the correct code relatively easily. This further reduces the rework cost and also reduces the cost of development.

This also means that the QA resource/ team needs to work very closely with development teams and does not act as a gatekeeper but as a collaborator.

This approach is related to the concepts of Test First and Test Driver Development (TDD). The TDD is usually 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 a step slightly challenging to get used to at first. But with a bit of discipline and practice, it is not too difficult a skill to acquire.

Automate the regression tests

In a tech startup, the idea is to build the product in increments, i.e., to follow an agile methodology. This time-tested approach results in better deliveries and quicker turnaround times.

However, this poses a problem in quality management. The problem is that while development efforts are targeted at working on only the affected modules, the testing has to be repeated for many modules. This is because the modules are interrelated, and it is usually difficult to ascertain without a doubt that changes will not affect any other module.

These issues may arise because of new changes or configuration errors. Therefore, these related modules must be tested again to ensure sustained quality levels.

This means the testing effort is increasing even for relatively minor changes and development sprints. I am sure you will agree from your experience that the testing phase is the most time constraint phase.

The only way out of this is to automate your most frequently run test cases (or the regression test suite). The earlier you start doing that, the higher the benefits you reap from it in terms of saved costs, faster turnaround times, and higher quality achieved.

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 discussed in the previous section.

Using quality management as your collaboration approach

All of us are aware that it requires collaboration to generate quality.

What if I say that 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 the business stakeholders, including the product owner, to the next level. It also integrates back the Test Driven Development approach all the way to the business owners.

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

If followed correctly, this through and through the interaction of the quality approach can help deliver higher quality with reduced costs. The emphasis of this approach is to involve the business stakeholders throughout the development process (even before it gets started) and hence helps build the quality of the product rather than leaving it to be inspected in the end.

Make quality an agenda in all your reviews

Finally, it is the responsibility of the top management to build a culture of quality. If the leadership allows the bad quality to pass, the rest of the organization will likely follow suit. As the leader of a tech startup, it is crucial that you make quality an agenda in all your review meetings.

Quality needs to be seen as a constraint alongside timelines and cost, and meeting quality objectives should be considered as important, if not more, as schedule and budget.

Further, the review should not just look at the number of defects as a metric but also at which stage the defect got injected, what caused it, and what is being done to correct the defect and prevent it in the future. The management's commitment to quality is potentially the most important ingredient of this entire recipe.

Conclusion

Managing the quality of a product in a constantly changing environment and continuous development approach can be challenging. However, following the best practices, integrating the quality into the entire development cycle, and involving the right stakeholders help meet superior quality standards.