| || |
Can\'t Mercury fix TD
There are many things I dislike about TD - ie, clumsy to use UI; obvious bugs that STILL seem to be in the latest version; and it seems to have been designed from the assumption that all testing involves stepping through a series of windows (ie, the Step 1, Step 2, etc way it forces you to document tests). Some tests don't suit this - eg, say you're testing a report that contains complicated data. Your first step is print out the report - your Expected Results are then extremely detailed. So you have a one-step test, with extremely detailed Expected/Actual Results. TD appears to have been designed from the idea that your tests always go as follows: 1. select to open a window - Expected Result - window opens. 2. click button A - Expected Results - another window opens, etc.
It also forces you to manually copy across all of your tests from Test Plan to Test Lab - there's no way that you can select tests from Test Plan and automatically copy them into Test Lab. So we've frequently had to manually copy them across - which is just dumb, and forces you to spend enormous amounts of time doing something that the software should do for you.
But number one on my list of annoyances at the moment is Test Director's time-out. We've got the time-out set to something like 2 hours - which is fine, that's entirely up to the user to decide what you want as your time-out (we've got it set up like that as we have limited licences, so the intention is that people who aren't really using it get kicked out.) The problem is that the time-out kicks you off regardless of whether you're actually doing things. An example: I selected to add a new Defect before - so there I was entering all the details, then I hit Submit (at most a few minutes after selecting to the add the Defect) then it tells me my times up and I need to re-login. I have this happen a few times every day, and it's extremely annoying. Mercury charge an awful lot for this product - I think it's about time they sorted out some basic issues that make it a pain to use.
I expect I may now get at least one reply that tells me to stop being so negative. But I felt the need to vent.
Happy QA'ing all.
Re: Can\'t Mercury fix TD
Here's what I found in the Knowledge base at Mercury, it might answer your problem in that if the client was running a manual test and leaves it in that condition, it will not time out:
[ QUOTE ]
Problem ID: 44967 WAIT_BEFORE_DISCONNECT methodology
From client side:
Every client session is aware of this parameter value. Every 5 minutes, each client machine (the Webgate on the client machine) sends a PING to the server to notify that the client is alive. Part of the data that is being sent is the interval in milliseconds from the last action that this specific client did (action that is not PING). After WAIT_BEFORE_DISCONNET interval the Webgate of that client stops sending PING requests and the client session will display the message, "You have been disconnected by the server."
From server side:
Every 15 minutes a job called CInactiveTdSessionsCleanerJob is being executed on the QC server. The purpose of this job is to locate inactive sessions, clean their resources (license, locks, etc) and then clean the sessions themselves from the SESSIONS table.
In order to locate inactive sessions, the server runs an SQL query that finds all sessions where their last PING time is greater than 10 minutes. In other words, sessions that did not send PING request to the server in the last 10 minutes are considered as inactive. As you can see the server is NOT aware of the WAIT_BEFORE_DISCONNECT interval.
As a result, after the last valid ping between client and server, it could take up to a minimum of the minutes set in WAIT_BEFORE_DISCONNECT and a maximum of 10 minutes + 15 minutes + WAIT_BEFORE_DISCONNECT.
Another way to look at this:
The last action time in Site Administrator -> Connections tab holds the time of the last "real" request of the session. Where "real" means request that was made by the client, and not a ping. If a user is running a manual or automated test and they just leave the manual runner session open for manual runs, then their client will send pings to the server to stay alive but it will not update the last action time. Same thing for automated tests, if the test set takes 4 hours to finish then last action time will not get updated and the Quality Center administrator might think that WAIT_BEFORE_DISCONNECT is not working.
So, most likely the disconnects that are not working are because the users are running either manual (left window open in execution of manual test) or running automated tests, which is as designed.
This mechanism has been implemented for performance reasons. It is intended for users to use in order to disconnect any "forgotten" sessions and free up their resources. For example, if a user has connected to QC and then leaves for an extended period of time. Mercury does not recommend to set this time to less than 60 minutes. The default value is set to 600 minutes.
[/ QUOTE ]
Success is the ability to go from one failure to another with no loss of enthusiasm.
~ Winston Churchill ~