I had one of those moments the other day — the kind of moment where you remember something that happened in the past and your blood runs cold. It’s a lot like when you wake up from that one nightmare where you’re taking a final for a class you never went to, and the test is in a language you don’t read or write, and you’re sitting in the classroom only wearing underwear and bunny slippers.
This was sparked by the memory of the day when a legacy feature in production for an application I worked on had a critical defect caused by new code and no one knew much of anything about it. This was early in my career and I was still having a lot of those “first” experiences working in software that you carry with you throughout your whole career. In the case of this first experience, it was the first critical production defect and the first time I was blamed for not testing or understanding a feature that I didn’t even know existed.
One of the first questions asked was “How did QA miss this?” At the time, I felt compelled to apologize profusely and offer to do anything needed to handle the defect. Today, I would react differently.
The company I was working for at the time did not place any value in systems and tools like Jira, test management software, or traceability. Investing in these things wouldn’t have eliminated the chance of a defect like the one we encountered making it to production. However, there would have been a much smaller risk — and better chance that it could have been mitigated.
What is traceability?
There are multiple kinds of traceability. Traceability in general is a method of identifying and making visible connections between multiple things. In this case, we’re making connections between requirements and tests or test cases. We call this bidirectional traceability since it’s the connection between two things. We can also have tridirectional traceability, the best example of which is the connection between requirements, tests or test cases, and identified risks in risk-based testing.
A common narrative is that traceability is waterfall or part of the “old world” of testing and that it requires too much process and effort for agile. However, there are many ways that traceability can enhance your testing. There are methods to make maintaining traceability a very low lift for you and your team. In most cases, using a requirements management tool and a test case management application that integrate well will enable your team to create and maintain traceability with very little effort.
Why traceability matters
At this point, you might see how traceability would have helped me head off disaster during my first production crisis — or at least recover faster. If traceability had been in place, I would have been more aware of tests tied to a part of the application that I didn’t know existed. It also would have enabled me to quickly find the requirements for the feature, giving the team what they needed to find a quick fix.
In fact, better visibility into the requirements for the feature may have prevented the situation entirely. Enhanced visibility and traceability would have allowed us to plan and test for the potential integration issues with the legacy feature.
Better traceability and proactive quality management go hand in hand
You can’t test features if you don’t know they exist. And you can’t quickly address issues if you have to hunt down requirements. If you want to be proactive and prevent stressful nightmares — traceability is key.
Related read: Qase Q1 product update, including Jira Requirements Traceability Matrix
