#software techniques

Important Guidelines For Writing Test Cases

Test case writing is an important activity in software testing. Let us first define, what do you mean by a test case? before moving forward.

Definition:

A test case is a group or a set of actions that are executed by a tester, to check that a particular functionality or a feature of the software being tested is as expected or not.

Writing good test cases is an aptitude and that can be accomplished by some experience and in detail investigation of the application on which test cases are being written.

What is the need for writing test cases?

The essential aim of writing test cases is to validate the testing scope of the application. In the event that you are working in any CMMi level organization, then you will entirely take after standards about test cases. So, writing test cases brings some kind of institutionalization and minimizes the ad-hoc method in software testing.

Whether it be manual testing or automation testing, test cases are important. Without them, one cannot proceed further in the testing process. Selenium testing which is carried out using the Selenium automation tool, also has the facility to record test cases in it.

Here are the standard practices for writing effective test cases:

1. Write test cases keeping the end user in mind:

The main objective of any software project is to prepare test cases that meets client prerequisites and is anything but difficult to utilize and work on. A tester must write test cases remembering the end user point of view.

2. Make no assumption:

Try not to assume the functionality and features of your product application while writing test cases. Adhere to the Specification Documents.

3. Make use of testing techniques:

It’s impractical to check each conceivable condition in your software. Testing techniques help you select a couple test cases with the most extreme plausibility of finding a defect.

Boundary Value Analysis (BVA): As the name recommends, the method characterizes the testing of limits for indicated scope of values.

Equivalence Partition (EP): This method partitions the range into equivalent amounts of/groups that have a tendency to have the same behavior.

State Transition Technique: This strategy is utilized when software conduct changes starting with one state then onto the next after specific activity or action. Error Guessing Technique: This is speculating/foreseeing the defects that may emerge while testing. This is not a formal strategy and takes focal points of an tester’s involvement with the application.

4. Review From Peers:

Subsequent to writing test cases, get them checked by your partners or peers. Your companions can reveal imperfections in your test case design, which you may effortlessly miss.

5. Try to ensure 100% coverage:

Ensure you compose test cases to check all product prerequisites said in the requirement specification document. Use Traceability Matrix to guarantee no functionality/conditions are left untested.

6. Self Cleaning:

The test case you prepare must give back the test environment to the pre-test state and ought not render the test environment unusable. This is particularly valid for configuration testing.

7. Ensure that test case repetition does not happen:

Try not to repeat the test cases. In the event that a test case is required for executing some other test case, call the test case by its id in the pre-condition section.

Include below information while drafting a test case:

The current test case should be in correct business scenario order with other test cases. Active voice is recommended while writing a test case. Ideal length of a test case is up to 15 steps. Do not go beyond that. Attachments or proofs are required. Details of what requirement is currently under test. Details of how the system would be tested.

These are a few guidelines, as far as writing test cases is concerned.

This article would be helpful for student Software Testing reviews.

More Related Blogs:

Software Testing and Risk Analysis

Students are often confused between the verification and validation process, as far as Software Testing is concerned. Let us initially define both the processes

Verification:

Verification is nothing but the process of ensuring whether are we building the system right? It is checking whether the system, service or an application meets with a regulation, specification, requirement or an imposed condition. It is in contrast with the validation process and is an internal one.

Validation:

Validation is nothing but asking the question are we building the right system? Further speaking, it is an assurance that the system, service or application meets the needs of the customer and the stakeholders.

It is not very easy to tell the difference between the two. Let us take an illustration, so that we can understand it better.

You are testing one application. The system requirements state that there are two fields with maximum length of 64 characters and Save button as well. The Use case says that the User will fill in first and last name and click on the save button.

While checking the existence of the fields and the Save button, is verification. When you take after the use case, it is validation. With regards to testing, “Verification and Validation” are generally and usually utilized terms. The vast majority of the times, we consider the terms same, yet really the terms are very distinctive.

Here are a few more points of difference between the two:

Verification:

Verifies the intermediary products and stages to see whether it matches the specific requirements of that particular phase.

Checks whether the product is developed according to the predetermined requirements and design particulars.

Can be done without execution of the software.

Static methods are used.

e.g. reviews, walkthrough and inspection.

Validation:

Checks whether the end product meets the need of the business.

Answers the question as to whether the software or application is fit for usage and fulfills the business requirements.

The execution of software is necessary for doing validation.

Dynamic methods are used.

e.g. Types of Testing like regression, smoke etc. are involved over here.

The main aim behind carrying out the verification and validation process is as follows:

-Enables early finding and rectification of Defects.

-Supports and improves the management intervention and inside into procedure and product related risks.

-Give steady measures towards the product Life-Cycle Process, to improve consistence with schedule and budget prerequisites.

Maker’s perspective of quality, in less difficult terms implies the developers impression of the last item. Buyers perspective of quality means clients impression of the final product.

Validation is important to check whether the various data controls present on a page are accepting the desired data and giving the expected output.

When we do the V&V errands, we need to think both of these perspective of quality.

V&V processes figure out if results of a given activity affirm to requirements and are fit for its utilization. In an extremely less complex terms ( to maintain a strategic distance from any sort of perplexity), we simply recollect that Verification implies the review exercises or the static testing systems and validation implies the genuine test execution exercises or the dynamic Testing Methods.

To conclude:

Both these processes are an integral part of the testing process and happen to be very important. Imagine that we are unable to deliver that product which the customer expects. Then what is the use of investing so much time and money and efforts? To keep a check on the same, these techniques are used widely.

It is important for software testers to identify the difference between these two processes. So that, they can implement these whenever required during the testing process.

We will continue to explore more topics and concepts related to software testing.

More Related Blogs:

Cost Of Quality In Software