Just in Time Testing Course Materials

AmiBug.Com,Inc.
Just-In-Time Testing
www.amibug.com
Robert Sabourin, 2010
Robert Sabourin
rsabourin@amibug.com
AmiBug.Com, Inc.
61 8th avenue
Roxboro, Quebec
Canada, H8Y 2W7
514-916-0440
Robert Sabourin
President
AmiBug.Com, Inc.
Montreal, Canada
June 16, 2010
Slide 1
AmiBug.Com, Inc.
Overview
Welcome
Some Philosophy
Context Drivers
Turbulence
Skills
Bug Flow
Testing Ideas
Test Triage
Exploratory Testing
June 16, 2010
Slide 2
AmiBug.Com, Inc.
Just In Time Testing

Robert Sabourin ,
Software Evangelist
President
AmiBug.Com Inc.
Montreal, Quebec,
Canada
June 16, 2010
Slide 3
AmiBug.Com, Inc.
June 16, 2010
Slide 4
AmiBug.Com, Inc.
Welcome
June 16, 2010
Slide 5
AmiBug.Com, Inc.
Pain points?
What hurts?
How Much?
June 16, 2010
Slide 6
AmiBug.Com, Inc.
Just In Time For ________?
June 16, 2010
Slide 7
AmiBug.Com, Inc.
June 16, 2010
Slide 8
AmiBug.Com, Inc.
Some Philosophy
June 16, 2010
Slide 9
AmiBug.Com, Inc.
Fundamental Question
How do you know when you are finished?
June 16, 2010
Slide 10
AmiBug.Com, Inc.
Crosby on Quality
Quality is defined as conformance to
requirements
Quality is not a measure of
GOODNESS
Phil B. Crosby, Quality is Free
June 16, 2010
Slide 11
AmiBug.Com, Inc.
Joseph Juran
Quality is fitness for use

Quality Control
Handbook
June 16, 2010
Slide 12
AmiBug.Com, Inc.
Gerald M. Weinberg
Quality is value to some person
Exploring Requirements
Quality Before Design
Dorset House
June 16, 2010
Slide 13
AmiBug.Com, Inc.
Edsger W. Dijkstra
Program testing can be used to show
the presence of bugs, but never to show
their absence
June 16, 2010
Slide 14
AmiBug.Com, Inc.
Watts S. Humphrey
A even the most
experienced software
engineer injects about one
defect for ten lines of code
A
June 16, 2010
Slide 15
AmiBug.Com, Inc.
C. Northcote Parkinson
Parkinsons Law:
Awork expands so as to fill the
time available for its
completionA
June 16, 2010
Slide 16
AmiBug.Com, Inc.
James Bach
The classical approach to test design is like playing

20 Questions by writing out all the questions in
advance.
June 16, 2010
Slide 17
AmiBug.Com, Inc.
Purpose of Testing
Common definition:
To find bugs before our customers do!
Broader definition:
The role of testing is to provide objective input to
facilitate business decisions!
Keeps stakeholders aware of all issues or
concerns that relate to shipping a product!
June 16, 2010
Slide 18
AmiBug.Com, Inc.
Bug Defined
To make our job more fun, whenever
we have a concern with software, we
call it a bug.
June 16, 2010
Slide 19
AmiBug.Com, Inc.
Its all about people! (and the occasional
bug too)
June 16, 2010
Slide 20
AmiBug.Com, Inc.
10
Context Drivers
June 16, 2010
Slide 21
AmiBug.Com, Inc.
Context Drivers - BTO

Business
Value
To whom?
Why?
Technology
Solutions
Organization
Corporate Structure
Team Structure
Roles and Responsibilities
June 16, 2010
Slide 22
AmiBug.Com, Inc.
11
June 16, 2010
Slide 23
AmiBug.Com, Inc.
Context Listeners
Find Sources
Monitor Drivers
Anticipate Change
React
June 16, 2010
Slide 24
AmiBug.Com, Inc.
12

Get Ready, Get Set,
Cause here it comes
June 16, 2010
Slide 25
AmiBug.Com, Inc.
Turbulence
(.wav)
June 16, 2010
Slide 26
AmiBug.Com, Inc.
13
Unprepared
June 16, 2010
Slide 27
AmiBug.Com, Inc.
Sharpen Testing Skills
Thinker
Detective
Reporter
Diplomat
Negotiator
Cheer Leader
Pragmatist
June 16, 2010
Slide 28
AmiBug.Com, Inc.
14
Philosophy
We have precious little time to run tests!
We must always be prepared!
June 16, 2010
Slide 29
AmiBug.Com, Inc.
Time
June 16, 2010
Slide 30
AmiBug.Com, Inc.
15
- Who manages them?

- How are they prioritized?
- Where can I find them?
- Are the communicated?
- Do they get reprioritized?
- Are business drivers known?
- Are technical risks known?
Getting
Things Done
REQ
FLOW
BUG
FLOW
Development
- Who manages them?

- What are they?
- Where can I find them?
- When are they updated?
- Why are they changing?
- How are they evolving?
- Do we observe turbulence?
June 16, 2010
Release
Cycle
- Are builds delivered?

- Where do developers work?
- Configuration management?
- Source control? Baseline?
- Transition? Periodic?
- Smoke tests?
- Owners:Dev IT DBA SQA?
Slide 31
AmiBug.Com, Inc.
BUILD
DAILY
Getting Things Done

Adapt to change
Revised risks?
New test objectives?
Triage Testing
Assign testing team members.

Analysis and exploration to more senior team members
Prioritize Bugs
Relative importance of testing objective?

Any test objective more important than any other?
Track Progress
Total budget effort

Spread across testing objectives
Smoke Test
Should the new build be tested at all?

On failure continue with previous build in test.
FAST Test
Each area of functionality has a simple test.

Is functional area stable enough to test
Regression Test
Does application still work as expected?

Did we accidentally break something?
Confirmation Test
Have bugs really been fixed?

Double check in test lab for each bug!
Stress Testing
How well does the application behave in harsh conditions?

Treated as an experiment.
June 16, 2010
Slide 32
AmiBug.Com, Inc.
16

Test Triage
June 16, 2010
Slide 33
AmiBug.Com, Inc.
Plan to support change
Yoda
"No! Try not, Do. Or do not.

There is no try."
June 16, 2010
Slide 34
AmiBug.Com, Inc.
17
Testing Ideas
Collect all testing ideas you can find!
List
Sort
Organize
Shuffle
June 16, 2010
Slide 35
AmiBug.Com, Inc.
Testing Ideas
How to find them?
Does system do what it is suppose to do?

Does the system do things it is not supposed to?
How can the system break?
How does the system react to its environment?
What characteristics must the system have?
Why have similar systems failed?
How have previous projects failed?
June 16, 2010
Slide 36
AmiBug.Com, Inc.
18
Testing Ideas
Capture testing ideas
Collect testing ideas

From testing ideas build a
series of testing objectives
Each can be assigned as
work to testers
Each can include all, part of,
or multiple testing ideas
June 16, 2010
Slide 37
AmiBug.Com, Inc.
Testing Ideas
I often use Index Cards

Unique id
One testing idea per card
Colour indicates source
Shuffled and reviewed
Organized and reorganized
Sorted, grouped, prioritized and collected
June 16, 2010
Slide 38
AmiBug.Com, Inc.
19
Test Idea Sources
Capabilities
Failure Modes
Quality Factors
Usage Scenarios
Creative Ideas
States
Data
Environments
White Box
Taxonomies
June 16, 2010
Slide 39
AmiBug.Com, Inc.
Testing Ideas
Investigative
approaches
We become truffle
snorting pigs and try to
find useful information in
all evidence we discover
We can even get good
ideas from out of date
sources
June 16, 2010
Slide 40
AmiBug.Com, Inc.
20
Testing Ideas
Capabilities
Use cases
Functional
requirements
Documented
requirements
Implicit requirements
June 16, 2010
Slide 41
AmiBug.Com, Inc.
Testing Ideas
Failure Modes
What can break?
Reaction to invalid input?
How does software
behave in constrained
environment?
Memory
Disk Space
Network Bandwidth
CPU capacity
Shared resources
Stress, Load, Volume

June 16, 2010
Slide 42
AmiBug.Com, Inc.
21
Adaptability
Accessibility
Auditability
Availability
Continuity
Dependability
Expandability
Functionality
Integrity
Interoperability
Maintainability
Operability
Portability
Reliability
Re-usability
Scalability
Security
Serviceability
Testability
Usability
Application service provider

Automatic content generator
Customized access
Database access
Delivery
Document access
File sharing
Informational
Interactive
Transaction oriented
User-provided content
Workflow oriented
High Focus
Medium Focus
Low Focus
June 16, 2010
Quality Factors Importance

Different Application Types
Slide 43
AmiBug.Com, Inc.
Testing Ideas
Usage Scenarios
Identify classes of
users
Identify how users
will use system
Describe scenarios
Use Story board or
similar approaches
Identify variations
June 16, 2010
Slide 44
AmiBug.Com, Inc.
22
Testing Ideas
Creative
approaches
Action verbs
Mind Maps
Soap Operas
Lateral Thinking
June 16, 2010
Slide 45
AmiBug.Com, Inc.
Testing Ideas
power up
service
needed
reset button
idle
coin inserted
inserting
coins
coin return
no cups
OR no coffee
OR sensor jam
cup removed
coin return
make
coffee
button pushed
right amount
entered
user
choose
State Models
June 16, 2010
Slide 46
AmiBug.Com, Inc.
23
Testing Ideas
Data
Flow
Structure
Create
Update
Change
June 16, 2010
Slide 47
AmiBug.Com, Inc.
Testing Ideas
Environment
Hardware
Software
Operating systems
Locales
Browsers
Plug-ins
Co-dependent software
June 16, 2010
Slide 48
AmiBug.Com, Inc.
24
Testing Ideas
White Box
Design
Internal structure
Code
June 16, 2010
Slide 49
AmiBug.Com, Inc.
Testing Ideas
Bug taxonomies
Collections of possible bugs
Appendix A of Testing
Computer Software, Kaner,
Falk, Nguyen
Boris Biezer Taxonomy Otto
Vinter manages
Shopping cart taxonomy Giri
Vijayaraghavan
June 16, 2010
Slide 50
AmiBug.Com, Inc.
25
Which test?
Impact estimation
Triage testing ideas
For each test idea guesstimate:
benefit of implementation
consequence of implementation
benefit for not implementing
consequence of not implementing
How credible is the information?
June 16, 2010
Slide 51
AmiBug.Com, Inc.
Which test?
Test Idea Rejection What If?
If the cost/benefit does not make business

sense then consider implementing:
part of the test, could that lead to part of the
benefit at a more reasonable cost?
more than the stated test, would that generate
more benefit?
a different test than the stated idea, could that
generate more benefit for less cost?
June 16, 2010
Slide 52
AmiBug.Com, Inc.
26
Test Triage
Test Triage Meeting
Review Context
Business
Technical
Information since last

triage
Test results
Bug results
New testing ideas
June 16, 2010
Slide 53
AmiBug.Com, Inc.
Test Triage
Allocate Testing Assignments to Testers
Make sure testers know context

Best thing to test
Best person to test it
Best people to explore it
Best lead
Are subject matter experts required
June 16, 2010
Slide 54
AmiBug.Com, Inc.
27
Test Triage
Life of a test idea
a.
b.
c.
Comes into existence

Clarified
Prioritized
a.
b.
c.
d.
e.
f.
d.
Test Now (before further testing)

Test before shipping
Nice to have
May be of interest in some future release
Not of interest in current form
Will never be of interest
Integrate into a testing objective
June 16, 2010
Slide 55
AmiBug.Com, Inc.
Which test is next?
Questions
Given state of project, state of business, state of
technology, our abilities, our experience and our
history, what we know and what we do not know,
what should we test next?
How much effort are we willing to spend
continuing to test this project?
Can we ship yet?
June 16, 2010
Slide 56
AmiBug.Com, Inc.
28
Which test is next?

Magic crystal ball
If it existed how would you use it?

What question would you ask?
What question would it ask?
June 16, 2010
Slide 57
AmiBug.Com, Inc.
Deciding what not to

test?
Time pressure
Should we skip a test?
If test failed could system still be of
value to some stakeholder?
If test was skipped could important
bugs have been otherwise found?
June 16, 2010
Slide 58
AmiBug.Com, Inc.
29
Guidelines and
Decisions
Get Started Right
To each stakeholder
risk of failure
consequence of failure
value of success
how much certainty do we have
is it a wild guess or an absolute
truth?
June 16, 2010
Slide 59
AmiBug.Com, Inc.
Bottom Line
Get Started Right
My experience is that it is better to

omit a test on purpose than to skip it
because you ran out of time or
forgot about it!
Systematically collecting, evaluating

and triaging testing ideas helps me
decide what not to test - at least for
now?
June 16, 2010
Slide 60
AmiBug.Com, Inc.
30

Exploratory Testing
June 16, 2010
Slide 61
AmiBug.Com, Inc.
Mandate to explore
William Clark
Meriwether Lewis
The object of your mission is to explore the Missouri river,

& such principle streams of it, as, by its course and communication
with the waters of the Pacific ocean...may offer the most direct &
practicable water communication across this continent for the
purposes of commerce.
- Thomas Jefferson's letter to Meriwether Lewis, June 1803
June 16, 2010
Slide 62
AmiBug.Com, Inc.
31
Make intelligent
decisions
Take notes
about your
decisions
Map out
where you
have been
June 16, 2010
Others can
use the
result Slide 63
AmiBug.Com, Inc.
Chart as you explore

Further
exploration
yields a
good idea of
the state of
the world!
One bit at a
time
June 16, 2010
Slide 64
AmiBug.Com, Inc.
32
Exploration Notes
- Tabular
- Chronological
- Schematic
- Point form
- Concise
June 16, 2010
Slide 65
AmiBug.Com, Inc.
Exploratory Testing
Test Cases
Not known in advance
Defined & executed on the fly while you learn
about the product
Map Making Skills

Consistent note taking style
Practice
June 16, 2010
Slide 66
AmiBug.Com, Inc.
33
Exploratory Testing
During test we must capture
Function, options or sub-functions being explored

Test cases attempted
Comments, notes, images or attachments
Hints, reminders and observations which may be useful to
future testers
Date, Platform, Build or Configuration under test
Name of person running test
Oracles, strategy to assess correctness
Other relevant details
June 16, 2010
Slide 67
AmiBug.Com, Inc.
An Exploratory Test
Process
Confirm Test Objective

Ensure context known
Kick Off
Ensure HW and SW OK
All tools available
Chunk of 90 to 120 min
Test, Plan, Discover
Prepare
Wrap up
Collect all notes data
Run
Review results with

Test Lead
Complete
Review
Reassess goals
Piece together map
June 16, 2010
Follow Up
Slide 68
AmiBug.Com, Inc.
34
Light Test Idea

Workflow
June 16, 2010
Slide 69
AmiBug.Com, Inc.
Light Test Idea Workflow
Reject
Enter
Idea
Rejected
Prioritize
Test Later
Entered
Prioritize
Reorganize
Change
Test Now
Elaborate
Reconsider
Prioritize
Elaborated
Run
Do Not
Test
Test Ran
June 16, 2010
Slide 70
AmiBug.Com, Inc.
35
Comprehensive Test
Idea Workflow
June 16, 2010
Slide 71
AmiBug.Com, Inc.
Identify
Duplicate
Get
Idea
Comprehensive Test Idea

Workflow
Redundant
Recapture
Exists
Capture
Gist
Changed
Refactor
Captured
Clarify
Punt
Clarified
Accept
Punted
Open
Prioritize
Reorganize
Decide
Approach
Prioritize
Test Now
Prioritize
Reconsider
Prioritize
Test Soon
To Be
Tested
Assign to
Elaborate
Assigned
to
Elaborate
Test Later
Elaborate
Elaborated
Do Not
Test
Assign to
Run
Assigned
to
Run
Run
Test Ran
June 16, 2010
Slide 72
AmiBug.Com, Inc.
36
Finished?
How do you know you are finished?
June 16, 2010
Slide 73
AmiBug.Com, Inc.
You know you are

finished when
the only bugs left are the ones are

acceptable (based on your objective
test team input) ...
June 16, 2010
Slide 74
AmiBug.Com, Inc.
37
You know you are

finished when
the only bugs left are the ones are

acceptable (based on your objective
test team input) ...
At least for now!

June 16, 2010
Slide 75
AmiBug.Com, Inc.
Thank You
Questions?
June 16, 2010
Slide 76
AmiBug.Com, Inc.
38
Just-In-Time
Testing Skills Exercise
First Visit
Holodeck
Level of Sophistication
Touch to Know
Roles
Stereotypes
Impressive
Background noise confusion
Dress the part
Get into PERSONA
Period Costumes
Tools to see - Visor
How does it work?
The real London was ...
Computer illusion
Distant perspective
Watson takes notes
Simulate environment
Images so perfect
Computer fools you in other ways
I say Holmes were should we head?
Kid runs through be chased "Stop It" distracton
He stole my goods
No - it is a ruse
Holmes knows which was to go
Question what you are doing?
Question what is over here
Running youth was a ploy
The real crime
Know victim
Saw plaque read the sign
Put plaque and rope together to derive conclusion
Deduce
Unexpected snakes
You didn't deduce anything
Reasoning
Definition of deduction
Variation on a theme
All he knows is stored in his memory bank
Original thought
It is not possible
Circuits would short out with an original mystery
It's elementary dear data
We will see whos cicuits will short out
COP OPENS SCENE - AUTHORITY FIGURE
Wear cool hats
Observations
Dupe of a gang of crooks

Saw rope hanging from bell
Enabled me to deduce
Meet a most distasteful and untimely demise
Fraud
Recognize elements from two different stories
From general to specific
Is that not the way Sherlock Holmes worked
Now do you see my point
Inspiration
True strengths of Holmes
Give credit for vaste knowledge
Truly original mystery
Wait a minute
Cool hand signals
Smoke a pipe
Data looks through meat pie cart
Just-In-Time
Testing Ideas Exercise
www.amibug.com
Notes
Priority
Name
Technical Risk
Credibility
2

M
Technical Risk
Business
Importance
Bus Importance
Credibility
Source
Focus
Description
Date
Notes
Id
www.amibug.com
Priority
Name
Technical Risk
Credibility

M
Technical Risk
Business
Importance
Bus Importance
Credibility
Source
Focus
Description
Date
Id
www.amibug.com
Description
Focus
Id
www.amibug.com
Description
Focus
Id
Notes
Notes
Name
Priority
Technical Risk
Credibility
Technical Risk
Business
Importance
Bus Importance
Credibility
Source
Date
Name
Priority
Technical Risk
Credibility
Technical Risk
Business
Importance
Bus Importance
Credibility
Source
Date
Milk
Dark
Fudge
Hard Candy
White
Composition
Bitter
Semisweet
Swiss
Belge
Truffle
Praline
Bar
Traditional Chocolate
Configuration
Turtle
Bon Bon
Filled
Solid
Chocolates
Monitor status
Jelly
Viscosity
Semi Solid
Operator
Stops
Too Light
In Range
Batch reports
Weight
Auditor
Too Heavy
Two
Chocolate Wrapping Paper
Size
Chocolates
Three
Loader
Slow
Inputs
Conveyor Speed
High
Very Fast
Wrap-O-Matic
Users
Box wrapping materials

Unloader
Input Stream
Sparce
Ribbons
Empty Boxes
Boxed chocolates
Rejected chocolates
Regular
Random
Daily reports
Monthly reports
One
Medium
Enter manifests
Starts
Hollow
Contamination
Distribution
Health Inspector
Frequency
Ingredients match labels

Peanuts
Dense
Emergency repair
Manifest describing box chololate layout selection
Periodic maintenance
None
Maintainer
Thin
Wax
Paper
Tissue
None
Thread
Ribbons
Cord
Wire
Wide
Rectangular
Circular
Heart Shaped
Type
OEM Custom
Bag
Empty Boxes
Small
Medium
Size
Large
Single layer
Multiple layer
Configuration
Upgrades
Cleaning
Foil
String
Updates
Operator
Monitor status
Enter manifests
Batch reports
Auditor
Daily reports
Monthly reports
Chocolate Wrapping Paper
Chocolates
Loader
Ribbons
Empty Boxes
Box wrapping materials
Users
Wrap-O-Matic
Unloader
Boxed chocolates
Rejected chocolates
Contamination
Health Inspector
Ingredients match labels

Peanuts
Emergency repair
Periodic maintenance
Maintainer
Updates
Upgrades
Cleaning
The Wrap-O-Matic
Contents
Section I: Introduction ............................................................................................................. 3
1.1
Purpose ........................................................................................................................ 3
1.2
Scope ........................................................................................................................... 3
1.3
Definitions, Acronyms & Abbreviations ................................................................... 3
1.4
References .................................................................................................................. 3
1.5
Overview...................................................................................................................... 3
Section II: Overall Description ................................................................................................. 3

2.1
Product Perspective ................................................................................................... 4
2.2
Product Functions ....................................................................................................... 5
Section III:
Specific Requirements ........................................................................................ 5
3.1
External Interface Requirements .............................................................................. 6
3.2
System Features .......................................................................................................... 6
3.3
Performance Requirements ...................................................................................... 7
3.4
Design Constraints ...................................................................................................... 7
3.5
Software System Attributes ........................................................................................ 7
Section I:
Introduction
1.1
Purpose
The purpose of this Software Requirement Specifications document is to outline the requirements and
functionality of the Wrap-o-Matic, a machine designed to wrap chocolates.
1.2
Scope
The software this document describes is hereto referred to as WrapSoft, the software to be installed on the
embedded system that controls the physical hardware of the Wrap-o-Matic.
WrapSoft will control all functionality, timing, and reporting concerning the Wrap-o-Matic machine.
WrapSoft will allow operator manifest data entry describing a production run.
1.3
Definitions, Acronyms & Abbreviations

Inputs to the Wrap-o-Matic include the following:
Chocolates:
Specification of input chocolates including:
Composition
Configuration
Viscosity
Weight
Size
Input Stream Distribution Frequency and Pattern

Manifest:
Description of a production run including the box chocolate layout selection.
Paper:
Refers to the type of paper used to wrap chocolates
Ribbons:
Refers to the type of ribbon used to wrap chocolates
Empty Boxes:
Refers to the type of boxes wrapped chocolates are placed in including:
Box Shape
Box Size
Box Configuration
Wrap-o-Matic Users include:
Operator:
Refers to the operator of the Wrap-o-Matic, whose tasks include monitoring status,
Entering manifests, Starts, Stops
Auditor:
Refers to the auditor of the Wrap-o-Matic, whose tasks include reviewing Batch reports,
Daily reports, and Monthly reports
Loader:
Refers to the loader of the Wrap-o-Matic, whose tasks include loading materials into the
Wrap-O-Matic including wrapping paper, chocolates and ribbons.
Unloader:
Refers to the unloader of the Wrap-o-Matic, who is responsible for unloading Boxed
chocolates and Rejected Chocolates.
Health Inspector: Refers to the health inspector, who inspects the Wrap-O-Matic for Contamination, checks
whether Ingredient match labels, and for the presence of nuts.
Maintainer:
Refers to the maintenance personnel responsible for Emergency repair, Periodic
maintenance, Updates, Upgrades, and Cleaning
WrapSoft:
Wrap-o-Matic:
The software that will control the Wrap-o-Matic

The physical machine designed to wrap chocolates
1.4
References
This document complies with IEEE Standard 830-1998 for Software Requirement Specifications.
1.5
Overview
The remainder of this document contains a full description of the functionality of the Wrap-o-Matic
followed by specific requirements of the system.
Section II: Overall Description

2.1
Product Perspective
The Wrap-o-Matic performs the packaging step of a system designed to create boxes of chocolates. The
inputs to the Wrap-o-Matic (including chocolates, manifest, papers, ribbons, and empty boxes) can be
created using any method or machinery desired, subject to the size and shape constraints of the configured
inputs to the Wrap-o-Matic. The Loader loads these inputs into the Wrap-o-Matic. The output, packaged
chocolates can then be further boxed and shipped to the appropriate location using any machinery desired.
The Unloader is responsible for unloading the boxed chocolates for further processing.
2.1.1
System Interfaces
The Wrap-o-Matic interfaces with the remainder of the chocolate box creation system at the loading and the
unloading area.
Loading Area:
The system external interfaces to the Wrap-o-Matic providing chocolates, papers,

ribbons, and boxes.
Unloading Area:
The system external interfaces allowing for unloading boxed and rejected chocolates.
2.1.2
User Interfaces
Users interact with the Wrap-o-Matic through different interfaces depending on their roles:
Operator:
The Operator will interact with the console. WrapSoft provides functionality allowing the
operator to monitor the status of the Wrap-o-Matic, enter manifests, and start/stop the
machine.
Auditor:
The Auditor will interact with the console to request production reports. WrapSoft must
therefore provide functionality to create Daily, Monthly, and Batch reports.
Loader:
The Loader interacts with the loading areas of the Wrap-o-Matic.
Unloader:
The Unloader will interact with the unloading area of the Wrap-o-Matic.
Health Inspector:
The Health Inspector will interact with the console. The Health Inspector can pause
the Wrap-o-Matic and remove and inspect completed boxes of chocolates.
Maintainer:
2.1.3
The Maintaner will interact with the Wrap-o-Matic to ensure proper functionality and
maintenance. The Wrap-O-Matic console enables the Maintainer to update or upgrade WrapO-Matic firmware.
Operations
Input Manifest:
In this mode, the Wrap-o-Matic will enable the operator to input the Manifest information.
Running:
In this mode, the Wrap-o-Matic is packaging the chocolates.
Stopped:
In this mode, the Wrap-o-Matic has stopped packaging chocolates.
Data Logging:
In the background at all times the reporting functions of WrapSoft are monitoring and storing data.
Backup
All stored data in the Wrap-O-Matic may be backed up on a third party storage device at user-configurable
intervals.
Restore
Wrap-O-Matic data may be restored from previously prepared backups.
Restart
In the case of a malfunction, the system can be restarted after error conditions or malfunctions are cleared.
2.2
Product Functions
2.2.1
Wrapping & Ribboning Chocolates
The Wrap-o-Matic may takes individual chocolates and wraps them in paper and ties them with a ribbon.
The wrapped chocolates are then inserted into a box.
Paper available to wrap the chocolates:
Ribbon available to tie the chocolates:
2.2.2
None, Thin, Wax, Foil, Tissue

None, Thread, String, Cord, Wire, Wide
Boxing Chocolates
Once the individual chocolates have been wrapped and/or ribboned (if specified), the Wrap-o-Matic inserts
the finished chocolates into the selected box. The Wrap-o-Matic is designed to box chocolates with the
following parameters:
Type:
Size:
Configuration:
2.2.3
Rectangular, Circular, Heart Shaped, OEM Custom, Bag

Small, Medium, Large
Single Layer, Multiple Layer
Reporting
WrapSoft automatically performs all data logging and report creation in the background. This includes
Monthly, Weekly, and Batch Reports.
Section III: Specific Requirements

3.1
External Interface Requirements

3.1.1
User interfaces
3.1.1.1
The Wrap-O-Matic console consists of a display, keyboard and mouse.
3.1.1.2
The display is a 14 inch LCD monitor with a resolution of 1366x768 pixels.
3.1.1.3
The keyboard is a US 102 Key QWERTY Layout Keyboard are available for operator
data entry.
3.1.1.4
The mouse is PC style with two buttons.
3.1.1.2
The operator can use the console to stop and start the Wrap-O-Matic, and enter &
configure manifests (see 3.2.4.2 to 3.2.4.5).
3.1.1.3
The auditor can use the console to display and print Daily, Monthly, and Batch reports
(see 3.2.4.x).
3.1.1.4
There are twenty inbound conveyor belts to accept the chocolates loaded by the loader
(see 3.2.1.1).
3.1.1.5
There are four loading slots to accept paper
3.1.1.6
There are four spools to accept ribbons
3.1.1.7
There is one bin to accept empty boxes
3.1.1.6
There is an output conveyor belt that transfers the completed boxes of chocolates to the
unloader (see 3.2.3.1).
3.1.2
Hardware interfaces
3.1.2.1
No additional hardware interfaces are required.
3.1.3
Software interfaces
3.1.3.1
No additional software interfaces are required.
3.1.4
Communications interfaces
3.1.3.2
No additional communication interfaces are required.
3.2
System Features
3.2.1
Loading of Chocolates & Additional Material
3.2.1.1
There are twenty inbound conveyor belts.
3.2.1.2
There are four input paper trays.
3.2.1.3
There are four input ribbon spools.
3.2.1.4
There is a loading area where the empty boxes are loaded by the loader.
3.2.2
Wrapping & Boxing of Chocolates
3.2.2.1
Chocolates can be wrapped in Thin, Foil, Wax or Tissue paper, or not wrapped at all.
3.2.2.2
Chocolates can be tied in Thread, String, Cord, Wire or Wide ribbon, or not tied at all.
3.2.2.3
Chocolates can be placed in boxes in the pattern as designated in the manifest.
3.2.2.4
Chocolates can be placed in Rectangular, Circular, Heart shaped or OEM Custom
boxes, or in a bag.
3.2.2.5
Chocolates can be placed in Small, Medium, or Large boxes.
3.2.2.6
Chocolates can be placed in boxes with Single or Multiple layers.
3.2.3
Output of Chocolates
3.2.3.1
Completed boxes of chocolates are transferred to the unloader.
3.2.4
Monitor Control of the Wrap-o-Matic
3.2.4.1
The monitor has a machine status panel providing information on the current state of the
Wrap-o-Matic: current manifest information, rate and frequency of chocolate
processing, and a constantly updated batch report. This is the main display tab.
3.2.4.2
The monitor has a button to start the machine (commence processing with current
settings).
3.2.4.3
The monitor has a button to stop the machine (immediately cease processing with
current settings).
3.2.4.4
If the monitor is stopped and subsequently started, processing resumes as previously.
3.2.4.5
If the monitor is stopped and subsequently reconfigured, the Wrap-o-Matic will clear all
other chocolates from the system prior to starting the process with the new manifest.
3.2.4.6
3.2.4.7
3.2.4.8
The monitor has a secondary tab for all reporting purposes. From this tab, the auditor
can select a date range, the type of report (Weekly, Monthly or Batch reports), and
generate the reports.
When a report is requested, it is displayed on the screen. On this report display there is a
button offering to email or print the report.
The monitor has a reset button that will completely purge all materials currently being
processed by the Wrap-o-Matic, and reset WrapSoft to the default manifest.
3.3
Performance Requirements
3.3.1
The Wrap-o-Matic supports and requires only one terminal and a single user.
3.3.2
There will not be user accounts. WrapSoft will have a simple password protected interface (see
3.5.3).
3.3.3
There are no strict timing requirements on the system, however all user actions must be realized
within 10 seconds of instruction initiation.
3.3.4
The Wrap-o-Matic should complete one box of chocolates per ten seconds.
3.4
Design Constraints
3.4.1
Standards Compliance
3.4.1.1
FDA Food processing standards conformance.
3.5
Software System Attributes

3.5.3
Security
3.5.3.1
The Wrap-o-Matic security will be controlled by WrapSoft, which has a simple
password protected interface known only to personnel with the appropriate privileges.
Operator passwords allow only login and operation of the Wrap-o-Matic. Administrator
passwords allow the password(s) to be changed, in addition to the privileges above.
Decision Table
Wrapping & Ribboning Chocolates
Wrap-O-Matic Decision Table

Wrapping Rules:
o The Wrap-O-Matic:
Disallows ribbons applied to unwrapped chocolates.
Disallows hollow chocolates tied with metallic ribbon.
Uses the gentle wrapping algorithm with tissues wrappers.
Uses the rapid wrapping algorithm whenever chocolates do not have
ribbons and do not have tissue wrappers.
Uses the gentle algorithm whenever hollow chocolates are tied with
ribbons.
Uses the normal algorithm for all other cases.
Wrap-O-Matic Decision Table

Rules
Actions
Conditions
R01
R02
R03
R04
Viscosity
R05
R06
R07
R08
R09
R10
R11
R12
Hollow
Ribbon
Metallic
R13
R14
R15
Not Hollow
Other
None
Metallic or Other
None
Wrapper
Metallic
or
Paper
Tissue
None
Metallic
or
Paper
Tissue
None
Metallic
or
Paper
Tissue
None
Metallic
or
Paper
Tissue
None
Metallic
or
Paper
Tissue
None
Disallow
Rapid
Algorithm
Normal
Algorithm
Gentle
Algorithm
The Wrapping and Boxing Chocolate Process
State Diagram
Operator
ud Primary Use Cases
Operation: Input Manifest
Use Case Sample
EnterManifest
ConfigureManifest
InputManifestInformation
Loader
InputMaterials
InputBoxes
InputRibbons
InputChocolates
InputPaper
Creating a New Manifest

This use case allows a new manifest to be entered into WrapSoft.
Use Case Name:
Participating Actors:
Flow of Events:
Entry Conditions:
Exit Conditions:
InputManifestInformation
Initiated by Operator
Communicates with Loader
1. The Operator activates the Input Manifest Information function of the console
2. WrapSoft responds by presenting an options page. The page includes the choice of
configuring or creating a manifest
3. The Operator chooses the option to create a manifest and choose a name for it
4. Wrapsoft responds by presenting a form to the Operator. The form includes the following
options: chocolate, paper, ribbons, boxes.
5. The Operator chooses the materials needed by scrolling through the scroll down menu of
each option. Once completed the Operator submits the form.
6. Wrapsoft receives the form, saves it in the database and notifies the Loader by a pop-up
dialog
7. The Loader reviews the submitted information and makes sure all the materials are in stock.
The loader then sends a confirmation to the Operator to begin.
The Operator is logged into Wrapsoft
The Operator stopped the Wrap-o-Matic
The Operator receives acknowledgement OR
The Operator receives an explanation why transaction cannot be completed
Configuring an Existing Manifest

This use case allows an existing manifested to be configured/altered and then stored into
WrapSoft.
1.
2.
3.
4.
Alternate Flow of Events:
Configuring an existing
Manifest
5.
6.
7.
8.
The Operator activates the Input Manifest Information function of the console
WrapSoft responds by presenting an options page. The page includes the choice of
The Operator chooses the option to configure a manifest
Wrapsoft responds by presenting a page of existing manifests. The page includes all
existing manifest by their respective names.
The Operator chooses the manifest needed.
Wrapsoft responds by presenting a form with the existing selected options of the manifest
chosen. The Operator chooses the materials to be configured by scrolling through the
scroll down menu of the option needed to be changed. Once completed the Operator
submits the form
Wrapsoft receives the form, saves it in the database and notifies the Loader by a pop-up
dialog
The Loader reviews the submitted information and makes sure all the materials are in
stock. The loader then sends a confirmation to the Operator to begin.
Creating a Manifest with Insufficient Material

This use case indicates to the operator that the created manifest does not have the material
needed to start packaging chocolates.
1.
2.
3.
4.
Error Flow:
Material needed out of stock
5.
6.
7.
The Operator activates the Input Manifest Information function of the console
WrapSoft responds by presenting an options page. The page includes the choice of
The Operator chooses the option to create a manifest and choose a name for it
Wrapsoft responds by presenting a form to the Operator. The form includes the following
options: chocolate, paper, ribbons, boxes.
The Operator chooses the materials needed by scrolling through the scroll down menu of
each option. Once completed the Operator submits the form.
Wrapsoft receives the form, saves it in the database and notifies the Loader by a pop-up
dialog
The Loader reviews the submitted information and makes sure all the materials are in
stock. One of the materials is out of stock. Therefore the loader sends an explanation
why the manifest cannot be completed at this time
Identifier
IDK00001
IDK00002
IDK00003
IDK00004
IDK00005
IDK00006
IDK00007
IDK00008
IDK00009
IDK00010
IDK00011
IDK00012
IDK00013
IDK00014
IDK00015
IDK00016
IDK00017
IDK00018
IDK00019
IDK00020
IDK00021
IDK00022
IDK00023
IDK00024
IDK00025
IDK00026
IDK00027
IDK00028
IDK00029
IDK00030
IDK00031
IDK00032
IDK00033
IDK00034
IDK00035
IDK00036
IDK00037
User (WrapSoft) stories for the Wrap-o-Matic

Description
WrapSoft can allow operators to login based on a password protected system.
WrapSoft can allow administrators to login based on a password protected system.
WrapSoft can allow administrators to change password(s) and permissions on the system.
WrapSoft can perform a system check.
WrapSoft can deliver messages to the operator based on system checks (these messages include
maintenance warnings, insufficient inputs (paper/ribbon/boxes), etc)
WrapSoft can accept new manifests.
WrapSoft can run a previously saved manifest.
WrapSoft can reconfigure a previously saved manifest, while overwriting or preserving the old
manifest as desired.
WrapSoft can start the processing of chocolates corresponding to a new manifest.
WrapSoft can continue processing an existing manifest while a new manifest is entered or
configured.
WrapSoft can alter the chocolate input speed and frequency by changing the speed of the inbound
conveyor belts.
WrapSoft can determine if a box of chocolates does not meet quality standards and reject the box.
WrapSoft can wrap individual chocolates with paper of type Thin, Foil, Wax or Tissue.
WrapSoft can place a printed manifest describing box configuration into each box of chocolates.
WrapSoft can box chocolates in boxes of type Rectangular, Circular, Heart Shaped, OEM Custom,
or Bag
WrapSoft can box chocolates in boxes of size small, medium, or large.
WrapSoft can box chocolates in boxes of configuraion single layer or multiple layer.
WrapSoft can tie boxes of chocolates with ribbon of type Thread, String, Cord, Wire, or Wide.
WrapSoft can accept and package inbound chocolates of composition Milk, Dark, Fudge, Hard
Candy, White, Bitter, Semisweet, Swiss, or Belge.
WrapSoft can accept and package inbound chocolates of configuration Truffle, Praline, Bar,
Traditional Chocolate, Turtle, Bon Bon, or Filled.
WrapSoft can accept and package inbound chocolates of viscosity Solid, Jelly, Semi Solid, or
Hollow.
WrapSoft can accept and package inbound chocolates of weight Too Light, In Range, or Too Heavy.
WrapSoft can accept and package inbound chocolates of size One, Two, or Three.
WrapSoft can turn off the Wrap-o-Matic.
WrapSoft can reset the Wrap-o-Matic.
WrapSoft can recover reports and manifests stored on a backup disk.
WrapSoft can backup reports and manifests.
WrapSoft can create Monthly, Weekly, and Batch Reports.
WrapSoft can continually monitor and store data for use in reporting functions.
WrapSoft will complete the packaging of one box of chocolates every 10 seconds.
WrapSoft will detect and report paper, ribbon, or box jams.
WrapSoft will monitor temperature levels in the machine and report a warning if temperatures rise
above 35 degrees.
WrapSoft can deliver finished boxes of chocolates to the unloader via the outbound conveyor belt.
WrapSoft can print reports.
WrapSoft can enter idle mode when no manifest is being processed.
WrapSoft can be connected to a network for purposes of global control, emergency shutoff, or
system override.
WrapSoft can continually monitor current status of the Wrap-o-Matic and display this to the operator
or administrator.
Just-In-Time
Purpose Exercise
Wrap-O-Matic
Robert Sabourin
President
AmiBug.Com, Inc.
Montreal, Canada
1.1
AmiBug.Com, Inc.
Wrap-O-Matic
Robert Sabourin ,
Software Evangelist
President
AmiBug.Com Inc.
Montreal, Quebec,
Canada
www.amibug.com
1.2
AmiBug.Com, Inc.
Wrap-O-Matic
New Product
First commercial release
Development is feature complete
Independent system test team
1.3
AmiBug.Com, Inc.
Wrap-O-Matic
New Business Model
We will be leasing the Wrap-O-Matic
During rush seasons customers will be
able to use multiple concurrent Wrap-OMatics
No features have been added
Input and output streams are shared
1.4
AmiBug.Com, Inc.
Wrap-O-Matic
Trade Show Demo
In advance of an upcoming trade show the
testing team is asked to identify possible
problems with the Wrap-O-Matic in order to
avoid them in a trade show context
Focus will be on showing off product to
Godiva
1.5
AmiBug.Com, Inc.
Wrap-O-Matic
New Feature
Ability to wrap individual chocolates with
ribbon has been added to the Wrap-OMatic.
Nothing else was supposed to have
changed.
1.6
AmiBug.Com, Inc.
Wrap-O-Matic
Bug Fix
A bug has been corrected in the paper
wrapping modules. The bug was related to
having multiple chocolates with different
paper types adjacent to each other in a box
of chocolates.
Nothing else was supposed to have
changed.
1.7
AmiBug.Com, Inc.
Wrap-O-Matic
Anticipated Health Inspection
A health inspector will be coming to audit
the Wrap-O-Matic. Special concern is
related to whether the machines
contaminate products.
We want to identify possible concerns in
advance.
1.8
AmiBug.Com, Inc.
Wrap-O-Matic
Performance Tuning
The Wrap-O-Matic has been modified to
improve throughput for the most commonly
occurring operational profiles.
No features of the product are supposed to
have changed.
1.9
AmiBug.Com, Inc.
Wrap-O-Matic
Competitive Product Comparison
A major competitor is releasing a product
(the Wrap-Zapper) designed to replace the
Wrap-O-Matic. They have great marketing
and aggressive sales teams but no track
record.
The testing team is challenged to find
problems, concerns, strengths and
weakness in the Wrap-Zapper.
1.10
AmiBug.Com, Inc.
Wrap-O-Matic
Localized Wrap-O-Matic
The new release of the Wrap-O-Matic has
been localized to allow operators to work in
their native languages and with locale
specific units of measure.
No features of the product are supposed to
have changed.
1.11
AmiBug.Com, Inc.
Wrap-O-Matic
Customer Acceptance Testing
A customer intends to purchase a Wrap-OMatic (as an off the shelf product).
The customer will run the acceptance tests
in a real production environment to confirm
the Wrap-O-Matic is acceptable.
Customer will not buy the Wrap-O-Matic if
the tests expose important concerns.
1.12
AmiBug.Com, Inc.
Wrap-O-Matic
Knowledge of Project context
Influences testing
ideas
priorities
oracles
Helps to focus testers
1.13
AmiBug.Com, Inc.
Wrap-O-Matic
It is important to understand WHY a
product is being tested.
1.14
AmiBug.Com, Inc.
Just-In-Time
Testing Articles
by Robert Sabourin
I am always on the lookout for new testing ideas. Some of the most valuable test ideas come to mind when I am
actually testing. Here is a list of ten sources of test ideas I use on Just-in-Time (JIT) testing projects.
Capabilities. Capability-based test ideas focus on confirming that an application does what it is supposed to do.
Requirement and functional specifications can be used as a source of capability-based testing ideas.
Failure Modes. Failure mode-based test ideas are what if questions that often are inspired by how a system is
designed. I look at all of the objects, components, and interfaces in a system and ask myself, what if they break or
exhibit some sort of unanticipated failure. Failure modes can be the result of harshly constrained system resources
or forced error conditions.
Quality Factors. Quality factors are characteristics of a system that must be present for the project to be successful. Quality factors are the ilities including: usability, reliability, availability, scalability, and maintainability.
Quality factor test ideas often involve experiments to determine if a quality factor is present. Examples include
performance, load, and stress testing.
Usage Scenarios. A usage scenario test idea challenges whether a user can achieve his tasks with the software
under test. To paraphrase the Kennedy inaugural addresswe ask not what the software does for the user, but
rather we ask what the user does with the software. Usage scenario-based test ideas involve identifying who is
using the system, what he is trying to achieve, and in what context.
Creative Ideas. Creative test ideas come from many sources. I often use deliberate lateral thinking techniques (for
example, Edward De Bonos Six Thinking Hats) to come up with cool and effective tests. I also use metaphors to
come up with testing ideas. I wonder what would happen if the Tasmanian Devil used the system. Perhaps a Dr.
Seuss story inspires some testing ideas. Perhaps great detectives or movies. Pretty much anything goes here.
States. When testing an application, a state model helps me come up with test ideas. For example, a transaction
goes through many states of existence from creation through approval, payment, and delivery. I use state models
to identify test ideas such as getting to states, exercising state transitions, and navigating paths through the
system.
Data. Data is a rich source of testing ideas. Data flow paths can be exercised, different data sets can be used, data
can be cooked up and built from combinations of different data types, and stored procedures can be verified. Test
ideas can be developed to create, update, and remove any persistent data.
Environments. Exploring how the application behaves in different operating environments is a rich source of testing ideas. Environment test ideas can relate to varying the platform, hardware, software, operating system, coresident third-party software, and locales.
White Box. White box test ideas come from reviewing low-level design, code, and data schemas. White box test
ideas include exercising the code, decisions, and paths through the program. White box test ideas look at the work
products of developers to find ways to challenge the application under test.
Taxonomies. One of my favorite sources of test ideas is bug taxonomies. These are organized, documented collections of bugs. I peruse taxonomies randomly in search of interesting bugs. If the bug could happen in my application, I come up with a test idea to expose it. Three taxonomies I often use are:
Appendix A of Testing Computer Software (Kaner, Falk, and Nguyen)
Boris Beizer Taxonomy (Otto Vinter)
Shopping Cart Taxonomy (Giri Vijayaraghavan)
46
BETTER SOFTWARE
APRIL 2008
www.StickyMinds.com

Just in Time Testing Course Materials

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Just in Time Testing Course Materials

Transféré par

Droits d'auteur :

Formats disponibles

AmiBug.Com,Inc.

Robert Sabourin, 2010

June 16, 2010

Robert Sabourin, 2010