Many users ask us if there is an ideal size for their tests.

Well, this is not a PractiTest-specific question, but it is an important question anyway. The size of your tests and also the way you structure them will help you to make better use (and re-use) of them and it will also contribute to helping your testers perform better in their work.

There is no one-size fits all approach to testing. The approach you will take depends on many factors, such as the application you are testing, the development approach followed by your team, the subject matter knowledge of your testers, and many other things that may point towards a specific approach or another.

Still, there are some best practices that will help most testing teams in most testing approaches.

1. Plan your tests as reusable blocks – Make sure your tests cover small and simple pieces of functionality, then group them in order to generate test sets that cover more complex scenarios.

2. Keep your tests short – A testing session should not last more than 60 – 90 minutes. After this time the human brain will start getting tired and stop being effective, meaning that your testers will start missing some of the issues in your product.

When planning your tests, take into account that you want each atomic test to last less than this time, ideally (following up on point 1) you should strive to create tests that last between 15 and 45 min, and plan your testing session to work with cover 3, 4 or 5 of these tests.

In any case, if you have a test that has over 40 steps we suggest you review it and decide if it is not better to break it down into several smaller and more modular tests.

3. Write steps depending on the knowledge level of your testers – Unless you are working in a “regulated environment” where you are forced to have very low-level test steps and scripts you should try to match the depth or level of your steps to the knowledge and level of your testers.

For example, if your testers are experts and power users of the application they are testing, you may want to work mostly with step names and leave the step description empty (as it may be obvious to them how to perform the specific task described in the step name). But on the other hand, if your testers are not really experts, or for some reason you want them to do exactly the operation in a very specific way, then you will want to have very low-level step descriptions.

Based on our experience, most of the time you will want to do something that falls in the middle between these two extremes.

4. Create guidelines or rules of thumb for writing your tests and steps – Writing tests is something very personal and every tester, if left to himself, will write tests in a different way depending on what he knows and likes. If you leave your test styling approach to each tester you will get individual tests that are very hard to combine in order to create good test sets.

To achieve homogeneity in your testing it is recommended to create guidelines for your testers. These guidelines need to match the needs of your team and process.

Examples of guidelines are the following:
– Create steps that cover only one screen at a time
– Have tests that have between 5 and 15 steps
– Information to perform your steps, if you have more than one set of data, should be stored as attachments to the step.

The most important thing to remember is that by using a modular approach you will be able to make better use of your tests and so save valuable time in writing, managing, and maintaining your tests.