Understanding Technical Debt from a QA Perspective

Technical debt, also known as tech debt or code debt, is a term used to describe the accumulation of shortcuts and quick fixes that are taken to meet deadlines or to get a product to market quickly. The concept of technical debt has become an important part of the software development lexicon and is widely recognized as a key factor that can impact the long-term success of a software product.

Technical debt is mainly used by developers and project managers, but in this article we will take a look at technical debt, measurements, and repayments from a quality assurance perspective.

When and why does technical debt occur?

Often when developing software, development teams need to make some tough decisions—should they focus on writing perfect code early on or should they focus on fast delivery and fix issues later on when there will be more time and resources. While many teams opt for the “build now, fix later” option, this approach can actually be a more difficult path to follow in the long run.

Solutions that prioritize delivery speed over code quality often backfire on development teams. Namely, easy and quick solutions to release MVP* features tend to accumulate in the long run, resulting in technical debt. And when the time comes to “repay” your debts, aka address the previously postponed issues, an avalanche of delayed “payments” can lead to unpredictable consequences.

* A minimum viable product (MVP) is a product that has the minimum set of features necessary to be useful to early adopters and gather feedback for further development.

Additionally, the Cost of Change (CoC) increases with growing technical debt, which leads to low productivity on the team. Technical debt, in the company of other artifacts, makes adding new features difficult because botched or quick solutions are often used instead of a general solution.

Developers may take shortcuts or make quick fixes in different parts of the codebase rather than addressing the root cause of the issue. This can result in multiple fixes being implemented in different places and in different ways, which can make it more difficult to maintain and update the codebase in the future, also leading to the introduction of unexpected bugs.

Technical debt could be accumulated due to the poor quality of the specification, its absence and poor problem statements. In agile teams the product manager decides to release MVP features more often to get user feedback faster, which also leads to adding more and more technical debt items to the backlog.

In numerous teams, the role of business analyst is performed by the QA specialist, while the QA team is in charge of signing off a product and assigning tasks and supporting the development team.

Releasing MVP features with technical debt can be a tough decision made by the Product Manager, QA Lead and Dev Lead. As a result, technical debt normally appears unintentionally.

However, technical debt can also be added intentionally, in cases when a custom solution is used instead of a general solution in order to avoid over-engineering.

Some examples of over-engineering:

• Implementing parser for all possible input formats vs. Implementing parser only for formats supported by current clients.
• Designing a scalable and high-available solution vs. Designing a simple solution suitable for the current product market of 10 users.
• Trying to predict all incoming data types and build a generic storage solution vs. Launching an application, analyzing data and then trying to come up with a solution which fits our data.

Why should we measure technical debt?

Metaphorical concepts can be challenging to measure, there are no universal metrics that can tell the full story. A lot is tied to the choice of how to do something—quickly or correctly. While it is easier to measure how “quick” a concept is, measuring the “correctness” of it is very challenging and brings on a wide range of opinions and debates on the best approach to take in order to measure technical debt.

Specially added technical debt should be documented to not be forgotten. For example, create a special label or ticket type in the issue tracker. On planning, it will be possible to add such deferred tasks to the sprint.

Technical debt that is created unintentionally is more difficult to measure. So, how do we know if we have technical debt and how can we measure it?

Developers can use a variety of diagnostic techniques:

• cyclomatic complexity
• component coupling
• test coverage
• //TODO comments in the code

Though none of these diagnostic techniques give an accurate understanding of the problem, their combination can push the team's thoughts in the right direction.

Some people think that the test coverage metric itself is harmful, but we must remember that it is a very bad idea to start refactoring or paying off technical debt in code that is not covered by tests. Perhaps the lack of tests is already a technical debt?

Here we come to the role of the QA team and the importance of the kickoff meeting to discuss features. The QA team can use leading questions to help identify a future problem:

• Why is the feature being added the way it is?
• Why such a big estimate?
• Why such large uncertainties in estimates?

Use your soft skills. Product development is a team task and technical debt is a team problem. But don't worry, technical debt is a typical part of each and every software system, even in good teams and organizations.

But why should QA teams be worried about technical debt at all?

Technical debt can negatively impact the quality and reliability of a system. If a system has a high level of technical debt, it may be more prone to errors and defects, which can negatively impact the user experience and the overall performance of the system.

It is important to ensure that the products you are testing are of high quality and free of defects, and addressing technical debt can help you achieve this goal.

How can QA teams help minimize technical debt?

To effectively address and manage tech debt, it is crucial for quality assurance teams to be involved in the analysis, planning, and execution of tech debt tasks:

• Identify and prioritize technical debt
  QA teams can provide valuable insights and support in identifying areas of the product that may be in need of refactoring or repair, as well as in developing and implementing strategies for addressing these issues.
• Participate in code reviews
  The testing team can play an important role in advocating for the allocation of resources towards tech debt tasks, ensuring that these tasks are given the necessary attention and priority.
• Test early and often
  Early and frequent testing from QA teams can help to catch issues and bugs early on, which can reduce the need for quick fixes and minimize the accumulation of technical debt.
• Work closely with developers
  With close collaboration with developers, QA teams can help to ensure that technical debt is effectively managed and that the necessary resources are dedicated towards addressing and resolving it.
• Regularly review and update testing processes
  Continuously refining and optimizing testing approaches can help to minimize the risk of introducing new technical debt during the development process.

There are various ways QA teams can provide feedback on technical debt, including both formal and informal approaches.

In a more formal approach, QA teams regularly report specific metrics that provide insight into the team's performance and progress. These metrics may include the percentage of tech debt tickets in the backlog relative to the total number of tickets, any relevant performance metrics, and the estimated time required to fix identified issues.

QA teams may also use less formal approaches to provide feedback on technical debt, depending on the specific processes, team size, and development culture. For example, instead of formal reports: comments in the bug tracker, maybe even individual issues, emails, meeting notes, and even slack threads (you can hyperlink to them). The main idea is to have written evidence, be able to track it, not lose it and refer to it in the future.

Conclusion

Do not turn a blind eye to the growing number of tech debt tickets in the backlog. This is a problem not only for developers, but for the entire team and the product being developed. You need to learn how to work with those debts. It is important to monitor technical debt, show the importance to stakeholders, and work together to reduce it.

The ideal is unattainable. The best thing that all team members can do is learn from their mistakes, implement best testing practices, and be fully aware of the trade-offs that are made in product development.

Are you confident in your QA team’s ability to help development teams better manage and reduce technical debt? Our experienced QA engineers can provide you with additional support to make sure you follow the best practices when it comes to testing, analyzing, and reporting to ensure technical debt does not affect the overall quality of your product. Contact us with your project details to learn more about how we can help you and your team.