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 they way you structure them will help you to make better use (and re-use) of them and it will also contribute in helping your testers to perform their work better.
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 simply pieces of functionality, then group them together 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 produce.
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 a number of smaller and more modular tests.
3. Write steps depending on the knowledge level of your testers – Unless you are working on a “regulated environment” where you are forced to have very low level test steps and scripts you should try to match the dept or level of your steps to the knowledge and level of your testers.
For example, if your testers and 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). If on the other hand 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 times 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.
In order to achieve homogenity 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.
etc.
——————-
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.