strategy involving peers & the top management.
3) Automate the most
repetitive tasks and especially those tasks that have traditionally found the
majority of the bugs;
4) Formulate a test case management framework, to ensure that every software
testing engineer is operating under the boundaries of the same standards, and
all tests are properly maintained and easily accessible.
5) Cut down the maintenance - write common functions & modularize the
tests for easy maintainability, and reuse them everywhere & even on other
6) Write meaningful test logs & generate summary reports for all test
results i.e. pass or fail. Most important aspect is to log everything.
7) Design the tests in a way that they can be made to run unattended and must
be able to recover out of failure.
8) Design the tests in a way that we don’t have to rewrite them for every
language. The tests should support different platforms, and configurations.
9) Avoid repeating structured tests, which eventually will find the same
bugs. Thus introduce an element of some randomness in the order of execution of
test cases, to detect new bugs with the same automated tests.
10) Start with small-small automated Build Verification Tests (BVTs) running
for 1 to 2 hours daily. Move ahead with the installation & testing of the
build only after the success of BVTs.
11) Expand the BVTs to developer regression tests being short suite of tests
running for 10 to 20 minutes, on a private incremental build created by the
developer, just before checking in his or her changes to the source code. These
tests would cover the basic functionality of the product, and are aimed to
prevent the developers from checking in changes to the code which could break
the primary areas of functionality.
12) Measure effectiveness of
automation effort using a direct metric of number and rate of bugs
13) Use automation on stress testing performing same actions repeatedly. In a
multi-user environment, go on adding users to the system, and perform a common
action. If the application uses a database, write tests that add, amend, and
delete records continuously, and then look for a system crash, memory leaks, a
corrupted database, or an extremely large database. Execute the automated tests
till the product fails.
14) Use automation for regression testing. Automated tests should be easily
exploited to determine if there has been any regression in functionality between
15) Park all the tests in a test case management
16) We should write our scripts keeping the tool in mind, so that automating
them becomes easy and we can reduce the duplication.
17) We need to
ensure the availability of good quality static data so that automation tools
runs consistently. If the data happens to vary frequently, the tool will fail
the tests thereby forcing us spending wasteful hours in investigating as to
whether it was a software or a data error.
18) Maintenance of the automated tests should be an ongoing activity. Even
after the formal finish of the testing activity, software testing engineers
can’t afford to relax and should rather devote their time in keeping the tests
up to date and continuously work to enhance the existing scripts
19) We need to adopt a modular approach while building our scripts, masks and
data files, so that over a passage of time, a library of significant size could
come up and becomes a useful asset while creating more tests in the future.
20) While deciding on which programs to automate first, it is better to avoid
the ones, which happen to be under the time pressure. For getting success in
automating the tests of majority of programs, a convenient time period free of
undue pressure should be kept aside for the development of the techniques,
possible creation of common scripts, establishment of templates for
Note: I would welcome your feedback comments or suggestions on this
More Articles on Test Automation