<< Test Automation | Non-Functional Testing >>

What is Automated Testing Good For

<< Test Automation | Non-Functional Testing >>

What is Automated Testing Good For?

Automated testing is particularly good at :

Load and performance testing automated tests are a prerequisite of conducting
load and performance testing. It is not feasible to have 300 users manually test a
system simultaneously, it must be automated.

Smoke testing a quick and dirty test to confirm that the system `basically'
works. A system which fails a smoke test is automatically sent back to the
previous stage before work is conducted, saving time and effort

Regression testing testing functionality that should not have changed in a current
release of code. Existing automated tests can be run and they will highlight
changes in the functionality they have been designed to test (in incremental
development builds can be quickly tested and reworked if they have altered
functionality delivered in previous increments)

Setting up test data or pre-test conditions an automated test can be used to
set-up test data or test conditions which would otherwise be time consuming

Repetitive testing which includes manual tasks that are tedious and prone to
human error (e.g. checking account balances to 7 decimal places)

Pitfalls of Test Automation

Automating your testing should be treated like a software project in its own right.

It must clearly define its requirements. It must specify what is to be automated and what isn't. It
must design a solution for testing and that solution must be validated against an external reference.

Consider the situation where a piece of software is written from an incorrect functional spec.
Then a tester takes the same functional spec. and writes an automated test from it.

Will the code pass the test?

Of course. Every single time.

Will the software deliver the result the customer wants? Is the test a valid one?

Nope.

Of course, manual testing could fall into the same trap. But manual testing involves human testers
who ask impertinent questions and provoke discussion. Automated tests only do what they're told.
If you tell them to do something the wrong way, they will and they won't ask questions.

Further, automated tests should be designed with maintainability in mind. They should be built
from modular units and should be designed to be flexible and parameter driven (no hard-coded
constants). They should follow rigourous coding standards and there should be a review process to
ensure the standards are implemented.

Failure to do this will result in the generation of a code base that is difficult to maintain, incorrect
in its assumptions and that will decay faster than the code it is supposed to be testing.