Manual Testing

Manual Testing

Page #
Manual Testing

1. Introduction to Software Testing

1.1 What is Software Testing

“Software testing is a process of executing the application with the

intent of finding the defects by comparing the output behavior of the
application with expected behavior (requirement).”

In other words it’s comparing the actual behavior of an application with expected
behavior.

1.2 Why Software Testing

Humans make mistakes all the time!!

“Software testing is really required to point out the defects and errors
that were made during the development phases”.

We humans can’t identify our mistakes in a work done by us. We should get
someone else to check our work because another person may identify the
mistakes done by us. In the same way software developers may not
identify the mismatches in a program or application implemented by them
which can be identify by the another department called Software Test
Engineer.

1.3 Benefits of Software Testing

“Software testing helps in finalizing the software application against business

Page #
Manual Testing
requirements.”

Software testing makes sure that the testing is being done properly and
hence the system is ready for the customers to use.

Below are few benefits of software testing.

- Finding the defects before delivery

- Gaines the confidence about quality
- To Prevent defects
- Ensure the requirements are delivered to client

1.4 What is Quality

“Software quality is nothing but delivering a bug free application

and delivered on time with all requirements.”

ISO 8402-1986 standard defines quality as “the totality of features and

characteristics of a product or service that bears its ability to satisfy stated
or implied needs.”

1.5 What is defect

“A defect is a deviation or mismatch from the requirements”.

When actual result deviates from the expected result while testing a
software application or product then it results into a defect. Hence, any
deviation from the specification mentioned in the functional
specification document is a defect. In different organizations it’s called

Page #
Manual Testing
differently like bug, issue, incidents or problem.

1.6 Project Vs. Product

“Project is developed for a single customer on his own requirements by

the software companies and the project will be used by the customer
only.”

“Product is developed for multiple customers on their consolidated

requirements by the software companies and the product will be used
by all customers.”

Page #
Manual Testing

2. Software Development Life Cycle (SDLC)

2.1 What is Software Development Life Cycle

“SDLC is a process followed for a software project, within a software

organization. It consists of a detailed plan describing how to develop,
maintain, replace and alter or enhance specific software”

2.2 Why Software Development Life Cycle

“SDLC ensure success in process of software development.”

2.3 Phases of Software Development Life Cycle

 Initial
 Analysis
 Design
 Coding
 Testing

 Delivery & Maintenance

2.3.1Initial

“Business requirements are gathered in this phase. “

This phase is the main focus of the project managers and stake holders.
Meetings with managers, stake holders and users are held in order to

Page #
Manual Testing
determine the requirements like;

- Who is going to use the system?

- How will they use the system?
- What data should be input into the system?
- What data should be output by the system?

Roles Involved: Business Analyst (BA), System Architects

Outcome: System Requirement Specification (SRS)

2.3.2 Analysis

“After requirement gathering these requirements are analyzed for their

validity and the possibility of developing the requirements in the
system.”

Requirement analysis is the most important and fundamental stage in

SDLC. It is performed by both development team and testing team.

Roles Involved: Dev & QA team, Architects, Project Managers

Outcome: Final SRS approved by customer, Technology selection for both Dev & QA

2.3.3 Design

“During this part of the design phase, the consultants/architects break down
the system into pieces that can be programmed.”

System Design helps in specifying hardware and system requirements and also
helps in defining overall system architecture. The system design

Page #
Manual Testing
specifications serve as input for the next phase of the model.

Roles Involved: Architects & Team

Page #
Outcome: Technical Design Document (TDD)

2.3.4 Coding

“The actual development starts and the product is built in coding phase. “

The work is divided in modules/units and actual coding is started in this

coding phase and it is the main focus for developer. Coding is one of
the longest phase of SDLC.

Roles involved: Developers and Architects

Outcome: Programs or Application or Module

2.3.5Testing

“In Testing phase testers execute the test cases against the application, report
the defects and retested the fixed defects. “

During this phase unit testing, integration testing, system testing, acceptance testing
are done.

Roles Involved: Testers, Developers

Outcome: Defects, Test Summary Report, Test Plan, Test Case document
2.3.6 Delivery & Maintenance

“Delivery: After successful testing the product is delivered / deployed to the

c During the Delivery phase, customer will perform user acceptance testing
(UAT) in a real time environment.
Once when the customers starts using the developed system then the
actual problems comes up and needs to be solved from time to time. This
process where the care is taken for the developed product is known as
maintenance.

Roles Involved: Testers, Developers, Customer, Business team, Architects, Project

Manager, and Delivery Manager

Outcome: Quality Product, Enhancements &Production Issues (Maintenance)

3. Software Development Life Cycle (SDLC) Models

“There are many development models life that have cycle been
developed in order to achieve different required objectives.”
The selection of model has very high impact on the testing that is
carried out. It will define the what, where and when of our planned
testing, influence regression testing and largely determines which test
techniques to use.

3.1 Water Fall Model

“Inawaterfall model, each phase must be completed fully before the
next phase can The Waterfall Model was first Process Model to be
introduced. It is also referred to as a linear-sequential life cycle
Model. It is very simple to understand and use. This type of model is
basically used for the project which is small and there are no uncertain
requirements.
 Advantages of waterfall model:

- This model is simple and easy to understand and use.

- It is easy to manage due to the rigidity of the model

- In this model phases are processed and completed one at a time.

Disadvantages of waterfall model:

- Once an application is in the testing stage, it is very difficult to go back and

change
- No working software is produced until late during the life cycle.
- High amounts of risk

- Not a good model for complex and object-oriented projects.

- Poor model for long and ongoing projects.

When to use the waterfall model:

- This model is used only when the requirements are very well known, clear and
fixed.
- The project is short.

3.2 V Model
 “The – V model is a SDLC model where execution of processes happens in a sequential
manner in V-shape. “

V-Shaped life cycle is a sequential path of execution of processes. Each

phase must be completed before the next phase begins. Testing of the
product is planned in parallel with a corresponding phase of
development.

Advantages of V-model:
- Simple and easy to use.
- Testing activities like planning, test designing happens well before coding. This
saves a lot of time.
- Proactive defect tracking – that is defects are found at early stage.

Disadvantages of V-model:

- Software is developed during the implementation phase, so no early

prototypes of the software are produced.
- If any changes happen in midway, then the test documents along with
requirement documents has to be updated.

When to use the V-model:

- The V-shaped model should be used for small to medium sized projects where
requirements are clearly defined and fixed.
The V-Shaped model should be chosen when ample technical resources are available
with needed technical expertise.

3.3 Prototype Model

 “Prototyping is an attractive placated and idea large systems for com for
which there is no manual process or existing system to help determining
the requirements.”

Advantages of Prototype model:

Users are actively involved in the development

Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed.

- Errors can be detected much earlier.

- Quicker user feedback is available leading to better solutions.
- Missing functionality can be identified easily
- Confusing or difficult functions can be identified

Disadvantages of Prototype model:

Practically, this methodology may increase the complexity of the system as scope of the system
may expand beyond original plans.
Incomplete application may cause application not to be used as thefull system was designed

When to use Prototype model:

Prototype model should be used when the desired system needs to have a lot of interaction with the end users.

3.4 Agile Model

“Software is developed in incremental,
rapidsmallincrementalcyclesreleases.Thiswith resultseachrelease in building
on previous functionality.”
Manual Testing

Page #
Manual Testing

Advantages of Agile model:

- Customer satisfaction by continuous delivery of software.

- Customers, developers and testers constantly interact with each other.
- Working software is delivered frequently

- Continuous attention to technical excellence and good design.

- Even late changes in requirements are welcomed

Disadvantages of Agile model:

- It is difficult to assess the effort required at the beginning of the software

development life cycle.

outcome that they want.

- The project can easily get taken off track if the customer representative is not
clear what final
- Only senior programmers are capable of taking the kind
of decisions required during the development process.

When to use Agile model:

- New changes can be implemented at very little cost

- To implement a new feature the developers need to lose only the work of a few
days.
- Unlike the waterfall model in agile model very limited planning is required to
get started with the project.

Page #
 Manual Testing

4. Software Testing Methodologies

4.1 Block Box Testing

4.1.1 What is Block box testing

i “Thetechnique oftesting without having technical knowledge ofan application

-based testing technique is also known as „black-box‟or input/output driven testing techniques because they view the software as a black-box with inputs a

will perform block box testing

“Testing teamwill perform theblockboxtesting”

inside the box. In black-box testing the tester is concentrating on what the software does, not how it does it.

l testing is concerned with what the system does its features or functions. Non-functional testing is concerned with examining how well the system does. No

Advantages Disadvantages

Well suited and efficient for large code segments. Limited Coverage since only a selected number of test scenarios are actually perform

Code Access not required. Inefficient testing, due to the fact that the tester only has limited knowledge about an a
Blind Coverage, since the tester cannot target specific code segments or error prone
The test cases are difficult to design.
Clearly separates user's perspective from the developer's
ve through visibly defined roles.

mbers of moderately skilled testers can test the application with no knowledge of implementation, programming
or operating systems.

Website:www.testingmasters.com
Email:[email protected]
Page # 9
Manual Testing

4.1.4 Block box testing techniques

Website:www.testingmasters.com
Email:[email protected]
Page #
Below is the black box testing techniques:

- Equivalence partitioning
- Boundary value analysis
- Error Guessing

4.2 White box testing

4.2.1What is white box testing

“Structure-based testing technique is also known as „white-box‟ or „glass-box‟ testing

technique because here testers require knowledge of how the software is implemented,
how it works “

4.2.2Who will perform White box testing

“Developers use -basedstructuretechniques in component testing and

component integration testing, especially where there is good tool
support for code coverage.”

4.2.3How to perform White box testing

White box testing is the detailed investigation of internal logic and

structure of the code. White box testing is alsocalled g lass testing or
Openbox testing.

Advantages Disadvantages
As the tester has knowledge of the
source code, it becomes very easy to Due to the fact that a skilled tester is
find out which type of data can help in needed to perform white box testing, the
testing the application effectively. costs are increased.

It helps in optimizing the code. Sometimes it is impossible to look into

every nook and corner to find out hidden
Extra lines of code can be removed errors that may create problems as many
which can bring in hidden defects. paths

will go untested.
Due to the tester's knowledge about the
It is difficult to maintain white box
code, maximum coverage is attained
testing as the use of specialized tools
during test scenario writing.
like code analyzers and debugging tools
are required.

4.3 Grey Box testing

4.3.1What is grey box testing

“Grey Box testing is a techniqueapplication

withtolimitedtestknowledgethe of the internal working of an
application.”

4.3.2Who will perform Grey box testing

 “Unlike blacktesting,boxwhere the tester only tests the application's user
interface, in grey boxtesting, the tester has access to design documents and
the database. Having this knowledge, the tester is able to better prepare test
data and test scenarios when making the test plan.”

Advantages Disadvantages

nefits of black box and white box testing wherever possible.

source code is not available, the Grey box testers don't rely on the source code; insteadability to go over the code and test coverage is limited. theyrelyond
sts can be redundant if the software designer has already run a test case.
information available, a grey box
interface
on protocols and data type handling.it would take an unreasonable amount of time; therefore, many
ntested.
m the point of view of the user and not the designer.
tester can design excellent test scenarios especially Testing every possible input stream is unrealistic because

S.N. Black Box Testing Grey Box Testing White Box Testing
The Internal Workings of an Tester has full knowledge of
Somewhat knowledge of the internal
1 application are not required to be the Internal workings of the
workings are known
Black known
Box vs Grey Box vs White Box: application
 Manual Testing

, Another term
Also known for grey
as closed box testing is
box testing
data driven testing and functional testing
Also known as clear box testing, structural testing or code based testing

2 translucent testing asby testers and developers

Normally done

Performed by end users and also the tester hasInternal workings are fully known and the tester can design test data acc
by testers and developers
limited knowledge of the insides of the
Testing is based on external
expectations - Internal behavior o
application
the application is unknown

This is the least time consuming and exhaustive

Performed by end users and also byexhaustive and time
The most
consuming type of testing
3
Not suited to algorithm testing testers and developers
Suited for algorithm testing
Data domains and Internal boundaries can be better tested
This can only be done by trial and
error method Testing is done on the basis of high level
4 f database diagrams and data flow
diagrams

5 Partly time consuming and exhaustive

6 Not suited to algorithm testing

Data domains and Internal boundaries can

7 be tested, if known

5. Levels of testing

“In software development life cycle models there are defined phases like require

Website:www.testingmasters.com
Email:[email protected]
Page #
Manual Testing
coding or implementation, testing and deployment. Each phase goes through the
testing.”

Hence there are various levels of testing. The various levels of testing are:

5.1 Unit Testing

What is Unit testing:“A unit is the smallest testable part of an

applicatprocedures,ion like funct interfaces. “ Unit testing is a method
by which individual units of source code are tested to determine if they
are fit for use.
Who will perform Unit testing: “Unit tests are basically written and executedtomake
by software sure that code meets its design
and requirements and behaves as expected.”

5.2 Module/Component Testing

What is Module/Component Testing: “Component testing is a method where testing

of each c application is done separately.”

Suppose, in an application there are 5 components. Testing of each 5

components separately and efficiently is called as component testing.

Who will perform Component Testing:“Component testing is done by the tester.”

Website:www.testingmasters.com
Email:[email protected]
Page #
5.3 Integration Testing

What is Integration Testing: “Integrations donetestingwhentwoi

modules are integrated, in order to test the behavior and functionality
of both the modules after integration.”

As displayed in the image below when two different modules „Module A‟ and „Modul
integration testing is done.
ill perform Integration Testing:“Integration testing is done by a specific integration tester or test team.”

ation Testing Techniques:

wn
Up

own integration testing: Testing takes place from top to bottom, following the control flow or architectural. Components or systems are substituted by stub

s the diagram of „TopdownApp roach‟:

Bottom-up integration testing: Testing takes place from the bottom

of the control flow upwards. Components or systems are substituted by
drivers.

Below is the image of „Bottom up approach‟:

Stub: A stub is called from the software component to be tested.

Driver: A driver calls the component to be tested.

5.4 System Testing

What is system testing: “Once all the components are integrated, the application as a
wh see that it meets the requirements?”

System testing is most often the final test to verify that the system to be
delivered meets the specification and its purpose.
Who will do the system testing:
testing “System
is carried out by specialist testers or inde

5.5 User Acceptance Testing (UAT)

What is UAT: “Acceptance testing is basically done to ensurefth

specificationthattherequirementsaremet. ”o

- The goal of acceptance testing is to establish confidence in the system.

- Acceptance testing is most often focused on a validation type testing.

Who will perform UAT: “Acceptance testing is basically done by

the user or customer although other stakeholders may be involved
as well.”

Alpha Testing: “Alpha testing is done at thedeveloper‟s site. It is

do ne at the end

Beta testing: “Beta testing is done at the customers

site. It is done just before the
Manual Testing

6. Verification & Validation

6.1 Verification

6.1.1What is Verification: “The process of evaluating work-products (not the actual

final product) of a
development phase to determine whether they meet the specified
requirements

Verification is done at the starting of the development process. It

includes reviews and meetings, walkthroughs, inspection, etc. to
evaluate documents, plans, code, requirements and specifications.

Website:www.testingmasters.com
Email:[email protected]
Page #
Manual Testing

6.1.2Who will perform: Peers (Sr Team Members, Architects, Analysts)

6.1.3Verification Techniques:Below are the validation techniques

- Reviews
- Inspections
- Walk through

Reviews:“A review is a systematicexaminationof document by one or

more people with the main aim of finding and removing errors early in the
software development life cycle.”

There are two types of Reviews held in verification. They are Formal Review and
Informal Review.

a. Formal Review:“Formal reviews follow a formal process. It

is well structured and regulated. It contains: Planning, Kick-
off, Preparation, Review meeting, Rework. ”

b. Informal Review:“Informal reviews are applied many times during

the early stages of the life cycle of the document. A two person
team can conduct an informal review.” The most important thing to
keep in mind about the informal reviews is that they are not
documented.

Website:www.testingmasters.com
Email:[email protected]
Page #
Manual Testing
6.1.4Inspection:

“Inspection is the most formal form of reviews, a strategy adopted during static
testing phase.”

Website:www.testingmasters.com
Email:[email protected]
Page #
Manual Testing

- It is the most formal review type

- It is led by the trained moderators
- During inspection the documents are prepared and checked
thoroughly by the reviewers before the meeting

6.1.5Walkthrough

“A walkthrough is conducted by„documentheauthorunderof thereview‟

who takes the participants
document and his or her thought
processes, to achieve a common
understanding and to gather feedback.”

6.2 Validation

6.1.1 What is Validation: “The process of evaluating software

during or at the end of the development process to determine whether it
satisfies specified business requirements.”

6.1.2 Who will perform: Testing Team, Dev Team, Client or BA team

Criteria Verification Validation

To ensure that the product is To ensure that the product
being built according to the actually meets the user‟s needs,
Website:www.testingmasters.com
Email:[email protected]
Page #
Manual Testing
objective requirements and design and that the specifications were
specifications. In other correct in the first place. In
words, to ensure that work other words, to demonstrate
products meet their specified that the product fulfills its
requirements. intended use when placed in its
intended environment.
Question Are we building the product Are we building the right
right? product?
Evaluation Plans, Requirement Specs, The actual product/software.
Items Design Specs, Code, Test
Cases

Activities Reviews, Walkthroughs, Testing

Inspections

7. Functional & Non Functional Testing

Functional Testing: “Functional Testing is a testing technique that is used

to test the features/functionality of the Software”.

7.1 Smoke Testing:“Smoke testing refers to testing the basic functionality of the
bui declared as unstable and it is NOT tested anymore until the smoke test of the
build passes.

7.2 Sanity Testing:“Software testing technique performed by the test

team for some basic tests. The aim of basic test is to be conducted
whenever a new build is received for testing. “
Website:www.testingmasters.com
Email:[email protected]
Page #
Manual Testing

The terminologies such as Smoke Test or Build Verification Test or Basic

Acceptance Test or Sanity Test are interchangeably used, however,
each one of them is used under a slightly different scenario.

Sanity test is usually unscripted, helps to identify the dependent missing

functionalities. It is used to determine if the section of the application is still
working after a minor change.Sanity testing can be narrow and deep.
Sanity test is a narrow regression test that focuses on one or a few areas of
functionality

7.3 Re-testing: “Retesting is executing a previously failed test

against new software to check if the problem is resolved. “

7.4 Regression Testing: “Regression testing is performed to verify if the

build has NOT broken any other parts of the application by the recent code
changes for defect fixing or for enhancement. “

The purpose of a regression testing is to verify that modifications in the

software or the environment have not caused any unintended adverse
side effects and that the system still meets its requirements.

7.5 Exploratory Testing: “Testing of software without any documents (test cases or
test planning) and Identify the functionality of application by exploring the application
and exploring & learni

7.6 Monkey Testing: “Monkey testing is a software testing technique in which the testi

Website:www.testingmasters.com
Email:[email protected]
Page #
Manual Testing
system under test randomly. The Input data that is used to test also generated r

7.7 End to End Testing:“End-to-end testing is a methodology used to

test whether the flow of an application is performing as designed from
start to finish.”

The purpose of carrying out end-to-end tests is to identify system

dependencies and to ensure that the right information is passed
between various system components and systems.

Difference between System testing and End to End testing:

There isn't really a huge difference between the two and in some
establishments the terms could be used interchangeably. Everywhere is
different.

System testing: You're testing the whole system i.e. all of its components
to ensure that each is functioning as intended. This is more from a
functional side to check against requirements.

End to end testing: This is more about the actual flow through a system in a
more realistic end user scenario. Can a user navigate the application as
expected and does it work. You're testing the workflow.

Non Functional Testing:

7.8 User Interface Testing:“Graphical User Interface (GUI) testing is

checking the application design of an application”.
Website:www.testingmasters.com
Email:[email protected]
Page #
Manual Testing
Ex: Required/Optional, Fields Align, Lengths, Progress Bars, Scroll Bars, Alignments, etc

Website:www.testingmasters.com
Email:[email protected]
Page #
7.9 Usability Testing: “In usability testing basically the testers tests the
ease with which the user interfaces can be used. It tests that whether
the application is user-friendly or not. “

Usability Testing tests the following features of the software.

– How easy it is to use the software.

– How easy it is to learn the software.
– How convenient is the software to end user.

7.10 Stress Testing: “It is a form of testing that is used to determine

the stability of a given system, Stress testing involves testing beyond
normal operational capacity, often to a breaking point, in order to observe
the results. “

Stress testing is a generic term used to describe the process of putting a system through
stress.

7.11 Load Testing: “Load testing is performed to determine a system’s

behavior under both normal and at peak conditions. “

A load test is usually conducted to understand the behavior of the

application under a specific expected load.

E.g. If the number of users are in creased then how much CPU, memory
will be consumed, what is the network and bandwidth response time.

7.12 Performance Testing: “Performance testing is testing that is

performed, to determine how fast some aspect of a system performs
under a particular workload. “

It can serve different purposes like it can demonstrate that the system meets
performance criteria.

7.13 Localization Testing: “Localization translates the product UI and

occasionally changes some initial settings to make it suitable for another
region.” Localization testing checks the quality of a product's localization
for a particular target culture/locale.

The test effort during localization testing focuses on:

- Areas affected by localization, such as UI and content

- Culture/locale-specific, language-specific, and region-specific areas

7.14 Globalization Testing: “Globalization Testing is testing process to

check whether software can perform properly in any locale or culture &
functioning properly with all types of international inputs and steps to
effectively make your product truly global.”
This type of testing validates whether the application is capable for
using all over the world and to check whether the input accepts all the
language texts.

Ex: Let’s see another example of a Zip code field in Sign up form:

- For globalized, it should allow to enter alphanumeric inputs

- For localized (country like INDIA), it should allow only numbers in input field.

7.15 Security Testing: “Security testing is basically to check that

whether the application or the product is secured or not. “

Can anyone came tomorrow and hack the system or login the application
without any authorization. It is a process to determine that an information
system protects data and maintains functionality as intended.

Security testing is related to the security of data and the functionality of

the application. You should be aware of the following concepts while
performing security testing:

1. Confidentiality - The application should only provide the data to

the relevant party e.g. one customer's transactional data should not be
visible to another customer; the irrelevant personal details of the
customer should not be visible to the administrator and so on.

2. Integrity - The data stored and displayed by the application should be

correct e.g. after a withdrawal, the customer's account should be debited by
the correct amount.
3. Authentication - It should be possible to attribute the data transmitted
in the application to either the application or the customer. In other words,
no one other than the customer or the bank should be able to create or
modify any data.

4. Authorization - The application or a user should only be able to

perform the tasks which they are respectively authorized to perform e.g.
a customer should not be able to withdraw more than the balance in
their account without having an overdraft facility, the application should
not be able to levy charges on a customer account without prior
customer approval.

5. Availability - The data and functionality should be available to the

users throughout the working period e.g. if the bank's operating times are
from 8 a.m. to 8 p.m. on all working days, it should be possible for a
customer to access their account and make the necessary transactions on their
account.

6. Non-repudiation - At a later date, it should not be possible for a party

to deny that a particular transaction or data change took place e.g. if a
customer withdraws an amount from their account, this should trigger the
relevant actions (posting to their transaction records, debiting their
account and sending them a notification etc.).
7.16 Compatibility Testing: ”Compatibility Testing ensure
compatibility of the application built with various other objects such as
other web browsers, hardware platforms, operating systems etc.”

This type of testing helps find out how well a system performs in a
particular environment that includes hardware, network, operating
system and other software etc.

Ex: Browser Compatibility Testing, OS Compatibility Testing

7.17 Installation Testing: “Installation testing is performed to ensure

that all necessary components are installed properly and working as per
the requirements of the software, post installation. Installation process
may include partial, full or upgrade install. “

7.18 Recovery Testing: “Recovery testing is done in order

to check how fast and better the application can recover after it
has gone through any type of crash or failure“

Ex: For example, when an application is receiving data from a network,

unplug the connecting cable. After some time, plug the cable back in and
analyze the application’s ability to continue receiving data from the point
at which the network connection got disappeared. Restart the system
while a browser has a definite number of sessions and check whether the
browser is able to recover all of them or not.
8. Windows & Web Application

8.1 What is Windows application: “A program that is written to run

under Microsoft's Windows operating system. “

8.2 What is Web application: “Web application is an application that is

accessed via Web browser over a network such as the Internet or an
intranet. “

8.3 Difference between Windows & Web:

Windows Application:

a. Windows applications typically run under all 32-bit versions of

Windows, but earlier applications might also run under the 16-bit
versions (Windows 3.x) as well. b. Runs on personal computers
and work stations.
 c. Window based app. need to be installed on your machine to access.

d. Windows applications (desktop) need to be installed on each client's PC.

e. Windows application runs faster than Webapplication.

f.Windows application has many inbuilt classes in .Net compared to Web

application.

Web application:

a. It is a computer software application that is coded in a browser-

supported language (such as HTML, ASP, PHP, Perl, Python etc.) and
reliant on a common web browser to render the application
executable.
b. Web applications are very much useful when they are
hosted.Web app. can be access from any ware in the world
through the internet.
c. Web application is tested mainly for browser
compatibility and operating system compatibility, error
handling, static pages, back-end testing and load
testing.
e. Web applications are programs that used to run inside some
web server (e.g., IIS) to fulfill the user requests over the http.
f. Common Web applications include Webmail, online retail
sales, online auctions, wikis, discussion boards, Weblogs
Manual Testing

9. Software Testing Life Cycle (STLC)

Website:www.testingmasters.com
Email:[email protected]
Page #
Manual Testing
“STLC consists of series of activities carried out methodologically to help
certify your software product. These activities are part ofthe Software
Testing Life Cycle.”

The different stages in Software Test Life Cycle:

Website:www.testingmasters.com
Email:[email protected]
Page #
9.1 Requirement Analysis: “During this phase, test team studies the
requirements from a testing point of view to identify the testable
requirements.”

The QA team may interact with various stakeholders (Client, Business

Analyst, Technical Leads, and System Architects etc.) to understand the
requirements in detail. Requirements could be either Functional (defining
what the software must do) or Non Functional (defining system
performance
/security availability).
Deliverables:Requirement Traceability Matrix (RTM), Clarification Document

RTM: “Traceability matrix links a business requirement to its corresponding functional

requirement.”

If a Test Case fails, traceability helps determine the corresponding functionality

easily; it also helps ensure that all requirements are tested.

Sample RTM:
Clarification Document: “Contains all clarifications which will arise during
the requirement analysis phase”.

Sample:

Sno Date Module/Page Query Comments

Name Description

9.2 Test Planning:

What is Test plan: “Test planning is the first step of the testing
process. In this phase we identify the activities and resources which
would help to meet the testing objectives.”

What Test Plan contains: (IEEE 829 STANDARD TEST PLAN TEMPLATE)
Test plan
identifier Test
deliverables
Introduction
Test tasks
Test items
Environmental
needs Features
to be tested
Responsibilities
Features not to be
tested Staffing and
training needs
Approach Schedule
Item pass/fail
criteria Risks and
contingencies

Who will prepare the test plan: Test Lead or Test Manager.
Manual Testing

What is Test Strategy:“A Test Strategy document is a high level document

and normally developed by project manager. This document defines “Software
Testing Approach” to achieve testing objectives. The Test Strategy is normally
derived from the Business Requirement Specification document.”

Test plan Vs Test Strategy: Generally it doesn’t matter which comes first.
Test planning document is a combination of strategy plugged with overall
project plan. According to IEEE Standard 829-2008, strategy plan is a sub
item of test plan.

Every organization has their own standards and processes to maintain

these documents. Some organizations include strategy details in test
plan itself. Some organizations list strategy as a subsection in testing
plan but details is separated out in different test strategy document.

Ex:Test plan gives the information of who is going to test at what

time. For example: Module 1 is going to be tested by “X tester”. If
tester Y replaces X for some reason, the test plan has to be updated.

On the contrary, test strategy is going to have details like – “Individual

modules are to be tested by test team members. “ In this case, it does not
matter who is testing it- so it’s generic and the change in the team member
does not have to be updated, keeping it static.

Deliverables: Test Plan with estimation

9.3 Test Case Development: “During this phase the test cases will be prepared”.

Page #
26
Manual Testing

9.3.1 What is test case: “A test case is a set of conditions under which
a tester will determine whether a system under test satisfies requirements
or works correctly.”

Writing Good Test Cases:

 As far as possible, write test cases in such a way that you test
only one thing at a time. Do not overlap or complicate test cases.
Attempt to make your test cases ‘atomic’.
 Ensure that all positive scenarios and negative scenarios are covered.
 Language:
 Write in simple and easy to understand language.
 Use active voice: Do this, do that.
 Use exact and consistent names (of forms, fields, etc).
 Characteristics of a good test case:
 Accurate: Exacts the purpose.
 Economical: No unnecessary steps or words.
 Traceable: Capable of being traced to requirements.
 Repeatable: Can be used to perform the test over and over.

 Reusable: Can be reused if necessary.

9.3.2 Test Case Techniques:

 Equivalence Portioning (EP)

 Boundary Value Analysis (BVP)
 Error Guessing

Equivalence Portioning:“EP divides the input data of a software unit into

Page #
27
Manual Testing
partitions of equivalent data from which test cases can be derived.”

Test cases are designed to cover each partition at least once. This
technique tries to define test cases that uncover classes of errors, thereby
reducing the total number of test cases that must be developed. An
advantage of this approach is reduction in the time required for testing a
software due to lesser number of test cases.

Boundary Value Analysis:“Tests are designed to include representatives of boundary

values “

Error Guessing:“The Error guessing is a technique where the experienced

and good testers are encouraged to think of situations in which the
software may not be able to cope.”

The success of error guessing is very much dependent on the skill of the
tester, as good testers know where the defects are most likely to be. This is
why an error guessing approach, used after more formal techniques have
been applied to some extent, can be very effective.

9.3.3 Test Data Preparation

What is Test Data: “In order to test a software application you need to
enter some data for testing most of the features. Any such specifically
identified data which is used in tests is known as test data.”

Page #
28
Manual Testing
Test data preparation: In the above example we can generate the inputs for Valid and
Invalid partitions.

Ex:

Valid: 1, 2, 5, 10, 11, 12

Invalid: -2, -1, 0, 13, 15, 99, 150, 999

Page #
29
9.3.4 Types of test cases

Functional Test Cases: “The test cases based on functional requirement specifications”

Positive Test Cases: “Test Cases with valid input and also verifying that the outputs
are correct.”

Negative Test Cases:“This testing involves exercising application functionality

using a combination of invalid inputs, some unexpected operating conditions
and by some other “out-of-bounds” scenarios.”

Non Functional Test Cases:“The test cases based on functional

requirement specifications like performance, Load, Stress, Security, etc.”

9.3.5 Test Case Review: Reviewing is a form of testing too – the

verification part of the V&V, also called static testing.

Why Review: For exactly the same reason we test the software

 To uncover errors
 To check for completeness
 To make sure the standards and guidelines are followed

Review Checklist:

 Do test cases cover all requirements?

 Has each test case been assigned a test case identifier?
 Does each test case specify?
- Actions
 - Test condition
- Expected result
 Have the expected results been recorded in detail?
 Is any method for validating expected results specified?

 Do test cases for field validations, record validations and

database updates include the following?
- Valid conditions
- Invalid conditions
- Boundary or unusual conditions
 Do the test cases for reports include the test data along with the expected output?
 Have the inter test case dependencies been described?
 Have Pass/Fail criteria been specified?
  Have all requested environments been specified?
 Has the method for logging on to the test environment been specified?
 Are pre-conditions for the test specified?
 Is the number of Test cases met customer standards?

Self-Review: “Review our own work by us”

Peer Review: “Review our own work by colleague”

Lead Review: “Review our work by our Test lead or Manager”

Client Review: “Review our work by client or business team after lead review.”

Deliverables: Test Case Document, Test Data

9.4 Test Environment Setup

“Test environment decides the software and hardware conditions under

which a work product is tested. “

Test environment set-up is one of the critical aspects of testing process and
can be done in parallel with Test Case Development Stage. Test team may not
be involved in this activity if the customer or dev team provides the test
environment in which case the test team is required to do a readiness check
(smoke testing) of the given environment.

Deliverables: Test Environment

How many environments do we have: “A Typical project can have following

environments”

- Dev
- QA
 - Pre-Production
- Production

9.5 Test Execution

“In this phase testing team start executing test cases based on prepared test
planning & prepared test cases in the prior step in testing environment”.

Deliverables: Test cases updated with results

9.6 Result Analysis & Reporting:

“After test execution phase, if the test case is passed then same can be
marked as Passed. If any test case is failed then corresponding defect can
be reported to developer team via bug tracking system & bug can be
linked for corresponding test case for further analysis.”

Severity:It is the extent to which the defect can affect the software. In
other words it defines the impact that a given defect has on the
system.

If an application or web page crashes when a remote link is clicked, in this

case clicking the remote link by an user is rare but the impact of
application crashing is severe. So the severity is high but priority is low.

 Critical: The defect that results in the termination of the complete

system or one or more component of the system and causes extensive
corruption of the data. The failed function is unusable and there is no
acceptable alternative method to achieve the required results then the
severity will be stated as critical.

 Major: The defect that results in the termination of the complete

system or one or more component of the system and causes
extensive corruption of the data. The failed function is unusable but
there exists an acceptable alternative method to achieve the required
results then the severity will be stated as major.
  Medium: The defect that does not result in the termination, but
causes the system to produce incorrect, incomplete or inconsistent
results then the severity will be stated as moderate.

 Minor: The defect that does not result in the termination and does
not damage the usability of the system and the desired results can be
easily obtained by working around the defects then the severity is
stated as minor.

 Cosmetic: The defect that is related to the enhancement of the

system where the changes are related to the look and field of the
application then the severity is stated as cosmetic.

Priority: “Priority defines the order in which we should resolve a defect.

Should we fix it now, or can it wait?”
This priority status is set by the tester to the developer mentioning the time
frame to fix the defect. If high priority is mentioned then the developer has
to fix it at the earliest. The priority status is set based on the customer
requirements.

For example: If the company name is misspelled in the home page of

the website, then the priority is high and severity is low to fix it.

 Low: The defect is an irritant which should be repaired, but

repair can be deferred until after more serious defect has been
fixed.

 Medium: The defect should be resolved in the normal course of

development activities. It can wait until a new build or version is
created.

 High: The defect must be resolved as soon as possible because the

defect is affecting the application or the product severely. The system
cannot be used until the repair has been done.

Few very important scenarios related to the severity and priority which
are asked during the interview:

 High Priority & High Severity: An error which occurs on the basic
functionality of the application and will not allow the user to use the
system. (Eg. A site maintaining the student details, on saving record
if it, doesn’t allow to save the record then this is high priority and
high severity bug.)
  High Priority & Low Severity: The spelling mistakes that happens on
the cover page or heading or title of an application.

 High Severity & Low Priority: An error which occurs on the

functionality of the application (for which there is no workaround)
and will not allow the user to use the system but on click of link
which is rarely used by the end user.

 Low Priority and Low Severity: Any cosmetic or spelling issues which
is within a paragraph or in the report (Not on cover page, heading,
title).

Famous Defect Tracking Tools:

- Bugzilla
- JIRA
- ALM (QC)
A typical Defect Tracker will have:

- Defect id
- Date
- Created By
- Assigned TO
- Bug description
- Steps to Reproduce
- Expected Result
- Comments
- Screen shots

Defect Life Cycle:“Defect life cycle is a cycle which a defect goes through during its
lifetime. “

It starts when defect is found and ends when a defect is

closed, after ensuring it’s not reproduced. Defect life cycle is
related to the bug found during testing.

The Life cycle of the bug can be shown diagrammatically as follows:

 New: When a defect is logged and posted for the first time. It’s state is given as
new.

 Assigned: After the tester has posted the bug, the lead of the
tester approves that the bug is genuine and he assigns the bug to
corresponding developer and the developer team. It’s state given
as assigned.
 Open: At this state the developer has started analyzing and working on the defect
fix.
 Fixed: When developer makes necessary code changes and verifies
the changes then he/she can make bug status as ‘Fixed’ and the bug
is passed to testing team.

 Pending retest: After fixing the defect the developer has given that
particular code for retesting to the tester. Here the testing is pending
on the testers end. Hence its status is pending retest.

 Retest: At this stage the tester do the retesting of the changed code
which developer has given to him to check whether the defect got
fixed or not.

 Verified: The tester tests the bug again after it got fixed by the
developer. If the bug is not present in the software, he approves that
the bug is fixed and changes the status to “verified”.

 Reopen: If the bug still exists even after the bug is fixed by the
developer, the tester changes the status to “reopened”. The bug
goes through the life cycle once again.

 Closed: Once the bug is fixed, it is tested by the tester. If the tester
feels that the bug no longer exists in the software, he changes the
status of the bug to “closed”. This state means that the bug is fixed,
tested and approved.

 Duplicate: If the bug is repeated twice or the two bugs mention

the same concept of the bug, then one bug status is changed to
“duplicate“.

 Rejected: If the developer feels that the bug is not genuine, he

rejects the bug. Then the state of the bug is changed to “rejected”.
  Deferred: The bug, changed to deferred state means the bug is
expected to be fixed in next releases. The reasons for changing the
bug to this state have many factors. Some of them are priority of the
bug may be low, lack of time for the release or the bug may not have
major effect on the software.
 Not a bug: The state given as “Not a bug” if there is no change in
the functionality of the application. For an example: If customer
asks for some change in the look and field of the application like
change of color of some text then it is not a bug but just some
change in the
looks of the application.

9.7 Delivery & Maintenance

Evaluate cycle completion criteria based on Time,Test

overage,Cost,Software,Critical Business Objectives, Quality.

Typical Exit criteria may include the following:

 All Test plans have been run.

 A certain level of requirements coverage has been achieved.
 No high priority or severe bugs are left outstanding.
 All high-risk areas have been fully tested, with only minor residual risks left
outstanding.
  Cost – when the budget has been spent.
 The schedule has been achieved.

Maintenance: Once a system is deployed it is in service for years and

decades. During this time the system and its operational environment is
often corrected, changed or extended. Testing that is provided during this
phase is called maintenance testing.

Usually maintenance testing is consisting of two parts:

First one is, testing the changes that has been made because of the
correction in the system or if the system is extended or because of some
additional features added to it.

Second one is regression tests to prove that the rest of the system
has not been affected by the maintenance work.

Metrics:

A Metric is a quantitative measure of the degree to which a system,

system component, or process possesses a given attribute.

Metrics can be defined as “STANDARDS OF MEASUREMENT”.

Software Metrics are used to measure the quality of the project.

Simply, Metric is a unit used for describing an attribute. Metric is a
scale for measurement.
Suppose, in general, “Kilogram” is a metric for measuring the attribute
“Weight”. Similarly, in software, “How many issues are found in thousand
lines of code?”, here No. of issues is one measurement & No. of lines of
code is another measurement. Metric is defined from these two
measurements.

Test metrics example:

 How many defects are existed within the module?
 How many test cases are executed per person?
 What is the Test coverage %?

Why Test Metrics?

Generation of Software Test Metrics is the most important

responsibility of the Software Test Lead/Manager.

“We cannot improve what we

cannot measure.” “We cannot
control what we cannot measure”
  Take decision for next phase of activities
 Evidence of the claim or prediction
 Understand the type of improvement required
 Take decision on process or technology change

Effectiveness: Doing the right thing. It deals with meeting the desirable
attributes that are expected by the customer.

Efficiency: Doing the thing right. It concerns the resources used for the service to be
rendered

a. Test Plan coverage on Functionality:

Formula: (No of requirements covered / total number of requirements) * 100

b. Test Case defect density:

Formula: (Defective Test Scripts /Total Test Scripts) * 100

Example: Total test script developed 1360, total test script executed
1280, total test script passed 1065, total test script failed 215.

So, test case defect density is :215 X 100 / 1280 = 16.8%

This 16.8% value can also be called as test case efficiency %, which is
depends upon total number of test cases which uncovered defects.

c. Defect Slippage Ratio: Number of defects slipped (reported from

production) v/s number of defects reported during execution.

Formula: Number of Defects Slipped / (Number of Defects Raised - Number of Defects

Withdrawn)

Example: Customer filed defects are 21, total defect found while testing
are 267, total number of invalid defects are 17.

So, Slippage Ratio is [21/ (267-17)] X 100 = 8.4%

d. Requirement Volatility: Number of requirements agreed v/s number of
requirements changed.

Formula: Number of Requirements Added + Deleted + Modified) *100 /

Number of Original Requirements Example: VSS 1.3 release had total 67
requirements initially, later they added another 7
new requirements and removed 3 from initial requirements and
modified 11 requirements. So, requirement Volatility is (7 + 3 +
11) * 100/67 = 31.34%
Means almost 1/3 of the requirement changed after initial identification

e. Review Efficiency: The Review Efficiency is a metric that offers

insight on the review quality and testing some organization also use this
term as “Static Testing” efficiency and they are aiming to get min of
30% defects in static testing.

Formula=100*Total number of defects found by reviews/Total number of project defects

Example: A project found total 269 defects in different reviews, which

were fixed and test team got 476 defects which were reported and
valid

So, Review efficiency is [269/(269+476)] X 100 = 36.1%

f. Defect Removal Effectiveness(DRE):

DRE= (Defects removed during development phase x100%) / Defects latent in the
product
Defects latent in the product = Defects removed during development Phase+ defects
found later by user
 Testing Terminology

1. Project: Requirements will come from one customer and mostly it will
be used by customer and his people.

2. Product: Requirements will come from various customers and will be

used by more number of customers.

3. Application: Group of programs designed for the customers to use for specific
operations.

4. AUT (Application under Testing): After Designing and coding

phase of development cycle,the application(build) comes for
testing then the application(build) is called "Application Under
test".

5. Quality: Justification of the Requirements and absence of Defects, delivered on time.

6. Defect: Deviation from the requirement

7. SRS: System Requirement Specification, which is the actual requirement document.

8. BDD: Business Design Document, which is an initial document designed by
business people and then they will prepare the SRS.

9. Mock ups: In Design phase or for requirement phase, some sample

screens replica of actual application will be provided for team.

10. Use Case: It will describe the Basic Flow, Alternate Flow and
Exceptional Flow, how the application will be processed. Use case
document will be used as the base document by both the Developers
and the Testers. Developers will write the code based on the Use case
and Testers in turn will identify test scenarios and write test cases
based on the use case. Use will be written by the Business Analysts
from the Functionality requirement document.

11. Test Case: Test cases are the step wise description or activities which
are going to be executed in order to validate the application. The test
cases will contain the step number, description or activity - what action
is going to happen while validation, the input data, the expected result
and the actual
 result. The test cases are written based on the functionality or
requirements or the use cases received from the client. Test Cases
will be prepared by Testing Team.

12. Test data: Test data is the data that is used in tests of a software system.

In order to test a software application you need to enter some data for
testing most of the features. Any such specifically identified data which is
used in tests is known as test data.

You can have test data in excel sheet which can be entered manually
while executing test cases or it can be read automatically from files
(XML, Flat Files, Database etc.) by automation tools.

13. Version Control: It is a system that records changes to a file or set

of files over time so that you can recall specific versions later.

14. Check out: Taking the document to edit (do the changes, ex:
Updating the defect tracker, test cases, etc) from the configuration
management tool or common repository (VSS).

15. Check in: Releasing the document after performing the changes to the
configuration management tool or common repository (VSS).

16. Release notes: Release notes is a document which will be prepared

by the dev team during the release time. It will be delivered to the
customers which contains the technical information about changes
addressed in the current release.
17. Build: Build is a version of software will be given for testing
team to test. Usually release contains multiple builds to test.
Software is still in testing.

18. Release: Software is no longer in testing phase, ready to deliver to customer.

19. Delivery: Handover the working software constructed based on the

customer requirements to the customer on or before delivery date.

20. Test Deliverables: The documents which were prepared during the testing phase.

- Clarification Document / Query Tracker

- Traceability Matrix
- Test Case Document with results
- Defect Report (Open, Closed, Defer)
- Test Summary Report (Passed, Failed, Hold)
21. Test Summary Report:

22. Traceability Matrix: t is a document that maps and traces user

requirement with test cases. The main purpose of Requirement
Traceability Matrix is to see that all test cases are covered so that no
functionality should miss while testing.

23. Productivity: Effective hours produced by individual team members in the

team. Ex, if a person stays at office more than 10 hrs and he works only
for 7 hrs and 3 hrs he didn’t work on the project, Then the productivity is
7 hrs.

24. Variance: Variance is the difference between what was planned and the
 actual value. Ex, if planned date is 20th Jan 15 and actual completion
date is 25th Jan 15 then the variance is 5 days.

25. Estimation: Providing the time to finish the specific work.

26. Escalation: Taking the issue to next step. If there is a defect and
defect is not accepting by the dev team but still you believe that it’s
an issue, you can contact customer for the issue.

27. Roles & Responsibilities: The work which we are going to perform
after getting the Job. The Responsibilities will change based on role. Ex,
Test engineer will do requirement understanding, test case preparation,
execution and reporting the bugs. Test Lead will assign the work to his
team members, collects data, etc.

28. Entry Criteria: Entry criterion is used to determine when a given

test activity should start. It also includes the beginning of a level of
testing, when test design or when test execution is ready to start.
29. Exit Criteria: Exit criterion is used to determine whether a given test
activity has been completed or NOT. Exit criteria can be defined for all of
the test activities right from planning, specification and execution.

30. Status Call: Status call will happen daily / weekly / monthly based
on client/company rules where we will discuss about project status.

31. MOM: Minutes of Meeting are the written or recorded

documentation that is used to inform attendees and non-attendees
of the happenings during the meeting.

MOM Contains:

The names of the participants, the agenda items covered, decisions made by
the participants, the follow-up actions committed to by participants, due
dates for the completion of commitments , and any other events or
discussions worth documenting for future review or history.

32. One to One: It is a face to face meeting.

33. Appraisal: The comp people (HR, Managers, and team) will assess the
individual team member based on Peer/Lead/Manager feedback and
they will revise your salary or role. There will be Midterm and annual
appraisals based on company rules.

34. Rating: Giving ranking for the individual team member by the
Lead/managers based on their skills and their performance during
 appraisal period.

35. Time sheet: If a team member is billable (charging client) the he will
have to submit his time sheet weekly/daily contains his tasks completed
during the week. Usually total hours per week are 40 hrs which is 8 hrs per
day.

Ex: Task Monday Tuesday Wednesday Thursday Friday

Test Case Preparation 2 hrs 4 hrs 5 hrs 7 hrs 8 hrs
Weekly Meeting 2 hrs 2 hrs 1 hrs
Requirement Understating 4 hrs 2 hrs 3 hrs
Total 8 hrs 8 hrs 8 hrs 8 hrs 8 hrs

36. Resource Funding / Billable: A resource (team member) who is

being charging from client for his work.
37. Non Billable: A resource that is not being charged from client is
called Shadow / non billable resource.

38. OOO: Out of office, going out from office. Usually uses while informing
to team that you are going out from office.

39. Planned Leave: You planned your leave long before and applied. It’s a
scheduled or planned well before.

40. Un Planned or Sick Leave: Unscheduled and unplanned leave,

usually take if resource is not feeling well.

Usually we do have 16 planned leave (4 per quarter) and 5-10 sick leaves. It’s diff per
company.

41. PTO: Paid Time Off, taking leave. Using the leaves (Planned Leave, Sick
Leave) and still company pay you salary for this time.

42. Notice Period: Once you want to move out of from the current
company then we will quit the Job. Company has a policy that we will
have to inform before 2/3 months so that they will search for a
replacement for us.

43. Bench Mark: Finalising any document or any process. Ex, Finalising the test cases,
requirement.
44. CTC: Cost to Company (CTC) is the salary package of an employee. It
indicates the total amount of expense an employer (organization) is
spending for an employee in a year.

45. Variable Pay: Variable pay is used generally to recognize and reward
employee contribution toward company productivity, profitability, team
work, safety, quality, or some other metric deemed important.

This will be pay you based on your performance and company

performance during the appraisal period.

46. Basic Salary: Basic salary is the amount paid to an employee before
any extras are added or taken off, such as reductions because of salary
sacrifice schemes or an increase due to overtime or a
 bonus. Allowances, such as internet for home-based workers or
contributions to phone usage, would also be added to the basic salary.

47. Gross Salary: Gross salary is the term used to describe all of the
money you've made while working at your job, figured before any
deductions are taken for state and federal taxes, Social Security and
health insurance. If you work more than one job, you'll have a gross
salary amount for each one.

48. Demo: Demonstrating the completed part of work or software to

customer and will get his feedback.

49. POC: Point of Contact, to whom we need to contact. There will be diff
for diff departments. Ex, for all QA related queries, you can contact Mr
John, for all development related queries you can contact Mr Anderson.

(OR)

Proof of Concept: A proof of concept (POC) is a demonstration, the

purpose of which is to verify that certain concepts or theories have the
potential for real-world application. POC is therefore a prototype that is
designed to determine feasibility, but does not represent deliverables.
Proof of concept is also known as proof of principle.

50. Pipeline: In progress, expecting something shortly or near future. Ex, there is more
work in pipe line.
51. Project Sign in: Project was finalised and the team is ready to work on.