0

The shop I work for has recently switched to Agile/Scrum software development. We've started logging User Stories, and defining their scope with Acceptance Criteria. So, we have

  • Features defined by
    • One or more User Stories
  • User Stories defined by
    • One or more Acceptance Criteria
  • Acceptance Criteria validated by
    • One or more Test Cases
    • One or more Unit Tests

We're now starting to look into Test Case Management software for the QA guys. The idea being that it will help manage their growing number of Test Cases. We've been told that with proper TCM software we can associate Test Cases with Requirements (Acceptance Criteria) such that the Test Cases are flagged whenever their associated Requirement changes. The idea being that a QA member would then update the Test Cases as needed.

Now, as a developer, I would like something very similar for my unit tests. Ideally, whenever a Requirement changes, I would like my associated Unit Test to fail. This will let me know that all my unit tests are always up to date.

Does such a system exist? Is there a magical system that will let you manage your Requirements, Test Cases, and allow you to break your unit tests when Requirements change?

Additionally, I would like my build to fail whenever a Feature has been extended (i.e., has had new Requirements added).

Improve this question
4
  • I don't know of anything magical. Wouldn't it depend on how (or how well) you write your unit tests? If your unit tests are detailed enough, any requirement change would "break" them, right?
    – Joe Strazzere
    May 3, 2013 at 16:30
  • Hi Joe, thanks for the reply. What you're saying is true, but only if the application code has already been written to match the new requirements. I'm looking for something that will break my unit tests (or flag them for update) as soon as their associated Requirement has changed.
    – MetaFight
    May 4, 2013 at 12:11
  • Should I maybe transfer this to programmers.se ?
    – MetaFight
    May 4, 2013 at 12:11
  • Haven't heard of this before. Why fail tests that could be fine? Just because requirements change wouldn't mean that a unit test for a class would need to change. I would think code coverage would work better. If you fail builds when unit tests aren't added wouldn't that accomplish something similar?
    – Steve Miskiewicz
    May 5, 2013 at 2:17

2 Answers 2

Reset to default
1

It depends on the test framework you are using. The frameworks I know allow you to define your own assertions. With that, you could define a time based assertion like assertSpecifiedBefore(<specification>, <date>), which checks the last modification date of the specification is not newer than the date of test creation (<date>).

Improve this answer
1
  • Sounds like what I'm looking for. Thanks :) Now all I need is a system that I can query when the tests are run which will give me the specification's modification date. I'm pretty sure I can rig something up.
    – MetaFight
    May 6, 2013 at 12:00
1

Take a look at Microsoft Test Manager. Although not dependent on .net, it is fully integrated with Team Foundation System - so if you're not using TFS for work item management / scrum process - it will not work for you.

It does allow you to define standard and custom relationship and you can create your own transitions to invalidate tests if that is what you wish.

Improve this answer
2
  • Do you mean invalidate coded tests (ie, unit tests) or tests withing MTM?
    – MetaFight
    May 4, 2013 at 12:32
  • You would set the test work items in TFS as "invalid" or "not up to date" or smth.
    – Bogdan Gavril MSFT
    May 5, 2013 at 11:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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