Bug 865334 - test_case_runs.running_date does not update after pushing 'play' button
Summary: test_case_runs.running_date does not update after pushing 'play' button
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: TCMS
Classification: Other
Component: Database
Version: Devel
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 3.9.0
Assignee: Yang Ren
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On: 865329 865332
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-11 09:06 UTC by Chris Ward
Modified: 2016-06-13 07:44 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-06-13 07:44:17 UTC
Embargoed:


Attachments (Terms of Use)

Description Chris Ward 2012-10-11 09:06:13 UTC
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.

Comment 1 yawei Li 2012-10-17 07:19:08 UTC
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

Comment 2 Chris Ward 2012-10-17 12:30:25 UTC
(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?)

Comment 3 yawei Li 2012-10-19 08:35:42 UTC
(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.

Comment 4 Chris Ward 2012-10-19 10:28:44 UTC
(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.

Comment 5 Chris Ward 2012-10-20 07:24:39 UTC
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.

Comment 6 yawei Li 2012-10-26 01:23:52 UTC
(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.

Comment 7 Chris Ward 2012-10-27 13:30:34 UTC
(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.

Comment 8 yawei Li 2012-10-30 09:50:34 UTC
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.

Comment 10 Chris Ward 2016-06-13 07:44:17 UTC
Stale bug clean up; reopen if anyone else actually supports this.


Note You need to log in before you can comment on or make changes to this bug.