ORGANISING THE TEST CASES
-Test note of “Essential Software Test Design”
2015-09-24
22.1 Test Cases
22.1.1 Size and Subdivision in Test Cases
22.1.2 Components
22.1.4 Benefits and Drawbacks of Documenting in Such Detail
22.2 Test Chains
22.2.3 How Large is a Test Chain?
22.3 Test Packages
22.3.2 How Do You Know What is a Good Test Package?
22.4 Execution Plan
22.4.1 Contents
22.4.2 Example of an Execution Plan Overview
22.4.3 Example of an Execution Plan in Detail
THIS CHAPTER CONTAINS practical details for how you can build and organize test cases. We must also link them up in an appropriate way so that the result is executable.
To help us, we have things like test chains, test packages and execution plans：
- The execution often begins with free-standing simple test cases for a limited area, which are not mutually dependent. These can be run in parallel, without an internal order.
- A test chain can be seen as a red line linking up several test cases which have to be run in series.
- Test packages, in turn, are a practical categorization, where you put into the same package all the test cases which, for some reason, need to be carried out simultaneously.
- The execution plan links everything up in a detailed schedule. The picture below illustrates how it fits together.
Figure 22.1: Picture of how you can organize your test cases. There is no absolute truth about how best to organize your tests: like everything else, it depends on the situation.
22.1 Test Cases
22.1.1 Size and Subdivision in Test Cases
- The maximum size should suit about as long a period as you can manage to concentrate, or sit still in one session.
- If many actors are involved, it may be appropriate to divide the test cases up according to who will be carrying them out.
- You should remember that the test case has a clear purpose: when the purpose is achieved, the test case is finished.
22.1.2 Components
Administrative Fields:
- ID,Name
- status, system, test level, priority and date
22.1.4 Benefits and Drawbacks of Documenting in Such Detail
Benefits of describing each detail in the test case are:
- It can be saved as a regression test case
- It requires less knowledge of the system as a whole
- A person from outside can carry it out with a little support
- You end up with documentation about your work, if this is needed
- The execution of the test case goes more quickly when you have decided on the details in advance.
Drawbacks of having overly detailed test cases may be that:
- When you are about to run the test case, you discover that the system has been changed, and that the details no longer match
- After having run a number of test cases, you have so much knowledge that you are no longer reading what is in the description and, therefore, risk making mistakes by missing certain details
- It takes ages longer to write down the details, time you could have used for designing more test cases, or carrying out tests
22.2 Test Chains
After the simple functions have been verified, you must also verify that the whole application fits together, including its manual routines. In this case, it often gets far too complicated and impractical to write everything in one single test case. You can link up several test cases in chains. Thus, a test chain consists of a number of test cases which are run in a particular sequence.
It is appropriate to split up the test case into a chain if several different people are to carry out different parts, if we have to change the date in the system between different steps, or if completely different dialogues/functions in the system are used for different steps.
Test chains are especially well suited to verifying business processes, larger use cases, scenarios and during data and business cycle testing.
22.2.3 How Large is a Test Chain?
A test chain can be seen as a red line running through the system. How long the line is, and what it contains, varies depending on the system. Some typical examples of how you can arrive at a test chain are time cycles and business processes.
22.3 Test Packages
A package contains test cases which are practical or necessary to run at the same time. When you write down your execution plan, you often write down which test packages are run each day.
Often, it is not practically possible to run all test cases in a chain at the same time – this may require batches, rolling dates or something else amongst different parts.
22.3.2 How Do You Know What is a Good Test Package?
This is a question of what is practical in your case. In the example above, we packaged by date. This is often, but not always, a good form of subdivision.
At earlier levels of a project, you may choose to package by test area (function, dialogue, object etc.). A package may then contain, for example, a walkthrough of all the help texts in the system, or all the detail tests of a special window.
22.4 Execution Plan
22.4.1 Contents
1. Preparation
Usually, the level begins with preparation, e.g. loading base data, setting parameters, verifying the test environment. When you have succeeded in carrying out the preparations correctly, it is recommended that you perform a backup.
2. Happy-Day Testing
In order to check whether the application is ready to test, you often run some simple introductory tests. Happy-Day tests, as they are often called, are an introductory check on whether the system fits together. Use the central functions with simple data. Here, there is often a point of decision which says that you do not continue with any more tests before the most elementary ones are successful. You perform these introductory tests, appropriately, with each new larger delivery.
It can be regarded as curious that this is also called Smoke Testing, which stems from the good old days when we had to check circuit boards, which, with any defect in construction, could start to burn, giving off smoke as a result.
3. The Next Step
Subsequent tests can be split up in many different ways. For earlier levels, it is common, firstly, to verify individual dialogues, functions or test areas in detail,before you continue with more overarching scenario based tests.
Schedules are built according to what is most practical. Parameters affecting this are:
• the priority of the test area – the most important is tested first
• the order of delivery – this may differ from the priority of the tests
• the flow through the system may require particular functions to be carried out before others – the business processes are an important source of information
• time cycles govern which test dates apply
A common approach is, firstly, to make sure that the elementary tests are performed for the whole system, before you begin with test chains for the most important parts.
22.4.2 Example of an Execution Plan Overview
Figure 22.3: Execution plan overview for test level. It makes things easier to have some form of overview plan, especially if we are dependent on other systems and resources.
22.4.3 Example of an Execution Plan in Detail
Figure 22.4: Execution plan of level of detail. As a test manager, I really want
to be able to put in the plan who has to do what and when.