You are on page 1of 53

SOFTWARE TESTING AND

INTRODUCTION TO QUALITY
Nature of Error
Software Errors and Bugs

“An error is a deviation from accuracy or


correctness” and  “A software bug is an
error, flaw, failure, or fault in a computer
program or system that causes it to
produce an incorrect or unexpected result,
or to behave in unintended ways “.
1) Functionality Errors:
Functionality is a way the software is
intended to behave. Software has a
functionality error if something that
you expect it to do is hard, awkward,
confusing, or impossible.
E.g.  If the Cancel button is not clickable
then it is a functionality error.
2) Communication Errors:
These errors occur in communication from
software to end-user. Anything that the
end user needs to know in order to
use the software should be made
available on screen.

Few examples of communication errors are


– No Help instructions/menu provided,
features that are part of the release but are
not documented in the help menu, a button
named ‘Save’ should not erase a file etc.
3) Missing command errors:
This happens to occur when an expected
command is missing. 

Window allows the user to create a new


project. However, there is no option for the
user to exit from this window without
creating the project. Since ‘Cancel’
option/button is not provided to the user,
this is a missing command error.
4) Syntactic Error:
Syntactic errors are misspelled words or
grammatically incorrect sentences and
are very evident while testing software
GUI. Please note that we are NOT referring to
syntax errors in code. The compiler will warn
the developer about any syntax errors that
occur in the code
Note the misspelled word ‘Cancel’:
5) Error handling errors:
Any errors that occur while the user is
interacting with the software needs to
be handled in a clear and meaningful
manner. If not, it is called as an Error
Handling Error.
Take a look at this image. The error message
gives no indication of what the error actually
is. Is it missing mandatory field, saving error,
page loading error or is it a system error?
Hence, this is an ‘Error Handing Error’.
6) Calculation Errors:
These errors occur due to any of the following
reasons:
Bad logic
Incorrect formulae
Data type mismatch
Coding errors
Function call issues , etc.
7) Control flow errors:
The control flow of a software describes what it
will do next and on what condition.
For example, consider a system where user
has to fill in a form and the options available to
user are: Save, Save and Close, and Cancel. If
a user clicks on ‘Save and Close’ button, the
user information in the form should be saved
and the form should close. If clicking on the
button does not close the form, then it is a
control flow error
SOFTWARE QUALITY FACTORS
1) Product operation:
Correctness:
 Correctness is the extent to which a program satisfies
its specifications.
Reliability:
Reliability is the property that defines how well the
software meets its requirements.
Efficiency:
Efficiency is a factor relating to all issues in the
execution of software; it includes considerations such as
response time, memory requirement, and throughput.
Usability:
Usability, or the effort required locating and fixing errors
in operating programs.
2) Product transition: 

Portability:
Portability is the effort required to transfer the
software from one configuration to another.

Reusability:
Reusability is the extent to which parts of the
software can be reused in other related
applications.
3) Product revision:
Maintainability:
Maintainability is the effort required to maintain
the system in order to check the quality.

Testability:
Testability is the effort required to test to ensure
that the system or a module performs its
intended function.

Flexibility:
Flexibility is the effort required to modify an
operational program.
Quality assurance (QA)
Quality assurance (QA) is the process of
verifying whether a product meets required
specifications and customer
expectations.

QA is a process-driven approach that


simplifies and defines goals regarding
product design, development and
production.

QA's primary goal is tracking and resolving


deficiencies prior to product release.
Measurability is the key to QA. Products are
tested and evaluated to determine
whether they meet required
performance specifications. QA may
require many iterations and involve
production delays.

An organization's QA approach generally


emphasizes management, knowledge, skills,
personal integrity, confidence, quality
relationships and infrastructure.
Quality Control
Quality control is the set of measures and
procedures to follow in order to ensure
that the quality of a product is
maintained and improved against a set of
benchmarks and that any errors
encountered are either eliminated or
reduced.

The focus of quality control is to ensure that


the product and product manufacturing are
not only consistent but also in line with
customer requirements.
 One of the features of quality control is the use of well-
defined controls. It brings standardization into the
process.

Most organizations have a quality control/assurance


department that provides the set of standards to be
followed for each product.

Quality control involves testing of units and determining


if they are within the specifications for the final product.

The purpose of the testing is to determine any


needs for corrective actions in the manufacturing
process.

 Good quality control helps companies meet


consumer demands for better products.
Software Development Life
Cycle (SDLC)
Software Development Life Cycle (SDLC) is a
process used by the software industry to
design, develop and test high quality
software's.

The SDLC aims to produce a high-quality


software that meets or exceeds customer
expectations, reaches completion within times
and cost estimates.
Planning and Requirement Analysis
Requirement analysis is the most important
and fundamental stage in SDLC.

It is performed by the senior members of


the team with inputs from the customer,
the sales department, market surveys and
domain experts in the industry.

This information is then used to plan the


basic project approach and to conduct
product feasibility study in the economical,
operational and technical areas.
 Defining Requirements
Once the requirement analysis is done the next
step is to clearly define and document the
product requirements and get them approved
from the customer or the market analysts.

This is done through an SRS (Software


Requirement Specification)document which
consists of all the product requirements to be
designed and developed during the project life
cycle.
Designing the Product Architecture
SRS is the reference for product architects
to come out with the best architecture for
the product to be developed.

 Based on the requirements specified in


SRS, usually more than one design
approach for the product architecture is
proposed and documented in a DDS -
Design Document Specification.
Building or Developing the Product
In this stage of SDLC the actual
development starts and the product is built.

The programming code is generated as per


DDS during this stage.

 If the design is performed in a detailed and


organized manner, code generation can be
accomplished without much difficulty.
Testing the Product
This stage is usually a subset of all the stages
as in the modern SDLC models, the testing
activities are mostly involved in all the stages
of SDLC.

However, this stage refers to the testing only


stage of the product where product defects are
reported, tracked, fixed and retested, until the
product reaches the quality standards defined
in the SRS
Deployment in the Market and
Maintenance
Once the product is tested and ready to be
deployed it is released formally in the
appropriate market.

Sometimes product deployment happens in


stages as per the business strategy of that
organization.

The product may first be released in a


limited segment and tested in the real
business environment 
ER Diagram
Software Review
A software review is "A process or meeting during
which a software product is examined by a project
staffs, managers, users, customers, user
representatives, or other interested parties for
comment or approval".

"software product" means "any technical document


or partial document, produced as a deliverable of a
software development activity", and may include
documents such as contracts, project plans and
budgets, requirements documents,
specifications, designs, source code, user
documentation, support and maintenance
documentation, test plans, test specifications,
standards, and any other type of specialist work
product.
Software reviews may be divided into three
categories:
Software peer reviews are conducted by
the author of the work product, or by one or
more colleagues of the author, to evaluate the
technical content and/or quality of the work.

Software management reviews are


conducted by management representatives to
evaluate the status of work done and to make
decisions regarding downstream activities.

Software audit reviews are conducted by


external staff/employee to the software
project, to evaluate compliance with
What is Static Testing?
Static Testing, a software testing technique
in which the software is tested without
executing the code. It has two parts as
listed below:
Review - Typically used to find and
eliminate errors or ambiguities in
documents such as requirements, design,
test cases, etc.
Static analysis - The code written by
developers are analyzed (usually by
tools) for structural defects that may lead
to defects.
Informal Reviews: This is one of the type of
review which doesn't follow any process to find
errors in the document. Under this technique , you
just review the document and give informal
comments on it.

Technical Reviews: A team consisting of your


 peers,   review the technical specification of
the software product and checks whether it is
suitable for the project. They try to  find any
inconsistencies in the specifications and
standards followed. This review concentrates
mainly on the technical document related to the
software such as Test Strategy, Test Plan and
requirement specification documents.
Walkthrough: The author of the work
product explains the product to his team.
Participants can ask questions if any. 
Meeting is led by the author. Scribe makes
note of review comments

Inspection: The main purpose is to find


defects and meeting is led by trained
moderator. This review is a formal type of
review where it follows strict process to find
the defects. Reviewers have checklist to
review the work products .They record
the defect and inform the participants to
correct those errors.
Static code Review: This is systematic
review of the software source code without
executing the code. It checks the syntax of
the code, coding standards, code
optimization, etc. This is also termed as white
box testing .This review can be done at any
point during development.
What is an Inspection?
Inspection is the most formal form of
reviews, a strategy adopted during static
testing phase.
Characteristics of Inspection :
Inspection is usually led by a trained moderator,
who is not the author. Moderator's role is to do a peer
examination of a document
Inspection is most formal and driven by checklists
and rules.
This review process makes use of entry and exit
criteria.
It is essential to have a pre-meeting preparation.
Inspection report is prepared and shared with
the author for appropriate actions.
Post Inspection, a formal follow-up process is used to
ensure a timely and a prompt corrective action.
Aim of Inspection is NOT only to identify defects
but also to bring in for process improvement.
Walkthrough
 Code Walkthrough is a form of peer review in
which a programmer leads the review
process and the other team members ask
questions and spot possible errors
against development standards and other
issues.
Characteristics of
walkthrough:
The meeting is usually led by the author of the
document under review and attended by other
members of the team.
Review sessions may be formal or informal.
Before the walkthrough meeting, the preparation by
reviewers and then a review report with a list of
findings.
The scribe, who is not the author, marks the minutes
of meeting and note down all the defects/issues so
that it can be tracked to closure.
The main purpose of walkthrough is to enable
learning about the content of the document
under review to help team members gain an
understanding of the content of the document
and also to find defects.
What is White Box Testing?
White box testing is a testing technique,
that examines the program structure
and derives test data from the program
logic/code.

The other names of glass box testing are


clear box testing, open box testing, logic
driven testing or path driven testing or
structural testing.
White Box Testing Techniques:
Statement Coverage - This technique is
aimed at exercising all programming
statements with minimal tests.

Branch Coverage - This technique is


running a series of tests to ensure that all
branches are tested at least once.

Path Coverage - This technique


corresponds to testing all possible paths
which means that each statement and
branch is covered
Advantages of White Box Testing:
Forces test developer to reason carefully
about implementation.

Reveals errors in "hidden" code.

Spots the Dead Code or other issues


with respect to best programming
practices.
Disadvantages of White Box
Testing:
Expensive as one has to spend both time
and money to perform white box testing.

Every possibility that few lines of code


are missed accidentally.

In-depth knowledge about the


programming language is necessary to
perform white box testing.
What is Statement coverage?
The statement coverage is also known as
line coverage or segment coverage.

The statement coverage covers only the


true conditions.

Through statement coverage we can identify


the statements executed and where the
code is not executed because of blockage.

In this process each and every line of


code needs to be checked and executed
Advantage of statement coverage:
It verifies what the written code is expected
to do and not to do
It measures the quality of code written
It checks the flow of different paths in the
program and it also ensure that whether those
path are tested or not.

Disadvantage of statement coverage:


It cannot test the false conditions.
It does not report that whether the loop
reaches its termination condition.
It does not understand the logical
operators.
What is Branch Coverage or Decision Coverage?
Branch coverage is also known as Decision
coverage or all-edges coverage.
It covers both the true and false
conditions unlikely the statement
coverage.
A branch is the outcome of a decision,
so branch coverage simply measures
which decision outcomes have been tested.
Advantages of decision coverage:
To validate that all the branches in the
code are reached
To ensure that no branches lead to any
abnormality of the program’s operation
It eliminate problems that occur with
statement coverage testing

Disadvantages of decision coverage:


This metric ignores branches within boolean
expressions which occur due to short-circuit
operators.
What is Basis Path Testing?
 Basis path testing, a structured testing or
white box testing technique used for designing
test cases intended to examine all
possible paths of execution at least once.
Black Box Testing
BLACK BOX TESTING, also known as Behavioral
Testing, is a software testing method in which the
internal structure/ design/ implementation of the
item being tested is not known to the tester. These
tests can be functional or non-functional, though usually
functional.
This method is named so because the software
program, in the eyes of the tester, is like a
black box; inside which one cannot see. 

This method attempts to find errors in the


following categories:
 Incorrect or missing functions
 Interface errors
 Errors in data structures or external database
access
 Behavior or performance errors
 Initialization and termination errors
Advantages of Black Box Testing
– Tester can be non-technical.
– Used to verify contradictions in actual system
and the
specifications.
– Test cases can be designed as soon as the
functional
specifications are complete

Disadvantages of Black Box Testing


– The test inputs needs to be from large sample
space.
– It is difficult to identify all possible inputs in
limited testing
time. So writing test cases is slow and
Equivalence Partitioning:
It is also known as Equivalence Class Partitioning (ECP).

Using equivalence partitioning test design technique,


we divide the test conditions into class (group).

From each group we do test only one condition.


Assumption is that all the conditions in one group
works in the same manner. If a condition from a group
works then all of the conditions from that group work
and vice versa.

Reduces lots of rework and also gives the good


test coverage. We could save lots of time by reducing
total number of test cases that must be developed.
Boundary Value Analysis:
Using Boundary value analysis (BVA), we
take the test conditions as partitions
and design the test cases by getting the
boundary values of the partition.

The boundary between two partitions is the


place where the behavior of the application
varies. The test conditions on either side
of the boundary are called boundary
values.

In this we have to get both valid boundaries


(from the valid partitions) and invalid
boundaries (from the invalid partitions).
Decision Table:
This test technique is appropriate for
functionalities which has logical
relationships between inputs (if-else
logic). 

In Decision table technique, we deal with


combinations of inputs. To identify the test
cases with decision table, we consider
conditions and actions.

We take conditions as inputs and actions


as outputs.
Error Guessing:
Error guessing is one of the testing
techniques used to find bugs in a
software application based on tester’s
prior experience. In Error guessing we
don’t follow any specific rules.

Some of the examples are:


Submitting a form without entering values.
Entering invalid values such as entering
alphabets in the numeric field.

You might also like