Over the course of the last year I have been using iMacros plugin for the Fire Fox browser. This has turned out to be a pretty neat tool to allow me to test out my applications quickly in Fire Fox. Although there is some babysitting with the free tool it does save a tremendous amount of time. Besides spend that time eating my lunch or other various things while waiting to begin manual and exploratory testing. The tool also records times it takes for webpages to load which is awesome for testing pages between different builds. The paid version has a ton of additional features compared to the free tool. The paid version is incredibly cheap compared to other tools on the market so who knows we could be using the paid version here one day....

One extremely helpful finding in my testing career has been the user of a database to track test cases.  If any tool (besides my keen mental abilities j/k) has become extremely useful in my testing repertoire it has been the manual test case database.  My current tool is in MS Access and lacks all the bells and whistles I would like. One of my goals is to write my own front end using C# and a back end database in SQL.  Well we can all dream but the idea is any future changes could be designed and implemented easier by me then waiting on a developer to complete the tasks.  Ohh well one can dream right.

Sometimes I forget to close my browser between each case or scenerio. Doing this can allow bugs to slip through your air tight QA process. Your browser session hangs on to data collected in the session. This could cause a case which would normally Fail to appear as a Pass.
Albeit rare it will happen. One great benefit of automated testing is it will close the browser session for you. We must remeber our Test Cases or scenerios are exactly the path you are expecting the end user to follow

Estimating QA hours for the stabilization cycle of a project or release is extremely difficult. I attempt to view several factors when conducting my estimations. 

The first item to examine is the complexity of the functionality being tested.  This is tough to measure in my opinion.  Normally experience plays a huge role in estimating the complexity.  I also use attempt to estimate each test case and a lot a block of time for exploratory testing.  In my development environment there are a ton of changes to the requirements.  We work in an agile type environment and the requirements are constantly in flux and it is important for the team to work closely to ensure we are developing and testing the correct product.  This flexibility tacks on an added complexity when attempting to measure complexity!!  I know that was not funny but it has been a long day……

The second item which is examined when estimating stabilization hours is the regression testing timeframe. I always add this to the end because usually we don't find many errors in the full regression testing but we cannot rely on the system testing alone.  It can also be devastating to make it almost all the way through regression only to find a costly error. 

At the end of the day it is still difficult to get a dead on estimation of hours to fulfill the project.  The goal is to provide a product which is Fit for Use and if it takes a few more hours to do that than so be it. Although I am going to continue to refine our process and even try to determine a way to prove statistically how long each complexity of item takes to produce.

 

Many time when we design test cases we forget to design cases using the back button. Within a web application the back button on a browser can case unexpected and unwanted behavior. The reasons seems to be because the behavior is controlled through the users browser and nobody seems to expect different behavior. I have seen this problem where the page which the user is trying to return to needs a value which was retrieved in the last page but does not remain in session since the first page never had the value. This seems to cause applicaiton errors and is then difficult to track down if this is found to be happening post deployment. We cannot do exhaustive testing but implementing some of this testing into our test scripts can help alleviate pesky anoyances once in production. Especially if there is very little monitoring of error logs or tracking of support issues once the build is deployed to production. Check you back button!!