It is a step-by-step procedure OR standard procedure to develop a new

software or new project.

Ques. When a software company should follow or implement SDLC ?

Ans. Whenever a software company gets a new project, they should follow or
implement SDLC.

Procedure or Diagram for SDLC

1. Requirement collection
2. Feasibility study
3. Design
4. Coding
5. Testing
6. Installation
7. Maintenance

• Customer will approach a software company for the sake of software in

order to run his business.
• Domain expert will visit at customer place as a business analyst (BA) in
order to collect the requirement from customer.
• Business Analyst (BA) will collect the requirement from customer in
business language (CRS) and he will convert the requirement into software
language (SRS).
• After converting the requirement, he will explain this to everyone in the
software company who will be involved in the project.
• In this way business analyst act as a bridge between customer and the
software company.
Ques. Who can become Business Analyst ?
1. Domain expert: Any person who has worked on the same domain for at
least 5 years and having a good knowledge of that domain after given
software training can become a BA.
2. Senior developer/ senior test engineer: Any senior developer or test
engineer who has worked on the same domain project for at least 5 years
and having a good knowledge of that domain can become a BA.
3. Any fresher after given training on domain as well as software can become
BA.

Feasibility study:
▪ The general meaning of the word “feasible” is “Possibility”. In this stage
software company decides whether to accept the project or not.
▪ In feasibility study Project manager, Architect, BA, Finance team and HR
are involved.
▪ In this stage software company decides that technically it is possible to
develop the project or not, resources are available or not and financially the
project is profitable or not.
 ▪ If all the above situations are favorable to the software company then the
software company accept the project and sign an agreement (MOU) with
the customer.

Design:
▪ Once after the feasibility study is done, software company go for design.
▪ Design is done by Architect.
▪ There are two types of design:
1. High Level Design (HLD)
2. Low Level Design (LLD)

Example.
 • The process of designing the main modules of an application is called
“High Level Design”.
• It is also known as “external design of the application”.

• The process of designing each and every individual module of HLD in

detailed manner is called as “Low Level Design”.
• It is also known as “internal design of the application”.

• If we are having 1 web server, 1 application server and 1 database server

in an application, then the design is known as 3-tier architect.
• If we have 1 web server, more than one application server and more
than one database server in an application, then the design is known as n-
tier architect.
Ques. What is module?
Module is a part of an application which contains some specific functionality or
performs specific task of that application.
 Coding:
• Once after design is done, software company go for coding.
• Coding is done by developers.

Hierarchy of Software company

▪ In coding Critical features are developed by senior developers, Major features

are developed by junior developers and Minor features are developed by
fresher developers.

Testing:
• Once after coding is done, software company go for testing.
• Testing is done by test engineers.
• Critical features are tested by senior test engineers, Major features are tested
by junior test engineers and Minor features are tested by fresher test engineers.
Installation:
• Once after testing is done, software company go for installation.
• Installation is done by “Installation engineer or Site engineer or DevOps
engineer”.
• Installation engineer visit at customer place and setup the environment in
order to install the software.
• After installing the software, installation engineer gives a demo of the software
to the customer and if customer has any doubt regarding the software,
installation engineer clarify the doubt of the customer.
 Maintenance:
• Once after software is installed, customer will start using the software in order
to run his business.
• While using the software, customer may find some defects in the software
which will be fixed by the software company free of cost for a certain period
of time. That certain period of time is called “Maintenance period”.
• After maintenance period, if customer finds any defect, that will be fixed by
the software company, but they will charge for fixing the defect.

Ques. Who will be involved in maintenance?

The same developer and test engineers who worked on the project will be
involved in maintenance, but the number will be less as customer might ask for
small changes in the application.

1. Waterfall model
2. Spiral model
3. V-shape model
4. Prototype model
5. Hybrid model
6. Customized/Derived model
7. Agile mode-most important
Waterfall Model or Basic or Traditional or Sequential Model
• It is a step-by-step procedure of standard procedure to develop a new software
of a new project.

Ques. Why this model is called as “Waterfall” model?

➢ Once after feasibility study is done, we are going to freeze the requirement, that
means we can’t go back and change the requirements i.e., Backtracking is not
possible, that’s why this model is called “Waterfall model”.
• Because we can go only in forward direction in step-by-step procedure like
waterfall. We can’t go reverse.
• It is because requirement changes aren’t allowed during SDLC procedure due
to lack of resources.
Ques. What happens if we don’t follow SDLC to develop the software?
We will not be able to collect proper requirements from the customer.
We will not be able to calculate the time, resources and cost required to
complete the project.
We will not be able to deliver the software to customer in proper time.
Ques. Why we freeze the requirement in Waterfall model?
We freeze the requirement in waterfall model because if requirement change,
design will also change, and code will also change due to which we are
going to get lot of defects while testing the software.
Ques. Why customer wants to change the requirement?
Because of the competition in the market.
Because customer wants to update himself with new technologies.
As & When the business changes, supporting software should also be changed.

Note: In earlier days if a software company is following waterfall model, then

developers are involved into testing, but now a days if a software company is
following waterfall model, then test engineers are involved into testing.
Ques. What happens if developers are involved into testing?
• Developers are more concerned about developing the software instead of
testing it.
• Developers will always see the product from +ve point of view. They will never
see the product from -ve point of view.
• Developers will utilize the testing time in development of the software.
• If developers find any defect, they will try to hide the defect instead of fixing it.
• Software quality will not be good, and time taken will be more.

Advantages of Waterfall model

1. This model is simple and easy to implement.
2. Time and cost effective model.
3. Software quality will be good in model.

Disadvantages of Waterfall model

1. Requirement changes aren’t allowed in this model.
2. It is not a flexible model.
3. We can’t go for long term project or complex application with model. We can
only go for short term project or simple applications with this model.
4. In earlier days developers are involved into testing.
5. Requirement and design stage are not tested: No one verifies requirement
and design collected by business analyst.
Ques. For what kind of applications we can follow waterfall model?
Applications in which customer says that he will not change the requirement.
Short-term or simple applications.
• It is a step by step procedure or standard procedure to develop a new
software or project.
• In order to overcome the drawback, which was there in waterfall model, we
come up with Spiral model.
• We go for spiral model mainly when there is dependency between modules.
• Example: In Gmail
CRS – Customer Requirement Specification

BRS – Business Requirement Specification

BS – Business Specification Requirement in Business

Language

MRS – Market Requirement Specification

MRD – Market Requirement Document

SRS – Software Requirement Specification

FRS – Functional Requirement Specification

FS – Functional Specification
 Software: Software is a collection of programs or set of instructions which performs a
specific task or function.

Software Testing: The process of finding defects in the software is called “Software
testing”.
OR
Verifying the functionalities of an application according to the customer requirement is
called as “Software testing.”

Methods/ways for software testing

1. Manual testing
2. Automation testing

Manual testing: The process of executing the test cases manually is called as
“Manual testing”.
Automation testing: The process of executing the test cases with the help of a
programming language and an automation tool by writing automation script is
called automation testing.
Ques. Why software testing is important?
OR why we test the software?
• Every software is developed to support the customer business. If there is any
defect in the software, it might impact the customer business. So, before we
giving to customer it should be tested and all the defects impacting business
should be resolved.
• We test the software to check whether it is working according to the
customer’s requirement or not.
• We test the software to improve the quality of the product.

Types of software testing

1. White box testing
2. Black box testing

White box testing

• Testing each and every line of code is called as “White box testing”. It is always
done by developers.
• We call this as white box testing because code is visible to developers.
Ques. Why white box testing is also known as “Unit testing”?
The smallest unit of an application is one line of code and developers are going to
test each and every line of code. That’s why white box testing is also known as “Unit
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

Black box testing:

• The process of finding defects in the software is called “Black box testing”.
• It is done by test engineers
• We call this as black box testing, because code is not visible to test
engineers.
Note: The combination of white box testing and black box testing is called as
“Grey box testing”.

Types of Black box testing

1. Functionality testing
2. Integration testing
3. System testing
4. Acceptance testing
5. Smoke testing
6. Adhoc testing
7. Compatibility testing
8. Performance testing
9. Usability testing
10. Regression testing
11. Globalization testing
I. I 18N testing
II. L10N testing
12. Accessibility testing
13. Exploratory testing
Functionality testing (Component or field level testing)
• Testing each & every component of an application thoroughly according to
the customer requirement is called Functionality testing.
• Here thoroughly means testing with all possible values.
• Here component means it can be text field, drop-down list, radio button,
button, etc.

Examples of components
 Difference between Test Scenario and Test Case
Test Scenario Test Case
1. It is a high level document It is a detailed document
2. In test scenario, we decide what to test In test case, we decide how to test.
3. We write test scenario by referring the We write test case by referring both
Requirement test scenario and requirement
4. Test scenario is not the final document Test case is the final document using
Using which we test the software. which we test the software.

Ques. Why every requirement has got requirement number?

• To have better clarity and understanding on the requirement.
• It will be easy for developers, test engineers and customer to communicate with each
other on the requirement.
 ➢ There is no need to identify test scenario for dropdown list, scroll bar, checkbox,
radio button and button. We will test these components directly, but we will
write the test cases.

Donkey testing:
• Testing the application with those values which doesn’t make any sense is called as
“Donkey Testing”.
• OR Testing the application with same set of data in different ways is called as “Donkey
testing”.
• By doing Donkey testing, we are going to waste our time and money.
Positive testing:
• Testing the application by entering valid data is called as “Positive testing”.
Negative testing:
• Testing the application by entering invalid data is called as “Negative testing”.
Optimize testing:
• Testing the application with those values which make sense is called “Optimize testing”.
• OR testing the application with minimum set of required valid and invalid data is called
as “Optimize testing”.
• By doing optimize testing we are going to cover all the test scenarios in very less time.
Under testing:
• Testing the application with insufficient set of data or less no. of test scenarios is called
“Under testing”.
• By doing under testing, we are going to miss lot of test scenarios because of which we
are going to miss lot of defects.
Note:
➢ We should always start testing the application by entering valid data first (positive
testing). Later we will go for negative testing.
➢ While doing positive testing, if we find any defect, immediately we should stop the testing
and communicate the defect to developer.
➢ While doing negative testing, if we find any defect, we should go for some more values
and after that, communicate the defect to the developer.
➢ We should always go for optimize testing, we should never go for “under testing” or
“exhaustive testing”.
Integration Testing: Testing the data flow between two modules of an application is
called as “Integration testing”.
Compose
Inbox

Ques. How to do integration testing?

• We will read the requirement, understand the requirement that how each module
works and how they are interrelated with each other.
• We will identify the maximum possible integration test scenarios.
• We will prioritize the integration test scenarios.
• We will document the integration test scenarios.
 Assignment1-4.2: Compose to draft

Assignment1-4.3: Compose to outbox

Assignment1-4.4: Compose to inbox

5. We will write the test cases and execute the same.

6. If we find any defect, we will communicate it with the developer.

Testing the data flow between two modules of an application by using valid data
is called “Positive integration testing”.

Testing the data flow between two modules of an application by using invalid
data is called as “Negative integration testing”.
• The process of adding the modules incrementally and testing the data flow
between them is called “Incremental integration testing”.
• There are 2 types of incremental integration testing
1. Top down incremental integration testing
2. Bottom up incremental integration testing
The process of adding the modules incrementally and testing the data flow
between them, but we have to make sure that the module which we are adding
must be the child of previous module, is called as “Top down incremental
integration testing”.

The process of adding the modules incrementally and testing the data flow
between them, but we have to make sure that the module which we are adding
must be the parent of previous module, is called as “Bottom up incremental
integration testing”.

The combination of both Top down and bottom up is called as “Sandwich

integration testing”.

• The process of combining all the modules and testing the data flow between
them is called as “Non incremental integration testing”.
• Generally, we perform non incremental integration testing when some
defect is fixed or changes in the application is done.
Ques. Can we do integration testing if one module is ready and other module is
not ready?
No, but yes it can be done by developing a dummy module.
What are Stub and Driver?
Stub: Stub is a dummy module which is used in place of child module, if it is not
ready while performing Top Down Incremental Integration testing.

Driver: Driver is a dummy module which is used in place of parent module, if it is

not ready while performing Bottom Up Incremental Integration testing.
• Coupling means the in an
application.
• High coupling means higher degree of dependency between two modules.
• Low coupling means lower degree of dependency between two modules.
It is an end to end testing where test environment is similar to the production
environment.

Consider an end to end scenario of customer business and

check it on the software that it is capable of handling it or not.

It is a setup used to develop the software. It consist

of software, hardware, network and server.

It is a setup used to test the software. It consist of

software, hardware, network and server.

It is a setup used by customer or test engineer for

performing acceptance testing or user acceptance testing. It consist of software,
hardware, network and server.

It is a setup where the customer launch the software and

end user use the software to run the business. It also consist of software, hardware,
network and server.
Development environment
Testing the interaction and communication between two application is called as “System
integration Testing” (SIT).

End to end scenario example:

Assignment1: If user is taking loan for second time, the remove the processing fee.
Assignment2: If customer is taking loan for 3rd time then remove the processing fee and
also refund the processing fee by adjusting it in the loan amount which was charged for
taking loan for the first time.
 It is the effort and estimated time taken to start and finish the testing of a
build.
Test cycle duration (2-21 days) depends upon the following factors:
I. Size of the build
II. Complexity of the build/application
III. No. of test engineers working in the team
IV. It depends upon whether we are testing the application manually or with the help
of automation.
When developers compile all the program, they are going to get binary language
and when they compress binary language, we are going to get a build.
 Getting the same build again in the same test cycle or one test cycle is called as
“Respin”.

Starting from collecting the requirement, developing the software, testing the
software and when it is given to the customer is called as “Release”.

Who will be involved in installing the build/ software?

Anyone from testing team, development team or test lead or developer lead or
devops engineer might be involved in installing the build/ software.
Patch: Patch is a small software which consist of newly written program,
modifying program or delete program.
Q. What happens if we install patch?
• Newly written program easily goes and adds new features in the
application.
• Modify program easily goes and update existing features in the
application.
• Delete program easily goes and remove old features from the application.
Note: Patch is used for small changes/ modification in the software, but Release
takes place when we are going to make a lot of changes in the application.
When we should go for System testing?
▪ When basic features are stable.
▪ When a bunch of features are ready.
▪ When test environment is similar to the production environment.
Note:
➢ We are supposed to test only our own assigned features.
➢ We are not supposed to test other test engineers assigned features.
➢ If we find any defect then we are the owner of that defect and we are
responsible to get it fixed.
➢ We should always retest the fixed defect.
It is an end to end testing done by test engineers or IT engineers sitting at customer
place where they refer the real time business scenarios and check whether software
is capable of handling it or not.
Q. Why customer should do acceptance testing?
1) Chances are there that under business pressure, software company gives the
software with lot of defects. To know this in the beginning itself customer
should do acceptance testing.
2) Chances are there that software company misunderstood the requirement
and develops the wrong software. To know this in the beginning itself
customer should do acceptance testing.
3) If customer launch the software in the production environment without
doing acceptance testing then end users might get lot of defects which can
impact customer business.

It is an end to end testing done by internal end users where they use software for
a particular period of time by referring the real time business scenario and check
whether software is capable of handling it or not.

If UAT testing is done by external end users of the application and on the basis of
feedback of users, customer is going to make improvement in the application then
it is known as Beta Testing.
Advantages of Beta Testing:
• Customer will get multiple users to test the application.
• Cost saving for customer.
Disadvantages of Beta Testing:
• External end users will not refer real time business scenario to test the
software.
• Time taken will be more.

If user acceptance testing is performed by software company test engineers (or

some time developers) then it is known as “Alpha testing”.

It is an end to end testing done by software company test engineers sitting at

customer place where they refer the real time business scenario and check
whether software is capable of handling it or not.
 Approach 4:

It is an end to end testing done by software company test engineers sitting at

there own place where they refer the real time business scenario and check
whether software is capable of handling it or not.

Smoke Testing:
Alternate Names:-
1. Sanity testing
2. Dry Run testing
3. Confident testing
4. Build verification testing
5. Skim testing
6. Health check of a software

Fig.

Note:

• Smoke testing is the first testing we should perform on a build.

• Smoke testing-On new build
• Sanity testing-on old build

Fig.

Smoke Testing: Testing the basic or critical features of an application with valid
data before we do thorough or detail testing (functionality testing).
We always do positive testing while performing smoke testing. We will never
go for negative testing because time given for doing * testing is very less.

Sanity testing: Testing the defect which is fixed or changes made by the
developer in the application and again testing the basic or critical features of an
application using valid data is called as “Sanity testing”.
Ques. Why we do smoke testing?

1. We do smoke testing to check whether product is testable or not. If we find

blocker defect in the beginning itself, that means the product is not eligible
for further testing. Immediately we should stop testing and communicate
the defect to the developer.
2. If we find blocker defect in the beginning itself and send it to the developer
then in this way time for both developer and test engineer can be saved.
3. We do smoke testing to check whether software/build is installed properly
or not.
4. Smoke testing is like health checkup of a software. We do it to ensure that
we are not receiving broken build (incomplete build) from the development
team.

Ques. When we do Smoke testing?

• Whenever we receive a new build from the development team, we will
always start with smoke testing.
• Whenever customer do acceptance testing, he will start with positive
testing (Smoke testing) to ensure that :
1. Completer software is received properly or not.
2. Complete software is installed properly or not.
• After launching the software in the production environment customer will
again do positive testing (smoke testing) to check whether software is
installed properly or not.
• Chances are there that developer can also do smoke testing to ensure that
they are not giving broken build (incomplete build) to the testing team.
 Testing the application randomly where we don’t follow any
kind of formal documents like requirement, test scenario or test cases is called as
“Adhoc testing”.
Alternate Names-
1. Monkey testing
2. Gorilla testing
3. Out of the box testing
4. Informal testing
5. Random testing

Ques. Why we do Adhoc Testing?

1. If we launch the software to the end users they might use it randomly and
may find defects. To avoid this test engineers should only test the software
randomly and find the defects.
2. If we test the software according requirement, we will find less number of
defects. To find more number of defects we do Adhoc testing.
3. We do Adhoc testing to somehow increase our test coverage and defect
count.
4. We do Adhoc testing to check whether software is working according to
implicit requirement of the customer or not.

It is a type of requirement for which customer will definitely

say to test.

It is a type of requirement for which customer will not say to

test.
Ques. When we do Adhoc testing?
• Once the application/feature is functionally stable.
• If we have completed all the required testing according to the requirement
and if we have free time then we go for Adhoc testing.
Note 1:

Note 2: In Adhoc testing, we always perform .

Buddy Testing: If Adhoc testing is performed by a developer and test engineer

sitting together, then it is called as “Buddy testing”.
Pair testing: If Adhoc testing is performed by a test engineer is sitting with another
test engineer, then it is known as ”Pair testing”.
Compatibility testing:
Testing the application in different software and hardware environment is called
as “Compatibility testing”.

Fig.

Ques. Why we should do compatibility testing?

1. Chances are there that software which works on one platform might not work
the same on other platform. To make sure that software is working same on
all the platform, we should do compatibility testing.
2. Chances are there that developer develops the software for one platform and
test engineer test the software for same platform but when it is launched to
the end users, they will use it on different platform. To ensure this we should
do compatibility testing.
3. Chances are there that developer writes a common code and says that it works
on all the platform. To know this, we should do compatibility testing.
4. Different software and hardware environment presents the GUI in different
ways. To know that GUI is same on all the platform, we should do compatibility
testing.
Ques. When we should go for compatibility testing?
Once the application is functionally stable, we can go for compatibility testing.
Ques. What kind of defects we can find while doing compatibility testing?
1. Installation issues
2. Look & feel issues
3. Alignment issues fig.
4. Object overlapping issues fig.
5. Scatter issue fig.
6. Scroll bar issues
7. Tool tip defect fig.

Ques. How test engineer manages compatibility testing on different platform?

Application like VMware is installed in the computer, because of which test
engineers are able to switch from one platform to another platform on the same
computer.
Performance Testing:
Testing the stability and response time of an application by applying load is called
performance testing.

Stability: It is the ability of an application to withstand the load.

Response time: It is the total time taken to send request to server (T1), time
taken to process the request by server (T2) and time taken to send response back
to the user (T3) is called as “Response time”.

Fig.
Response time (Rt)=T1 +T2 +T3

Load: Number of users using the application is known as “Load”.

Performance Testing tools:
1. J- meter
2. Load runner
3. Neo load
Ques. How does performance testing tool works?
1. Consider a performance testing tool (J-meter/ Load runner/ Neo load) and insert
the test script into it and click on run button.
2. The moment we click on run button, it will ask for the number of virtual users. Here
we will enter the number of virtual users as 1 crore and after entering click on run
button.
3. The moment we click on run button, there will be a heavy load on the server of
application which will be equal to 1 crore real time users.
4. Server will give the response to the performance testing tool. Performance testing
tool will analyze the response received from server and gives the result in the form
of graph.
5. Test engineer should analyze the result whether the test is passed or failed.
6. If the test is failed, test engineer should communicate this as a defect to the
developer.
7. Test engineer should repeat the same process until and unless the test is passed.
Types of Performance testing:
1. Load testing
2. Stress testing
3. Volume testing
4. Soak testing
5. Scalability testing
6. Spike testing

Load testing: Testing the stability and response time of an application by

applying load which is less than or equal to the number of users is called as “Load
testing”.

Stress testing: Testing the stability and response time of an application by

applying load which is more than the number of users is called as “Stress testing”.

Volume Testing: Testing the stability and response time of an application by

transferring huge volume of data to the server is called as “Volume testing.”
Fig.

Soak testing/ endurance testing:

Testing the stability and response time of an application by applying load
continuously for a certain period of time is called as soak testing.
Example. Jio hotstar. When IPL match is going on.
Flipkart and amazon when big billion days is going on.

Scalability testing:
Testing the stability and response time of an application by gradually increasing
the load and gradually decreasing the load is called as Scalability testing.

Spike testing:
Testing the stability and response time of an application by suddenly increasing
the load and suddenly decreasing the load is called as spike testing.
Example. IRCTC while booking tatkal ticket.
Exam result website when result is displayed.
Fig.
Ques. When we should go for performance testing?
Once the application is functionally stable, we can go for performance testing.

Ques. For what kind of applications we can go for performance testing?

1. Any application which is used by multi users.
2. Any application which generates lot of revenue.
Usability testing/ Cosmetic testing/GUI testing
Testing the user-friendliness of an application is called as Usability testing.

Ques. In which testing requirements are not given?

Usability testing. It is a non-functional testing where user requirements is not
given by customer.
Ques. How to do usability testing?
1. I will check whether the look and feel of the application is good or not.
2. I will check whether the application is simple and easy to understand or not.
3. Important features or frequently used features should be easily available. It
should be available within 3 clicks.
4. To do any simple activity it should take less time.

Ques. When we should go for usability testing?

Once the application is functionally stable, we can go for Usability testing.

Ques. For what kind of applications we can go for usability testing?

1. Any application which is used by variety of users (different age group),
educated or uneducated.
2. Application which generates lot of revenue.
3. Any application in which we are expecting the end users to understand the
application by themselves and use it. E.g. Ola, uber, WhatsApp
Regression Testing
Definition 1: Testing the unchanged features of an application to make sure that
it is not broken or impacted because of the changes in the application.
Here changes in the application means:
1. adding new features in the application or
2. modifying features in the application:
I. When some existing features is updated.
II. When some defect is fixed.
III. When some features is deleted.
OR
Definition 2: Re executing the same test cases in different test cycles OR Sprint
OR Release is called as “Regression testing”.
Ques. What is the role of a manual test engineer?
Whenever new features are added in the application or changes done in the
application, manual test engineer test it manually unless & until the features
become stable.

Ques. What is the role of an automation test engineer?

Whenever changes in the application is done, automation test engineer test the
unchanged features of the application by executing the automation script.

Types of Regression Testing

1. Unit Regression Testing
2. Regional Regression Testing
3. Full Regression Testing

Unit Regression Testing

Testing only the defect which is fixed or changes made by the developer in the
application because the changes in the application is not impacting any
unchanged features of the application. This type of regression testing is known
as Unit regression testing.

Regional Regression Testing

Testing the defect which is fixed or changes made by the developer and also
testing the impacted regions is called as Regional regression testing.
 Ques. How will you identify the impact regions while doing regression testing?

OR How to do impact analysis?

1. By having good product knowledge: As a test engineer I will be
having good knowledge of requirement, and I will be knowing that how
each module works and how they are interrelated with each other.
2. By doing impact analysis meeting: In this meeting the entire testing
team sit together at one place, and they discuss about the newly added
feature and its impact regions and also they discuss about the modified
feature and its impact regions.
3. By preparing impact matrix: Test engineers are preparing impact
matrix in which they list all the features of the application and also the
changed features. After that, they are going to map the changed
features with all the features on the application.
4. We can also identify the impact regions by directly communicating with
other test engineers, developers, Business analyst and customer.

Full regression Testing:

Fi.g

Testing the defect which is fixed or changes made by the developer and testing all
the remaining features of the application is called as “Full Regression testing”.

Ques. When we will go for Full regression testing?

1. When changes are done in the core feature of an application.
2. When too many changes are done in the application.
Advantages of regional regression testing
Time and cost saving.
Disadvantages of regional regression testing
1. Chances are there we might miss the impact regions.
2. Software quality might not be good

Advantages of full regression testing

Software quality will be good.

Disadvantages of full regression testing
Time and money consuming.

Progression and Regression Testing

Testing any feature for the first time is called as “Progression testing”.

Regression Testing:
Testing any feature for second or more number of time is called as “Regression
testing”.
Ques. Difference b/w Regression and Retest?
Regression Retest
Testing the unchanged features of an Testing the defect which is fixed by the
application to make sure that it is not developer is called as Retest.
impacted because of the changes in the
application.
We can automate the regression test cases. We can’t automate the retest test cases.

While performing regression testing, we While performing retest, we refer failed test
refer passed test cases. cases.
Regression is on less priority than retest Retest is on more priority than regression.
Regression is not a part of retest Retest is a part of regression testing.

Ques. Which testing is performed most of the time in test process?

Ans. Regression Testing.
Accessibility Testing
Alternate Names:

• ADA testing (American Disability Test)

• 508 testing
Testing the user friendliness of an application according to the physically
challenged person’s point of view is called as accessibility testing. For example,
Blind person, color blind, hearing problem, etc.

Exploratory Testing (Machine Testing)Important

Exploring the application, understanding the application, identifying the
maximum possible test scenarios, writing the test cases and executing the same is
called as “Exploratory Testing”.
Ques. When we should go for Exploratory Testing?
We should go for exploratory testing when we don’t have the requirement or
when we have lost the requirement.
Ques. What are the drawbacks of Exploratory Testing?
1. By doing exploratory testing, we are going to miss lot of test scenarios
because of which we are going to miss lot defects.
2. Software quality will not be good.
3. Chances are there we might misunderstood the feature as a defect and vice
versa.

Globalisation Testing
Testing the application which is developed in multiple languages and also
testing it according to the country culture and country standard is called as
Globalisation Testing.
There are two types of Globalisation Testing:
1. Internationalisation Testing (I18N Testing)
2. Localisation Testing (L10N Testing)

I18N Testing: Testing the application which is developed in multiple languages

is called as I18N Testing.

In this testing we check:

1. Right language is displayed or not.
2. Right language is displayed at right place or not.
Ques. How does application developed in multiple languages works?
1. Consider an application which is developed in multiple languages in such
type of application we are having two sections on a server as given below:
I. Program files: It is used to store program files for various pages and
features present in the application.
II. Property files: It is used to store the content of all pages in multiple
languages.
2. When we send request using such application request contains two sections:
Page name, language code.
3. As soon as request enters the server the first section of the request (page
name) is identified by the server and program written for the requested page
start executing.
4. After executing the program file, forward the request to the property file of
the requested page.
5. Property file identify the second section of the request (language code) and
the content stored in the property file start executing and is displayed to the
user in that languages which is requested.

Ques. How to do I18N Testing?

1. We will go to property files stored on the server.
2. We will add prefix and suffix in the page we want to test and save it.
3. We will go to application and request the same page in which we have
added prefix & suffix.
4. If the prefix is displayed that means right language is displayed and if the
suffix is displayed that means right language is displayed at right place.
5. We will go to property files and remove the prefix and suffix from the page
and save it.
6. We will repeat the same above process for each and every page which is
stored in multiple languages.
Ques. What kind of defects we can expect while doing I18N testing?
1. Right language might not be displayed.
2. Right language might not be displayed at right place.
3. Alignment issue.
4. Object overlapping issue.
Localisation Testing
Testing the application according to the country culture and country standard is
called as “Localisation Testing”. In this testing we check currency format, mobile
number format, pin code format, date format, etc.

1. Reliability testing: Testing the features of an application for longer period

of time.
2. Recovery testing: Capability of an application to recover by itself after crash/
hang.
3. Comparison testing (Parallel testing, A/B testing, Bucket testing):
testing the application with similar type of existing application in the market.
4. Compliance testing (Conformance testing):
5. Yellow box testing: Testing the warning messages of an application is called
yellow box testing. It is subset of usability testing.
6. Security testing:
7. Risk based testing (RBT):
8. Crowed beta testing: Testing the application by group of people(crowd)
who are not the users of the application.
9. Pair wise testing (All pair testing):
Defect
Any feature which is not working according to the customer requirement is
called as Defect.
OR
Deviation of any feature from requirement specification is known as Defect.

Bug: It is an informal name given to defect.

Error
It is the mistake done by the programmer while writing the programming codes
because of which we are not able to compile it.

Failure/ Bug leakage:

If any defect is found by the end users while using the software in the
production then it is known as Failure.

Fig.

Test engineer
• While testing the software, if test engineer finds a defect then he will
login to defect tracking tool (JIRA, ALM-{Application Lifecyle
Management}, BugZilla, FireFlink, Test-Rail) and prepares a defect report.
• He will send the defect report to the developer lead by giving the status
as NEW.

Developer Lead
• Developer lead will read the defect report and understand the problem.
• He will try to identify the developer who has done the mistake.
• After identifying the developer, he will send the defect report to that
developer by changing the status to ASSIGNED.

Developer:
 • Developer will read the defect report and understand the problem.
• When he starts working on the defect, he will change the status to OPEN
and after fixing the defect, he will change the status to FIXED.
• He will send the defect to the test engineer by keeping a CC to his
developer lead.
Test engineer:
• Test engineer will retest the fixed defect.
• If the defect is really fixed then he will change the status to CLOSED but
if the defect is not fixed he will change the status to REOPEN and send it
to the developer by keeping a CC to developer lead.
This whole above process is known as “Defect/ Bug life cycle” or Defect
Triangle.

Note:
Test engineer will always keep a CC to his test lead before sending any
defect to the development team.

Ques. Why we should not take the permission from test lead before sending
any defect to the development team.
1. As a test engineer I will be having good knowledge of requirement, and I will
be knowing that how each module works and how they are interrelated with
each other. So, it is better to take our own decision and send the defect to the
development team without taking the permission of our test lead.
2. If we wait for the permission of our test lead, there will be delay in
communicating the defect to the development team.

Ques. Why we should always keep a CC to our test lead before sending any
defect to the development team?
1. Test lead is person who might be busy in various kinds of meeting like
developers meeting, BA meeting, test engineers meeting, customer
meeting. So, he must be aware what is ongoing in the project.
2. Test lead will get the visibility that test engineers are working.
 Ques. Why we should send the defect immediately to the development team
as soon as we find it?
1. To save the time.
2. We might forget to send the defect.
3. Some other test engineer might send the defect, if the defect is in
common feature of the application.
Q. If you find a in the software on the last
day of release, then will you release the software to the customer?
1. As a test engineer I am not the right person to take this decision.
However, I will suggest my test lead and project manager not to release
the project.
2. If I was the project manager, definitely I am not going to release the
project. I will talk to customer and explain him about the defect and how
it will impact his business, if software is released to him.
3. I will apologize for the inconvenience caused from our end and ask him
to give some more extension. Apart from this, I will ask my team
members to stretch themselves for long working hours and resolve the
issue as soon as possible.
Ques. What is Hotfix defect?
Any defect which should be fixed immediately, otherwise it will cause a huge
impact on customer business.

Severity:
It is decided based on the impact of defect on customer business.

There are 4 different levels of severity as given below:

1. Blocker defect
2. Critical defect
3. Major defect
4. Minor defect

Blocker Defect:
If test engineer finds a defect in the application and he is 100% sure that the defect
will impact customer business and also it is not allowing the test engineer to test
the software further then this type of defect is known as “Blocker defect”.

Fig.

Critical Defect:
If test engineer finds a defect in the application and he is 100% sure that the
defect will impact customer business, but it is not blocking the test engineer to
test the software further, then this type of defect is known as “Critical defect”.
Fig.

Major Defect:
If test engineer finds a defect in the application and his not sure how the defect is
going to impact the customer business, then this type of defect is known as
“Major defect”.
Fig.

Minor Defect:
• If test engineer finds a defect in the application and he is 100% sure that the
defect will not impact the functionality of application or business scenario of
the customer, then this type of defect is known as “Minor Defect”.
• Generally, in minor defect, we cover spelling mistakes, alignment issue,
object overlapping issue, look and feel, etc.
Fig.

It is the importance given to fix the defect. There are 3 different types of priority
as given below:
1. High priority (P1)
2. Medium priority (P2)
3. Low priority (P3)

High Priority(P1)
If test engineer finds a defect in the application and send it to the developer, by
giving the priority as P1 (High priority), then the developer has to fix the defect
immediately.
Medium Priority (P2)
If test engineer finds a defect in the application and send it to the developer by
giving the priority as P2 (Medium priority ), then the developer can fix the defect
within 2-3 test cycles OR within a release.
Low Priority (P3)
If test engineer finds a defect in the application and send it to the developer by
giving the priority as P3 (low priority), then the developer can fix the defect within
2-3 releases.

1. High severity, high priority

2. High severity, low priority
3. Low severity, high priority
4. Low severity, low priority
Trick

High severity high priority examples

1. In login page of application, login button is not working.
2. In login page, username and password text-field is not working.
3. In Flipkart, buy button is not working.
4. In Flipkart Search text-field is not working.
5. In compose module, attachment feature is not working.
Note:
• Agr koi feature kam nhi kr rha, chahe wo small feature hi q na ho, to is case
me severity High hogi.
• In Flipkart, agr payment krne ke bad order cancel button is not working,
then it is High severity, high priority.

High severity low priority examples

1. In login page, cancel button is not working.
 2. In Facebook, deactivate my account for 30 days is not working.
3. Login button is going to blank page if we click continuously for 10 seconds.
4. Blue tick sign is not displaying in WhatsApp after the message is seen by
user.
5. In WhatsApp one or two emojis is not working due to defect.

Low severity high priority examples

1. Spelling mistake in the name of application. E.g., Zomato is written as
Tomato.
2. Spelling mistakes in the main modules of an application. E.g., in WhatsApp,
chats is written as Cats.
3. Wrong company logo is displayed on the website or application.
4. Alignment issue, object overlapping issue or spelling mistakes in the login
page of an application.
5. Mistake in the customer support number or mail id in an application.

Low severity low priority examples

1. Spelling mistakes in the content of Help or About us module.
2. Alignment issue, object overlapping issue in the content of Help or About us
module.
3. Color of some emojis is not proper in the application.
4. Wrong font size is used in the content of help or About us Module.
5. Look & feel issue in the content of Help or About us page.

Defect life cycle Status

Fig.

Status name
1. Reject
2. Duplicate
3. Postponed/ Deferred
4. Cannot be fixed
5. Issue not reproducible
6. RFE (Request for enhancement or CR)

Reject:
If test engineer finds a defect in the application and sends it to the developer but
the developer is not ready to accept that as a defect, then in this case he will give
the status as reject.

Ques. Why do we get reject status?

1. Because of misunderstanding the requirement:
Chance are there either developer or test engineer misunderstood the
requirement because of which developer can reject the defect sent by test
engineer.
Fig.
2. Because of extra feature in the application/ Page:
Chances are there that developer develops a feature which is given in the
requirement, but he develops in the incorrect page of application. Test
engineer will raise this extra feature as defect which might be rejected by the
developer. So in this case, test engineer should reopen the defect and ask the
developer to update the requirement.
Fig.
3. Because of installing the old build:
Chances are there that test engineer installed the same build again in which
defect was already present instead of installing the build in which defect was
fixed. In this case developer can give the status as reject to the defect sent by
test engineer.
Fig.
4. Because of referring old requirement: Chances are there either developer
or test engineer is referring the old requirement instead of referring updated
requirement. In this case developer might reject the defect sent by test
engineer.

Duplicate:
If test engineer finds a defect in the application and send it to the developer but
the same defect is already sent by some other test engineer then in this case,
developer will give the status as duplicate.

Ques. Why we get duplicate?

1. Because of testing common feature in the application.
2. If test engineer finds a defect and send it to the developer and the developer
has kept that defect under pending section. In the meantime, a new test
 engineer joins the company and by mistake sends the same defect which is
under the pending section of the developer. So, in this case developer will give
the status as duplicate.

TE-1 ---->DEFECT ------------> NEW

TE-2 ---->SAME DEFECT------->NEVER TRACK THIS DEFECT

TE-1 ---->DEFECT------------>FIXED
TE-2 ---->SAME DEFECT ----->REOPEN

TE-1 ----->DEFECT ---------->CLOSED

TE-2 ----->SAME DEFECT ---> NEW

Postponed/Defered: if test engineer finds a defect in the application and sent

it to the developer but the developer want to fix the defect later, then in this case
he will give the status as postponed.

Ques. Why do we get postponed status?

• If test engineer finds a minor defect on the last day of release and the defect
is not going customer business then in this case, developer will give the
status as “Postponed”.
• If test engineer finds a defect in that feature of application which is not
required by customer in the present release then in this case, developer will
give the status as postponed.

Fig.
Compose
Inbox
Outbox
Drafts
Sent items

• If test engineer finds a defect in that feature of an application in which

customer is going to make some updation in the coming days, then in this
case developer will give the status as “Postponed”.
 • If the defect is exposed to that feature which is used by the internal user of
the application then in this case, developer might give the status as
“Postponed”.

Cannot be fixed
• If test engineer finds a defect in the application and sent it to the developer
but developer don’t want to fix the defect or he is not able to fix the defect,
then in this case he will give the status as “Cannot be fixed”.
Ques. Why do we get cannot be fixed status?
1. If test engineer finds a minor defect in the core feature of an application and
the defect is not going to impact the customer business, then in this case
developer will give the status as Cannot be fixed.
➢ It is because core feature are connected with other features, fixing
minor defect may result in impact on other major or critical features.
Fig.
2. If the cost of fixing the defect is more than the cost of defect, then in this
case developer can give the status as Cannot be fixed.
Fig.
3. Because of technology not supportive: Chances are there that the
programming language which is used to develop the software might not
have the capability to fix the defect. So, in this case developer can give the
status as Cannot be fixed.

Issue not Reproducible or Flacky Defect

If test engineer finds a defect in the application and send it to the developer, but
the developer is not able to find the same defect, then in this case developer will
give the status as “issue not reproducible”.

Ques. Why do we get issue not reproducible status?

1. Because of platform mismatch:
▪ Operating system mismatch
▪ Browser mismatch
▪ Browser version mismatch
2. Because of using incorrect/ wrong data:
Chances are there that the data which is used by test engineer to test the
software is able to find the defect but the data which is used by developer is
not able to find the defect.
Fig.
 3. Because of inconsistent defect:
Some defect are inconsistent in nature that means sometimes they are visible
and sometimes they are not visible because of which developer might give the
status as “Issue not reproducible”.

RFE (Request for Extension) or CR

• If test engineer finds a defect in that feature of an application which is not
given in the requirement and sent it to the developer, but developer has
developed that feature to enhance or support the customer business, then
in this case developer will give the status as RFE.
• RFE can be given by developers, test engineers, test lead, developer lead, BA
or customer also.

Ques. How will you convince the developer that the defect which you have
sent is really a defect?
1. I will share him the details of the operating system used, browser used,
browser version used.
2. I will share him the step by step procedure that how I got the defect.
3. I will share him the screenshot of the defect and even after that if he is not
convinced, I will ask him to connect to my computer and I will show him the
demo that how I got the defect.
4. Even after that, if he is not convinced, I will try to find the same defect in two
or three more computers around me and after that I will inform to my test
lead.
Ques. If time is very less what will be your test approach?
1. We have to follow very focused approach:
A. Test all the critical(important) features first.
B. Test those features which give more coverage in less time.
2. I will come up with certain tricks to catch more defect in less time:
A. I will test newly modified feature.
B. I will test those feature which can have more impact because of newly
modified feature.
C. I will test those feature which is developed new by developer.
D. I will test those feature which was developed by the developer who
normally does more mistake.
3. I will not do certain activity which are really not important:
A. I will not do more negative testing.
B. I will not do Adhoc testing.
C. I will avoid doing usability testing.
D. I will not test the application on all platforms, I will test it on important
platforms only.
E. I will stretch myself for long working hours and complete the testing on
time.

1. Service based or Project based company

2. Product based company
Service based or Project based company:
• Initially customer is present.
• Business analyst visit at customer place in order to collect the requirement
from customer.
• Software company develops the software, test the software according to
the customer requirement and gives the software to that particular
customer only.
• Software company has no right to sell the software or source code to other
customers.
• Example, TCS, Infosys, HCL, Wipro, etc.
Product based company:
• Initially customer is not present.
• Product analyst do market survey and collect the requirement from the
market.
• Software company develops the software, test the software according to
the market requirement and sell the software to multiple customers.
• Software company has full right to sell the software or source code to
multiple customers.
• Example: Google, Microsoft, Sony, Samsung.

1. Defect Cascading: If a defect is trigging any other defect.

2. Defect Leakage: Defect found by end users after release.
3. Latent Defect: Any defect which should be found earlier, but we found
after long period of time.
4. Defect paradox/ pesticide paradox: we should update our test cases
time to time in order to get more defects; i.e., if we are using same test case
or scenario again and again and we are not getting any error.
5. Defect clustering: maximum defect in one or small module.
6. Defect Triage meeting or Defect group meeting: When time is
very less and there are too many pending bugs to be fixed. In such a case,
defects are categorized into different status:
A. All critical defects are moved to assigned status.
B. There are some defects which need not to be fixed on urgent basis.
These defect are moved to postponed status.
C. There are some defects which need not be fixed at all. These defects are
moved to cannot be fixed status.
Such grouping of defect is called as Defect triage.
7. Defect Seeding: intentionally introducing defect in the software to
evaluate the efficiency of a test engineer, is called Test seeding.
8. Defect masking: One defect is hiding another defect is called “Defect
masking”.
Traceability Matrix
Alternate Names
1. RTM (Requirement Traceability Matrix)
2. CRM (Cross Requirement Matrix)
Traceability matrix is a document which ensures that we have written at least one
test case for each and every requirement.

Template for Traceability Matrix

S.No. Module High level Detailed Test Automation Script
Name Requirement Requirement Case
1. Login To login into Enter valid
module application data into the
components
given below:
1)Username:
2)Password:
3)Login
4)Cancel

1. Forward traceability matrix

2. Backward traceability matrix
3. Bi-directional traceability matrix
Fig.
Forward Traceability Matrix:
The process of mapping from root document (Test case) to derive document
(automation script) is called as Forward traceability matrix.

Backward traceability matrix

The process of mapping from derived document (automation script) to root
document (test case) is called as Backward traceability matrix.

Bi-directional traceability matrix

The process of performing both forward and backward traceability matrix is
called as Bi-directional matrix.
Advantages
1. It ensures that we have written at least one test for each & every requirement.
2. It keeps tracking from requirement till automation script .
3. Software quality will be good.

Disadvantages:
Time and money consuming.

1. We should start the testing process at very early stage. (Reading &
understanding the requirement, writing test scenario and test cases.)
2. We are testing the software in order to find the defects.
3. We should not do exhaustive testing while testing the software.
4. 100% defect free software is not possible.
5. We should always do context based testing while testing the software.
(Performing required testing among the available black box testing.)
6. We should be aware of pesticide/ defect paradox.
7. Defects cluster together.
Customer requirement/ user story

Release – Sprint

SCRUM: A method or procedure to develop software.

1. Formation of Scrum team: generally, of 5-12 persons

2. Formation of Product backlog: prioritize feature formation
3. Formation of sprint planning meeting:
A. First sprint backlog: Pulling the requirement from sprint backlog
B. Scrum master is going to assign task
C. STORY POINT: estimated time taken to complete the derive task.

Core team Shared team

Scrum master BA
Developers Product owner
Test engineers Architect
UI/ UX designer
Network admin
Database admin
4. Coding and Testing:
Sprint review meeting
5. Acceptance testing
6. Production environment
7. Retrospect meeting: Discuss the achievement and mistakes
8. Same above stages followed for next sprint.

Ques.
1. Sprint planning meeting
2. Sprint review meeting
3. Retrospect meeting
4. Daily scrum meeting or standup meeting or Roll Call meeting: 10 to 20 min
5. Grooming meeting or backlog refinement meeting (optional): In this
meeting training or grooming is given to the scrum team regarding the user
story or the product backlog.
Terms related to Agile
1. Spill over: Feature that was supposed to be developed in same sprint, but
due to some reason, assigned in next sprint.
2. Burndown chart: Graphical representation of work left vs time taken
3. Story board: board or screen that shows list of pending task, task in
progress and completed task.
4. Chicken: Person who is not involved in the project directly but are eager or
curious to know what is going on in the project.
5. Epic: When we break a large collection of user story into many small user
stories, then the collection of small user stories is known as epic.
6. Velocity: Velocity chart is used to calculate the efficiency of a scrum team. It
is the graphical representation which specifies how much work can be
completed by scrum team within given time.

Now days We can have also. In this

way project is completed in shorter span of time.
 • It is a step by step procedure or standard procedure to test a software.
• It is a part of SDLC.

Stages in STLC
1. System study: In this stage we are going to read the requirement,
understand the requirement and we have doubt regarding the requirement
we are going to clarify it by communicating with developers, BA or
customers.

2. Prepare Test plan: Test plan is a document which drives all the future
testing activities. It consist of following points:
I. How many test engineers will be required for testing activities.
II. What each test engineer should do in each stage of testing.
III. What will be the testing approach.
IV. What are the various types of testing we are going to conduct on the
software.
V. What are the features to be tested and what are the features not to be
tested.
VI. What are the features to be automated and what are the features not
be automated.

3. Prepare test case: Once after test plan is ready we start preparing test
cases. This stage itself contains many sections as given below:
I. We do system testing.
II. We identify the maximum possible test scenarios.
 III. We write the test cases.
IV. We will go to test lead for test case approval.
V. Test lead will assign reviewer to review the test case.
VI. Reviewer will review the test case and give the review comments.
VII. We will fix/correct the test case review comments.
VIII. Reviewer will verify the fixed/ corrected review comments.
IX. test lead will verify the test cases randomly and if everything is found
to be ok then test lead will approve the test case.
X. We will store the approved test cases in test case repository.

4. Prepare traceability matrix: Once after test case is ready one of the
biggest question arises is that what is the guarantee that we have written test
cases for each and every requirement. To ensure this, we prepare one
document known as traceability matrix. Traceability matrix is a document
which ensures that we have written at least one test case for each and every
requirement.

5. Execute the test cases: Once we have received the build from the
developer and installed it in the test environment, we start executing the test
cases. This is the stage where we perform various types of black box testing
on the software in order to find the defects. This is the stage where a test
engineer is most productive to the software company.

6. Defect tracking: we are executing the test cases that means definitely we
are going find the defects in the software. All the defects should be tracked
in a systematic and organized manner.

7. Prepare test execution report: We prepare test execution report at the

end of every test cycle. This report consist of following points:
I. How many total test cases are written.
II. How many test cases are executed.
III. How many test cases aren’t executed.
IV. How many test cases are passed.
V. How many test cases are failed.
VI. What is the test case pass percentage.
VII. What is the test case fail percentage.

Note: We give the test execution report of the last test cycle to the customer.
By looking into the test execution report, customer understands that the project
is completed for him, but for the software company there is one more stage left,
that is Retrospect meeting.

Retrospect meeting: In this meeting the entire testing team sit together at one
place, and they discuss about the achievements and the mistakes they have
done in the project. They make a note of all the achievements and the mistakes
in one of the document known as retrospect document. When they start
working for the next project and when it is under planning stage they refer the
retrospect document and make sure that all the achievements should be carry
forward and mistakes should be avoided for the next project. In this way test
engineer improve themselves after every software testing lifecycle.

Ques. Difference between SDLC and STLC?

SDLC STLC
1. SDLC stands for Software STLC stands for Software Testing Lifecycle
Development Lifecycle.
2. It is a step by step procedure to It is a step by step procedure to test a
develop a new software. new software.
3. SDLC is not a part of STLC. STLC is a part of SDLC.
4. In SDLC stages like design, In STLC stages only testing stage is
coding, testing and deployment involved.
of the software is involved.

Test plan doesn’t have any standard sections. It contains various sections.
Test case is a detailed document which covers all the possible test scenarios for a
specific requirement.

Ques. What will happen if we test the software by looking into the requirement?
1. There will be no consistency in testing the software.
2. Quality of testing depends upon the memory power of the test engineer.
3. Quality of testing will depend upon the mood of the software test engineer.
4. Quality of testing will vary from one test engineer to another test engineer.
5. Software quality will not be good.

Ques. When exactly do we write test cases?

1. When we get new requirement, we will read the requirement, understand
the requirement, identify the maximum possible test scenarios and write
the test cases.
2. Whenever there is a updation in the requirement in between the project to
add new features, we will write test cases for newly added features.
3. Whenever there is a modification in the requirement in between the
project, we will modify our test cases accordingly.

Ques. Why do we write test cases?

1. There will be consistency in testing the software.
2. Test coverage will be good.
3. We can avoid training every new test engineer on the requirement who
joins the company in between of the project.
4. Test case is a document which acts like a proof between test engineer and
developer, test lead, project manager, BA, customer that test engineer has
tested each & every feature in detailed manner.
5. Test case is the base document for writing automation script.
6. If we will not write the test case, we will not be able to cover all the test
scenarios in detailed manner.
7. Software quality will be good and test execution happens in smooth
manner.

1. Error Guessing
2. Equivalence class partitioning (ECP)
 I. Pressman Rule
II. Practice method
3. Boundary Value Analysis (BVA)
4. Decision Table
5. State Transition

Error Guessing
In this technique we write the test cases by looking into the requirement, by
using our previous knowledge and experience or by having intuition.
Example.
Fig.

Equivalence class partitioning (ECP)

Pressman Rule:

1. If the input given is in the range of values, then we will test for 1 valid value and
two invalid values.
Example. Amount -->100-5000
1 Valid -->1000
2 Invalid→ 99, 5001
2. If the input given is for a set of values then we will test for 1 valid and 2 invalid
values. Example. Mob

3. If the input given is in Boolean, then we will test for all the values.
Example. Gender
Male Female
2. Year
Drawback of Pressman Rule
• Consider the above given example for which we are going to test using
pressman rule.
• By following pressman rule, we will test for 1 valid value (1000) and 2
invalid values (99 & 5001).
• If we test by entering the valid value (1000) then first block of the program
will be executed, and first condition of the requirement will be tested.
• If we test by entering the first invalid value (99) then 3rd block of the program
will be executed, and 3rd condition of the requirement will be tested.
• If we test by entering the 2nd invalid value (5001), then again 3rd block of the
program will be executed, and 3rd condition of the requirement will be
tested.
 • So here by following Pressman rule, we are not able to test the 2nd condition
of the requirement at least once.
• So, whenever there is more condition or deviation given in the requirement
then pressman rule fails there. So, in order to overcome this we come up
with Practice method.

Practice method
• If the input given is in range of value, then we will divide the range into equal
parts and we will test for 1 valid value for each part and 2 invalid values for
complete range.
Example. Amount →100-5000
I. 100-2000 →20 cashback
II. 2001-5000→50 cashback
III. Other values →Error message
• Practice method:
99

100-1000 →500
1001-

Note:
1. Whenever there is a deviation or more no. of conditions given in the
requirement, we will always follows practice method.
2. If there is no deviation in the requirement, we can follow Pressman rule.
3. By looking into the requirement, we will come to know there is deviation or
not.

If the input given is in a range between minimum & maximum then we will test for
min-1, min, min+1 and max-1, max, max+1.
Example. Amount -->100-5000
Decision Table (Cause effect table)
We use this technique when we are having multiple conditions and corresponding
actions. In this technique we deal with different combinations of inputs to check
which action is performed.

State transition
We use this technique if changing the input condition changes the state of the
application. We use this technique to test the behavior of the application.
Test engineer performs both positive & negative testing to check the application
behavior.

Every test engineer will be writing test cases either in excel sheet or test case
management tool. There is nothing called as “Standard test case template”. It
may vary from software company to software company and project to project.

Generally, we are having 3 sections in a test case template as given below:

 1. Header
2. Body
3. Footer

HOW TO GIVE TEST CASE NAME

Project name_Module name_Scenario name_Page name
e.g. ICICI BANK_INSURANCE_AGE TEXT FIELD

NOTE POINTS WHILE WRITING TEST CASES:

1. We should always start writing test cases using navigational steps.
2. While writing the expected result we should always use the terms like should
be displayed or must be displayed. We should not use the terms like can
be, may be, will be, shall be displayed etc.
3. While writing the test cases we should always imagine the application.
4. We will always write the actual result while executing the test cases in order
to test the software.
 5. If actual result and expected result are same that means the test steps are
passed, and we should give the status as passed.
6. If actual result doesn’t match with the expected result that means the test
steps are failed, and we should give the status as failed and report this as a
defect to the developer.

the process of removing the duplicate test cases is

known as Test Case Optimization.

It is a document which is in the form of text, flow chart, diagram or

graphical representation and is used to understand the working flow of
application or how a user interacts with the application.