STLDODN - Agile Testing in a Waterfall World


Published on

Everybody seems to be talking about agile these days, but most companies are still using a waterfall based methodology. Often, the team delivering the code uses a different process than the team responsible for software quality. In this presentation, Angela will discuss which agile tenets are worth incorporating into your daily testing activities in this situation and the impacts, both positive and negative, that you should expect. You will learn tips and tricks for introducing agile concepts into a waterfall environment slowly and successfully; methods that incorporate not just application lifecycle management tools, but a look at strategies for process improvement and in some cases good, old-fashioned psychology. Join Angela to find that low hanging fruit you can address quickly to become more agile, understand how to recognize and mitigate common pitfalls, and learn tools and techniques for managing an agile-under-waterfall testing effort.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

STLDODN - Agile Testing in a Waterfall World

  1. 1. St Louis Day of .NET Angela Dugan ALM Practice Manager Polaris Solutions
  2. 2. Of course this has NEVER happened to you... Right?
  3. 3. It is plan-driven, and plans are good right? Pert charts, Gaant charts, Critical paths, OH MY! Rules with an Iron Fist (A.K.A Microsoft Project) Pre-defined Start Dates & End Dates Teams operate in silos (Centers of Excellence) It is not the devil, but it CAN be evil if its prescribed techniques are abused
  4. 4. Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
  5. 5. Embraces uncertainty, software IS uncertain Empirical (based on experience and observation) Continuous improvement “Forecast” rather than “commitment” Self-organization and estimation by the “do-ers” It is not the devil, but it CAN be evil if its prescribed techniques are abused
  6. 6. Daily standup INCLUDES people from multiple disciplines Agile estimation leverages INSTINCT and EXPERIENCE to provide realistic expectations and more confident forecasts Backlog grooming focuses team’s efforts on customer’s current PRIORITIES An iterative process fueled by customer FEEDBACK ensures the team delivers the right functionality A constant FOCUS ON QUALITY ensures that quality is built-in, not tested in Retrospectives foster CONTINUOUS IMPROVEMENT by inspecting outcomes, sharing of best practices and honing the process
  7. 7. Waterfall Agile Requirements documents Just-in-time, informal requirements Occasional “customer” involvement Frequent “customer” involvement Start-to-finish Project Plan Plan for Sprint. Details are sketchy beyond that. Priorities shift based on new data. Tasks are assigned Assigned tasks are a bottleneck Potentially large team size Teams of 3 – 9 people Multiple phases, eventual delivery Working software each Sprint / Iteration Resistant to change Change is expected Contract says what we build, deliver Contract is a lot closer to T&E
  8. 8. Waterfall Agile Test cases created from Specifications Acceptance criteria Test cases are created Manually Manual Automate stubs from acceptance criteria Test cases are created Up front Started up front, continually refined Time commitment Large Still a lot, but a huge improvement Text execution is Well defined steps Some automation Near end of project Some defined steps Scenario-based/Exploratory Automation Executed early, often, continuously Tests executed by QA Team Everyone Weaknesses Documentation overhead Regression often squeezed Sensitive to change Coordination can be challenging Requires skilled automation resources
  9. 9. More collaboration Better overall visibility of status, progress, quality Less bureaucracy to get in your way Less impact from requirement churn Testing is EVERYBODY’S concern, ALL the time! Reduces resource bottlenecks Less focus on output, more focus on quality Everyone feels IS invested in the deliverable
  10. 10. More meetings (kind of) Less (perceived) accountability Less (unnecessary) documentation More requirement churn Shorter runway for writing tests May require a new “toolbox”
  11. 11. Change is hard, and this could be a BIG one FAR greater levels of discipline required by EVERYONE on an agile team (yes, really) Far more responsibility on Stakeholders and endusers Management support can be difficult to achieve & maintain, and it is CRITICAL for success! Agile shines a light on existing dysfunction
  12. 12. Agile for day-to-day dev/test activities Detect problems and continuously improve with Sprints Focus on Definition Of Done & delivering working software (a.k.a. value to customers) Waterfall-ish style for multi-team coordination Waterfall for environment release planning/management
  13. 13. Agile testing starts with requirements (ATDD) Continues throughout development (TDD, Unit Test Automation, CI) QA validates delivered functionality every day (Scenario/Exploratory Testing) Culminated with customers (UAT) Testing is not a practice, it is an attitude!
  14. 14. Teams may struggle to adapt to changes because significant effort has already gone into the initial requirements development and testing a.k.a “Throwing good money after bad.” Engineers may not be used to being “responsible for quality”. QA should never be testing code that has not already passed unit testing in the development phase. QA is still logically the last task in marking a user story done. Delays in development tasks still impact QA timelines. QA may not be used to inspecting requirements and asking questions up front. Addition of new user stories into the current iteration impacts EVERYONE. Include QA to ensure appropriate commitments and estimations are built in
  15. 15. Collaborate: daily stand-ups should include testers Adopt a process (if it’s all ad-hoc today) Adopt an integrated ALM tool (if you don’t have one) Shorten delivery cycles Question anything that “smells” Continuously improve, even if it is just the little things
  16. 16. Get your developers involved (TDD, unit testing) Automate regression tests Scenario based testing when appropriate Generate test case documentation whenever possible (from exploratory tests or acceptance criteria) Involve stakeholders in testing (UAT) Adopt a good toolset to assist with collaboration and automation
  17. 17. Gartner’s “Magic Quadrant” 2012 Ovum Decision Matrix for ALM 2013
  18. 18. Read what Forrester and Gartner have to say, then sh*t-can the reports and make your own decision Focus on tools that foster collaboration Many tools can fit the bill, use what feels good Best fit is not always “Best of Breed” Tools can foster efficiency and collaboration Tools cannot fix your people or process issues, they just automate them :- Expensive tools and fancy practices are useless if they aren't supportive of the approach you are willing to adopt.
  19. 19. No more Magna Carta Requirements documents Tests automated in VS and run via CI builds in TFS Tests created and managed in MTM Lab Management – ‘nuf said! Rich bugs, OMG Web tools
  20. 20. Drive: The Surprising Truth About What Motivates Us Daniel Pink Under $10 on Amazon
  21. 21. Succeeding with Agile Mike Cohn $35 on Amazon
  22. 22. Agile Testing Lisa Crispin Janet Gregory $40 on Amazon
  23. 23. Visual Studio Team Foundation Server 2012: Adopting Agile Software Practices: From Backlog to Continuous Feedback Sam Guckenheimer Neno Loje $30 on Amazon
  24. 24. Agile Software Testing in a Large Scale Project: Great Testing Blog: Another Great Testing Blog: Forrester ALM Blogs:
  25. 25. Free ALM Images with HOL: ALM Summit Video: Testing and Agile: The Team Approach ALM Summit Video: Agile Testing: ALM Summit Video: Exploratory Testing:
  26. 26.
  27. 27. Platinum Sponsors Gold Sponsors Silver Sponsors