1
© 2011 Inspire Quality Services
Effective Agile Test Management
Agile Testing Days
2011
Fran O’Hara
Inspire Quality Services
e: fran.ohara@inspireqs.ie
w: www.inspireqs.ie
t: +353 (0)1 2854510
2
Inspire Quality Services
We provide Agile, Quality and Process Improvement Services such as
 Consulting/Coaching:
– Strategic advice and hands-on Coaching/mentoring in areas such as agile, testing, process
improvement, etc.
 Training public/inhouse:
– Agile: Certified/Advanced ScrumMaster, Succeeding with Agile/Scrum, Agile project
management, Agile Testing, Product Owner training, Lean/Kanban, etc.
– Testing (ISTQB Foundation and Advanced Test Manager/Analyst, Risk-based testing, Test design
techniques, Testing for developers, TMap®, Peer Reviews, UAT, etc.)
– Requirements/Business analysis
– Software project management
 Assessments
– Agile practices
– Industry standards and models such as CMMI®, TPI®, TMMi®, etc.
3
© 2011 Inspire Quality Services
Agenda
 Transitioning the Test Manager role
 Agile Test Strategy
 Test Management Process – estimating and
planning in Agile
 Test Management issues – metrics, process
improvement, etc.
4
© 2011 Inspire Quality Services
Some Underlying Shifts…
5
© 2011 Inspire Quality Services
Levels of Team Autonomy
Always give trust slightly in advance of demonstrated trustworthiness
“Light-Touch Leadership”
6
Line/functional Agile Test Management responsibilities
Support tester capability within agile teams
• Hiring/firing, overall management of professional test capability
• Career development/Performance management
• Training/coaching/mentoring - domain/product, agile test process/culture,
technology
• Communities of practice
• Specialist test support for agile teams (Performance, security, etc.)
Remove organizational obstacles
Agile test strategy
• Integrated whole team thinking
• Supporting overall quality e.g. supporting developers, automation approaches,..
Agile test process
• Test practices such as TDD
• Test role definition
• Balancing standardisation/organisational improvement with team empowerment?
Test Tool standardisation?
7
Project Test Management in agile –
some considerations
Traditional test manager responsibilities now done by agile team:
• Estimation and Planning
• Monitoring/control
Direct involvement in agile teams?
• ScrumMaster
• Team member for key developments – leading by example
Larger more complex projects
• Higher level involvement in planning and co-ordination
• Test Integration planning and co-ordination
• Reporting
• See also previous slide
8
© 2011 Inspire Quality Services
Agenda
 Transitioning the Test Manager role
 Agile Test Strategy
 Test Management Process – estimating and
planning in Agile
 Test Management issues – metrics, process
improvement, etc.
9
Agile Test Strategy
 Risks
– Similar product risks
– Regression risk with high level of change
 How many test levels?
– XP appears to advocate two as part of a predefined test strategy
 Unit and Acceptance (both automated as part of Test Driven
Development ideally)
 Is system test no longer required?
– Automation reduces regression risk
– Developers doing testing reduces risk of poor quality code
– But how can a test strategy/approach be method rather than product
based?
10
‘Acceptance’ Testing – is it enough?
 May not be…context/risk/strategy issue…
– May not be fully automated – partial regression strategy
needed
– Expand to fuller ‘system’ tests
 Functional testing
 Non-functional testing – performance, usability, etc.
– May still need end-to-end business scenario focused User
Acceptance test, user story interaction tests, etc.
– System integration testing issues
– Etc.
 Strategy and scheduling issue
– Adaptive, risk-driven
11
Agile Testing Quadrants
12
Testing within a Sprint
Automated
Acceptance/Story
based
Tests
Automated
Unit
Tests
Manual
Exploratory
Tests
Represent Executable
requirements
Represent Executable
Design specifications
Provides
Supplementary
feedback
13
Sprints and Testing Strategy
Sprint 1
Dev + Test*
Sprint 2
Dev + Test*
Sprint 3
Dev + Test*
Additional testing Additional Testing
*Sprint test = Automated Unit & Acceptance, Manual Exploratory
Within a Sprint may need to perform additional testing as part of a defined but adaptive testing
strategy e.g.:
– Additional exploratory testing
– Performance testing
– Usability testing
– Security testing
– System integration testing
– Combination/feature interaction testing
– Business cycle & end-to-end scenario testing – exercising multiple stories, end of month processing, etc.
 Note: Ideally any testing needed should be included within the Sprint rather than being
deferred….otherwise are we defining one ‘Done’ for Sprints and another for Release…?
Working software!!
Additional testing
…
14
Acceptance Testing
 Automated Acceptance Testing
– Design and Code for automation, cross functional test design
workshops, separate test design from implementation…
– Tools/Frameworks e.g.
 FIT/Fitnesse
 Cucumber - for Behaviour driven development
 WatiR – web application testing in Ruby
 Selenium – record/playback and scripting for web testing
– May still need exploratory testing for UI layer…
Web Server
Web Browser
Automation
Library
Web Server
Web Browser
Automation
Library
15
The Automation Pyramid
Unit
API/Service
GUI
Manual
tests
16
© 2011 Inspire Quality Services
Agenda
 Transitioning the Test Manager role
 Agile Test Strategy
 Test Management Process – estimating and
planning in Agile
 Test Management issues – metrics, process
improvement, etc.
17
Myth - Just Do It!
Planning is everything, the plan is nothing
- Dwight D Eisenhower
18
© 2011 Inspire Quality Services
IEEE 829 Test Plan?
Thought process – definitely; Big doc – no!
 High level Strategy/Approach: Implicit in release plan + ?
 What to test and not to test: Story Conditions/Done/Demo
 Test environment: Tasks in sprint backlog + separate doc?
 Test data: Tasks in sprint backlog
 How to test: Sprint planning + test case descriptions
 Entry criteria: Daily build and approved unit tests
 Exit/Acceptance criteria: Story Conditions/Done/Demo
 Deliverables: Tasks in sprint backlog
 Schedule: Sprint planning/task board/backlog
 Organization: Sprint planning/daily scrum meetings
 Problems and risks: Sprint planning + daily scrum meetings
19
© 2011 Inspire Quality Services
Sample Release Plan
Sprint 2 3 4
Start and End
Date
07 March
2007
20 March
2007
21 March
2007
03 April
2007
04 April
2007
17 April
2007
Items 1, 2, 3, 4, 6, 8, 9, 10,
11, 12
5, 7, 14, 15, 16, 18,
19, 20, 21
13, 17, 22, 23, 24
Velocity 17 20 10
Comments &
Assumptions
80% velocity
assumed
Easter holiday
Sprint 5 6 7
Start and End
Date
18 April
2007
01 May
2007
02 May
2007
15 May
2007
16 May
2007
29 May
2007
Items 25, 26, 27, 28, 29 30, 31, 32 33, 34, 35
Velocity 20 20 20
Comments &
Assumptions
First drop into
production
First of May is bank
holiday
Final drop into
production
20
© 2011 Inspire Quality Services
Test Estimation
 Done as part of story estimation and sprint planning
 Story estimation in backlog
– Typically story points
 Sprint planning – task estimation
– Typically effort in ideal hours
 Both can use planning poker (delphi) technique for a
team based estimate
– E.g. using fibonacci sequence 1, 2, 3, 5, 8, 13
21
© 2011 Inspire Quality Services
Agenda
 Transitioning the Test Manager role
 Agile Test Strategy
 Test Management Process – estimating and
planning in Agile
 Test Management issues – metrics, process
improvement, etc.
22
Test Management Issues
Metrics
• Burn rate & Delivered functionality
• Velocity & defects
Test Process improvement in agile
• Retrospectives
• Is there a role for guidance, organisational
improvement, etc.?
• Suitability of TPI, TMMi, etc?
Similarly re Tooling
• Balancing empowerment with Organisational support to
avoid tool proliferation and associated inefficiencies
23
Agile Test Management –
Some Dos and Don’ts
 Do
– Servant leadership
– Develop agile test competencies of testers & team
– Provide guidelines/support re test strategy,
process, tooling, DoD, etc.
– Support communities of practice
– Embrace agile – try working on a team
 Don’t
– Be prescriptive re process, tooling, …
– Write BUFP
– Forget non-functional
– Play a passive role in the agile transformation
– Worry!
24
Questions/discussion…
your test management challenges and
experiences...
Contact Details:
Fran.OHara@inspireqs.ie
25
© 2011 Inspire Quality Services
 What does “Done” mean for the project?...
– Spec written
– Code checked in
– Builds
– Unit tests complete successfully
– 80% code branch coverage on unit tests
– Usual coverage of boundaries, story
conditions/requirements, risks, etc.
– Within acceptable defect levels
– Non functionally tested (performance, security…?)
– Etc.
– Accepted by product owner
 If stories not ‘done’ by end of Sprint then they are put
back on backlog for the next Sprint planning
Done
26
CCC
As a <role>
I need <action>
so that <result>
Card
As a customer I search for users so
that I can view their details
Value: Med
Risk: Low
Estimate: 3 pts
Conversation
Confirmation
•I can find users
•I can use any search
criteria I need
•Once found I can view
details
•….
Remember –
different
users/personas
may have different
ways of working
and different
objectives
26

Agile Test Management

  • 1.
    1 © 2011 InspireQuality Services Effective Agile Test Management Agile Testing Days 2011 Fran O’Hara Inspire Quality Services e: fran.ohara@inspireqs.ie w: www.inspireqs.ie t: +353 (0)1 2854510
  • 2.
    2 Inspire Quality Services Weprovide Agile, Quality and Process Improvement Services such as  Consulting/Coaching: – Strategic advice and hands-on Coaching/mentoring in areas such as agile, testing, process improvement, etc.  Training public/inhouse: – Agile: Certified/Advanced ScrumMaster, Succeeding with Agile/Scrum, Agile project management, Agile Testing, Product Owner training, Lean/Kanban, etc. – Testing (ISTQB Foundation and Advanced Test Manager/Analyst, Risk-based testing, Test design techniques, Testing for developers, TMap®, Peer Reviews, UAT, etc.) – Requirements/Business analysis – Software project management  Assessments – Agile practices – Industry standards and models such as CMMI®, TPI®, TMMi®, etc.
  • 3.
    3 © 2011 InspireQuality Services Agenda  Transitioning the Test Manager role  Agile Test Strategy  Test Management Process – estimating and planning in Agile  Test Management issues – metrics, process improvement, etc.
  • 4.
    4 © 2011 InspireQuality Services Some Underlying Shifts…
  • 5.
    5 © 2011 InspireQuality Services Levels of Team Autonomy Always give trust slightly in advance of demonstrated trustworthiness “Light-Touch Leadership”
  • 6.
    6 Line/functional Agile TestManagement responsibilities Support tester capability within agile teams • Hiring/firing, overall management of professional test capability • Career development/Performance management • Training/coaching/mentoring - domain/product, agile test process/culture, technology • Communities of practice • Specialist test support for agile teams (Performance, security, etc.) Remove organizational obstacles Agile test strategy • Integrated whole team thinking • Supporting overall quality e.g. supporting developers, automation approaches,.. Agile test process • Test practices such as TDD • Test role definition • Balancing standardisation/organisational improvement with team empowerment? Test Tool standardisation?
  • 7.
    7 Project Test Managementin agile – some considerations Traditional test manager responsibilities now done by agile team: • Estimation and Planning • Monitoring/control Direct involvement in agile teams? • ScrumMaster • Team member for key developments – leading by example Larger more complex projects • Higher level involvement in planning and co-ordination • Test Integration planning and co-ordination • Reporting • See also previous slide
  • 8.
    8 © 2011 InspireQuality Services Agenda  Transitioning the Test Manager role  Agile Test Strategy  Test Management Process – estimating and planning in Agile  Test Management issues – metrics, process improvement, etc.
  • 9.
    9 Agile Test Strategy Risks – Similar product risks – Regression risk with high level of change  How many test levels? – XP appears to advocate two as part of a predefined test strategy  Unit and Acceptance (both automated as part of Test Driven Development ideally)  Is system test no longer required? – Automation reduces regression risk – Developers doing testing reduces risk of poor quality code – But how can a test strategy/approach be method rather than product based?
  • 10.
    10 ‘Acceptance’ Testing –is it enough?  May not be…context/risk/strategy issue… – May not be fully automated – partial regression strategy needed – Expand to fuller ‘system’ tests  Functional testing  Non-functional testing – performance, usability, etc. – May still need end-to-end business scenario focused User Acceptance test, user story interaction tests, etc. – System integration testing issues – Etc.  Strategy and scheduling issue – Adaptive, risk-driven
  • 11.
  • 12.
    12 Testing within aSprint Automated Acceptance/Story based Tests Automated Unit Tests Manual Exploratory Tests Represent Executable requirements Represent Executable Design specifications Provides Supplementary feedback
  • 13.
    13 Sprints and TestingStrategy Sprint 1 Dev + Test* Sprint 2 Dev + Test* Sprint 3 Dev + Test* Additional testing Additional Testing *Sprint test = Automated Unit & Acceptance, Manual Exploratory Within a Sprint may need to perform additional testing as part of a defined but adaptive testing strategy e.g.: – Additional exploratory testing – Performance testing – Usability testing – Security testing – System integration testing – Combination/feature interaction testing – Business cycle & end-to-end scenario testing – exercising multiple stories, end of month processing, etc.  Note: Ideally any testing needed should be included within the Sprint rather than being deferred….otherwise are we defining one ‘Done’ for Sprints and another for Release…? Working software!! Additional testing …
  • 14.
    14 Acceptance Testing  AutomatedAcceptance Testing – Design and Code for automation, cross functional test design workshops, separate test design from implementation… – Tools/Frameworks e.g.  FIT/Fitnesse  Cucumber - for Behaviour driven development  WatiR – web application testing in Ruby  Selenium – record/playback and scripting for web testing – May still need exploratory testing for UI layer… Web Server Web Browser Automation Library Web Server Web Browser Automation Library
  • 15.
  • 16.
    16 © 2011 InspireQuality Services Agenda  Transitioning the Test Manager role  Agile Test Strategy  Test Management Process – estimating and planning in Agile  Test Management issues – metrics, process improvement, etc.
  • 17.
    17 Myth - JustDo It! Planning is everything, the plan is nothing - Dwight D Eisenhower
  • 18.
    18 © 2011 InspireQuality Services IEEE 829 Test Plan? Thought process – definitely; Big doc – no!  High level Strategy/Approach: Implicit in release plan + ?  What to test and not to test: Story Conditions/Done/Demo  Test environment: Tasks in sprint backlog + separate doc?  Test data: Tasks in sprint backlog  How to test: Sprint planning + test case descriptions  Entry criteria: Daily build and approved unit tests  Exit/Acceptance criteria: Story Conditions/Done/Demo  Deliverables: Tasks in sprint backlog  Schedule: Sprint planning/task board/backlog  Organization: Sprint planning/daily scrum meetings  Problems and risks: Sprint planning + daily scrum meetings
  • 19.
    19 © 2011 InspireQuality Services Sample Release Plan Sprint 2 3 4 Start and End Date 07 March 2007 20 March 2007 21 March 2007 03 April 2007 04 April 2007 17 April 2007 Items 1, 2, 3, 4, 6, 8, 9, 10, 11, 12 5, 7, 14, 15, 16, 18, 19, 20, 21 13, 17, 22, 23, 24 Velocity 17 20 10 Comments & Assumptions 80% velocity assumed Easter holiday Sprint 5 6 7 Start and End Date 18 April 2007 01 May 2007 02 May 2007 15 May 2007 16 May 2007 29 May 2007 Items 25, 26, 27, 28, 29 30, 31, 32 33, 34, 35 Velocity 20 20 20 Comments & Assumptions First drop into production First of May is bank holiday Final drop into production
  • 20.
    20 © 2011 InspireQuality Services Test Estimation  Done as part of story estimation and sprint planning  Story estimation in backlog – Typically story points  Sprint planning – task estimation – Typically effort in ideal hours  Both can use planning poker (delphi) technique for a team based estimate – E.g. using fibonacci sequence 1, 2, 3, 5, 8, 13
  • 21.
    21 © 2011 InspireQuality Services Agenda  Transitioning the Test Manager role  Agile Test Strategy  Test Management Process – estimating and planning in Agile  Test Management issues – metrics, process improvement, etc.
  • 22.
    22 Test Management Issues Metrics •Burn rate & Delivered functionality • Velocity & defects Test Process improvement in agile • Retrospectives • Is there a role for guidance, organisational improvement, etc.? • Suitability of TPI, TMMi, etc? Similarly re Tooling • Balancing empowerment with Organisational support to avoid tool proliferation and associated inefficiencies
  • 23.
    23 Agile Test Management– Some Dos and Don’ts  Do – Servant leadership – Develop agile test competencies of testers & team – Provide guidelines/support re test strategy, process, tooling, DoD, etc. – Support communities of practice – Embrace agile – try working on a team  Don’t – Be prescriptive re process, tooling, … – Write BUFP – Forget non-functional – Play a passive role in the agile transformation – Worry!
  • 24.
    24 Questions/discussion… your test managementchallenges and experiences... Contact Details: Fran.OHara@inspireqs.ie
  • 25.
    25 © 2011 InspireQuality Services  What does “Done” mean for the project?... – Spec written – Code checked in – Builds – Unit tests complete successfully – 80% code branch coverage on unit tests – Usual coverage of boundaries, story conditions/requirements, risks, etc. – Within acceptable defect levels – Non functionally tested (performance, security…?) – Etc. – Accepted by product owner  If stories not ‘done’ by end of Sprint then they are put back on backlog for the next Sprint planning Done
  • 26.
    26 CCC As a <role> Ineed <action> so that <result> Card As a customer I search for users so that I can view their details Value: Med Risk: Low Estimate: 3 pts Conversation Confirmation •I can find users •I can use any search criteria I need •Once found I can view details •…. Remember – different users/personas may have different ways of working and different objectives 26