Test Process and Test Design

Test Process and Test Design

Any analysis, including software testing is aimed at finding bugs.

A bug is a deviation of the actual result (certain actions) from the expected result.

What is testing for? The testing phase allows the developers to find bugs before the users do as once users get disappointed with improper behavior of an app they will stop working with it. At that bugs should be discovered before releasing the product to be developed.

To conduct testing you need:

1. Get the expected result.
2. Get the actual result.
3. Compare these results.

For example, we need to test bulletproof glass. At that there is every reason to expect that a bullet cannot pierce it. We should try to refute this expectation to do the test, i.e., to shoot the glass and find out the actual result. Then it is compared with the expected result: if the bullet shatters the glass, then there is a bug.

Thus, for testing purposes, you still need to perform some action (in this context – a shot), and, eventually, we are arriving at the conclusion that the testing process consists of four stages:

1. Select an action.
2. Get the expected result of this action.
3. Get the actual result.
4. Compare these results.

The first two stages relate to the test design – writing tests.

1. Select an action (test scenario).

If we have a formal software requirements specification, then test scripts should be written based on these requirements. A good specification contains explicit use-cases represented as step-by-step instructions that can be used to execute a software test. If the specification does not contain step-by-step instructions, but only general words, the test designer should write such instructions.

Load testing service is what you need to verify performance of a system under real-life workload conditions. It helps to determine how the app behaves when many users access it concurrently.

For more thorough testing, you can come up with your own test scripts. There are many different techniques for selecting such scripts.

2. Information on the expected result can be found in the specification. If the requirements do not describe this, you can use:

2.1. Authoritative opinion (the one obtained from the person who creates the specifications)

2.2. Well-established standards (formal ones, for example, RFC, or de facto standards, for example, a context menu that appears when you right-click an item on the desktop).

2.3. Common sense.

2.4. Look into the source code.

2.5. Other.