MANUAL TESTING
TEST PLAN
After completion of Test Strategy Document, the strategy of the Project implemented by Test Lead in the Project through Test Plan.
During Test Plan Document preparation, Test Lead category people follows below approach.
a) Team Formation:
In general Test Plan Document preparation starts with Team formation. In this Test Lead category people form the Testing Team depending on below factors.
i. Project size.
ii. Project duration.
iii. Availability of domain testers.
iv. Resources (Automation Tools) b) Identify Risks
After completion of Team Formation the Test Lead identifies risks with respect to that formed testing team in Testing.
i. Lack of time.
ii. Lack of resources.
iii. Lack of communication.
iv. Lack of knowledge on project domain.
v. Lack of test data.
vi. Lack of development process rigor.
vii. Delays in delivery.
BRS
TRM
Development Plan
a) Team formation b) Identify risks c) Prepare Test Plan d) Review Test Plan
System Test Plan Module Test Plan
(if project is big then only Module Test Plan is to be prepared)
c) Prepare Test Plan
After completion of Team formation and Risk Analysis, Team Lead will prepare Test Plan Document in IEEE (Institute of Electrical &
Electronic Engineer) Format (829)
1) Test Plan ID 9) Exit Criteria
2) Introduction 10) Test deliverables 3) Test items 11) Test environment 4) Features to be tested 12) Staff & Training needs 5) Features not to be tested 13) Responsibilities
6) Test approach 14) Schedule
7) Entry criteria 15) Risks & Mitigations 8) Suspension Criteria 16) Approved by
1) Test Plan ID:
Unique number for feature reference.
2) Introduction
Introduction about the project or module.
3) Test items
The name of the requirements or features.
4) Features to be tested
The name of the requirements or features to be test.
5) Features not to be tested
The name of the requirements or features not to be test 6) Test approach
The list of selected quality factors to be applied by the Tester.
7) Entry criteria
When to start Testing
Î Take complete and correct Test cases.
Î Create Test Environment.
Î Receive Stable Build from the developers.
8) Suspension criteria
When to suspend testing temporarily Î When we have network problem.
Î If pending defects are more
9) Exit criteria
When to stop testing
Î After completion of all module testing.
Î After completion of all Major bugs resolved.
10) Test deliverables
The required documents to be prepared by the Testers.
Ex.: Test Scenarios, Test Cases, Test Scripts, Test Data, Test log, Defect Report, FSR ………… etc.,
11) Test environment
The required Software and Hardware to conduct Testing.
12) Staff and Training needs
The names of selected testers and their training needs.
13) Responsibilities
Work allocation to the testers.
Ex. Modules Vs. Testers.
14) Schedule
Time duration to the testers.
15) Risks and Mitigations
The required solutions for the previously analyzed risks.
16) Approved by
Who approved the document, the signature of the Project Manager.
Name of the Test Lead.
d) Review Test Plan:
Completion of Test Plan Document preparation, Test Lead is conducting Review Meeting to estimate completeness and correctness of that document.
During this review they will concentrate on below coverages.
(i) Requirements Based Coverage (What to Test?)
(ii) Risk Based Coverage (Who to Test & When to Test?) (iii) TRM Based Coverage (How to test?)
TEST SCENARIOS &TEST CASE DESIGN
After completion of Test Plan Document and corresponding Reviews Test Lad allocate the work to the Testers.
Testers are preparing corresponding Test Scenarios and Test Caes based on Requirement Specifications.
USE CASE
Use Case is a required document which maintenance the detail information about one low level requirement.
If you want to design Test Cases based on Use Cases, we can study the Use Case below approach.
USE CASE FORMAT: Title
Requirement Description Actors / Users
Pre-operation Action
Positive Flows
Exceptions / Negative flows
Alternative flows / Alternative Positive flows 1) Collect all Use Cases.
2) Take one Use Case and Study.
2.1) Identity Entry Point.
2.2) Identity Input Requirement 2.3) Identity Outputs
2.4) Identity Alternative flows and exceptions.
2.5) Identity exit point.
3) Prepare scenarios.
4) Review scenarios.
5) Prepare Test Cass with step by step procedure.
6) Continue from step (2) to (6) until completion of all Use Cases.
TEST SCENARIOS
Test Scenarios means Test situations.
Test Scenario Template
These templates are created in MS Excel.
Project Name:
Reviewed by Module Name:
Created by: Reviewed by
Created on:
Sl. No. Requirement Name Test Scenario Test Cases
TEST CASES
A set of Test steps documented along with required inputs and expected results in order to test one low level requirement.
Thinks to remember while designing the Test Cases.
1) Test Case should be simple and clear.
2) Test Case should be complete.
3) No duplicate Test Case should b written.
TEST CASE TYPE
1) User Interface Test Cases.
2) Usability Test Cases.
3) Validation Test Cases.
4) Functional Test Cases.
1) User Interface Test Cases
To verify the look and Feel of application build screens.
Ex: Font Size, Text alignment, Images etc., 2) Usability Test Cases
To verify ease of use of application build screens.
Ex:
a) Default cursor should be present at the first field.
b) Tab keys should be implemented for all input objects from left to right in downward direction.
c) Shortcut keys should be implemented for all menu operation.
d) Tool tips (Whenever we place the cursor on particular object, it should return meaningful message)
3) Validation Test Cases:
Test Cases that are required to validate business rules or field validation.
4) Functional Test Cases:
Test Cases that are required to validate the functionality.
TEST DESIGN TECHNIQUES
They are mainly (5) types of design techniques.
(1) Boundary Value Analysis (BVA) (2) ECP (Equal Class Partition) (3) Error Guessing
(4) Decision Tables (5) State transition.
(1) BVA:
It is used to validate the range of input objects.
(2) ECP:
Î Splitting the inputs into equal parts and randomly checking them.
Î To verify the type of input objects.
(3) Error Guessing
It is a technique which can be used by the people, who have prior knowledge on that application (Ex. This can be used by experts)
(4) Decision Tables
A Black Box Test Design testing in which test cases are designed to execute the combination of inputs.
(5) State Transition
A Black Box Test design techniques, in which test cases are designed to execute valid, invalid state transition.
Valid Invalid Valid Invalid Valid Valid Invalid Valid
Insert card
Wait for PIN Entry
1st Entry
2nd Entry
3rd Entry Block
Card
Access Account PIN Wrong
PIN Wrong
PIN Wrong
PIN Ok
PIN Ok
PIN Ok
TEST CASE TEMPLATE
Test Case Name / ID
Test Case
Description Priority Step Name
Step Description
Test Data
1 2 3 4 5 6
Expected Results
Actual
Results Status Created By
Created
on Comments
7 8 9 10 11 12
QC Path Reviewed By
Reviewed On
Reviewer’s Comments
13 14 15 16