Software quality is an subject that has become more prominent in the software development industry over time because companies have placed more importance on offering quality products to different types of customers in the market. Nowadays software vendors place more attention on software testing and thus invests and puts more effort into planning and test cases.
Test cases are nothing more than the individual parts of a test plan designed to ensure the quality of the software during the process of elaboration, development and implementation of a project. These parts or individual processes in turn are composed of conditions or variables that are defined and based upon the initial requirements of the project, which is to say, you should clearly understand the purpose of the software.
Now, how to get test cases? You should initially count on a test plan, where its design and development will depend on the methodology used to carry out the development of the project, there may be user history, case usage, among others. However, the important thing is to keep in mind that the main source of any of these methods is to have good documentation on the purpose of the project and establish a clear relationship between expected results and initial requirements.
Once this relationship is understood, the overall structure of the process will be established and will then proceed to divide this process into several sub-processes consequently obtaining the information necessary for the definition of the different test cases that will allow structured evaluation of the functionality of the project.
Based on this, the following question arises, how do you make a test case? Below is an example of how to build a test case as a starting point for a user history:
Example of a user history:
Structure of a test case:
- Project name: name of the application.
- Test environment: Web version or desktop.
- Test case author: name of the analyst who designed the test case.
- Test Case ID: number that identifies the test case
- History ID of the User: number that identifies the history of user who makes reference to the case.
- Purpose: What is the purpose of the test case.
- #: No. of the action.
- Actions: steps to follow to verify the case.
- Expected output: result expected according to initial requirements.
- Obtained output: results obtained.
- Result: approved / in progress / rejected
- Follow-up: Action code where the result was not expected.
- Severity: the degree of failure.
- Evidence: support that the results are correct.
- Approved by: name of the analyst who performed the test.
- Revision date: date on which testing was performed.
Example of a test case
As you can see, structuring a test case is quite simple when you have the information necessary for its development, becoming a tool of great help in the registration, control and monitoring of different aspects to consider when checking a software.
It is also an excellent support when it comes to returning cases to developers to apply corrections or to implement changes if expected results are obtained.
Also having test cases facilitates when you want to compare or evaluate the changes that have suffered the initial requirements of the customer over time, this tracking allows you to verify that results are consistent with what has been requested, and as a result obtaining the satisfaction of the client and making them our main ally in ensuring the quality of the software.