* SOFTWARE TESTING INSTITUTION*

CONTACT NO: 9545762176

Page | 1
 Index
Sr.No. Topic Page No.

1 Software Testing 3

2 SDLC 4

3 Waterfall Model 6

4 V-Model 7

5 Architecture of Agile 8

6 Different Types of Meetings (Ceremonies) 10

7 Testing Approaches 12

8 Testing Terminologies 13

9 Test Case Reviews 14

10 Black Box Testing 15

11 Functional Testing 15

12 Software testing Life Cycle 18

13 Difference Between V-Model and Agile Model 19

14 Scrum 20

15 Types Of Testing 21

16 Sanity and Smoke Testing 23

17 Retesting and Regression Testing 24

18 Types Of Environments 24

19 Change Request 25

20 Defect Life Cycle 25

21 Priority and Severity 26

22 Conditions Of Priority and Severity 27

Page | 2
 Software Testing
Definition: - Software testing is a process to identify the correctness, completeness and
quality of the development software.
OR
- To find whether the developed software met the specified requirements or not.
OR
- To identify the defects to ensure that the product is defect free in order to produce the
quality product.
SDLC: - Software development life cycle.
- It has divided into two types.
1) LCD = Life Cycle Development
2) LCT = Life Cycle Testing

Stages in SDLC:-

Requirement Gathering

Analysis

Design

Coding

Testing

Maintenance

Page | 3
SDLC Definition :-
- SDLC is a process used by software industry to develop, design and test high quality
software. SDLC aims to produce high quality software that meets customer
expectations and reaches completion within time and customer estimation.

Information Gathering :-
- Business Analyst (BA) is responsible for information gathering.

- Information gathering is nothing but requirement gathering from client.

- It involves Business Requirement Specification.
- BRS is a bridge between client Developer and Tester.

- BA prepares BRS document.

Analysis:-
- BA involves in this process.
- In Analysis phase SRS is made.
- SRS = Software Requirement Specification.
- SRS is detailed document.
BRS :-SRS:-

- Gather req. Ex. Banking Project -Same Ex.

- Sign Up - Sign up page should have = Name
- Home Page - Number
- Account info. - Email
-password
-This is overall requirement gathering. -This is detailed specification which shows
minor unit of software.

SRS :-

- SRS is simplified version of BRS.

- It consists of :-
- Functional flow diagram
- Functional requirement
- Use cases and Snapshots

Page | 4
Design :-

- In design phase senior developer and project architect designs HLD & LLD.
- HLD- External Design / Main Module (High Level Design)
- LLD- Internal Design / Sub Module (Low level Design)
- Ex. According to our project the HLD contains

My Trade Bulk Upload Authentication Transaction

These are the main modules of my project.
- Ex. According to our project the LLD contains.
Trade type Security type Quantity Amount
All above are the sub modules of my project.
Coding :-

- Coding is written by developer and written coding is being checked by senior developer.
- It includes WBT (White Box Testing)
Testing :-
- Testing is the process of checking correctness and completeness of the software.
- It includes WBT, BBT, Gray Box Testing.

WBT BBT
Developer performs WBT Tester performs BBT
It is Coding level testing technique It is Build level testing technique
Developer checks presence of defect in Tester checks presence and absence of
code. defect in code
Developer tests only positive scenario Tester tests positive and negative scenario.
Developer only concentrates on UI or Tester concentrates on front end and back
GUI(Front End) end.

Maintenance :-
- Maintenance means to provide service after delivery of the product.

Page | 5
Waterfall Model :-

Requirements

Analysis

Design

Coding

Testing

Maintenance

- Waterfall model is a linear sequential model of SDLC.

- We can only go to the next stage only after completion of first or existing stage.
- If new requirement comes, we cannot go back to the previous stage.
- When the requirements are fixed then and then only this model can be used.
- It is outdated module as of now as customer requirements are changing continuously.
- Generally, the release time duration of waterfall model is 3 months.

Page | 6
 V Model :- (Verification / Validation)

- V Stands for verification and validation.

- There will be mapping of development stage & testing stage at a similar level.
- It is mostly used model because Development and Testing runs parallelly.
- In this model extra cost is charged for new change request.
Agile Model :-
- Agile is a flexible and Iterative model.
- Developer and Tester, they both accept changes at any phase in this model and it does not
impact on functionality and performance of the product or software.
- Even if we get frequent changes in requirements that do not impact on development,
testing and production.
- This is the model in all SDLC models which is being used at the most.
- There are different types of Agile model which are as follows : -
XP (Xtream programming)
Scrum
Lean
KANBAN
DSDM (Dynamic Software Development Method)
FDD (Future Driven Development)
Page | 7
CR / RFC :- (Change Request / Request for Change)
- Whenever any requirement comes during the test execution or even after build goes to the
production that is known as Change request or Request for change.

Architecture of Agile:-

Stake Holder
Product Owner
Product Backlog

Sprint Backlog
User Story

Test case design

Stake Holder :-
- Stake holder tells the requirement
Product Owner :-
-Product owner collects the list of requirements.
Product Backlog :-
- Product backlog consists of overall requirement of an entire project.
- In this stage all requirements are well groomed and prioritized.
Sprint Backlog :-
- In sprint backlog committed stories get stored as per Tester and Developer (Scrum Team)
- Note:- In this stage we collect sprint backlog stories as per the previous sprint velocity.

Estimation :-
- Selection of particular requirement from product backlog for releasing one sprint.
- The criteria on what basis they decide an estimation is as follows :-
- Knowledge of a team
- complexity of an application / requirement
Page | 8
 - Effort and how much time is required to deliver these requirement.
User Story :-
- User stories are the description of requirement which consists of
1. Use cases
2. Screen shots
- Product owner writes stories.
- Based on user stories test engineer writes test cases and that is known as test case design.
- We get user stories via Jira tool or Mail.
- User stories consists of :-
1). Description:- Requirements of the customer should be briefly described inside stories.
2). Acceptance Criteria :- Whatever requirements we get from the clients those are required to be
tested whether those fulfill or not. Acceptance criteria should fulfill all requirements.
Test case design :-
- Here we write the test cases from SRS, FSD.

Page | 9
* Different meetings in agile (ceremonies):-
- Sprint planning meeting
- Scrum meeting
- Sprint review meeting
- Retrospective meeting

Sprint planning meeting :-

- It happens at the starting of every sprint.
- PO, Developer Lead, Tester Lead these are there in this meeting.
- They decide the whole work plan.
- This meeting happens at once at the starting of the sprint for one sprint.
Purpose :- To determine what work to do in the coming sprint.

Scrum Meeting :-
- This meeting is also called as daily scrum meeting, every day status call, everyday happen.
- Test engineers are involved in this meeting along with testing team, dev team, scrum
master, product owner.
- For 9.30 to 6.30 PM shift, scrum meeting happens at 9.30 AM. it lasts for 15-20 mins.
- It allows team member to commit, collaborate and communicate with the risk.
- Scrum master leads this meeting.
- What is to be discussed in scrum meeting
1. What we did yesterday?
2. What is to be done today?
3. What are the roadblocks?

Page | 10
Sprint review meeting :-
- This meeting happens at final stage (i.e. after the completion of the sprint)
- Stake holder (client) gets involved in this meeting.
- Purpose:- The work is completed by team during the sprint is get discussed to receive
feedback from stakeholder.
- Frequency :- It happens at once in the end of the sprint.

Retro-spective Meeting :-
- The agenda of this meeting are as follows
1. What went well
2. What went wrong
3. What are the improvement area.

Page | 11
Testing Approaches :-
- Top down approach
- Bottom up approach
- Sandwich approach / Bidirectional
Top down approach :-

- In this Approach, main module is M1 which is developed and M2 is sub module which is
under construction phase or physically not present for testing or it can be developed by the
other company.
- Here submodule is under construction so we can use this as a dummy module and it is called as stub.
- Stub :- It is a temporary program used to check main module instead of under constructive.
- Stub is written in XML format and it contains tag & values in the format
<tag> value
<color> black color
<Qty> 200
<Amount> 5000
Tester uses notepad for uploading XML file.

Bottom Up Approach :- Driver

M1

M2 M3

- In this approach M2 & M3 both modules are developed and its main module is under
construction or it is not physically present for testing.
Page | 12
- Here M1 is under construction so we can use dummy module i.e. driver.

Sandwich approach / Bidirectional /Hybrid Approach :-

M
1
Driver

M2

M3

Stub
- In sandwich approach, it is a combination of top down approach and bottom up approach.
- We use this module where there is a situation like our component which we test that works
as main module as well as submodule.

Testing Terminologies:-
1. Monkey Testing
2. Exploratory testing
3. Ad-hoc Testing.
1. Monkey Testing :-
- When we need to test lots of test cases but we don’t get enough time to execute those test
cases at that time we understand the priority of the test cases and we execute some of them on
priority is known as monkey testing.
- In this testing, Test Engineer performs according to the High, Medium and Low priority of
the test cases.
2. Exploratory Testing :-
- We perform this testing when we are not aware about the application but at the same
time we have test cases, test data and SRS in this situation perform exploratory testing.
We have data like test cases and SRS but lack of domain knowledge.

3. Ad-hoc Testing :-
- We perform this testing when we are aware about application and at the same time we have test cases
but we don’t have test data at that time we perform ad-hoc testing. We have test cases and domain
knowledge but lack of test data.

Page | 13
 Test Cases Review
1. Self Review
2. Peer Review
3. Internal Review
4. External Review

1. Self Review:-
- When Test Engineer reviews self test cases that review is referred to as self review.

2. Peer Review:-
- When any other team member reviews the test cases of ours that is referred to as Peer
Review.

3. Internal Review :-
- This is being done by testing team along with developer lead and test lead.

4. External Review :-
- Whenever any inspections come at that time they review the test cases.
- Client reviews the test cases that comes under external review.
BLACK BOX TESTING:

BLACK BOX TESTING

USABILITY Functional and NON-Functional Testing

Performance and Security
TESTING

Page | 14
-FUNCTIONAL TESTING
Type of Functional Testing are:-

1. Behavioral Testing

2. Input- Domain Testing

3. Error Handling Testing

4. Backend or Database Testing

5. Sequential Testing

6. Calculation Based T esting

1. Behavioral Testing;
In this we check Behavior of the application i.e “object” and it’s “property”
Eg;
OBJECT PROPERTY

Radio On /off
Button

Button Enable/
Disable

Page | 15
2. Input-DomainTesting:

In this we check the size and type of data to be input in textbox

This is applicable only for textbox-object
It has 2 methods
1.BVA- Boundary Value Analysis
- To Calculate length [min max] of the input data entered in textbox
Ex-
To pass the Customer Requirement,4-6 char should be
There we use 6 Scenarios :

Scenarios Status

Min= Pass
4

Max= Pass
6

Min- Fail
1=3

Max+ Fail
1=7

Max- Pass
1=5

Min+1 Pass
=5

Page | 16
2 . ECP- Equivalence Class Partitioning
-To find validate the data type.
Data types are divided into 2 type
Valid and Invalid
Valid Invalid

A-Z SPACE
a-z
(@,#,$)

3. Error handling Testing :

- It prevent negative navigation
- Testing with valid as well as invalid data
-It include checking whether system shows error message or not
EX-
When we have to insert 10 digit number and we enter 9 or 11 digit we should be shown
error message i.e invalid mobile number .
4. Backend or Database Testing;
-In this testing we check that data entered by user in frontend is stored in database or not.
-To check we are able to fetch data from Database .
5. Sequential or Service level Testing :
- To check the navigation of the application is in sequence or not.
- Functionality should be check in sequence only.
6. Calculation based Testing :
In this arithmetical operation takes place such as Subtraction, Addition,
Division, Multiplication.

Page | 17
 SOFTWARE TESTING LIFE CYCLE

TEST SENARIO IDENTIFICATION

TEST
TEST PLAN TEST CASE PREPARATION
INITITAION

RETESTING TEST CASE

DEFECT EXECUTION
REGRESSION

TEST SUMMARY REPORT

- In my organization testing process start as PM does the

- TEST INITIATION
-Where PM focuses on

- Risk involved in the project.

- Req. in the project.
- Scope of the project.
TEST PLAN
-It is prepared by Test Lead

-Test lead focuses on

1. Job allocation
2. Resource allocation
3. Estimation
TEST SCENARIO IDENTIFICATION
-It is done by Test Engineer
-In this Test Engineer identify the scenario for preparing Test Case .

Page | 18
TEST CASE PREPARATION:
-It is prepared by test engineer.
-Test engineer prepares Test Cases from SRS.
TEST EXECUTION
- In this the test case are executed to validate the functionality
- If we find any defect TE register it on JIRA
- Developer fix the defect and send it to TE in UAT Environment
- TE will perform Re-testing and Regression Testing.
- If the defect is fixed TE will closed the defect.
- If the defect is not fixed TE will Reopen the defect and this cycle will continue till
the defect is Fixed.
After this stage the Test Engineer prepare Test Report and send to the Test Lead

TEST SUMMARY REPORT

In this TE send the report to the Test lead and Test Lead prepares the Test Summary Report.

• Different Between V-Model And Agile Model.

-V-Model -Agile-Model
Client Stake Holder
BUSSINESS ANALYST Product Owner
Business Requirement Specification (BRS) Product Backlog
Software Requirement Specification (SRS) Sprint Backlog

Product Owner Scrum Master

Use Case/Requirement in SRS User Stores
Release Sprint

Page | 19
➢ SCRUM

➢ Scrum – Cross Functional Team

i.e - Independently Working, without taking help from
others.

➢ Scrum Role-
1. Scrum Master
2. Product Owner
3. Developer
➢ Scrum Master –
o He/she plays different role from project manager.
o Scrum Master is servant leader

➢ Scrum team size :

- Scrum Master – 1
- Product Owner – 1
- Development team -7
➢ Total Scrum team – 9

SCRUM MASTER

TEST LEAD
DEV. LEAD
TESTER
DEVLOPERS

Page | 20
TYPES OF TESTING :
- WHITE BOX TESTING
- It is unit level testing in which small code or a piece of program gets
tested by developer.
- GRAY BOX TESTING
- In this testing tester has some knowledge about coding.
- It is combination of WBT and BBT.
- Tester should resolve the defect by making changes in code.
- RED BOX TESTING
This testing is related to embedded system, mobile device testing.
- BLACK BOX TESTING
- Performed by tester
- Tester check the functionality of the software .

• USABILITY TESTING;
- It is GUI (Graphical User Interface ) related testing .
1. Look & feel
2. Easy to use
3. Speed of Processing.
Look & Feel- The Screen should be attractive & pleasant.
Ease to use - The UI should be as simple as it can be used by anyone.
Speed of processing - It takes less number of Events to complete the task.

Page | 21
 • UAT TESTING (USER ACCEPTANCE TESTING)

- UAT or User Acceptance Testing is the final stage in the software testing process.
- There are 2 Types of UAT Testing;
1) ALPHA
2) BETA

ALPHA BETA

-This is applicable for software -This is applicable for software

application product.

- This testing is done in -This is being done at Customer

our organization under Side in uncontrolled
controlled environment in environment absence of
presence of Developer and developer and tester
Tester.
-This testing is done by our client -This testing is done only by end
customer (END USER)

Page | 22
SANITY TESTING AND SMOKE TESTING

- Smoke testing
- When build is received from developer tester will do testing of critical functionality.
- Does installing software contains all files or not.
Build provided by developer is stable or not to the environment
- Build verification testing
- Sanity Testing
- When build is sent to us by developer tester test the basic or core
functionality of the software.

- DIFFERENCE BETWEEN SMOKE AND SANITY

SMOKE SANITY
- Done to make sure the build is - Testing of basic or core
stable or not functionality of the app.

- Done by both developer and - Done by tester only.

tester.
- It is done on a Initial Build. - It is done on a stable build

Page | 23
 • RETESTING AND REGRESSION TESTING

• RETESTING:
Retesting is a method of Re-Executing some build /application with Multiple
Test Data.
It is rechecking the functionality when test case gets failed.

• Regression Testing:
It is performed in two cases:
1) When developing new functionality it should not impact on existing module.
2) When any defect is found & fixed by developer then we perform retesting
and regression.

- CHANGE REQUEST (CR):

- If any new requirement comes during test execution or after build goes to production
it will be considered as CR-CHANGE REQUEST

TYPES OF ENVIRONMENT
• DIT
• SIT
• UAT
• PRODUCTION

• DIT – DEVELOPMENT INDEPENDENT TESTING

• Developer performs unit testing

• SIT- System integration testing

- When build is received from developer, we perform testing such as
- Sanity testing
- Functionality testing

Page | 24
 - Regression / Retesting.
• UAT (User Acceptance testing)
- Customer involved in testing.
- Different T.E are involved in this testing than SIT, As they might get new defect
apart from SIT.

• DEFECT LIFE CYCLE

- When tester finds any new defect then tester logs the defect in JIRA and assigns it to the respective
developer.

- Now defect status remains “OPEN”

- As developer takes action on that defect, developer puts that defect in analysis vendor.
- In analysis vendor developer has 3 choices
1) Fix – In this developer fixes the defect.
2) Reject /Duplicate - when defect is not valid / when someone has already raised that defect.
3) Deferred – Not necessary to fix immediately but has to be fixed at the end of the sprint.
- If developer decides to Fix the defect, developer will send the fixed defect in UAT environment then
tester performs Retesting and Regression Testing and if defect is fixed properly then tester closes the defect
and if the defect is not fixed properly then tester re-opens the defect and send it back to developer in
analysis vendor. This cycle continues till the defect gets resolved (fixed).

Page | 25
• PRIORITY AND SEVERITY
Priority ;
- Importance of defect with respect to customer
Requirement.

Types are:
• Critical:
- Critical is also called showstopper and blocker.
- In this the core functionality of application is blocked, this type
of defect has to be resolved immediately.
• High :
- Defect should be resolved as early as possible as it is affecting
application functionality. It is also called as major.
• Medium: It is also called minor.
- In this cosmetic error is handle such as expecting the right error message
during failure.

• Low:
- it is an issue but does not have to be fixed immediately.

• Severity
- Seriousness of defect with respect to customer functions.
Types are:
• Critical
• High
• Medium
• Low

Page | 26
 • 4 CONDITIONS OF PRIORITY AND SEVERITY

• High priority – High severity

- An Error which occur on the basic functionality of application and will not allow
the user to use the system.
Ex- User is not able to log in to application.
• High priority – Low severity
- If the company Name is mis-placed on Home page of Website.
• High severity – Low priority
- Web page not found when user clicks on the link.

• Low priority – Low severity

- Cosmetic issue or spelling issue which is within program or in report.

Page | 27
Study Hard !!!
All The Best !!!
Thank you!!!

Page | 28
Page | 29