Test Case Training

Manual Test Script

Agenda

Software Testing - Introduction

Testing Techniques and Testing Strategy

Test Plan and Test Case

Test Case design Techniques

Test Case Format

Integration Test Cases

Guidelines for Test Cases

Improving testability

Test case review check list

Q/A

Introduction

What is Software Testing?

Software testing is a process of analyzing or operating software for the purpose of finding bugs

The word “process” is used to emphasize that testing involves planned, orderly activities

Testing cannot show the absence of defects, it can only show that software defects are present

Why is Software Testing Required?

To find defects

To ensure that it meets user requirements

To reduce cost of quality by delivering defect free product

To achieve customer satisfaction

Continuously improving test process

Reduce risk of software failure

To determine the state of software

Testing Techniques

Testing Techniques

Black - Box Testing In using this strategy, the tester views the program as a black - box, tester doesn't see the code of the program: Equivalence partitioning, Boundary - value analysis, Error guessing, AdHoc Approach.

White - Box Testing In using this strategy, the tester examine the internal structure of the program: Statement coverage, Decision coverage, condition coverage, Decision/Condition coverage, Multiple - condition coverage

Test Plan and Test Case

What's a 'test plan'?

A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it

What's a 'test case'?

A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results

Note that the process of developing test cases can help find problems in the requirements or design of an application, since it requires completely thinking through the operation of the application. For this reason, it's useful to prepare test cases early in the development cycle if possible

Test Case can be of Two type I.e. Positive Test case and Negative Test Case

Test Case Design Techniques

Boundary Value Analysis - A data selection technique in which test data is chosen from the “boundaries” of the input or output domain classes data structures and procedure parameters. Choices often include the actual minimum and maximum boundary values the maximum value plus or minus one and the minimum value plus or minus one

Boundary Value Analysis: If Valid Input is 100

Boundary + 1 = 101

Boundary Value = 100

Boundary – 1= 99

Equivalence partitioning – Divide the input domain into classes of data for which test cases can be generated. Attempting to uncover classes of errors. Based on equivalence classes for input conditions. An equivalence class represents a set of valid or invalid states An input condition is either a specific numeric value, range of values, a set of related values, or a Boolean condition. Equivalence classes can be defined by:

Equivalence Partitioning: If Valid Input is in the Range of 10 and 15

Invalid Below the Partition = 8

Valid In the Partition = 12

Outside of the Partition = 18

Error Guessing - Its testers experience to test the functionality creating such a data which may cause failure. – Feb 29, 2001

Boundary value analysis and equivalence partitioning are inevitably linked together

Test Case Format Test Case and Test Scenario Format

Integration Testing

Integration testing is the most crucial steps in Software Development Life Cycle. Different components are integrated together and tested. This can be a daunting task in enterprise applications where diverse teams build different modules and components.

Prerequisites for Integration Testing

Before we begin Integration Testing it is important that all the components have been successfully unit tested.

Integration Testing Steps

Integration Testing typically involves the following Steps: Step 1: Create a Test Plan. Step 2: Create Test Cases and Test Data. Step 3: Once the components have been integrated execute the test cases. Step 4: Fix the bugs if any and retest the code. Step 5: Repeat the test cycle until the components have been successfully integrated.

How to write an Integration Test Case?

Simply put, a Test Case describes exactly how the test should be carried out. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.

So the Integration Test cases should typically focus on scenarios where one component is being called from another. Also the overall application functionality should be tested to make sure the app works when the different components are brought together.

The various Integration Test Cases clubbed together form an Integration Test Suite Each suite may have a particular focus. In other words different Test Suites may be created to focus on different areas of the application.

Integration Test Cases should be as detailed as possible.

Integration test case should include Name of Main Module , Name of Sub Module and Respective Dependency , Name of Function which is calling or get called , name of Database tables which will get affected after Saving offshore.

Guidelines For Writing Manual Test Cases/Scenarios

Guidelines For Writing Manual Test Cases/Scenarios

The First component in the Scenario/Test Case ID should be the type of testing for which the Scenario/Test Case is being written.

The Second component in the Scenario/Test Case ID should be Module Name/ Module Name–Sub Module Name

PT Performance Test Case IT Integration Test Case ST System Test Case Notations Types of Test Cases SA_ACT Accounts SA Subagent BO_RPT Reports BO_ADM Administration BO BackOffice Sub Module Name Notation Module Name

Improving Testability - Language

Testability = easy to test

Use active case, do this, do that

System displays this, does that

Simple, conversational language

Exact, consistent names of fields, not generic

Don’t explain Windows basics

10-15 steps or less. In the case of integration test case’s try to provide references instead of explaining the functionality again and again.

Always updated your test cases along with new build.

Always maintain a Data table.

Object Naming Conventions

Module Names should be in all capitals and bold. E.g. to mention BackOffice Module in the Scenario/Test Case, usage should be “BACKOFFICE”.

Screen Names should be bold and have Camel Notation, i.e. the first letter of the word in Capitals and rest in Small letters. If there are multiple words in the screen name, then the 1st letter of all the words should be in Capitals and the rest of the word in small letters.

i.e. for Agent Detail screen name will be “Agent Details”

All the objects like Text Box, List Box, Check Box, Radio Button, Combo Box names should be in italics and bold.

i.e. Login Text box should be mentioned as Login .

The Link Names should be mentioned with an Italics, bold and underline below the word.

i.e. Sign out link will be named as Sign Out .

Database table name should be in Caps

I.e. for Emp_Detail table name will be EMP_DETAIL

General Guidelines

All the Scenario/Test Case should be easily understandable, clear, concise and to the point.

The pre-requisite for the Scenario/Test Case should be mentioned before the test cases.

The Scenario/Test Case for different module should be maintained in a single Worksheet in an Excel File. The Name of the Excel File should be -

TypeOfTesting_ModuleName.xls I.e. ST_BackOffice.xls

Whenever new Scenario/Test Case is been added in between two existing one it should be named after the previous Scenario/Test ID with decimal places.

I.e. If we have to add new Scenario in between scenario ID ST-SA-BKG-0015 and ST-SA-BKG-0016, then new scenario id will be ID ST-SA-BKG-0015.1 and so on.