A guide on how to go about test case development

A Guide On How To Go About Test Case Development ?

In this testing related blog, we will talk about software test case development. It is an important aspect of this domain and forms a core part of software testing. Enroll for a software testing course in Pune to start a career in this field.

Before beginning with the test case development process, it is important to understand what a test case is basically.

What is a test case?

A test case is a generally utilized term for a particular test. This is typically the most basic and smallest unit of testing. A Test Case will comprise of data, for example, requirements testing, test steps, prerequisites, verification steps, test environment, outputs and so forth.

Organizations take an assortment of ways to deal with reporting test cases; these extent from creating nitty gritty, formula like strides to composing general depictions. In detailed test cases, the steps portray precisely how to play out the test. In descriptive test cases, the tester chooses at the time of the test how to play out the test and what information to utilize.

Below mentioned are the steps to develop test cases: 1. Study of the system under question: Before writing down test cases, it is critical to have a detailed knowledge about the software which you are testing. It can be any application or any site or any product. Attempt and get however much data as could reasonably be expected through accessible documentation, for example, prerequisite specs, use cases, user guides, instructional exercises, or by having hands on the product itself.

Assemble all the conceivable positive scenarios furthermore the odd cases which may break the software Destructive testing, e.g. stress testing, exceptional blends of inputs and so on.

2. Use simple language: While writing a test case, it is exceptionally prescribed to write in a basic and comprehensible language. It is similarly vital to write your steps to the point and exact.

Exact and predictable names for e.g. of forms, or fields under test must be utilized to maintain a strategic distance from vagueness.

3. Test case template design: Let us take a look at the basic design of a test case template. It appears somewhat like this: 

Test case ID:

On the off chance that we are presenting test case for a general application which doesn't have a place with a particular module then ID would begin as TC001.

On the off chance that we are writing test cases for a module particular system then ID would begin from MC001 and so on.....

Thusly we can keep up all the test case IDs and if in future any prerequisite gets changed or included then we can simply include new test cases taking after the standard guidelines without changing the test case IDs of beforehand composed test cases. 

Test case name:

The primary benefit of keeping up this field is, if a prerequisite gets changed in future then we can undoubtedly gauge what number of test cases that change will influence and we change/remove the comparing test cases in like manner. 

Description:

This field has the outline what particular test case is going to do. It clarifies what attribute is under test and under what condition. E.g. On the off chance that a text box is under test, which permits just number and letters in order then portrayal can be composed as "Random special characters (@, #, %,$,^,*) are entered", in the event that we need to test a negative situation. 

Pre-conditions/pre-requisites:

At the point when the system should be in a specific base state for the function to be tested, these pre conditions ought to be defined clearly.

Pre-conditions ought to be fulfilled before the test case execution begins. 

Execution steps:

These are the steps to be executed on the system under test to get the sought results. Steps must be characterized clearly and must be precise. They are written and executed serially. 

Expected results:

These are the coveted results from the execution steps performed. Expected results ought to be unmistakably defined for every step. It indicates what the specification or customer anticipates from that specific action. 

Actual results:

This field has the actual results after the execution steps were performed on the product under test. In the event that the outcomes match with the expected ones then we can simply mention "As expected", else we have to specified the exact result watched. 

Status:

This field can have values like failed , passed , not applicable etc. based on the actual result. 

Comments: This field is meant for remarks and other additional information related to the test case.

To conclude: Test case development colossally relies on upon the involvement with the system under test. On the off chance that tester is acquainted with the software, he can compose more compelling test cases.

Test cases ought not be needy just on the requirements given by the customer, it is similarly critical to think from a client point of view while writing test cases.

This blog would prove to be useful for you to develop test cases. For learning more, go to a software testing institute in Pune.