SOFTWARE TESTING

Instructor: Mehwish
 OUTLINE
• Testing in Software Life Cycle
• V-Model
• Component Testing
• Integration Testing
• System Testing
General Principles of Testing
 General Principles of Testing
• There are seven principles of testing, which
have evolved over 40 years and can be used
as a general guideline for all testing.
• First Principle
– The first principle states that testing can show that
defects are present; however cannot prove that
there are no defects.
• Second Principle
– The second principle states that testing all combinations of
inputs and preconditions is not feasible, except in trivial
cases.
• Third Principle
– The third principle states that errors identified late in the
development process are more costly to resolve.
• Fourth Principle
– The fourth principle of testing is based on the Pareto
principle or 80–20 Rule, which states that 80% of defects
are caused by 20% of causes.
• Fifth Principle
– The fifth testing principle states that a variety of tests and
techniques should be used to expose a range of defects
across different areas of the product.
• Sixth Principle
– The sixth principle states that different software products
have varying requirements, functions, and purposes; so
same tests should not be applied across the board.
• Seventh Principle
– The seventh and final testing principle states that to
ensure adequate software testing procedures are
performed in every situation, testers should assume that
all software contains some concealed faults, as undetected
errors do not mean the software is error-free.
Ethical Guidelines
 Ethical Guidelines
• The code of ethics concerns the Association for
Computing Machinery (ACM) and the Institute of
Electrical and Electronic Engineers (IEEE).
• Testers, as a part of their job, will have access to
privileged information from these bodies.
• Testers should follow the code of ethics to ensure
that confidential information is not used
inappropriately.
• A certified Software Tester should:
– Not hurt public interest in any way
– Act according to the requirements of the client and
employer
– Ensure that all deliverables on the product they test meet
highest possible standards
– Maintain integrity and independence in judgment
– Promote and maintain an ethical approach
– Advance integrity and reputation of the profession
– Provide fair support and co-operation to colleagues
– Practice an attitude of lifelong learning and ethical
approach to the profession
Testing in Software Lifecycle
 Testing in Software Lifecycle
• Every SDLC model has several testing characteristics,
such as the following:
– Every development activity should have a corresponding
testing activity.
– Each test level has objectives specific to it.
– Testers should be involved in reviewing documents as soon
as drafts are available in the development lifecycle.
– Type of test and test strategy depends on the nature or
complexity of the project.
• The right test approach selection should be based on
a variety of factors.
• Few factors to be considered are:
– Nature of the project
– Software development model
– Risk associated
– The complexity of the project
The General V-Model
 The General V-Model
• V-model, as also known as Sequential Development
Model, follows an ordered path of execution of
phases.
• Each phase must be completed before the next
phase begins.
• The four key levels of testing in this model are:
– Component test
– Integration test
– System test
– Acceptance test.
Component Testing
 Component Testing
• A component may be a class or a cluster of classes.
• There are several situations in which an individual
class should be tested regardless of their size or
complexity.
• Components can be broadly categorized as:
– Reusable
– Domain
– Commercial components
• First level testing of executable code, and therefore a
large percentage of errors can be found at this level.
• In this level, each component is individually tested
using white box testing techniques, usually by the
developer.
• For example,
– an application has 10 functional components, and each is
tested in isolation before all are integrated into one.
• Component testing is strongly recommended
invariant from the type of development model
selected.
– Reusable components should be tested over a wide range
of values than a component intended for a single focused
use.
– Domain components represent significant domain
concepts and should be tested for accuracy.
• Commercial components are sold as individual
products and should be tested as it is a potential
source of liability.
Integration Testing
 Integration Testing
• Once components have been tested individually,
these are then integrated and tested.
– This is called Integration testing, where software
components, hardware components, or both are
combined and tested to evaluate their interactions.
• Testers perform integration testing with formal
defect management mechanisms.
– At this stage, the testers concentrate only on integration.
• The three standard strategies to perform this testing
are:
– Top-Down
– Bottom-Up
– Big Bang approach
• Top-Down
– The Top-Down approach to integration testing requires the
highest-level modules to be tested and integrated first.
– This allows early testing of high-level logic and data flow in
the process and tends to minimize the need for drivers.
• Bottom-Up
– The Bottom-Up approach requires the lowest-level units or
utility modules to be tested and integrated first.
– Through this approach, utility modules are tested early in
the development process, and the need for stubs is
minimized.
• Big Bang
– The third approach Big Bang, or umbrella approach,
requires testing functional data and control flow paths.
– First, functions inputs are integrated into the bottom-up
pattern.
– Each function outputs are then embedded in a top-down
manner.
– The primary advantage of this approach is the degree of
support for the early release of limited functionality.
– It also helps in minimizing the need for stubs and drivers.
System Testing
 System Testing
• Once the integration testing has been performed, the
system is subjected to end-to-end or system testing.
• Following are some of the characteristics.
– System testing is done on application software to evaluate
its overall compliance with the business, functional, or
end-user requirements.
– System testing mainly uses
Black Box software testing techniques. Hence the
knowledge of internal design, structure, or code is not
required.
– It is usually carried out by an independent testing team
and aims to detect defects or bugs both within the
interfaces, and the software.
– It follows formal defect management process as well.
– System testing will include both functional and non-
functional requirements such as performance, usability,
and security.
– The test environment for system testing should correspond
as closely as possible to a production environment,
• to minimize the risk of not finding environment specific failures in
testing.
THE END
Thanks