Professional Documents
Culture Documents
Lec 12
Lec 12
Lec 12
ENGINEERING
Lecture 12
Outlines
• An Initial Definition of (Software) Quality
• Standard Definitions of (Software) Quality
• Why we need Testing?
• Testing Definition
• Error, Fault and Failure
• Verification and Validation in software testing
• Testing Levels
• Cost of not testing
Initial Definition of Quality
3
Standard Definitions of (Software) Quality
• IEEE Glossary: Degree to which a system, component, or
process meets
• (1) specified requirements, and
• (2) customer or user needs or expectations
4
Software Quality Assurance (SQA)
SQA vs QC vs Testing
Testing is a subset of QC
It is the process of executing a system in order to detect
bugs in the product so that they get fixed
Testing is an integral part of QC as it helps demonstrate
that the product runs the way it is expected and designed
for.
Why we need testing?
• Computers do not make mistakes. In fact the humans,
who
use to develop software for computers, certainly do mistakes.
• A complex computer application, which controls various
aspects of the system such as
• sensing, speed, temperature, location,
communication in underwater submarines, Flight control
systems, Medical treatment
also need to be trustworthy/dependable.
• Therefore, developing complex computer system also
requires a process to ensure that the software is fit for
the purpose.
What is Testing?
• Software testing is a process of executing a program or
application with the intent of finding the software bugs.
• It can also be stated as the process of validating and
verifying that a software program or application or
product:
• Meets the business and technical requirements that guided it’s
design and development
• Works as expected
What is Bug?
• When the result of the software application or product
does not meet with the end user expectations or the
software requirements then it results into a Bug or Defect.
13
Verification and Validation
• Verification and Validation in context of V&V model
Error, Fault and Failure
• Error
• It is a mistake made by human. This kind of mistake causes fault in the
system. This could happen because of : some confusion in
understanding the requirement of the software.
• A mistake in the source code indicates Error
• Fault
• appearance of an error in software, also known as fault. Fault is also
known as Defect or Bug.
• A Defect/Fault is a deviation between the actual and expected outcomes
• Failure
• When a system or piece of software produces an incorrect result or does
not perform the correct action, this is known as a failure. Failures are
caused by faults in the software.
Example: Error, Fault, Failure
• Example: Software for finding factorial
• Error: factorial is the sum 1 to N (instead of product!)
• Fault: use + operator instead of *
• Failure: wrong value produced
16
A Concrete Example
Fault: Should start
searching at 0, not 1
Testing Lifecycle
SE 2223 Software Engineering 21
Testing Lifecycle
• Test Plan
• It is a systematic approach to test a system i.e. software
• The plan typically contains a detailed understanding of what the
eventual testing workflow will be
• Test case
• It is a specific procedure of testing a particular requirement
• It will include
• Identification of specific requirement tested
• Test case success/failure criteria
• Specific steps to execute test
• Test data
Type of Testing
• Black box Testing
• White Box Testing
Black box Testing
• Testing software against a specification of its external
behavior without knowledge of internal implementation
details
• The tester is unaware to the system architecture and does
not have access to the source code.
• Typically, when performing a black box test, a tester will
interact with the system’s user interface by providing
inputs and examining outputs without knowing how and
where the inputs are worked upon.
SE 2223 Software Engineering 24
BBT vs WBT
• Black box testing
• No knowledge of internal program design or code required
• Tests are based on requirements and functionality
• White box testing
• Knowledge of the internal program design and code required
• Tests are based on coverage of code statements, branches, paths,
conditions.
SE 2223 Software Engineering 27
Testing Methodologies
SE 2223 Software Engineering 28
Testing Level
• Unit testing
• Tests each module individually
• Follows a white box testing (Logic of the program)
• Done by developers
• Integration testing
• Once all the modules have been unit tested, integration testing is
performed
• It is systematic testing
Produce tests to identify errors associated with interfacing
• Types:
• Big Bang Integration testing
• Top Down Integration testing
• Bottom Up Integration testing
• Mixed Integration testing
SE 2223 Software Engineering 32
System Testing
System Testing
• Alpha Testing
• It is carried out by the test team within the developing organization
• Beta Testing
• It is performed by a selected group of friendly customer
• Acceptance Testing
• It is performed by the customer to determine whether to accept or
reject the delivery of the system
• Performance Testing
• It is carried out to check whether the system meets the
nonfunctional requirements identified in the SRS document
SE 2223 Software Engineering 34
Regression Testing
• Regression testing is a type of software testing that
ensures that previously developed and tested software
still performs the same way after it is changed or
interfaced with other software
• Whenever software is corrected, some aspect of the
software configuration (the program, its documentation, or
the data that support it) is changed
• Regression testing helps to ensure that changes (due to
testing or for other reasons) do not introduce unintended
behavior or additional errors