NOTE: We're using TD v6.02- others will have to comment as to whether newer versions have this same issue.

We've discovered what I'll call a nasty design/usage flaw in TestDirector (v6.02). I'm submitting it so others won't stumble over it like we did. It is related to how we use the product, so depending how your conditions it may not affect you. The problem is this:
When running tests, we leave the "Tester" field "unassigned" (in reality we use the "Guest" value to indicate an unassigned test). We do this as it is too difficult with all the changes that happen from day to day for a test designer to know (perhaps weeks) in advance who's going to be available to run a particular test. Therefore, our process is for a tester to review the available tests ("unassigned") to run, decide which they want to execute and indicate that by changing the "Tester" field to his/her name.

That's when the problem can occur. If two people pick the same test, and depending on when they last refreshed the "Run Test" tab, they both could assign themselves as the tester and start what amounts to two runs of the same test. Chances are moderate/unknown that they will not know this is the case until the first one to assign the test to themselves notices that the other tester's name appears when they finish the run and the screen is updated. It's hard to say as it all depends on if tester #2 has done something to cause a database update.

To work around this problem, we've found the following works:
  1. <LI>With the Run Tests tab "active", press [F5] key to refresh the screen to ensure display is of most current data.
    <LI>Find an unassigned test that you want to run.
    <LI>Since #2 may take a while, press [F5] again to ensure no one else picked that test.
    <LI>Change the "Tester" field to your name.
    <LI>Press [F5] key to immediately write the change of Step 4 to the database.
    <LI>Verify that your name is still assigned in the "Tester" field.

The changing in Step #4 of the Tester's name is where the problem occurs- this change should be immediately written to the database, but probably for some very good reason from the programmer's point of view, it does not.

Hope this helps others. Let me know if you find an easier to get rid of this annoyance.

If we cease to become better, we will one day cease to be good. -Thomas Acquinas

[This message has been edited by acquinas (edited 02-26-2002).]