THE OVERARCHING PROCESS OF TEST DESIGN
-Test note of “Essential Software Test Design”
2015-08-27
Content：
Since test design is complicated, and contains many different approaches, it is appropriate to divide the work up into several steps.
Figure 8.1: Process for test design in four steps
8.1 Preparation – Get the Big Picture
Before you begin to develop test cases, it is a good idea to compile an overview of what is to be tested. Often, the test strategy contains some form of overview of the test coverage.
Find out which documents and other test basis are available to you to work from. This can be anything from business plans to technical models and program specifications with database descriptions. Go through the test basis and try to identify which requirements you are affected by. If the requirements are not written down, you need to conduct a dialogue with those placing the order, and the developer, in order to obtain the test basis you need.
All the requirements we have identified, and all the requirements we can assume exist, even if they are not written down, must now be tested. As a test designer, you must find a way of arriving at the right questions to ask.
8.2 Step One – Creating a Model of the Requirements
When the overview is complete, it is time to build test cases. Your first step is to model the requirements in a form which you will cover by test cases in the next step.
There are many types of model to use and, in the majority of projects, you must use several different types in order to give as good a variation as possible to the test cases. Common models are tables, flow graphs and state diagrams.
Remember that you must have early involvement in the project. You must develop your models in parallel with the requirements being written. By compiling the models, you will contribute to the quality assurance of both the requirements and the design.
Here, you have the opportunity to contribute genuinely to the common good, by asking important questions at such an early stage that they can be answered in time before the coding gets under way. On the other hand, do not try to develop all your test cases in detail before you have had your models examined and accepted by the rest of the project team. It is obviously a good thing to think like a tester and question almost everything, but do not be too hard in your criticism, since your job is to be an asset to the project team, and not to run down the other team members.
What you actually do is the part known as analysis in many project models, which often contains the steps requirements-analysis-design-coding-testing. It can be argued that those who compile the requirements, or those who design the system, should carry out this analysis but, in my experience, this is seldom the case. Also, even if those who write the requirements, or design the system, carry out this analysis, they do not ask the same questions as you do as a tester.
8.3 Step Two – Covering the Model, Creating Base Test Cases
Step two is to cover the model with test cases. In this way, you get a measure of which test coverage you have. Graphic models are filled in through writing test cases which encompass all the rectangles and circles in place, and the arrows linking them up. For formulae or sets of rules, it is a question of all the parameters involved being tested, as well as the most important combinations of them.
8.4 Step Three – Supplementing With Test Data
The base test cases we have generated in step two must now be run once or several times with different data in order to achieve a greater depth of testing.
Equivalence partitioning of each parameter and boundary value analysis provides you with relevant values for dividing up the test data. When
8.5 Step Four – Advanced Testing
