SDLC

(Software development life cycle)

Definition:
It is a procedure to develop the software.
Stages:

When do we follow SDLC?

Whenever a software company or a person wants to develop a new software
they have to follow SDLC
What will happen if we don’t follow SDLC?
1)We will not get to know how much money should be invested
2)We will not get to know how many resources are needed
3)We will not get detailed requirement document
4)There might be delay in releasing the software
Models of SDLC:
1)Waterfall model
2)Spiral model
3)Prototype model
4)V-model
5)Agile model
Waterfall model
Definition:
It is a step by step procedure to develop the [Link] is a
traditional model
Stages:

Why do we call it as waterfall model?

Here the the progress is seen as flowing downwards like a waterfall therefore
this model is called as waterfall model
Requirement collection:
Here the business analyst will go to the customer place and collect the
requirements. Requirement is in the form of CRS (customer requirement
specification) CRS is converted to SRS, meaning “business language” is
converted to “software language “by the BA /PA
CRS: It is the requirement document in the form of customer business language
SRS: It is the requirement document in the form of the software language
BA: He will Convert CRS to SRS in the Service based Company.
PA: He will Convert CRS to SRS in the Product Based Company.
Service Based Company: They provide service and develop software for other
companies, according to their requirement
Ex: Infosys, Wipro, TCS……
Product Based Company: They develop their own software and sell it to other
companies which may need the S/W & earn profit
Ex: Microsoft, Oracle, Google…….
Who can become a Business Analyst?
Domain Expert -> Person who have worked in the same domain for more than
10-15 years
Senior Developer -> Developer who have worked in the same project domain
for more than 6 to 7 years
Sr. Test Engineer -> Test engineer who has tested in the same project same
for more than 6 to 7 years
Feasibility Study:
It is done by a team.
The team consists of Business Analyst, Project Manager, Architect, Hr Team
and finance Team
Here we check for:

Technical feasibility: Here we check technology is available or not to develop

 the software (It is done by architect)
Financial Feasibility: Here we check budget is available or not to develop the
software. (It is done by Finance Team)
Resource Feasibility: Here we check resource is available or not to develop the
software. (It is done by HR Team)
Architect: He will do the technical feasibility study and tell which technology to
use for developing the software. Any Sr. Dev can become an
architect.
Design:
Here we do high level design and low level design of the software
1. High Level Design: It is done by architect & Sr. Dev.
It is the architect of the software to be developed
2. Low Level Design: It is done by Sr. Dev.
It describes how each and every feature in the
software should work, how each and every component
should work
Coding:
Here we start building the software or writing the code for the product. It is
done by Sr. Dev, Jr. Dev, Freshers
Testing:
After coding we start testing where in we identify defect in the software it is
done by test engineer
Note: In waterfall model, developers are involved in testing.
Why Developers should not be involved in testing?
1. Developers consume most of the time for developing the software rather
than testing and testing will have no time
2. Developers see the product from the positive point of view and not from
negative point of view
3. Developers will have over confidence on the software that they have
built.
4. Developers might find the defects while testing but still end up not fixing
it.
Installation:
After the software is develop & tested it is installed in the customer place for
using it is done by installation engineer
Maintenance:
After the software is installed and used if the customer finds any defect, the
software company will fix it according to agreement that is, if the defect is
found in the maintenance period then the software company will fix it free of
cost
Advantages:
1. Requirement or Design doesn’t change so we get a stable product.
2. Quality of the software is good.
Drawbacks:
1. Backtracking is not possible i.e. for example, we cannot change the
requirement once the design stage is completed, meaning the requirement
are freezed. Hence this model is not flexible.
2. Requirement is not tested, Design is not tested, if there is any bug in the
requirement it does till the end & leads to a lot of rework.
3. It is a traditional model, where developers were involved in testing.
Applications:
1. We go for waterfall Model to develop simple applications where the
requirements are fixed.
2. We go for Waterfall model to develop short term products where the
requirements are fixed.
Ex: Alarm, Calculator.

Spiral model
It is the process of developing the software. Here software is developed module
wise

Here once requirement collection for ‘A’ is done, we go for design of module A
Once design is done & after coding we go for testing of ‘A’ same process
continue module wise for the upcoming requirement.
How can we handle the changes?
1)Major changes

2)Minor changes
Advantages:
1) Requirement changes allowed after each cycle with minimum effort
2) Addition of new requirement is allowed
Drawback:
1) Same process repeated for each & every module
2) It is a traditional model where developers are involved in testing
Application:
We go for spiral model whenever customer gives the requirement in stages

Prototype model
Here we develop a prototype model or a dummy model before actual
development of the software

Here, the customer looks at the prototype and give the feedback if any changes
are needed
After the prototype is confirmed by the customer the actual design, development
and testing of the software happens
Advantages:
1)Good communication between the customer & development team
2)customer can make the changes if needed after looking at the prototype
Dis-advantages:
1)Investment is more
2)Delay in starting the actual development
Application:
1)when customer is new to the software
2)when developers are new to the domain
3)when customer is not clear about his own requirement

V-model
It is a step by step procedure to develop new software. It is also called V and V
model which means Verification and Validation model
Verification:
It is the process of reviewing CRS, SRS, Design and Code, Test Case and
related documents
Validation:
It is the actual testing done after the software is developed. Here we execute the
test cases
Here both the testing and development teams are parallelly involved.
Both the testing team and development team first do the verification process and
then validation process.
Verification is done to prevent the defect.
Once the software is ready, validation is done in order to identify and fix the
defects

Advantages:
1. Testing starts from the initial stages i.e. Requirement and Design are
tested.
2. Downward flow of defects is reduced
3. Software quality will be good
Disadvantages:
1. Initial investment is more
2. Documentation is more
Applications:
1. Complex projects and huge projects
2. For long term projects

Software testing
Process of finding the defect in the software is known as software testing
 (OR)
Verifying the functionality of an application against requirements specification
is called software testing
(OR)
Execution of program with the intent of finding the defects is called software
testing
Why do we do software testing?
1)Every software is developed to support the business. If there is a defect in the
software it affects the business. So, before we use the software for business it
should be tested, all the problems must be recognized & solved
2)To check if the software is developed according to the requirement
3)To improve the quality of the product
Ways of testing
a) Manual testing:
Testing the software repeatedly manually in order to find
defects in the software according to the requirement specification is
called as manual testing
b) Automation testing:
Test engineer will write code/program/script by using
tools like selenium/QTP & run the program against the software. Tool or
program will automatically test the software & give the result as pass or
fail this concept is called as automation testing
Types of software testing
1)White box testing
2)Grey box testing
3)Black box testing

White box testing

Testing each and every line of code is called white box testing
Types of white box testing:
1)Path testing
2)Condition testing
3)Loop testing
4)White box testing from memory point of view
5)White box testing from performance point of view

a) Path testing:
Here developer will write the flowchart & test all the independent path

Advantages of flow graph:

1) Will not miss any path
2) Will not repeat any path
b) Condition testing:
here developers will test all the logical condition for both true & false values
c) Loop testing:
here developers will test the loop and ensure that the logic is repeating for all
defined number of cycles

d) White box testing from memory point of view:

What are the typical mistakes done by developer because of which size of the
code increases

● Because of repetition of same code instead of writing the function

● Because of not using inbuilt function

● Because of unused variable & function

e) White box testing from performance point of view:

 ● Because of not using better logic

● Using proper AND & OR

Black box testing

Verifying the functionality of an application according to requirement

specification is called as black box testing
It is done by test engineers
 Functionality testing
Testing each and every component thoroughly against requirement specification
is called functionality testing.

Component:
Component means that can be link, text field, text area, drop down, button,
widget.
Thoroughly:
Testing the component by entering all the possible input is called as thoroughly
Why should the requirements be numbered?

● It is very easy to understand the requirement

● There will be clarity in the requirement

● Requirement becomes traceable

● Requirement becomes measurable

● It becomes very easy to communicate between developer testing team &

customer
We can do any type of testing in 3 different ways
1) Over testing
 2) Under testing
3) Optimized testing

a) Over testing:

Testing the application with the same scenarios in different ways

(OR)
Testing the application with those scenarios which doesn’t make sense is called
as over testing
Dis-advantages:

● By doing over testing we will waste lot of time

b) Under testing:

Testing the application with insufficient set of scenarios is called as under

testing
Dis-advantages:
 ● By doing over testing we will miss lot of defect
c) Optimized testing:

Testing the application only with those scenarios which make sense is called as
optimized testing
Advantages:
1) TE will not miss any scenarios
2) TE will not miss any defects
3) There will be no duplicate
4) Time will not be wasted
5) Quality will be good
Positive testing:
Testing each and every component of an application by entering valid or
expected data which is according to the requirement specification is called as
positive testing.
Negative testing:
Testing each and every component of an application by entering invalid or
unexpected data which is not according to the requirement specification is
called as negative testing
Rules:

● Always start testing the application with valid data if the application
works for valid data then only test for invalid data
● If application is not working for one of the invalid values you can
continue for testing some more invalid value
 ● Test engineer should not assume (or) purpose the requirement if you have
any queries (or) question you should integrate with developer,
customer(or) business analyst and get it clarified.

Integration testing
Testing the data flow between (or) interface between two modules is called as
integration testing.

Integration scenario:
1)Login as user ‘A’, click on amount transfer, enter FAN as user ‘A’, TAN as
user ‘B’ and enter amount as (RS.1000) and click on transfer. Confirmation
page should be displayed. Logout as user ‘A’. login as user ‘B’, click on the
amount balance and check if the proper balance is displayed or not logout as
user ‘B’.
Q. How to do integration testing?
1) Understanding the application is very important
a) You should understand each & every module
b) You should also understand how all the module are related
2) Identify all possible scenario
3)Prioritize the identified scenario
4)Document the scenario according to priority
5)Execute scenario
6)If you find the defect send it to developer
Positive integration testing:
Amount Transfer is less than or equal to balance this testing is known as
positive integration testing
Scenario:
Login as user ‘A’ check for amount balance, click on amount transfer, enter
FAN as user ‘A’, TAN as user ‘B’ and enter amount as (Rs.1000). click on
transfer confirmation message will be displayed, logout as user ‘A’. login as
user B, click on amount balance, there proper balance should be displayed (old
balance+1000), logout as user ‘B’
Negative integration testing:
Amount transfer is more than the balance
Scenario:
Login as user ‘A’ check for amount balance, click on amount transfer, enter
FAN as user ‘A’, TAN as user ‘B’ and enter amount as (Rs.15,000). click on
transfer logout as user ‘A’. login as user B, click on amount balance, there old
balance should be displayed logout as user ‘B’.
Type of integration testing:
Incremental integration testing:
Incremental add the modules & test the dataflow between the modules is called
as incremental integration testing.
Top-down incremental integration testing:
Incrementally adding the modules & testing the dataflow between the module
and make sure that the module which is added should be the child of the
previous module.

Bottom-up incremental integration testing:

Incrementally adding the module & testing the dataflow between the module
and make sure that the module which is added should be the parent of the
previous module.
Non-incremental integration testing:
Combining all the modules at once and testing the data flow between them is
called as non-incremental integration testing.

Drawback of non-incremental integration testing:

1) Chances is there we might miss some dataflow
2) Chances are there we might end up testing same thing again & again
because of this time taken will be more
3) It is difficult to identify the root cause of the defect

Difference between stubs and driver?

If one module is ready & another module is not ready then how will you do
integration testing?
Stubs: it is a dummy module, it acts like module which is not yet build, it
generates the data & receives the data
Driver: it is one which set up the testing environment and does lot of
transaction, analyse the result & send the output (does the transaction between
real module & stubs)
 System testing
It is an end to end testing where in the test environment is just similar to the
production environment.
End-end testing:
Navigating through all the features and check whether the end feature is
working as expected or not.

OD Flow:
Types of environment:

Development environment:
It is the setup which is used for developing the software
(it consists of hardware, software, server, network)
Test environment:
It is the setup which is used for testing the software
(it consists of hardware, software, server, network)
Production environment:
It is the setup which is used for run the software
(it consists of hardware, software, server, network)
When do we do system testing?

● Whenever the environment which is just similar to the production

environment
● Whenever the module is functionally stable (a smaller number of defects)

● Whenever bunch of modules are available

Terminologies:
Build:
When developers write the code & compile the code to get the binary we get
the file format, that file format we call it as build.

Test cycle:
It is the time spent or the effort spent by the test engineer to start and end the
testing.
 Respin:
The process of getting a new build within one test cycle is called as Respin.
If there are blocker defects, we will get Respin.
To install respin, first you should Uninstall old build and install respin.

Patch:
Patch is a small software which consists of modified programs, added
programs and removed programs.

Release:
Starting from collecting the requirement, developing the software and testing
the software for so many cycles and releasing the software to the customer
we call it as 1-release.

Acceptance testing
It is an end-to-end testing done by IT engineers, sitting at customer’s place
where in they take out the real time business scenarios & check whether
software is capable of handling it or not.

Why do we do Acceptance testing?

1. Chances are there under business pressure software company might push
software to the customer with critical bugs, to prevent that they do
Acceptance testing.

2. If they use software with the critical bugs for business they will undergo
severe loss, to avoid that they do acceptance testing.

3. Chances are there development team would misunderstand the

requirement & develop wrong features, to find such features customer will
do Acceptance testing.

Approach 2:

It is an end-to-end testing done by end-users wherein they use software for the
business for a particular period of time and check whether software is capable
of handling all real time business scenarios.
Approach 3:

It is an end-to-end testing done by our own TE sitting at customer’s place where

in they refer user scenarios given by the customer and check whether software
is capable of handling all real time business scenarios.

Approach 4:

It is an end-to-end testing done by our own T.E sitting at our own place where
in they refer user scenarios given by the customer and check whether software
is capable of handling all real time business scenarios.
 Smoke testing

Testing the basic or critical features of an application before going for

thorough testing is called as Smoke Testing.
Advantages of Smoke testing:

1. T.E can find all the blocker defects in the early stage itself.

2. Developers will get sufficient time to fix the defect.

3. Test cycle will not get postponed and the release will not be delayed.

Points to remember:

· In smoke testing we test only basic or critical features.

· We take every basic or critical feature and test for 1 or 2 important

scenarios.
 · Here we do only positive testing.

· In the beginning we will not be able to identify basic or critical features,

we will learn it only after getting very good product knowledge.

When do we do smoke testing?

1. Whenever we get a new build from the development team we should

always start with smoke testing because adding, modifying, removing the
features or fixing the defects might affect basic or critical features, to find
that in the beginning they do smoke testing.

2. Customer before he does acceptance testing he should also do smoke

testing:

a) To check whether he has received the complete product or not.

b) To check whether the product is properly installed and configured.

3. One who installs the product in the server should do smoke testing to
check whether the product is installed properly or not.

4. Before they give build to testing team, developers should do smoke

testing so that too many defects are there means they need not give build to
testing team.

Why do we do smoke testing?

1. To check whether the product is testable or not.

In the beginning if you find too many defects, it means product is not testable so
better stop testing and spend all time in identifying some more scenarios.

2. Do smoke testing in the beginning itself if you find any blocker defect
send it to the developer in the beginning itself so that developers will have
sufficient time to fix the defect.

3. To check whether we have received broken build by the development

team.

4. We do this to check that the product is installed properly or not.

5. It is like a health check of the product.

Difference between smoke testing & sanity testing

 Smoke testing Sanity testing

● Smoke testing is a shallow and ● It is deep and narrow testing

wide testing (shallow means (here we take one feature and
high level testing, wide means go deep inside and test it.)
cover all basic or critical ●
features)

● Smoke testing is positive ● It is both positive & negative

testing. testing.

● Here we document scenarios ● Here we don’t document

and test cases. scenarios and test cases

● Here we go for automation. ● Here we don’t go for

automation.

● Smoke testing is done by both ● Sanity testing is done by only

developers and T. E T. E

Ad-hoc Testing
Testing the Application Randomly is called Ad-hoc Testing where in we don’t
refer any kind of formal document like test cases or scenarios

Why do we do Adhoc Testing?

 1. Chances are there when the product is launched end users might use the
application randomly and find defects.

2. To avoid that test engineer should only test the application randomly.

3. If you see the requirement and test the software no. of defects which you
are going to catch more no. of defects.

4. We do this to increase the defect count.

5. We do this to have better test coverage.

6. The intention of doing adhoc testing is to somehow break the product.

How to do Adhoc testing?

Login as User, click on compose fill the details for all fields click on send,
logout. Click on the browser back button and check whether the login page
should be displayed or the application should ask to enter UN and PWD.

When do we do Adhoc testing?

1. When the product is functionally stable then we should think about adhoc
testing.

2. When we are doing smoke testing, we should not do negative

testing/adhoc testing. If you do this you will not be able to test basic or
critical features.

3. Whenever the testing team/T.E is free they should spend time doing
Adhoc testing.
 4. Whenever we are doing FT/IT/ST, if we get some adhoc scenarios we
should pause our regular testing & do adhoc testing , if we get too many
scenarios we should document it & execute it when we get time.

(Note: It is not a formal like test case)

 Agile model

Agile is a model where in we develop the software in an incremental and

iterative process.

They came up with this model in order to overcome the drawbacks that were
there in the traditional model.
 Here we build large products in shorter cycles called Sprint.

Scrum process:

Ø It is the process used to build an application in agile model.

Scrum team:

Ø It is the group of Engineers working towards completing committed

features or stories.

a. Generally, scrum team will have 7-12 members.

b. It includes Shared team and Core team members

c. Core team includes Scrum master, Development Engineer and Test

Engineer.

d. Shared team includes Architect, Product Owner, Database admin,

network admin, UI and UX designers, BA.

e. Scrum master leads this entire scrum team and he facilitates everyone to
complete their task.
Product Backlog:

Ø It is a prioritized list of stories or requirements that must be developed in

the complete project.

a. Generally, Product owner, Customer, Business analyst, architect, Scrum

master will be involved in building it.

b. Generally, stories in product backlog need not be in detail.

Sprint Backlog:

Ø It is a list of stories and the associated task committed by the scrum team
that must be delivered within one sprint.

SPRINT PLANNING MEETING:

· Here the entire scrum team sits together and pulls the stories from the
product backlog.
 · Scrum master assigns each story to development engineer and test
engineer.

· Now each engineer derives the tasks to be completed to build the stories.

· Each engineer will estimate the time taken to complete each task i.e. they
derive the story point.

Following are the roles played by different people in Sprint planning

meeting:

1. Scrum master:

a. This complete meeting is driven by the scrum master.

2. Product owner:

a. He clarifies if there are any questions related to stories or

requirements.

3. Development Engineer:

a. He should derive the task for building every story.

b. He prioritizes which story to be built first and which story to build

later in the sprint.

c. He prioritizes the tasks.

d. He derives the story point.

4. Test engineer:

He derives the task to be completed to test each feature or story.

Ex: Create a/c à Identify scenarios

 Write test cases

Review test cases

Execute test cases

Defect tracking

DAILY STAND-UP MEETING/ROLE CALL MEETING/

DAILY SCRUM MEETING

· Here the entire scrum team meets.

· This meeting is completely driven by the scrum master.

· Here every engineer should explain:

*What they have done yesterday

*What were the impediments/hurdles they faced yesterday

*What are the Activities he is planning to do today

*What are the impediments he is expecting in order to complete today’s task.

· The scrum master tries to solve certain impediments right there in the
meeting. If it takes too much time then scrum master notes it down in
‘Impediment backlog’ and solves it later.

· Generally, this meeting should be completed within 10-15 mins.

· This meeting should be conducted at the beginning of the day.

· Here everybody should stand-up in the meeting so that people only talk to
the point.
SPRINT REVIEW MEETING:

· Sprint review meeting should be done at the end of the sprint, where the
engineers will give a demo to the product owner.

· They will also discuss how to plan for the next sprint.

RETROSPECTIVE MEETING

· Here the entire scrum team meets and discusses all achievements (good
process followed) and mistakes (wrong activities performed) and it will be
documented. This document is called a Retrospect document.

· When the next sprint starts while doing sprint planning meeting, we refer
this document & we plan it in such a way that old mistakes should not be
repeated and good activities are once again adopted.

BURNDOWN CHART:

It is a graphical representation of work left vs time.

STORYBOARD/WHITE BOARD:

It is a board which contains a list of pending tasks, tasks in progress and

completed tasks.

HOT FIX/ INCIDENT MANAGEMENT:

In the production if the customer faces any blocker or critical defects it will be
communicated to the company, developers will immediately fix the defect and
TE will retest and patch will be created & it will be installed in the production
server.

This is called as Hot Fix or Incident management.

This may take up to 3 hours or 3 days.

ROOT CAUSE ANALYSIS

· Here the entire team sits together and finds the root cause of the defect
and shares it in a common folder where everyone can access it & present it
to the entire team.

· This technique is called Fish bone technique or Ishikawa method or RCA

meeting (Root Cause Analysis)
 Multiple scrum team

Compatibility testing

Testing the functionality of the application in different hardware and software

environments is called as Compatibility testing.
Why do we do compatibility testing?

1)Chances are their developer might develop the software in one platform and
TE would test the software in same platform and when it is released to the
production end-users might use the application in different platform, software
which works in one platform, but might not work in another platform because of
some defects, due to this end-user’s usage will go down & customer will
undergo a huge loss, to avoid that all this we do compatibility testing

2)To check whether the application is working consistently in all the platforms
we do compatibility testing

3)DE might write common code & claim that application works in all the
platform or else DE might write platform specific code & say that it is works in
all respective platforms

We have to test it in every platform & confirm that it really works or not
When we do compatibility testing

when the product is functionally stable in the base platform only, we think about
testing the application in different platform

How we do compatibility testing?

It depends on the type of application

There are 3 types of application

a) Stand-alone application: It is a kind of application where we take one

setup file and install it in computer or a mobile only one user can
access the software at a time here no internet as well as server is
 required, no database required, this kind of application is called as
stand-alone application

Ex: Calculator, Alarm, MS. Paint

b) Client server application: It is a kind of application where two types

of the software i.e., client software & server software where in we use
client software to interact with server software this kind of application
requires both internet as well as server

Ex: WhatsApp, Instagram, Snapchat

c) Web application: It is a kind of client server application where in

browser behaviours like a client

Ex: WhatsApp, Facebook, Instagram.

How to do compatibility testing?

1)Buy the real device

2)Rent the real device

3)Browser stack
4)Virtualization

Web application: VM-ware

Android application: Emulator

IOS: Simulator

5)Crowd beta testing

Performance testing

Testing the stability and response time of an application by applying a

load on it is called as performance testing.

Response time:
Time taken to send the request time taken to execute the program & the
time taken to receive the response

T=T1+T2+T3

Load:

Designed number of users

Stability:

Ability to withstand the load

Performance testing tool:

a) J-meter

b) Neo load

c) Load runner

d) Rational performance tool

e) Silk performance tool

How will you do performance testing?

 Types of performance testing:

1)Load testing

2)Stress testing

3)volume testing

4)Soak testing

A) Load testing: Testing the Stability & response time of an application by

applying the load which is less than or equal to designed number of users
B) Stress testing: Testing the Stability & response time of an application by
applying the load which is more than designed number of users

C) Volume testing: Testing the Stability & response time of an application by

transferring huge volume of data
D) Soak testing: Testing the Stability & response time of an application by
applying load continuously for a particular period of time

Globalization testing
Developing software for multiple languages is called as Globalization.

Testing software which is developed for multiple languages is called Globalization

testing.
Types of globalization testing:

1) Internationalization testing(I18N)

2) Localization testing(L10N)

How to do I18N testing?

Testing the application which is developed for multiple languages

1) Here we check whether content is displayed in right language or not

2) Right content is displayed in right place or not

3) Features are broken with language changed or not

How to do I18N testing for (Chinese language)?

a) Go to (Chinese language) property file

b) Add prefix and suffix to the content

c) Open the application & select the language Chinese corresponding page comes

d) I will check for prefix, if prefix is correct means content is in right language

e) I will check for suffix, if suffix is correct means content is in right place

Localization testing
testing the application to check whether application is developed according to the
country standard or country culture or not is called localization testing(L10N)

Usability testing
Testing the user friendliness of an application is called as usability testing.
How to do usability testing?

1) I will check the look and feel of the application

2) I will check whether the application is easy to understand or not or the

application should take less time to perform specific action or not

3) Important or frequently used feature must be taken to the user within 3 clicks

4) Important or frequently used feature used features shouted br present either at

the left

For what kind of application we do usability testing?

1)Any application which is used by multiple users or variety of users we do

usability testing

2)Any application which generates lot of revenue

3)Any application where end users won’t be provided any kind of training
When we do usability testing?

1)When the product is functionally stable we can do usability testing

2)Certain project we do usability testing in the beginning of the SDLC itself.

(Prototype model)

Yellow Box testing

Testing the warning message of an application is called as yellow box testing.

Comparison testing
Testing the newly build application with the similar kind of application which
released in the market, here we compare the application, check the advantages and
dis-advantages and check whether all the features are present in our newly build
application or not is called as comparison testing.
 Accessibility testing
Testing the user friendliness of an application from physically challenged people
point of view.

Reli
ability testing
Testing the functionality of an application continuously for a particular period of
time is called as reliability testing.

Recovery testing
Testing the functionality of an application to check well the application recovers
the data from the crash or disasters.

Exploratory Testing
Understand the application, identify the scenarios, document the scenarios and test
the application by referring the document is called as Exploratory testing.

Or

Explore the application, understand how each and every feature works and test the
application based on your understanding is called as Exploratory testing.

When we go for exploratory testing?

When the requirement is missing we go for exploratory testing.

-In long term projects, when it’s a very big/huge/complex application, the
requirement for some modules might be missing.

-In product-based companies, since we don’t have customer, we won’t have proper
requirement document.

-In start-ups, if the company is very new, they might not maintain requirement
document properly.

-Sometimes even if the requirement (SRS) is present, we don’t have sufficient time
to read and understand the requirement.

How to do Exploratory testing?

1. Understand the application

a) Understand how each and every component works.

b) Understand how each and every module/feature works.

2. Identify the scenarios

3. Document the scenarios

4. Execute the scenarios referring the document.

5. When you find defects communicate of the developers.

Drawbacks of Exploratory testing:

1) Time Consuming

2) We might miss testing some features in turn we might miss the defects.

3) We might misunderstand defect as feature.

4) We might misunderstand feature as defect.

How to overcome the drawbacks of exploratory testing?

1. Interact with Sr. Dev, Sr. T.E, B.A or Customer.

2. Based on Product knowledge

3. Based on domain knowledge

4. By comparing the similar application.

5. Based on common sense.

Regression testing
Testing the unchanged features to make sure that is not affected or broken because
of changes is called as Regression testing (here changes can be addition,
modification, removal of features or fixing the defect)

OR

Re-execution of same test case is different test cycle(or)sprint(or)Release to make

sure that changes are not introducing any defects in unchanged features (Changes
can be addition, modification or removal of features is called Regression testing)

Type of Regression testing:

1)Unit regression testing

2)Regional regression testing

3)Full regression testing

a) Unit regression testing:

Testing the changes (or) only the bugs which is fixed is called as Unit regression
testing.
 b) Regional regression testing:
Testing the changes & only the impacted regions is called Regional regression
testing

How will you identify impacted Region?

1)Based on product knowledge

(As a TE in-depth I will be knowing how each & every module works & also I
will be knowing how all the modules are related based on that knowledge, I
will be able to identify impacted areas)
2)By preparing Impact matrix

(Here we list the changes & also all the features in the application, then mark
the impacted areas)

3)By conducting Impact analysis meeting

(As soon as the new build comes entire testing team meets & discuss about list
of bugs fixed & the impacted areas)

4)By interacting with customer, business analyst, development team, testing

team we should gather the impacted areas & create an impact list based on that
we should do Regression testing
Advantages of Regional Regression Testing:
1)By not testing certain features we are saving testing time which intern

reduces the testing cost

2)Test cycle duration Reduces because of that turnaround time taken to

deliver the product to the customer reduces

Dis-advantages of Regional Regression Testing:

1)Chances are there we might miss identifying the impacted area because of that
we might miss the bugs.

c) Full Regression testing:

Testing the changes and all the remaining features is called as Full Regression
testing

Why/when we do full regression testing?

1)Whenever too many changes are done in the product better to do full

regression testing

2)If the changes are done in core features

3)every few (4-5) cycle once we should do full regression testing & last few cycles
we should do full regression testing because we are about to launch the product to
the production to not to take any risk
Interview Question
Difference between Regression Testing and Re-testing

Regression Testing Retesting

· Fixing the bugs or doing · Whenever developer gives
changes might have impact on build, checking or verifying
other features so testing the whether defect is fixed or not is
unchanged feature to make sure called Retesting.
that it is not broken because of
changes is called as Regression
Testing

· Regression Testing is done for

Passed test cases
· Retesting is done for failed
· Here we can go for Test cases
Automation

· Here we cannot go for

 Automation

Progression testing:

Testing newly added features is called as progression testing.

Q. When we do regression testing?

1) 1st release 2nd build only we do regression testing

2) 2nd release 1st build only we do regression testing

What are the drawbacks of manual repeated regression testing?

1) Manual testing is reparative in nature over the period of time it becomes

monotonous because of that testing engineer may not be effective in testing

2) As the size of the application increases test cycle duration also increases
because of that turn around time taken to delivery the product to the customer
increases

3) Man power is expensive

To overcome this drawback, we go for automation

What is the role of Manual test engineer?

1. Write manual Test cases

2. Test new feature manually.

3. Test modified feature, fixed bugs manually

4. Find the defects & communicate to the developers.

What is the role of Automation Test engineer?

1. Understand the application

2. Understand the test cases.

3. Convert the manual test cases into automation test scripts(manual test cases
of the stable features)

4. Execute the automation scripts when the new build comes.

5. Maintain the automation scripts:

a) Whenever the requirement changes, test cases also should be changed.

b) When the test cases changes, we should change the automation scripts

c) If there are problems in old script, they have to fix it.

Why we go for Test Automation?

We go for test automation:

1. To reduce manual repeated testing efforts.

2. To reduce test cycle duration.

3. To reduce the turn around time taken to deliver the product to the customer.

4. To reduce the no. of engineers

5. To reduce the cost of testing.

6. To improve the test efficiency.

7. To have the consistency in quality of test execution.

 Test Plan
It is a document which drives all the future testing activities. Generally, it is
prepared by test lead or test manager. It has got several sections like:

1. Objective

2. Effort estimation

3. Scope

4. Approach

5. Assumption

6. Risk

7. Mitigation plan/Backup plan

 8. Test Methodology

9. Test schedule

10. Test environment

11. Defect tracking

12. Test automation

13. Deliverables

14. Entry & exit criteria

15. Test stop criteria

16. Roles & responsibilities

17. Templates

1) Objective:

This section covers aim of preparing the test plan

2) Effort estimation:

This section covers estimation of how long it will take to complete the project &
also we estimate how many engineers are needed & the cost needed to complete the
task and the cost of testing.

1) Scope:

This section covers what are the features to be tested and what are the features not
to be tested.

2) Approach:
This section covers how we are going to test the product in future.

3) Assumption:

This section covers assumptions that we have made while planning.

4) Risk:

This section covers if any assumptions fails that becomes risk.

5) Mitigation plan/Backup Plan:

This section covers how to overcome (or) how to face the risk.

6) Test methodology:

This section covers what are the types of testing that we are planning to conduct.

7) Test Schedule:

This section covers when exactly we should start and end and activity.

8) Test Environment:

This section covers how we go about setting up the test environment in future (or)
how we setup the environment in future.

Ex: 12.1 Procedure to install the build

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

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

------------
 12.2 Hardware

12.2.1 Server side

HP startcat 1500

12.2.2 Client side

6 computers with following configurations

1 gz speed Intel processor

1 GB RAM

12.3 Software

12.3.1 Server side

OS: Linux, Version:

Web server: Tomcat, Version:

App server: Web sphere

DB server: Oracle, version:

12.3.2 Client side

OS: Win 10, win 8

Browser: Mozilla Firefox

Chrome

9) Defect Tracking:

This section covers in future when we find defects how it should be tracked and
also covers the procedure, status, severity and priority.
It also covers what should be the

a) Procedure

b) Status

c) Severity

d) Priority

10) Test Automation:

This section covers what are the features to be automated & what are the features
not to be automated & the complete automation strategy.

Ex: 6.1 Features to be Automated

---------

---------

6.2 Features not be automated

-------

------

6.3 Automation framework to be used

---------

---------

6.4 Automation tool to be used

Selenium

-----------
 11) Deliverables:

This section covers which all documents that has to be provided by the testing team
at the end of test cycle.

Ex: Test cases, Traceability matrix, test execution report, defect report, release
note, graphs & matrices.

Release Note: Along with the product, we release a note to the customer called as
release note.

Release note consists of:

· List of open defects which are there in the product.

· List of bugs that are found in the previous release and fixed in the
current release.

· List of pending bugs in previous release & fixed in current release

· List of features added, modified or removed in current release.

· Procedure to install the software.

· Version of the product.

Graphs & matrices:

Graphs:

Defect density (or) Defect distribution graph

Build-wise defect distribution graph
Matrices:

Defect distribution matrices:

Test Engineer efficiency Matrices:

 1) Entry & Exit Criteria:

Entry criteria:

This section covers list of criteria that should be met to start the activity.

Exit criteria:

This section covers list of criteria that should be met to say that activity
is over.

Ex: System study:

Entry criteria for system study:

· Should have got approved requirement from customer

· Should have assigned engineers to do system study

Exit criteria for system study:

· Should have completed reading the requirement.

· Should have got answers for all the queries.

Prepare Test Plan:

 Entry criteria for test plan:

· Test plan template should be ready.

· Should have assigned someone to prepare test plan & review

the test plan.

· Should have met the exit criteria of system study.

Exit criteria for test plan:

· Should have got approval for test plan.

Write Test case:

Entry criteria for writing test case:

· Test case template should be ready.

· Should have met exit criteria of test plan.

· Should have assigned the module to engineer.

Exit criteria for writing test case:

· Test case should be reviewed, approved & stored in repository.

2) Test stop criteria:

This section covers when exactly we should stop testing.

When will you stop testing?

è We stop testing when the product quality is very good or product

quality is very bad.

ü Product quality is very good means if all the end-to-end

business scenarios are working fine.

ü If there are no blocker or critical defects.

 ü There are few bugs left out which are all minor or major but
are less than the acceptable limit set by the customer.

ü If all the features requested by the customer are ready

û Product quality is bad means there are too many blocker &
critical bugs.

û If it is crossing the budget.

û If it is crossing the schedule/deadline.

3) Roles & responsibility:

This section covers what each engineer should do in different stages of test life
cycle.

Roles and responsibilities of Test manager:

· Write and review Test plan.

· Interact with testing team, development team, if needed with

customer.

· Should handle all the issues and escalations.

· He should approve release note.

Roles and responsibilities of Test lead:

· Write and review Test Plan.

· Allocate work to each engineer and make sure that they are
going to work and complete the task within the schedule.

· Consolidate all the reports which are sent by every TE and

communicate with testing team, development team, project
manager and customer.

· He conducts impact analysis meeting.

 Roles and responsibilities of Test Engineer:

· Write Test case

· Review test case of another test engineer.

· Execute test case for his allocated features.

4) Templates:

This section covers formats for all the documents that we are planning to
prepare in the entire test life cycle.

i. Test case template

ii. Traceability matrix template

iii. Defect report template

iv. Test case review template

v. Test execution report template

STLC
1. System study:
Read the requirement, understand the requirement if you have any queries,
interact with BA, developers or customer.

2. Prepare Test plan:

Once after reading and understanding the requirement, we go for preparing
the test plan.

Test plan is a document which drives all the future testing activities.

-Here we decide how many engineers we require to complete the testing.

-What is the total time for completing the testing/project.

-What each engineer should do in different stages of testing.

-What are types of testing we will conduct in future.

-What are the features that are to be tested and not to be tested.

-What is the testing approach

-When each activity should start & end.

3. Write test cases:

Test case is a document which contains all possible scenarios.

This activity has got several stages like:

System study, identify all possible scenarios, write test case, review test case,
fix the review comments, verify the fix, test case approval, store in
repository.

4. Prepare traceability matrix:

Once after we write test case, the biggest question is what is the proof that
each and every requirement has got a test case?

We prepare traceability matrix to ensure that each and every requirement has
got at least one test case.

5. Test Execution:
This is the stage where we execute all the test cases.

This is where we conduct all types of testing and find the bug.

This is the stage where Test engineers become productive to the

organization.

This is the stage where the T.E spends a lot of time.

6. Defect tracking:
Once after test execution, obviously we are going to find the defects.

Each defect that we find should be tracked in an organized way. This is

called as Defect tracking.
 7. Test execution report:
At the end of every test cycle we prepare test execution report.

It is a document which we prepare and provide to the customer at the end of

every test cycle.

This report covers:

*Total no. of test cases

*Total no. of test cases executed.

*Total no. of test cases not executed.

*No of test cases passed.

*No of test cases failed

*What is the pass percentage

*What is the fail percentage.

We will prepare this document and send it to the customer. From customer’s
POV this is the stage. But from company’s POV we have one more activity
called as Retrospective meeting.

8. Retrospective meeting/Project closure meeting/Post-mortem

meeting:
Here the entire team will sit together and discuss about the achievements and
mistakes, they document all this, that document is called as Retrospect
document.

In the next release/sprint they open this document in the planning stage and
plan in such a way that all the achievements are adopted and all the mistakes
are avoided.

What is defect?
Any feature which is not working according to the requirement specification is
called as Defect.
OR
Deviation from requirement specification is called as Defect.

Why do we get Defect?

1. Wrong Implementation

2. Missing Implementation
 3. Extra Implementation

What is the difference between Error, Defect, Bug and Failure?

Error: Error is a mistake done in the program because of which we will not be able
to compile the code or Run the code.
There are 2 types of error: i) Compile time error ii) Run time error
Defect: Any feature which is not working according to the requirement is called as
Defect.
OR
Error found in the application or s/w is called as defect.
Bug: It is an informal name given to defect.
Failure: Many defects in the s/w leads to failure. It is the term which is used by
customer or end user.

DEFECT TRACKING PROCESS:

TEST ENGINEER:
1. Test engineer finds the defects
2. Prepare defects report
3. He will put the status as new/open
4. Send the report to development lead
DEVELOPMENT ENGINEER:
1. DL reads the report & understand the problem
2. Identifies the developer who did the mistake
3. Change the status to assign
4. Sends it development engineer
DEVELOPMENT ENGINEER:
1. DE reads the report & understand the problem
2. Goes the source code & fix the bug
3. Change the status to fixed
4. Send the report to test engineer & CC to development lead
TEST ENGINEER:
1. TE reads the report & understand the problem fixed
2. Retest the fix bug, if the bug is fixed change the status to closed
3. Otherwise change the status to reopen
4. Send the report to development engineer & also CC to development lead
Why test engineer should not wait for the permission of test lead for sending
report to development?

● There will be delay in communication report to developer

● As a test engineer will be having knowledge in depth about his feature, so

better take a decision and send report directly to development lead without
the permission of test lead
Why we should keep CC for every report to test lead?

● Test Lead is the one who attends managements developers and customer
meeting, so he should be aware of all the issue that are present in the product
● To get visibility that test engineer is working

As soon as you find defect immediately you have communicated defect to

developer why?

● Developers will get sufficient time to find the defect

● Someone else might send your defect

● Chances are there TE might forget the defect

Severity:
It is the impact of the defect on customer business
1. Blocker defect
2. Critical defect
3. Major defect
4. Minor defect
Blocker:
Assume that there is a defect in the software, I am 100% sure that this defect is
going to affect customer business work flow and also blocking test engineer to
test the feature, this kind of defect is called as blocker defect.

Critical defect:
Assume that there is defect in the application, I am 100% sure that this defect
will affect customer’s business work flow, but not blocking Test Engineer to
test the feature still we can continue testing. This type of defects is called as
Critical defect.
Major Defect:
Assume that there is a defect in the application, I am not sure that how this
defect is going to affect customer business work flow, this type of defects is
called Major Defect.

Minor Defect:
Assume that there is defect in the application, I am 100% sure that this defect
will never affect customer business work flow, this type of Defect is called
Minor defect.
Example: Spelling mistake, colour mistake, overlapping issue, alignment issue
etc.
 PRIORITY:
Importance given to fix the defect is called as priority
OR
How soon the defect must be fixed by the developer.
There are 3 levels of Priority. They are:
1) High or P1
2) Medium or P2
3) Low or P3
High or P1:
In the defect is having priority P1, then the developer should fix the defect
immediately.
Medium or P2:
If the defect is having priority P2, then he can fix the defect, within some test cycle
or builds or within a release
Low or P3:
If the defect is having priority P3 then developer can fix the defect in upcoming
release or within some 2-3 release.
There are 4 combinations:
1. High severity High priority
2. Low severity low priority
3. High severity Low priority
Ex:

4. Low severity High Priority

DEFECT LIFE CYCLE:
Defect life cycle consists of Below mentioned status:
1. New/open
2. Assigned
3. Fixed
4. Closed
5. Reopen
6. Reject
7. Defect cannot be fixed
8. Postponed
9. Duplicate
[Link] not reproduceable
 [Link] for enhancement (RFE)

What is Reject status?

TE will find a defect and send it to developer, now developer says that it is not a
defect, it is a feature, in this case developers will change the status as Reject.
Why we get Reject status?
i) Because of Misunderstanding the requirement.

ii) Because of referring old requirement

iii) Whenever build or software is wrongly installed or wrongly configured.
If the test engineer installed build wrongly and find defect in software and
communicate it to the developers, now developer will tell it is not a defect
because code is perfect, but TE has not properly installed the software.
What is Duplicate status?
Test Engineer will find defect and communicate to developers, if already same
defect is tracked by another TE then developer says that this new defect is duplicate
of old defect.
Why we get Duplicate status?
i) Because of testing common feature.

ii) Assume that old TE has found lot of defects and communicated to
developer, in that some defects are fixed and some are pending. If new
TE joins same project and communicate old defects then developers say
this new defect are duplicate of Old defects.
What is Defect cannot be fixed status?
Here the developers are accepting that it is a defect but they are not in a position to
fix the defect, in this case developer says defect cannot be fixed.
Why we get Defect cannot be fixed?
i) If TE finds a defect in the root of the product and if it is a minor defect
and if it is not affecting customer business work flow, then developer says
Defect cannot be fixed.
(Suppose if its blocker or critical defect then developer should fix the
defect.)

ii) If the cost of fixing the defect is more than cost of defect then developer
says Defect cannot be fixed.
Here the cost of defect means loss in the business because of having
defect in the software.
iii) When the technology itself doesn’t support.
What is Postpone status?
Here developers are accepting that it is defect but they want to fix it a little later. In
this case developers gives status as Postpone.
Why we get Postpone status?
i) If TE finds minor defect at the end of the release and if developer is not
having sufficient time to fix the defect in this case developer will give
Postpone status.

ii) TE finds a defect in a feature which is not required to customer in Current

release, then developer will give Postpone status.

iii) If TE finds a defect in a feature where customer wants to do lot of

changes in the requirement (same feature) and even customer might
remove feature as well. In this case developer will give Postpone status.
 iv) TE finds a defect in the feature which is exposed to internal users and if it
is a major or minor defect then developer will give the postpone status.

What is issue not reproduceable status?

TE is able to see the defect but developer is not able to see the same defect. In this
case developer says that issue not reproducible.
Why we get issue not reproduceable status?
i) Because of improper defect report
a. Because of using incorrect platform/Platform Mismatch: TE might be
using one OS or Browser but developers might be using some other
OS or Browser because of that they might not get the defect.
b. Because of Incorrect data: TE might be using some data to get the bug
 but developers might be using some other data to get the same bug.

ii) Because of Inconsistent defect

What is Inconsistent defect?

Sometimes the defect appears, sometimes the defect disappears.
Or
Sometimes feature is working, sometimes same feature is not working.

What is Request for Enhancement (RFE)?

While testing the software if the TE finds any defect and if that defect is not a part
of requirement, then it is called as RFE or Change request.
 Defect Report

What is defect tracking tool? Name some defect tracking tools.

Defect tracking tool is a software which is mainly used to track or store
the defects in centralized place and communicate defect to developer in
an organized way.
Defects tracking tools are:
1. Bugzilla
2. QC/ALM
3. JIRA
4. Mantis
5. CrocPlus
6. Rational clear Quest
7. Bugnet
 Release in Traditional Model

Introduction to Agile Model

Agile model
 Agile is a model where in we develop the software in an incremental and
iterative process.

They come up with this model in order to overcome the drawbacks that were
there in traditional model.

Here we build large products in shorter cycles called Sprint.

Scrum process:

⮚ It is the process used to build an application in agile model.

Scrum team:

⮚ It is the group of Engineers working towards completing committed features

or stories.
a. Generally, scrum team will have 7-12 members.
b. It includes Shared team and Core team members
c. Core team includes Scrum master, Development Engineer and Test
Engineer.
d. Shared team includes Architect, Product Owner, Database admin, network
admin, UI and UX designers, BA.
e. Scrum master leads this entire scrum team and he facilitate everyone to
complete their task.
Product Backlog:

⮚ It is prioritized list of stories or requirements that must developed in

complete project.
a. Generally, Product owner, Customer, Business analyst, architect, Scrum
master will be involved in building it.
b. Generally, stories in product backlog need not to be in detail.
Sprint Backlog:

⮚ It is a list of stories and the associated task committed by scrum team that

must be delivered within one sprint.

SPRINT PLANNING MEETING:

● Here entire scrum team sit together and pull the stories from the product

backlog.

● Scrum master assigns each story to development engineer and test engineer.

● Now each engineer derives the tasks to be completed to build the stories.

● Each engineer will estimate the time taken to complete each task i.e. they

derive story point.

Following are the roles played by different people in Sprint planning

meeting:

1. Scrum master:
a. This complete meeting is driven by the scrum master.
2. Product owner:
a. He clarifies if there are any questions related to stories or requirements.
3. Development Engineer:
a. He should derive the task for building every story.
b. He prioritizes which story to be built first and which story to build later in
the sprint.
c. He prioritizes the tasks.
d. He derives the story point.
 4. Test engineer:
He derives the task to be completed to test each feature or story.
Ex: Create a/c 🡪 Identify scenarios
Write test cases
Review test cases
Execute test cases
Defect tracking

DAILY STAND-UP MEETING/ROLE CALL MEETING/

DAILY SCRUM MEETING

● Here the entire scrum team meets.

● This meeting is completely driven by the scrum master.

● Here every engineer should explain:

*What they have done yesterday

*What were the impediments/hurdles they faced yesterday
*What are the Activities he is planning to do today
*What are the impediments he is expecting in order to complete today’s task.

● The scrum master tries to solve certain impediments right there in the

meeting. If it takes too much of time then scrum master notes it down in
‘Impediment backlog’ and solves it later.

● Generally, this meeting should be completed within 10-15 mins.

● This meeting should be conducted in the beginning of the day.

● Here everybody should stand-up in the meeting so that people only talk to
 the point.

SPRINT REVIEW MEETING:

● Sprint review meeting should be done at the end of the sprint, where the

engineers will give demo to the product owner.

● They will also discuss how to plan for the next sprint.

RETROSPECTIVE MEETING

● Here the entire scrum team meets and discuss about all achievements (good

process followed) and mistakes (wrong activities performed) and it will be

documented. This document is called as Retrospect document.

● When next sprint starts while doing sprint planning meeting, we refer this

document & we plan it in such a way that old mistakes should not be
repeated and good activities are once again adopted.

BURNDOWN CHART:

It is a graphical representation of work left vs time.

STORY BOARD/WHITE BOARD:

It is a board which contains list of pending tasks, tasks in progress and completed
tasks.

HOT FIX/ INCIDENT MANAGEMENT:

In the production if the customer faces any blocker or critical defects it will be
communicated to the company, developers will immediately fix the defect and TE
will retest and patch will be created & it will be installed in the production server.

This is called as Hot Fix or Incident management.

This may take up to 3 hours or 3 days.

ROOT CAUSE ANALYSIS

● Here entire team sits together and find the root cause of the defect and share

it in a common folder where everyone can access it & present it to entire

team.

● This technique is called Fish bone technique or Ishikawa method or RCA

meeting (Root Cause Analysis)

Multiple scrum team

 Test case
Test case is a document that covers all possible scenarios for a specific
requirement.
It contains different sections like step no., input, action or description, expected
result, actual result, status, and comments.

What will happen if you look into requirements and test the software?
Or
 What are the drawbacks of not writing test cases?

● There will be no consistency in testing if you look into requirements and test
the software.
● The test engineer will miss lot of scenarios and defects.

● Quality of testing varies from person to person if you look into requirements
and test the s/w.
● Testing depends on the memory power of the test engineer.

● Chances are there we might end up in testing the same things again and again
if you look into requirement.
● Test coverage will not be good.

● Testing depends on the mood of the T.E.

When do we write test case?

1. When developers are busy in building the product, the testing team will be
busy writing the test cases.
2. When the customer is adding the requirement developers will add the
features parallelly test engineers will add new test cases.
3. When the customer is modifying or changing the requirement developers
will modify or change the feature, parallelly T.E. will modify or change the
test cases.
4. When the customer is removing the requirement, developers will remove the
feature, and parallelly test engineer will remove the test cases to make sure
that features are removed from the s/w or not.
Why do we write Test cases?

⮚ We write test cases to have better test coverage.

When the requirement comes in developers are busy building the product
same time test engineers are free, so they identify all possible scenarios and
document it. When the build comes we can spend time executing the
scenarios, because of this no. of scenarios that you are covering will be more.
⮚ To have consistency in test execution.
It means if you have documented the scenarios, you can make sure that you
are executing all the scenarios in all the test cycles, sprints, or releases.
⮚ To depend on the process rather than on a person.

⮚ To avoid training every new engineer on the product or on the requirement.

⮚ Test case is the only document that acts like as proof for customer,
development team, and also manager that we have covered all possible
scenarios.
⮚ Test case acts like a base document for writing automation scripts, if you
refer to the test case and write automation scripts you can ensure the same
kind of coverage even in automation.
⮚ If you documented the test case, no need to remember the scenarios.

⮚ If you have documented the test cases, test execution happens in a very
organized way.
⮚ If you have documented the test cases, the time taken to execute is much
less.
 Test case template
-Every T.E. should write test case in test case template only.
-Test case template can be prepared either in test management tool or MS Excel.
-There is nothing called standard test case template, test case template varies from
company to company, project to project.
Header:
1. Test case name:
2. Requirement no:
3. Test data:
4. Pre-condition:
5. Severity:
6. Test case type:
7. Brief description:
Body:
Step Action/Description Input Expected Actual Status Comments
no: result result

Footer:
1. Author:
2. Reviewer:
3. Approved by:
4. Approval date:

Test case design techniques

It is a technique which is used while writing test case in order to improve test
 case in order to improve test coverage.
Types of Test case design techniques:
1. Error guessing
2. Equivalence class partition
3. Boundary value analysis (BVA)

1. Error Guessing:
Here we guess all possible errors and we derive the scenarios.
We guess errors based on the following:
i. Requirement
ii. Experience
iii. Intuition
Ex: Amount
100
5001
99

4999
100.50
100%

$100
0
100 Rs only

2. Equivalence class partition:

Pressman Rules:
Rule 1: If the input is a range of values, then design test case for one valid and two
invalid inputs.
Ex: Amount 100-5000

Valid-500
Invalid- 90
6000
Ex: Insurance
Age 5-55

Valid- 30
Invalid- 4, 60
Rule 2: If the input is in a set of values, then design test case for one valid and two
invalid inputs.
Ex:

Printer- 10
Scanner- 20 Set of values
Webcam- 30
Valid- 30
Invalid- 25
40
Ex:

Rule 3: If the input is in Boolean, then design the test case for both true and false
values.
Ex: Whenever we are testing for checkbox or radio buttons you should test the
application for both true and false values.

Practice Method:
If the input is in range of values then divide the range into equivalent parts, try for
all the values and also test for at least two invalid values.
Ex: Amount 100-5000

1000
2000
3000
4000
5000

Note:

1. If there is a deviation between the range of values then we go got the practice
 method.
2. If there is no deviation between the range of values then we go for Pressman
rules.
3. By looking into requirements, we will get to know whether there is a
deviation or not.

Boundary Value Analysis:

If the input is in the range of value b/w A to B then design test case for A, A+1, A-
1 and B, B+1, B-1.
Amount 100-5000

100 5000
101 5001
99 999

Test case optimization:

The process of removing the duplicates from the test cases is called as Test case
optimization.
Difference between test case & test scenarios:
Test scenarios Test cases
⮚ It is a high-level document of ⮚ It is a detailed document of the
all the customer business scenario that helps us to test the
workflow according to the application.
customer's Requirement.

⮚ We write Test scenarios by ⮚ We write test cases by looking

looking into the requirements. into both requirement and test
scenarios.

⮚ By looking into test scenarios, ⮚ We can test any application by

we can’t test any application looking at the test case, no
until you have good product matter if you have product
knowledge. knowledge or not.

⮚ Here we mention what to test. ⮚ Here we mention how to test.

Test case review Process:

On what basis do they assign test case for review?
They will assign to the person:
1. Who is working on a similar or related module in the project.
2. Who has worked on same module in the previous project.
3. Who has been working in the project since the beginning knows every corner
of the product.
4. Who is responsible, and who will understand the requirement very fast and
identify more mistakes.
How do you ensure that reviewer does his job?
1. Assign primary and secondary reviewer.
2. Test lead should also randomly review and find the mistakes.
3. Test lead will intentionally introduce some mistakes and check whether it is
found by the reviewer.
Review ethics:
1. Always review the content, and not the author.
2. Reviewer should spend more time in finding the mistakes rather than giving
the solution.
3. Even after review if there are still any mistakes, both author and reviewer are
 responsible.

Test case review template:

● Every TE should write the review comments in the test case review template
only.
● Test case review template will be prepared either in the Test management
tool or MS Word/MS Excel.
● Test case review template is not standard, it may vary from Company to
company and project to project.
 Traceability Matrix:
It is a document that we prepare to make sure that every requirement has got at
least one test case.

Advantages:
1. It ensures that every requirement has got at least one test cases, which
indirectly assures that you have tested every feature at least once.
2. It gives us Traceability from High level requirement till automation script.
Drawback:
It will not ensure that you have got 100% coverage.
Types of traceability Matrix:
There are 3 types of traceability Matrix. They are:
1. Forward Traceability Matrix:
Mapping from the root document to derived document is called forward
traceability matrix.
Ex: Mapping from Req to test case and test case to test script
2. Backward Traceability Matrix:
Mapping from derived document to root document is called as Backward
Traceability Matrix.
 Ex: Mapping from test scripts to test cases and test cases to requirement.

3. Bi-Directional traceability Matrix:

Doing both forward and backward traceability matrix is called as Bi-
directional traceability Matrix.

Difference between Traceability Matrix and Test case review:

Traceability Matrix Test case review
● Here we check every req has ● Here we check test case is
got at least one test case. covering all possible scenarios
for specific requirement.

● Here we don’t check whether ● Here we don’t check whether

test case is covering all every requirement has got at
possible scenarios for a specific least one test case.
requirement.

Lessons to remember while writing test cases:

#1: Before we actually write test cases, we should come up with options and select
the best option out of it.
#2: Start writing the test case with navigational steps.
#3: Never write hardcore test cases, always write generic test cases.
#4: Whatever we have covered in FT, don’t cover the same in Integration test
cases.
If something is covered in integration test cases then don’t cover it in the system
test cases.
#5: Elaborate only those steps in which you have to focus. Don’t elaborate all steps
unnecessarily.
#6: Whenever we are writing test cases we should imagine/visualize the
application.
#7: Always use should be/must be in expected results.
Don’t use could be/would be/will be/can be/might be.
#8: If you organize the steps properly, the total no. of steps can be reduced.
Approach to write Functionality Test cases:
1. Go to the body of the test case.
2. Start with navigational steps.
3. Take the first field.
● Start with valid inputs.

● Write the error-guessing scenarios

● Write equivalence class partition scenarios.

● Write the BVA scenarios.

4. Take the second field.
● Start with valid inputs.

● Write the error-guessing scenarios

● Write equivalence class partition scenarios.

● Write the BVA scenarios.

Approach to write Integration test cases:

1. Take one feature, and identify all possible scenarios.
2. Prioritize the identified scenarios & document it.
3. Go to the body of the test case.
4. Start with navigational steps.
5. Cover the scenarios.
How to fill the header?
1. Test case name:
Format: Projectname_ModuleName_scenario
Ex: CB_AmountTransfer_integration
CB_AmountTransfer_AmountTextFeild

2. Requirement Number:
BA when he converts CRS to SRS, in SRS for each requirement he will
write the requirement no.
Ex: 30.1 Amount Transfer
30.1.1 FAN text field
30.1.2 TAN text field
30.1.3 Amount text field

3. Test data:
It is the data written by a TE and has to be done before the test execution.
Ex: TE should have UN, PWD, URL, a/c number

4. Pre-condition:
 It is a set of actions or settings which should be ready/done by TE before
executing the 1st test case.
Ex: User should have balance in his account.

5. Test case type:

Here the TE mention what type of test case he is writing.
Ex: Functionality test case, Integration test case, system test case.

6. Severity:
TE will give severity for every individual test case, based on how important
and complex the feature is from customer’s POV.
TE will execute test case based on severity.
There are 3 types of severity for Test cases: Critical, major, minor

7. Brief Description:
It describes about the complete test case and the behavior of the test case.
Ex: In the amount transfer module, it should accept only +ve integers.

How to fill the footer?

1. Author: Anyone who writes the test case will be the author.
Ex: Dinga
2. Reviewer: The person who reviews the test cases.
Ex: Dingi
3. Approved by: A person who approved the test cases.
Ex: Test lead
4. Approval date:
Ex: 01-01-2023
 Procedure to write Test cases:

System study:
Read the requirement, understand the requirement, and if you have any queries
interact with the customer, B.A.
Identify all possible scenarios:
i) Identify
ii) Brainstorming sessions:
Write the test cases:

● Group all related scenarios.

● Prioritize the scenarios within each group.

● Apply test case design technique.

● Use the test case format given to you.

● Document it.

Store in test case repository:

It is a centralized place where in we store all the test cases in an organized way.