Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

In traceability matrix the links between requirements and tests can help answer:

  • Which requirements is almost never tested, and which is tested extremely often?
  • Will a change to a particular requirement cause revisions to a huge number of tests in the system?

In agile there are no requirements but stories, so traceability matrix does not exist in traditional sense. Well, stories describe requirements but when you complete story, you close it and then you close an iteration and forget about that story. It is done, accepted, and closed. So maybe this is a reason, why in software we used for planning and tracking of iteration and tests there is no such matrix.

Or maybe my guess is wrong. I'm curious whether you use kind of traceability matrix (linking stories/epics with tests)?

One place I would see it useful, is when you get additional budget/iteration to verify your epic better and you want to decide which stories require additional testing...

share|improve this question
1  
Have you read sqa.stackexchange.com/questions/3869/… ? –  user246 Nov 2 '12 at 17:12
    
@user246, I will, thank you. –  dzieciou Nov 2 '12 at 17:16
add comment

3 Answers 3

up vote 6 down vote accepted

Tracebility matrix is a tool. It doesn't have any inheritent value, but it might be easiest way of mapping certain kind of relations between tests and requirements. As with any other tool, if it seems to work well, use it. If something else fits better, use that. If the tool nearly fits your need, modify it to give what information you need.

If testing is done long after implementation, some kind of tracking is probably needed to make sure that everything relevant is covered and things are what they are supposed to be. However, if they are tested when they are implemented, it's much easier to make sure that they match the intended. Automating tests that try to make sure that features work also long after should replace the need for tracking the requirement/test linkage manually as they are tested all the time. And in the best case even a large number of broken tests is fixed quite easily by changing things in one place, if DRY principle (don't repeat yourself) is followed.

share|improve this answer
add comment

In an agile environment you can (should) replace these traditional tools by their agile equivalent.

Instead of having a matrix in some documented format (eg.: Excel sheet with the requirement and there place of implementation) you can use your tests.

For each requirements you are going to have some tests implemented (assuming TDD). These tests then can be mapped straight to the code (what code part do they cover?). This then can be used as an agile bidirectional traceability tool.

This could work very well, though I have never seen this thing in practice. It is quite uncommon to have even the traditional matrix.

share|improve this answer
add comment

I have never seen such a matrix and never heard of it before :-(.

Your goal:

Which requirements is almost never tested, and which is tested extremely often?

can be achived by agile/technical means:

  • Using Behavior driven development bdd as automated test for a userstory to verify that it is complete and still working.
  • There are code coverage tools that show which production code is (not) touched by the tests.

However, I don't know how to answer your second question.

Will a change to a particular requirement cause revisions to a huge number of tests in the system?

share|improve this answer
    
Thanks. How BDD is going to tell me which requirements are never tested? –  dzieciou Nov 2 '12 at 17:04
    
The codecovarage tells you which code-fragments were not called in the tests. If you identify to which userstory the untested code belongs to you know which userstories are untested. –  k3b Nov 2 '12 at 17:11
    
Code coverage and story coverage are not the same thing. Linking the code and story might not be so straightforward I would prefer black-box approach :-) –  dzieciou Nov 2 '12 at 17:16
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.