I’m sure you are familiar with the term Technical debt. We’re all familiar with the ever going debates when designing and programming software – should we do it the ‘right (and long, expensive) way’ or maybe we should take the easier, faster road, which will get us quickly to a working new feature/product but also to a code that will need fixing or change in the future (therefore the ‘debt’).
It’s the same when we look at Software testing.
Our testing projects present similar challenges as developers face:
- No Holistic, methodology-backed, approach to testing
- Not enough time to test
- No documentation
- Management not invested in testing, unaware of importance
- Not enough resources (mainly human – testers)
- Lack of expertise
- Testing group not involved in the design and requirements phase, therefore missing the big picture
- Testing pushed back and testing time is always the first to be shortened when business pressure starts
Therefore, they are also faced with what can be referred to as Software testing debt.
Test Debt Types
When planning our testing project, we’re always juggling between what needs to be tested vs. the time we have to test, between the way we really want to test vs. the means and resources we have and between the different stakeholders (devs, business, marketing, design, management, etc.), each with their goals and schedules.
In this process, we know that whatever we don’t do now, do only partially, or do via the shortcut rather than the right-path, all these will haunt us in the future. There’s no right or wrong, it is all a matter of priorities and compromises. The important thing is awareness – making decisions while knowing the facts, not ignoring them, considering future consequences and aligning with the organization’s priorities and business decisions.
Here are a few possible areas to consider as possible future Software testing debt:
- Full coverage of tests
- Integrating unit testing as an integral and obligatory part of the development
- Implementation of functional testing as an integral and binding part of the release of the version
- Implementation of automated testing as an integral part of the CI-CD process
- Complete working methodology of development-testing-release
- Measuring the work process of development-testing-bug fixing
Managing software Testing Debt
The first thing to understand is that the optimal point of the organization is not zero testing debt. This is crucial to remember when managing your testing debt (same goes for the concept of Technical debt). It’s OK, and even recommended, to knowingly take measured risks, in order to gain advantage elsewhere (for example time saving).
When allocating time for dealing with your Software debt, try to find those elements that will have a positive impact on your project/product. Avoid those that won’t make a real difference for the software’s behavior or quality, even if it’s something that bothers you – as a tester.
Also remember that you don’t have to fix or sort out such a debt completely. Fixing it partially, so that the problem is less critical now, may be enough in many cases. Realizing this, can help you deal with a few issues, rather than allocating all the time to one of them only.
Working to minimize the created debt can be done in different ways:
- Dedicated team, working to solve and fix debt issues
- Allowing time for debt fixing at the end of each cycle/feature/project, done by the same team of testers
- Opportunity based fixing: whenever there’s time, whenever there’s a tester with free time, whenever there’s a chance to fix something due to a new cycle/project, etc.
Each of these approaches has its advantages and disadvantages, choose whichever is best for your specific needs and environment.
There’s one other thing that can help, and that is transparency. Yep, being transparent with other groups in the project, sharing your list of testing debt issues can be helpful in the future, since the codes, the products, are constantly changing. So are processes, priorities and even resources. Some of the issues, if known to everyone, may be dealt together with these ongoing changes, as part of the workflow, rather than as special treatment.
And lastly, differentiate between your manual and your automated testing with regards to software testing debts management. The factors are different and so should be their management.