test-case-training3002

Manual Test Script

Mainframe Solutions Contemporary Technology Solutions Business Process Outsourcing

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 100Boundary + 1 = 101Boundary Value = 100Boundary – 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 15Invalid Below the Partition = 8Valid In the Partition = 12Outside 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

Types of Test Cases Notations

System Test Case ST

Integration Test Case IT

Performance Test Case PT

Module Name Sub Module Name Notation

BackOffice BO

Administration BO_ADM

Reports BO_RPT

Subagent SA

Accounts SA_ACT


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.

Defect ID of a Scenario/Test Case should match the Defect ID submitted against that defect in Defect Tracking System/Excel file.

Traceable - to a requirement


Test Case Review Check List

All the test cases should reviewed at least once and checklist should be filled by respective person.

General Points of a Review Check List:

• Test cases follow agreed standard format.

• The Test cases are complete with respect to the Specifications Document on which they are based.

• Test data is mentioned explicitly for each test condition.

• 'Expected result' section of each test case is complete

• Pre-conditions for executing a test case or a set of test cases are specified.

• It is specified which test cases are to be executed together (or in a specific order).

• Test cases cover the entire functionality of the integrated module.

• There are test cases for checking the integrity of the global variables or database being accessed.

• Test cases follow the order of integration as defined in the HLD document or test plan.


Best Practices

Q/AThank you

test-case-training3002

Documents

test process

test group

test case whats

test conditionssetup

positive test case

possible test case

testing strategy test

software project test