Download to read offline
Uploaded byLesley Wallace, CSP, CSM, ICP-ACC, SA
No Time for Testing: Strategies to Keep Testing Inside Your Sprints
Lesley Wallace discusses the challenges and strategies of software testing within agile environments, emphasizing that quality is a shared responsibility among all team members. Key recommendations include evolving organizational culture, reducing story scope, and ensuring testing is integrated with the development process. Automation tools are encouraged to be utilized to facilitate testing within tight sprint timelines.
More Related Content
Similar to No Time for Testing: Strategies to Keep Testing Inside Your Sprints
No Time for Testing: Strategies to Keep Testing Inside Your Sprints
- 1.
- 2.
- 3. HELLO My name is LesleyWallace 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
- 4. How many aredeveloping software using Scrum? How much test automation is being used? Do you find it difficult to test within a sprint?
- 5. From “101 InspiringQuotes about Agile” - Front Row Agile
- 6.
- 7. Who is responsiblefor Quality? A) QA Team Members B) Developers C) Business Analysts D) Product Owner E) All of the above Everyone in the team is responsible for building in quality. ANYONE can be a tester, and everyone should create tests.
- 8. Challenge: How can wechange this? QA cannot be part of a Scrum team because automation doesn’t exist. A company’s culture dictates:
- 9. Elevate Organization’s AgileMaturity 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
- 10. – Larry Apke,Agilist and Technology Executive Identify Your “Person”
- 11. Focused on theTeam’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
- 12. Don’t accept “It’salways 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
- 13. Sprint 1 Sprint2 Sprint 3 Sprint 4 #ofBugs Stop Using “# of Bugs” as a Metric Defect Management Changes Missed requirement, conversations Bugs should be hard to find Quality practices = less defects intrasprint Measure issues post-release Team accountability
- 15. How do wemanually test within a two week Sprint? Won’t it just wind up mini- waterfall? Challenge:
- 16. Let Your Storiesbe 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?
- 17. Are Testers involvedin AC creation? Do Testers use AC as their “expected result”? How do you write your Acceptance Criteria (AC)? Let Your Stories be Your Guide
- 18. But what aboutRegression? 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:
- 19. Splitting modules isrisky 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
- 20. HARDENING IS NOTA SAFETY NET FOR MISSED TESTS!
- 21. But we don’thave 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:
- 22. Manual testing withina 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
- 23.