Testing+Tools+(Manual)

(1)

Jai Sri Ram Jai Sai Ram Quality

Quality means satisfaction of the customer.

To define good quality of software, the company people will concentrate on two (2) factors such as 1) Technical factor and 2) Non-technical factor.

1) Technical factor

a. Customer requirements in terms of functionalities.

b. Customer expectations (Look and feel, Ease of use, right output, speed of processing, security)

2) Non-technical factor

a. Low cost to purchase b. Time to market.

S.Q.A (Software Quality Assurance)

It means monitoring and measuring the strength of development process. REQUIREMENTS GATHERINGS

Business Development People / Business Analyst

Business Requirement Specification (BRS) / User Requirement Specification (URS) / Customer Requirement Specification (CRS)

ANALYSIS Analyst

Software Requirement Specification (S/W RS)

FRS Functional Requirement Specification SRS System Requirement Specification DESIGN Designers Design Document _LLD

Low Level Design Document

HLD

High Level Design Document

CODING Programmers

TESTING Testers

PROJECT MANAGEMENT Release and Maintenance

(2)

1) REQUIREMENT GATHERINGS:

In general software development starts with requirement gathering. In this stage Business Development People (BDP) / Business Analyst People (BA) are preparing Business Requirement Specification Document (BRS) / User Requirement Specification Document (URS) / Customer Requirement Specification Document (CRS), after gathering all required requirements from the user / customer.

Business Requirement Specification Document defines the requirement of the customer.

2) ANALYSIS:

After completion of Business Requirement Specification Document, Analyst People are preparing “Analysis Document”. This document is also called as “Software Requirement Specification Document” (S/w RS). The document consists of (2) Sub documents such as FRS & SRS

(i) FRS

It means “Function Requirement Specification”. It defines the required functionality to be used in the project.

(ii) SRS

It means “System Requirement Specification”. It defines the required Hardware to develop that functionality.

3) DESIGN

After completion of Analysis Document, Designers are preparing Design Document. It consists of (2) sub documents, such as (i) HLD & (ii) LLD

(i) HLD (High Level Design Document)

It is also called as External Design Document. It defines the hierarchy of over all application functionalities in terms of modules from root level to leaf level.

Ex:

Mail Chat

Login

(3)

(ii) LLD (Low Level Design Document)

It is also known as Internal Design Document. It defines the internal logic of every functionality or module in terms of ER Diagrams, Data Flow Diagrams.

4) CODING:

A Physical construction of Software is called as “Coding”.

Build: An executable form of all integrated module set is called “Build”. 5) TESTING

In this stage, the testers are validating that developed Build with respective Customer requirements and customer expectations.

6) RELEASE AND MAINTENANCE

After completion of software testing the Project Management will deliver that software to customer for usage.

During utilization of the software, if customer get any problem or if customer want to enhance the application, that can be handled by the company people. System M1 M2 M3 S2 S3 S1 SS1 SS2 SS3 P3 P2 P1 LOGIN User Name Password V V OK CANCEL DATA BASE V IV IV V IV IV V - Valid IV - Invalid MESSAGE BOX Please Try Again

OK

INBOX

Note: A Project will have one HLD and Multiple LLDs.

(4)

What is the difference between Software Product and Software Application?

Software Application

If the Software developed with respective particular client requirements or single client requirements that can be called as Software Application.

Ex: Bank Applications, Hospital Applications. Software Product

If the Software developed with respective multiple clients requirements, that can be called as Software Product.

Ex: MS Office, VB, Operating System etc.,

What is Error, Defect, Bug? Error:

Any mistake in a programme is called “Error”. Defect:

Any mistake found by the tester during Testing can be called as “Defect”. Bug:

The reported defect is accepted by developer to resolve can be called as “Bug”.

SQC (Software Quality Control)

It is a process of validating the Software.

Why Software has Bugs? (i) Poor requirements

(ii) Futurities (Customers requirements are frequently changing) (iii) Miscellaneous Communication.

(iv) Unrealistic schedule (v) Inadequate testing. Solutions

(i) Solid requirements (ii) Good communication (iii) Realistic schedule (iv) Adequate testing

(5)

TESTING MODELS

FISH MODEL

Fish model defines the mapping between development stages and Testing stages.

Reviews in Analysis

In general Software Development process starts with requirements gathering and analysis. In this, Business Development People are preparing Business Requirement Specification Document and Analyst people are preparing Analysis Document with respective to Business Requirement Specification.

After completion of analysis document, the same category people conducting reviews in Analysis Document for completeness and correctness.

During the review they are concentrate on the below factors. i) Are they complete?

ii) Are they right requirement? iii) Are they achievable?

iv) Are they reasonable? v) Are they testable?

Reviews in Design Document

After completion of Analysis document and corresponding reviews, designers are preparing design document which includes Functional Requirement Specifications and System Requirement Specifications.

After completion of design document the same category people are conducting reviews in design document for completeness and correctness.

During the review they concentrate on below factors.

Requirements Gathering BRS / CRS / URS Reviews in Analysis S/W RS (FRS & SRS) Analysis Reviews in Design Design (HLD & LLD) Coding

White Box Testing / Glass Box Testing / Programe Phase Testing / Open Box

Testing Black Box Testing / Functional & System Testing / Close Box Testing Release & Maintenance Test Software Changes Validation Verification

(6)

i) Are they complete/

ii) Are they met right requirements? iii) Are they understandable?

iv) Does they handle Errors or not? White Box Testing

After completion of deign document and correspondence reviews, programs with concentrate on coding to construct a Software Build.

After completion of preparing all programs, Programmers are interconnecting them to a system. In this interconnection of programs to verify the programs and interface between programs or modules, programmers are conducting “White Box Testing”

White Box Testing classified as Two Types such as (I) Unit Testing (II) Integration Testing.

(I) Unit Testing

It is also called as Program Testing or Micro Testing. Unit testing means “Single Program Testing or Component Testing. Unit testing consists of below factors.

a) Basic Path Testing.

During this testing programmers are checking that whether the program is running or not?

To perform this test they will follow below approach. 1) Draw flow diagram of that program.

2) Calculate number of independent paths in that program (Cyclometic Complexity) (The number of independent paths in the program)

3) Execute the program more that one time to cover all independent paths in that program.

b) Control Structure Testing

In this testing the programmers will concentrate on corresponding program output.

In this programmers will concentrate on every statement including, If conditions, For loops, Memory allocation etc.,

c) Program Technique Testing

In this testing the programmers are checking the execution speed of the program.

If the execution speed of the program is not good, then programmers are performing changes in the structure of the program without disturbing functionality.

d) Mutation Testing

Mutation means changes in a program. In this testing programmers are performing wanted changes in the program and executing the program repeatedly. In this Test repetition,

(7)

Programmers are checking the completeness and correctness of the Test.

Passed Passed Failed

(In-compete (Complete

Testing) Testing)

(II) Integration Testing

After completion of dependent program development and corresponding Unit Testing, Programmers are interconnecting to form a system. To estimate the interface between programs or modules programmers are conducting Integration Testing. They are (4) Types of approaches.

a) Top-Down Approach.

The verification of main module without coming to some of the Sub-Modules is called as Top-Down Approach.

“Conduct test on Main module without conducting test on some of the Sub-Modules is called Top-Down Approach.”

In the above approach “STUB” is a Temporary Program, it works like as under constructive Sub Module, it is also called as Called Program.

b) Bottom-Up Approach.

The verification of Sub-Modules without coming from Main Module is called “Bottom-Up” Approach.

“Conducting test on Sub-Modules without testing on Main Module is called Bottom-up Approach.

In the above approach “Driver” is temporary program, it works like as under constructive Main Module. Driver is also known as Calling Program.

Perform change A=10 B=20 I=A+B C=I msgbox I A=10 B=20 C=A+B msgbox I Main Module Sub-Module-1 Sub-Module-2 STUB Sub-Module-3 Main Module Driver / Calling Program

Sub-Module-1 Sub-Module-2 Sub-Module-3

Temporary Program / Called Program

(8)

c) Hybrid Approach / Sand-witch Approach

The combination of Top-down Approach and Bottom-Up Approach is called as Hybrid Approach / Sand-witch approach.

d) Bigbang Approach.

The verification of all modules after completion of all Modules development and corresponding unit testing is called as “Bigbang Approach”.

This approach is not suitable for large modules. CASE STUDY

Case 1: Top-down approach is followable, when the customer’s requirements are constituent of clear.

Case 2: Bottom-up approach is followable, when the customer’s requirements are not clear or frequently changing.

Case 3: Hybrid Approach is followable, when the customer’s requirements are clear and the architecture structure of the system is changing. Case 4: Bigbang Approach is followable, when the application build

consists less number of modules or less number of interconnections.

Main Module Driver / Calling Program

Sub-Module-1 Sub-Module-2 Sub-Module-3

Sub-Sub-Module-1 STUB Sub-Sub-Module-2 Sub-Sub-Module-3 Bottom-Up Approach Top-Down Approach

(9)

BLACK BOX TESTING

After completion integration of all modules to form a system, developers are sending that build to the separate Testing team. This separate testing team validates the Software build with respective customer’s requirements and expectations through “Black Box Testing” techniques.

It is also known as “Close Box Testing” / “Functional & System Testing” It is classified as (3) types such as

1) Usability Testing.

a. User Interface Testing. b. Manual Support Testing.

2) Functional Testing. a. Functionality Testing. b. Sanitation Testing. 3) Non-Functional Testing. a. Recovery Testing. b. Compatibility Testing c. Configuration Testing. d. Intersystem Testing e. Comparative Testing f. Security Testing. g. Installation Testing. h. Load Testing. i. Stress Testing

j. Data Volume Testing.

k. Storage Testing. 1) Usability Testing

After receiving build from the development people, testers are conducting usability testing to check whether the application build is providing user friendly screens or not.

Usability Testing is classified into (2) Types such as (a) User Interface Testing (2) Manual Support Testing.

a. User Interface Testing

During this testing testers are checking the Look and Feel, Ease of use of application of build screen.

Ex: The Microsoft (6) Rules for testing 1) Controls are initcaps.

2) Ok, Cancel existence. 3) System Menu existence. 4) Controls are not overlapped. 5) Controls should be visible. 6) Controls must be aligned.

(10)

b. Manual Support Testing

It is also known as “Help document Testing”. During this testing Testers are checking the context sensitiveness testing.

Ex: Spelling Mistakes, Grammar mistakes, Word Missing, Line Missing etc.,

Case 1: Receive build from the developers.

User interface testing.

Functional & Non-Functional Testing

Manual Support Testing. 2) Functional Testing

After completion of User Interface testing, Testers are conducting Functional Testing to validate customer requirements.

Functional Testing classified into (2) Types (a) Functionality Testing (b) Sanitation Testing.

a) Functionality Testing

During this Testing Testers are validating customers requirement in terms of (6) coverage.

1) Behavioural Coverage. 2) Input Domain Coverage. 3) Error-Handling Coverage. 4) Calculation Coverage. 5) Back-end Coverage. 6) Service level Coverage. 1) Behavioural Coverage.

In this testing Testers are checking whether the objects are properly responding of not, with respective to Business Operation.

2) Input Domain Coverage

In this testing Testers are checking whether the input objects / Input fields are taking right type and range of value or not.

To perform this test we (Testers) are using (2) Types of Testing. (i) BVA (Boundary Value Analysis

(ii) ECP (Equivalence Class Partitioning) BVA

(Range of Object)

ECP

(Defines Type of Object) Range Expected Actual Result Valid Invalid Min= Min-1= Min+1= Max= Max-1= Max+1= Pass Fail Pass Pass Pass Fail Pass fail Usability Testing

(11)

Ex: A Login process allows User Name and Password from a User. In this User Name object allows “Alphabets lower case” Range from 4 to 8 Characters long and Password object allows “Alphabets lower case” range from 6 to 10 Characters long.

Prepare BVA and ECP for the above expected.

BVA & ECP for User Name

BVA ECP

Range Expected Actual Result Valid Invalid Min= 4 Char Min-1= 3 Char Min+1= 5 Char Max= 8 Char Max-1= 7 Char Max+1= 9 Char Pass Fail Pass Pass Pass Fail [a-z] [A-Z] [0-9] All Special characters BVA & ECP for Password

BVA ECP

Range Expected Actual Result Valid Invalid Min= 6 Char Min-1= 5 Char Min+1= 7 Char Max= 10 Char Max-1= 9 Char Max+1= 11 Char Pass Fail Pass Pass Pass Fail [a-z] [A-Z] [0-9] All Special characters

Ex: Age object allows numeric range from 16 to 60.

Prepare BVA and ECP for the above expected. BVA & ECP for Age

BVA ECP

Range Expected Actual Result Valid Invalid Min= 16 Min-1= 15 Min+1= 17 Max= 60 Max-1= 59 Max+1= 61 Pass Fail Pass Pass Pass Fail [0-9] [A-Z] [a-z] All Special characters

(12)

Ex: Mobile No. object allows numeric 10 digits only. Prepare BVA and ECP for the above expected.

BVA & ECP for Mobile No.

BVA ECP

Range Expected Actual Result Valid Invalid Max= 10 Max-1= 9 Max+1= 11 Pass Fail Fail [0-9] [A-Z] [a-z]

All Special characters 3) Error-Handling Coverage.

In this we are checking whether the objects are preventing “Negative Operations” or not.

4) Calculation Coverage.

In this we are checking whether the functionality output is right or wrong.

5) Back-End Coverage.

ODBC JDBC

In this testing we are checking whether the insert of front end operations on back end table context.

6) Service level coverage. The order functionality.

(13)

b) Sanitation Testing

It is also known as “Garbage Testing”. During this testing, testers are finding extra functionalities in the build with respect to customer requirements.

3) Non-Functional Testing

After completion of Functional Testing, testers are concentrating on Non-Functional Testing to validate extra characteristics of that build. They are divided into (11) Types.

a) Recovery Testing

During this testing we are checking that whether the application Build is changing from Abnormal State (Crash / Hang) to Normal State or not.

Abnormal State to Normal State Normal State

Abnormal State b) Compatibility Testing

They are (2) types of Compatibility Testing.

V.B Unix VC++ Win98

Ex: Unix does not support VB Æ Win98 is supporting VC++

Techniques Æ But Build is not working

Properly due to defects

During this testing we are checking whether the application build is able to run on different platforms or not.

Platform means Operating System, Browsers, compilers and other System software’s.

(14)

c) Configuration Testing

It is also known as “Hardware Compatibility Testing”. During this testing we are validating whether the application build is supporting different technologies input / Output devises or not.

d) Intersystem Testing.

It is also known as “Inter operability Testing”. During this testing we are checking whether the application build is coexistence with other existence to share common resource or not.

Ex.: E-Seva.

e) Comparative Testing.

It is also known as “Competitive Testing”. During this testing we are comparing the features of produce with some like previous produce (or) Existing produce in the market to estimate competitiveness.

f) Security Testing.

It is also known as “Penetration Testing”. During this testing we are validating (3) types of factors such as

(i) Authorization. (ii) Access Control.

(iii) Encrypt / Decrypt Data Testing. (i) Authorization.

In this testers are checking whether a valid user is accessible or not, invalid user is preventable or not.

(ii) Access Control

In this we are checking whether a valid user have permission to use specific features / Services or not.

Common Data Base Server Server Elec. Bill Telephone Bill Water Tax Bill Income Tax Bill

Municipal Bill _Server

Server Server

Note: Comparative Testing is applicable for Software Produces only not for applications, because Software application is developed for a single client requirement, but product can be developed with respect to multiple clients requirements.

(15)

(iii) Encrypt / Decrypt Data Testing.

The code conversion in between client process and server process to avoid third party accessing.

g) Installation Testing

It is also known as “Deploying Testing”. During this testing we are validating below factors.

h) Load Testing.

Run the application under customer expected configuration under customer load to estimate the speed of processing is called “Load Testing”.

i) Stress Testing.

Run the application under customer expected configuration under various loads from low to peak to estimate Stress capacity of the application build is called Stress Testing.

j) Storage Testing.

The execution of application build under customer expected configuration under huge amount of resources to estimate the storage capacity of the application database is called Storage Testing.

k) Data Volume Testing.

During this testing Testers are calculating the number of records to be stored into application database.

CLIENT User Name Password SERVER Request Encrypt Cipher Text Cipher Text Decrypt Request Encrypt Decrypt Build & Supported Software Customer expected configure Computer Æ Setup Program. Æ Easy Navigation. Æ Occupied Disk Space. Æ Check Un-installation.

Note: Storage Testing, Data volume Testing coverages same, but Storage Testing is representing in Number of bytes and Data Volume Testing

(16)

GRAY BOX TESTING

Gray Box Testing is a combination of “White Box Testing” and Black Box Testing.

UAT (User Acceptance Test)

After completion of Software Testing, the Project Management / Project Manager will invite customer to collect feedback on one developed software.

They are (2) types such as

α

–

Test (Alfa Test)

β

–

Test (Beta Test) Æ Software Application. Æ By Real customer. Æ At development site. Æ Software Product. Æ By Model customer. Æ At customer site. Release Testing

It is also known as “Port Testing”. After completion of User Acceptance Test” and corresponding modifications, the Project Management will establish Release Team with few Developers, few Testers and One (or) two Hardware Engineers. This release team will go to customer’s site to install the software ion the customer’s environment.

During this they will concentrate on below factors. Î Compact Installation.

Î Overall functionality. Î Input device handling. Î Output device handling. Î OS Error handling.

Î Secondary storage handling.

Î Coexistence with other existence software.

After completion of above like factor observation the release team is providing required training sessions to the customers to understand about the project.

(17)

Maintenance

During utilization of Software by customers, the company people are receiving change request from them.

To receive change request from the customers the Project Management establish “CCB” (Change Control Board) with few Developers, few testers and Project Manager.

CASE STUDY

TESTING STAGES RESPONSIBLE PERSONS

Review in Analysis Analyst

Review in Design Designer

Unit Testing Programmers

Integration Testing Programmers

Functional & System Testing Test Engineers / Testers User Acceptance Testing Users / Customers Release Testing / Port Testing CCB

TERMINOLOGY

DEVELOPERS TESTERS

Input Test Data

Output Test Log

Program Test Script

Challenges in Testing

Generally organizations are maintaining separate Testing for Functional and System Testing. This separate Testing team is also involving in Release Team and CCB. Some time this separate Testing team is also not able to conduct planned Testing or good testing due to some risks.

CCB

Receive change

Enhancement Missed Defect

Impact Analysis Perform changes Test S/w changes Impact Analysis Perform changes Test S/w changes Increase Testing process Capability

(18)

The risks are

Î Lack of knowledge on project domain. Î Lack of communication.

Î Lack of resources. Î Lack of time. Î Lack of Test Data.

To overcome above like risks, the people are following “Ad-hoc” Testing.

Planned Testing

A Tester conduct Test on application build with pre-planned procedure is called Planned Testing.

(or)

A Tester conduct Test on application build by following formal methods are called Planned Testing.

Ad-hoc Testing

A Tester conduct test on application build without Pre-planed is called Ad-hoc Testing.

(or)

A Tester conduct test on application build by following “Informal Methods” is called “Ad-hoc Testing”.

They are classified as (4) Types. (a) Monkey Testing.

Due to lack of time, Testers are conducting test on major functionalities of the application build. This style of testing is called “Monkey Testing”. It is also known as Cheapening Testing.

(b) Buddy Testing.

Due lack of time, Testers are grouping with programmers to conduct Test on application as early as possible. This style of Testing is called as Buddy Testing.

Buddy means a group of Programmers and Testers. (c) Pair Testing.

Due to lack of knowledge on domain Junior Testers grouped with Senior Testers to share their knowledge. This style of testing is called Pair Testing.

(d) Exploratory Testing.

Due to lack of Test Data, Testers are conducting Test on application depending on available documents, discussions with other and get the requirements from customers. This style of testing called Exploratory Testing.

(19)

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) 1) WATERFALL MODEL

Î In this Model next stage starts after completion of previous stage. Î There is no overlapping between two stages.

ADVANTAGES

i) It is less expensive.

ii) It works well for small applications.

iii) It is flexible when the customer requirements are constant. DISADVANTAGES

i) Testing is a single stage starts after coding.

ii) If any defect is found during Testing, the rectification of that defect would be difficult.

iii) It is “not flexible” to have changes in the customer requirements during developing the software.

2) INCREMENTAL WATERFALL MODEL

Î To overcome some of the limitations of Waterfall we can use Incremental Waterfall model.

Î Incremental Waterfall Model can be used Software Produce Development.

Î In this Model a set of requirements they would be one working product. Requirement Gathering Analysis Design Coding Testing Release & Maintenance

R.G Analysis Design Coding Testing R & M R.G Analysis Design Coding Testing R & M R.G Analysis Design Coding Testing R & M

1.0 2.0 3.0

(20)

3) PROTOTYPE MODEL

It is followable when the customer requirements are not clear.

“Prototype means a sample Model of application without functionality.

ADVANTAGES

i) It is flexible when the customer requirements are not clear. DISADVANTAGES

i) It is expensive 4) Spiral Model

Î Spiral Model is followable when the customer requirements are enhanceble in terms of versions.

Î In this Model we will start the process within complete requirements.

ADVANTAGES

It is flexible for high risk based projects. DISADVANTAGES

It is expensive.

Not Clear

Hardware Prototype Software Prototype Demo to Client Requirements refined Finalize Environment BRS Base lined SRS Base lined 1.0 2.0 3.0 4.0 5.0

Planning Risk Analysis Requirement Gathering Engineers Evaluation Coding and Testing Customer Evaluation

(21)

5) V-MODEL

Like as Fish Model “V-Model” is also defines the mapping between Development stages and Testing stages.

In V-Model V stands for “Verification and Validation”. Verification

To check whether the people are developing right product or not. Validation

To check whether the developed product is right or not. Software Testing

The “Verification and Validation” of a Software is called Software Testing. Requirement Gathering Analysis Design BRS Coding User Acceptance Testing System Testing Integration Testing Unit Testing FRS HLD LLD White Box Testing Black Box Testing

(22)

6) Agile Model

It is a latest model which is used in Software produce development.

In this model we can get build from the developers in very short time (1 to 4 Weeks)

In this model development process, testing process will be carried out parallelly.

They are (2) methods such as (a) X-Tream Programming. (b) Scrum

ADVANTAGES

i) Any defect identified early, so that he rectification of the defect cost and time would be very less.

ii) As the defect is identified early, the impact of the same defect is very less on subsequent features.

DISADVANTAGES

i) Documentation is very less.

Sanity Testing

After receiving the build from the developers we people are conducting “Sanity Testing” to estimate stability of that build before start real testing.

During this testing we will be concentrate on below factors. a) Understandable. b) Operatable. c) Observable. d) Controllable. e) Consistency. f) Automatable. g) Maintainable h) Simplicity.

From the above (8) factors, Sanity Testing is also known as Build Verification Testing (BVT) or Tester Acceptance Testing (TAT) or Testability Testing or Oct-angle Testing.

Smoke Testing

Like as Sanity Testing, Smoke Testing is also used to estimate the stability of the Build.

(23)

Re-Testing.

Case 1: The repeating of same test for more than one time with multiple data is called as “Re-Testing”.

Case 2: The re-execution of failed tests on modified build to ensure bug fixing work is called “Re-Testing”

Regression Testing.

The Re-execution of selected test or modified build, to check is there any side effects occurred or not on dependent functionalities by modifying reported defects or by adding new requirements.

Types of Build

They are (7) types of Build. They are (1) Initial Build

(2) Stable Build

(3) Defect effected Build (4) Modified Build

(5) Complete Build (6) Master Build (7) Golden Build

Types of Projects

Mainly there are (3) Types of projects. They are (1) Traditional Project (2) Outsourcing Project (3) Maintenance Project

Type of Project R/G Analysis Design Coding Testing R&M

Traditional

9

Outsourcing

8

9

Maintenance

8

9

Development Initial Build

Sanity Testing Comprehensi ve Testing _Bug Fixing Re-Testing Regression

Testing Test Closer

(Test Lead) U.A.T

Sign off Stable Build

Defect Effected Build

Modified Build

Complete Build Master Build

(24)

MANUAL TESTING

Testing Process Test Initiation (Project Management / Quality Analyst T.R.M (Test Responsibility

Matrix) _{3) Risk involved in that Project} 2) Type of the Project

1) Scope of the Project

Test Plan Document

(Test Lead)

4) Whom to Test? 1) What to Test? 3) Who to Test?

Test Scenarios & Test Cases with

Step by step procedure

(Test Engineer / Tester)

Test Case execution as Batches

Test Closer (Test Lead) Bug fixing 2) How to Test? Re-testing & Regression Testing UAT Sign Off

Defect Report Final Summary Report

(25)

PETT Process (Process Expert Tolls and Techniques) Requirement Gathering

Analysis

Test initiation Design

Coding Test Plan Document

Test Scenarios & Test Case with Step by step process

Level ‘0’ Testing / Sanity Testing

Level ‘1’ Testing / Comprehensive Testing / Batch Testing

Level ‘3’ Testing / Test Closure / Postmortem Testing / Pre-acceptance Testing (1) Initial Build (2) Stable Build (5) Complete Build (3) Defect Effected Build Bug Fixing Level ‘2’ Testing Re-Testing / Regression Testing Defect Report (4) Modified Build

User Acceptance Testing

Sign Off

(6) Master Build

(26)

Testing Initiation:

In general testing process start with “Test initiation”. In this, Project Manager / Quality Analyst develop Test starting Document. This document defines the required testing approach to be followed by the testing team.

During this document preparation they will concentrate on below (12) components.

1) Scope & Objective. 7) Test Automation

2) Budget Control. 8) Defect Tracing & Reporting

3) Test approach. 9) Measurements & Matrix.

4) Roles & Responsibilities 10) Change & Configuration Management 5) Communication & Status Reporting 11) Risks & Mitigations

6) Test deliverables 12) Training Plan.

1) Scope & Objective:

The need of testing in the project. 2) Budget Control.

Time & Cost allocation to the project. Ex: As per U.S. Norms

3) Test approach

In this they will specify a list of selected quality factors to be applied by the Tester.

T.R.M (Test Responsibility Matrix) can be finalized by Project Manager / Quality Analyst based on scope of the project, type of the project and Risks involved in that project.

TRM : It defines the mapping between Test factors and Development Stages. 100% 64% Development Department 36% Testing Department

#

##

(27)

Quality Factors / Test Factors

RG &

Analysis Design Coding

Function & System Testing R & M 1) Authorization 2) Access Control 3) Ease of use 4) Ease of operation 5) Correctness 6) Continuity & Processing 7) Coupling 8) Data integrity 9) Recovery 10) Portable 11) Service Level 12) Performance 13) Maintainable 14) Methodology 15) Audit trail.

1) Authorization: Whether a valid user is accessible or not and Invalid User is preventable or not.

2) Access control: Whether a valid user have permission to user specific service of not

3) Ease of Use: Whether the application build is providing user friendly screens or not.

4) Ease of operate: Easy to installation, downloading, uploading, dumping, un-installing.

5) Correctness: Whether the functionality output is right or wrong. 6) Continuity & processing: The integration of modules.

7) Coupling: Co-existence with other Software.

8) Data Integrity: Whether the input objects are taking right type and range of values or not.

9) Recovery: Whether the application build is changing from abnormal state to normal state or not.

10) Portable: Whether the application build is able to run on different platforms or not.

11) Service Level: The order of functionality. 12) Performance: The speed of processing.

13) Maintainable: Whether the application build is longtime serviceable in customers site or not.

(28)

14) Methodology: Whether the people (Tester) are following right process of not. If not he will be punishable.

15) Audit Trail: Whether the system is maintains data for the user operation (Ex. Bank Application, Withdrawal time, ATM Centre Code etc.,)

1) Authorization Æ Security Testing

2) Access Control Æ Security Testing

3) Ease of use Æ User interface Testing

4) Ease of operation Æ Installation Testing

5) Correctness Æ Functionality Testing

6) Continuity & Processing Æ Integration Testing

7) Coupling Æ Intersystem Testing

8) Data integrity Æ Input domain Testing

9) Recovery Æ Recovery Testing

10) Portable Æ Compatibility Testing

11) Service Level Æ Functionality Testing

12) Performance Æ Load, Stress, Storage, Data volume Testing

13) Maintainable Æ Stress Testing

14) Methodology Æ Compliance Testing

15) Audit trail. Æ Functionality Testing

4) Roles and Responsibilities

Name of the jobs and his / her responsibilities. 5) Communication n& Status reporting

The required communication between two consecutive jobs. Ex:

When do report? Weekly Once, twice, daily etc., 6) Test deliverables

The required documents to be prepared by the testing team. The following documents were prepared by the Test lead and Test engineers.

Test Plan, Test Scenario, Test Cases, Test Data, Test log, Defect report, Final Summery Report etc.,

7) Test automation

The purpose of Automation testing in the project and available tools in the organization.

(29)

8) Defect tracing & Reporting.

The required communication between Programmers and Testers when Test Engineer / Tester got a mismatch.

Large Scale Small Scale

Transmittal Report 9) Measurement & Matrix:

The required measurement to estimate the status of the project. In measurements there are (3) types such as (1) Quality Assessment Measurement (2) Test Management Measurement (3) Process Capability Measurement.

10) Change & Configuration Management

How to handle change request from the customer and how to store the documents for future reference.

11) Risk & Mitigations:

The possible risks and solutions to overcome them. 12) Training Plan:

The required training secession to the Testing team to understand about the project.

Project Management Project Lead Team Lead Programmer Test Lead Test Engineer Project Management Team Lead Programmer Test Lead Test Engineer

(30)

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)

(31)

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

(32)

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?)

(33)

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:

(34)

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.

(35)

(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

(36)

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 1) Test Case Name / ID:

Unique Number for future reference

Ex: TC001_Project Name_Module Name_Functionality Name 2) Test Case Description:

The description about that Test case. Î Pre-requisites

Î Documents referred. 3) Priority

Importance of the Test Case. They are classified into (3) Types such as

(1) High Priority (Basic functionality Test Cases)

(2) Medium Priority (General functionality Test Cases – Recovery, Compatibility Testing etc.,)

(3) Low Priority (Cosmetic Test Cases – User Interface Testing)

4) Step Name

Every Test Case divided into multiple steps, every step in the test case will have unique number.

Ex: Step–1; Step–2; Step–3 etc., 5) Step Description

The required action to be performed by the user. 6) Test Data

(37)

7) Expected Results

The required expected output from the system for the corresponding user action.

8) Actual Results

The actual output of the system after performing user action. 9) Status

The current position of the Test Case. They are classified into (4) types, such as

(a) No Run: Test Case not executed atleast for once. (b) Not complied: A partially executed test case.

(c) Passed: Test Case executed and the expected value and Actual value is same, “Test is passed”.

(d) Failed: Test Case any step(s) expected values

mismatched with actual value, “Test is failed”. 10) Created By

The name of the Test Engineer, who created the Test Cases. 11) Created on

Date and Time of the created Test Case. 12) Comments

A set of comments given by Tester for the Step or Test Cases. 13) QC Path

The path of Quality Control. 14) Reviewed By

Name of the Reviewer. 15) Reviewed on

When (Date & Time) the document was reviewed by reviewer. 16) Reviewer’s Comments

(38)

(39)

User Name

User Name object allows alphabets lower case range from 4 to 8 characters.

Password

Password object allows alphabets lower case range from 6 to 10 characters.

Customer Name

Î Customer Name object allows alphabets. Î Range from 4 to 12 characters.

Î First letter should be Upper Case. Î Mandatory.

Customer Address

Î Customer Address object allows alpha-numeric and some special Characters (“–“ “/” “#” “,” “.”)

Î Maximum of 20 Characters. Î Mandatory.

Customer DOB

Î Customer DOB object allows Numeric Only. Î The format is MM/DD/YYYY.

Î Date should be less than current system date. Î Mandatory.

Customer Ph.No.

Î Customer Ph.No. object allows Numeric Only. Î Allows 10 digits only.

Î Phone number is unique. Î Mandatory.

E–Mail

Î E-Mail object allows alpha-numeric and special Characters. Î Format is [email protected].

(40)

TEST SCENARIO DOCUMENT

Project Name: Customer Info _{Reviewed by} Module Name: Admin

Created by: Suresh _{Reviewed by}

Created on: 18/10/2008

Sl. No. Requirement _Name _ScenarioTest Test Cases 1 Login

Ok Cancel

1) Verify Ok with valid data. 2) Verify Ok with invalid data. 3) Verify Cancel

2 Add Insert

Cancel

1) Verify Insert with valid data. 2) Verify Insert with invalid

data.

3) Verify Insert with duplicate data.

4) Verify Insert with missing mandatory fields.

5) Verify Cancel 3 Search

Search

Cancel

1) Verify Search with valid data.

2) Verify Search with invalid data. 3) Verify Cancel 4 Edit Update Cancel Home

1) Verify Update with valid data.

2) Verify Update with invalid data.

3) Verify Update with duplicate data.

4) Verify Update with missing mandatory fields.

5) Verify Cancel 6) Verify Home

5 Delete Delete Verify Delete

6 Cancel Cancel Verify Cancel

7 Home Home Verify Home

8 Logout Logout Verify Logout

Note: RCN (Requirement Clarification Note)

Any doubt in FRS / BRS Document, we people design RCN Document and the same will be sent to BDP for clarification.

(41)

TEST CASE DOCUMENT Test Case name Test Case description Step Name Step Description Test

Data Expected Result TC01_ Customer Info_Admin_ Verify Ok with Valid data This Test case validates ‘Ok’ functionality with valid data

Step-1 Open Brower, enter Url. Address, click on Go

Url It should display Login Page with User Name, Password objects and Ok, Cancel functionalities. Step-2 Enter valid

User Name and Password click on Ok User Name & Pass word It should display Customer Information page with Add, Search, Logout functionalities. TC02_ Customer Info_Admin_ Verify Ok with invalid data This Test case validates ‘Ok’ functionality with invalid data

Url It should display Login Page with User Name, Password objects and Ok, Cancel functionalities. Step-2 Enter invalid

User Name and Password click on Ok User Name & Pass word It should display meaningful error message. TC03_ Customer Info_Admin_ Verify Cancel This Test case validates Cancel functionality

Url It should display Login Page with User Name, Password objects and Ok, Cancel functionalities.

Step-2 Enter User

Name and Password click on Cancel User Name & Pass word

It should clear all fields and cursor should be present in the first field. TC04_ Customer Info_Admin_ Verify Insert with Valid data This Test case validates ‘Insert’ functionality with valid data

User Name and Password click on Ok User Name & Pass word It should display Customer Information page with Add, Search, Logout functionalities. Step-3 Click on Add - - It should display Add

Customer page with C.Name, C.Addr., C.DOB, C.Ph.No.,

E-mail objects and Insert,

(42)

Test Case name Test Case description Step Name Step Description Test

Data Expected Result Step-4 Enter data in

corresponding fields and click on Reset C.Name C.Addr. C.DOB C.PhNo E-mail

It should clear all fields and cursor should be present in the first field. Step-5 Enter valid

data in corresponding fields and click on Insert C.Name C.Addr. C.DOB C.PhNo E-mail It should display a meaningful Message such as “Customer Data created with Customer ID” TC05_ Customer Info_Admin_ Verify Insert with invalid data This Test case validates ‘Insert’ functionality with invalid data

Reset, Cancel functionalities.

Step-4 Enter invalid

data in corresponding fields and click on Insert C.Name C.Addr. C.DOB C.PhNo E-mail It should display a meaningful Error Message. TC06_ Customer Info_Admin_ Verify Insert with duplicate data This Test case validates ‘Insert’ functionality with duplicate data

Customer page with C.Name, C.Addr.,

(43)

Data Expected Result C.DOB, C.Ph.No., E-mail objects and Insert,

Reset, Cancel functionalities. Step-4 Enter duplicate data in corresponding fields and click on Insert C.Name C.Addr. C.DOB C.PhNo E-mail It should display a meaningful Error Message. TC07_ Customer Info_Admin_ Verify Insert with missing mandatory fields This Test case validates ‘Insert’ functionality with missing mandatory fields

Step-4 Enter data in corresponding fields by missing some mandatory fields and click on Insert C.Name C.Addr. C.DOB C.PhNo E-mail It should display a meaningful Error Message. TC08_ Customer Info_Admin_ Verify Cancel This Test case validates ‘Cancel’ functionality

User Name and Password User Name & Pass It should display Customer Information page with Add, Search,

(44)

Data Expected Result Step-3 Click on Add - - It should display Add

Step-4 Enter data in

corresponding fields and click on Cancel C.Name C.Addr. C.DOB C.PhNo E-mail

It should close current page and display previous page. TC09_ Customer Info_Admin_ Verify Search with valid data This Test case validates ‘Search’ functionality with valid data

User Name and Password click on Ok User Name & Pass word It should display Customer Information page with Add, Search, Logout functionalities.

Step-3 Click on

Search

- - It should display Search Page with C.ID, C.Name,

C.DOB, C.Ph.No., objects and Search,

Step-4 Enter data in corresponding fields click on Reset C.ID C.Name C.DOB C.PhNo

It should clear all fields and cursor should be present in the first field.

Step-5 Enter valid

data in corresponding

fields and click on Search

C.ID C.Name

C.DOB C.PhNo

It should display Search Results Page with Customers Information and Edit, Delete, Cancel, Home functionalities. TC10_ Customer Info_Admin_ Verify Search with invalid data This Test case validates ‘Search’ functionality with invalid

User Name User Name

It should display Customer Information

(45)

Data Expected Result

data and Password

click on Ok

& Pass word

page with Add, Search, Logout functionalities. Step-3 Click on

Search

Step-4 Enter invalid data in corresponding

fields and click on Search C.ID C.Name C.DOB C.PhNo It should display meaningful error message. TC11_ Customer Info_Admin_ Verify Cancel This Test case validates ‘Cancel’ functionality

User Name and Password click on Ok User Name & Pass word It should display Customer Information page with Add, Search, Logout functionalities. Step-3 Click on

Search

Step-4 Enter data in corresponding fields and click on Cancel

C.ID C.Name

C.DOB C.PhNo

It should close current page and display previous page. TC12_ Customer Info_Admin_ Verify Update with valid data This Test case validates ‘Update’ functionality

User Name and Password User Name & Pass It should display Customer Information page with Add, Search,

(46)

Step-3 Click on

Search

Step-4 Enter valid

C.ID C.Name

C.DOB C.PhNo

It should display Search Results Page with Customers Information and Edit, Delete, Cancel, Home functionalities.

Step-5 Select a

Customer data click on Edit

- _{It should display Edit}

Page with C.ID, C.Name,

C.Addr., C.DOB, C.Ph.No., E-mail objects

and Update, Reset,

Cancel, Home functionalities.

Step-6 Enter data in corresponding fields click on Reset C.ID C.Name C.DOB C.Addr. C.PhNo E-mail

It should clear all fields and cursor should be present in the first field.

Step-7 Enter valid

data in corresponding fields click on update C.ID C.Name C.DOB C.Addr. C.PhNo E-mail

It should display “Update done” message. TC13_ Customer Info_Admin_ Verify Update with invalid data This Test case validates ‘Update’ functionality with invalid data

Step-3 Click on

Search

(47)

Step-4 Enter valid

C.ID C.Name

C.DOB C.PhNo

It should display Search Results Page with Customers Information and Edit, Delete, Cancel, Home functionalities. Step-5 Select a

and Update, Reset,

Step-6 Enter invalid

data in corresponding fields click on update C.ID C.Name C.DOB C.Addr. C.PhNo E-mail It should display meaningful error message. TC14_ Customer Info_Admin_ Verify Update with duplicate data This Test case validates ‘Update’ functionality with duplicate data

Search

Step-4 Enter valid

C.ID C.Name

C.DOB C.PhNo

(48)

Step-5 Select a

and Update, Reset,

Cancel, Home functionalities. Step-6 Enter duplicate data in corresponding fields click on update C.ID C.Name C.DOB C.Addr. C.PhNo E-mail It should display meaningful error message. TC15_ Customer Info_Admin_ Verify Update with missing mandatory fields This Test case validates ‘Update’ functionality with missing mandatory fields

Step-3 Click on

Search

Step-4 Enter valid

C.ID C.Name

C.DOB C.PhNo

Step-5 Select a

and Update, Reset,

(49)

Data Expected Result Step-6 Enter data in

corresponding fields by missing some mandatory fields and click on update C.ID C.Name C.DOB C.Addr. C.PhNo E-mail It should display meaningful error message. TC16_ Customer Info_Admin_ Verify Cancel This Test case validates Cancel functionality

Search

Step-4 Enter valid

C.ID C.Name

C.DOB C.PhNo

It should display Search Results Page with Customers Information and Edit, Delete, Cancel, Home functionalities. Step-5 Select a

and Update, Reset, Cancel, Home functionalities. Step-6 Enter data in

corresponding fields and click on Cancel C.ID C.Name C.DOB C.Addr. C.PhNo E-mail

It should close current page and display Previous Page.

Testing+Tools+(Manual)







TESTING MODELS

BLACK BOX TESTING







GRAY BOX TESTING

α

–

β

–







9

9

9

9

9

9

8

8

8

8

9

9

8

8

8

8

8

9

MANUAL TESTING

#

##