Locked test case timeouts?

[pbrooks]

When you go to edit a test case, then hit the back button on the web browser, the test case remains locked. Although that doesn't seem like a bug, just a quirk of having a web interface, it seems like there should be a way around having those test cases locked indefinitely. Would it be possible to have a timeout such that after a few minutes it automatically unlocks the test case if it was locked in the web interface? It may be more logical to have the timeout happen when the user times out of the login session with the web client, such that every time the web session ends, it also unlocks all open test cases (or whatever you had locked in that session) and discards any unsaved changes.

I've noticed that having locked test cases seems to pop up error dialogs when trying to copy the test cases or generate project reports, so having them automatically unlock after a period of time or when a user logs out (or is forced out) may alleviate some of those issues.

[pbrooks]

bringing this back to the front page...

We've started a full test pass, and with 10 people in our company testing, all being required to use the web-app, the locked test cases not timing out is becoming quite a nuisance. After only 1 day of testing, there were about 20 locked test cases, even though i keep pestering my people to never leave the edit page without canceling or saving their changes. At this rate, when we finish our test pass, we'll have to go through and manually unlock upwards of 100-120 test cases, which will be a total pain to track down, considering we have around 1500 test cases in one test pass.

On another note, if a test case is locked, what exactly does that mean in terms of reports? are those test cases skipped? are they included but with the pre-locking information (which is usually correct, as most of these test cases are being locked accidentally)? are they included in the count, but marked as not yet attempted?

any information you can give me would be greatly appreciated.

[Tim (PassMark)]

Unlocking files on the back button action of the browser is a little tricky due to the whole stateless nature of the web browser, it would probably require javascript to intercept the back button click, then call the CGI to unlock, and then we would have to do a redirect from the CGI, which also means the previous page would need to be retrieved as well.

Automatic time-outs that come into effect when opening a test case would be more feasible, the time can be retrieved from the lock file and compared to a time-out saved in the CGI config file. A similar system could be put into the standalone version of TestLog.

To unlock all files held open by the same use when their session times out is more complex, a list of open files would need to be stored which isn't curently being stored.

The locked warning during report creation is just to alert that the test cases being used in the report may still be in the process of being edited. The data saved in the test case is still included in the report.

We'll look at adding an Unlock All function to the standalone version, this should make it easier to remove the locks created by web users hitting back, as well as adding the automatic time-out option to the CGI module.

[pbrooks]

What about a way to generate a report that tells you what the locked test cases are, and who locked them? It'd be great if i could get mad at the right people who keep leaving test cases locked all the time.

[Tim (PassMark)]

We'll keep it in mind, maybe add it as a report that is created as a text file from the command line, seeing it would mainly be an administration tool.