Test case Summary rules

A test case is a professional documentation of a tester, as well as a sequence of actions aimed at checking some functionality, describing how to cause an actual result. 

A test case can also be understood as a corresponding document providing a formal test case record.

Also the test cases are subdivided into: 

• high level test case - a test case without a specific input data and expected results. 

As a rule, such a test case is limited to general ideas and options, which is similar in its essence to the detailed item of a checklist. It is quite often found in the integration and system testing, as well as on the level of smoke testing. It can serve as a starting point for exploratory testing or for creating low-level test cases.

• low level test case - a test case with a specific input data and expected results. 

It is a completely «ready to run» test case and is the basic type of test case. Beginner testers are most often taught to write such test cases, since it is much easier to write all the data in detail than to understand what information can be ignored without reducing the value of the test case.

In testing the word «case» should be translated as «situation» simply because a test case is a situation that needs to be created to test the work of one particular functionality. All the steps listed in the case make it possible to check one test situation, write one scenario for using the software.

A test case Summary - is a descriptive test name, which makes it easy to search and to understand its content.

The test case Summary should not contain:

1. Dependencies on the other test cases. The associated test case can always be removed due to not being unnecessary or it may be changed, and in such case it is not clear how to complete the test case, in which there are references. Also due to the dependence of the test case, there may be a feeling that the tested product will be at a desired state thanks to the completion of the related test cases. 
2. Unclear wording. If the Summary description is not clear, then it  will complicate the passing of the test case and the perception of the test suite as a whole.

While creating a test case Summary, you need to remember:

• something that is obvious to you now, may become completely incomprehensible in a couple of months. 

So, shortenings with undeciphered abbreviations that you understand now, may later become a Chinese literacy for you, so it will be easier to write a test case again than to wade through the jungle of carelessly made abbreviations both in the Summary and in the case. 

• the test case, the Summary of which cannot be understood and subsequently performed by no one except its author, must be publicly destroyed. 

The reason is simple, the author of the case can get sick, go on vacation, leave the company and so on. Any test case should be created with the thought about colleges in mind, who will use this case one day.

For example:

If the Summary is empty or there is simply written «10», then each person performing this test case, every time will spend a few minutes of his time and/or the time of his colleagues to find out what is checked by this test case.

3. Excessive detalization. Excessive information only makes it difficult to understand the meaning that is embedded in the topic.

While performing a test case, the tester first reads the topic, realizes it, roughly imagines what he will need to do now, and only after that, he moves to the steps. 

Example: 

Will it be convenient to check the test case if in the Summary says the following:

In this test case we check point specification 21.6  number 34 «Adding a credit card to a user account scenario»?

In addition, the test case name must be unique for the project and carry the description of the functionality under test. This is vital to simplify the search for the required case among hundreds and thousands of others on the project.

Skills that are required for writing test cases:

• The ability to split the system into its components (to perform a decomposition). It means, you need not only to be able to see the system as a whole, but also to be able to decompose it into its component parts. This is a really useful skill for functional testing, where every aspect of the product is tested. 
• The ability to collect and to analyze the product requirements. If there are no formally described requirements (specifications), you need to be able to collect them from the developers, analysts, users. 
• The ability to prioritize. The test designer must be able to distinguish something more important  from less important and also to prioritize testing. 
• The ability to formulate their thoughts (both written and oral). This skill is important for a tester in principle. It helps a test designer a lot when creating test cases. 
• The knowledge of a test design techniques as well as the ability to apply it in practice.

Important points when drawing up a test case:

The understanding the requirements for which the case is being compiled

It will not be possible to create and describe an effective test case, if there is no understanding of how exactly one or another functional of the program  should be implemented. It will be more efficient to spend time and effort clarifying inaccuracies and to write a «working» test case that to first compile an absolutely wrong one, to understand during testing that is not worked as it should, and again spend time on clarifications and only then completely redo it and get a working version.

Simplicity and the ease of understanding 

It is important for the test case to be described in understandable words without the use of special terminology and complex language constructions, since it can be passed by specialists of various skill levels and specializations (experienced and new testers, project managers, developers, analysts and even the the customer’s employees that are not always have a sufficient level of knowledge in computer technology).

Special attention to a test data sets 

If the test involves the use of any data, you should pay attention to the correctness of their compilation and subsequent indication. Otherwise, such a test is useless.

Basic mistakes when writing a test case Summary

Reading theory is one thing, doing it in practice is quite another. Usually, in theory everything is clear, but on practice, we get the following: 

«Test case #01. Creating a tenant.»

Try to find the problem areas in this test case by yourself, without looking at the answer. And then check yourself. 

Let’s analyze the case 01 errors.

Abstract name.

At first look, the name is good, short and understandable, after all we are really creating a tenant. But! If we create several more test cases for entering incorrect full names, they all will have the exact same name. 

As a result, a new tester, who received the task to check the case «Creating a tenant» will find two dozen checks with the same name in the system, will be confused and won’t know which one to choose? 

Always remember about «briefly but succinctly». By  the test case name a tester who knows the project must understand what to do without looking into steps, so we supplement the names: «Creating a tenant without a patronymic» «Creating a tenant with numbers in the «Name» field» etc.

Let’s correct the test case to all comments. 

«Test case #02. Creating a tenant with the correct name.»

That’s better, but can you improve this test case?  

Try again to find the problem areas in this test case, without looking at the answer. And then check yourself.

So, the case 02 errors: 

Abstract name.

The words «correct», «right» etc. in the test case Summary are the same marker as «error» in the name of the bug, such words should be avoided. 

You can think of at least a hundred positive checks, but how will they differ? The creation of a tenant who does not have a middle name is also a case with the correct full name. Only from such Summary it is immediately clear what the case is about. 

Therefore, forget about the words «correct, incorrect» etc. try to write it more clearly, always remember the principle «Brief, but succinctly». 

Also, dividing cases into semantic groups (negative/positive tests, tests for special cases), make a test case in the control system through flags or separate test cases.

Corrected version of the test case Summary:

«Test case #03. Creating a tenant with a full name.»

In this name version it is already clear that this test case will check the possibility of creating a tenant with all three attributes: last name, first name and patronymic.