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.

Noel: Does traceability, or the need for traceability, differ between smaller and larger scale projects, or are you a big enough proponent of it to argue it's equally important for any project where QA is highly valued?

William: It's important at all levels, but probably the more stakeholders the more critical because the flow of information comes from many different sources and stakeholders.

Noel: Would you say that traceability has a larger role on an agile project than on a waterfall project or is the need the same?

William: The need is the same, but I think you need to be more artful in agile because of the time constraints. In waterfall, you can build traceability pretty easily because of the requisite document on requirements. The hybrid types also present challenges because your delivery could be agile but your method could be waterfall. So the requirements aren't always that good and they are frequently updated along the way, the review and walk through process is similar to waterfall, but the biggest challenge is QA isn't as close to the other stakeholders and must rely heavily on the documentation. That is fine, but QA in the "hybrid" world still needs to be more agile than not. And traceability helps in making sure you are linking together all the artifacts of the requirement and not so much worrying about updating documents or expecting document sign offs, etc.

William Gens is a senior test engineer at Dealogic in New York City. He has been involved with software quality for more than thirty years at Credit Suisse/First Boston, Merrill Lynch/Bank of America, Dell Computer, and numerous joint ventures with IBM in the financial services Industry. With a passion for software quality and the integrity of the quality assurance process, William prides himself on being one of the original quality frontiersmen in financial services software development and testing.