Add more options to "Make Test Runs Current"; removing all data is painful

George Butler
edited October 2016 in
I wont be able to attend the virtual meeting will it be recorded?

A scenario we keep coming up against is after testing we find a result falls short of the requirement (thus the expected result in a test case step).

For various reasons (spec relief, typos etc) we're allowed to update the initial requirement. This causes as suspect link to the test case, which is great, the test case is updated.

The issue we have is in "Make Test Runs Current". Doing this erases all data from the previous test run. In this scenario the same results will need to be added again, which is painful for complex test run with complex test cases.

Ideally Jama would have an option for retaining the data from a previous test run version.
Thoughts on the following:
  • Name - Overwrite if modified as the name field isn't the unique id of the test case. 
  • Description - Overwrite if modified
  • Customer fields  - Overwrite if modified
  • Test steps - See below
  • Actual Results - Retained
For test steps Jama could:
  • Retain the results of previous steps
  • New step would be blank.
  • Deleted step would obviously have the data dropped.
This should be possible as each test step has a unique id in the database & the step index is a field.

I'm sure I may have simplified the solution but something along these lines would be very helpful.
 

Note: This conversation was created from a reply on: Have questions about the test center? Block your calendar for the inaugural "Ask ....

Comments

  • Knowledge Base
    edited August 2015
    Absolutely agree with this.  There's a lot of value in the Make Test Runs Current feature, and at times it's totally fine to make a run current by deleting the existing one and starting over.  But run deletion as the only option in an existing cycle is far from ideal.  Creating a new cycle to get the latest case revision isn't always the right option either.

    Jama does such a great job versioning most other things in the database.  Adding those capabilities to Test Runs would be fantastic.
  • Jason Kettler
    edited January 2016
    Adding my vote here as well.  I typically handle this by creating a new cycle but as mark points out that is not always ideal
  • Knowledge Base
    edited October 2015
    An extension of this request - we would like to be able to configure which fields result in a test run becoming out of date. There are some fields in our system that don't impact the runtime conditions of a test, but they still result in the out of date indicator when the values change. That in turn forces testers to pay attention to changes that they really don't need to worry about.
  • George Butler
    edited October 2015
    This sounds like it could be an extension of the options that cause specific fields to trigger a suspect link. But this would only apply to items with a category of "Test Case".
  • Knowledge Base
    edited August 2015
    That would be the perfect location for that configurable, I think.  And along that line, it would even be nice if the out of date condition was something that could be cleared just like a suspect link.  For valid content changes, testers need to make a choice whether or not they're going to update the test in an existing cycle or create a new cycle.  If the decision is made not to inherit a change and not to create a new cycle, that indicator should go away....  until the next change condition causes the icon to appear again. 
  • Jennifer Leitch
    edited March 2016
    I would like to add my vote as well. Unless I'm mistaken, there is no way to 'revive' the data that is lost if one Makes Test Runs current (notes etc). Even in viewing the Baseline if one is created, the make baseline current fails and will not recover the data.

    Thanks!
  • Vladimir Cech
    edited October 2016
    Hi Jama,
    Any update on this. It is beneficial for many reasons. E.g. to fix typo, formating, etc. It's not possible to lost test execution data in this case.
    Vlada
  • Christian Binard
    edited October 2019
    Hi,
    I'd like to relive this. To summarize:
    Like it's possible to define what fields trigger downstream items to be suspect, the request is to add properties to define what Text Cases fields trigger Test Run to become obsolete in case of change + provide ways to
    - clear the Test Run obsolete flag (resolve the issue with no data loss since still valid) or
    - replace the test run by a new one (with loss of data, as today by "make current") or
    - add a new test Run in another Test Cycle (request for new data while keeping historical data ).
  • Christian Binard
    edited October 2019
    Hi,
    To support the new cycle creation strategy (that is the preferred way in my case), I would like an option at cycle creation to add Test Runs for all Test Cases that did changed (on impacting fields, see comment 9) since last Test Run creation.
  • Christian Binard
    edited October 2019

    Hi,

    Related problem is that the Test Case Status does not reflect the fact that the Test Runs are outdated.
    I see this as critical issue since a Test Case can be reported as PASSED bases on outdated measurements.
    It's not OK to have to check, for each Test Cases, if in each Test Plans the latest Test Runs has a "pencil" icon.

    So I would like that the test Case status indicates "Outdated" when one consolidated Test Run is outdated.
    Thanks

  • Christian Binard
    edited April 2020

    +3 from Selecting test cases based on their "priority" while adding a new test cycles.

    We would also appreciate to have a split between "Not Run" and "New" since the selection of "Not Run/New" after new Test Case creation duplicates unnecessarily the "Not Run" Test Runs.