Creation of a clear test case is quite challenging because it forms the entire testing and serves as a guide. Since a test case stipulates a basis of future testing, it has to be meaningful to provide the strategy of testing.
Let’s define the origins of a test case and its nature. A test case is a set of input data, conditions and expected results, designed to verify the stated product properties. Test cases, assembled in particular order to achieve some goal form a test suite.
Project managers and team leads [1]have to specify the input data, execution conditions, testing procedure, and expected results to define how the test must be performed. He also should know the practical side of how to write test cases. A test case is a tool for the team lead to direct the team for achieving a specific software testing goal. For example, performing a specific program path or examination of compliance with a specific requirement needs a proper test case. That is why a test case must be clear both for the project manager and each particular tester.
Watch the differences
To avoid the misunderstandings at the stage of test case creation, you need to be well aware of issues which may intervene a proper composition of the test case (basing on sample test cases):
Do not confuse the checklist and test case. The difference between a test case and a checklist is that the checklist is just an idea of the future test, and the test case, as mentioned above, is a set of data and expected results. Often, a checklist becomes a good start for the Test description attribute in a test case.
Watch the difference between the test plan and test case. The test plan is a fundamental document that describes various aspects of the testing process. The test case, in its turn, includes the input data and parameters.
Test script and test case also differ. A test scenario is a set of tests (test cases), assembled in sequence to achieve some goal. Good test scripts and test cases in it always describe a certain logic, for example, typical use of the application, ease of testing, distribution of functions across modules, etc.
The key test case attributes
A test case has its common attributes, which allow recognizing the peculiarities of each module:
ID is a unique identifier which is often generated automatically[2]. If it is assigned manually, it is advisable to make it meaningful to understand the purpose of a test case clearly.
Priority (priority test case) – an attribute that indicates the priority of the TC, and takes the value according to the company’s classification (A-B-C-D-E, High-Medium-Low, etc.).
Version – version of a test case, which is specified automatically.
Req. ID – an attribute indicating the test item associated with the test.
Module – this indicates the module associated with the test case.
Sub-Module – similar to the previous item, only the smaller structural unit fits in.
Type – to verify functionality, interface, usability or intended for automation.
Test description (description of test cases) – an important attribute, which specifies the title (the essence of the test), the conditions for its implementation, steps and actions before/during/after passing the test. Test description, respectively, can and should contain precondition (preparative steps for setting the program and testing environment), steps, postcondition.
Expected result (expected results of the test case) – reflects the expected result for each step and proper reaction of the program to these steps. It should be meaningful, clear and simple.
Result – data about the result of the passed test is entered here (passed/failed, etc.).
Created on…by/Last modified…by – date of creation and name of the creator/last amendments and modifications and name of operator. Automatically specified.
Comment – here you can make your notes to the test (questions to the customer, any observations or details).
Add attachment – attached file, comment or srсeenshot.
Here is a test case example for your review:
How to monitor a proper preparation of test case
A test case also has its attributes of proper preparation, as each element of testing. Here are the tips from QATestLab on how to succeed in test case creation (we consider test case example for manual testing):
Find problem areas in the requirements. If the requirement is not clear and not testable, then writing a test case will manifest it. However, here you need to be extremely responsible, you can not copy-paste the requirements in the TC.
Structure all information. Logic and structure will give you more chances to spend less time understanding the test document itself (one will flow from the other). Cases based on the detailed and full requirements allow you not to search for where this information is taken from.
Accelerate the regression. To conduct a qualitative regression, you must select the correct test cases, high-level test cases, etc. In addition, test cases should contain a maximum of supporting information: logins, passwords to save time.
Store and collect information. All complex settings should be described in test cases (logins, passwords, field validation, certificates, card data, etc.). You can always attach additional files to cases with the necessary info or even some important letter.
Track the testing process. Here it is important to note that one cell of the test case is equal to one test, to set the status clearly and without problems. You can create statistics (passed / not passed, not tested).
Test case creation and management. Summary.
Test cases, a test plan, and its test strategy can be used as a source of information for the following projects. In addition to the above, case testing helps to meet customer requirements[3]. Often the customer checks cases, sometimes not, but in general, most projects should have case studies. The systematic approach of test case creation is a warranty of proper test case, which is the aim not only of testers but of the team leads at the same time. Project managers are responsible to provide as much information, requirements, and expectations, as possible before composing test case and control the procedure of its creation and further use.