Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Continuous Delivery without
Test Automation
Maaret Pyhäjärvi
Email: <maaret@iki.fi> | Twitter: maaretp
Maaret Pyhäjärvi
Ni...
A Bit of Background
• 3 years into a web based (.NET/C#)
product
• 1:8 tester:developer ratio
• Missing agile technical pr...
Where
does this
say fast?
Where does
this say
automation
?
http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous-
deployment
Going for Continuous Delivery
The Main Driver for Change:
Testing
Scheduled release
Feature 1
Feature 2
Feature 3
Feature 4
Testing
Feature 1
Feature 2
...
Enablers that Made Timing Just
Right
• Henri Karhatsu and #NoEstimates –
experience report
• Availability of Git in Visual...
Changing How We Managed Our
Work: Setting up Jira Kanban
Removed
hour &
story point
estimates
Agreed in
WIP for
each
phase...
Branches and Test
Environments
Feature Test
Environment
Feature branches
on-demand builds
“Developers think
this can be te...
Continuous Deployment but
Significant Lead Times
Mon Tue Wed Thu Fri Mon Tue Wed Thu Fri
Change to
Master
Integration
to m...
Things Can Look Different from
Different Perspectives
Exploratory Testing:
Better tests, better testers!
• An approach to software testing
– Emphasized freedom and responsibili...
Exploratory Testing Enables
Continuous Deployment
• Every Jira task gets planned for
– Sometimes we go with developer
test...
Exploratory Testing:
Learning & Modeling
”A day’s work”
Vision (“Sandbox”) Current Charter
Other Charters Details
Bug
Repo...
Changes
• Active discussion about schedules and
merging, and needs of testing in the
branches
• More pairing for testing t...
To End This With: Key
Observations on Ideas that Guide
Our Test Design
Testers don’t break
your code, they
break your illusions
about the code.
-- adapted from James Bach
Upcoming SlideShare
Loading in …5
×

Continuous Delivery without Test Automation @STPCon, San Diego

1,188 views

Published on

Talk 1.4.2015 at Software Testing Professionals Conference on Continuous Delivery without Automation.

Published in: Software
  • Be the first to comment

Continuous Delivery without Test Automation @STPCon, San Diego

  1. 1. Continuous Delivery without Test Automation Maaret Pyhäjärvi Email: <maaret@iki.fi> | Twitter: maaretp Maaret Pyhäjärvi Nimeä | Attribution (Finland) http://creativecommons.org/licenses/by/1.0/fi/ http://creativecommons.org/licenses/by/1.0/fi/deed.en
  2. 2. A Bit of Background • 3 years into a web based (.NET/C#) product • 1:8 tester:developer ratio • Missing agile technical practices: test automation non-existent • Scrum-like monthly releases for first 2 years – Releases late – Releases not tested well enough • Negative cycle of failing with estimates eating team morale • Jira in a central role with estimates and burndown
  3. 3. Where does this say fast? Where does this say automation ?
  4. 4. http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous- deployment Going for Continuous Delivery
  5. 5. The Main Driver for Change: Testing Scheduled release Feature 1 Feature 2 Feature 3 Feature 4 Testing Feature 1 Feature 2 Feature 3 Feature 4 R1 R2 R3 Done includes Tested Schedule over Quality SCRUM + SCHEDULED DELIVERY with continuous integration KANBAN + CONTINUOUS DELIVERY
  6. 6. Enablers that Made Timing Just Right • Henri Karhatsu and #NoEstimates – experience report • Availability of Git in Visual Studio without plugins • Problems with schedules in Scrum • Lean and value delivery focus in Product Management
  7. 7. Changing How We Managed Our Work: Setting up Jira Kanban Removed hour & story point estimates Agreed in WIP for each phase Agreed on swarming Updated issue types
  8. 8. Branches and Test Environments Feature Test Environment Feature branches on-demand builds “Developers think this can be tested” Development Test Environment Integration branch build-on-checkin “Developers think this can be released” Acceptance Test Environment Master branch with fixes and merges from integration on-demand builds “Release next morning”
  9. 9. Continuous Deployment but Significant Lead Times Mon Tue Wed Thu Fri Mon Tue Wed Thu Fri Change to Master Integration to master Feature to integration Developers drive the decision on what they want feedback on
  10. 10. Things Can Look Different from Different Perspectives
  11. 11. Exploratory Testing: Better tests, better testers! • An approach to software testing – Emphasized freedom and responsibility of an individual in a process where continuous optimization of value of information is important • “Any testing process that involves simultaneous (mutually supporting) learning, test design, and execution.” – James Bach & Cem Kaner • Disciplined, planned and controlled testing that emphasizes continuous learning • Research in Finland, Itkonen et al. 2007 – No significant difference in results for preplanned test cases and exploratory testing – More false alarms with test cases – Comparing overall effort: significantly more in test-case based testing Unknown territory Test-related learning Design of new tests Test execution Result interpretation 11
  12. 12. Exploratory Testing Enables Continuous Deployment • Every Jira task gets planned for – Sometimes we go with developer testing only – Sometimes we test extensively • Exploratory Planning – No set test cases – Talking to developers and reflecting to a model of of use created through earlier explorations – Actionable information first –principle – Production monitoring is an option for getting information
  13. 13. Exploratory Testing: Learning & Modeling ”A day’s work” Vision (“Sandbox”) Current Charter Other Charters Details Bug Reports Perception of quality and coverage Quality ReportDebriefing Tester Test Manager Past Results Obstacles Outlook Feelings ? # xCharter backlog of the future testing Out of budget Next in importance! #, ?, x, + 20:20:60 Session sheets of the past testing Idea of exploration Metrics summary Coachin g 13 Playbooks Coverage outlines
  14. 14. Changes • Active discussion about schedules and merging, and needs of testing in the branches • More pairing for testing the features • More group work on defining the features • Introducing Flowdock due to increased need to collaborate; integrating logs, emails • Focus on getting better (scope of test automation; refactoring; pairing and group work; individuals’ skills)
  15. 15. To End This With: Key Observations on Ideas that Guide Our Test Design
  16. 16. Testers don’t break your code, they break your illusions about the code. -- adapted from James Bach

×