Test Planning Process and Test Case Development

Hi Webies Good Evening, in my previous article I have given the most common software errors

So now I am going to give you an overview about ‘Test Planning Process’ and ‘Test Case Development’.
It will help you to understand the testing process better.

The Test Planning Process

What is Test Strategy? And it’s Components?

Test Policy: Test Policy is a document characterizing the organization’s philosophy towards software
testing.

Test Strategy - A high-level document defining the test phases to be performed and the testing

within those phases for a program. It defines the process to be followed in each project. This

sets the standards for the processes, documents, activities etc. that should be followed for each

project.

For example, if a product is given for testing, you should decide if it is better to use black-box

testing or white-box testing and if you decide to use both, when will you apply each and to which

part of the software? All these details need to be specified in the Test Strategy.

Project Test Plan : a document defining the test phases to be performed and the testing within

those phases for a particular project.

A Test Strategy should cover more than one project and should address the following issues: An

approach to testing high risk areas first, Planning for testing, How to improve the process based

on previous testing, Environments/data used, Test management - Configuration management,

Problem management, What Metrics are followed, Will the tests be automated and if so which

tools will be used, What are the Testing Stages and Testing Methods, Post Testing Review

process, Templates.

Test planning needs to start as soon as the project requirements are known. The first document

that needs to be produced then is the Test Strategy/Testing Approach that sets the high level

approach for testing and covers all the other elements mentioned above.

Test Planning – Sample Structure

Once the approach is understood, a detailed test plan can be written. Usually, this test plan can

be written in different styles. Test plans can completely differ from project to project in the same

organization.

IEEE SOFTWARE TEST DOCUMENTATION Std 829-1998 - TEST PLAN

Purpose

To describe the scope, approach, resources, and schedule of the testing activities. To identify the

items being tested, the features to be tested, the testing tasks to be performed, the personnel

responsible for each task, and the risks associated with this plan.

OUTLINE

A test plan shall have the following structure:

• Test plan identifier. A unique identifier assign to the test plan.

• Introduction: Summarized the software items and features to be tested and the need for

them to be included.

• Test items: Identify the test items, their transmittal media which impact their

• Features to be tested

• Features not to be tested

• Approach

• Item pass/fail criteria

• Suspension criteria and resumption requirements

• Test deliverables

Testing tasks

• Environmental needs

• Responsibilities

• Staffing and training needs

• Schedule

• Risks and contingencies

• Approvals

Major Test Planning Tasks

Like any other process in software testing, the major tasks in test planning are to – Develop Test

Strategy, Critical Success Factors, Define Test Objectives, Identify Needed Test Resources, Plan

Test Environment, Define Test Procedures, Identify Functions To Be Tested, Identify Interfaces

With Other Systems or Components, Write Test Scripts, Define Test Cases, Design Test Data,

Build Test Matrix, Determine Test Schedules, Assemble Information, and Finalize the Plan

Next we need to develop the Test Cases

Test Case Development

A test case is a detailed procedure that fully tests a feature or an aspect of a feature. While the

test plan describes what to test, a test case describes how to perform a particular test. You need

to develop test cases for each test listed in the test plan.

General Guidelines

As a tester, the best way to determine the compliance of the software to requirements is by

designing effective test cases that provide a thorough test of a unit. Various test case design

techniques enable the testers to develop effective test cases. Besides, implementing the design

techniques, every tester needs to keep in mind general guidelines that will aid in test case

design:

a. The purpose of each test case is to run the test in the simplest way possible. [Suitable

techniques - Specification derived tests, Equivalence partitioning]

b. Concentrate initially on positive testing i.e. the test case should show that the software does

what it is intended to do. [Suitable techniques - Specification derived tests, Equivalence

partitioning, State-transition testing]

As a tester, the best way to determine the compliance of the software to requirements is by

designing effective test cases that provide a thorough test of a unit. Various test case design

techniques enable the testers to develop effective test cases. Besides, implementing the design

techniques, every tester needs to keep in mind general guidelines that will aid in test case

design:

a. The purpose of each test case is to run the test in the simplest way possible. [Suitable

techniques - Specification derived tests, Equivalence partitioning]

b. Concentrate initially on positive testing i.e. the test case should show that the software does

what it is intended to do. [Suitable techniques - Specification derived tests, Equivalence

partitioning, State-transition testing]

Test Case – Sample Structure

The manner in which a test case is depicted varies between organizations. Anyhow, many test

case templates are in the form of a table, for example, a 5-column table with fields:

Test Case ID

Test Case Description

Test Dependency/ Setup

Input Data Requirements/ Steps

Steps Expected Results

Pass/Fail

Test Case Design Techniques

The test case design techniques are broadly grouped into two categories: Black box techniques,

White box techniques and other techniques that do not fall under either category.

Black Box (Functional)	White Box (Structural)	Other
- Specification derived tests - Equivalence partitioning - Boundary Value Analysis - State-Transition Testing	- Branch Testing - Condition Testing - Data Definition - Use Testing - Internal boundary value   testing	- Error guessing

Specification Derived Tests

As the name suggests, test cases are designed by walking through the relevant specifications. It

is a positive test case design technique.

Equivalence Partitioning

 Equivalence partitioning is the process of taking all of the possible test values and placing them

into classes (partitions or groups). Test cases should be designed to test one value from each

class. Thereby, it uses fewest test cases to cover the maximum input requirements.

For example, if a program accepts integer values only from 1 to 10. The possible test cases for

such a program would be the range of all integers. In such a program, all integers upto to 0 and

above 10 will cause an error. So, it is reasonable to assume that if 11 will fail, all values above it

will fail and vice versa.

If an input condition is a range of values, let one valid equivalence class be the range (0 or 10 in

this example). Let the values below and above the range be two respective invalid equivalence

values (i.e. -1 and 11). Therefore, the above three partition values can be used as test cases for

the above example.

Boundary Value Analysis

This is a selection technique where the test data are chosen to lie along the boundaries of the

input domain or the output range. This technique is often called as stress testing and

incorporates a degree of negative testing in the test design by anticipating that errors will occur

at or around the partition boundaries.

For example, a field is required to accept amounts of money between $0 and $10. As a tester,

you need to check if it means up to and including $10 and $9.99 and if $10 is acceptable. So, the

boundary values are $0, $0.01, $9.99 and $10.

Now, the following tests can be executed. A negative value should be rejected, 0 should be

accepted (this is on the boundary), $0.01 and $9.99 should be accepted, null and $10 should be

rejected. In this way, it uses the same concept of partitions as equivalence partitioning.

State Transition Testing

As the name suggests, test cases are designed to test the transition between the states by

creating the events that cause the transition.

Branch Testing

In branch testing, test cases are designed to exercise control flow branches or decision points in a

unit. This is usually aimed at achieving a target level of Decision Coverage. Branch Coverage,

need to test both branches of IF and ELSE. All branches and compound conditions (e.g. loops and

array handling) within the branch should be exercised at least once.

Condition Testing

The object of condition testing is to design test cases to show that the individual components of

logical conditions and combinations of the individual components are correct. Test cases are

designed to test the individual elements of logical expressions, both within branch conditions and

within other expressions in a unit.

Data Definition – Use Testing

Data definition-use testing designs test cases to test pairs of data definitions and uses. Data

definition is anywhere that the value of a data item is set. Data use is anywhere that a data item

is read or used. The objective is to create test cases that will drive execution through paths

between specific definitions and uses.

Internal Boundary Value Testing

 In many cases, partitions and their boundaries can be identified from a functional specification for

 a unit, as described under equivalence partitioning and boundary value analysis above. However,

 a unit may also have internal boundary values that can only be identified from a structural

 specification.

Error Guessing

 It is a test case design technique where the testers use their experience to guess the possible

errors that might occur and design test cases accordingly to uncover them.

Using any or a combination of the above described test case design techniques; you can develop

effective test cases.

What is a Use Case?

A use case describes the system’s behavior under various conditions as it responds to a request

from one of the users. The user initiates an interaction with the system to accomplish some goal.

Different sequences of behavior, or scenarios, can unfold, depending on the particular requests

made and conditions surrounding the requests. The use case collects together those different

scenarios.

Use cases are popular largely because they tell coherent stories about how the system will

behave in use. The users of the system get to see just what this new system will be and get to

react early.

will give overview of Defect Tracking  and Types of Test Reports in my next post…
comments are welcome,  Good Night and Testing Dreams J JJ