William Gens sits down with Noel Wurst to describe "the art and science of traceability" ahead of his STAREAST session of the same name. Learn what makes traceability meaningful and such a valuable asset to projects, no matter how bad the requirements may seem to be.
Noel: You've said that "traceability for requirements is a combination of art and science, with a pinch of courage." The science is obvious to me, and there are many aspects of agile that people describe as art forms, but what's the story behind needing "courage?"
William: By courage I mean whenever you have to be creative you also have to be a little courageous, especially where traceability is so important. You don't always have great requirements or a clear path or link to traceability so rather than complain about it or keep pressing for it find ways to circumvent that with some creative solutions. don't be afraid to do something differently as long as you keep your goal in site of providing testers and development and business with a scientific and logical link to all the artifacts in the process, whatever they might be.
Noel: How does well executed traceability benefit project management specifically?
William: It saves time and resources. If you have artifacts as part of your SDLC no matter how good and complete those artifacts are, it provides project stakeholders with a link to all the pieces. This benefits the tester who can almost review the requirements, it benefits the developer who knows what requirements are failing which tests, and it provides the PM with exact direction as to where the resources and time need to be allocated. For example, if you have a loosely defined requirement, most of which was discussed between the developer and the business with QA eavesdropping, then the tests that are derived from that are really the acceptance tests to determine the viability and success of that specific requirement. This is hugely beneficial to scheduling and allocating resources because you have a specific footprint to follow and know exactly what needs to be done to meet the goals of the requirement.
Noel: You present a session that strives to help people create "meaningful traceability." What separates meaningful and meaningless traceability, and can meaningless traceably actually go further and end up being harmful or damaging?
William: Let me address meaningless first. If meaningless wastes time then yes, it is harmful. This is especially critical in the agile methodology because time wasted is a cardinal sin. Make every moment count so to speak. Traceability becomes meaningful when its goal is to provide a link to all the artifacts and thus enables all stakeholders to tap into the resources available. If I am working on Xtreme Agile and there's a lot of verbal communication going on, it's very beneficial to me and others to put those conversations in an email and assign some control number and categorize it and link it to a test case(s)....that is your requirement. It also becomes your acceptance, and if there is some discrepancy or issue, you have some traceability to all the discussion.
Your QA artifact no matter how sophisticated is key, if done with purpose and intention will enable the flow of information be available to all and not just the participants of the discussion. It is a mode of operating, when you make it your point to value information about a requirement and provide a link to all that information that is readily accessible to all the stakeholders. From a QA perspective, traceability provides you with better coverage of your product or service testing. And if you prioritize your requirements you can build tests and suits of test based on business priority. Time is so critical in Agile, if you waste time it can mean you curtail even critical testing and provide to the stakeholders poorly planned coverage.