Batch- 8 Jan 2022

Date- 11 Jan 2022

Manual Testing & Automation Testing

Manual Testing

Manual Part I

Different methodology/ process / model

1. SDLC / Fish model

2. Waterfall
3. V Model
4. Agile model ----90-95%

Different type testing

1. Sanity Testing / Smoke Testing

2. System & functional testing – 4 main type – 14 type of testing
3. Retesting & Regression Testing
4. User acceptance testing – 2 type

Manual Part 2 / depth part

Real part- Test case design, Review the test cases, test case execution & defect etc.

Documentation/report - Company level / project document

Project management tool- JIRA & HPALM

Database Testing/ Backend Testing

SQL – Oracle 11g

API/Web service Testing

SOAP & Rest services

Tool- Postman & SoapUI

Project

2 live project

1. Investment banking domain

2. Telecom domain

DT- Database Testing

FB-

Register

FN

LN
 Mb.No

Email Id

Submit

Creation of the UN & PW

UN- Mangesh

PW- Mangesh123

Store all the information in the Database

Database- No of table are present

Table – No of rows & columns are present

Table – Register

FN LN MB. No Email id UN PW
Mangesh Mangesh123

FB-Login

UN-Mangesh

PW-Mangesh123

Login

Data fetch- SQL language

API (application programming interface)/ Web service testing

Amazon- Request- Click on the mobile- server – database- pages – information – display – frontend- response

API- request & response

Ex- Bike- request- Starter – event create- engine – response – start the bike

Use tool- postman & soapui

Project- 2 live Project- Project name- Flipkart- duration 2 years

1. Project team/ main team- application new feature / modules/ functionality add/ implement
2. Support team/ Maintenance team-Existing application issues/defect/end user quires etc.-

6 month

Project team-

Application-

Filpkart

New feature – to buy different product

Modules-mobile/ electronics/ sports/glossary /registration/ login

Functionality add-

Login

UN-

PW-

Login

Implement

Application done- delivery – owner

-End user

Support Team

Existing application Issue/ error /mistake

Defect/ error

End user queries / problem

Tickets

Team Size

- I have worked in project / main team

- Team size
- Project team size /main team size (16-18 peoples)
- Delivery manager/ Solution Master(DM/SM)-(1)- project against deliver to client
- Business Analyst/ Product owner(BA/PO)-(1)- BA always communication with client for the
requirement
- Project Manager/ Scrum Master(PM/SM)-(1)-project work/task assign & monitor-work progress
- Designer/ System architecture/ solution architecture- (1)- application against design (developer-
experience more than 10 to 12 year)
 - Developers(8 to 10)- coding against the application
- Tester(3 to 4)- Test against application

- Support team/ maintenance team size (5 to 7 people)

- Project manager/Support manger –(1)- project tickets/ task assign & work progress
- Developer (3 to 4)- coding / programming against the issues/ tickets
- Tester (1 to 2)- test against resolved issues

- In your / our company – both - project team & support team are present in the current working project

- Project team & support team in the project- decide – client

- Ex- HSBC client -project – Project team – cybage & support team- Accenture

- EX- Dream 11 project- Project team & support team – capgemine

Interview Question

1. What is team size in your last project?-18

2. What is the size of developer in your current working project?- 10
3. What is the size of tester in your current working project?- 4
Role-
1- tester- manual testing
2 -test lead- manual / automation/ api testing
3-tester- automation testing
4-tester- manual testing
4. Are you working on which team?
Project team

12 Jan 2022

Basic Definition

1. Software
2. Testing
3. Software Testing
4. Software Testing Methods
5. Happy flow of the organization (Software)

Software-

Collection program

Set of instruction

Takes Input & generate output

 “Software is collection of specialized program which takes user input & generate the desired
output”

Ex- Flipkart- user input – mobile – generate output- display verity of mobile in front of you

Ex- Phonepay, Google pay….etc

“it is set of programs, procedures & services associated with the operating system (which make it
run)”

OS- Mac, Windows, Linux, Android, IOS

Testing

Correctness / finding bugs / check the process / output & defect/ check defect

“Testing is a process to checking whether the given software / application is generating desired output”

Ex- Phonepay – Mobile Recharge – to recharge the particular number- jio/idea/Vodafone/bsnl

“it is process to check where the software / application produce desired output = for given input i.e. finding
how something work”

Software Testing

“It is process to check completeness & correctness of software / application w.r.t customer requirement”

“Verification & Validation of software is called as software testing”

Verification- means whether the software is correctly implement or not

Validation- means the implemented software meets the customer requirements or not

Software Testing Methods

1. Manual Testing
2. Automation Testing

Manual Testing- testing an application manually without using automation tool

TCD/Review/TCE/generate report manually

Automation Testing- testing an application using automation tool / programming language

Tester- one application test in different different way this is nothing but good tester

Ex- Phonepay – Mobile Recharge – to recharge the particular number- jio/idea/Vodafone/bsnl

Ex- Phonepay – Mobile Recharge Developer-– to recharge the particular number- develop – only check its
working fine – he check only one way

Ex- Phonepay – Mobile Recharge Developer-– to recharge the particular number- tester – multiple way check
its working fine – he check multiple way- Jio/idea/Vodafone/bsnl

Ex. Google Map

Pune- Latur – display different root - 4 to 5------road problem / stuck

How the application / software work for the multiple input & how it produce the desired output

Software development process in organization

Application Name- Rockstar Cloth

Men Women

Men – Shirt Pant

Shirt – Brands, Size, Half, Full, Price

Pant- Bands, Size, Type, Price

Women- T-shirt Sari

T-Shirt- Brands, Size, Price

Sari- Brands, Price

Company- BA

Technical Team – PM, Solution team, Developer team, Tester team, CR (Change in requirement)

Solution Team- 1year – BA/PM

PM-
Dev Team-

Complete – Unit testing / WBT/ Integration Testing

One way scenario hit

Testing Team-

Sanity Testing – Positive scenario hit

Smoke Testing- Positive scenario hit

Finding root cause of defect

System & Functional Testing /BBT- from start to end all steps are check

Retesting- having found defect, it is sent to developer- developer fix defect- again sent to tester for
retesting

Regression Testing- impact to the other module after code change

Sign off

UAT/Client Testing

Sign off

Production/Live

Release

End Users

Maintenance

Ex. Mobile field

Positive way
Only enter 10digit
Negative way
We enter less than 10 digit
We enter more than 10 digit
We enter different character
We enter 10 digit

13 Jan 2022

Software development process

Software Quality Assurance

Software development process

There are different stages

1. Customer
 2. BA
3. Developer
4. Testing
5. Final Product
Customer (Requirement)

Business Analyst _BA (Collect

Requirements)

Developer

(Design & Develop as per Requirements)

Tester

Final Product

Customer

1. Customer wants some application/ software/product

2. Customer comes with the own idea/requirement

BA

1. BA- Collect/gather all the requirement

2. BA- responsible for information / requirement gathering
3. BA-make document & send to the technical team

Technical Team (PM,ST,DT,TT)

1. once document got from the BA then technical team understand the exact requirement of the
customer, analysis it, priority of the customer & assign to the experienced person on the priority
module with team

Developer Team

1. Understand the customer requirement

2. according to the priority of the customer requirement developer starts working on it / start
developing the code/module
Test team

1. Understand the customer requirement to prepare test case design

Positive testing

Provides valid data (correct) & checks how application behaves for valid data

Ex- Login page

UN- Mangesh

PW- Mangesh123

Login

Ex. Register page

FN- Mangesh- Char.

LN-

Mb.No- 9404624368

Negative testing

Provides invalid data & checks how application behaves for invalid data

Ex- Login page

UN- Mangesh
PW- Mangesh123
Login

UN- Mangesh
PW- blank
Login

“Please enter valid UN & PW”-----Validation message

UN- blank
PW- blank
Login

UN- blank
PW- Accept- 4 char, 1digit, 1special etc
Login

Ex. Register page

 FN- Mangesh- Char.
LN-
Mb.No- 9404624368
Enter less than 10 digit
Enter more than 10 digit

“Please enter 10 digit mobile number”- Validation message

Final Product

After all the testing final product is ready

Software Quality Assurance – ex-compare to rockstar cloth

Customer- BA -

BA- Previous client – req.- collect properly/ meet- to meet all the customer expectation- costing
project - timely deliver - maintenance -6month /1year

1. BA & client are involved

2. Communication happen between the BA & client
3. It is process , which measure & monitor the development & testing factor
4. Check the quality

SQA depends on the following factor

1. To meet the customer requirement

2. To meet the customer expectation
3. Cost of the project
4. Time to deliver
5. Maintenance

To meet the customer requirement

Identified customer requirement & purpose

Which type of application customer wants?

Which is the domain of the customer requirement?

Ex. Banking, Telecom, insurance, healthcare , ecommerce etc

To meet the customer expectation

Ex. Banking

Privacy –Security – gather – aadhar card/pancard- sensitive data – privacy- big transaction

Performance –Speed- with & without load condition

 Load balance

Work properly- heavy load

Ex. Google meet – with load- 133 & without load-10/50/90

Ex.FB

Ex- Instagram

Cost of the project- MNC- costing-hr- employee- day

Customer requirement

Team size

Duration to complete- ST- 1year- 100cr- customer- 6month -–BA-150cr- 18- 36

Type of project- Critical project (Banking) & Normal Project (gaming)

Resources required-

Critical project – Resources more

Normal project- Resources less

Domain

Time to deliver

BA-information collect- send team- ST/DA- design- decide –duration/time-deliver

Rockstar cloth- 6month

Client – 5month – mail- reminder mail

Client -5.5 month –mail-reminder mail

Duration of delivery exceed

Penalty – reduction in fund ex customer give 50cr – after penalty – he give only45cr

Escalation is nothing but penalty

Maintenance

After delivery of the project, if any problems/technical difficulty occurs in such case company
has to fix without any cost

Duration decided by customer & BA

Technical support –KPO- knowledge process outsourcing

 Non-technical support- BPO- business process outsourcing

Ex. customer care call

Interview Questions

What is SQA?

How the SQA is maintained in your organization?

How you can deal with the SQA?

Project having 2 categories

Critical project

Resources requirement ratio- 2 (developer):1(tester)

Ex. Banking project – 2dev & 1 tester

100 developer- 50tester

Normal project

Resources requirement ratio- 3 (developer):1(tester)

Ex. gaming project

100 developer – 33tester

Process / methodology/model

Process a way to develop & test the software/application

Ex. Kite, Phone pay, paytm….etc.

1. SDLC(Software development life cycle)

2. Waterfall model/process
3. V model/process
4. Agile model/process-90/95%

Who will decide the process?

 If client has IT department-then client will decide the process-----ex.HSBC

 If client not has IT department- then company will decide the process (BA & client)….Ex.cred
 Process decided
 Ex. HSBC company-client has IT department-wipro-project process decide by client
 Ex.cred-client don’t IT department-Accenture-project process will decided by company
Client- Developer /Tester -HSBC Accenture –developer & tester –

Client- rockstar cloth- capgemini-BA – decide which process use

SDLC- Software development life cycle

SDLC have two types

1. LCD- life cycle development- developer are involved

2. Life cycle testing-tester are involved

SDLC-

It is a process used by the software company/industry/organization to design, develop & test the
high quality software/ to deliver the high quality software

Software is process which include different stages (6stage)

1. Information /requirement gathering /BRS (Business requirement specification)-BA-collect

the requirement from client/customer
2. Analysis /SRS (software requirement specification)-BA-Functional requirement
3. Design- Designer-prepare –HLD(high level design),LLD(low level design)
4. Coding-developer-developer will do coding on LLD
5. Testing-tester-tester will TCD(test case design), Review, TCE(test case execution)
6. Support/maintenance-application/software support

1. Information gathering

 BA is responsible person for information gathering

 Information gathering means requirement gathering
 In this stage BA will intract with client & collect requirement related to client
project/business
 BA prepared one document that document is called as BRS(business requirement specification)
 BRS defines business related requirement for the application
 Ex. Client project-platform-end user application login-access/plan-service you see-hostar /
amazon prime
 BRS document we don’t get (developer/tester/designer)
  BA is taking requirement from client & prepare BRS document

Simply acts as bridge between

BA

Client Technical Team

Analysis

 In analysis stage, BA is also involved/working

 BA will communicate to the client & collect the functional requirement from client
 BA again prepared a document SRS(software requirement specification)
 SRS also called FRS (functional requirement specification)& CRS(customer requirement
specification)
 SRS- defines software/functional requirement to be development/developed & system
requirement that will be used
 Ex. Paytm-Recharge module-mobile no test(10 digit no)&circle selection &operator test box-
browse plan
 SRS will contain
1. Functional requirement (project- multiple requirement)
2. Functional flow diagram (step by step flow)
3. Use cases (specific requirement / 1 requirement)
4. Screen shot/snapshot/prototype/dummy model

Date- 18/01/2022
1. Functional flow diagram (step by step flow)

Ex. Flipkart- Buy the mobile

Register

Login

Home Page

Mobile

Select-MI

Add to crat

Address
 Payment

1. FFD- represent step by step stages of the application/module

2. FFD- represent relation between the task
3. FFD- represent dependencies between the task

2. Functional requirement (project- multiple requirement)

FR- meeting the attributes which are required to complete specific function/task

Ex. Register on Kite/banking app

FN- Should accept character, length-48 | special symbols, digit, decimal, space not allowed

LN- Should accept character, length-64 | special symbols, digit, decimal, space not allowed

DOB- DD-MM-YY or MM/DD/YY or DD/MM/YY format| only digits

Email Id- Should accept character, special symbol, digit, decimal, a-z, length

Phone number- should accept only digit

Submit

3. Use cases (specify requirement/ 1 requirement)

Description- details about requirement

Acceptance criteria – does & don’t about requirement

UC- combination of – Input + process + Output

Checking the functionality for available input, process & output

Ex. Use cases for online shopping

Register

Input Login Output

Submit

UC- Test Scenarios- Test cases – entire system- start to end test

UC- help to identify test cases – cover the entire functionality

4. Sanpshot- application without functionality

Sanpshot is also called dummy model, prototype, format, review, screenshot

Snapshot provide idea to developer how SW suppose look like after development

Snapshot is created by BA

Uses Irise- software for snapshot creation

Visualization of functionality before development of product

Irise-8.1 version

 When BA will completed the SRS documents, then BA will sent these documents to
developer & tester, designer & PM
 BA will sent these documents throw Mail to Developer & Tester team
 Developer & Tester team will do the analysis/ understand the documents
 If we have doubt about SRS documents, then developer & Tester team will communicate
to BA (For communicate we will conduct meeting)

Difference between BRS & SRS?

BRS SRS
Business requirement specification Software requirement specification
This document generally consists of In SRS document all functional and non-
complete scope of the project, functional requirements are covered.
performance, requirement, and usability.
BA people prepares BRS BA people prepares SRS
From client BA collects the requirements and SRS is derived from BRS
prepares BRS document
Gathering Customer requirements Gathering Software & Technical Req.
Use cases are not present in BRS Use cases are present in SRS.
Overall req. Detail req.
E.g., Banking Domain
Sign Up page Sign Up page-Logo,UN,PW
Home Page
Account Information Number, Special Character
Contact List
Ex. Investment banking domain Ex-functional requirement
Kite
Register Register
Login FN
2FA LN
Dashboard Pan
Watch list Mb.No.
Order DOB
Position Email id
Fund Login
Profile UN
PW
Login button
Forgot PW

Date- 19/01/2022
Design

- BA- sent- SRS- designer

- Designer start working on it
- Designer prepared HLD & LLD
Ex.
Men Women
Men- Shirt Pant
Shirt- brands, size, price etc…..
- System architecture or designer architecture or solution architecture
HLD
LLD

HLD

- High level design is developed by design architecture

- Designing structural functionality of the main module is known as external design
- Include relation dependency of main module
Ex. Register – login- 2FA- Dashboard
- Include what & how any main module work

LLD

- LLD is developed by front end developer / UI developer

- Designing structural functionality of the sub module module is known as internal design
- Ex.
Register- FN-LN-Mb.No-DOB-etc….
 - Static logic of every sub module define

Coding/ Development

- Coding means programming

- One line is code
- Multiple line is known as coding/programming
- It is set of programming language designed, written by developer/programmer known as coding
- Coding- working- developer
- Developer we do the coding on LLD
- LLD-
- HLD- Paytm- Recharge
- LLD- Radio button, mobile number, circle , operator, amount, check box

Developer there 2 types

1. Front end developer / UI developer/ coding

- UI, functionality flow check/develop, process this is developed by front end developer

2. Back end developer/coding

- Data gathering , data management, data security this is done by back end developer
- Table name – FB- Register – Mangesh
o FN
o LN
o Mb.No
o DOB
o Email id
- Table - UN & PW
UN- Mangesh
PW- Mangesh123
- Login
UN- Mangesh
PW- Mangesh123
Login

FED + BED = Full stack developer

Testing
“It is process to check completeness & correctness of application w.r.t. to customer requirement”

There are 3 types of testing

1. WBT- White box testing- developer
2. BBT-Black box testing – tester
3. GBT- Grey Box testing – tester
WBT-
Clear box testing
Glass box testing
Transparent testing
Code level testing
WBT techniques – Unit Testing
Unit Testing
Integration Testing

- This testing is done by developer / coder

- Coding level testing – check or test completeness & correctness of program
- Once the developer complete the programming or coding then developer checks or test their own code
& if any defect/error found then developer to solve it
- Developer test only positive way
- Developer aware about the internal coding of the application
- Developer – test- own code- sure – there is no defect/error
- Developer can’t send the code to the tester without doing white box testing

Ex. Login page

UN
PW
Login

BBT-

- Tester is responsible person to do the BBT

- It’s also called as build level testing – Url
- It’s also called as system and functional testing
- Tester verify / validate internal functionality of application depends upon the external functionality or
external interface (front end)
- BBT- overall functionality of application is checked step by step from start to end
- Tester not aware about the internal functionality – validate- based external functionality ot front end
- Ex
- Sign up- FN,LN, Email id, DOB
Information fill-up- back end
Fill up front end – external functionality
- Verify the application in the positive way & negative way
- Build/Url- https://paytm.com/recharge

GBT- Build- Url

- Combination of WBT & BBT

 - Tester is responsible person
- Tester required some programming knowledge --- courses/ experience candidate-
- Whenever final software is handover to the tester, tester check its functionality & if any defect/error
found/ occurs in the output of function in such case tester makes some changes in code itself instead
of assigning to the developer
- SRS- Mobile number required – with country code -+91
- Developer develop only mobile number –GBT- change code itself

Advantages- Efforts & Time Save

Difference between WBT & BBT

WBT BBT
Performed by developer Performed by tester
WBT is 2 type /technique BBT is different type
1. Unit testing 1. Sanity/smoke
2. Integration testing 2. System & function
3. Retesting & regression….. etc
WBT- check –own code- logic for code, condition Tester will check
statement, loop, branches etc… Functional Coverage-6type
Input domain coverage
Error handing coverage
Backend coverage
It’s called code level testing Build level testing
Clear box, glass box, transparent testing System & functional testing
Developer – check own code Tester – verify overall functionality from start to
end
Developer aware about the internal coding Tester are not aware about the internal coding

Date- 20/01/2022

Question- Testing start before development or after development?

Testing having 2 basic way

1. TCD
2. TCE

Customer – req.
BA- collect the req.
BA- prepare- BRS
BA- prepare- SRS

After the completion of the SRS. BA sent this document to the technical team

Design/ Developer Tester

After getting document after getting the document

Understand the req. Understand the req.

Design TCD
HLD/LLD
TCD- Review- self/peer/internal/external
Coding

Testing
Unit
Integration

Test case execution

Review- Pass/fail
Defect review

Maintenance/Support
- After the delivery of the project / application/ software, if there is any problem or any technical
difficulty, in such case organization has to fix the difficulty without any cost -6/1/2
- Maintenance
Technical support – KPO- Knowledge process outsourcing
Non-technical support – BPO- Business process outsourcing

Ex. Customer care

Net recharge – 499/-
Call- customer care
First person- BPO

Call- KPO
Technical

Fish Model- Advance version of SDLC

Information Analysis Design Coding Testing Support

Gathering (BRS) (SRS) (HLD, LLD) (Developers) TCD, TCE

Review (BA) Review (BA) Review (Design) WBT (White BBT (Black
Box testing) box testing)
 Static testing/ Verification / Dynamic testing / Validation
Quality assurance Quality control

- Fish model is an advance version of SDLC

- Fish of consist of verification & validation

Ex.
Tesla & Tata
Pre launching – one charge – 100km- quality assurance
Actual launch – one charge – 100km- quality control

Review/ feedback- Velocity / Faculty

Review – it is process to check correctness & completeness of the own document

Verification
- Verification is nothing but quality assurance
- Verification is nothing but static testing

Requirement Gathering
- BA- collect the customer requirement & prepare BRS

Review-before analysis the SRS document he review the BRS

Analysis
- BA- collect customer functional requirement & prepare SRS

Review
- After the preparation of SRS document, BA has to check SRS document, whether it is correct or not
because all the further process depends on the SRS document
- This checking process is known as review

Design
- SA/DA/SA- design the HLD & LLD
- After completion of design phase, DA has to do the review process

Coding
- When developer complete coding, developer check all the code review
- Developer got the error – fix

Static Testing
- It is process responsible authority do only review process

Validation
- Is nothing but quality control
- Is nothing but dynamic testing
- Dynamic testing focuses on the product quality
 - To test overall functionality of the product from start to end
- Validation include BBT & GBT
- Testing
Test overall functionality
Execute positive & negative test cases

What is difference between verification & validation?

What is difference between static testing & dynamic testing?

Difference between verification & validation

Sr. No Verification Validation

1 This process known as Quality This process known as Quality Control
Assurance
2 It is process oriented, during the It is product oriented , during or after
process - we are providing assurance testing we are providing assurance about
about QA QC
4 Also known as static testing Also known as dynamic testing
6 Verification is review process Validation is End to End Testing process
7 It is an Preventive Technique – Main It is Corrective Technique – identify the
aim is prevent the Defect/Bug defects & provide fixes

Difference between Static & Dynamic Testing

Sr.No Static testing Dynamic testing
1 In Static testing designer BA, & In dynamics testing, Tester will check
Developer are checking their own functionality of the application
documents, design & code review
2 In Static testing BA, Designer & In dynamics testing Tester is working
Developer are present
3 Static testing also called Verification Dynamics testing also called Validation
4 Throw Static testing, we will define Throw dynamic testing, tester will define
quality assurance of the application quality control the of the application
5 Static testing also called In-progress Dynamic testing also called End-progress
testing testing

Model/Methodology/process/implementation of SDLC

Waterfall Model
V Model
Agile Model -90 to 95%

If client – it dept. – client decide the process

If client- not it dept.- company but discussion with client

What is difference between waterfall / v /agile model?

Waterfall V Agile
Requirement are fixes from client Requirement are changed (CR)- Requirement CR are vary/change
 client have to pay some extra but no extra amount is taken
amount from client
Used – small project/ amount - Big project Big project & complex project

It is a step by step or continuous Simultaneous process Flexible process

process

Rockstar cloth-

Requirement are fix- waterfall

Requirement are fix- after sometime customer want some changes – CR – amount pay

Men
Shirt
Pant

Mobile- CR- client have to pay some amount

Waterfall- 10 cr – client requirement fix

V model- 12cr (initial stage-req. fix) + (change in request- req. change- amount pay)

Agile model- 15cr (CR change any time- no limit)

Waterfall

Requirement Gathering

Analysis

Design

Coding

Testing – TCD/Review/TCE

Support

1. It is a step by step implementation of SDLC

2. It is linear sequential model for software development & testing
3. Sequential model means- after completion of first stage then second stage will be come
4. Ex. Sequential means- testing will start when coding is completed
5. Ex. Sequential means- developer will start the coding when design is completed
6. In this model the client requirement are fixed
7. It is used in the small project/ small budgets etc.
8. Duration/ delivery of the project of the waterfall model is more than 3 month
9. Develop & deliver – 5 to 6 module
10. Cases-
 1. If you need to enter in to next stage or before moving to the next stage, the current stage or previous
stage should be completed & then & then we can enter in to the next stage
2. Consider coding stage has been completed & now testing is there
If any defect/error occur, then tester cannot revert back to the developer or coding stage
In such case, tester has to lock the defect (project management tool / defect tracking tool- JIRA &
HPALM) in the testing stage & prepare report of it,
Then this defect is fixed in the next version or updated version

Disadvantages-

1. Backtrack is not possible (tester cant sent defect to the developer)

2. Delivery to client more than 3 month/ not fixed

Ex.
Module

V 9.0
Modules- 5 to 6
3 month
Defect- fix- v9.1

V9.1- new module (5 to 6) + defect previous version fix = v 9.1

Project- 100 module -10cr

Delivery- 3month

5 to 6

Next 3 month

5 to 6

Build- Executable file/ Url

Developer- code- url - https://www.flipkart.com/

Release-
Handover to client
Ready to use it

Version – V.1.0.0 or V 1.0

V 1.1.5
1. 1-First edition
2. 1 -1 major difference
3. 5- 5 minor feature update or defect fix

V Model
Verification Validation
Information gathering/ Analysis Assessment of development plan
Prepared test plan
Requirement of phase testing
Design & coding Design phase testing
Program phase testing
Test case testing
Install build (integrate) Sanity Testing- 5
System & functional testing -17
UAT testing -2
Documentation
Maintenance Defect removal efficiency
Request for change
Post marten testing
Regression testing
Verification Validation

LCD- Development stage LCT- Testing Stage

Information Gathering Assessment of Dev. Plan

& Analysis Preparation of Test Plan

Requirement of phase Testing

Design & Design Phase Testing

Coding
Program Phase Testing
Test Case Design

(Installation Build) Sanity Testing

Integration Testing System & functional Testing

UAT

Test Documentation

Maintains DRE
RFC

Post marten testing

Regression Testing
V Model-

It is also known as verification & validation

In v model verification & validation work parallel
In v model, development stage mapped with testing stage
In v model, suppose, we have completed 1st stage & now, we are in second stage which is running. If any change
in requirement (CR) for 1st stage or for the previous stage, then we can revert back to the previous stage or 1 st
stage to full fill CR (change in requirement) but, for this CR client has to pay extra amount

Ex. Designer- design stage – design stage complete- coding- developer start the coding – Client- CR- BA-
designer – designer change – new design – coding – developer again start- client pay some amount

V model is used in big organization

In v model, duration of project delivery/release is near about 3 & 3+ month

Ex. project 2 years – 100module- 1st release – 3 month – 5 to 6 module – handover to the client

It is plan driven methodology – because CR are rarely come

Information Gathering & analysis – Refer SDLC

1. Assessment of the development plan

2. Preparation of the test plan
3. Requirement of the phase testing

Assessment of the development plan

Defining objective of project / domain of the project- Banking, telecom, insurance, healthcare, e-commerce etc.
Defining step to achieve objective of project
Strategy of project development & testing is prepared here
In testing- there are automation & manual testing. So among these two, which methodology need to be
implemented is decided here
Test responsibility matrix (TRM) is finalized in this stage
Top level people or PM involved in this stage

Ex. project- banking- 12 testing

TRM- it’s a mapping between SDLC and test factor
Test factor- 15 testing

EX. BCCI format – Test / one / T20

IND vs AUS
BCCA

BCCI/ Rahul/ Rohit – 15 people finalize- 11 select

Preparation of the test plan

TRM is implemented in preparation of test plan
PM is responsible for TRM implementation- 15 out off
PM prepare a test team
PM assign team leader & both PM & TL distribute work to all member
Test estimation is created in this stage
Estimation- means how much time it will take to complete particular assigned task (Start to end date)
In this phase job allocation, resource allocation & estimation are done

Ex.
Coach – Rahul- PM – TRM finalize – 15 testing
Captain- Rohit – TL
Team – IND vs AUS
Team member- 15
Select- 11
Batsman- 5
Keeper-1
All-rounder- 2
Blower- 2
Spinner-1

Requirement of the phase testing – Client- Whatapp- Client requ. – Message sent & audio calling – video
calling – estimation decide

Ex project duration 6 month & ½ - design – developer – other module

Whatsapp- audio calling/ video calling- time period - Requirement of the phase testing

Phase means unit

In this phase, estimated requirement of the phase/unit are finalized

Ex. Paytm- recharge, rent, gas, movie, train…ect---- design/developer- flight-10days

Design & Coding – refer SDLC

1. Design phase testing

2. Program phase testing
3. Test case design

Design & program phase testing

Design & program phase testing means code testing

Developer are involved in this testing, because he check the own code, find the error & fix the error this testing
is like unit testing/WBT

Test case design

Tester are involved here
Tester understand the SRS document & then tester prepares test case design
Test case design include
1. Positive test case design / positive scenarios
2. Negative test case design / negative scenarios
After the review completion tester perform black box testing at the time of execution of test cases

Installation build (integration testing)

1. Sanity testing
2. System & functional testing (BBT)
3. User acceptance testing
4. Test documentation

Installation build (integration testing)

In 3 month duration, generally 5 to 6 module are developer

Release – 5 to 6

CR- new module develop but in the existing flow

Fro. Ex
For current running project, if company receives new requirement from the client to develop new module, if
client wants to add this new module in to existing flow then we can called as integration testing

In such case, developer develop code for new requirement & perform unit testing
So when new module is ready, they add/integrate new module in the existing application flow

Example- E-commerce – Amazon

Home- fashion-electronics-mobile-beauty….etc.
Existing flow

Mobile- view product- buy product/add-place order-payment- delivery

1 2 3 4 5 6

New CR– Exchange

New flow

Mobile- view product- buy product/add- Exchange- place order-payment- delivery

Device Company
Module
Year
IMEI
Price – 3k

New mobile- 10k

Final price- new mobile price- old mobile price= 10-3=7k

 1. Sanity Testing
2. System & Functional Testing (BBT)
3. User Acceptance Testing (UAT)
4. Documentation

Sanity Testing – 5 way – build/url – critical defect (reject build)- S & F testing

Sanity testing – build is stable or unstable

Client Requirement – BA- BRS /SRS- Sent- Technical team- own work – developer develop module/ Tester
TCD- developer build/url- sent – tester- tester perform sanity testing- basic & core functionality – 2 to 4 hr

Ex. Paytm- Recharge Module- sanity testing – core & basic functionality

Recharge module- recharge the specific number

Major/ critical/ blocker/show stopper defect – lock- assign developer- sanity testing

Without solve this defect we can’t move forward to testing / stuck

Minor/ small defect-

Jio spelling mistake

Expected- Jio
Actual- Joi

Operator
Select- BSNL – logo not display

All above defect- note down

Lock- System & function testing lock

1. It comes under the validation process

2. In sanity testing as a tester we validate basic & core functionality of the application
3. Check the happy flow of the application/ main flow
4. We check only positive way
5. Tester we check in application any blocker or not
6. In sanity testing, only critical/blocker defects are lock or assign on (JIRA) to the developer
7. Tester is responsible person to do the sanity testing
8. Duration for sanity testing 2 to 4 hr
9. We not executing test cases
Ex.
IRCT- book ticket – core functionality
Plan my journey – my booking – PNR enquiry
Refund history
Source to destination
Class
Date- date format mistake – DD-MM-YY but MM-DD-YY

No of station – Latur – Pune- 15

14

Logo –

Submit button/ search train- not working – critical /blocker

After integration testing first testing is sanity testing

System & functional Testing – main 4 type- 17 testing

After the completion of sanity testing, we carried out S & F testing

It is also called as BBT
In this testing, as a tester we check the entire / overall application or functionality / build step by step from
start to end
In this testing tester execute positive & negative test cases
In this testing we lock the small/minor/ critical defect on JIRA
Ex.
Paytm
Spelling mistake
Logo
IRCTC
Date format
Station count
logo

UAT- 2 type
After the completion of S & F testing carried out UAT
After the removal of defect the application or product / build is moved to UAT
So, after S & F testing we assure about defect free application
In UAT, client/customer/BA/PM/Designer/Dev team, & test team sit together & check the overall
functionality of the application step by step from start to end as per the given requirement
Ex. UI, main module, sub module, logo, font, color etc….

Test documentation
Tester prepare
Test case design- Review- Self/peer/internal/external (complex functionality)
Test case execution – pass/ fail
Defect report - screenshots
Tester sent this document- test lead
Test lead send this document to – PM
PM send this document to – BA
BA send this document – Client

Ex.
Name of module Test cases status (pass/fail) comment
 Maintenance – refer SDLC

1. DRE- defect removal efficiency

2. RFC- request for change
3. PM- post moren testing
4. RT- Regression testing

DRE- defect removal efficiency

It is process of calculating at which level tester performed testing

At which level tester tested the application

DRE has 2 Phase

1. Defect found by tester
2. Defect found during UAT

Defect found by tester

During testing, if tester found defects then some of the defect are fixed & some of the defect are cancelled

Ex. In SIT, consider tester found 100 defect

90 – were fixed
10 – were cancelled (due to duplicate, not a defect, technical issue & environmental issue)

Defect found during UAT

If client found some defects during the testing of application

Ex.
In UAT, 10 defect were found

A= defect found by tester - 90

B= defect found during UAT-10

DRE= A/(A+B) = defect found by tester/(defect found by tester+defect found during UAT)

= 90/(90+10)= 0.9

Based on this what kind of testing has been performed by tester is calculated

DRE range Remarks

0.8-1 Good testing
0.5-08 Average testing
Below 0.5 Below average testing

RFC- Request for change (CR- change in request)

Configuration management team- BA/Developer/Tester

Changes- update – SRS- end - red color with * mark

We get the pdf format
CR- amount pay

If customer want to some changes in the product at the time of release then it is considered as request for change
or change in request
To handle this CR- there is one team called as configuration management team
CMT- involve- BA/developer/tester (developer lead/tester lead)
So, in which environment (DIT,SIT,UAT,Prod) we did the changes is decided by CMT
Change in request is mentioned in the SRS document at the end
It is mentioned in red color with * mark, also we get in the PDF
So, for this change in request for changes customer has to pay extra amount

CR – CMT- decide – time/impact development – client – next release implement

Post mortem testing

Application- production – testing – generate output – developer – check all the module detail perform WBT
PMT

It is used to check complex & critical functionality of application

PM testing- done by developer
When whole testing is done (S & F, UAT- sign off) & product is ready for production & if product is not
producing desired output then developer has to check all the modules in detail & has to perform WBT
In this testing developer has to find out exact root cause of the defect- where it is & what is the problem

RT- regression testing – 3 types

As tester – we start testing – we got the error/defect- defect is assign to developer- JIRA/HPALM- developer fix
the defect- developer assign – tester – retesting (defect)- regression testing (side impact to other module)

RT is the subset of sanity testing

Regression testing is performed
1. During SIT
2. After SIT
3. After UAT
RT is always performed on modified build/newly build/ corrected build to ensure that defect will be fixed &
there is side impact on other module or not is nothing but RT

Duplicate defect- cancel

Defect- mobile number field

Mobile number field does not have length validation- duplicate

Mobile number field accept less than 1o digit – duplicate
Mobile number field accept more than 1o digit – duplicate
Mobile number field missing the validation message – less than & more than

Dev- SIT-UAT- prod-

Cilent- CR- regression perform – 2 to 4 hr

There are 4 type of environment

DIT- developer
SIT- tester
UAT- client & other team
Prod- live – end user

V Model
What is V model?
DRE?
RFC?
PM?

Agile Model
- Introduction of agile
- Naming convention- difference (SDLC vs Agile)
- Different type of agile
- Agile architecture
- Agile meeting
- Adv. & dis agile
- Agile daily work plan
- Agile term- IMP
- Interview questions

Agile model/process/methodology/implementation Introduction

- Agile methodology is the module driven methodology

V- 5 to 6 model- 3month – modules

Agile- 1 or 2 module – 2 week or 3 week

- In agile methodology requirement changes frequently, so it is not plan driven methodology

V model- plan driven methodology- req. fix – rarely change

- In agile methodology, client can request for change in requirement at any point of development stage
- Client can request for change at any stage (i.e. DIT,SIT,UAT,Prod)
- If any CR, that will be accepted at any stage/point without extra amount/money
- If any CR comes from client then we will accept (BA) & check impact on current development,
testing & production process
1. If impact is more on current development & testing, then BA/PM will discuss with client or
inform to client
2. If impact is less then we will consider new CR
- Agile duration of delivery is of 1 or 2 or 3 or 4 week (fix no= 2 week)
- Agile methodology is a value driven methodology (we are giving the priority to client)
- In agile methodology, project is divided in to no of module/phase & releases
- As per client priority/ top priority, no of module have to be developed, module wise delivery is
possible in agile or we can top priority for releases also considered
- Its flexible process
- Ex. in agile model, project is divided in to no of module/phases & releases

1 2 3 4 6

7 8 9 10 11

Client priority – release – 1 & 9 module- module delivery

Naming convention – agile different

SDLC/Waterfall/V Agile
Customer/client Stake holder
BA Product/Project owner
BRS Product/project Backlog
SRS Sprint Backlog
Use Cases/ functional req. User story
Release- 3month Sprint- 2 week
PM Scrum Master
Developer Developer
Tester Tester
Designer Designer
Delivery Manager Solution Master
Extra amount No extra amount

Agile Types
Agile sub type
Agile sub method
Agile sub model
Agile different methodology
Agile framework
Agile flavor

1. Kanban- Support team

2. Lean- Support team
3. XP-Extreme program (only developer & no testing)
4. Scrum- Project team- Sprint wise delivery to client with 2 week (Sprint 1, Sprint 2, Sprint 3)
5. FDD-feature driven development
6. DSSM-dynamic system development method
7. Crystal

- I have worked in Scrum agile methodology

Agile architecture

SDLC Agile

IG (BRS) Product backlog (1 project = 2000US)

Analysis (SRS)-2000UC Sprint Backlog

V- 5 to 6 - 3 month – 100UC (Sprint 1= 20US) (priority- Stakeholder/client)
(Sprint 2= 17US) No. decide PO/BA
(Sprint 2= 18US)

Use cases (specific req.) User story (Specific Req.)

1. Description Description
2. Acceptance criteria acceptance criteria

Designer (HLD, LLD) Designer (HLD,LLD)

Coding (LLD) Coding(US against LLD)

Tester – TCD & TCE Tester – TCD,TCD against US

Support/ Maintenance Support Maintence

 Stake Holder

Project Owner

Product Backlog

Estimation

Sprint Backlog

User Stories

Design/Coding/Testing (TCD)

Maintenance/ Support
Agile
Agile is a software development methodology on iterative & incremental approach
Just in time- delivery – product – quality software

Scrum
Scum is a framework used in agile methodology
Scrum is used to implement agile methodology
Scrum meeting, tools & roles
Scrum is an agile framework that can help teams work together

Sprint

Sprint is part of Scrum framework structure

Sprint is defined a period of creating feature/functionality/module
Describe time boxed iteration
During a sprint, a specific module or feature of the product is created
A set period of time during which specific task must be completed
Sprint duration vary between 1 or 2 or 3 or 4 week

Stake holder
- Stake holder is a client/customer
- Stake holder comes with bunch of requirement
- Stake holder is a member of the top most body of the company
- In agile methodology , stake holder can request for change in requirement at any point of
development stage

Product Owner
- Product owner gather/collect requirement from stakeholder
- Product owner create/prepare product backlog
- Product owner – team member- sprint planning meeting

Product backlog
- Product backlog is created by product owner
- In product backlog will contains overall/total/ entire requirement of the project
- It includes requirement of all modules (2000US)

Estimation
a. Estimation
- In agile methodology the focus in on module base delivery
- We get requirement & those requirement are not for one specific/ particular module
- So, in estimation requirements are sorted for development (Sprint 1- 20US)
 - Estimation is an important parameter of sprint planning meeting
Ex- 1 project – 100 module- 2000US (product backlog)- Sprint- 2week – priority client- 21-
40US (sprint backlog)- estimation- Mangesh – 1,2,3 US- assign- 21hr/13hr

b. Estimation
- It is a process to check how we can deal with problems when obstacle occur (tester-leave)
- Estimation of number phases/modules in the project
So, we can assign number of developer & tester
- Priority based module
Depends on client requirement
- People involved- PO/SM/DL/TL
- There are 3 main factor in the estimation
1. Knowledge
2. Efforts
3. Complexity

Knowledge-
- Domain of project & knowledge about project are checked
- Experienced(critical module) & non experienced(normal module) resources are taken in to
consideration
- After that team is formed, after formation of team each member of the team should have
knowledge about domain check
- KT- knowledge transfer (1 week – 2 week, cap Gemini- 2 month training)

Efforts –
- Authority decide how much efforts are required for project
- Authority decide how much resources are required for project
- Selection of US – depends on module

Complexity
- Complexity of the project measured to do estimation of time, cost, resources

Sprint Backlog
- Crated by product owner
- Sprint backlog contains user stories of that particular module
- PO- prepare sprint backlog
- Sprint backlog contains detailed information of requirement, which are required for
development in sprint

User stories
- User stories are nothing but functional requirement
- User stories are decided in to the estimation phase
 - In estimation, sprint planning members(PO) decide which module have to develop & what
are the requirement of the module, those sorted requirement are included in the sprint
backlog
Ex- 2000US – PO- login module develop- requirement- sorted – sprint backlog
- So those user stories are functional requirement for that particular module are to be
developed
- User stories have two criteria
Description Criteria – details about requirement
Acceptance Criteria – does & don’t about requirement

Description criteria template

As a [user/person], I want [process], so that [benefits]

As a [who], I want to [what], so that [why]

Acceptance criteria
Given [situational pre condition] when [user action1, user action 2….n] then [product
action 1, 2…n]

1. FN accept capital letter

2. Mb. No. accept digit

Ex.
As a user, I want to be securely login in to the system so that my information can only be
accessed by me
As a online customer, I need to search for products, so that I can find the once I want to buy

Test case design

- Test cases are designed by tester
- Test cases are mapped with the user stories to cover all the requirement
- Ex. Us- Login- 45 test cases

Agile Meetings / Ceremonies

Agile 5 types of meetings/ceremonies

1. Grooming meeting
2. Sprint planning meeting
3. Scrum/daily stand up meeting
4. Sprint review meeting
5. Sprint retrospective meeting
Sprint – 31/01/22- 12/02/22

Grooming Meeting (PO/SM)

- Grooming meeting/session is conducted before the start of the sprint (Thursday)
- Purpose
1. To understand the objective of sprint/project
2. To understand the purpose of stakeholder
3. To understand the user stories of the particular module will develop in the sprint (US-20)
4. PO- share essential information (US) & provides guidelines to development & testing team
5. If we have doubt about the requirement/US so, discuss with PO & clear doubt
- People involved in meeting
PO, SM, Designer, development team & testing team
- Duration- 30min to 60min (60min)

Sprint Planning Meeting

- Sprint planning meeting is conducted by SM on the 1st day of the sprint (31/01/22-Monday)
People involved- PO, SM, Designer, development team & testing team
- In the grooming session, we get overall idea about the US or current sprint US/ project/Module
(Ex. Sprint1-20US), so in sprint planning meeting, SM allocates work/task & US to the
development team lead (particular developer) & testing team lead (particular tester) as per the
requirement & priority of the stakeholder
- Development team lead distributes work/task to development team members, according to the
experience of the employee, requirement & priority of the stakeholder
- Testing team lead distributes work/task to testing team members according to the experience of
the employee, requirement & priority of the stake holder
- SM asks for estimation/story point (i.e. how much time, it will take to complete the assigned
development & testing task or time span for every US)
- Ex. ask for estimation= task & story point (hr or day)
Day- 8hr/week=40hr each member = 2 week = 80 hr
Ex. 1 US estimation/story point= designer (4hr) + developer (16hr) + tester (12hr)= 32hr
- Once the sprint planning is done, SM- monitor each activity on daily basis
- Duration = 30min to 60 min (60min)

Daily stand up / scrum meeting / scrum call / status call (SM) - Tuesday- next week Friday –
12:30pm – SA-9am

- It is daily/everyday status call/ stand up call meeting

- People- SM, PO(Optional), designer, dev. Team, test team
- SM is a chairperson of the standup call meeting
- Agenda- of this meeting is discussion about the progress of the project or work progress of the
designer, developer & tester
- Topics is discussed in meeting – 3 questions ask in scrum meeting
 1. What we did yesterday?/ what you have yesterday ?
Previous work (monday)
2. What we will do today?/what are you doing today?
Pending work /new work – complete EOD
3. Discussion about blocker / what are roadblock or issue?
Difficulty – test case design, execution, developer- lack communication

- Duration = 15 to 30 min = (depends on team member)

What we did yesterday? (before development/ inprocess)

Good mooring all, so, yesterday I have understand US & I started with test case design of this
particular module “registration”.
I have completed 70% of the test cases of the particular module / US “registration”.
In between I had some doubt, so I had connected with development team to write sown some
scenarios

What we did yesterday? (after dvelopment)

Good morning all, after the completion of test case design preparation. I have executes few test cases
& here is the result, so its working fine. I have found defect, so that I have assign/lock defect to the
developer (defect ID). I have communicate with developer for that particular defect

What we will do today?

We will complete the remaining part of the test cases, so at the EOD I will share the test case sheet
along with team

Discussion about blocker

While executing test cases there was a blocker, so due to this we could not test that US/module
I am waiting for the JIRA access
I am waiting for the particular test data
I am waiting for the login credentials

Summery- CR – open discussion

Sprint review meeting / demo meeting – PO/SM- Friday – 2:30pm-3:30pm

- Sprint review meeting is conducted on the last day of the sprint
- Review of the work – stakeholder (optional), PO,SM
- People involved- stakeholder, PO,SM, DT, Designer, TT
- Development team or test team prepares demo of the application(particular US) & delivers to the
SH,PO,SM
 - In this review- requirement are cross checked, some suggestion & some additional changes are
also told
- Purpose – to check completeness & correctness of the US as per the stakeholder requirement
- Duration- 60min

Sprint retrospective meeting – SM – Friday – 3:30pm – 4:30pm

- SRM- conducted by SM on the last day sprint
- People – SM, PO, Designer, DT,TT
- Agenda- Discuss about the sprint
1. What went well- good
2. What didn’t go well= bad
3. Difficulties faced by developer & tester (test data / login credentials)
4. What were the action plan for next sprint?
5. Overall experience shared about sprint (good/bad)
- Purpose- avoid mistakes in the next sprint
- Duration – 30min to 60min

Sprint 2

Summary of all meetings

Agile Meeting Purpose Involved

Grooming meeting - US / requirement doubt/ Clarity 1hr – PO, SM,

( Any time- 2week) understand Development team, Testing
(Before start of Sprint) team, Designer
Sprint planning meeting - Current sprint = 20 US added / 30 min/ 1hr – PO, SM,
(1 times – Start day of work decide  SM, PO & Development team, Testing
sprint) (1 Sprint - 2week) Designer team, Designer
- Estimation provide
Ex. 1US = designer (2hr) +
developer (14hr) + Tester (8hr) 
total = 24h
Daily stand up meeting/ - What you have done yesterday 15 min – PO, SM,
Scrum meeting - What are you doing today Development team, Testing
(Daily – 10 am to 10.15am) - Issue/ roadblock team, Designer
Sprint review meeting - US  Tester or developer 1hr – Stakeholder/ UAT /
demo/ review to Client/ UAT / PO PO, SM, Development
(1 times – End day of team, Testing team,
sprint) Designer
Sprint retrospective - Current sprint (Sprint 1  2 week 30 min/1hr- SM, PO,
meeting complete)  Sprint 2 work Development team, Testing
(1 times – End of day team, Designer
sprint) Good & Bad things discuses
Advantages & disadvantages of agile
1. Check point
V- production – output is not generate properly- Developer- PM – check each module in
detail
Agile- tester check point- found defect- assign developer- fix – highlight- red color

1 0 2 0 3 0 4
R L 2FA Watchlist
2. Scrum meeting
Monitor daily status
3. Implementation of automation
70% - manual 30%- automation
Selenium- automation tool
Adv.- less cost/high accuracy/ less time/ less resources
4. Sprint wise delivery
V- 3 month /release -5 to 6 module
Release/ year- 4- 20 module

Agile
2 week – 1 module
Release – 24 -12 to 18

Disadvantage
Software develop- developer & tester – total knowledge about the flow of application,
dependencies & relationship of the module
CR- delivery will take time
Module is depends on the other module – delivery will take time
2
2
2
2
Agile Daily wise plan-
Project team size- 18 peoples (10 developer + 4 tester)
Agile duration delivery- 2week (5*2=10) (Monday to Friday)
1 team – recharge module/epic/US- 3 developer + 1 tester
2 team- electricity module/epic/US- 2 developer + 1 tester
3 team- invest in stock module- 3 developer + 1 tester
4 team- rent module- 2 developer + 1tester
Scrum agile- sprint wise delivery= 18US – (4 US- assign- 3 team)

1 week-
Monday (start day of sprint)
- Grooming meeting (60 min)- US doubt celerity
- Sprint planning meeting (60min)-
1. Sprint 1 = 18 US- assign work/task to the developer & tester (4US)
2. Estimation= 1 US – designer (1hr) + developer (13hr) + tester (10hr)
- 1 US- 3 developer- 1 US coding(6hr)- in progress + tester – 1 US TCD (5/6hr)- complete

Tuesday
- Daily stand up meeting (15min-30min)
1. What you have done yesterday? (1 US-TCD-complete)
2. What are you doing today?(1 US- TCE)
3. Roadblock
- 1/2 US- 3 developer- 1 US coding (2hr)- complete- build sent for 1 US- tester, 2 US-
coding(5-6hr)- in progress + tester – 1 US TCE (7-8hr)- complete

Wednesday
- Daily stand up meeting (15min-30min)
4. What you have done yesterday? (1 US-TCE- complete)
5. What are you doing today?(2 US- TCD)
6. Roadblock
 - 2 US- 3 developer- 2 US- coding (7-8hr)-complete + tester – 2 US TCD (6-7hr)-complete
Thursday
- Daily stand up meeting (15min-30min)
7. What you have done yesterday? (2 US- TCD-complete)
8. What are you doing today?(2US-TCE)
9. Roadblock
- 2/3 US- 3 developer – 2 US- build sent to tester, 3 US- coding (6-7hr)- inprogress
+tester- 2US TCE (7-8hr)- complete

Friday
- Daily stand up meeting (15min-30min)
10. What you have done yesterday? (2 US- TCE-complete)
11. What are you doing today?(3US-TCD)
12. Roadblock
- 3 US – 3 developer – 3 uS –coding (4-5hr) – inprogress + tester – 3 US TCD (4 to5 hr)-
inprogress

2 week
Monday
- Daily stand up meeting (15min-30min)
13. What you have done yesterday? (3 US- TCD-inprogress)
14. What are you doing today?(3US-TCD- complete + 3US-TCE)
15. Roadblock
- 3US- 3 developer – 3 US- coding (4hr)- complete- build sent ot tester- coding (3hr)-
inprogress + tester – 3US TCD (3hr)-complete , 3 US- TCE (4/5hr)- inprogress
- 3 US- TCE (2 defect)- defect we will inform to developer + developer will fix defect
(2/3hr) + tester will check defect (2) (2hr)- complete

Tuesday
- Daily stand up meeting (15min-30min)
16. What you have done yesterday? (3 US- TCD-complete, TCE- inprogress, 2 defect)
 17. What are you doing today?(3 US – remaining- TCE-complete)
18. Roadblock
- 3/4 US- 3 developer – 4US- coding (5/6hr)- inprogress + tester – 3 US TCE (4/5hr)-
complete

Wednesday
- Daily stand up meeting (15min-30min)
19. What you have done yesterday? (3US- TCE-complete)
20. What are you doing today?(4 US- TCD)
21. Roadblock
- 4US- 3 developer- 4US-coding (5/6hr)- complete + 4 US TCD (4/5)- complete

Thursday
- Daily stand up meeting (15min-30min)
22. What you have done yesterday? (4US- TCD-complet)
23. What are you doing today?(4 US- TCE)
24. Roadblock
- 4 US- 3 developer- 4 US- coding – complete- build sent to tester + tester 4 US TCE
(6/7hr)
- Tester 4US- TCE- found 7 defect- tester inform to the developer(JIRA) – developer- fix-
1 to 5 defect- fix- 6 to 7 duplicate + tester will check defect 1 to 5 – retesting (3hr)

Friday
- Daily stand up meeting (15min-30min)
25. What you have done yesterday? (4US- TCE-inprocess, 7 defect, 5 defect- retest-
close)
26. What are you doing today?(4 US- remaining TCE)
27. Roadblock
- 4 US- 3 developer – 4 US- defect fix (2/3 hr) + tester – 4US- TCE(3 to 4hr)-completed
- Defect 6 to 7 – reproduce – reassign – developer fix- completed – retest
Sprint review meeting (1hr)
Tester/developer 4 US- test- demo to the client/po/sm/team- UAT

Sprint retrospective meeting

Current sprint –sprint1 – good & bad discussion

Next sprint move- “Carried over defect”

CR- +91- 5 min

Agile Term- imp for interview

Burn down chart
It is graph
Defines how much work will be remaining w.r.t. date/time

Burn up chart
It is graph
Defines how much work will be completed w.r.t. date/time

Velocity chart
It is graph
Defines how much US we are delivery to client w.r.t. sprint
Track the amount of work completed from sprint to sprint.
Epic
It is a large US
Main module- which contains multiple user story in it
Ex. Paytm- Recharge module – Epic –main module – 15 to 20 US

Estimation/ Story point

Estimation – by using voting method
US1- Mangesh(13hr)- Estimation- PO(8)/PM(5)/Dev team(8)/ test team(13)- voting method
Estimation change- daily stand up – SM
Estimation – which consider
1. How much knowledge about US
2. How to complex testing
3. How much efforts required – US- 2 to 3 testing or 7 to 8 testing

Sprint zero – PO/SM/Designer/ TT/DT (optional)

Software
Hardware
Tool
Training
Some organizations introduce a Sprint Zero before the project kicks off actually. This Sprint might
be used to accomplish the following tasks.
For assembling the Scrum team.
Finding a resolution for hardware, software, and colocation issues.
If required, train a team in Scrum or other technology.
To populate the product backlog with a few high-level items as a preparation for the first Sprint
planning meeting.

Project Technology
Different project technology
1. Front end – Dot net languages-
2. Database/backend – SQL
3. Services/API- Java language / XML /HTML

Front end- UI /GUI

Manual testing
Automation Testing- Java & Selenium

Services (Soap & Rest)

API testing/ Rest – Postman
Web Services- Soap & Rest - SoapUI
Backend
SQL server
Oracal 11g

Project management tool – Defect tracking tool – JIRA/HPALM/TFS/Bugzilla

Frond End – GUI/ Service- (SOAP/

UI REST)
Manual Testing/
Automation Testing API Testing

Database (DB) -
SQL Server

Database Testing

Environments
There are 4 types of environment
1. Development Integration testing (DIT) / Dev Environment
2. System Integration testing (SIT)/ qa environment / non preprod / testing env.
3. User acceptance Testing (UAT) env. / preprod env.
4. Production / live env.

Dev Env- developer coding on US-build mail to JIRA- unit testing

SIT env.- tester will work TCD- TCE (build/url)

TCE- found defect – assign developer- tester mail or JIRA

Developer fix- build- testing

SIT env. – Tester / DBA/developer- build create – UAT env.

Production / live –
DIT
- Developer are involved
- Developer develop code according to the US
- Completed coding they perform - WBT- Unit testing & integration testing
- After completion of testing – code pushed – particular location/ server
- DBA team /developer – to drag code and prepare builds (URL) for that code
- Code is deployed on the build (url)

Other Way
- Developer complete the coding & push the code in to server
- DBA/Developer prepare or create Dev build
- Dev build is given to the developer
- Developer will perform WBT- unit & integration testing
- Error – solve – fix – send to the server
- DBA drag the code and create the build

SIT
- Tester are involved
- Having deployed code on build- SIT build – mail from developer team/ dev team lead or JIRA/
HPALM
- Main-
1. Build (url)
2. Credentials
3. Test data (sometimes) (test data- PO/BA)
4. Design document
5. Unit testing document (positive way)
6. Build version
7. Build release
- Test execution- perform sanity/smoke testing, system & function testing etc.
- If we get the defect/error found- defect assign/raise/lock to the developer on JIRA/HPALM
- Developer fix the defect – we perform retesting/regression testing
- Working fine

UAT
- DBA- UAT env. Create
- UAT- stakeholder, PO,SM, all the team sited together & check the entire functiolanlity of the
application step by step from start to end
- Defect free – UAT- provide the Sign off – go head – to the production

How to get the build for testing?

After completion of coding developer perform different testing like unit & integration after that
developer/DBA team send a mail also through PMT(JIRA/HPALM)
Mail contains

1. Build (url)
2. Credentials
3. Test data (sometimes) (test data- PO/BA)
4. Design document
5. Unit testing document (positive way)
6. Build version
7. Build release
- SIT env. We open the build & perform the testing

IMP- Server is hired by company to maintain all data

DBA/developer build create – Jenkins Tool for deployment

Dev Env------server Github (push) -------DBA/Developer------Jenkins tool – build create------SIT env.

Dev Env- Unit / integration testing

SIT env.- Sanity/Smoke testing , S & F testing , Retesting, Regression testing ….etc

UAT env. – alpha & beta testing

Interview question-

1. What are different technologies present in your project?

2. What are different environments in your project
3. What is the URL for SIT environment? How you’re opening the application?
4. How you get the build?
 Answer- 1. When Developer will complete the coding then he will sent build to SIT
environment.
 Developer will sent attachment – unit testing doc, URL, tables names
 In My organization, we are using “Jenkins tool” for deployment
 Dev
5. What is your approach Git –hub Jenkins
if SIT environments are tool-
not present? ORSITif both developer &
Job (Sent the
tester are working in Push
Environment same environments? code from Git Environment
to SIT)

 Answer-Developer & tester are working in same environment. Some of these defect
we will missed in testing.
 If SIT environments is not present, we will try to test the application in Dev &
UAT environment (remotes desktop access we will do testing)

---------------------------------------------------------------------------------------------------------------------

Types of Project

There are 3 types of project

1. Traditional project
TP – developing and testing is done in the same company

2. Off the shelf

OTS- project development & testing team are from the different company

SA- Insurance domain – Testing /India- Developer/ SA

3. Maintenance
After completion of project in the maintenance include technical & non-technical
support
Project duration – 3years
Maintenance – tickets / defect found

--------------------------------------------------------------------------------------------------------------------
Error, defect, bug, & issue

Error-
- A mistake in programming is known as error
- Ex. extra code / missing the functionality / loop is not closed

Defect –
- If error is found by the tester is known as defects
- Ex. page navigation not working, logo not proper display….etc.

Bug-
- Tester lock the defect & assign to the developer
- If defect is valid & it is accepted by developer then it is called bug

Issue-
- If application does not meet the functional requirements is known as issue
- Developer understand the bug but does not get any root cause

-----------------------------------------------------------------------------------------------------------------------

Defect density, defect removal efficiency, defect leakage, defect rejection ratio & defect age

Defect Density-

- No of defect identified per US/requirement

- No of defect found / no of requirement (Size)
- Ex. 20/2= 10

DRE- refer the V model

(A/A+B)*100

(fixed defect)/(fixed defect + missed defect)*100

(90)/(90+10)*100= 0.9

Defect Leakage
- No of defect found in UAT
- (No of defect found in UAT)/ defect found in testing)*100
- (10/90)*100= 11.11%
Defect Rejection Ratio

(No of defect rejected/to total no of defect lock)*100

(25/100)*100= 25%

(5/100)*100=5%

Defect Age

Birth – death

Fixed date – reported date / assign/ lock/ raise date

1/02/22 – defect lock –id-01

3/02/22- fix the defect

Defect age – 2 days

---------------------------------------------------------------------------------------------------------------

Testing

Dev env-

1. Unit testing
2. Integration testing

SIT env.

1. Sanity / Smoke testing

2. BBT- S & F testing- 17 type
3. Retesting
4. Regression testing

UAT env.

1. Alpha testing
2. Beta testing
Production/ live – production issue

Testing terminology

1. Monkey testing
2. Ad-hoc testing
3. Exploratory testing

Priority & Severity

-------------------------------------------------------------------------------------------------------------------------------

DIT Env.

- Developer are involved

- Developer done the coding and perform the unit testing & integration testing

1. Unit Testing
- Unit- single component / phase
- UT- is perform by developer on every US after coding
- Every US against, developer perform the unit testing
- UT- developer check the coding is correct or not in the positive way
- Unit testing, it will performed in sub module
- Unit testing contains- document, step to execution, flow of application (screenshots), tablename,
credentials – UN & PW, includes URL etc.

Ex. Paytm- Recharge module

Recharge module- Main module

US1 US2 US3 US4 US5 US6 US7

Recharge icon Radio Button Mobile Circle Operator amount payment Thanks

Integration Testing
- Perform by developer
- Carried out after unit testing
- Integration – combine – all sub module & prepare the main module
- Integration – all the dependent sub module are added/ integrated together to form one main
module / application
- IT- should have knowledge about functionality, dependencies of their module, relation beacue
output of one module acts as a input of other module
IT- it is the process to check completeness & correctness of the flow of functionality whenever
integration of module performed

- IT there are 2 types

1. Front end integration – combine all dependent module using CALL function
2. Backend integration – combine all the table in the database by using JOIN function

- Different approaches for IT

1. Top – down approach
2. Bottom- up approach
3. Bidirectional / sandwich approach

Top – down approach

- When main module with functionality is available for testing but sub module are not available
for testing
- Sub module are not available because
1. Under development
2. Sub module have some defect
- So to test main module, developer create dummy module i.e. developer create the dummy
program in XML language is known as stub program
- XML is code language, which used to communicate between the two application
- XML language – request & response

Ex.
Email Sign in page Stub program Home page
Email id Email id
PSW PW
Login

Is not available for testing

Bottom Up approach

- Sub module with functionality is available but main module is not available for testing
- So that time developer create dummy program of main module i.e. developer create dummy
module in XML language is known as driver program

Ex.
Email Sign in page Driver program Home page
Email id
PW
Is not available for testing

Bidirectional approach

- Combination of top down & bottom up approach

- If developer wants to check functionality of main module & he does not have sub module the
uses the stub program
- If developer wants to check functionality of sub module & he does not have main module the
uses the driver program

--------------------------------------------------------------------------------------------------------------------------

DIT Url- http://dev.kite.com

SIT Env.- 17

- What is ABC testing?

- Why we are doing these testing?
- We are preparing any document? – TCD/TCD/Defect
- Send mail – TL/SM/PO
- Developer coding – testing – build create – sent – inform throw main – JIRA/HPALM- attached
document- unit testing document
- Dev – SIT
- Tester are involved in the SIT env.
- Tester will do TCD- Review- TCE- lock defect to developer – fix- retesting / regression
- SIT env. There different types of testing

1. Sanity / Smoke testing

2. System & functional testing (BBT)
3. Retesting & Regression testing ….etc.

SIT Url- http://qa.kite.com

SIT/QA/NONPREPROD

1. Sanity Testing

- SIT env. First testing is the sanity testing

- Sanity testing – tester are involved
- Sanity testing is also called as – zero level testing / level zero testing
- Sanity testing also called as – build verification testing / tester acceptance testing
- Tester – we got new build – from developer/DBA then tester will check the build stability i.e.
either build is stable for testing – it is called as sanity testing
- Main agenda-
1. To check basic & core functionality
Main flow of application
Happy flow of application
Application working flow
- Sanity testing we will performed/ includes

1. Validating the core functionality of application/feature

2. Validating tab (text box)
3. Validating link
4. Validating page
5. Validating the GUI

1. Basic & core functionality validation

- We check main flow of application form start to end or page to page i.e. we check the happy flow
- We check for blocker/critical/show stopper, if we found, we raise that defect & assign to
developer (JIRA/MAIL)
- If we found blocker, we reproduce 2 to3 time before the raising defect
- If we found the defect- small, large , critical we note down
- Ex. Paytm – Recharge module- Recharge to every mobile number

2. Tab validation
- Tab – text field
- We check functionality of tab – to enter characters, digit, special symbol- we check whether this
text box is accepting or not
- Screen keyboards or physical keypads- enter special char, digit, symbols etc

3. Link validation
- Sequence of interlink pages are testing
- If I click recharge icon/ fight icon- recharge sub module information page should open
- Developer provide link

4. Page validation
- Means navigation validation
- We check, we navigate from one page to other page
- Arrow- back & front
- We check pagination (web based)
 5. GUI
- User interact directly
- Tester
1. Logo – link
2. Images-
3. Alignment –
4. Drop down – particular JIO
5. UI- wireframe functionality/ snapshot
- Visualization- GUI validation

- Performed the sanity testing – if we got the found the critical defect in the
application/feature/module, then tester will reject the build
- Performed the sanity testing- if we found the defects (15-25) (buggy build)- reject the build
- Reject the build – inform to developer throw mail (outlook) (JIRA/HPALM)
- After sanity testing- decide- whether build is stable or unstable
- Developer fix defect – sent new build, again tester will perform the sanity testing
- Build- Friday (defect)- Monday (afternoon)- again sanity perform- stable – other testing

Ex. paytm-recharge module – 7 US- developer will coding – after coding – prepare new build (V
1.0)- developer sent build – tester – tester will do sanity testing (check build stability)- core
functionality working or not- if found defect – as a tester directly reject the build (V1.0) – inform to
the developer mail/JIRA- developer fix defect- prepared new build (V 1.1)- sent tp tester – again
tester will perform the sanity testing

- Sanity testing we required only 2 to 4 hr

- Sanity testing we are not writing the test cases
- We are not executing test cases

Note-
- When we decide build is unstable then, we send mail to the developer / developer lead, test lead
CC(PO/SM)
Mail
Subject- Sanity testing – Build (V.10)

Sanity has been performed successfully & these are my observation

During sanity, I have found this critical defect or this much of defects
I have raised that defect & I have assigned it to the developer also
Defect ID- PT 1,2,3….. or PT-1
Comments
Expected behavior
Actual behavior
 Screenshots
-------
On this reports, actually decide, next testing has to continue or not
If we reject the build then DL/TT & sanity tester & developer sit together & discuss the issue /
defect / blocker

Smoke Testing

- It is advance version of a sanity testing

- Sanity testing – found a critical defect then as a tester we will reject build
- Smoke testing- developer will sent a new build – tester – tester perform the testing – found the
critical defect then we reject the build but we will provide the root cause of that defect
- Developer will fix the defect – agin sent a new build – again tester perform the smoke testing

Smoke testing = Sanity testing + root cause – tester

B&C
Tab
Link + critical defect root cause find out
Page
GUI

Smoke testing = Sanity testing + package validation – developer

Package validation – collection of object

When we got the defect as a tester we conduct session with the developer (backend developer), then we
check package for which parameter is not passing there etc. we get the all the response in console & we
get exact root cause

Smoke testing – involved tester & developer (When we got the defect as a tester we conduct session with
the developer (backend developer), then we check package for which parameter is not passing there etc.
we get the all the response in console & we get exact root cause)

Smoke testing-we will inform to developer by sent a mail & root cause of defect

Smoke testing – we cant execute & write the test cases

Smoke testing we required – 2 to 4 hr
In my project, we are performing sanity testing, whenever we get the new build

Difference

Sanity Testing Smoke Testing

Validation Validation
B&C B&C
Page Page
Tab Tab
Link Link
GUI GUI
Tester Tester
Test case – cant write & execute Test case – cant write & execute
Found the defect we reject the build Found the defect we reject the build we will find
the root cause

Interview question-

1. What are your approaches, when you got the build?

2. What is difference between sanity testing & smoke testing?
3. What types of defect you have got in sanity testing/ Smoke testing?
4. Which testing you will perform in SIT Env./Testing, when you got the new builds?
Answer- In My project, we will performed Smoke testing or Sanity testing
5. Are you writing test cases in smoke testing or sanity testing?
 Answer- No
6. Are you creating/log defects in smoke testing?
7. When developer is look into these defects, then what you will do? OR When you have
rejected the build then what you will do?
8. Which testing, you will perform in your project when we get the new build? Why?
 Answer- Smoke Testing or Sanity testing
Why-
1. Before going to system & functional testing, we don’t get show stopper defect.
2. It will be save the time, for developer if we will inform that where is defect & their
troubleshoot.
 9. Which testing you have performed in your Origination
 Answer- In my Origination we performed Smoke testing or Sanity Testing
 In Smoke Testing, we are checking or validating stability of the build.
 In Smoke Testing, we will check Core functionality, Tab/Page, link validation,
GUI/UI, navigation validation, etc
 In Smoke Testing we required 2 to 4 hr
 If we found defects in smoke testing, then we will reject the build and we will
provide the root clause if defects.
 We will send us a mail to developer.
10. If we found defects in smoke Testing then what is your approaches?
 Answer- When we are randomly application in smoke testing or sanity testing.
 If we found defects then we will reject the build.
 Only critical defects are created in project management tool (JIRA/ HPALM) &
inform to developer throw the Mail
11. Which testing will follow when you got new build?
a. Answer- In my organization, we are performing Sanity Testing or Smoke testing
 When we got new build form developer then we perform then Sanity testing
 In Sanity testing we are checking
1. Validating the GUI/ UI of application
2. Validating core functionality (ex. Recharge module- Mobile no. recharge)
3. Validating the link
4. Validating the tab
5. Validating the page/navigation

Smoke – Rgression/Sanity
Sanity- Rgression / smoke

System & functional testing

- S & F testing will perform – after sanity or smoke testing i.e. after build stable/stability
- S & F testing its also called BBT
 - S & F testing as a tester to tests the overall / entrie functionality of the application step by step
from start to end
- US- test scenarios- test cases after the completion review & when we perform the S & F testing
so that time we execute the test cases
- Functional testing- testing in a single feature in a product
- System testing- whole product (functional & nonfunctional testing )
- S & F testing there are 4 main types

1. Functional testing – (90-95%)

2. Usability testing – (90-95%)
3. Security testing – (0-5%)
4. Performance testing –(0-5%)- Jmeter & load runner

1. Functional testing
- Validate build/application- internal & external functionality / feature
- FT there are main 2 types
1. Functionality testing – validate application- internal feature
2. Non functionality testing – validate application- external feature

1. Functionality testing
- We check completeness & correctness of the application as functional point of view
- FT- it is process to check internal functionality of the application depends / based on external
interface / functionality (front end/ UI)
- We execute the test case step by step from start to end

Ex.
Developer –code – build – UI

Tester – code validate – UI functionality – properly working

Ex. recharge – radio button – select – developer code – for that functionality

- Validation the internal feature of build/ application

- Tit includes / there are 6 type/coverage of FT (BIEBSC)

1. Behavior coverage testing

2. Input domain coverage testing
3. Error handling coverage testing
4. Backend / database coverage testing
5. Service base coverage testing
6. Calculation level coverage testing
 1. Behavior coverage testing
- In this testing as a tester we validate the behavioral of the object / web element
- In behavioral as a tester we validate property of the object
- Objects are working properly or not

Object Property
Link Click & unclick / navigating or not
Check box Check & uncheck
Radio button On & off / select & unselect
Button Click & unclick / enabled & disable
Text box Accept the user input / enable & disable

2. Error handling coverage testing (check validation message)

- Validating the input which we are passing into object in wrong way then we see the
functionality is showing error message or not
- Invalid data- different error message generated in web page
- Validating the what are different type of error message are present in the object
- Invalid data/ blank data
Ex.
Paytm – recharge module – mobile number –

Blank- “please enter mobile number”

Invalid data- “please enter valid mobile number”

3. Backend testing / database testing – 1 & 1/2 week

- Validating all front end operation are stored in database or not
- Data entered in the front end is stored in the databse
- Validate – data has been entered in the front end that data has been stored in the database or not
- We validate data can be fetched or not
- Databse – no of tables – no of row & coumn
- Different types database – mysql,sql server, oracal, mangodb
- Ex. register – kite
FN
LN
Mob.No
Pan Card
Aadhar No
DOB
Submit – register successfully
- SQL – structural query language – commands
 - SQL queries is used to fetch data

SELECT * FROM tablename;

SELECT*FROM register;
Output- all table data

4. Service level coverage testing (functional flow of feature/module)

Functional flow
Ex. paytm- recharge icon – radio button- mobile number – operator – amount – check box- recharge
payment button (PO/)

- As tester we validate function sequence of the feature/application

- Validating sequential order of functionality
- PO- prepare functional flow diagram- sequence – module/feature

5. Calculation base coverage testing

- As a tester we validate arithmetic operations (i.e. addition , subtraction, multiplication & division)
- Flipcard

Add 4 item to cart

1 item price -200
2 ittem price -100
3 item price- 500
4 item price- 600
Payment – 1400/-

Add 4 item to cart

1 item price -200
2 ittem price -100
3 item price- 500
----------------------------
Payment – 800/-

Same item multiple – 40 *100= 4000/-

Division
Discount
Recharge – 499 (10%)- 499-49= 450/-

Ex. movie tickets

Ex. Train tickets
Ex. Travels tickets

Input domain coverage testing

Ex.
Register – KITE

FN- length / data type – 48 – char

FN – accept 48 char

FN – 1,2,3,4,5,6,7,8,9,10------48- reduce the data

Max-48- pass
Min-2 – OM- pass
Max+1-49 – fail - Boundary value analysis – length
Max-1-47 - pass
Min+1-3 - pass
Max-1-1- fail

FN-
Char A-Z/a-z - valid
Int-0-9 - invalid
Space -invaild equivalent class partition – datatype
_ -invaild
@#$% - invalid

DTT- different values combination sent – result

Object Rule 1 Rule 2 Rule 3 Rule 4 Rule 6 Rule 5
UN Valid InValid Valid inValid balnk Valid
PW Valid Valid inValid inValid blank blank
Login press press press press press press
Result/o/p Home page Error Error Error Error Error

LN- length / data type – 64 - char

Mob. No- digit
Email Id- string “”

Non Functionality Testing

- Checking external functionality or external feature of the application

- Validation of external feature of the application
- Check whether the application is running on particular operating system & browser or not
- There are different coverage’s/ types of non functionality testing it includes

1. Recovery testing – S & P

2. Compatibility testing -– S & P
3. Configuration testing -P
4. Installation testing -P
5. Intersystem testing -– S & P
6. Sanitation testing -– S & P
7. Parallelization testing -P
8. Globalization testing -– S & P

1. Recovery testing
- It also called as reliability testing
- As a tester we check application is able to recover from abnormal situation to normal situation or
not
- We validate, whether the application is capable to handle abnormal situation or not
- Recovery requirement / recovery point are given by stakeholder (i.e. system should recover from
start point or should resume from stopped point)
- Ex.
Downloading – we are downloading movie of 2 gb & suddenly network is lost but 1200mb has
been downloaded, after some time the connection resume the movie is started downloading from
1200mb (from which point is should be decided by stakeholder)

Amazon-
 Buying something- enter the address- payment- suddenly application is crash – application is
reopen start point or resume point this will be decided by client

Compatibility Testing
- As a tester the application is supporting to the users expected platform or not
- CT there are 2 categories
1. Software Compatibility- OS support, Browser support, application support- we are
2. Hardware compatibility- Parts, printers & external devices

- There are 2 types of compatibility testing

1. Forward compatibility testing
2. Backward compatibility testing

Forward compatibility testing

Application-Kite OS (Windows 9)

If we have problem on the OS

-application is correct or ok but OS/bowser does not work properly

-Os issue – resolve by technical support/IT support
- it team to get less number of defects

Backward compatibility testing

- OS/browser is ok or correct but build is not working properly
- Developer/DBA
- We get the more defects

Application-Kite OS (Windows 9)

If we have problem on build

- Compatibility testing includes

1. Operating system compatibility testing – we are not involved
2. Browser compatibility testing – we are involved
a. Cross browser compatibility testing
b. Version compatibility testing

Cross browser compatibility testing

- As a tester we tests the build on different different browsers like
 IE,Chrome,Mozila,Safari,Edge,UC browser, opera etc…..
- Validating the application is supporting to all browsers or not
- Kite- registration, login & 2FA- different browsers – chrome, IE, Mozila

Version compatibility testing

- As a tester we tests the build on different different version of same browser
- Validating the application is supporting to one browser with different version
- Ex. kite- registration, login & 2FA- chrome – V98, V97, V96…..
- VM software (virtual machine) & remote desktop we can use same brwser with different version

50 TC- BCT- Chrome-20, IE-10, Edge-10

Configuration Testing / Hardware Testing

- I am not part of this testing, I am involved in service based application testing. But I am aware,
how it works. There is a spate team, who does the testing
- During this testing tester tests whether application is supporting to different hardware’s or not
- Hardware – printer (dot matrix, laser)
- Ex. paytm- invoice download clik- print page

Installation Testing
- I am not a part of this testing.
- I am inoved in service based level application testing
- But I aware about it also
- As a tester we are checking installation of software in the existing system of user as per user
expected platform

Application – existing software Customer expected platform Set program execution

Easy interface
Occupied disc space
Check uninstallation

Set program execution

To check whether all the setup file are present or not / package all

Easy interface
Installation Process should be user friendly, so user can navigate easily

Disc interface
Check disc space occupied

Check uninstallation
Installed software we can uninstalled from system or not
Inter System Testing
- It’s a process of checking whether our application share data or information with other
application or not
- Data communication- XML
- Banking domain- mostly use this type of testing

Ex.
1. JIO Recharge – phone pay- fetch information from JIO application
2. ATM- ICICI –
3. Paytm- electric bill will pay – MSDCT
4. Paytm- train ticket- IRCTC

IRCTC Flight booking

Paytm gas booking

Electricity Bill Insurance

Parallel Testing

Dustlon- Phonepay – comparison – other market app- google pay / amazon pay

Phonepay- application check with google pay

- I am not involving in this type of testing. Actually I am involved in the service based company.
But I am aware about it also
- It is called as comparison testing
- It’s a process of checking our application with other product

Sanitation testing –
- It is part of non functionality testing
- It is also called as garbage testing
- As a tester we try to identified any extra feature in the application which are not specified in
the client requirement this is nothing but sanitation testing

Ex. Client- application- all country

Register page- mobile number- client requirement- only 10 digit are accepted
 - During the development, developer sense it, this particular functionality should have been in the
development but which is not in the client requirement. So even through developer adds that
functionality during the development
Ex. add country +91 (dropdown) in front of mobile number
- During the testing, tester finds out some extra added feature by developer which is not in the
client requirement

- As a tester, we can lock the defect for that extra added functionality on JIRA
- Developer can suggest new functionality to the client but we need to take permission of PO/BA.
- If client is agree on it, then it will be will new CR
- So in such case a tester cant lock the defect
Globalization Testing
- It is the part of non functionality testing
- It is the process of checking whether application supports different languages or not
- There are 3 types
1. Localization testing
- As a tester we verify whether our application supports to the local languages or not
- It includes- Marathi, tamil, telgu, …….
- Ex. facebook, amazon

2. International testing
As a tester we verify whether our application supports to the national languages or not
It includes- Hindi, japnis, garman….. …….
Ex. whatsApp

3. Global testing (we are part of this testing mostly)

- As a tester we validate whether our application is support to the global language or not
- It includes only English

Note- different language change- but digit use – same

Usability Testing
- It is a part of system & functional testing
- As a tester we verify user friendliness of the application as real end user point of view
- It is also called accessibility testing
- We observe- UI, front , color, resolution, visually & if any error is find there so we simply lock
the defect
- We check our application should take less number of event / steps to complete the task
- Validate how many steps this application is taking as well as how much time this application is
taking to complete
- Ex. mobile filed- we enter only 7 digit instead of 10 digit
“Please enter the 10digit number”
 - There are 2 types of UT
1. GUI(graphical user interface)
2. Manual support testing

GUI-
- Validating look & feel of the application
We observe- UI, font, color, resolution etc.
- Validating easy to use of application
We validate, one click- next action should be perform immediately
- Validating speed of interface in application
We validate, how quick application responds to the users actions

Ex. Gmail vs Yahoo

Gmail- easy GUI

Yahoo- not user friendly interface

Tool- NVDA & WAT tool

Manual Support Testing / productive search

- It is process of checking context sensitiveness of user manual input

- It is also called as regular expression testing
- Ex. Irctc application
Source to destination – manual suggestion
When I enter P – it should show cities whose names started with p
- Ex. contact list
- Ex. kite share
- Ex. mobile plan

Security Testing

- We validate whether application is secured or not

- We validate, whether users information data, operations are secured or protected or not
- Tester & developer are involved
- There are 3 types are involved
1. Authorization
We validate – user is valid/registered/authorized or not

2. Access control
Only authorized user has permission to access & perform the specific operation or not
 3. Encryption & Decryption
Developer are involved they perform Encryption & Decryption
Encryption- it is process converting normal message in to meaningless message (unreadable
format)
Ex. phone pay- pin- 1234- XXXX

Decryption- it is process converting meaningless message in to original format (readable format)

Performance Testing (Jmeter & load runner)

- As tester we check the speed of the processing of our application
- Application is tested – without & with work load condition
- PT- measured the speed of processing
- Performance test engineer (separate team)conduct the this testing
- They use load runner & J meter tool for testing
- Still I didn’t get chance to work with them
- Types of PT

1. Load testing
- Check the application ability to perform under anticipated user loads – 50 -60 -70

2. Stress testing
- Check the application under extreme work load & to see how it handle traffic or data processing -
500-100-1500

3. Spike testing (short duration)

- Check the application to sudden large spike in the load generated by user -2000, 4000, 6000

4. Scalability testing
- Determine the application effectiveness to support an increase in user load

5. Volume testing
- Large no of data populated in the overall application & monitor behavior -10000

6. Endurance testing
- Check the application can handle the expected load over a long period of time -10000-1hr
123456789

RCCIIGSP

US- TS- TC

Retesting & Regression Testing

UAT testing

Production issue
Testing terminology

Priority & Severity

Retesting
- It is a part of functional testing
- Defines to validating the same functionality / feature by passing the multiple test data
Or
- Re execution of the same application/ functionality with multiple test data to validate
functionality of the application is known as retesting
- Ex. Paytm – Recharge module- operator – test data – BSNL, Airtel, JIO, VI…….
- Filpkart- login page –
Mobile no- BSNL, Airtel, JIO, VI……. Or
Email id – gmail, Yahoo,………..
- Test data- PO to provide test data / developer / database
- Test data- PO- sent through mail

- Retesting is performed only 2 times

1. Before the lock of the defect – we do retesting ------ 1 test data – defect – 2 to 3 time – same data-
other data enter – re execution of the same functionality

2. After developer fix the defect- we do retesting – tester – lock the defect – developer- developer
fix the defect – tester- test the functionality again – retesting

- Before lock the defect, we validate whether the defect is valid or not – 2 to 3 time re execute
- Before raising the defect, we have to check it, whether its good defect or bad defect
- While executing the test cases if we found the defect then we have to execute test cases with
multiple test data & still there is defect then it’s a good defect
 - While executing the test cases with one test data & if we found the defect , its considered as bad
defect

Retesting Process

We do retesting
Test case execute
Found the defect
Assign on JIRA to the developer
Defect ID
Developer fix the defect
Developer assign to the tester again
Tester – retest the previously failed test cases with multiple test data & ensure it work fine or not
If not working fine
Again tester reassign to the developer
Note-

Create defect on JIRA

Defect is valid then assign on JIRA tool

Select project –
Select issue – Bug

Summary – mobile number filed doesn’t have length validation

Description-
When I enter the mobile number less than & more than 10 digit so this mobile number accept it
Steps
- Open browser
- Enter Url
- Click on registration
- Enter mobile number in the mobile number filed

URL- defect ulr- https://paytm.com/recharge

Expected result-
Actual result-

Please also see the screenshots

Priority- medium (highest/high/medium/low)

Assign – search developer name – mangesh

Environments – Qa/ SIT

Attachment- defect screenshots

Epic / US link – select US registration

Select sprint – sprint 2

Click on the create button

Then defect id is generated

Developer – defect is valid – then he changes the code & deployed that on the build- new build

Developer comments on JIRA

“the issue/bug has been fixed, in this particular package I have changed this code not its working fine,
please retest it & I have given new testing build & testing data”

Tester – retested the functionality

If it is solved/working fine – tester comment
“We have verified build version/ particular functionality V 1.1 its working fine as expected & the defect
has been resolved”

If it is not solved/ not working

“The defect has been still existing in the qa environment. Kindly look to this defect, please find attached
below screenshots”

Regression Testing

During BBT- we execute test cases – if we found the defect – tester create defect on JIRA & assign to the
developer

Developer – if defect is valid- developer fix the defect- change the code & deploy to the build

Developer comment

Developer assign to the tester

Tester – execute the test case failed with multiple test data

Ensure its working fine or not

As well as we verify the impact of new code on interconnected module, main module or sub module

Or

We simply verify whether it is hampering other module or not

Or

Regression testing we validate defect has been working correct or not & there is not side impact on
interconnected module it also check
Or

Regression testing it is process in which we are testing modified build / newly corrected build to
ensure that they are working fine or not & also to check their side effect/impact on the other
working module or not

Ex. paytm- recharge module – mobile no- object-build(V 1.0) (1000) – retesting – VI, airtel, JIO,
BSNL….but BSNL is not working—tester will raised a defect to the developer- developer fixed the
defect – depolye code to the build – we get new build / modified build (V 1.1) (1050) & sent modilfied
build to the tester – as a tester we perform – regression testing (retesting (BSNL) + Regression
testing(side impact on the other functionality)(VI, JIO, Airtel,,,,))

Regression testing is performed 3 times

1. During the SIT- whenever we found the defect
2. After the SIT- whenever build is moving from SIT to UAT
3. After the UAT- whenever build is moving from UAT to prod

During the SIT

We get the number of defect & as well as new CR – we get the new build – defect are working fine or not
& CR & also check the impact of other module that particular defect & CR

During SIT- defect fix + CR = new build = regression testing (retesting defect + impact check)

After SIT
All fix= all defect = regression testing
Check all other module are working fine or not
After UAT
Client found defect – immediately developer fix the defect- after that we perform RT
UAT- New suggestion + CR = new fix = regression testing

To Create regression Suite (bunch of test cases)

1. Failed test cases (Ex. BSNL test cases)

2. High priority test cases / core functionality test cases (operator-JIO,VI,Airtel)
3. Extra feature or extra functionality test cases (+91)
4. If time limit is permit – we execute medium & low priority test cases

Regression testing we required 2 – 4 hr

My project, for regression testing we required 2 to 4 hr

Ex. manual test cases- module -200 test cases- regression suite – 70 to 80 cases

Types of RT
Impact analysis meeting is conducted – developer & tester

Unit RT-We are testing only changes, or modification part done by developer

Regional RT-We are testing only changing part & also impacted area

A B C D

Full RT-We are testing the changed features & also remaining part of an application

A B C D E F

UAT – user acceptance testing

- This UAT testing is performed after the completion of SIT environment testing
- It is also called end to end testing / customer acceptance testing
 - After SIT, during the UAT, the client conduct the no of session with us
- In that session include- PO,SM, Designer, dev. team & test team
- UAT- whichever testing client does related to their application, related to their all requirements
this verification is known as UAT
- UAT- collect feedback from the client
- During the client verifies
1. Whether application is as per the expected platform or not
2. Whether their all requirements have been full filled or not
3. Whether all new suggestion & CR have been executed or not
4. Whether technical approach is correct or not
5. Whether application is providing desired output or not
6. So during UAT client verify each & every functionality of the application step by step from
start to end
7. Objective- of UAT is to confirm application is ready for prod/ release or not

- Q messenger & Webex- we use for communication

- Slack & hangout- MT- is used for internal communication
- JIRA- used for ticket raise

- During the UAT we follow this process

1. Test team/ tester share desktop between client,PO,PM,TT,DT

2. Client select one user story & we have to execute test cases for that US
3. We execute test cases with the multiple test data & this test data is given by client (i.e.
business data)
4. Client validate start to end functionality with out of scope
5. If client satisfy then we update the result – successful
6. Sometimes client give suggestion & also new CR
7. In case, during UAT, if client found defect then developer has to check the log file, also tester
reproduce this defect in the SIT env. If defect is valid then tester raise the defect & developer
has to provide fix of it with estimation (high priority)
8. No of times UAT conduct & after that client updates the results, whether UAT has been
completed partially or successfully
9. Once successful – we get sign off then product is deployed for production

- UAT check or validating S & F testing

- UAT there are 2 types
1. Alpha testing
2. Beta testing

- In my project we perform the alpha testing

Alpha Testing
 - It is performed in the service based application
- In this testing -developer, tester , SM , client & product owner are involved
- This testing is performed in the controlled environment
- Where, test team share desktop between clients,PO,SM,TT,DT & client select US & we have to
execute the test cases with multiple test data & data is given by client
- Client verify or validate overall functionality of the application step by step from start to end
- If client found the defect, then developer check the log file, then tester has to reproduce the
defect in the SIT env. & to ensure defect is valid or not
- If defect valid- tester raise defect to the developer & developer has to provide immediate fix
- This testing is performed at development site
- Client is involved more in alpha testing

Beta testing

- It is performed in product base application

- It is carried out uncontrolled env. Or client location
- Developer & tester are not part of this testing
- End users are the part of this testing
- After the alpha testing application will be deployed at client env. & beta testing is performed at
client site in uncontrolled env.
- If defect is found in client location then immediate fix is not possible & fix is provide in the next
version

Alpha Testing Beta Testing

Service base application Product base application
Paytm, cred etc Khatabook, adobe reader
Both developer & tester are available Both developer & tester are not available
Defect immediately fixed Defect fixed on next version / not fix immediately
Controlled env. Uncontrolled env
Development site Client site
Client interaction is more End user interaction

One project – tester we not work in both env. (SIT & UAT)

One project – I work on the both env.

I have performed UAT testing – when UAT tester is on leave (2 to 3 month)

One project – both env. Sit & uat we can’t work

I have got chance to work in UAT team, in another project I have worked in UAT
 or

In same project but in the another module

Production Issue

- After UAT, we performed regression testing

- After the regression testing – the application is deployed in to production/live env.
- When client found any defect in the production env. is called as production issue or hot fix
- Production issue occurred due to 2 reasons
1. If production issue has missed the defect from your company these production issue are
called hot fix.
Client sent mail to project team or escalation mail (penalty apply)

a. Production issue – client mail to project team or escalation mail – tester (SIT) will check /
reproduce defect (production issue) in the SIT env.- if issue has been found in SIT env. – tester
will inform to PM, team & developer fix the issue asap- developer fix ASAP & tester will test the
defect (working fine)- developer will deployed to client (production/live). (PM ask to tester –
clarification mail reply)

I have missed the incident this time but I will take care future testing

b. Production issue – client mail to project team or escalation mail – tester (SIT) will check /
reproduce defect (production issue) in the SIT env.- if issue has not found in SIT env. – tester
will inform to PM, team & developer defect is not occurred or functionality is working fine – PM
will say to developer kindly check the deployment process (PM ask to developer – clarification
mail reply)

2. If found defect in the production due to missed the functionality / requirement from customer
side these type of production issue are called request for change/ change in request (CR)
Customer sent mail to project team
 Consider the new CR
a. If any CR / RFC from the customer side- don’t not impact on deployment or testing or production
- If impact is more – simply inform to the customer
- If impact is less then we will proceed

Production Issue

Company Client

HOT FIX RFC/CR

Impact analysis Impact analysis

Developer-coding Developer-coding

Tester- check Hot Fix Tester- test CR

Deployment -Prod Deployment-Prod

Testing Terminology

1. Monkey testing
2. Ad-doc testing
3. Exploratory testing

Monkey testing

- When we have maximum no of test cases but we have less time for execution then we perform
monkey testing
- When we have lot of test cases to execute but do not have a enough time to do execution of test
cases that time we perform monkey testing
- It is also called random testing / speed up testing
- In this testing, we execute
High priory test case
Core functionality test case
Positive test cases
Time limit is permit – medium & low priority test cases

- If we found a defect- immediately assign to the developer & try to get fix asap possible
- Situation arise- when developer find difficulty to solve bug, then that time developer take extra
time then that bug is called as blocker defect
When blocker defect comes, that time we do monkey testing

Other way situation

 - If we have more test cases (70-100) but we have less time for testing (1 /2hr) or
- If we got the build at last moment/time (1/2hr)
- Deployment will happens with (1/2hr) SIT to UAT or UAT to prod
- At these situation we will perform MT
- MT- only HPTC/ CFTC
- TCE- found defect – inform to the developer and fix ASAP
- Deploy to Client & inform that we have done TCE on only HPTC/CFTC

- But in MT- more than defects are present 10-15 then inform to the developer & fi x asap but it is
not fixed in Friday / last working day

- Saturday & Sunday we will work – developer will fix the defect & tester – will verify defect
15 defect- priority – developer- 10 fix – remaining -5
- Still if a defect is not fixed in Saturday or Sunday – New sprint we will create task or US “carried
over bug” developer – fix the defects & tester will validate the defect

Ad-hoc Testing

- When we are knowledge of application / aware about the application but, we don’t have test case
data or we have less test data to test the application then we perform ad-hoc testing
- For
Mobile test field
10 digit with country code
Our Mobile number- +91 9404624368
Account no filed accept- 14 (hard code- 12345678945612)

Exploratory Testing

- When we don’t have knowledge about application / we are not aware about application but we
have more test data then we perform exploratory testing
- Also called as Step by step testing & level by level testing
- As per previous experience we perform ET
- For Ex. other team member are on leave – 1 week – test data- US/TC/Builds- on this situation we
performed ET

Priority & severity

Priority & severity will defined against the defect

Priority
Defines defect impact on client business/client requirement
Importance of defect w.r.t client requirement
Types – very high, high, medium & low

Severity
Defines defect impact on functionality of application
Seriousness of defect w.r.t functionality of the application
Type- critical, high, medium & low

1. High Priority & High Severity-

 Ex. Login page is not working
 Ex. Core functionality is not working
 Ex. Share sell or buy functionality not working
 Ex. Paytm mobile number is not accepting

2. High Priority & Low Severity-

 Ex. Client logo is not present in application/ build
 Ex. Feature/ functionality text are overlapped with each other
 Ex. Home page spelling error in logo or in Focus world spelling mistake
 Ex. Drop-down functionality not display proper

3. Low Priority & High Severity-

 Ex. Rarely functionality – invoice download or Coin functionality not working
 Ex. Rarely functionality it is not working (Paytm- Promo code)

4. Low Priority & Low Severity-

 Ex. Spelling mistake in text present in button/ link/ drop down
 Ex. Text has been changed Submit button  Processed/ Ok button
 Ex. Thank message, spelling is wrong –“Thank you” = “Thanks you!”
 Ex. Some of button, World as “Submit” but spelling “OK”

 Who will decide the severity & priority in your current working project?
  Severity – we will be decide by tester
 Priority – Initial we will decide Priority while creating defects, but in standup I will
inform to PM, BA and they will decide

Interview question-
1. What is system & functional Testing?
2. What is system testing?
3. What is functional Testing?
4. What is different testing, you have performed in your project?
5. Which testing you will perform after getting a defects?
6. What is re-testing & Regression Testing?
7. What is UAT testing? Where you have done UAT Testing?
8. What is Production issue? Have you work/ handled production issue?
9. What are your approaches, if you got production issue?
10. What are your approaches, if you got defects in UAT?
11. What are your approaches, if you have less time for testing & you have more test cases to
execute?
12. What are your approaches, if your another tester is on leave & your have do the test cases
execution?
13. What is Error, Defect & Bug
14. What are different testing terminology?
15. What is Priority & Severity?
16. Give me the example of is high Priority & Low Severity & Low Priority & High Severity
17. What is ready & done state for US?
Answer- Ready – US is completed for development & Testing ready for deployment.
Done- US is completed deployed to client
18. Who will do the deployment of US?
Answer- In my project, we will do deployment at every Saturday/ Monday
Deployment will be done by developer

19. What are your approaches, if you have less time for testing & you have more test cases to
execute?
Answer- If we have more test cases to execute (50 to 60 TCD) and we have less time for
execution (1 hr to 2hr) OR if we got build in last moment (last Friday) from developer OR
When we have to move build from SIT to UAT/Prod and we have less time(1 to 2hr), on these
situation we will performed/ we will follow Monkey testing approaching
Monkey testing approaching, we will execute only high priority test cases/ test cases related to
core functionality of application
If we get defects in these monkey testing approaches OR if we got defects in testing high priority
test cases/ test cases related to core functionality of application
On these situation, we will work on Saturday / Sunday
Developer, Tester & PM will work on Saturday / Sunday. To fix that issue Test US
deployment to client

20. What is your approach, if we have not completed the development & testing of US and you have
missed the delivery time line/ deadline?
Answer- Current sprint (sprint 1) - 1US- development is completed but testing is reaming. These
US will mark/ comments against US as carried forwardInto Next sprint (Sprint 2) In Sprint 2,
we will performed only testing activity

21. What is your approach, if a defect has been not fixed in current sprint, what you will do?
Answer- If defects has not fixed in current sprint, then we will work on Saturday / Sunday We
will try to fix these defects
1. If defects has been fixed in Saturday / Sunday then tester will test and deployment to client
2. If defects has been not fixed in Saturday / Sunday, then we will moves these defect into next
sprint (Sprint 2) US – “Carried over Bug”