no time for testing: strategies to keep testing inside your sprints
TRANSCRIPT
Presented by:
Lesley Wallace, CSP, CSM, SA
Dilbert on Testing…
HELLOMy name is
Lesley Wallace
o Nit-picky tester since 2004• Web and Software testing (Manual &
Automated)• Automation tools: HP QTP/UFT,
TestComplete, Selenium, AutoIt/Watir
o Agile since 2013
o Scrum Master since 2014
o Certifications: CSP, CSM, SA, CSPO
How many are developing software using Scrum?
How much test automation is being used?
Do you find it difficult to test within a sprint?
From “101 Inspiring Quotes about Agile” - Front Row Agile
And More…
Who is responsible for Quality?
A) QA Team MembersB) DevelopersC) Business AnalystsD) Product OwnerE) All of the above
Everyone in the team is responsible for building in quality. ANYONE can be a tester, and everyone should create tests.
Challenge:
How can we change this?
QA cannot be part of a Scrum team because
automation doesn’t exist.
A company’s culture dictates:
Elevate Organization’s Agile Maturity
01 Identify your person
02 Dedicate team members 100%
03 Discover the “why” behind documentation
04 Stop using “# of bugs” as a metric
05 Drive the culture that EVERYONE owns quality
– Larry Apke, Agilist and Technology Executive
Identify Your “Person”
Focused on the Team’s success
Higher productivity, no competing priorities, teamwork, shared vision
Measurable Growth
Consistent velocity, time to learn new technology
Dedicate more than 50%
If 100% isn’t possible, don’t split 50/50
Don’t accept “It’s always been this way.”
Keep asking “Why?” until there’s a reason. If no reason, “Why not try something else?”
Seek out the minimum necessary
SOX? PCI? What do they really need to be happy?
Look for easy ways to satisfy documentation needs
Screenshots, automated notifications, tool access
Sprint 1 Sprint 2 Sprint 3 Sprint 4
# o
f B
ugs
Stop Using “# of Bugs” as a Metric
Defect Management ChangesMissed requirement, conversations
Bugs should be hard to findQuality practices = less defects intrasprint
Measure issues post-releaseTeam accountability
How do we manually test within a two week Sprint?
Won’t it just wind up mini-waterfall?
Challenge:
Let Your Stories be Your Guide
How are your User Stories broken down?
How many stories are you accepting into a sprint?
Do they take more than 2 days to code?
Are Testers involved in AC creation?
Do Testers use AC as their “expected result”?
How do you write your Acceptance Criteria (AC)?
Let Your Stories be Your Guide
But what about Regression? It’s not possible within a Sprint!
Add a Hardening Sprint!
Are you comfortable that the application will work when all stories are pushed to production?
Do you have a bit more time before a release is expected?
Challenge:
Splitting modules is risky
Keep integration paths intact for Regression testing
User Acceptance Testing
Hands on in prod-like environment
All additional tests go here
Penetration, security, performance; any extra tests not covered in team’s DoD
HARDENING IS NOT A SAFETY NET FOR MISSED
TESTS!
But we don’t have time for this “Hardening Sprint” business!
Modified Regression at the last Sprint
Where do you experience the most traffic?
What are the most critical features to keep your business in business?
Challenge:
Manual testing within a sprint is hard, but not impossible.
Add automation whenever you can. It helps. And there are tools out there for all needs & budgets, so give one a try!
01 Make changing organizational culture a priority
02 Decrease the scope of each story
03 Commit to coding and testing based on Acceptance Criteria
04 “Everyone owns quality” should be ingrained in teams
