Automated Testing and Test Design

Test automation success highly depends on the way the tests are designed. Design defines how fast automated tests can be developed, how these tests are suitable to read and understand the concept, how they can localize the problem and how they can reveal problems at all. All these points are highly depend on tests structure. It means that test design takes essential part in test automation. It is test scenario or test workflow description which is basis for automated test implementation. That's why direct impact on test design stage may highly improve test automation process. Well, in order to improve test automation any test scenario requires the following:

1. All tests (or perhaps most of them) start from some fixed and predefined state - it corresponds to user scenario. In most cases there is some common action set the test starts with ( e.g. application start, login, initial navigation). From the implementation point of view there is some function ( or any other kind of program module ) driving system under test into some initial state and restoring it after test completion ( if necessary ). There are a lot of solutions having built-in components for this purpose. E.g. there are setUp and tearDown methods in JUnit TestCase class, SilkTest has its own recovery system mechanism involving such modules as appstates.
2. All tests are independent on each other - this is quite critical point. It wouldn't be great if some test failure caused other tests to be failed (as chain reaction). In this case we actually have single very long workflow test being split to sub-tests and each test failure causes "domino effect". So, in order to avoid this effect it's better to design tests in specific way to make them running the same way both in a batch and in case of single run. Such design can be achieved by means initial state fixation (see previous point) as well as additional test-specific conditions definition. In most cases these conditions are closely connected to external test data organization.
3. One test per one function - the main idea is to avoid huge long workflow tests (covering a lot of different aspects) and concentrate testing activity on some separate business function. It means that test is built by the following pattern: drive the application to the state the function under test is accessible -> perform function under test verification actions -> go out. And nothing more. If more than one business function is affected by the test and these functions are independent to each other then we are at risk to miss errors in one functionality in case we found critical error in another functionality being tested before. From test design point of view there's no improvement in the approach described. But from implementation point of view we get rid of necessity to apply recovery scenarios for independent parts of test. Of course, it's useless to clone a lot of tiny and almost the same tests but huge workflow scenarios are inconvenient too. We need to find some balance suitable both for desing and implementation
4. There is fixed execution and verification command set - it means that it would be great to have some core command set covering as much actions as possible (some actions can be parametrized in order to decrease commands amount ). For example, if we test Content Management System then for defferent content type we have fixed operation set like: navigate, create, fill in form, save and verify, reopen, modify etc. Such templates can be applied for each content type. Resources involved is the only specific (and can be parametrized). In this case test designer performs a lot of duplications without any reason because these duplications are usually omitted during test automation development. In addition to this there are some test automation approaches which are effective only in case of some test design applied. For example keyword-driven approach is the most effective in case of ability to define such fixed execution and verification command set described in this point. That's why some unified command set for tests or at least some test group can highly optimize test designer work as well as minimize test automation development workload.

Testing process is neither isolated nor separated. That's why there's possibility to simplify your work before the work is assigned. And good test design allows minimizing your implementation problems