Re^3: (OT) Tracking Issues, Requirements, Tests

Are there industry standard definitions of "requirements tracking" and "test tracking"? Is there lists of features for each tracking type that must be available before you can call it such?

Extending request tracker is very, very easy, though I admit thats easy for me to say because I've been paid to do so in the past. It doesn't ONLY do request tracking, it does just plain tracking, of anything you feel like tracking with it.

Comment on Re^3: (OT) Tracking Issues, Requirements, Tests

Replies are listed 'Best First'.
Re^4: (OT) Tracking Issues, Requirements, Tests by Corion (Patriarch) on Apr 09, 2025 at 12:43 UTC
Feature/bug tracking is "simple", as that is a single item and that item is either "done" or not. If it was in status "done", but failed acceptance criteria, the issue gets reopened. Test tracking is different, because a test can fail and then you need to redo at least that test, or maybe the whole sequence of tests (if they rely on each other). So as I know it, you have a defined test suite, and a test suite then needs a successful test execution, which consists of several test results. This setup can be implemented in any tracking tool, and I think this is also the reason that all tracking tools are horrible since they all are workflow tools with their own horrible configuration language for that workflow. And usually they are configured by people who don't know the workflow or have no choice but to implement a random workflow using the tool at hand.	[reply]

Replies are listed 'Best First'.

Re^4: (OT) Tracking Issues, Requirements, Tests
by Corion (Patriarch) on Apr 09, 2025 at 12:43 UTC

Feature/bug tracking is "simple", as that is a single item and that item is either "done" or not. If it was in status "done", but failed acceptance criteria, the issue gets reopened.

Test tracking is different, because a test can fail and then you need to redo at least that test, or maybe the whole sequence of tests (if they rely on each other). So as I know it, you have a defined test suite, and a test suite then needs a successful test execution, which consists of several test results.

This setup can be implemented in any tracking tool, and I think this is also the reason that all tracking tools are horrible since they all are workflow tools with their own horrible configuration language for that workflow. And usually they are configured by people who don't know the workflow or have no choice but to implement a random workflow using the tool at hand.

[reply]