Test cases are very important for determining the quality for acceptance testing. They are the first steps in a test cycle and if test cases aren’t of sufficient quality, then the whole project will be ‘burdened’. Writing “great” test cases is a skill that gets form by simply doing it. But it’s very handy to have some insights that could help you. With this article I want to reach out to you and give suggestions to make it easier, more fun and better. The tips that will be given will in particularly relate with test cases at acceptance testing of ERP systems.
Within the world of software testing, there are a lot of definitions of test cases. Because of this it is important to name our definition. In our philosophy test cases are (based on IEEE610): “A set of test inputs, execution conditions, and expected results developed for a particular objective.” Knowing how to write good test cases is extremely useful for anyone who wants to test. Whether it’s a functional test, a user acceptance test, testing a web application or a module of an ERP-system. In all situations described above the test cases determine to what extend the results give a verdict on the pre-set targets.
As described in the definition, Test cases help guide testers through a sequence of test instructions to determine whether or not the the software meets the pre-defined requirements. The execution of test cases helps us gather and discover information to realize that specific goal or target. The first problem we directly encounter is the diversity of possible targets. And because there are different types of test and goals, there are different types of corresponding test cases.
A second problem is related to the content of the actual test instruction or steps. The level of these instructions is dependent on the type of tester that has to interpret this information and give an opinion. A professional tester will need different instructions as opposed to an end user that is involved with acceptance testing of an ERP-system
Think about what you want to report, so that you can determine your derivative goal. Using that as a base, you’ve got the outline of the test case in view. There are many different goals, where we always have to ask ourselves what we are trying to learn or achieve when we are going to run the test. Here are some examples:
The test results as derived from the test cases provides direct relevant information about the goal.
Reserve enough time to design your test cases, so that they match your goals. Poor test cases will haunt you throughout the entire test process. Comparing test results, reporting on several test rounds, etc. Are essentially determined by the quality of your test cases.
If you are already running out of time to design, but still want to start testing, make sure you have at least defined the main risks. If 10 testers must review 5 test cases with 1 test step, this will result into 50 test results. No matter what these 50 results give more information about quality then doing nothing. This will probably not be exhaustive, but it’s a first step. From thereon, the level of detail of certain parts can be determined.
We prefer that you think well in advance about how the test should be designed, and that the results of the test give a real answer to the objective. But in reality this is sometimes unruly.
Naming test cases is important. In an average ERP test you easily have more than 500 test cases. You will understand that a logical name structure enhances findability. In the literature is often referred to as a complete as possible name, in which the to be tested process, module, object etc. Are all included in the name. You can imagine that providing 500 test cases with such a complete title gives a chaotic administration. With a simple Excel sheet, you easily loose overview. Test management tools provide a structure to which you can relate test cases to reusable objects, without them “polluting” the name. You also have test registration tools that organize these relationships in a different way.
Within TestMonitor for example we invented a different solution. In the tool you can define labels or tags that you then can link to test cases. Within TestMonitor the test cases are linked to one or multiple business process-, risk-, requirement- or application labels. This allows test cases to be grouped and retrieved from different perspectives.
For the name of a test case within TestMonitor it suffices with a clear description of the purpose of the test case. To make it simple you describe an activity with an implicit expectation.
Example test case name:
“Termination of lease – independent home”
“Create customer” “Provisional booking receipt”
Example of test case “Provisional booking receipt” which is linked to several labels:
It’s important to describe the expected result per test case. The tester then knows in which direction the “answer” needs to be and directly gets an explicit testing framework.
As described in the definition test cases are a collection of test instructions that help us discover information to achieve a particular goal.
A test case must have a clear beginning and end to determine whether the test case passed or failed. In addition, a test case is composed out of one or more test instructions or -steps, wherein there are multiple paths possible in order to achieve the desired result. Only testing the path of success is often insufficient. In certain situations following non-success paths can just make the difference.
It is important to define test steps as clearly as possible so that the end-user for a user acceptance test knows exactly what they have to do. Of course, there are pre-conditions to come up with, like functional level tester, knowledge of the new system, knowledge of the possible adjusted business processes, etc. But in essence everyone should understand all the test steps.
Suppose we further describe the test case “Lease termination – independent home” for a simple success path:
What do you notice?
In the above mentioned example, the assumption is made that a specialist from a particular field will evaluate the test step. And because he or she is a specialist, no input conditions are given or explicit expectations outlined, because the specialist still has his own case studies up his sleeve and his expectations are crystal clear.
Should you currently not have a specialist, you can expand the test steps with input conditions and explicit expectations.
For example test step 1 at the test case “Termination of lease – independent home” with more details.
We regularly come across test projects where >50 test step are assigned to one test case. This is too much for a few reasons:
Beside that you also have test registration tools that can present the test cases in various forms to the tester. TestMonitor for example has two different view. TestMonitor has a display which shows all test steps separately per page and a display in which the test cases are presented per page including all test steps.The advantage of the first display is that each tester can obtain more information for each test step. The disadvantage in case the tester is more experienced he has to click on “next” every time he wants to proceed to the next test step. In the other view for each test case the advantages and disadvantages are vice versa.
In practice, we regularly see test scripts prepared by the programmers of the software supplier. When reviewing these test scripts by the eventual testers, there usually are more questions than answers. Conversely, this works the same for test scripts prepared by their own employee’s. It gives a real added value reviewing these by the software supplier. They look at the completed test scripts with different eyes and always come up with meaningful additions or modifications.
With a little bit of brainstorming with the software supplier specialists and the client organization you quickly get focus on the essence of what needs to be tested. Then take the time to consider the test cases, non-success scenarios and you will see that your test model is rapidly becomes more extensive and detailed. Besides that, you get more information about the quality then you deemed possible.
Beside that make use of a professional test platform and make quality really insightful. Request a free trial of TestMonitor today and see and experience the difference for yourself.