life of a pragmatic tester
DESCRIPTION
There are not only one correct solution to many of the tasks we do within testing, we need a toolbox of many different tools and the pragmatism to acknowledge that we cannot use the same every time - there are no one size fits all :-)TRANSCRIPT
Life of a Pragmatic Tester
1
Gitte Ottosen
@Godtesen
A bit about the company
The company:
• Sogeti is a leading provider of structured testing solutions
• Part of the Sogeti Group, which brings together more than 20,000 professionals in 15 countries and is present in over 100 locations in Europe, USA and India
• Creators of the globally recognized methodologies TMap NEXT ® and TPI NEXT®
2
And About Me
About me:
• I AM CERTIFIED ISEB Practitioner, TMap test engineer, Certified Scrum master, Certified Agile Test (CAT) Trainer, TPI NEXT Foundation…And I am probably not done yet
• Worked in the Royal Danish Air force for 9 years
• Tested complex mission critical systems the last 19 years
• Read a lot of books… about a lot of “stuff”
• Participate in conferences – to learn and share
• Part of networks – to learn and share
• I was a scout for 10 years – learning by doing
• I am doing a lot of crafts and creative stuff that stimulates my brain
• Sometimes I am just looking at the fish in my aquariums …
3
Why this Presentation
• Context driven vs. Standards driven
• Agile vs. Waterfall/v-model
• Life is not black and white
• A tool belt with many tools
4
A Quote from Cem Kaner
5
Controversy good. Polarization bad.
In a socioeconomic milieu that seems bent on becoming even more
polarized, it is no surprise that some of the rhetoric within the software
testing community has been going that way too.
It sells well. It gets people excited. But I don’t see how polarization will help
us make products safer and more pleasant to use or improve our working
conditions as we make those products.
Cem Kaner: Context-driven.com
6
Let’s get started
Product Risk Analysis - TMap
7
Critical succes factors Change request Requirements
Business processes etc.
Allocating test design techniques
6
Client Determining risk class
Assignment and test goals
Creating test cases
Determining test intensity Result Risk Time Costs
Test execution
Risk table
8
Test goal Characteristic Damage Chance of Failure
Risk Class
1.1 Functions work correctly
Functionality H H A
User-friendliness
M L C
1.2 Payment methods accepted
Functionality M M B
Security H M B
1.3 Sale traceable Functionality M L C
2.1 Tickets printed fast and easily
Performance M L C
2.2 Prizes are found fast Performance L L C
2.3 FO application works as intended
Functionality M M B
Suitability M M B
.. .. .. .. ..
A visual risk assessment
9
Likelihood
Impact
Creating the Test Strategy
• Test strategy table
• Formal documentation
• Test strategy table in an agile context
• User story risk quadrants
• SFDIPOT
10
From Product Risk to Test strategy
11
Characteristic
- test goal RC UAT Test type Technique
Functionality
1.1 functions work correctly A functional test DCT-eq
1.2 payment methods accepted B I implicit with the regression test -
1.3 sale traceable C functional test DCT-eq
2.3 FO application works as intended B functional test ECT-mcdc
User-friendliness
1.1 functions work correctly C usability test SYN-checklist
Performance
2.1 tickets printed fast and easily C real life test -
2.2 prizes are found fast C real life test -
Security
1.2 payment methods accepted B user with knowlegde of security Checklist, EG
Suitability
2.3 FO application works as intended B process test PCT-test depth 1
Risk analyses Test strategy
IEEE 829
• Test plan identified
• Introduction
• Test items
• Features to be tested
• Features not to be tested
• Approacch
• Item pass/fail criteria
• Suspension criteria and resumption requirements
• Test deliverables
• Testing tasks
• Environmental needs
• Responsibilities
• Staffing and training needs
• Schedule
• Risks and contingencies
• Approvals
TMap
• Introduction
• Assignment formulation
– Scope
– Assumptions and preconditions
– Acceptants and acceptance criteria
• Documentation
• Test Strategy
• Approach
• Organization
• Infrastructure
• Management
• Test process risks and countermeasures
• Global estimation and planning
Formal Documentation
12
Agile Test Strategy
13
Source: Leo van der Aalst – No test levels needed in agile software testmanagement
User Story Risk Quadrants
14
Source: Pascal Dafour, http://pascaldufour.wordpress.com/
SFDIPOT
15
From Test Strategy to Test Plan
• Formal test execution plan
• Staying in the test strategy table
• The test execution board
• Using a tool
16
Formal Test Execution Plan, example
• Introduction
• Structuring the test
• Approach
• Test cases
• Test data
• Test environments and test stubs
• Test Organization
• The customer’s participation in the test
• Test Criteria
• Schedule
• Risks and mitigations
• Test Deliverables
17
From Strategy to Implementation
18
Source: Leo van der Aalst – No test levels needed in agile software testmanagement
The Test Board
19
Ready to test In progress Done Execute again
Impediments/
Defects
Test task Blocked
Using a Test Management ”tool”
20
But what About Test Cases?
• Scripted
• Scenarios
• Checklists
• Charters
21
• When?
• Formal acceptance test cases
• Inexperienced testers
• Changing group of testers
• Very complex test situations
• Regression tests?
• Test case title
• Purpose
• Requirement addressed
• Prerequisites
• Procedure steps
• Test result
Traditional - Scripted
22
Making Scripted more Creative
23
Checklist
24
Create new document
From local template
From network template
From blank
Open document
Position
Local drive
Network drive
..
Type
Same version
Earlier version
Illegal format
…
How to open
From explorer
From xx
…
…
Scenario Description
25
Exploratory Charter
Learn
Test design
Explore
Analyse
26
Communicating status
• Progress
– In sprints
– For test phases
• Final reports
– Internal
– External
27
Formal Reports
28
Becoming more visual – on page reports
29
Mindmap as dashboard
30
The Smiley Dashboard
31
It’s All About Context
32
33
One size doesn’t fit all