Manual Part II

1. Organization test documentation

2. STLC- Software Testing Life Cycle
Testing Process
3. Test Scenarios & Test cases with excel sheet format
4. Test case review
5. Test execution & test proof
6. Traceability matrix
7. Defect life cycle
8. Principles of software testing

What is your organization Test documentation?

 Test Document hierarchy

Quality control – QC/ Test Policy

Testing Head -TH Company Level
document
Test Strategist – TS & PM Test Strategy

Project manager – PM Test Methodology TRM

Team Lead – TL Test Plan

Identify Test Scenario/ Case

Test Procedure/Design
Tester – Tester Project Level
Test Script/ Execution document
(Test Proof)

Defect Report

Test Summary Report

Team Lead – TL
Final Report/ Test
closer Report
 1. Test policy
- Test policy document it is a company level document
- Test policy document is prepared by QC- quality control / Testing Head- TH
- Test policy documents defines domain & objective of the project / testing

2. Test Strategy
- Test strategy document defines which strategy / approaches we can apply for full fill the objective
of the project
- Ex. Project- Automation Testing- Java/C#/ paython, php, ruby….etc + selenium tool
- Test strategy document will be prepared by Test strategist or PM (Testing)
- Test strategy document it is a company level document
- In this document includes- testing approaches, available resources & standards to be followed for
testing are given
- Test policy document- objective of the project is defined, so to achieve the objective & full
fill the objective of the project we need test strategy document
- Test strategy documents contains different approaches
1. Scope & objective
PM defines (about testing need & their purpose)
Purpose of the project (objective of the project)
Definition of the project (which type of testing or possible testing activities should be
conduct)

2. Business issue

It is nothing but cost analysis & it depends on

Cost of the project
Domain of the project
Resource allocation
100%- project cost
70% - development & testing- 30%

3. Test responsibility matrix

It is mapping between the development stages & testing factors/issues is known as TRM
It is also called Test matrix (TM)

Mapping – project type & testing factors

Development Information Design Coding Testing Maintains

Stage gathering/
Analysis
Project
Type
Traditional Yes Yes Yes Yes Yes
Off the shelf No No No Yes No
Maintenance No No No No Yes

Development Information Design Coding Testing Maintains

Stage gathering/
Analysis
Testing
factor
System & No No No Yes Yes
functional
Testing
Security No No No Yes Yes
Performance No No No Yes Yes
Testing

4. Test deliverable

It defines we can’t go to 2nd stage without completing 1st stage

Test methodology- test plan- test case design – test case review – test case execution- defect
report- test summary – closer report

5. Roles & responsibility

Names of the JOB in testing team and their responsibility

R & R allocated- based on the experience of the employee, knowledge about domain of the
project, priority of the project

6. Communication & status reporting

Require communication & status reporting between two consecutive jobs in testing team

7. Defect reporting & tracking

Required communication between testing team & development team

It includes
Lock the defect- by tester
Analysis of the defect- developer
Fixing the defect- developer
Retesting the fixes- tester
Regression testing- tester- to verify the impact on the other module
Defect tracking till closure

8. Implementation of automation
Decide automation testing is required in how many %
 9. Test measurement- DRE- refer V model

10. Change & configuration management – CR

11. Testing plan & testing session

Need of training to tester before starts of the every project
No of KT – fresher – senior tester

12. Risk & mitigation

Risk – problems- availability of the tester analyzed
Mitigation – solution

Test methodology

Test methodology defines – environment follow/ use for strategy / approaches

TMD will be prepared by PM

TND it is a project level document

TMD- it depends upon the type of the project & project requirement

TM- types of the project + project requirements

TMD- PM will prepared the TRM

During this documentation, PM focuses on

1. Type of project

Development Information Design Coding Testing Maintains

Stage gathering/
Analysis
Project
Type
Traditional Yes Yes Yes Yes Yes
Off the shelf No No No Yes No
Maintenance No No No No Yes

2. Scope of the project

Identify the scope of the application according to the need of the project
 3. Requirements of the project
S&F
Security
Performance etc

4. Risk in project
New person- KT need
Less person- work overload
If not having knowledge- exploratory testing

5. Preparation of the Test plan- TL

Job allocation
Resources allocation
Estimation

6. TRM finalization – finalize

Test Plan

- It is the project level document

- TPD is prepared by test lead
- Test plan will contains
Resource allocation
Job allocation
Estimation etc.

Test plan contains

1. Test plan ID- unique number

2. Introduction – about project & test team
3. Test items- modules/features/functions
4. Feature to be tested- responsible module to prepare test cases
5. Feature not be tested- which ones & why not?
6. Approach – required list of testing technique (depends on the TRM)
7. Feature pass or fail criteria- when a feature is pass & when a feature is fail
8. Suspension criteria- possible abnormal situation raised during above feature testing
9. Testing task- necessary task to do before start of every feature testing
10. Test deliverable – requirement test documents to prepare during the testing
11. Test environment- required HW and SW including testing tool
12. Staff & training need- names of selected test engineer
13. Responsibilities – work allocation
14. Schedule – dates & times
 15. Risks & mitigation
16. Approval- signature of test plan – PM

Identify test scenarios & test case design

- Tester will identify test scenarios & test case design

- Tester prepared TS & TCD
- It is a project level document

Test Case execution & defect report

- TCE
- In TCE, if we found the defect then we will assign to the developer
- Modified build we will perform regression & retesting

Test summary report & test closure report

- Test summary report it will contains

Module name-
TCD-
TCE-
TCS-
DL-
Etc.
- TSR & TCR- it is prepared by test lead
- It is a project level document

SDLC- RG A D C T M

Software Testing Life Cycle

What is your organization testing process?

What is STLC?

It’s a systematic approach to validate application based on the stakeholder requirement &
expectation

STLC is a sequence of different activities performed by the testing team to ensure the quality of
the software

It describe step by step process performed by separate testing team in order to validate application

STLC there are different stages

 Test Initiation Test plan Test Scenarios Test Case Design Test case Execution
Defect Test closure / test summary report

Test Initiation Test Plan Test Scenario

Defect
Test Case
Test Case sent to
Execution-
Design developer
Test Proof

Test Closer/ Test

Summery Report

Test Initiation

- In my organization the testing process is started with test initiation process

- In the test initiation, the SM is work
- In TI – SM focuses on
1. Requirement analysis (requirement of project)
Requirement of the project means domain of the project
On which project domain we are working
Ex. insurance, healthcare, banking, telecom, banking, e-commerce etc

2. Scope of project
In this the strategist will be decided to test the functionality of modules present in the project

3. Risk analysis (risk involve in the project)

Risk project in the projects are
- lack of knowledge
- less test data
- less resources etc

Test Plan

- In test plan stage, test lead will work

- Test lead will prepared test plan
- Test plan will contains
- Job allocation
Means testing are selected in that particular project
 - Resource allocation/ team formation
Resources means people are allocated for that particular project based on that selected testing
- Estimation
Means start to end date of the project

-Test plan contains

What to test?

Who will test?

When to test?

How to test?

Test Scenarios

- Having analyzed requirement document & assigned US as a tester we identify test scenarios
- Test scenarios describes way to test the functionality of the application
- Test scenarios derived from user stories
- Test scenarios defines What to test
- One test scenario will contains / includes multiple test cases
- Test scenarios always defines high level test cases
- Test scenarios always written in +ve ways

Test Case Design

- Test cases defines steps to test functionality of an application

- Test cases derived from test scenarios
- Test cases will defines how to test
- Test cases always defines low level test cases
- Test cases always written in +ve & -ve ways
- Types of test cases
UI test cases
Usability test cases
Validation test cases
Functionality test cases

- TCD- TCS- US & SRS

Test cases execution & defect

- Having review the test cases, & when we get the build we perform “Sanity Testing/Smoke
Testing” there
 - If build is stable, we go for “S & F testing”
- As tester will start the test cases execution
- So, during the test case execution, if we got the defect we assign to the developer
- If we got the fix from developer we will perform retesting there & if we required we perform the
regression testing
- After it, we have to prepare test case execution report & defect report
- We have to send it to test lead

Test summary report

- It is prepared by the test lead

- TSR it will contains
How many test cases executes
How many test case design
How many test cases skip
How many test cases failed etc.
How many defects lock

Tester name-

Module name/Build Name-

Login Credentials

Browsers- C/IE/FF

Test Marix

TCD-300 + 200 + 100 + 100 = 500

TCE-250

TCP-

TCP-

TCF-

TCS-10

TCF-40

Test Closure Report

- It is prepared by test lead

 - Team lead check all the reports & checks all the process are correct or not as per the JIRA tool
- Test closure report provides detailed analysis of the type of the testing carried out, process
followed & status of the defect found
- Test lead use dash board tool – for the test closure report
- This report is form in a graph
- Sent to the SM
Testing Process

Test Scenarios & Test case design

SRS/FRS/CRS- PO/BA

US/UC- PO/BA

TS- Tester

TCD- Tester

SRS/FRS/CRS

- SRS derived from BRS

- SRS is prepared by BA/PO
- SRS- defines functional requirements to development & system requirements that will be used
- SRS contains
1. FFD
2. FR
3. US
4. Snapshot
- SRS documents contains multiple US/UC

US/UC

- US/UC are derived from SRS

- US/UC prepared by BA/PO
- US/UC defines functional requirement or single specific requirement
- US/UC will contains
Description- details about the requirement
Acceptance Criteria- does & don’t about requirement
Test Scenarios vs Test Cases

Test Scenarios

- Having analyzed requirement document & assigned US as a tester we identify test scenarios
- Test scenarios describes way to test the functionality of the application
- Test scenarios derived from user stories
- Test scenarios defines What to test
- One test scenario will contains / includes multiple test cases
- Test scenarios always defines high level test cases
- Test scenarios always written in +ve ways

Ex. Login Page- Username Text box, Password, Submit button

US – Login Page

Description – login page will contains UN / PW/ Submit

Acceptance Criteria- login page should accept mobile no as a UN & Password will contains 4 to 6 char
combination

Test Scenarios of login page

1. Verify login page by passing mobile number in UN test box

2. Verify login page by passing email id in UN test box
3. Verify login page by passing data in UN & PW text box

Test Case Design

- Test cases defines steps to test functionality of an application

- Test cases derived from test scenarios
- Test cases will defines how to test
- Test cases always defines low level test cases
- Test cases always written in +ve & -ve ways
- Types of test cases
UI test cases
Usability test cases
Validation test cases
Functionality test cases

Verify login page by passing mobile number in UN test box

1. Verify login page by passing JIO mobile no in UN test box

2. Verify login page by passing IDEA mobile no in UN test box
3. Verify login page by passing Vodafone mobile no in UN test box
4. Verify login page by passing BSNL mobile no in UN test box
 5. Verify login page by passing Airtel mobile no in UN test box
6. Verify login page by passing invalid mb.no in US text box
7. Verify login page by passing null values / blank in mob.no in UN text box

Verify login page by passing email id in UN test box

1. Verify login page by passing Mac@gmail.com ids in UN text box

2. Verify login page by passing Mac@outlook.com ids in UN text box
3. Verify login page by passing Mac@hotmail.com ids in UN text box
4. Verify login page by passing Mac@redefmail.com ids in UN text box
5. Verify login page by passing Mac@yahoo.com ids in UN text box
6. Verify login page by invalid passing Mac@gmail.com ids in UN text box
7. Verify login page by invalid passing Mac@outlook.com ids in UN text box
8. Verify login page by invalid Mac@hotmail.com ids in UN text box
9. Verify login page by invalid Mac@redefmail.com ids in UN text box
10. Verify login page by invalid passing Mac@yahoo.com ids in UN text box
11. Verify login page by passing blank ids in UN text box

Verify login page by passing data in UN & PW text box

1. Verify login by passing valid data in UN & valid data in PW text box
2. Verify login by passing invalid data in UN & valid data in PW text box
3. Verify login by passing valid data in UN & invalid data in PW text box
4. Verify login by passing invalid data in UN & invalid data in PW text box
5. Verify login by passing blank data in UN & valid data in PW text box
6. Verify login by passing valid data in UN & blank data in PW text box
7. Verify login by passing blank data in UN & blank data in PW text box

Submit

1. Verify submit button is clickable or not

2. Verify submit button mouse over effect

UN-mangesh
PW-Mag (text filed – validation message)

Login
Difference

between Test scenarios & Test Cases?

Sr.No Test Scenario Test Case

1 Test Scenario are derived from the user derived from the Test Scenario Test Case
stories are
2 Test Scenario focuses on “What to Test Case focuses on “How to test”
test”
3 Test Scenario high level actions Test Case low level actions
4 Test Scenario describes test Test Case describes validation procedures of
condition/requirements/functionality, each functionality or requirements
which we have to validate

Test Case format- Excel Sheet

Field / attributes

1. Test scenario ID
2. Test scenarios description (1)
3. Test case ID (1,2,3,4,5)
4. Test case description
5. Test step
6. Pre- condition
7. Test data
8. Post condition
9. Expected result
10. Actual result
11. Status- Pass & Fail
12. Executed by (tester id/ name)
13. Executed date
14. Comment
Review

- After preparation of test cases, we have to through the test case review process to check
completeness & correctness of test cases w.r.t requirement
- Review- to check completeness & correctness of the test case document
- Importance of review of test cases

It’s necessary to review test cases to verify

1. Whether test cases are written with the intent to detect defect or not
2. Whether understanding of the requirement is correct or not
3. Whether impacted area are identified
4. Whether positive & negative test cases are covered or not
5. Test case coverage is adequate or not

There are 4 types of review

1. Self review- self

2. Peer review- teammates
3. Internal review- PO
4. External review- Client

Self-review

- As a tester will do the review of their own document of test cases these process is known as self
review
- We have to check our own document to verify whether all the requirement have been covered or
not

Peer Review

- Tester have written the test cases

- Test lead / senior tester will review the tester test cases these process is known as peer review
process
- This review is conducted by test lead / senior tester of the team
- As a tester we have send excel sheet to them through mail

Mail-

Subject- Review of Login test cases

Hi Roy,

I have written test cases of module “Login” kindly go through it & let me know if any changes are
required. Please find below attached test case design document of “login”.

Having reviewed test cases they provide comments/feedback through the mail

Mail-

Hi Mangesh,

You are good enough, now we can arrange the internal review for the same

Or

Add or modify these test cases (mention comment of test cases- comment column)

Internal Review

- In internal review, PO will review test cases these process known as internal review
- The review is taken by the PO & sometimes with project team (Scrum Team)
- Test lead sends mail invite to project team (scrum team) & PO
- So, we have to share our screen & we have to explain it. After that we take feedback from them
- PO is responsible person to review your test cases
- If PO is not available so that time SM is responsible person to review your test cases

Mail-

Subject- Internal Review of Login test cases

Hi Khushto,

I have written test cases of module “Login” kindly go through it & let me know if any changes are
required. Please find below attached test case design document of “login”.

Having reviewed test cases they provide comments/feedback through the mail

Mail-

Hi Mangesh,

You are good enough, now we can arrange the external review for the same

Or
Add or modify these test cases (mention comment of test cases- comment column)

External Review

- In external review, client team/ UAT team will do test cases review these process called external
review
- We conduct this external review when generally project is complicated
- Test lead send mail invite to all team like PO,SM, tester (PO, SM, Dev Team, Test Team) &
client
- PO/ SM explain that, we have conducted internal, peer, & self review whatever suggestion we
had given, accordingly TC have been updated by the tester

Review 1

Review 2 mentioned in the excel sheet

Review 3

- After this as a tester we have to share test case design document in front of them
- Client verify all the requirement have been covered or not
- We take feedback, suggestion, comments from client
- After the meeting MOM are shared, which includes
1. On TC, what we have discussed
2. Suggestion, feedback, & comments from client
3. New modification if any
4. CR + technical implementation
5. After this review, we have to modify TC accordingly to the Suggestion, feedback, &
comments from client

Note-

In my project, we cover internal review & external review

In review, if we got Suggestion, feedback, & comments – tester will accept the Suggestion,
feedback, & comments from client are written in excel
Suggestion, feedback, & comments from client as per that TC modify & inform to review PO,
client throw mail

While Test case review we focus on

Test case review Consider parameter
1. Test cases should covered functionality/ requirements
 2. Test cases is covered all functionality
3. Test cases should be not duplicate
4. Test cases should be standard format
5. Test cases should be simple & understandable
6. Test cases spelling mistake
7. Test cases grammar mistake

Do you take any external review?

Yes, we have taken, actually my project was complex, so many modification & new CRs were there. So,
we decide at organization level to review TC documents from the client

Traceability Matrix- (Requirements Traceability Matrix)- TM/RTM

In general we conduct the review but if sometimes requirements are missed then we are covered in the
TM

TM it also called as RTM

It a high level documents to map & trace user’s requirements with test cases to ensure that for each
requirements adequate level of testing is being achieved

In TM- test cases & defects are mapped/link to US/requirements

TM defines- tracing of US, TC, & defect

It is prepared by tester

There are 3 types of TM

1. Forward TM
2. Backward TM
3. Bi directional TM

Forward TM

- FTM is prepared by doing mapping between business requirement/ US & prepared test cases
- In FTM test cases will mapped / link to US/requirement
- Why we do FTM?

1 US – 70TC

2 US- 50TC

I US- 10 Defect
2 US- 5 Defects

Defect Life Cycle

Testing principles