In financial services, it is called the "maker-checker process" In risk management, it is popularly known as the "4 eyes principle" In US nuclear weapons management, it is called the "two person concept"
Essentially, they all do the same thing: these processes include an additional level of assessment, confirmation, authorization or approval to ensure the accuracy, quality or relevance of the result.
In software development, this is called testing or quality assurance. Simply put, software testing evaluates code to ensure it works as expected. To perform this activity effectively, quality teams use a powerful tool called a test case.
In this blog post, we explore what it is, why it is needed, when to use it, and most importantly, how to write test cases.
What is a test case?
A test case is a set of actions, conditions, and input data used to evaluate the quality of a software application.
Suppose you have created a form to spain number data capture the user's name and email ID for newsletter subscription. Your test case will specify the following:
Actions [both user-facing and internal] : Anything that the user or the software is expected to do to complete the workflow in the software being built.
Conditions : The requirements that the user or system is expected to meet when performing its actions.
Save if name field validation is accepted, otherwise show error message
Input data : Samples of what is acceptable input to the function. QA teams typically create test data that allows for checking positive and negative results.
For example, if a condition for validation of a name field is "can only contain letters of the alphabet and spaces", the test data would be as follows
The test case method is a comprehensive, systematic, and repeatable approach to software testing. While its primary goal is to ensure application quality, it adds multiple levels of robustness and reliability to the software engineering process itself.
Balance the bigger picture : A new feature may work well in isolation. But when integrated into the rest of the software, it could break or cause some other feature to break. Test cases ensure this is caught before it impacts the user experience in production.
Can a test case do all of the above? Not really. Depending on the function, software, systems, needs, and goals of the organization, QA teams write various types of test cases.
Types of test cases
There is a test case for every type of software testing . Some of the most commonly used ones are as follows.
Functionality Test Case : This basic and fundamental test case evaluates whether a software works as expected. At a minimum, all QA managers write this test case.
Unit Test Cases : Unit tests evaluate a portion of functionality or a single unit. For example, a QA might write unit tests to verify that the email address field meets various conditions.
Security Test Cases : The feature is assessed for compliance with security standards to be released to production. Typically this would include testing for authorization, authentication, compliance with OWASP standards, etc.
Performance Test Cases : Validate that the new feature meets speed, reliability, scalability, and resource utilization requirements.
Regression Test Cases : Regression testing ensures that the new feature you have developed does not affect any of the existing features in the product.
In addition to these, specific test cases can also be run. For example, design-oriented organizations may include user interface test cases. Products that are part of a larger workflow may write many integration tests. Others may create specific usability test cases on heuristics, accessibility, inclusion, etc.