Verification of application states

All test cases need to verify at least one part or process of the application, (this would be the preferred method), though some test cases may verify more than one item.  These are decided at design time of the test plan and recorded at the test script recording phase.  Some times, these may change (using new test data being a typical reason) and may need re-recording.  This can cause a bottle neck in the testing cycle.  For better verification use paramatised verification. (see below)

Error handling should a test fail (to assure that all test scripts can be run unattended)

Due to the ability to run automated tests unattended tests can be run overnight.  Should a test fail though, some test tools fail to restore the application to baseline for continuation of the next test.  With QA Partner, our preferred testing tool, there is built in error recovery functionality.  So should your application fail during an 'Ordering' test case, (an example being a SQL update failing), the test script will log the failure, the error recovery will close the 'Orders' form and all related forms, to begin the next test case.

What is paramatisation?  What does it mean?  Why paramatise?  By paramatising test scripts, you make your test scripts more usable.  Now instead of recording a test script for a different 'order details' or 'user' you paramatise the first recording and simulate an unlimited amount of test case scenarios.  Your only limited by your test data.  It is important to note that verifications need to be paramatised to and this usually requires in-dept analysis with the developers.  Using the developers knowledge of the processes taking place, it is easy to drill down and paramaterise verifications.  Again this will increase the scope of the tests as you can simulate more scenarios quicker and easier.

Due to the record once and multiple play of automated testing, your testing process is speeded up.  But when initially recording tests the QA engineer should be aware of localization issues.  If aware, scripts created can be coded for use against localized versions of the product.  This then enables the client to run the same scripts against not only two different english versions of a product but also different french, arabic, and chinese versions of a product.  This further increases usability of your test scripts in the testing process.  With minor set up overheads, and minimal configuration on playback, many localized versions of a product can be tested successfully, easily and safely.