Software Testing

ISTQB / ISEB Foundation Exam Practice

Testing throughout the

Software Life Cycle
Group 4: Phạm Tiến Đạt
Đỗ Anh Hào
Trần Minh Phụng
Nguyễn Phúc Minh Thông
 CONTENT

• Software Development Life Cycle Models

• Test levels

• Test types

• Maintenance testing
 System Testing

System testing focuses on the

behaviour and capabilities of a
whole system or product, often
considering the end-to-end tasks
the system can perform and the
non-functional behaviours it
exhibits while performing those
tasks.
 System Testing

Objectives Reduce risk. Verify functional & non-functional

behaviours of system. Validate system is complete & as
expected. Build confidence. Find & Prevent defects.

Test Basis Software & system reqs specs. Risk analysis reports. Use
cases. Epics & user stories. System models. State
diagrams. System & User manuals.

Test Objects Applications. Hardware/software. Operating system.

System configuration & config data.

Typical Defects & Incorrect calculations. Incorrect/unexpected system

Failures (non-)functional behaviours. Incorrect data flows.
Cannot complete end-to-end tasks. Not as described in
manuals.
 System Testing: Approaches & Responsibilities

• Independent testers typically carry out system testing.

• System testing of functional reqs starts by using most appropriate

black-box techniques (e.g., decision table). White-box techniques
may be used to assess the thoroughness of testing elements
(e.g., menu dialogue structure, web page navigation).

• The (properly controlled) test environment should ideally

correspond to the final target or production environment.
 Acceptance Testing

Acceptance testing. Formal testing

with respect to user needs,
requirements, and business
processes conducted to determine
whether or not a system satisfies
the acceptance criteria and to
enable the user, customers or other
authorised entity to determine
whether or not to accept the
system. (Textbook, p.55)
 Acceptance Testing

• Acceptance testing may produce information to assess the

system’s readiness for deployment and use by the customer
(end-user).
• Defects may be found during acceptance testing, but finding
defects is often not an objective, and finding a significant number
of defects during acceptance testing may in some cases be
considered a major project risk.
 Acceptance Testing: UAT

• Done by end-users
• Focus: business processes
• Environment: real / simulated
operational environment
• Aim: to build confidence that
system will enable users to
perform what they need to do with
a minimum of difficulty, cost, and
risk
 User acceptance testing

• Final stage of validation

o Customer (user) should perform or be closely involved
o Customer can perform any test they wish, usually based on their
business processes
o Final user sign-off

• Approach
o Mixture of scripted and unscripted testing
o "Model Office" concept sometimes used
 Why customer / user involvement

• Users know:
o what really happens in business situations
o complexity of business relationships
o how users would do their work using the system
o variants to standard tasks (e.g. country-specific)
o examples of real cases
o how to identify sensible work-arounds

Benefit:
Benefit:detailed
detailedunderstanding
understandingof
ofthe
thenew
newsystem
system
 Acceptance Testing: OAT

• Done by system admins

• Focus: backups; installation,
uninstallation upgrading; disaster
recovery; user management;
maintenance; data loading & migrations;
security; performance
• Environment: simulated production
environment
• Aim: to give confidence to the system
admins that they will be able to keep the
system running & recover from adverse
events quickly and w/o additional risks.
 Acceptance Testing: C/RAT

• Contractual AT: to verify whether a

system satisfies its contractual
requirements. Performed by users /
independent testers.
• Regulatory AT: to verify whether a
system conforms to relevant laws,
policies and regulations. Performed
by independent testers (possibly with
a representative of regulatory body.
 Acceptance Testing: Alpha & Beta Testing

• Alpha testing. Simulated or actual

operational testing conducted in the
developer’s test environment, by
roles outside the development
organization.
• Beta testing (field testing). Simulated
or actual operational testing
conducted at an external site, by
roles outside the development
organisation  diverse users; various
environments  testing can cover
more combinations of factors.
 Acceptance Testing
Objectives Establish confidence. Validate the system is complete & as
expected. Verify functional & non-functional behaviours as
specified.

Test Basis Biz process. User/Biz reqs. Regulations, legal contract &
standards. Use cases. System reqs. System/User
documentation. Risk analysis reports.
Backup & recovery procedures. Disaster recovery plan. Non-
functional reqs. Operations doc. Performance targets. DB
packages. Security standards.
Test SUT. System configuration & config data. Recovery system. Hot
Objects sits. Forms. Reports.

Typical System workflow. Business rules. Contract. Non-functional

Defects & failures (security vulnerabilities, performance inefficiency, etc)
Failures
 Acceptance testing motto

IfIf you
you don't
don't have
have patience
patience to
to test
test the
the
system,
system, thethe system
system will
will surely
surely test
test your
your
patience.
patience.
 CONTENT

• Software Development Life Cycle Models

• Test levels

• Test types

• Maintenance testing
 Test Types

• A test type is a group of test activities aimed at testing specific

characteristics of a software system, or a part of a system, based
on specific test objectives.

Test types

Functional Non-functional White-box Change-related

testing testing testing testing
Testing of Testing of Testing of Confirmation /
function software’s quality software’s Regression Test
characteristics structure /
architecture
 [1] Functional Testing

• The function of a system/component is "what" it does. Testing

conducted to evaluate the compliance of a component/system
with functional requirements.
• Functional requirements may be described in work products such
as: o Business reqs specs o Use cases
o Epics o Functional specs
o User stories o They may be undocumented.

• Functional tests should be performed at all test levels, though

the focus is different at each level
• Can be done from 2 perspectives: requirement-based and
business-process-based.
 [1] Functional Testing

• Functional requirements
o a requirement that specifies a function that a system or system
component must perform (ANSI/IEEE Std 729-1983, Software
Engineering Terminology)

• Functional specification
o the document that describes in detail the characteristics of the
product with regard to its intended capability (BS 4778 Part 2, BS
7925-1)
 [1] Functional Testing: Requirements-based

• Uses specification of requirements as the basis for

identifying tests
o Table of contents of the requirements spec provides an initial
test inventory of test conditions
o For each section / paragraph / topic / functional area,
• risk analysis to identify most important / critical
• decide how deeply to test each functional area
 [1] Functional Testing: Business-process-based

• Expected user profiles

o what will be used most often?
o what is critical to the business?

• Business scenarios
o typical business transactions (start to finish)

• Use cases
o prepared cases based on real situations
 [1] Functional Testing: Coverage

• Functional coverage is the extent to which some type of

functional element has been exercised by tests, and is expressed
as a percentage of the type(s) of element being covered.
• Using traceability between tests and functional requirements,
the percentage of these requirements which are addressed by
testing can be calculated, potentially identifying coverage gaps.
 [2] Non-functional 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, etc.
• Non-functional testing can be done at all test levels.
• Defines expected results in terms of external behaviour 
typically use black-box test techniques
o BVA – stress conditions – performance testing
o EP – types of devices – compatibility testing, or user groups –
usability testing (novice, experienced, age range, geographical
location, educational background)
 [2] Non-functional Testing: Coverage

• The thoroughness of non-functional testing can be measured by

the coverage of non-functional elements.
o If we had at least 1 test for each major group of users, we would
have 100% coverage of those user groups identified.

• Traceability between non-functional tests and non-functional

requirements, we can identify coverage gaps
o E.g., an implicit requirement is for accessibility for disabled users
 Performance Tests

• Timing Tests
o Response and service times
o Database back-up times

• Capacity & Volume Tests

o Maximum amount or processing rate
o Number of records on the system
o Graceful degradation

• Endurance Tests (24-hr operation?)

o Robustness of the system
o Memory allocation
 Multi-User Tests

• Concurrency Tests
o Small numbers, large benefits
o Detect record locking problems

• Load Tests
o The measurement of system behaviour under realistic multi-user
load
• Stress Tests
o Go beyond limits for the system - know what will happen
o Particular relevance for e-commerce

Source: Sue Atkins, Magic Performance Management

 Usability Tests

• Messages tailored and meaningful to (real) users?

• Coherent and consistent interface?
• Sufficient redundancy of critical information?
• Within the "human envelope"? (7±2 choices)
• Feedback (wait messages)?
• Clear mappings (how to escape)?

Who should design / perform these tests?

 Security Tests

• Passwords
• Encryption
• Hardware permission devices
• Levels of access to information
• Authorisation
• Covert channels
• Physical security
 Configuration and Installation

• Configuration Tests
o Different hardware or software environment
o Configuration of the system itself
o Upgrade paths - may conflict

• Installation Tests
o Distribution (CD, network, etc.) and timings
o Physical aspects: electromagnetic fields, heat, humidity, motion,
chemicals, power supplies
o Uninstall (removing installation)
 Reliability / Qualities

• Reliability
o "System will be reliable" - how to test this?
o "2 failures per year over ten years"
o Mean Time Between Failures (MTBF)
o Reliability growth models

• Other Qualities
o Maintainability, Portability, Adaptability, etc.
 Back-up and Recovery

• Back-ups
o Computer functions
o Manual procedures (where are tapes stored)

• Recovery
o Real test of back-up
o Manual procedures unfamiliar
o Should be regularly rehearsed
o Documentation should be detailed, clear and thorough
 Documentation Testing

• Documentation review
o check for accuracy against other documents
o gain consensus about content
o documentation exists, in right format

• Documentation tests
o is it usable? does it work?
o user manual
o maintenance documentation
 [3] White-box Testing

• White-box testing derives tests based on the system’s internal

structure or implementation of the component or system.
• Internal structure may include code, architecture, work flows,
and/or data flows within the system.
• Can occurs at any test level; but
o tends to mostly at component testing and component integration
testing
o Generally less likely at higher test levels, except for business process
testing (test basis could be business rules)
 [3] White-box Testing: Coverage

• Structural coverage is the extent to which some type of structural

element has been exercised by tests, expressed as a percentage
of the type of element being covered.
• At the component testing level, code coverage is based on the
percentage of executable elements (e.g., statements or decision
outcomes)
• At the component integration testing level, white-box testing
may be based on the architecture of the system (e.g., interface
between components), and coverage may be measured by
percentage of interfaces exercised by tests.
 [4] Change-related Testing

• When changes are made to a system, 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.
• Two sub-types: Confirmation testing and Regression testing
[4] Change-related Testing: Confirmation Testing

• After a defect is fixed, the software should be re-tested.

• At the very least, the steps to reproduce the failure(s) caused by
the defect must be re-executed on the new software version.
• The purpose of a confirmation test is to confirm whether the
original defect has been successfully fixed.
 [4] Change-related Testing: Regression Testing

• It is possible that a change made in one part of

the code, may accidentally affect the behaviour
of other parts of the code
• Changes may include changes to the
environment
• Regression testing involves running tests to
detect such unintended side-effects.
 [4] Change-related Testing: Regression Testing

• Regression test suites are run many times

and generally evolve slowly, so regression
testing is a strong candidate for automation.
• Automation of these tests should start early
in the project.
• Change-related testing is performed at all
test levels.
 Test Types & Test Levels

Functional Test Non-functional Test

How components calculate Time to perform a complex
Component compound interest interest calculation
How account info from user Check for buffer overflow from
Component
interface is passed to the business data passed from the UI to
Integration
logic business logic
How account holders can apply for Portability tests of presentation
System
a line of credit layer on browsers & mobiles
How system uses an external
System microservice to check an account Reliability tests (robustness) if the
Integration holder’s credit score microservice does not respond
Usability tests (accessibility) for
Acceptance How banker handles a credit banker’s credit processing
application interface for the disabled
 Test Types & Test Levels

White-box Test Change-related Test

100% statement & decision Automated regression tests for
Component coverage for all financial each component are included in CI
calculations components framework & pipeline
Coverage of how each screen in Confirmation tests for interface-
Component
the browser interface passes data related defects are activated as
Integration to the next screen in biz logic fixes are checked in
Coverage of web page sequence All tests for a given workflow are
System
during a credit line application re-executed if any screen changes
Coverage of all possible inquiry Automated tests of interactions of
System types sent to the credit score system with microservice are re-
Integration microservice executed as the service is changed
Coverage of all supported financial Previously failed tests are re-
Acceptance data file structures & value ranges executed after defects found are
for bank-to-bank transfers fixed
 CONTENT

• Software Development Life Cycle Models

• Test levels

• Test types

• Maintenance testing
 Maintenance testing

• Testing to preserve quality:

o Different sequence
• Development testing executed bottom-up
• Maintenance testing executed top-down
• Different test data (live profile)
o Breadth tests to establish overall confidence
o Depth tests to investigate changes and critical areas
o Predominantly regression testing
 What to test in maintenance testing

• Triggers for maintenance: Modification – Migration – Retirement

• Impact analysis
o What could this change have an impact on?
o How important is a fault in the impacted area?
o Test what has been affected, but how much?
• Most important affected areas?
• Areas most likely to be affected?
• Whole system?
• The answer: "It depends"
 Poor or missing specifications

• Consider what the system should do

o talk with users

• Document your assumptions

o ensure other people have the opportunity to review them

• Improve the current situation

o document what you do know and find out

• Track cost of working with poor specifications

o to make business case for better specifications
 What should the system do?

• Alternatives
o the way the system works now must be right (except for the specific
change)
o use existing system as the baseline for regression tests
o look in user manuals or guides (if they exist)
o ask the experts - the current users

• Without a specification, you cannot really test, only explore. You

can validate, but not verify.
1. What is the Difference Between System Test and
Acceptance Test?
System Test:
• Purpose: System testing is performed to ensure that the entire system functions as
intended and meets the specified requirements.
• Scope: It covers the testing of the complete system, including integrated components and
interactions between different subsystems or modules.
• Stakeholders: Typically conducted by the development or QA team.

Acceptance Test:
• Purpose: Acceptance testing is conducted to determine whether the system meets the
acceptance criteria and is acceptable for delivery to the end users or customers.
• Scope: It focuses on validating the system from the perspective of the end users or
customers, emphasizing real-world scenarios.
• Stakeholders: Involves end users, customers, or other external stakeholders who evaluate
the system against their business requirements.
 2. What is the Difference Between Test Levels and
Test Types?
Test Levels:
• Definition: Test levels refer to the different stages or phases of testing in the software
development life cycle (SDLC).
• Examples: Common test levels include unit testing, integration testing, system testing, and
acceptance testing.
• Objective: Each test level has a specific focus and purpose in ensuring the quality of the
software product.
Test Types:
• Definition: Test types represent the different approaches or methods used to evaluate a
software application.
• Examples: Common test types include functional testing, non-functional testing (e.g.,
performance testing, security testing), and regression testing.
• Objective: Each test type addresses specific aspects of the software, such as functionality,
performance, or security.