Chapter 2
Software Testing
ISTQB / ISEB Foundation Exam Practice
Testing in the Lifecycle
1 Principles
2 Lifecycle
4 Dynamic test
5 Management
techniques
3 Static testing
6 Tools
Lifecycle
1
2
3
4
5
6
ISTQB / ISEB Foundation Exam Practice
Contents
Models for testing, economics of testing
High level test planning
Component Testing
Integration testing in the small
System testing (non-functional and functional)
Integration testing in the large
Acceptance testing
Maintenance testing
V-Model: test levels
Business
Requirements
Acceptance
Testing
Project
Specification
Integration Testing
in the Large
System
Specification
Design
Specification
Code
System
Testing
Integration Testing
in the Small
Component
Testing
V-Model: late test design
Tests
Business
Requirements
Acceptance
Testing
Tests
Project
Specification
Integration Testing
“We don’t have
in the Large
time to design
tests early”Tests
System
Specification
System
Testing
Tests
Design
Specification
Integration Testing
in the Small
Tests
Code
Component
Testing
Design
Tests?
V-Model: early test design
Tests
Tests
Business
Requirements
Acceptance
Testing
Tests
Tests
Project
Specification
Integration Testing
in the Large
Tests
Tests
System
Specification
System
Testing
Tests
Tests
Design
Specification
Integration Testing
in the Small
Tests Tests
Design
Tests
Code
Component
Testing
Run
Tests
Early test design
•
•
•
•
•
•
test design finds faults
faults found early are cheaper to fix
most significant faults found first
faults prevented, not built in
no additional effort, re-schedule test design
changing requirements caused by test design
Early test design helps to build quality,
stops fault multiplication
Experience report: Phase 1
Phase 1: Plan
2 mo
2 mo
dev
test
"has to go in"
but didn't work
Actual
fraught, lots of dev overtime
Quality
test
150 faults
1st mo.
50 faults
users
not
happy
Experience report: Phase 2
Phase
1:2:Plan
Phase
Phase 2: Plan
Plan
Actual
Actual
Actual
Quality
Quality
Quality
2 mo
22 mo
mo
dev
dev
dev
mo
662wks
wks
test
test
test
"has
totest:
go in"
acc
full
acc
test:
full
but
didn't
work
week
week (vs
(vs half
half day)
day)
on
on time
time
fraught, lots of dev overtime
smooth,
smooth, not
not much
much for
for dev
dev to
to do
do
test
test
test
150
faults
50
50 faults
faults
1st1st
mo.
1st mo.
mo.
500 faults
0 faults
faults
Source: Simon Barlow & Alan Veitch, Scottish Widows, Feb 96
users
not
happy
happy
happy
users!
users!
VV&T
• Verification
• the process of evaluating a system or component to
determine whether the products of the given development
phase satisfy the conditions imposed at the start of that phase
[BS 7925-1]
• Validation
• determination of the correctness of the products of software
development with respect to the user needs and
requirements [BS 7925-1]
• Testing
• the process of exercising software to verify that it satisfies
specified requirements and to detect faults
Verification, Validation and Testing
Validation
Any
Verification
Testing
V-model exercise
The V Model
VD
-
Build
Assemblage
Review VD
DS
Build
System
Review DS
FD
Review FD
TD
Exercise
Review TD
Build
Components
Build
Units
Assembly
Test
System
Test
Integration
Test
FUT
Exceptions:
Conversion Test
FOS: DN/Gldn
Code
TUT
How would you test this spec?
• A computer program plays chess with one user. It
displays the board and the pieces on the screen.
Moves are made by dragging pieces.
“Testing is expensive”
• Compared to what?
• What is the cost of NOT testing, or of faults missed
that should have been found in test?
– Cost to fix faults escalates the later the fault is found
– Poor quality software costs more to use
•
•
•
•
users take more time to understand what to do
users make more mistakes in using it
morale suffers
=> lower productivity
• Do you know what it costs your organisation?
What do software faults cost?
• Have you ever accidentally destroyed a PC?
– knocked it off your desk?
– poured coffee into the hard disc drive?
– dropped it out of a 2nd storey window?
• How would you feel?
• How much would it cost?
Hypothetical Cost - 1
(Loaded Salary cost: £50/hr)
Fault Cost
Developer User
- detect ( .5 hr)
£25
- report ( .5 hr)
£25
- receive & process (1 hr)
£50
- assign & bkgnd (4 hrs)
£200
- debug ( .5 hr)
£25
- test fault fix ( .5 hr)
£25
- regression test (8 hrs)
£400
£700
£50
Hypothetical Cost - 2
Fault Cost
Developer User
£700
- update doc'n, CM (2 hrs)
£100
- update code library (1 hr)
£50
- inform users (1 hr)
£50
- admin(10% = 2 hrs)
£100
Total (20 hrs)
£1000
£50
Hypothetical Cost - 3
Fault Cost
Developer User
£1000
£50
(suppose affects only 5 users)
- work x 2, 1 wk
£4000
- fix data (1 day)
£350
- pay for fix (3 days maint)
£750
- regr test & sign off (2 days)
£700
- update doc'n / inform (1 day)
£350
- double check + 12% 5 wks
£5000
- admin (+7.5%)
Totals
£800
£1000
£12000
Cost of fixing faults
1000
100
10
1
Req
Des
Test
Use
How expensive for you?
• Do your own calculation
– calculate cost of testing
• people’s time, machines, tools
– calculate cost to fix faults found in testing
– calculate cost to fix faults missed by testing
• Estimate if no data available
– your figures will be the best your company has!
(10 minutes)
Lifecycle
1
2
3
4
5
6
ISTQB / ISEB Foundation Exam Practice
Contents
Models for testing, economics of testing
High level test planning
Component Testing
Integration testing in the small
System testing (non-functional and functional)
Integration testing in the large
Acceptance testing
Maintenance testing
(Before planning for a set of tests)
• set organisational test strategy
• identify people to be involved (sponsors, testers,
QA, development, support, et al.)
• examine the requirements or functional
specifications (test basis)
• set up the test organisation and infrastructure
• defining test deliverables & reporting structure
See: Structured Testing, an introduction to TMap®, Pol & van Veenendaal, 1998
High level test planning
• What is the purpose of a high level test plan?
– Who does it communicate to?
– Why is it a good idea to have one?
• What information should be in a high level test
plan?
– What is your standard for contents of a test plan?
– Have you ever forgotten something important?
– What is not included in a test plan?
Test Plan 1
• 1 Test Plan Identifier
• 2 Introduction
– software items and features to be tested
– references to project authorisation, project plan, QA
plan, CM plan, relevant policies & standards
• 3 Test items
– test items including version/revision level
– how transmitted (net, disc, CD, etc.)
– references to software documentation
Source: ANSI/IEEE Std 829-1998, Test Documentation
Test Plan 2
• 4 Features to be tested
– identify test design specification / techniques
• 5 Features not to be tested
– reasons for exclusion
Test Plan 3
• 6 Approach
– activities, techniques and tools
– detailed enough to estimate
– specify degree of comprehensiveness (e.g. coverage)
and other completion criteria (e.g. faults)
– identify constraints (environment, staff, deadlines)
• 7 Item Pass/Fail Criteria
• 8 Suspension criteria and resumption criteria
– for all or parts of testing activities
– which activities must be repeated on resumption
Test Plan 4
• 9 Test Deliverables
– Test plan
– Test design specification
– Test case specification
– Test procedure specification
– Test item transmittal reports
– Test logs
– Test incident reports
– Test summary reports
Test Plan 5
• 10 Testing tasks
– including inter-task dependencies & special skills
• 11 Environment
– physical, hardware, software, tools
– mode of usage, security, office space
• 12 Responsibilities
– to manage, design, prepare, execute, witness, check,
resolve issues, providing environment, providing the
software to test
Test Plan 6
• 13 Staffing and Training Needs
• 14 Schedule
–
–
–
–
test milestones in project schedule
item transmittal milestones
additional test milestones (environment ready)
what resources are needed when
• 15 Risks and Contingencies
– contingency plan for each identified risk
• 16 Approvals
– names and when approved
Lifecycle
1
2
3
4
5
6
ISTQB / ISEB Foundation Exam Practice
Contents
Models for testing, economics of testing
High level test planning
Component Testing
Integration testing in the small
System testing (non-functional and functional)
Integration testing in the large
Acceptance testing
Maintenance testing
Component testing
• lowest level
• tested in isolation
• most thorough look at detail
– error handling
– interfaces
• usually done by programmer
• also known as unit, module, program testing
Component test strategy 1
• specify test design techniques and rationale
– from Section 3 of the standard*
• specify criteria for test completion and rationale
– from Section 4 of the standard
• document the degree of independence for test
design
– component author, another person, from different
section, from different organisation, non-human
*Source: BS 7925-2, Software Component Testing Standard
Component test strategy 2
• component integration and environment
– isolation, top-down, bottom-up, or mixture
– hardware and software
• document test process and activities
– including inputs and outputs of each activity
• affected activities are repeated after any fault fixes
or changes
• project component test plan
– dependencies between component tests
Component
Test Document
Hierarchy
Component
Test Strategy
Project
Component
Test Plan
Component
Test Plan
Source: BS 7925-2,
Software Component
Testing Standard,
Annex A
Component
Test
Specification
Component
Test Report
Component test process
BEGIN
Component
Test Planning
Component
Test Specification
Component
Test Execution
Component
Test Recording
Checking for
Component
Test Completion
END
Component test process
Component test planning
- how the test strategy and
project test plan apply to
the component under test
- any exceptions to the strategy
- all software the component
will interact with (e.g. stubs
and drivers
BEGIN
Component
Test Planning
Component
Test Specification
Component
Test Execution
Component
Test Recording
Checking for
Component
Test Completion
END
Component test process
BEGIN
Component
Test Planning
Component
Test Specification
Component
Test Execution
Component
Test Recording
Checking for
Component
Test Completion
END
Component test specification
- test cases are designed
using the test case design
techniques specified in the
test plan (Section 3)
- Test case:
objective
initial state of component
input
expected outcome
- test cases should be
repeatable
Component test process
BEGIN
Component
Test Planning
Component
Test Specification
Component test execution
- each test case is executed
- standard does not specify
whether executed manually
or using a test execution
tool
Component
Test Execution
Component
Test Recording
Checking for
Component
Test Completion
END
Component test process
BEGIN
Component
Test Planning
Component
Test Specification
Component
Test Execution
Component
Test Recording
Checking for
Component
Test Completion
Component test recording
- identities & versions of
component, test specification
- actual outcome recorded &
compared to expected outcome
- discrepancies logged
- repeat test activities to establish
removal of the discrepancy
(fault in test or verify fix)
- record coverage levels achieved
for test completion criteria
specified in test plan
END
Sufficient
to show test
activities carried out
Component test process
BEGIN
Component
Test Planning
Component
Test Specification
Component
Test Execution
Component
Test Recording
Checking for
Component
Test Completion
END
Checking for component
test completion
- check test records against
specified test completion
criteria
- if not met, repeat test
activities
- may need to repeat test
specification to design test
cases to meet completion
criteria (e.g. white box)
Also a measurement
technique?
= Yes
Test design techniques
= No
• “Black box”
– Equivalence partitioning
– Boundary value analysis
– State transition testing
– Cause-effect graphing
– Syntax testing
– Random testing
• How to specify other
techniques
• “White box”
– Statement testing
– Branch / Decision testing
– Data flow testing
– Branch condition testing
– Branch condition
combination testing
– Modified condition
decision testing
– LCSAJ testing