Red Hat Bugzilla – Bug 865334
test_case_runs.running_date does not update after pushing 'play' button
Last modified: 2016-06-13 03:44:17 EDT
Description of problem: I assume test_case_runs.running_date is supposed to contain a timestamp for when the last time the test case was put into a "running state"; ie, someone pushes the 'play' button. If this is the case, then it would seem .running_date should get updated when the play button is pushed, but it doesn't.
Discuss related several bugs (865332, 865329), how about following solution: * running_date is for test case run changed into running status. * stop_date is for test case run completed. When status is changed into pass, fail, waved, the time stamp should be recorded into stop_date. * on web UI, both test run start date and completed date will be prompted
(In reply to comment #1) > Discuss related several bugs (865332, 865329), how about following solution: > * running_date is for test case run changed into running status. > * stop_date is for test case run completed. When status is changed into > pass, fail, waved, the time stamp should be recorded into stop_date. > * on web UI, both test run start date and completed date will be prompted What about? case_run_started:: update when state changed to anything like 'running'; case_run_stopped must be cleared case_run_stopped:: update when state changed to anything like 'stopped'; case_run_started must be cleared This way, only *_started or _stopped will have some value and we can then easily determine whether the case is currently running or stopped and when the action happened. It should not be a valid state to have both _started and _stopped with content. (and perhaps this should also be done plan_run_started, plan_run_stopped?)
(In reply to comment #2) > What about? > > case_run_started:: > update when state changed to anything like 'running'; case_run_stopped > must be cleared Agree. > > case_run_stopped:: > update when state changed to anything like 'stopped'; case_run_started > must be cleared Disagree. the started time can help to record the test case running period. > > This way, only *_started or _stopped will have some value and we can then > easily determine whether the case is currently running or stopped and when > the action happened. The status is very clear on if it is running or stopped and the result. > > It should not be a valid state to have both _started and _stopped with > content. Maybe running_started avaliable when "running", and running_stop avaliable when "pass", "failed" or "Waved" status. > > (and perhaps this should also be done plan_run_started, plan_run_stopped?) I believe you mean test run. It can be similiar with test case run.
(In reply to comment #3) > (In reply to comment #2) > > What about? > > > > case_run_started:: > > update when state changed to anything like 'running'; case_run_stopped > > must be cleared > Agree. > > > > case_run_stopped:: > > update when state changed to anything like 'stopped'; case_run_started > > must be cleared > Disagree. the started time can help to record the test case running period. > > But the data will get messy when user has started the case, then stopped it, then started again, no? 1. start -> cr_started = DATE0, cr_stopped = None 2. stop -> cr_started = DATE0, cr_stopped = DATE1 3. start -> cr-started = DATE2, cr_stopped = DATE1 To determine whether he case is 'running' or 'stopped' would require if (started and stopped) and started < stopped: 'stopped' elif (started and stopped) and started > stopped: 'running' elif (started and not stopped): 'running' else: # (not started and stopped) 'stopped' I guess this could work, but i believe there must be a better solution. This just isn't clean / understandable enough IMO. Maybe case_run_started and case_run_stopped are not really needed? If we have functional activity history logging, we should be able to do the following, no? User... 1. creates new test plan run with a single test case -> 'status' field is set to 'not_started' 2. push 'play' on test case -> 'status' field is set to 'running' -> activity history log entry is added where 'old_value' = not_started and 'newvalue'= 'running' 3. push '$STOP' (eg, pause, stop, fail, etc) -> 'status field is set to '$STOP' -> activity history log entry is added where 'old_value' = runnning and 'newvalue'= '$STOP' (eg, paused, stopped, failed) Then we can always know what exact state the run is in and we can also get information about the test run period by looking for the times when we status changed from 'running' to any $STOP status. Thoughts? > > This way, only *_started or _stopped will have some value and we can then > > easily determine whether the case is currently running or stopped and when > > the action happened. > The status is very clear on if it is running or stopped and the result. > > > > It should not be a valid state to have both _started and _stopped with > > content. > Maybe running_started avaliable when "running", and running_stop avaliable > when "pass", "failed" or "Waved" status. > > > > (and perhaps this should also be done plan_run_started, plan_run_stopped?) > I believe you mean test run. It can be similiar with test case run.
Or maybe each 'case_run' 'play' should map to *one* datetime_created datetime_started datetime_finished And everytime play is used, a new task is "started" for the run and then it can be stopped. A case_run could have zero or more sub-run 'tasks'... if you will.
(In reply to comment #5) > Or maybe each 'case_run' 'play' should map to *one* > datetime_created > datetime_started > datetime_finished > > And everytime play is used, a new task is "started" for the run and then it > can be stopped. > > A case_run could have zero or more sub-run 'tasks'... if you will. May we log these datetime in history instead of column in case_run? Log who, when, action in case_run_history table, the actions include creating, play "running", play "passed", "failed", "Waived" etc.
(In reply to comment #6) > (In reply to comment #5) > > Or maybe each 'case_run' 'play' should map to *one* > > datetime_created > > datetime_started > > datetime_finished > > > > And everytime play is used, a new task is "started" for the run and then it > > can be stopped. > > > > A case_run could have zero or more sub-run 'tasks'... if you will. > > May we log these datetime in history instead of column in case_run? > Log who, when, action in case_run_history table, the actions include > creating, play "running", play "passed", "failed", "Waived" etc. I would change it from 'log who, when, action' to 'log who, what, when, added, removed' :) but otherwise, as mentioned in Comment #4, I do personally think it makes sense if we use just use a single column per run table called something like '*_run.status' whose value at any time could be ['not_started', 'running', 'stopped', 'paused', ...] and status changes could be tracked over time by reversing through the history. But it means activity logging must be re-written first. Which i'm also +1 for, but as of last time i checked... this task was targeted for TCMS 4.3 or something like that... which means... realistically... IMO... 9-12 months minimum :( And I'm not sure of the exact implications, but I also think it's worth keeping in mind how this might impact that existing web-ui. If the ui stays the same, to get the answer to the equivalent questions of "running_date"' or "stop_date" would require querying activity log table to determine the last time the ('what') field's status equaled one of the 'running' or 'stopped' status equivalents.
I think we almost get consensus: reasonable logs and one status. The planned roadmap is not final one, the final priority will be decided by QE team. We will follow the priority to implement. So if it is critically required, it may be implemented on the first release. Before TCMS 4, if we have any release, we can fix the running_date and stop_date bug.
Stale bug clean up; reopen if anyone else actually supports this.