Technical debt is essentially the consequences of creating a system. Shortcuts are taken in the course of a sprint, and, if the isn’t time to fix them, then this is the technical debt of that sprint. It can cover anything from hardcoded values, missing tests, missing documentation, lack of experience on the team leading to the system not being developed efficiently.
I’m going to talk about 3 types of technical debt over the following weeks: technical debt in the ‘traditional’ sense, conceptual or UX debt, and finally, testing debt.
Technical debt can be prudent (we’ll have to ship and deal with issues as they rise), or reckless (we don’t need tests); deliberate (compromise based on educated knowledge of how the system will work), or inadvertent (shit happens). While the cause may be able to be evaluated and fixed, the result (the actual debt), is what’s important for the work that’s in front of you right now.
As an aside, its not always something that can be fixed – I got my developer partner to look over this for technical correctness (the best kind of correctness!) and he said that debt can’t always be fixed: Not always, times change, things that seemed good at the time turn out not to be. Building flexibility that turns out not needed complicates the code. Not building for flexibility (for simplicity/speed) which turns out to be needed later.
Developers often have to fix debt, and are best placed to know about said debt, but what, as part of the Test/QA team, can I do about it?
Good communication between developers and testers is always good, and if you as a tester, can learn about any technical debt present in the system, this may help with testing. For example, if the devs know they’ve taken a shortcut, then there may be some bugs that won’t come as too much of a surprise, or future development will be harder to do and this is good information to have.
Depending on the project setup, I as a tester, may be used as client/PO proxy. The inclusion of deliberate technical debt may be based on a decision I make, so that’s something I need to take into account. For example, if a developer asks me what I should expect from a feature, and gives me a couple of options, they might say ‘we can do x, but it will take longer. I can take a shortcut, but we’ll have to deal with it down the line, or we can do y, which is less ideal, but will be doable in the time and with no debt’ then that’s the information needed to make an educated call on where the priority lies.
Testing after refactoring. Refactoring is when a developer ‘tidies up’ the code for want of a better word. When developing iteratively, like in sprints, code is added on top of code. When the project is feature complete, there may be time for the developers to sit down and restructure the code, not making any changes to the functionality (in theory), but making the code better; tidier, more efficient, nicer. If a developer refactors to reduce debt, they may introduce different issues, and it means that the developers aren’t adding new features, or fixing bugs, so you need to weigh up the benefits here. Your automated checks may catch some issues, but visual testing and some exploratory testing may need to take place depending on what code has been altered and how risky it is, and so being aware of refactoring and what’s been done is essential.
Documentation of tests and/or any prudent/deliberate debt taken on. This means that there is a base for future development to work off.
Technical debt is also a nightmare when you’re on tight deadlines – in the Agilefall/ScrumBut clusterfuck where testers get all the stories in one batch 3 days before sprint end and you’re going by the skin of your teeth before sprint end (or testing is done next sprint) adds to debt, as any bugs and fixes are done in an even more compressed timeline, leading to more debt.
There is a post I’ll link that has a quadrant diagram of debt, with inadvertent/deliberate and reckless/prudent as the combinations, and the post discusses prudent and inadvertent debt, which is what happens on good teams. The idea is that; after a product is shipped successfully, the team has learned so much that they’re not happy with the code they shipped, as they now know better ways they could’ve handled it.
And it highlights that, it’s impossible to avoid debt; even the best teams have technical debt come the end of a project. And shit happens – a late client request, unexpected resource loss, etc. So you need to ensure you reduce and mitigate debt, and make sure the risks are as understood as possible before going forward to ensure you’re not enmeshed in debt forever.