Test Cases in Software Testing
A test case is nothing but, set of conditions or variables which can be used by the tester to determine whether the software is performing all the functions and giving the expected output.
A test case may be either human generated or machine generated. It can be a simple variable or complex relational data based on the type of software tested. A test case is mandatory and is a sensitive element during the entire period of the development of the software.
Since the software is released just after it is satisfying the demands as per the test cases.
Therefore, it is very much necessary to develop the test case in the same way as if the test case is the exact conditions or the input which is the same as the real world data when the software is launched in the real world environment.
In the process of developing the test case, it is also relevant for finding the problems in our functional and the non-functional requirements.
Therefore, to make sure that the test case is suitable and is maintaining all the standards of the testing, and satisfying the testing criteria. It is necessary to have a standard and internationally accepted template, which will make sure that the test case contains all the required parameters.
A test case contains the following attributes which make it an accepted test case. However, with the rise of the different testing tool, it has become a bit harder to follow the same template all over the world, but the majority of the template parameters are same for all levels of tester and testing software.
Let us see some major attributes in the test case template:
- Test suite ID: This is the ID of the test suite, to which the test case belongs.
- Test case ID: This is the ID of the test case.
- Summary of the test case: This contains the summary of the test case:
- Requirements: It says whether different setups or plugins are required to run the test case.
- Test Procedure: This is a step by step guide, for using the test cases and run it.
- Prerequisites: It is all about the requirements for the initiation of the testing.
- Test Data: It is the main test data, that is the data which will be input to the software.
- Result expected: This is the set of the result which is expected from the test case.
- Actual result: This is the actual result or the output behavior of the software after using the test case.
- Status: This the status of the test, here it is reported whether the test case has failed or succeeded. etc.
- Remarks: Any extra comments after the test are being performed or after the test has been performed.
- The developer of the test case: This contains the name of the developer of the test case.
- Creation Date: This the creation of the test case date.
- Executed by : This is the name of the lead or the main person by whom the test has been performed.
- An environment of Testing: This is the platform or the operating system inside which the test has been performed.
The test case sample may look like this:
Example of a ready-made test case template:
- Test suite ID: TS01
- Test case ID: TC01
- Summary of the test case: To verify whether the input of the PIN opens the account.
- Requirements: RS460
- Test Procedure: (a) Select option (b) Click on my account (c) Enter the pin (d) See the account details.
- Prerequisites: (a) Account holder is registered. (2) Data visibility is on.
- Test Data: PIN number.
- Result expected: This is expected that the appropriate account is opened after the validation of the PIN.
- Actual result: As expected, the account is displayed on entering the actual PIN.
- Status : Success.
- Remarks: The test case and the procedures were fine.
- The developer of the test case: Lary Paige
- Creation Date: 23/01/2019
- Executed by: Henry Lok
- The environment of Testing : Windows 2013.
The filled sample test case will look like this:
The Process of White box Testing
Test cases can be either a good or bad test case. We must follow some procedures to make our test case a good one. If a good test case is not written or developed then the actual performance of the software is underestimated.
The test case should be written in such a way, that the test case should aim at invoking some particular set of modules and not the overlapping modules. Test case for the system testing can be done in that case, if testing of all the interconnected modules is required.
But at the best, the test case which confuses the software should be avoided, by using test case to aim at a particular set of modules only.
To the extent of possibility, test cases should be atomic, that we test one execution path and at the time and not trying to overlap the entire module to make a mess.
We should keep in mind that all the positive and the negative scenarios are included in the test cases. So, unbiased testing can be carried out. And this will reduce the risk of losing the reputation of the software.
The format of the test cases should be well understood by the testers as well as the person who is new to the testing job. The language of the test cases should be easy to understand and also easy to be converted to modified test cases.
We must not make more uses of passive voices, rather it is advisable for any testing system, that active voices should be used.
There are even more characteristics for a test case to be a good test case:
- It should be accurate, that is the accurate purpose of the testing should be reflected in the test case.
- It should be economical, meaning that extra steps or non-relevant steps should be removed from the test case.
- It should be made repeatable, in the sense that, the test case must be formatted or designed in such a way, that it should be used over and over again.
- It should be reusable, in the sense that, the test case may be a recorder or saved when it can be used in future or even if the test case has remarkable efficiency, then it may be used to deploy in software which is under development.
- It should be capable of being traced, meaning that when test cases are input in the software, it should be traceable, as for how the test case is performing in the intermediate steps.
Good Practices for writing test cases:
- Test cases are needed to be simple and transparent, meaning that it should be easy to understand. But it should not be too simple, neither it should too complex. it should be so clear that as the creator of the test case will be not the one always to execute them.
- Test cases are must be concise and must use assertive sentences. Like very clear and simple words for the steps to be followed. For example, cancel, exit, etc.
- The test cases should be created while keeping the naive or the end user in mind. As the final goal of using the test case is to meet the requirements of the customer or the business enterprise. A tester or anyone developing the test cases must create the test cases from the user perspective.
- The Test case repetition must be avoided, if repeat is needed, then it can be called using its Test case ID, in the preconditioned column while testing itself.
- We should ensure 100% coverage of the functionalities of the entire system or the software. We may use the traceability matrix to trace or see how much or how many numbers of functionalities are being covered.
- We must not assume any functionality in the system without knowing them, rather we must rely on the specification documents if required at any point of time.
- The test case should be assigned with a unique ID so that, it is identifiable. As stated already that, no repetition of the test case is allowed, therefore if required, then, the entire test case can be simply referred to using the test case ID.
- This has to be kept in mind, any software cannot be tested for all the possible conditions where the software may not work fine. Therefore, it's our duty to design to create test cases in such a way, that there is a maximum possibility of finding defects with one test case only.
- The test case has to be designed in such a way, that during the test also, the system maintains a state of being recovered and brought back to the normal state. To do this, the testing state should have the way in it itself.
- Test result must not generate a different test result, from time to time, in one software. Whoever is going to perform it, the test case always should maintain a consistency about its results.
- A review must be taken from different experts while showing them the specification documents and the test case that has been developed.
Few tips to write a good test case:
- Testing only one thing at a time will make better use of the test case, that is one functional requirement at a time.
- We should always aim at writing independent test cases, that our test case should be able to run our test case without having to rely or depend on other test case or plugins or any other software.
- Practicing writing small test cases is a good practice, because a small test case is easily remembered and understood by different testers or the testing software may iterate it if needed without much difficulty.
- The complications of the test case should not be that much higher, at the same time, it should not be that less.
- The test case should be written from the user perspective who has a normal intelligence level.
- The test case should contain all the possible attributes, inside it so that in case of a failure, it can be identified, which part of the test case is causing the problem and whether the part can be eliminated or can be modified keeping the whole test case intact.
- The test case should be complying with all the regulation and guidelines prescribed by the tool which is going to test the software.
- The steps which may seem non-understandable to the normal persons, should not be just eliminated, instead, they should be converted with simpler and understandable sentences or logic which would perform the similar way.
Black Box Testing
A test case is nothing but, a set of inputs designed in such a way that the execution of those checks the entire software. A test case is designed based on real-life scenarios and users behavior.
A test case is a backbone of testing any software. There are different kinds of testings, starting from the functional testing to the non-functional testing. Also from the white box to the black box testing. A test case is designed for each and every possible testing phases, the software could go through.
A test case has a template or a format in which it is made and that format is followed along with the duration of the testing process.