Welcome to the Keep Houston Agile Workshop
• Please put your phone on silent mode
• Note: This is an intermediate class
• Q&A will be taken at the close of this presentation
Lean Principle #2: Build Quality In
Speaker: Allan Watty
Key Objectives
Will
cover
• What do we mean by the phrase
• Why is this important?
• Key Practices to get us there
• Obstacles along the way
• Reference information
Concepts
Lean Software Principles are derived from Lean Manufacturing Principles:
1. Eliminate Waste
2. Build Quality In
3. Create Knowledge
4. Defer Commitment
5. Deliver Fast
6. Respect People
7. Optimize the Whole
Concepts
Why is this important?
Bank Statements sent to the Wrong People
Bar exam software failure sets off wave of lawsuits
London Airspace Closed Due to Software Malfunction
Software Glitch Accidentally Releases Prisoners
Software errors cost the U.S. economy $60
billion annually in rework, lost
productivity and actual damages.
Why is this important?
• Avoid lengthy end of development cycle: test, find defects, fix, re-test, repeat…
• It reduces cost of delays associated with recall, rework, and defect fixing.
• Avoid trying to test the quality in at the end.
• Find ways to build quality into our product/projects from the start.
• “Quality is not something that can be added to a product. Trying to add quality after the product has been built would be like adding baking powder to a cake after the cake has been baked. It doesn’t work.” Alexander Tarlinder
Implementation Sprint Review, Retro, planning Final Regression, bug fix,re-test….
week1 week2 week1 week2 week1 week2 week1 week2 week1 week2 week3 week4 week….
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Hardening Sprint
Assumptions
F
E
D D
C C
B B B
A A A A
Sprint 1 Sprint 2 Sprint 3 Sprint 4 GA
We are doing Agile development:• Incremental, Iterative, Adaptive• 2 - 3 week sprints include development and testing• Plan as you go, progress is shown with working software• Features are decomposed into Epics and Stories• Based on an empirical process control model
week1 week2 week1 week2 week1 week2 week1 week2
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Implementation Sprint Review, Retro, planning
Whole Team Approach to Quality
The stereotypical animosity between dev and QA is counterproductive!
Whole Team Approach to Quality
Foundation of A Great Team
Patrick Lencioni: The Five Dysfunctions of a Team
A Whole Team Approach To Quality
• Whole team is responsible for quality and testing
• Daily collaboration• Testing is a first-class central
practice• Building shared understanding
of features• Release & Sprint planning
• No Silos!• Start and finish together• Guiding development with
examples and tests• Learning together from
customers• Common definition of “READY”• Common definition of “DONE”.
Proactive collaboration
Close collaboration among Developers, QE, Product Owners:• The power of 3+• Shared ownership of the story.• Shepherd a Story/Feature from inception to completion• Technical Reviews: Stories, Design, Code, test cases, automation
scripts, defect triage etc.• Everyone tests!• Shared understanding of:
What is being built Conditions of success
• Nothing is thrown over the wall – there is no wall!• Work at a sustainable pace• Start and finish together
Acceptance Criteria
• Story Grooming is key
• Time for grooming must be allocated each sprint
• Grooming sessions are lead by PO with Dev and QE plus other roles as needed.
• Reviewed by the Three Amigos before the sprint starts
• Engineering stories need to be groomed!
• Additional story info: wireframes, constraints, architecture runway
• Backlog of “ready” stories two sprints ahead.
Use Gherkin format for Acceptance Criteria
As an internet banking customer I want to see a rolling balance for my everyday accounts so that I know the balance of my account after each transaction is applied
Acceptance Criteria 1:
Given that I have accessed my account
When I click on my account balance
Then the latest rolling balance is displayed
Acceptance Criteria 2:
Given that I have accessed my account
And my balance was $10,500.00
When I withdraw $500.00 form my account
Then the balance is not recalculated to display the latest total of $10,00.00
Care about code quality
• Lowering quality lengthens development time.”—First Law of Programming.
• The quality of code is inversely proportional to the effort it takes to understand it
• Simple Design:
➢ Passes the tests
➢ Reveals intention
➢ No duplication
➢ Fewest elements
➢ https://martinfowler.com/bliki/BeckDesignRules.html
• Good code should read like a story, not like a puzzle.
• Code must be written for people to read.
“We can’t be agile if our code sucks" Venkat Subramaniam
Test Driven Development
Cycle:
• Write a failing test
• Write the code to make the test pass
• Refactor the code to make it clean
Goal:
• TDD is a practice not a process
• TDD is about good design
• Automated tests are a side effect
Design for Testability
• How can I make it easy for all features to be:➢ Tested➢ Debugged in production
• How can I make it easy maintenance, enhancements and integration:➢ SOLID Design principles➢ Layered Architecture➢ Interface Programming➢ API Contracts
• How do I avoid creating the big ball of mud?➢ Domain Driven Design
SOLID Principles of Software Design
• Single responsibility
➢ A class should have one, and only one, reason to change.
• Open-closed
➢ You should be able to extend the behavior of a class, without modifying it.
• Liskov substitution
➢ Derived classes must be substitutable for their base classes.
• Interface segregation
➢ Make fine grained interfaces that are client specific.
• Dependency inversion
➢ Depend on abstractions, not on the concrete details of other classes.
Domain Driven Design
• An approach that places emphasis on the domain model and carrying it into implementation.
• A shared ubiquitous language based on the problem domain binds analysis and code models.
• Focuses on core domain model and collaboration between business experts and development team.
• Maintenance of domain model integrity helps avoid BBOM.
Domain Driven Design
Body of Knowledge:
• Cliff Notes:
➢ Domain-Driven Design Quickly by by Abel Avram & Floyd Marinescu
• Original idea:
➢ Domain Driven Design by Eric Evans
• Concrete examples:
➢ Implementing Domain-Driven Design by Vaugn Vernon
➢ Patterns, Principles, and Practices of Domain-Driven Design by Scott Millett and Nick Tune
Continuous Integration
• Frequent System-Level Integration and Testing
• Plan for integration tests with external systems
• Maintain consistent integration and testing infrastructure
Continuous Integration
• Implement automated builds on demand and by code check-in: Unit Tests Acceptance Tests Static Code Analysis Code Coverage reports Successful deployment Automated UI Smoke Test
• Use thresholds to drive build failure• Broken Automated acceptance tests = broken build• Stop the Line for broken builds
Automation Focus
• Automated acceptance tests for all new features
• Behind the UI (API layer) tests
• Large scale performance and reliability tests
• Small UI Smoke Test to run against every build
• Reduce manual regression test time
➢ Test Data, deployment and environment preparation
➢ Automation of repetitive manual tests based on ROI
• Research:
➢ Progress on UI Automation tools (avoid snake oil salesmen)
➢ Google Test Automation Conference
➢ Embrace DEVOPS tools
Automating Acceptance Tests
Automated Acceptance
Tests
Customer
Unit Tests
Code
Acceptance criteria Review
Refactor
SBE/ATDD/BDDFitNesseCucumberJbehavePython BehaveSpecflowRobot framework
TDD
Automating Acceptance Tests
• Collaborative effort by Developers and Testers• Should be done as part of Story Implementation• Use any one of these methods:
➢ SBE: Specification by Example➢ ATDD: Acceptance Test Driven Development➢ BDD: Behavior Driven Development
• Broken Automated acceptance tests = broken build!• Automated tests become part of your regression suite
• Reduces risk when late changes are necessary• Early warnings sign of broken functionality• Allows QE to focus on deeper, difficult manual tests.
Automating Acceptance Tests
• BDD is about communication and driving development
• Tests represent expectations of behavior the software should have, created before coding begins.
• Tests provide feedback to the team about how close we are to “Done” and provide living documentation for the application.
• Tests are written in plain descriptive English type grammar
• Tests use examples that clarify requirements
Behavior Driven Development in Action
27
Behavior Driven Development in Action
28
BDD cycleKey artifacts:1. Feature Files2. Step/Scenario definitions
Tools:1. Java, Jbehave2. C#, Specflow3. Ruby, Cucumber4. Python, behave!
Sample Feature File
30
As a [Shopper] I want [to put items in my shopping cart] so that [I can manage items before I check out]
Acceptance Criteria N (scenario)
Given I'm a logged-in User
When I go to the Item page
And I click "Add item to cart"
Then the quantity of items in my cart should go up
And my subtotal should increment
And the warehouse inventory should decrement
Agile Quadrants
Test Automation Pyramid
Exploratory Testing
Key practice to help drive, verify product quality
• Utilizes the concept of charters or tours to guide the work
• Time boxed into multiple sessions
• Provides feedback to stakeholders on observations
• Can lead to formal test cases, new defects, design changes
• Ideas from testing come from conversations in Release Planning, Sprint Planning, Story reviews:
➢ No one is sure how something works
➢ What happens if a change is made to an existing feature
What to do with Manual Test Backlog?
RISK
Damage(Cost of failure)
Usage frequency Damage / Use
Probability of failure
Quality(failure rate / defect
density)t
• Utilize support incidents and Root Cause Analysis output as additional test ideas.
• Review the likely use of each feature by customers.• Analyze the likelihood and the impact of failure of key
features.• Prioritize regression testing based on risk• Surround key functionality with unit and systems tests• Plan to automate key repetitive tests based on ROI
Root Cause Analysis
Pair work
Pairing team members may increase productivity:
• Many different styles of pairing work:
➢ Two developers for all code development
➢ Developer and Tester on a story
➢ Spontaneous pairing: refactoring, automation, interface definitions
➢ Tester and Product Owner
• Focus on solving a problem or delivering faster
• Cultural Challenges
• "Joy, Inc.: How We Built a Workplace People Love"
Agile Metrics
The whole team agrees on a set of metrics to guide there work:
• Velocity
• Build Thresholds exceeded
• Build failures over time
• Customer defects over time
• Sprint Velocity
• CLOC over time
• Bug count
• Mean Time To Repair
• Total number of tests; % passing; %failing
• Test Code coverage
Agile Metrics
Agile Metrics
Lead time and MTTR in the delivery process
Measuring Team Productivity?
Mike Cohn:
My advice is to abandon the pointless pursuit for a metric by which to judge the performance of knowledge workers such as product development teams and instead observe and evaluate those teams. You may never be able to pinpoint which team or person is “the best of all time,” but you don’t need to know that to succeed with agile.
Key Challenges on Agile teams
• Untested legacy code• Mini-Waterfalls• Testers are always behind• Short-cuts• Cone of Uncertainty• Clarity on requirements• Huge Manual Regression Backlog• Poor estimates • What should be automated?• Applications not designed for testability• Walls between different roles• Waiting to do all testing at the end does not work• Moving / unclear definition of “DONE”
Adopt Regular Release Cadence
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
Release Planning
Release Review 3/31/2016 6/29/2016 9/23/2016 12/16/2016
Beta Release 7/14/2016
GA Release 9/28/16
2016
Q1 - PSI Q2 - PSI GA Release Q4 - PSI
1/4/2016 4/4/2016 7/11/2016 10/3/2016
Summary
• Whole Team Approach• Power of 3• Agreement on Acceptance Criteria before Writing Code• Test First Development• Good design still matters• Automated Acceptance Tests• Exploratory and Risk Based Testing• Continuous Integration• Utilize key metrics to assess where team is at any point.• Pair Work• Learning from Customers
Key References
• Agile Testing, by Lisa Crispin
• ATDD by Example: A Practical Guide to Acceptance Test-Driven Development, by Markus Gärtner
• Lean-Agile Acceptance Test-Driven Development, by Ken Pugh
• BDD in Action by John Ferguson Smart
• Essential Scrum by Ken Rubin
• Continuous Delivery,, by Jez Humble and David Farley
• The FIVE DYSFUNCTIONS of a TEAM, Patrick Lencioni
• Developer Testing by Alexander Tarlinder
• Patterns, Principles, and Practices of Domain-Driven Design by Scott Millett, Nick Tune
• SPECIFICATION BY EXAMPLE by Gojko Adzic
Agile Leadership Network – Houston Chapter
• Venue: Sysco Corporation, 1390 Enclave Parkway.
• Meetings are held the 3rd Thursday of each month unless otherwise noted on the chapter’s website.
• Meeting format:
o 6:00pm – 6:30pm – Network with your fellow Agile practitioners
o 6:30pm – 8:00pm – Announcements and introductions, followed by our Featured Program
• Admission is Free
• Registration: http://alnhouston.org
Speaker Bio
SoftNAS, 2016 : Sr. Director Quality AssuranceABB Inc., 2012 – 2015: Senior Development ManagerPROS, 2005 – 2012: Development Manager, QA ManagerAspen Technology, 2003 – 2005: Development ManagerBMC Software, 1995 – 2003: Senior Development Manager
Education• B.S. Math & Biology, Lehman College, CUNY • M.S. Computer Science, NYU Polytechnic • M.B.A , University Of Houston Bauer College,Certifications: PMP, CSM, SAFe AgilistPresident – Agile Leadership Network Houston ChapterFormer Life: Musician, Math Teacher
Any Questions?
