Test Documentation –

Q. 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 Plane

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

Test Policy-

 Test policy documents prepared by Quality control – QC/Testing Head -TH

 Test policy documents company related documents
 Test policy will defines objective of project (types of testing)
 Test Strategy-

 Test Strategy documents define the project objective to achieve, which Strategy we
can applied.
 Test Strategy documents prepared by Testing Strategy –TS & PM
 Test Strategy documents company related documents

Test Methodology-

 Test Methodology documents prepared by PM

 Test Methodology documents Project related documents
 Test Methodology defines depending on environment, which Strategy / approached us
can follow.
 TRM, it is mapping between development stage & testing factor
 PM in Test Methodology hw will TRM (Test responsibility matrix)

Development (SDLC)/ Information Design Coding Testing Maintain

gathering/
Analysis
Test Factor
Authorization Yes No Yes Yes No
GUI/ UI Yes Yes Yes Yes Yes
Functional No Yes Yes Yes Yes
Performance Testing No No No Yes

Test Plane-

 Test Plane documents prepared by Test Lead

 Test Plane documents Project related documents
 Test Plane will contains, Resource allocation, Job allocation, Estimation

Indentify Test Scenarios & Test cases –

 Tester will identify test scenario against the every US

 Test cases designee against test scenario
 Tester will identify test scenario & TCD for every US.

Test cases execution-

 Tester will do the TCE, when we get the build

  In Execution – defects then we will inform to developer & developer has fixed then re-
testing & Regression
 In TCE tester will prepared test proof

Defect report-

 Defect will prepared by Tester.

 What every US assign to tester, US defects report prepared.
 Defect report documents Project related documents

Test Summary Report-

 1A- Test summery report prepared by Test lead

 2B- Test summery report will contains, for every US TCD, TCE, TCS, Defects, etc
 3C- Test summery report documents Project related documents

Final Report/ Test closer Report-

 Final Report/ Test closer report prepared by Test lead

 For that Module, test lead will prepare the Closer report.
 Final Report/ Test closer report documents Project related documents

Software Testing Life Cycle (STLC) –

Q. What is your organization Test process OR what is STLC?

Test Initiation Test Plane Test Scenario

Requirement Test Case Test Case Defect

Analysis Design Execution- sent to
Test Proof developer

Test Summery
Report / Test
Closer
Test Initiation-

 PM will be work in Test Initiation

 Test Initiation stage PM will prepared TRM
 PM will send Final TRM to Test Lead.

Test Plane-
 Test will prepared the Test Plane
 While preparing Test plane, test lead focus, resource allocation, Job allocation &
Estimation
 Test plane will contains, how to test, when to test, what to test & who will test.
 Test Plane purpose to decide time span for testing i.e. Start date of testing & when it
will be end.

Test Scenario & TCD-

 Tester will identify the test scenario against US

 Tester will writes test cases from Test scenario

Test cases execution-

 Developer will sent us a build then tester will do TCE.

 If we found defects in TCE, then we will raise to defects.
 When Developer will fix the defects then tester will do Re-testing & Regression Testing

Defect report-

 Defect will prepared by Tester.

 What every US assign to tester, US defects report prepared.
 Defect report documents Project related documents

Test Summary Report/ Test closer report-

 Test summery report prepared by Test lead

 Test summery report will contains, for every US TCD, TCE, TCS, Defects, etc
 Test summery report documents Project related documents
 Testing Process-

BRS
Development Testing
SRS/FRS/CRS

Design Test Initiation Stage

Coding Test Plane

STLC
SDLC Unit Testing Test Case Design

Integration Testing Test Case Execution & Closer

(Install Build)

Level 0 Sanity/ Smoke Testing

Level 1 BBT/ System & function testing

(If found defect sent to developer)

Level 2 Regression Testing on Modified built

Level 3 Final Regression Testing

Test Plane-
 Test plane is prepared by Test lead
 Test plane preparing Test lead focus
1. Resource allocation
2. Job allocation
3. Estimation
4. Main purpose of Test plane is to decide start & end date of testing
Test plane contain-

1. Test plane ID
2. Iteration
3. Test item
4. Feature to tested
5. Feature not be tested
6. Test pass / Test fail
7. Test deliverable (If we have testing  complete of TCD)
8. Test environment
9. Critical issue/ Road Block/ Suspension criteria
10. Testing Task
11. Staff Training
12. Roles & Responsibilities
13. Signature & approval

Coding (Unit Testing)Integration Testing  Tester BBT  UAT testing

Entry criteria of BBT Complation of Unit Testing, entry criteria of BBT

Exit criteria of BBT Entry criteria of UAT OR complation of BBT itself, exit criteria of BBT

Test Scenario & Test cases-

 Tester will identify test scenarios against US

SRS

Use case/
User Story
Test
scenarios
Test cases

BA BA Tester Tester
SRS-
 SRS defines function requirement to develop & System requirement that will be used.
 SRS called FRS/CRS
 SRS will be derived from BRS
 SRS will prepared by BA
 SRS will contains
1. Functional Requirement
2. Functional flow diagram
3. Use cases (1 specific requirement)
4. Screenshot

Use Case-
 Use case defines functionality of specific requirement
 Use case also called User story in agile
 Use case will prepared by BA
 Use cases derived from SRS
 Use Case contains
1. Description
2. Acceptance criteria

Test Scenario-

 Test scenario defines functionality of the application/ build

 Test scenario derived from User cases/ User story\
 Test scenario prepared by Tester
 Test scenario will defines “What to test”
 From Test scenario we can writes multiples test cases
 Test scenario also called “High level test case”
 Test scenario writes in only +ve ways
 Ex. Login Page- US
 Description- Username text box only- Mobile or email id
Password- Only accept 4 to 6 charter/string only

Username-

Password-

Submit
Test scenario-

1. Verify that username text box by passing mobile no.

2. Verify that username text box by passing email id.
3. Verify that password text box by passing charter/string

Test Cases-

 Test cases validation of test scenario by performing by step by step operation

 Test cases derived test scenario
 Test cases will writes by Tester
 Test cases defines “How to test”
 Test cases will contains input, Output & result
 Test cases always low level test cases
 Test cases always contains +ve & -ve ways
 Ex. Test scenario- Verify that username text box by passing mobile no.
 Test cases-
1. Verify that username text box by passing idea mobile no.
2. Verify that username text box by passing Vodafone mobile no.
3. Verify that username text box by passing Airtel mobile no.
4. Verify that username text box by passing BSNL mobile no.
5. Verify that username text box by passing JIO mobile no.
6. Verify that username text box by passing invalid mobile no.
7. Verify that username text box by passing blank/null mobile no.

Test cases-
 Test cases against the test scenario
 Test case will write in excel sheet / direct project management tool (JIRA/
HPALM/TFS)
 Different parameters while writes test cases
1. Business logic test cases/ Functionality related test cases
2. Input based test cases
3. UI test based test cases
  Ex. US- Login VCTC VCTC student & staff login page

Description Acceptance criteria

Login page of VCTC application
contains Login text box, password
text box & sign in button.
This login page will provided for
VCTC student & staff login, from
which they login into their VCTC
account page. Login page will
contains all page as per standard
color as suggested.
1. Login text box accept only mobile no. Existing in your
domain (Vctc)
2. Login text box will unmasked (display)
3. Login text box doesn’t accept mobile no. other then
VCTC mobile number (error message- Enter valid data)
4. Password should contains char/string of 6 to 8
5. Password text box will accept One Capital letter, One
Small letter, One special char, One number
6. Password text box will masked (not display)
7. Password text box doesn’t combination other than One
Capital letter, One Small letter, One special char, One
number (error message- Enter valid data)

Test Scenario-

1. Verify VCTC login page by passing mobile no. in username text box
2. Verify VCTC login page by passing character/ string into password text box
3. Verify VCTC login page by pressing sing in button.

Test Cases-
Test scenario -Verify VCTC login page by passing mobile no. in username text box
1. Verify username text box will present hint text
 2. Verify username text box will present username icon
3. Verify VCTC login page by passing Idea mobile no. in username text box
4. Verify VCTC login page by passing Vodafone mobile no. in username text box
5. Verify VCTC login page by passing BSNL mobile no. in username text box
6. Verify VCTC login page by passing Airtel mobile no. in username text box
7. Verify VCTC login page by passing JIO mobile no. in username text box
8. Verify VCTC login page by passing MTNL mobile no. in username text box
9. Verify VCTC login page by passing invalid mobile no. other than vctc student & staff in
username text box
10. Verify VCTC login page by passing blank/ null mobile no. in username text box
11. Verify VCTC login page by passing min from 2 to 9 digits mobile no. in username text
box
12. Verify VCTC login page by passing max from 11 to 15 digits mobile no. in username
text box
13. Verify VCTC login page by passing email id/ charter/ String in username text box
14. Verify VCTC login page by passing combination of digits & charter/string into mobile
no. in username text box
15. Verify VCTC login page by passing mobile no. in username text box, which in
Unmasked
Test case-
Test Scenario-Verify VCTC login page by passing character/ string into password text box
1. Verify password text box will present hint text
2. Verify password text box will present username icon
3. Verify VCTC login page by passing a values (Ab1@vctc) in password text box
4. Verify VCTC login page by passing a values (Pq2@vctc) in password text box
5. Verify VCTC login page by passing a values (xY3@vctc) in password text box
6. Verify VCTC login page by passing a values (3Gj@vctc) in password text box
7. Verify VCTC login page by passing a values (@111Ya) in password text box
8. Verify VCTC login page by passing a values (@111Ya) in password text box
9. Verify VCTC login page by passing a values (@111Ya) in password text box, which is
masked
10. Verify VCTC login page by passing a values (YYYY) in password text box
11. Verify VCTC login page by passing a values (xzcv) in password text box
12. Verify VCTC login page by passing a values (@#$%) in password text box
13. Verify VCTC login page by passing a values (1234) in password text box
14. Verify VCTC login page by passing a values (YYzz) in password text box
15. Verify VCTC login page by passing a values (YYzz11) in password text box
16. Verify VCTC login page by passing a values (YYzz@@) in password text box
17. Verify VCTC login page by passing a values (AAbb11@vctc) in password text box
18. Verify VCTC login page by passing a values (AAbb11@vctc) in password text box
19. Verify VCTC login page by passing a values (Ab1@) in password text box
 20. Verify VCTC login page by passing a values (Ab1@@) in password text box
21. Verify VCTC login page by passing a values (AAb1@) in password text box
22.

Test case-
Test Scenario-Verify VCTC login page by pressing sing in button.

Test cases format-

 Excel sheet Test cases will contains

1. Test ID
2. Priority
3. Reference
4. Test scenario/ Title
5. Re-request
6. Test cases
7. Test data
8. Test cases steps
9. Expected result

Q. Writes the Test cases for following thing?

Answer- Side- https://artoftesting.com/pen

1. Whatup, Facebook, Filpkard, Paytm, etc

2. Pen, Fan, Chair, Keyboard, Lift, Mobile, etc
3. Scenario based- Application collage admission page

Test Cases Review-

 Review- To check correctness & Completeness of the documents.
 4 types Review for test cases
1. Self Review
2. Peer Review/ College Review
3. Internal review
4. External review

1. Self Review-
 Tester will do the review of their own Test cases these process called self review

2. Peer Review/ College Review-

 Tester have written test cases
 Test lead/ Senior tester will review the tester test cases these process called Peer/
College review

3. Internal review-
 In internal review, BA will review test cases these process called Internal review
 In Internal review, When Tester have written test cases, Mail to BA about test cases
 BA will set up meeting with tester, test cases review

4. External review-
 In external review, Client/ UAT team will do test cases review these process called
External review
 In external review, When Tester have written test cases, Mail to Client/ UAT team about
test cases
 Test Lead will set up meeting with client/ UAT team
 Test Lead will start meeting & ask to every tester, to do review with Client/ UAT team
 External Review involved Test Lead ,Tester, developer & Client/ UAT Team

 In my Project, we will cover Internal Review/ External review

 In review, if we got suggestion/ Comments/feedback Tester will accept the
suggestion/ Comments/feedback are written in excel sheet in suggestion/
Comments/feedback column.
 For suggestion/ Comments/feedback, test cases modify & inform to review BA, Client/
UAT team throw Mail.
Parameter in Test Cases review –

 Test cases review consider parameters

1. Test cases should covered functionality/ Business logic related
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 or understandable
6. Test cases spelling mistake
7. Test cases grammar

Test cases execution-

 When developer will sent us a build then we will start the testing
 Build Developer will sent Mail attachment (Unit Testing + Tables name + URL/URI)
 Tester will do TCE
 While TCE, tester will prepared the Test Proof
 In TCE, if we found defects then we will raised/ create into Project management tool
& Mail/ Inform to developer

Traceability matrix-
 Traceability matrix  Test case & defects mapped/Link to User story/ requirement
 Traceability matrix defines tracing of US, Test case & defect
 2 types Traceability matrix
1. Forward Traceability matrix-
 In Forward Traceability matrix test cases (Excel sheet) will mapped / link to US/
requirement
 Forward Traceability matrix  Excel sheet will be attached to US

2. Reverse Traceability matrix-

 In Reverse Traceability matrix defects will mapped / link to US/ requirement
 In Reverse Traceability matrix  Created Defects will mapped/Linked US/
requirement
 Traceability matrix will be prepared in Project Management tool (JIRA/
HPALM)
Defects life cycle-
 Defect- In Application/ build while TCE, if we found error these it is called defects
 Defect life cycle- The journey of the defects, from start to end it is called defects life
cycle

Closed

Fixed

Re-open

Rejected
New Open

Differed

Tester Developer Tester

 New- In TCE, if tester found a defects then we will create/ raised in JIRA/ HPALM 
Defect status = New
 Tester will mail (JIRA/ HPALM) to developer
 Open- When developer is doing analysis on the defects. Defect status = Open
 Fix – When developer defects then developer mark. Defect status = Fix
 Developer will again sent a mail (JIRA/ HPALM) to tester
1. Closed- Tester will check the defect has working fine/ correct. Defect status =
Closed
2. Re-open – If same defects have been occurred again. Tester will mark Defect status
= Re-open. Tester will mail (JIRA/ HPALM) to developer
  Rejected- If defects is invalid then developer will reject the reject. Developer will mark
Defect status = Rejected
 Developer will again sent a mail (JIRA/ HPALM) to tester
 Deferred- When developer will not fixed the defects in current sprint OR developer
has more work in current sprint so he is no time to fix OR developer priority of US is
changed OR Those US which is not completed in current sprint and it is moved to
next sprint, these defects related to these US. These defects status mark Defect status =
Deferred
 Deferred status will mark by PM, Designer, BA
 Deferred defects  JIRA/ HAPLM drop down (Defects type = deferred)

Duplicate defects-

 Duplicate defects are same defects raised again one time

 Ex. Paytm – Recharge module – Error while doing BSNL Maha  Defect (1021)
 Ex. Paytm – Recharge module – Error while doing BSNL MP/ UP  Defect (1222)

Re-producible defect-

 Defect which is occurred again & again called re-producible defect/ Know defects
 Re-producible defect due to functionality which is not supported in SIT environment.
 Re-producible defect due to Database connectivity
 Re-producible defect due to deployment process
 Re-producible defect in JIRA/ HPALM (Re-producible drop down – Y/ N)

Blocker defects-

 Defect which is shows some part of functionality is not working of application/ build
 Ex. Paytm  Recharge module- BSNL mobile no. not accepting

Show stopper defect-

 Defect which is stop the functionality of application/ build

 Ex. Paytm  After click on Recharge Icon- Recharge module is not opening
Bug leakage-

 Defect/ Bug which is missed from SIT and found in UAT or Product
 Occurred due to – Functionality is not understand, Deployment is not proper,
Environments problem of UAT or Product

Reports-
 In my project, following
1. Daily wise report  Working report
2. Test cases execution  Tester will prepared Test proof
3. Defect report  Tester will prepared defect report
4. Test summery report  Test lead Current Sprint US (TCD, TCE, TCS, defects, etc)
5. Test Closer report Test lead (Module test summery)

Defect report-

Test summery report-

Test Closer report-

Interview question-

1. What is your origination testing process? OR Tell me about STLC?

2. What is difference between SDLC & STLC
3. How you’re prepared test plane? What it will contains
4. What is difference between Test scenario & Test cases?
5. Consider a page which is used for admission; write Test scenario & Test cases?
6. What are different types of Reviews process? Which review is following in your
project?
7. If you got comments/ suggestion in review, what you will do?
8. What is traceability matrix and where you are prepared these?
9. What is defect life cycle?
10. What are differed defects? Who will decide differed defects status?
11. What is re-producible defects & duplicate defect? What is your approach on these?

Real time interview question-

Q. What role & responsibility?

 Requirement / US analysis (grooming meeting)
 Test scenario identify
 Test cases design
 Test cases review (internal/ external review)
 Test cases execution – Test proof
 Defect report
 Test summary report (help to test lead)
 Client interaction (Sprint review meeting)
 Daily stand up / Scrum meeting attend
Q. When you know that testing is completed?
  All test cases need to execution
 All defects need/ should to fixed
 Traceability matrix need to be completed

Q. How many test cases per day you will write & how may test cases you will execute per
day?
 It totally depends on complicity US
 An average I am writing (TCD) per day/ US 25 to 30 test cases.
 TCE, it totally depends on complicity of testing OR complicity of functionality
 An average I am executing (TCE) per day 15 to 20 test cases.
 In Automation, we are automating 4 to 5 test scripts

Q. How many defects you have raised per day?

 It totally depends on complicity of US
 If developer has done wrong coding, then I will get more defects
 If developer has done properly coding then I will get less defects
 An average, I am creating/ raising 4 to 5 defects per US.

Q. When developer is not accepting your defects then what is your approach?
 When I found defects, I will rise to the developer & with defects I am attaching
screenshot.
 But still developer is not accepting, then we will take call with developer à I will share
my screen and show cases defects.
 But still developer is not accepting, I will mail to Test Lead, PM, designer & all
developer
 Same things we will point out in daily stand up meeting

Q. If defect is found in last day of sprint OR if we found defects in last moments, then what
is your approaches?
 Tester – High priority defects will be informed to the developer & fix ASAP
 If developer is fixing defects à so we will extend you work
 If developer is not fixed all defects à So we will work in Saturday & Sunday
 If developer is not fixed all defects à So we will work in Saturday & Sunday
 If developer is not fixed all defects in Saturday & Sunday à So in next sprint we will
prepare a US with name “Carried over Bug” (PM, BA)

Q. If we have found a defect related to environments problems so what is your approaches?

  When I found defects, I will rise to the developer & with defects I am attaching
screenshot.
 But still developer is not accepting, then we will take call/ meeting with developer à I
will share my screen and show cases defects.
 We will tell to the developer kindly check deployment process. (Dev environment & SIT
environment)
 Tester will do hard refresh OR I will clear all cashes & cookies and we will test
application
 But, still there is a problem then we will inform to PM, Test Lead & developers
 Same things we will discuss with Scrum meeting/ Daily stand up

Q. What problems you have faced in your carrier Or What challenges you have faced in
testing?

 If we have lack of knowledge about domain/ project

 If we have less test data
 If we have less resources in the project
 If developer is not communicated properly
 If we have problem in environments
 If we have problem in deployments
 Frequent changes in requirement

Q. In Regression suite how many test cases are present?

 Project  Module (Rent payment)
 Initial developments (20 US)  Manual Testing (1 US= 25 to 30 TCD)
 Regression suite test cases (1 US= 5 to 7 TCD)
 In Module (Rent payment)  Regression suite will contains (50 to 60) Automation
Testing

Q. Difference between functionality & Non- functionality testing?

Functionality Non- functionality
Internal feature we are testing External feature we are testing
In functionality testing, we are checking In Non-functionality testing, we are
functional feature for increasing checking performance feature for
increasing
In functionality testing we performed - In Non- functionality testing we performed
 BIEBSC - RSSIISPG
In functionality testing, checking will be In Non-functionality testing, checking will
defied in US/ requirements not be defied in US/ requirements

Q. Difference between User story & Use cases?

Use cases User story
Use cases will be driver from SRS User story will be derived from Use cases
Use cases defines in-depth knowledge Or all Use story defines short knowledge Or all short
details about the requirement about the requirement
Ex. Only valid cancellation types will be listed Ex. 1. For Saving a/c – 5 drop down option
on the cancellation tab 2. For current a/c – 7 drop down option

Project management tool-

 Project management tool- JIRA/ HPALM
 Project management tool- JIRA/ HPALM  Assign US, Assign Task, Defect raised, etc
