SF332

การทดสอบและประกันคุณภาพซอฟต์แวร์
Software Testing and Quality Assurance

Week 2
Software Development Life Cycle

SF332 Software Testing and Quality Assurance 1

 Agenda

Software Development lifecycle

Software Testing Life Cycle

Test Levels

Test Types

SF332 Software Testing and Quality Assurance 2

 Software Development and Software Testing
In any software development lifecycle model, there are several characteristics of
good testing:
• For every development activity, there is a corresponding test activity
• Each test level has test objectives specific to that level
• Test analysis and design for a given test level begin during the corresponding
development activity
• Testers participate in discussions to define and refine requirements and design,
and are involved in reviewing work products (e.g., requirements, design, user
stories, etc.) as soon as drafts are available

SF332 Software Testing and Quality Assurance 3

 Software Development lifecycle
Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test high quality software. The SDLC aims to produce a high-quality software
that meets or exceeds customer expectations.
Requirement
Model
Gathering
- Waterfall Model
Deployment Analysis
- Iterative Model
- Scrum Model
SDLC - Kanban Model
Testing Design
- Spiral Model
- V model
Coding

SF332 Software Testing and Quality Assurance 4

 Waterfall Model
Requirement • Sequential flow of activities
• Linear Development Process
Analysis • Deliver software complete set of
features , but require months or years
Design for delivery

Coding

Test

Deploy

SF332 Software Testing and Quality Assurance 5

 V Model
Developer’s life cycle - VER Tester’s life cycle - VAL

SF332 Software Testing and Quality Assurance 6

 Iterative and incremental Model
Rational Unified Process: Each iteration
tends to be relatively long (e.g., two to
three months), and the feature
increments are correspondingly large,
such as two or three groups of related
features

https://en.wikipedia.org/wiki/Rational_Unified_Process
SF332 Software Testing and Quality Assurance 7
 Scrum Model

Scrum: Agile management framework which each iteration tends to be relatively

short (a few weeks- a few months), and the feature increments are correspondingly
small, such as a few enhancements and/or two or three new features. This
framework provide opportunity to give development team rapid feedback

SF332 Software Testing and Quality Assurance 8

 Kanban Model
Kanban: Implemented with or without fixed-length iterations, which can deliver either a single
enhancement or feature upon completion, or can group features together to release at once

https://www.digite.com/kanban/kanban-board/
SF332 Software Testing and Quality Assurance 9
 Spiral Model
Spiral (or prototyping): Involves creating
DEFINE ANALYSIS
experimental increments, some of which may
be heavily re-worked or even abandoned in
subsequent development work

Design
BUILD

https://www.geeksforgeeks.org/software-engineering-spiral-model/
SF332 Software Testing and Quality Assurance 10
 SDLC – Software Development Life Cycle
R
A
D
Water fall model C
T
De
Communication Planning Modeling Construction Deployment

• Project • Estimating • Analysis • Code • Delivery

initiation • Scheduling • Design • Test • Support
• Requirement • tracking • feedback
s gathering
Agile

SF332 Software Testing and Quality Assurance 11

 Agenda

Software Development lifecycle

Software Testing Life Cycle

Test Levels

Test Types

SF332 Software Testing and Quality Assurance 12

 Software Testing Life Cycle (STLC)
Activities and deliverables define what actions are performed and what the expected result
is. Some of these phases can be performed simultaneously while others require previous
phases to be completed first.
Requirement
Analysis

Test Testing
Closure planning

STLC

Testing Test
Execution Design

Environment
Setup

SF332 Software Testing and Quality Assurance 13

 Software Development lifecycle (SDLC)
and Software Testing Life Cycle (STLC)
Requirement Requirement
Gathering Analysis

Test Testing
Deployment Analysis Closure planning

SDLC STLC

Testing Test
Testing Design Execution Design

Environment
Coding
Setup

SF332 Software Testing and Quality Assurance 14

 Agenda

Software Development lifecycle

Software Testing Life Cycle

Test Levels

Test Types

SF332 Software Testing and Quality Assurance 15

 Component Integration System Acceptance
Test Levels Testing Testing Testing Testing

Test levels are groups of test activities that are organized and managed together.
Each test level is an instance of the test process.
Acceptance Testing
System 1
System Testing
Module X Module Y Integration Testing

A B C D E Component Testing

SF332 Software Testing and Quality Assurance 16

 Test Levels
Test levels are characterized by the following attributes:
• Specific objectives
• Test basis, referenced to derive test cases
• Test object (i.e., what is being tested)
• Typical defects and failures
• Specific approaches and responsibilities
For every test level, a suitable test environment is required.
In acceptance testing, for example, a production-like test environment is ideal,
while in component testing the developers typically use their own development environment.

SF332 Software Testing and Quality Assurance 17

 Component Testing
Test Objectives Test objects
• Reducing risk • Components, units or modules
• Verifying whether the functional and non-functional • Code and data structures
behaviors of the component are as designed and • Classes
specified • Database modules
• Building confidence in the component’s quality
• Finding defects in the component
Typical defects and failures
• Preventing defects from escaping to higher test levels. • Incorrect functionality
• Data flow problems
Test basis • Incorrect code and logic
• Detailed design
• Code
• Data model
• Component specifications
SF332 Software Testing and Quality Assurance 18
 Component Testing - Approaches
Test Driven Development Test Harness
Calling
Driver component

Parameters

Result
Test Unit

Stub Stub Stub

SF332 Software Testing and Quality Assurance 19

 Integration Testing
Component Integration System Integration

Sales
Point of Sales Commission
System System

Warehouse Financial
Inventory Accounting
System System

SF332 Software Testing and Quality Assurance 20

 Integration Testing
Test Objectives Test objects
• Verifying whether the functional and non-functional • Subsystems • Interfaces
behaviors of the interfaces are as designed and • Databases • APIs
specified • Infrastructure • Microservice
• Building confidence in the quality of the interfaces
• Preventing defects from escaping to higher test levels
Typical defects and failures
• Incorrect data, missing data, or incorrect data
Test basis encoding
• Sequence diagrams • Incorrect sequencing or timing of interface calls
• Interface and communication protocol specifications • Failures in communication between components
• Use cases • Unhandled or improperly handled
• Architecture at component or system level communication failures between components
• Workflows • Incorrect assumptions about the meaning, units,
• External interface definitions or boundaries
SF332 Software Testing and Quality Assurance 21
 Integration Testing Strategies

Bottom up Module 1 Top down

Dynamically changing Clear requirement and
(Agile) Module 2 Module 3 design (waterfall)

Module 4 Module 7
Module 5

Module 6

SF332 Software Testing and Quality Assurance 22

 System Testing
Test Objectives Test objects
• Verifying whether the functional and non-functional • Applications
behaviors of the system are as designed and specified • Hardware/software systems
• Validating that the system is complete and will work • Operating systems
as expected • System under test (SUT)
• Building confidence in the quality of the system as a • System configuration and configuration data
whole
Typical defects and failures
Test basis
• Incorrect or unexpected system functional or
• System and software requirement specifications non-functional behavior
• Risk analysis reports • Failure to properly and completely carry out end-
• Use cases, Epics and user stories to-end functional
• Models of system behavior, State diagrams • Failure of the system to work properly in the
• System and user manuals system environment(s)
SF332 Software Testing and Quality Assurance 23
 Acceptance Testing
Test Objectives
• Verifying that functional and non-functional behaviors
of the system are as specified
• Defects may be found but not objective, if found may
be major project risks.
• Acceptance testing may also satisfy legal or regulatory
requirements or standards
Test basis
• Business processes, User or business requirements
• Use cases and/or user stories
• System requirements
• System or user documentation, Installation procedures
• Risk analysis report
SF332 Software Testing and Quality Assurance
Test objects
• System configuration and configuration data
• Business processes for a fully integrated system
• Recovery systems and hot sites
• Operational and maintenance processes
• Forms, Reports
Typical defects and failures
• System workflows do not meet business or user
requirements
• Non-functional failures such as security
vulnerabilities, inadequate performance efficiency
under high loads, or improper operation on a
supported platform
24
 Types of Acceptance Testing - I
• User acceptance testing (UAT) : typically focused on validating the fitness for use
of the system by intended users in a real or simulated operational environment.
The main objective is building confidence that the users can use the system to
meet their needs, fulfill requirements, and perform business processes with
minimum difficulty, cost, and risk.  Business users , User representatives
• Operational acceptance testing (OAT) – often called operational readiness
testing. focus on operational aspects , procedures that allow the system to be
used and maintained e.g. backup/restore, Installing, uninstalling and upgrading,
user management, disaster recovery, maintenance tasks, performance testing
,security, etc.System administration staffs

SF332 Software Testing and Quality Assurance 25

 Types of Acceptance Testing - II
• Contractual and regulatory acceptance testing
• Contractual acceptance testing is performed against a contract’s acceptance
criteria for producing custom-developed software. Acceptance criteria should be
defined when the parties agree to the contract. Contractual acceptance testing
 Independent testers.
• Regulatory acceptance testing is performed against any regulations that must be
adhered to, such as government, legal, or safety regulations. Regulatory
acceptance testing is often performed by users or by
 regulatory agencies , independent testers

SF332 Software Testing and Quality Assurance 26

 Types of Acceptance Testing - III
• Alpha and beta testing are typically used by developers of commercial off-the-shelf
(COTS) software who want to get feedback from potential or existing users, customers,
and/or operators before the software product is put on the market.
• Alpha testing is performed at the developing organization’s site, not by the
development team, but by potential or existing customers, and/or operators or an
independent test team.
• Beta testing is performed by potential or existing customers, and/or operators at their own
locations. Beta testing may come after alpha testing or may occur without any preceding
alpha testing having occurred.

SF332 Software Testing and Quality Assurance 27

 Exercise Testing Level
1. What Is Beta testing?
A. Performed to identify all possible issues/bugs before releasing the product to everyday users
or the public. A type of Acceptance testing.
B. Examines whether the software complies with the regulations.
C. Performed by potential customers at their own locations. A type of Acceptance testing.
D. Ensure there are workflows in place to allow the software or system to be used.

2. What Is Component testing?

A. Testing the lowest or the smallest unit of any application.
B. Testing the behavior and capabilities of a whole system or product.
C. Testing the interactions between components or systems.
D. Testing the whole system that will work as expect.
SF332 Software Testing and Quality Assurance 28
 Exercise Testing Level
3. Which of the following is true of white-box testing?
A. It is carried out only by developers.
B. It can be used to test data file structures.
C. It is used only at unit and integration test levels.
D. Coverage achieved using white-box test techniques is not measurable.

4. Which of the following is not true of regression testing?

A. It can be carried out at each stage of the life cycle.
B. It serves to demonstrate that the changed software works as intended.
C. It serves to demonstrate that software has not been unintentionally changed.
D. It is often automated.

SF332 Software Testing and Quality Assurance 29

 Agenda

Software Development lifecycle

Software Testing Life Cycle

Test Levels

Non-
Functional
functional
Test Types
Change
White-box
Related

SF332 Software Testing and Quality Assurance 30

 ISO/IEC 25010 Ed. 2011 - Product Quality model
Functional Suitability Performance Compatibility Usability
efficiency
• Functional completeness • Appropriateness
• Functional correctness • Time-behavior • Co-existence recognizability
• Functional • Resource utilization • Interoperability • Learnability
appropriateness • Capability • Operability
• User error protection
• User interface aesthetics
• Accessibility
Reliability Security Maintainability
• Maturity • Confidentiality • Modularity Portability
• Availability • Integrity • Reusability
• Fault tolerance • Non-repudiation • Analyzability • Adaptability
• Recoverability • Accountability • Modifiability • Installability
• Authenticity • Testability • Replaceability

SF332 Software Testing and Quality Assurance 31

 Functional Testing
• Tests that evaluate functions that the system should perform (WHAT).
• Functional requirements may be described in work products such as business
requirements specifications, epics, user stories, use cases, or functional
specifications, or they may be undocumented.
• Functional tests should be performed at all test levels.
• Black-box techniques may be used to derive test conditions and test cases
• Measure through functional coverage and extent to which some type of functional
element e.g. %Functional Requirement coverage =
No. Functional Req. Cover by test condition / No. Functional requirements

SF332 Software Testing and Quality Assurance 32

 Non-Function Testing
• Non-functional testing is the testing of “how well” the system behaves.
• Non-functional testing of a system evaluates characteristics of systems and
software such as usability, performance efficiency or security.
• Non-functional testing can and often should be performed at all test
levels, and done as early as possible.
• Black-box techniques (see section 4.2) may be used to derive test conditions and
test cases for nonfunctional testing. For example, boundary value analysis can be
used to define the stress conditions for performance tests .
The thoroughness of non-functional testing can be measured through non-
functional coverage.

SF332 Software Testing and Quality Assurance 33

 White-Box Testing
• White-box testing derives tests based on the system’s internal structure or
implementation. Internal structure may include code, architecture, work flows,
and/or data flows within the system.
• white-box testing can be measured through structural coverage.

SF332 Software Testing and Quality Assurance 34

 Change Related Testing
• When changes are made to a system, either to correct a defect or because of new
or changing functionality, testing should be done to confirm that the changes have
corrected the defect or implemented the functionality correctly, and have not
caused any unforeseen adverse consequences.
• Confirmation testing: After a defect is fixed, the software may be tested with all
test cases that failed due to the defect, which should be re-executed on the new
software version.
• Regression testing: a change made in one part of the code may accidentally
affect the behavior of other parts of the code. Regression testing involves running
tests to detect such unintended side-effect.
• Confirmation testing and regression testing are performed at all test levels

SF332 Software Testing and Quality Assurance 35

 Confirmation and Regression Test
Round 1 Round 2

1 2 1 2
5 5

3 4 3 4

SF332 Software Testing and Quality Assurance 36

 Confirmation and Regression Test
Round 1 Round 2

1 2 1 2
5 5

3 4 3 4

SF332 Software Testing and Quality Assurance 37

 Maintenance Testing
Once deployed to production environments,
software and systems need to be maintained. Modification Migration Retirement
Changes of various sorts are almost inevitable
in delivered software and systems.
Impact analysis may be done before a change is made, to help decide if the change should be
made, based on the potential consequences in other areas of the system. Impact analysis can be
difficult if:
• Specifications / Test cases are out of date or missing
• Bi-directional traceability between tests and the test basis has not been maintained
• Tool support is weak or non-existent
• The people involved do not have domain and/or system knowledge
• Insufficient attention has been paid to the software's maintainability during development
SF332 Software Testing and Quality Assurance 38
 Type of Performance Testing

Performance Testing

Endurance Testing
Transaction Testing Load Testing Stress Testing Robustness Testing Scalability Testing
(Longivity/Soak)
Measure respond maximum limit to Go beyond limits for extended intervals how resilient the if the system is
time , identify work (Volume / the system to (e.g. 24 hour 365 system will be to capable of providing
bottle necks Concurrent users) looking for days per year) , negative input expected service
unexpected results/ repeat a transaction
more than once
Sample of volume/stress testing : Analogy of an air-traffic control system keeping track of 200 planes
• Volume test is to see what happened with 40,50, 100 and 200 planes
• Stress test will see what happens when 201st plane enters

SF332 Software Testing and Quality Assurance 39

 Exercise Test Types - Match descriptions to Type of Test
Type of Test Description
a. Checks the implementation of the program or code via testing of the
structure of the software system or its components. Functional Testing b.
b. Verifies that each function of the software application operates in
conformance with the requirement specification Non-functional Testing c.
c. Helps to estimate the readiness of a system according to the
different criteria which are not covered by functional testing. For
instance, Availability, Efficiency, Reliability, Reusability, Security White-box Testing a.

d. Provided to ensure that previously remove bugs have been fixed and
Change-related Testing d.
to catch bugs that may have been accidentally appeared into a new
version.
.
SF332 Software Testing and Quality Assurance 40
 Agenda

Software Development lifecycle

Software Testing Life Cycle

Test Levels

Test Types

SF332 Software Testing and Quality Assurance 41

SF332 Software Testing and Quality Assurance 42
 Assignment 2
จานวน 10 ข้อ 2 คะแนน

• https://docs.google.com/forms/d/e/1FAIpQL
SfmDNBtQY-
Aj1ObxmuMaWNlrO2SZen0NBsqjzIsfLfmTO0i
hA/viewform?usp=share_link

SF332 Software Testing and Quality Assurance 43

 Summary

Software Development lifecycle

Software Testing Life Cycle

Test Levels Component Integration System Acceptance

Testing Testing Testing Testing

Test Types
Non-
Functional
functional

Change
White-box
Related

SF332 Software Testing and Quality Assurance 44