692954 - a user should be able to view history on a test case with context on test runs

Status: RESOLVED FIXED

(Mozilla QA Graveyard :: MozTrap, enhancement)

Description

[Cameron Dawson [:camd]]

Test case version numbers aren't as meaningful without context as to where those versions were used.  When a version of a test case is shown, it should show the test cycles and runs that that version belonged to.

Additionally, when thinking of test case versions, it is synonymous with "history" of that case.  So we could present a UI that depicts the history to the user chronologically.

Ideally, supporting fields like "created on", "last updated" (perhaps also "created by" and "updated by") as well as the test cycle / test run combos for that version.

Comment 1

[Cameron Dawson [:camd]]

A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/19422601

Comment 2

[Cameron Dawson [:camd]]

Eric Meyer changed story state to started in Pivotal Tracker

Comment 3

[Cameron Dawson [:camd]]

Eric Meyer added a comment in Pivotal Tracker:   
   
Jonny, when you select a version, the list should disappear and the content below should update.

Comment 4

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
jonny: note that the "more runs" link is commented in _case_form_version_list_item.html and should be moved to a JS template, inserted if there is more than one run to expand and view more than just the first

Comment 5

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
(this testruns expansion is also needed JS here, not mentioned in erics comment)

Comment 6

[Cameron Dawson [:camd]]

Eric Meyer added a comment in Pivotal Tracker:   
   
Should this only exist if there is more than one version available?

Comment 7

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
that's a good question.  But I think I lean toward showing this ui whether there is only 1 version or several.  Good for consistency and the user never has to ask, "why can't I drop this one down?"  They'll immediately see there's only 1 in the list and question answered.

Another might be something like show number of versions, and if there's only 1, don't have the drop-down.

But, you know, I think my preference is to have this drop down in all cases.

Comment 8

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
Jonny: your update for prefixing filter inputs broke tagging test cases, as "newtag" is now "filter--newtag". Seems like some code is being shared between filters and tags on your end where it doesn't actually make sense to share it. Made a task here to fix it.

Comment 9

[Cameron Dawson [:camd]]

Jonny Gerig Meyer added a comment in Pivotal Tracker:   
   
Carl: I fixed the tag input names. While making those changes, I decided it would make sense to use name="filter-..." for the inputs in the main filtering widget also. I pushed those changes to a new branch (master-filter-prefix); you just need to update your python to expect inputs with "filter-" prefixed names for filtering.

Comment 10

[Cameron Dawson [:camd]]

Jonny Gerig Meyer changed story state to finished in Pivotal Tracker

Comment 11

[Cameron Dawson [:camd]]

Carl Meyer changed story state to delivered in Pivotal Tracker

Comment 12

[Cameron Dawson [:camd]]

Cameron Dawson changed story state to accepted in Pivotal Tracker