At the beginning of a good test setup there is a good test specification. Writing down the different test cases, helps us to plan the test implementation as well as the test execution phase – duration as well as resources.

Furthermore, based on a good test specification, the tests itself can be structured in a better way. With a specification it is easier to identify, which parts are needed in multiple tests, which parts only differ in their parameters and which parts are needed only for specific corner cases. As a result the implementation of the tests can be designed easier and as a subsequence the resulting test framework becomes cleaner and more extensible.

A test specification is also useful once the tests have been implemented and executed already. As you might know, after the test is before the test. With every iteration or extension of the system under test, all already executed tests need to be re-executed to avoid regressions – of course along with new tests . A good documentation helps to find out, which tests already exist and which ones must be added to the test framework.

So, what kind of information should a good test specification contain? In my opinion the following things are necessary:

Name

The name is a short identifier of the test and enables us to talk about a specific test easier. Ideally, the test name also roughly describes, what the test tests, so that you can quickly get a rough idea of what the test is about.

Examples:
successful login
failed login

Type

The type describes, which dimension of the system is tested. Does it test  its function, its performance or its behavior under load?

Description

The description explicitly describes, what needs to be done in the test. Along with the actual test steps, it might also contain the instructions to setup the preconditions of the actual test. The test description must be clear and precise. This is important, so that different people do not interpret different instructions. Otherwise, the person specifying the test, might want to test one situation, but the person implementing the test, implements a different situation. And possibly a third person, checking the test coverage, assumes, that something is tested, what actually is not.

So be clear, be precise!

Examples:
Bad: Login with wrong credentials.
Good: Login with no user name.
Good: Login with wrong user name.
Good: Login with no password.
Good: Login with wrong password.

Expected Result

The expected result does not only describe if the tested function is expected to fail or succeed. The final state expected after the test is at least as important as the behavior expected, while the tested function is running.

For example the result of a login with correct user name and password combination might be:
The login must be successful. During the login a in progress icon is shown. Once the login had been successfully done, the user is redirected to the start page. His last login time is resetted. The login did not take longer than 1 minute.

Conclusion

A good test specification has

• Name
• Type
• Description
• Expected Result

and enables us to:

• plan the test phase more precise
• write cleaner and easier extendable test code
• track code coverage of tests