MANUAL TESTING

Terminologies used in software industry

1) REQ: requirement
2) Defect: it’s a deviation in the with respect to requirement
3) Bug: it’s a informal name of a defect.
Whenever a defect is found by a test engineer it should be released to the
developers. Once the developers accept the defect it is termed as defect.
4) Error: mistake in the source code is known as error.
5) Issue: problem faced by the customer or the end users.
6) Failure: multiple issues will lead to the failure.
When the end users face lot of issues that will lead to the failure.
QA and QC
QA: is quality assurance.
It is a process oriented
QC: is a quality control.
It is a product oriented.

QA QC
It is a procedure that focus on providing It is a procedure that focus on fulfilling the
assurance that quality requested will be quality requested.
achieved.

QA aims to prevent the defect QC aims to identify the defect.

It is a method to manage quality verification It is a method to verify the quality validation

It does not involve executing the programs. It always involves executing the programs.

It is a preventive technique. It is a corrective technique.

RTM: requirement traceability matrix.

KT: knowledge transfer.
DOMAIN: it is a categorization of the software application into various fields. Each software
company will work for various domains.
Finacle: it is a banking software used by the banks.
 MANUAL TESTING

Servers and environments

We have usually 3 types of servers.
1. Development server.(used by developers)
2. Testing server or QA server(used by test engineers)
3. Production server(end users)
Eg . www.dev.facedook.com
www.qa.facebook.com
www.facebook.com
We have the different servers because developers, test engineers, end users should use the
application and work independently.
When developers are working for 1 feature. That feature is given to testing team during that
time developers start working for another feature
Due to this
1. Everybody can work independently.
2. Dependency will not be there.
3. If any problems occurs it can be handled separately.
4. Disturbance will not be there for end users.
Stake holders
A person who directly (or) indirectly involved in a software application (or) project is a stake
holder.
SDLC(SOFTWARE DEVELOPMENT LIFE CYCLE)
It is a procedure to develop the software application.
It consists of different stages.
CRS: customer requirement specification
BRS: business requirement specification.
SRS: system requirement specification.
BA: business analyst.
HR: human resource.
HLD: high level design.
LLD: low level design.
TE: test engineer.
PM: project manager
MANUAL TESTING
Requirement
gathering

Feasibility study

High level design

design
Low level design

coding

testing

Installation

maintaince
 MANUAL TESTING

Requirement analysis: usually customer or client gives a requirement in the form of

CRS/BRS. And it is converted into SRS by BA. BA means business analysis. BA acts bridge
b/w customer and company.
BA should be good in
1. Communication skills
2. Domain expert
3. Convencing skills.
4. Technical expert.
BA collects all the requirement from the customer is called requirement analysis.
Feasibility study: in this phase BA, HR, ARCHITECT, FINANCE, PM will discuss all the
information that is needed.
BA will explain about the project
HR is for needed resource.
Finance will take care about budget.
Architect will for which technology we should use for project.
Pm will take the final decision and gathers all the data information to proceed for the next
step or not.
Design: once everything is fine, we go for the design.in design we have HLD and LLD.
Usually design phase is done by the architect or senior developers
High level design: is just like a blue print .it shows the external specification of the project.
Low level design: shows the internal specification of the project.
Coding: once the design is done developers starts writing the code for application by
looking at design or requirement.
Testing: once coding is done developers will give application to test engineers. All test
engineers start finding the defects. If any defects are found in software application, it again
goes back to the developers like this process continues.
Once everything is completed, we will go for next phase called installation.
Installation: making the software application available for end users is called installation. It
is done by the software company once testing is completed. Customers should approve for
installation.
Maintenance: once software is provided to customer or end users if they face any problem a
support has to be provided that is maintenance.
Initially it will be free. later it will be paid. Free service will be provided based on the
agreement b/w customer and company. During maintenance defect fix will be handled and
changes will be taken care.
 MANUAL TESTING

TYPES OF SDLC MODLES

Water fall model
It is one of the oldest traditional models.
When we go for water fall model?
1. When the customer freezes the requirement
2. For any short-term project.
3. For developing simple application.
What are the advantages of waterfall model?
1. We can expect stable application.
2. There will be no disturbance for the team members if the requirement does not
change.
Drawbacks of waterfall model?
1. Testing happens after coding.
2. Requirement and design are not tested.
3. Developers used to do testing before. (currently it is done by test engineers)
4. If requirement changes it leads to lot of work.
Why developers are not involved in testing?
1. Developers always focus how to build the software not to break the software.
2. They always be over confident what they do.
3. They does not like to find there own mistake.
4. Since it is not easy to find there own mistake , even though mistake are there they will
hide it.
Spiral model
This is also one of the traditional model.
 MANUAL TESTING

When do we go for spiral model?

1. When the customer gives requirement part by part.
2. When there is a lot of dependency b/w the models.
What are the advantages of spiral model?
1. Customer can see the application partially and can get confidence.
2. Requirement changes can be done.
What are the drawbacks of the spiral model?
1. Requirement and design are not tested.
2. Testing happens only after coding.
3. Developers used to do testing.
4. If there is any requirement changes it may delay the projects.
Requirement changes are of two types.
1. Major: whenever there is a major changes we work only on that changes. we cannot
work on the new requirement.
2. Minor: whenever there is a minor change we can work on that changes and we can
work on the new requirement.
V and V model
V and V means verification and validation model
Verification is a process of checking “are we building product right”
Validation is a process of checking “are we building right product”.
V and V is done only by test engineer.
Verification is QA process.
Validation is a QC process.
When do we go for V and V model?
1. When the customer needs high quality products
2. For compiler applications
Ex banking, health care applications, space applications, airlines applications,
navy applications.
3. For Long term projects. (more than one year).
 MANUAL TESTING

Review CRS and AT Acceptance

CRS
Write ATP and ATC testing /UAT

Review SRS againest CRS

SRS ST
Write STP and STC

High level Review HLD Againest SRS

IT
design Write ITP and ITC

Review LLD against HLD

Low level FT
design Write FTP and FTC

coding White box

verification testing

verification validation
Software is
ready for
testing

advantages of V model
1. Testing is started at initial stage.
2. Requirement and design are tested
3. The downward flow of defects are less.
4. Requirements changes can done.
5. Quality will be high compared to other products.
6. Rework will be less.
Drawbacks of V model
1. Documentation work will be more.
2. Too much of resource are needed.
 MANUAL TESTING

Explain about V and V model?

V and V means verification and validation model. It is one of the best model in SDLC. In
this model the development and testing are done parallelly the left side of model is done
by developers and the right side of the model is done by the test engineers.
When the customers give the requirement of 100 pgs documents in the form of CRS. It is
converted in the form of SRS by BA. At some time, review of CRS is done by test
engineers. If there is any mistakes it goes back if not it will continue the process. The
SRS will review against the CRS to find the defects. Parallelly they do the test plan and
test cases will be ready for the application to test.
Once the documentation of development process is done, with the design and coding, the
software is ready for testing.
First testing is white box testing. This testing is done by the developers, then there will be
FT it is done by the TE. At the same time the execution of the test cases are also done.
After FT the IT is done, test cases are same for all the application for execution. Later ST
and then AT is done by the customer then it is released to end users.
The review of the document is verification and it is based on QA.
The testing of application is validation and it is based on QC.
Prototype model
Prototype is a dummy model that is a non-working application.
When we go for prototype model?
1. When the customer is not clear about requirement.
2. When the software company is new to the domain, then they will go for prototype
model.
3. When the developers are new to the technologies it is a experimentation model.
4. When the customer and software company are new to the business.
Advantages of prototype model
1. Initially customer can get to know what he gets on.
2. Initially itself developers will also come to know what they should deliver on last day.
3. Requirement changes can do on initially itself.
4. Initially investment is very less.
Drawbacks of protypes model
1. There will be a delay in the actual short of the real project.
2. Investment is done on non-working product.
3. Too many changes can disturb the rhythm of the company.
MANUAL TESTING
 MANUAL TESTING

SOFTWARE TESTING
• Testing the functionality of an application with respect to given REQ.
• Checking the application with the intent of finding the defect.
• Checking the behavior of an application to see whether it meets customer REQ or not.
• Testing the process of QA and QC.
MANUAL TESTING
Testing the software without using any tool and ensure its working fine.
AUTOMATION TESTING
Testing the software by using the tool to ensure it is working fine. (the tool can be selenium)
Examples
1. Television remote: if we operate by using the remote it is a automation testing
if we do without remote it is manual testing.
Why testing is important?
Every software is developed for business purpose if testing is not done, end users may find
the defects while using the applications.
This will spread negative impact in the market and number of users who uses application will
be reduced. This will become loss for the investor on business. To avoid all those things s/w
testing has to be done before it is released to end users.
SCENARIOS
Testing the application in all the possible ways is scenarios.
It can be +ve scenarios or -ve scenarios.
Testing the application with valid or expected data is called +ve scenarios. It is also called
positive testing.
Testing the application with invalid or unexpected data is called -ve scenarios. It is also called
negative testing.
To identify the defects we should find the scenarios first.
Scenario is not a defect or defect is not a scenario.
+ve scenarios and -ve scenarios are not a defect.
Few cases we may get confused whether it is a +ve scenario or -ve scenario. In this case we
can judge whether it is a defect or not a defect based on REQ.
DROWBACKS OF MANUAL TESTING.
It is a time-consuming process.
It is a repetitive in nature
Turn around time is more in manual testing so we go for automation testing.
 MANUAL TESTING

RETESTING AND REGRESSION TESTING

RETESTING
Testing the defect fixed which is done on an application is called retesting.
REGRESSION TESTING
Testing the impacted areas of an application after
1. After the defect fixed.
2. After changes done in application.
Changes can be adding modifying and deleting a feature.
TOOLS USED IN INDUSTRIES
Functional testing tools
1. Selenium(core java ,python,…)
2. QTP/UFT(quick test professional, unified functional test) supports VBS(visual basic
scripting)
Selenium is a free and is a open source.
Qtp/uft is a paid and licensed tool developed by HP. Hewlett Packard
Thought works is a company that came up with the selenium tool.
3. Win runner.
4. Silk test.
5. Test partner.
The tools which are using are
1. Functional testing tools are
1. Selenium : selenium is a tool which is in demand and it is a open source and free
tool. The best combination is that selenium is used by core java. Thought works is
the first company to come with the selenium.
2. Qtp/uft: it is powerful tool and it is a paid and licensed tool.
The best combination is that qtp is used by vbs.
performance testing tools
checking the load and response time.
1. Load runner
2. J meter.
3. Qa Load
4. Silk performer.
5. Neo load
Load runner is a licensed tool. it is with hp.
 MANUAL TESTING

Test management tools

1. QC/ALM(quality center /application life cycle management)
it is a licensed tool. it is with hp.
2. JIRA.(best tool for agile modal)
3. OTM(oracle test management tool)
4. Test link
Using the above tools we can manage the testing activities like below
Req-add requirement
Test plan-write test cases
Test lab-execute test case.
Defect-repose defect or track defect.
What are the test management activities?
1. Going through the req given by the customer and adding to the test management tool.
2. Write test cases by identifying scenarios
3. Execute test cases.
4. Find defect , report defect , and track.
Defect or Bug tracking tools
1. Bugzilla: it is a open source and free.
2. QC/ALM(quality center /application life cycle management)
it is a licensed tool. it is with hp.
3. JIRA.(partially free)
In Bugzilla we cannot add the requirement write test cases and execute test cases. We can
only report the defect and track the defect.

TYPES OF TESTING

White box Gray box Black box

testing testing testing

Unit testing functional testing

Glass box testing behavioral testing
Structural testing closed box testing
Transparent testing
Open box testing
 MANUAL TESTING

White box testing : testing the source code or internal structural of an application is called
White box testing.
It is usually done by developer.
Black box testing: testing the user interface(UI) or graphical user interface(GUI) of an
Application is known as black box testing
Here we don’t worry about internal structure of an application.
It is done by test engineers.
Gray box testing: testing the source code and user interface of an application parallelly
Together is called gray box testing.
It is done by a person who is aware of both testing and source code of an
Application. Means he can be a developer or test engineer.
White box testing tools
Junit: when the source code is written in java to test that we use junit.
Nunit: when the source code is written in .net to test that we use nunit.
Selenium is a tool to test the black box testing.
wbt

manually automation
1. Check each and every code 1. Write a pgm to develop
Manually without using a tool 2. Write a pgm to test(using junit,nuint)
Ex . check the syntax and logics 3. Run the test pgm in a tool
bbt

manually automation
1. Check each and every 1. Write a pgm to test (using selenium,
Functionality without using a qtp) the ui
Tool on ui. To use selenium core java is used
For qtp vb is used.
Run the test pgm in the tool.
 MANUAL TESTING

Difference b/w scenario and test cases.

scenario Test cases

It will tell all the possible ways we can test the It is step by step procedure to test the
application application.

Scenarios says “what to do” Test cases says “hoe to test”.

Scenario is a high-level document. Test cases is a low-level document.

Scenario doesn’t have a navigation steps. Test cases have a navigation steps.

Scenarios doesn’t say where the exact defect is Test cases will tell where the exact defect is
there present.

Scenarios take less time to write. Test cases take more time to write.

Template is a format used to write a test cases.

Test cases
A test case is a document which contain all the possible scenarios.
When do we write test cases?
When the developers are developing the application, we will write a test case.
There are two stages
1. Test case preparation.
2. Test case execution.
Under the test case preparation, we have to fill following sections like
1. Step no
2. Description
3. Input
4. Excepted result.
5. Actual result
Under test case execution we have to fill following sections like
1. Actual result.
2. Status.
3. Comments.
 MANUAL TESTING

Software testing life cycle (STLC)

It is the procedure to test the software application. It has a different stages and phases like

System study

Write test plan

Write test cases

Prepare RTM

Execute test cases

Defect tracking

Test execution report

Retrospective
meeting
 MANUAL TESTING

System study: it is going through the requirement given by the customer and understands
how the system works.
Write test plan: it is a document which is prepared for feature to do the testing activates.
It is done by the test lead or test manager in the testing field. Because the plans where done
by experienced people.
Write test cases: it is a step by step procedure to perform the testing on the application. It is
done by the test engineer. Once we go through the requirement, we identify the scenarios and
then converted into the test cases. To write the test case we need requirement and test case
template or tools (qc/alm, JIRA)
Prepare RTM:(requirement tractability matrix): it is a document which is prepared to check
weather every requirement has at least one test cases.
To prepare RTM we need both requirement and test cases.
Execute test cases: once the requirement is given to the test engineer. He writes test cases for
the application. After the developer gives the developed application then the test cases are
compared with expected result and actual result. If the expected result and actual result are
same then the status is pass, if the expected result and actual result are not same status will be
fail. This is called execute test cases. So, to execute test cases we need test cases and software
application. This is were the exactly the software is been tested. This is the most important
phases of software testing life cycle.
Defect tracking: while executing the test cases we may come across the defects. These
defects are raised to the developers and they accept defects and starts fixing it. This is called
defect tracking. It is done by using tool called “Bugzilla”.
Test execution report: once we execute the test cases. we should prepare one document
called test execution report. This document tells about how many test cases are pass and how
many test cases are fail.
Till here customer involvement will be there according to the customer this is the end of the
project.
Retrospective meeting: in this meeting all the team members will gather together like PM,
TL,DL, TL DEV,BA, TM and they discuss about the good and improvements needed once
the project is done. This will be very useful for next release or next project.
 MANUAL TESTING

DEFECT LIFE CYCLE OR BUG LIFE CYCLE

CLOSED
Differed/postpone Duplicate Cannot Invalid/ RFE Cannot
fix reject reproduce

RETEST
NEW /OPEN ASSIGN FIXED

REOPEN
If the defect is not fixed properly

When we are executing the test cases if the excepted result and actual result are not same we
come across the defect, then the defect are raised to the developer then the status will be
new/open. And the new defect is assigned to the developer or development lead. The
developer will reproduce the defect and accepts it. Then he start fixing the defect in the
development server. When he fixes the defect he will change the status as fixed. The defect
which is fixed is installed in testing server. The test engineer start retesting the defect fixed
in the testing server. If the defect is properly fixed then the status will be closed. If the status
is not properly fixed then again, the defect is reopened to the developer.
What is differed/postpone?
Whenever test engineer raises the defect the developer accepts the defect but he will not fix
the defect. He will give the status as differed/postpone.
Whenever there is a major defect or minor defect. Developer have less time to fix the major
defect. In this case the developer will fix the major defect and for minor defect he will assign
status as differed or postpone.
What is duplicate status?
Whenever the test engineer finds the defects and he did not raise it. If another test engineer
finds the same defect and he raise it unknowingly. Then this status is known as duplicate.
To avoid this when the test engineer finds the defects, he should raise it immediately so that
there will not be duplicate defects
 MANUAL TESTING

Can’t be reproduce
When the test engineer finds the defects but developer cannot be able to reproduce that
defect. So he will change the status as “cannot be reproduce”.
Ex mobile hang .. etc.
Reasons for can’t be reproduce
1. Installation problem
2. Improper defect report.
3. Inconsistent bug.
Can’t be fixed
Whenever the developer is unable to fix the defect that is raised by the test engineer, then he
changes the status as “can’t be fixed”. And it is a void defect but he can’t fix the defect.
Even though the developer does not fix the defect, it should not affect the business.
If the technology doesn’t support to fix the defect.
Invalid/reject
Whenever the test engineer raises the defects but developer will not accept the defects and he
change the status as invalid/reject.
Reasons for invalid
Due to the misunderstanding of the requirement.
1. If test engineers misunderstand requirement
New/open assign invalid closed
2. If developer misunderstand the requirement
New/open assign invalid reopen fixed closed
Request for enhancement (RFE)
Whenever the test engineer raises the defect which is not given in the requirement so the
developer will take it as suggestion. In this case he will change the status as RFE.
 MANUAL TESTING

SEVERITY
Severity will tell how much that defect effect to the customer business is known as severity
Types of severity
1. Blocker
2. Critical
3. Major
4. Minor
5. Trivial: this defect is negligible.

PRIORITY
Priority says which defect has to be fixed first by the developer.
For every defect we have to set priority.
Different types of priority
1. High
2. Medium
3. Low
Who will set severity and priority?
Test engineer will set severity and priority.
Developer or managers can discuss about this if they want to change it they have to provide
proper justification.
Priority is very much important for the developer to decide which defect has to be fixed first
If priority is not their developer may fix the easy defects and they leave all the important
defects
As a project point of view the important part of defects has to be fix earlier.to manage these
things we have severity and priority for each and every defect.
 MANUAL TESTING

TEST CASE TEMPLATE

Test case name
Project name
Module name
Requirement number
Test data
preconditions
Test case type
priority
Test case environment
Test case description
Test steps
Sl.no description Input Expected Actual Status comments
result result

Author
Reviewer
Approved by
Approved date

Header part
Test data: it is the data we need to execute the scenarios.
Pre conditions: it is the action which we should do before executing the scenarios.
Test case type: in this section we should write which type of testing we are going to use.
Priority: assigning the priority to each and every test cases will help us in prioritizing the
defects
Test case description: summery of test cases.
 MANUAL TESTING

DEFECT REPORT
When ever the test engineer finds the defect it has to be raised or logged or reported to
developer. For this we have to create a defect report.
When we create the defect report in tools like BUGZILLA, or by using the excel file or word
documents
Template for defect report
Defect ID This will be auto generated if we use the tools
Build no It is the number of build where defect has found
Test case no It is a number of the test case where we found this defect
Status
severity
Priority
Test environment
Module no
Reported by
Brief description
Test data
Steps to reproduce

Expected result
Actual result
Attachment of screen shot
 MANUAL TESTING

ACCEPTANCE TESTING:
It is testing which is mainly done to check the business scenarios of the application which is
done by the customer.
(or)
It is an end to end testing which is done by the customer to ensure the application is fit for
business scenarios or not.
Why acceptance testing is done?
This is mainly done to get a confidence for customer before he releases the product to the end
users.
Because of business pressures, software company might be releasing the project to the
customer with some defects. To ensure this customer will do acceptance testing.
If the product is released to the end user without checking the business scenarios, it will
affect the customer business. To avoid this acceptance testing has to be done.
Approaches of acceptance testing.
BA or IT employees of customer will do acceptance testing at customer place.
We may forget some of the business scenarios to test and those scenarios would be tested by
the customer
Note:
if the customer finds the defect during the acceptance testing. That is a negative path to the
test engineers.
So before finding the any defect we should think all those business scenarios and finds
defects.
Alpha testing and Beta testing are types of acceptance testing
Difference between alpha and beta testing

Alpha testing Beta testing

Alpha testing is performed by tester who are Beta testing is performed by the client or
usually an internal employee of an end users who are not an employee of an
organization. organization
Alpha testing is performed by the developer Beta testing is performed at the client
site location or end user of product
Reliability and security testing are not Reliability and security and robustness are
performed in depth alpha testing checked during beta testing
Alpha testing involved both black box and Beta testing typically uses black box testing
white box testing techniques Techniques
Alpha testing requires lab environment or Beta testing doesn’t require lab environment
testing environment or testing environment because software is
available for end users and is said to be real
time environment
 MANUAL TESTING

Long execution cycle may require for alpha Only few weeks execution are required for
testing beta testing
Critical issues or fix are addressed by Most of the issues or feedback are collected
developers immediately in alpha testing from beta testing will be implemented in
feature version of the product
Alpha testing ensures the quality of the Beta testing also concentrate on the quality
product before moving to the beta testing of the product but gathers user impact on
the product and ensures that the product is
ready for real time environment.
Virtual environment Real time environment
Off shore On site
Alpha testing is done under controlled Beta testing is done under uncontrolled
environment environment

Approach no 2: employees or test engineer of customer will do acceptance testing at

customer place.
Approach no 3: test engineers of software company will do acceptance testing at customer
place.
Approach no 4: test engineer or BA of software company will do acceptance testing under the
control of customer at developer place.
Hot fix / incident management system
When the software company releases the product to customer if the customer finds any
defects in the software. The customer will send the application back to the software company,
and software company should fix the defect as early as possible and give back to the
customer. This situation is called hotfix.
If any problem is find by the customer or end user in the production server, it will be raised as
the incident to the software company. Every incident is raised in the form of ticket and every
ticket will have a priority.
The commitment between software company and customer is called service level agreement.
Fish bone diagram

Root cause for defect

PM TL

Production
issues

BA TE DEV
Whenever there is a production issue all the team members will gather together, and they
discuss about reason for production issues that is documented in the form of fish bone
diagram. The main purpose of this is to find the root cause of the production house.
 MANUAL TESTING

SHORT TERM RELEASE/INTERIM RELEASE

Between two planned release of the application some times the customer gives a unplanned
release which is done in short duration. It is called short term release.
REAL TIME PROJECT (OR) HOW ARE THE SERVERS USED
Usually we have 3 servers like development server, testing/ QA server, production server.
Customer gives the requirement then the developer start writing the source code for
developing the application in the local system, this source code will be saved in the
repository(github,vlt.cvt), there white box testing will be done by developer. The source
code will be compiled and compressed, then we will be getting a file called build. All this
will be happened in developer server.
The build has to be installed from development server to testing server. It will be done by the
installation team or testing team.
Depending upon project to project
Once build is installed to the testing server testing team will perform different type of testing
depending upon the content of the build ex. For new features, FT, IT, will be done for old
features regression testing. for defect fixes retesting will be done.
While doing the testing we find the defects that will be raised to the developers. Development
team will reproduce the defect and they will fix it in the local system and it is saved in the
repository again. Same process will be repeated for every build, until we get the final stable
build.
Once the testing is completed, we will give the application to the customer for acceptance
testing. Customer will do acceptance testing in the testing server or customer will have their
own server called user acceptance testing server (UAT Server).
Once everything is fine application is released to end users that is for production server. This
is called production release.
What is release?
Starting from gathering the requirement, developing the application, testing the application,
finally releasing it to the end users is called release.
That is called production release.
What is a build?
The compiled and compressed format of source code is called build.
A build contains different formats like compress and archive.
Compress format:
1. Zip
2. Multiple lives can be made in single file.
3. Size of the file will be reduced.
 MANUAL TESTING

Archive format
1. Jar (java archive), war (web archive), tar (tape archive).
2. Multiple files are made in a single file.
3. Size of the file will be almost same.
What does build contain?
A build contains
1. New features
2. Old features
3. Defect fixes
It depends upon the contents which developer will add inside an build, and it varies from
build to build.
What is test cycle?
It is effort or time spent to test the application once the build is given. The duration of each
test cycle can be days, weeks, months, depending upon the build
Retesting and regression testing with respect to build
application

release 1 release 2 release 3

build1 build2 build1 build2 Build build1 build2 Build

Build
no 3 no 3
no 3

initial builds final stable builds

Application will be having multiple release.
Release can have multiple builds.
The final stable build will be released to production server.
The first release of first build1 we cannot do retesting and regression testing, for other builds
we can do retesting and retesting based on the situations.
 MANUAL TESTING

TEST STRATEGY
Test strategy is the approach to test the software application
Test plan
based on that approach we decide one approach and we plan based on that
how do you a define a format of good test case?
A good test case should have the header, body and footer sections.
It should contain the attributes which are easily understandable.
Ex in body section it should contain
1. Step no
2. Description
3. Input
4. Expected result
5. Actual result
6. Status
7. Comments
If the test case contains all the possible scenarios that can be called good test case.
What is a good test case?
a good test case is a test case which is easily understandable to every test engineer.
It should cover all the scenarios with respect to requirement.
A good test case should be written by applying like boundary value analyses, equivalence
partitioning, error guessing.
A test cases has to be reviewed by another test engineer and find mistakes in it. Those
mistakes have to be corrected then it becomes a good test case.
What would you do if you have a large suite and execute it in very less time?
First, we have to execute the basis features of an application that is smoke testing.
Difference b/w functional and non-functional testing?
Functional testing Non-functional testing
Functional testing Performance testing
Integration testing Compatibility testing
System testing Globalization testing
Security testing
Accessibility testing
Usability testing
Checking for single users Checking for multiple users
1. Multiple platforms
2. Multiple languages
 MANUAL TESTING

What is negative testing?

Testing the invalid or unexpected data then it is called negative testing.
How do you ensure that the testing having the good coverage?
We prepare RTM document.
Apply test case technique.
SMOKE TESTING (OR) BUILD VERIFICATION TESTING (OR) CONFIDENECE
TESTING
it is testing the basic feature of an application before we do through testing like functional,
integration, system testing.
Why we do smoke testing?
Test engineer will get confidence on basic features, that is working fine
If we find the defect in the basic features only, that create a good impact on the testing team
If there are any blocker or critical defect found in the basic features, developer will get more
time to fix the defect.
When we do smoke testing?
Once the build is given by the developer, we start doing smoke testing first.
For every build given by the developer we start with smoke testing first we assure basic
feature are working fine.
When time is less for testing team to do the testing, we will do smoke testing and if the
customer is fine, we will release to customer.
Difference b/w formal and informal smoke testing?

Formal smoke testing Informal smoke testing

It is a document type It is not a document type
We have a proof There is a proof
It has a procedure There is no proper procedure

Difference b/w smoke testing and sanity testing

Smoke testing Sanity testing
It is testing the basic features only It is testing the new features and bug fixes
It is shallow and wide testing It is narrow and deep testing
It is done on the unstable builds It is done on the stable builds
Only positive testing is done Both positive testing and negative testing are
done

It is the subset of regression testing.

 MANUAL TESTING

ADHOC TESTING (OR) MONKEY TESTING (OR) GORILLA TESTING

Testing the application randomly without following any formal documents like requirement,
test cases etc.
Why we do adhoc testing?
An application can be used different set of people or end users like
1. Children
2. A person with happy mode
3. A person with depressed mode.
4. A drunken person
When we are not able to get the defect through over regular testing like FT, IT, ST we can
think about adhoc testing so that we can get more defect.
This is the best testing for gaming application. Because while playing games usually children
will click where ever they want without their knowledge.
This testing is mandatory for gaming applications, for other applications we will do testing
based on customer request.
When we are not getting much defects with functional integration and system testing think
about adhoc testing we will get definitely defects.
All the defects we found through adhoc testing need not to be fixed by the developer unless
it is crashing the applications.

PERFORMANCE TESTING OR SCALABILITY TESTING

Testing the response time of an application by applying load for an application is known as
performance testing.
Load: number of users who uses the application.
Response time: time taken to get the expected screen based on the user actions.
Types of performance testing
Load testing:
Testing the response time of an application by applying the load which is less than or equal to
designed number of users. (it will be given by customer).
Ex: if the customer want application for 1 lakh users then the designed number of users are 1
lakh.
Stress testing:
Testing the response time of an application by applying the load which is greater then
designed no of users, that can be around 10-20% greater than the load.
Req-100000 users ------response time 2sec
Stress testing 110000 users --------- response time 2sec
 MANUAL TESTING

Can we do performance testing manually?

Yes, we can do performance testing manually but there are some drawbacks likes
1. Too much cost will be involved because of multiple human resource and multiple
devices, a huge place for gathering everybody.
2. There will be no accuracy in the results, we human beings we do not perform all the
actions at same time because of this result may vary.
So we go for automation
Volume testing
Testing the response time of an application by applying transferring huge volume of data
through application.
Ex data sharing through share it, Bluetooth, google drive by uploading more photos.
Sock testing
Testing the response time of an application by applying load continuously for some duration
of time
Ex 72 hrs users are using application continuously to check the response time

RELIABILITY TESTING
Testing the functionality of an application continuously for some duration of time. This can
be done by single users
Ex: mobile should work properly with one user.
Standalone applications: it does not depend on the server. It is installed separately
Ex calculator, calendar, word.
Client server application: using an application by server by using internet connection.
Web applications: fully depends on internet connection.
Ex. Chrome---gmail--- facebook
TYPES OF APPLICATIONS
Generally, we have three types of application
1. Standalone applications
2. Client server application
3. Web applications
Standalone applications:
This kind of applications can be installed, accessed and used without any dependency on
server or internet.
Ex notepad, calculator, word, calendar.
 MANUAL TESTING

This is the fastest applications with respect to response time.

Client server applications:
In this case we have software in two categories.
1. Client software
2. Server software
Client software will be installed by the end users usually from play store.
Server software will be available at the company location.
To use client software to interacting with each other, we need server software. To connect to
the server software, we need internet.
In client server application static elements will be already stored in the mobile , only dynamic
elements will be accessed through the internet.
This is the fastest compared to the web application and slower compared to standalone
application.
Ex whatsapp, facebook, gmail, redbus app.
Web application:
In this we access the application through the browser. Here static and dynamic element will
load together.
Ex: we can access gmail or fb any other application by entering the url into the browser.
We need internet connection compulsory.
Here the browser will act as client.

COMPATIBILITY TESTING
Testing the applications with different hardware and software platforms is called
compatibility testing.
Why do we do compatibility testing?
To ensure that application is working for multiple platforms because there might be different
types of users.
To check weather the application is working in all platforms.

GLOBALIZATION TESTING
Testing an application to which is developed for multiple languages is globalization testing.
When the language is changed the translated content is not proper because a machine
translator could not understand the exact meaning of the word displayed because of below
reasons
1. Machine does not have feeling
2. It cannot understand meaning.
 MANUAL TESTING

3. It cannot understand grammar.

4. It cannot understand spelling.
All this are reason for wrong translation. So, we go for human translator.
If a person is very good with multiple languages local and international, we could perform
good globalization testing.
Types of globalization testing
1. I18N: internationalization
2. L10N: localization
Internationalization
Testing the application weather, it displays the right content at the right place in the right
language is called I18N.
Localization
Testing the application with respect to the local culture or local standard to that country or
state or region is localization testing.

ACCESSIBILITY TESTING
Testing whether the application is suitable for physically challenged people or not
Ex RGB (red green blue) should not be used in the application.
Every feature or component in an application should be accessed by mouse and also by
keyboard.
RGB color blind will not be able to view that.
Music and keyword: anybody is injured wrist they can still use the application using the
keyboard.
Tools used for accessibility testing
1. In focus
2. Wave

RECOVERY TESTING
Testing the application weather, it is able to recover from crash state.

AESTHETIC TESTING:
Testing the beauty of an application is called aesthetic testing.
 MANUAL TESTING

USABILITY TESTING
Testing the application, it is user friendly or not
Why should we do usability testing?
1. End users is the best
2. Customer or client 2nd best.
3. Others project team members.
4. Nobody is there, test engineer has to do usability testing.
Test strategy:
Strategy is an approach to do any type of task.

TEST PLAN:
Test plan is a document which is prepared for future testing activities.
It is usually prepared by the test lead or manager.
Test engineer can also involve – if there is any support needed for test lead or manager.
Test plan contain different sections or attributes like
1. Objective: this section tells about the purpose of preparing the test plan.
2. Scope: limitations
This section will tell about
Future what to be tested.
Future what not to be tested.
3. Schedule and milestone:
This section will tell which activity has to done first and which activity has to done
next.
It is just like a time table of the project.
4. Entry and exit: this section tells about when to enter and when to exit each type of
testing.
5. Defect tracking: this section will tell about whenever a defect is found how to track
the defect and which is the tool, we are using to track the defect. And what are the
terminologies we are using to raise the defect.
6. Assumptions: this section will tell about what are the assumptions we have during
this project.
7. Risk: this section will tell about what are the possible risk happen during the project.
The possible risks are team members will quit the job suddenly and abscond.
8. Contiguity plan or mitigation plan: this section will tell about how to over come the
risk which occurs during the process.
to avoid this regular knowledge transfer or cross sections should happen inside the
company.
Roles and responsibilities of test engineer
This section will contain what are the roles and responsibilities for team members.
Ex roles and responsibilities for test engineers.
 MANUAL TESTING

Going through the requirement and understanding the requirement and identifying the
scenarios and writing the test cases, prepare RTM, and execute test cases when the
build is given, find the defect and raise the defects.
For automation test engineer:
We should perform above task plus we should write test scripts and execute test
scripts by using the selenium tool. Manage test script.
Environment: this section contains what is a platform we are using for testing
purpose ex. Window 10,8,7 chrome browser,
Deliverables: this section will tell what are the documents that should be prepared for
the project ex test plan, RTM, source code, defect, reports etc.
Graphs and matrices: this section contains the graphs and matrices that are prepared
for project.

RTM (REQUIREMENT TRACEABILITY MATRIX)

It is a document which is prepared to test that every requirement having at least one
test case or not.
Mapping from requirement to test case to automation test script to defect. This is
called forward traceability matrix.
Mapping from defect to automation test script to test case to requirement this is called
backward traceability matrix.
Mapping from test case to requirement and test case to automation test script to defect
this is bidirectional traceability matrix.
Mapping from test case to automation test script to defect can be traceability matrix.

Mobile compatibility testing:

When we test an application for different operating system and for each as for
different versions like kitkat windows ios, and for each brand of mobile (Samsung,
redmi, nokia) for different models.
What kind of bugs we find computability testing?
1. Look and feel change (whats app color green and white to blue and black)
2. Object overlapping (conform and cancel button sitting on one another)
3. Certain images will not displayed in certain browsers
4. Scroll bar issues
5. Alignment problems
6. Scattered content
7. Certain buttons, links and components may work in one browser and may not work in
another browsers

FUNCTIONAL TESTING
Testing the each and every component individually with respect to requirement thoroughly is
called functional testing.
 MANUAL TESTING

INTEGRATION TESTING:
Testing the data flow between two or more dependent modules is called integration testing.

SYSTEM TESTING:
Testing the application end to end like a real user is called system testing.
Defect seeding:
Injecting the defect in the application by developer to check the efficiency of test engineer is
called defect seeding.
This is done based on the request of manager.
Defect masking:
Whenever one defect is hiding another defect that is defect masking.
Defect leakage:
The defect which is not found by the testing team but it is found by the customer or end users
it is called defect leakage.
For a good testing team defect leakage percentage should be 0%.
Defect triage meetings
Manager arranges a meeting with all the development team and testing team discuss about the
existing defects which are not fixed because the defect age should not be increased and defect
status should be moved for further level until the defect status is closed. The meeting is
known as defect triage meeting. it is the main part of agile meeting.
Defect density:
Dd=number of defects/ total size of the project
Number of defects means the defect which are considered as valid defect not all the reported
defect.
 MANUAL TESTING

ISTQB
International software testing qualification board
It is a certification for software testing engineers.

ISTQB

Static testing Dynamic

testing

Review
Walk through
inception

White box Black box

technique technique

boundary value analysis statement coverage

equivalence partitioning branch coverage
error guessing path coverage
decision table cyclometric complexity
state transition diagram
use cases
STATIC TESTING:
testing which is performed on the document is called static testing.
there is no execution here.
types of static testing:
Review:
Finding the mistakes in the document is called review.
In review we have types
1. Self-review: review done by ourselves
2. Peer to peer review: review done by others
3. Manager review: review done by managers
 MANUAL TESTING

Walk through:
Explaining about the document to the set of people who are not aware of that.
Inception:
It is the kind of auditing process which is done on the documents for a software company.
IOS: international organization standardization.
It is for hardware.
CMMI: capability maturity model integration.
It has five levels CMMI 1, CMMI 2, CMMI 3, CMMI 4, CMMI 5.
Highest level is CMMI5
SEI: software engineer institute
CMMI is the recognition given by SEI
DYNAMIC TESTING:
Testing which is done on the application is called dynamic testing, that is on source code or
user interface of an application
Here in this testing and execution take place.
Black box testing techniques
Boundary value analysis:
Testing the boundaries of the certain components or element present on web page is called
boundary value analysis
Ex testing on text field which accepts only 3-10 characters.
Equivalence partitioning:
It is the technique where we come up with given range of requirement. Here it contains one
valid and two invalid data.
Error guessing:
It is the technique where we come with all the possible errors is known as error guessing
Without requirement we cannot do requirement.
Decision table:
It is the table which helps us to decide how many numbers of test cases are needed for a
given set of requirements.
The formula for this is 2^n= no of test cases or scenarios.
Where n is number of conditions or components
 MANUAL TESTING

State transition diagram:

It is a technique which is used to come up with the flow of an application in a easy manner.
This can be used in system testing and integration testing.
For atm machine this diagram helps a lot.
Use cases:
Use case testing is the functional black box testing technique that helps us testers to identify
the scenarios that excises whole system on each transition basis from start to finish.
Characteristics of use case testing
Use case can capture interaction between actor and system.
Actors represent user and interaction is that each user take part into.
Test cases based on use cases and are referred as scenarios.
Capability to identify the gaps in the system which would not find by testing individual
components is isolation.
Very effective in defining the scope of acceptance testing.
White box testing techniques:
Path testing: testing all the independent paths in a program is called path testing.
100% statement coverage is not equal to 100% branch coverage is not equal to path
coverage.
100% branch coverage is not equal to 100% statement coverage.
100% path coverage is equal to 100% branch coverage + 100% statement coverage
Cyclometric complexity
It is a technique which is mainly used to reduce the complexity in the source code.
If the source code is complex then testing also become complex.
Formula1: (e-n) +2
Formula 2: number of predicate nodes+1
Formula3: number of regions + 1
Formula 4: number of paths
Conditional testing:
Testing all the conditional statements like if, else, switch to, is called conditional testing.
Loop testing:
Testing all the looping statement like for, while, do while is called looping testing.
 MANUAL TESTING

RETESTING
Testing the defect fixed or bug fixed of an application is called retesting.

REGRESSION TESTING
Testing the impact areas of an application after
1. After the defect fixed.
2. After changes done in application.
Changes can be adding modifying and deleting a feature.
Why we do regression testing?
To make sure that existing features are still working properly after the changes is done in the
application or whenever a defect is fixed for an application.
When do we do regression testing?
1. After the defect fixed.
2. After changes done in application.
Changes can be adding modifying and deleting a feature.
How do we do regression testing?
Test engineer will write test case manually the test cases which has been executed again and
again will be categorized and a separate document will be maintained as regression test cases
Whenever we have to do regression testing, we will start testing by using the test cases.
Since the regression testing is repetitive in nature better, we will always go for automation
testing.
IN AUTOMATION REGRESSION TESTING TYPES:
Full execution:
Executing all the test scripts is called full execution.
Batch execution:
Executing the partially test scripts is called batch execution.
Types of regression testing
Unit regression testing:
Whenever a new feature is added for executing a module and the impact is only for that
particular module, we can also call it as unit.
When we do regression testing for that unit, we do not do regression testing for any other unit
that is called unit regression testing.
 MANUAL TESTING

Regional regression testing:

Whenever there is a change in the one module and that module is having dependency with
other few modules not all the modules, then we do regression testing for all the dependence
modules we call them as regional regression testing.
Full regression testing:
Whenever there is any change in the application and because of that change if we have an
impact on the whole application then we do complete testing again for whole application.
This is called full regression testing.
Difference between QC and QA
Quality analysis Quality control
it is a process oriented it is a product oriented
it is a verification process It is a validation process
it is a preventive method it is a detective method
Here we check “are we developing product Here we check “are we developing right
right” product”

It involves only static testing It includes dynamic testing

INTEGRATION TESTING
Testing the data flow between two or more dependent modules is called integration testing.
Ex in gmail if we send a mail the sent mail should be displayed in sent items checking
whether it there in sent items or not is a integration testing.
Types of integration testing
Integration testing

Incremental testing non incremental integration testing

Top down bottom up

P C2

p--parent
C1 C1
c—child

C2 P
 MANUAL TESTING

incremental integration testing:

whenever parent module is there child module is added, child module is there parent module
is added by preforming the integration testing between there modules is called integration
testing.
Non incremental integration testing:
Whenever we cannot find which is a child and which is a parent even then we find the
integration testing between them is called non incremental integration testing.
Stubs and drivers
Or one module is ready another module is not ready
How can we do integration testing by using stubs and drivers?
Stubs:
It is a dummy module which acts like a child module
Whenever there are no child module available stubs will receive the data and acknowledges
it.
Drivers:
It is a dummy module which acts like a parent module
Drivers will send or trigger data and send data to child module
Stubs and drivers are mainly used in critical projects related to space, medical, Submarines,
defense etc.