Test Cases-A Guiding light in QA

It is a well-known fact that each and every aspect of life needs a certain direction and path to follow. Saying that, a well-defined plan in place makes the tough tasks easier to perform. Following rules is a good way of life, which eventually shapes the course of events. In a nutshell, there has to be a guiding beacon to focus on for the better. Are you wondering why we are  discussing life in a testing-related article? This is just to set the tone for what is about to follow.

Testing is an integral part of the software development phase and requires a predefined process in place. Without a basic set of rules and strategies, testing is deemed inadequate. It is prudent to have a test plan in place for the test team to follow. A test plan is a formal document describing in detail, the scope, activities, timelines, test logistics, testing strategy, test cases etc for testing any software. It forms a fundamental basis for testing. Test cases help the testing team in executing the test plan defined for a module. People do refer the test cases as the “Bible for Software testing” or  “Source of Truth” which helps in an efficient testing process.

What is a Test Case?

Test cases are the step-by-step sequence a tester executes in order to validate that a piece of software is functioning as intended. It contains a set of test data, preconditions, expected results, and postconditions, developed for a particular test scenario, in order to verify compliance against a specific requirement.

However, the scope of test case is not limited to the above-mentioned fields. A typical test case might include the following elements:

• Test Case ID
• Test Scenario ID
• Test case Type (UI, API, Performance etc) 
• Test Case Summary
• Prerequisites/Pre-Condition
• Test Case Steps
• Test Data
• Expected Result
• Observed Result
• Status
• Comments

In the above image, you can see the use of various elements of a test case. It is indicative only and it is not necessary to use all the fields and follow the same order. It can be customized per the test process of the organization. In any case, the test cases should be written precisely and in a manner that even a non-technical person can read the instructions and follow them.

Characteristics of a Good Test Case

A test case can be called a good test case if it has characteristics described below:

• Accurate: Aligning to the purpose of testing.
• Simple: Simple and easy to understand with no complicated steps.
• Traceable: Should be traceable to requirements under test.
• Repeatable: Can be tested repeatedly with variety of inputs.
• Maintainable: Easy to be modified, if there is a change in requirements.

Guidelines for Writing a Good Test Case

There are few guidelines that can help in writing good comprehensive test cases.

• Write the test case in layman’s language, so that anyone reading it gets an idea of what  needs to be tested and how it can be tested.
• Always use simple terms that are more giving directions rather than requesting to perform an action. Like: Click on the button, Go to the <field name>, etc.
• Specify the exact names of the fields so that it is easy to locate on a page. For example, if a field’s name is “First Name”, it should not be referenced as “Name”.
• Specify the purpose of the test case clearly with the exact steps to follow, without any unnecessary information.
• Should be easily tracked with the requirement of the client. One can also include a column for the name of the feature or the user story for which the test case is written.
•  Classify Test Cases based on Business Scenarios and Functionality.
• Keep in mind all the pre conditions and assumptions.
• Specify post conditions and expected results.
• Assign priority to the test cases.
• Document and catalog with proper comments in place.
• Review the test case thoroughly before finally implementing in test plan.

By following the above-mentioned guidelines, it is easy to write a precise and instructional test case. Such test cases can be reused and easily modified in case there are any modifications done to the feature under test. 

Test case modifications are equally important as writing a fresh test case. This keeps the test plan updated as per the new changes.

When writing test cases, it’s important to select the correct style for the test case you are working on i.e To validate what the software is supposed to do OR To validate what it’s not supposed to do OR is the goal to see if the software breaks down at a certain point? All these 3 styles can be differentiated based on below categories of test cases:

• Positive test cases
• Negative test cases
• Destructive test cases+

A positive test case verifies that the application provides the intended output when the appropriate input is provided. The main purpose of this is to make sure the system isn’t throwing errors when it’s not supposed to. In general, positive testing ensures the system meets the requirements under positive scenarios and day-to-day use.

A negative test case verifies that the application does not do something which it is not supposed to do. The intent of negative testing is to ensure the system validates against invalid inputs by throwing errors or otherwise not allowing the system to perform in a certain away. 

The purpose of destructive test cases is to test what the system can handle until it breaks or “destructs”. Load testing and script injections are common approaches to destructive testing. 

These statements might seem to be confusing, so below are some examples that can help in better understanding.

Example of a Positive Test Case:

A user should be able to submit a form when all the required fields are filled with the information. 

• Password field should accept 5 characters
• Password field should accept a combination of letters & numbers

Example of a Negative Test Case: 

A user should not be able to submit a form if any of the required fields are left blank.

• Password field should not accept 1-4 characters
• Password field should not accept any characters outside of numbers or letter (!@#.. etc)

Example of a Destructive Test Case:

•  Applying a significant load to the system which results in a failure.
•  Injecting JavaScript into a web form with malicious intent

All these test cases must pass in order for the application to qualify as a quality product. A positive test case must pass because of the obvious reason, but a negative test case should also pass. A failed negative test case will mean that the application is doing something which it should not be doing and thus, will result in a faulty application. In case, the destructive test cases can help in improving the performance or efficiency of a system. 

By considering all angles of testing and writing positive, negative, and destructive test cases, your test coverage will be greater and your product will retain a higher level of quality.

Based on the status of these test cases, a tester can report bugs and during the retesting or regression testing, adhering to these test cases can reach a point where a tester can give a green signal for the product to be released for the public.

What Webomates has to Offer?

A perfect and comprehensive test cases is what we are capable of writing. Whenever we receive a product to be tested, we ensure that a proper and complete test suite is provided to all which helps in thorough coverage of the entire application. 

Webomates does all this with its  AI-powered, SAAS based testing tool, Webomates CQ. 

The regression service which uses these test cases, helps in improving the quality of product by providing a detailed triage report of all the test cases along with their pass and fail status so that the development team can work on the failed test cases and rectify the bugs in order to deliver a bug-free product. For more information on how Webomates work along with these test cases, contact us today and learn more about the wide range of our testing capabilities.

Tags: ad hoc testing, Negative Test case, Positive Test Case, Regression Testing, Software Testing Lifecycle