Your SlideShare is downloading. ×
0
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
IIBA and Solvera May Event - Testing w Agile slides
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

IIBA and Solvera May Event - Testing w Agile slides

70

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
70
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 1Outline„  Level Set on What Is Agile„  Level Set on Life Cycles„  Start with the Ideal: Software Development„  Bring It Up a Level: Solution Delivery„  Talk About the Challenges of Enterprise Agile„  Talk About the Agile Goodness to Harvest, Now
  • 2. 2What Is AgileThe Myth The RealityIt’s Faster It’s Faster to First Benefit, NotFaster to All BenefitsRequirements? Design?Documentation? Planning? Nah.Yes, Some Up Front and thenRefine Continually.Needs Heroes Needs DisciplineNo Project Manager Project Manager with an Emphasison LeadershipNo Risk Management Retrospectives and FrequentInteraction with the BusinessNo Budget Initial Budget is Refined based onActual Experience.
  • 3. 3What Is ScrumFrom: http://msdn.microsoft.com/en-us/library/dd997796(v=VS.100).aspx
  • 4. A Collection of Life Cycles„  Solution Acquisition Life Cycle„  Solution Delivery Life Cycle„  Software Development Life Cycle4Do Scrum and Agile Apply to All Life Cycles?
  • 5. 5Scrum for Software Development„  The Up Front Stuff„  Product Backlog/Impact Map/Story Map„  Release Plan„  High Level Design„  Team Organization„  Expect Adjustments„  Development System Setup and Testing„  Test By Building A Real Feature„  The Rest of the Sprints„  Plan the Sprint (select from story map)„  Build and Test (with the business)„  Test Everything from Previous Sprints (with the business)} Iteration Zero
  • 6. 6Scrum for Software Development (cont.)„  Iterative„  Evolving the Deliverables Created to Date„  Evolving the Documents/Features Already Delivered andAccepted„  Iterating means re-testing and therefore demands automation„  Incremental„  Delivering Features and/or Benefits One at a Time„  Accepting Features and/or Benefits One at a Time
  • 7. 7Agile Testing – Story Level Tests„  Use Examples to Describe a Feature„  Implement Examples in a Test Automation Tool„  Demand a Testable Architecture„  Array of Choices:„  Inside/Outside the GUI„  Table/Scenario/Keyword Driven (i.e., Fitnesse/Cucumber/RobotFramework)„  User acceptance testing (UAT) is part of every sprint,not a critical path phase after delivery
  • 8. 8Agile Testing – Unit Level Tests„  Prescribe the design element in the form ofautomated tests„  Finish implementing the design element when all thetests pass„  Maintain these tests just like they are productioncode
  • 9. 9Agile Testing – All Tests„  These must be automated since they can be runhundreds or even thousands of times„  Simple experiment was to create a logging version ofa popular test automation framework and havedevelopers use that, then analyze the generated logfiles.„  Even a simple CRUD feature involved running some tests overone hundred times.
  • 10. 10Agile Testing – The Difference„  Initially it’s not about ‘testing’ but rather using testingskills for different purposes:„  To better understand requirements (story level tests) usingexamples. As many examples as we can imagine for any givenrequirement.„  To better explain a design (unit level tests). These are alsoexamples, specifically examples of how components should interactwith one another or how a specific programming unit should behave.„  THEN the usage of those tests changes„  For refactoring – improving the design without changing thebehaviour„  For regression testing – enabling changing or adding features withoutstress by re-running the tests quickly„  It’s valuing mean time to repair (MTTR) over mean timebetween failures (MTBF)„  It means establishing a cadence
  • 11. 11Agile Testing – More Differences„  The Product Manager Chooses the Features/Benefitto Deliver in a Sprint„  A Feature/Benefit Doesn’t Exist Unless Tests For thatFeature/Benefit Exist (story level and unit level)„  A Developer Automates Tests First as a Means of„  Better Understanding the Requirements (Story Level Tests)„  Determining and Communicating the Design (Unit Level Tests)Everyone on the Team is a DeveloperThat’s Right, No Business Analysts or Testers
  • 12. 12Scrum for Software Development (cont.)„  Solution: Pairing„  BA-oriented developer “pairs” with a coding-oriented developer andthis is considered GOOD„  Test-oriented developer “pairs” with a coding-oriented developerand this is also considered GOOD„  BA-oriented developer “pairs” with a test-oriented developer andthis too is considered GOOD„  Solution: Feature Advocacy„  Team plans the sprint together, reviews each feature/benefit thathas been designated for the sprint„  All skills contributing together up-front, everyone understands thetasks that contribute to the sprint„  Individual strengths and preferences are expressed in what tasks onechooses to complete for the sprint and in “coaching” others
  • 13. 13Scrum for Software Development (cont.)„  The Product Manager Accepts and Demonstrates theFeatures/Benefits Delivered in a Sprint„  This is HARD. It is not easy accepting a feature/benefit when theentire solution is not yet complete.„  This is REALLY HARD. It is not easy accepting a feature/benefiton behalf of others that are not in the room.„  A Retrospective (a form of testing) Gives the Team aChance to Improve for the Next Sprint
  • 14. 14Example: The Enterprise App StoreWhat Would It Take to Build from Scratch?
  • 15. 15Example: The Enterprise App Store (cont.)Story Template Story Test TemplateAs a <blank>I want to <blank>so that <blank>Given <blank>when <blank>then <blank>
  • 16. 16Example: The Enterprise App Store (cont.)Story Story Test„  As the store managerI want to review submittedappsso that I can approve orreject as per policy„  Given an app and aregistered dev,when they submit it forreviewthen it appears on the to-be-approved app listing„  Given an app on the to-be-approved app listingwhen the store managerapproves itthen it should appear in thenew app listing
  • 17. 17Scrum for Solution Delivery„  Commercial Off-the-Shelf (COTS) implementations„  Delivery combines installation, configuration,customization, and perhaps integration of thepackage
  • 18. 18Sidebar: What Happens During UAT When aProblem/Issue is Discovered?„  Whole Team Approach; Problem is immediately ‘triaged’ bybusiness and technical people together. Best team/memberto resolve picks up the problem.„  Could be problem/issue with training materials„  Could be the business process that is wrong„  Could be the software and it truly is a ‘defect’„  Backlog; Problem is grouped with other problems and workis prioritized; team can’t work on them all but works on asmany as they can.„  Acceptance; Business users/customer accepts theresolutions to the feature within the phase. Projectcontinues.
  • 19. 19Sidebar: What Happens During UAT When aProblem/Issue is Discovered? (cont.)„  Duration; a typical UAT phase for an enterprise project is 2-4weeks. A typical Scrum sprint is 2-4 weeks.„  Now replace the term ‘problem/issue’ in this conversationwith ‘need/gap’.„  Now string 10 of these ‘UAT’ phases together with planning/adapting workshops in between to steer the project.„  What do you get?„  Yup. You get an agile project.
  • 20. 20Scrum for Solution Delivery„  The Up Front Stuff„  Product Backlog/Road Map/Story Map„  Release Plan„  High Level Design„  Team Organization„  Expect Adjustments„  Development System Setup and Testing„  Test By Building A Real Feature„  The Rest of the Sprints„  Plan the Sprint (select from story map)„  Build and Test (with the business)„  Test Everything from Previous Sprints (with the business)Challenges …
  • 21. 21Scrum for Solution Delivery (cont.)„  Iterative„  Evolving the Deliverables Created to Date„  Evolving the Documents/Features Already Delivered andAccepted„  Iterating means re-testing and therefore demands testautomation and in a package development environment, doesnot always exist„  Incremental„  Delivering Features and/or Benefits One at a Time„  Accepting Features and/or Benefits One at a Time
  • 22. 22Scrum for Solution Delivery (cont.)„  The Product Manager Chooses the Features/Benefitto Deliver in a Sprint„  A Feature/Benefit Doesn’t Exist Unless Tests For thatFeature/Benefit Exist (story level and unit level)„  A Developer Automates Tests First as a Means of„  Better Understanding the Requirements (Story Level Tests)„  Determining and Communicating the Design (Unit Level Tests)
  • 23. 23Scrum for Solution Delivery (cont.)„  The Product Manager Accepts and Demonstrates theFeatures/Benefits Delivered in a Sprint„  This is HARD. It is not easy accepting a feature/benefit when theentire solution is not yet complete.„  This is REALLY HARD. It is not easy accepting a feature/benefiton behalf of others that are not in the room.„  A Retrospective (a form of testing) Gives the Team aChance to Improve for the Next Sprint
  • 24. 24Example: The Enterprise App Store„  What Would It Take to Buy a Package and Implementthe Enterprise App Store based on that Package?„  Do We Create the Story Map?„  Use Product Backlog/Impact Maps/Story Maps todescribe what’s needed?„  Release Planning?„  Sprint Planning?Yes
  • 25. 25Example: The Enterprise App Store (cont.)„  Story Level Tests?„  Unit Level Tests?Harder
  • 26. 26SummaryAs an agile team member,I want to have testing skillsSo that I can express requirements using examplesGiven an agile projectwhen the team releases a new featurethen tests describing that feature are also releasedFor package implementations, there are challengesthat would be a competitive advantage if they wereworked out:„  test automation„  the product manager role
  • 27. 27Summary (cont.)„  Testing skills are more useful than ever in describingrequirements„  To see the difference, if any, convert a set of requirements youare familiar with to the given-when-then style„  All of a sudden, by understanding the requirements better, youhave built the test plan for that requirement … and in the rightcontext you have already built the regression suite for thatrequirement„  Testing skills are more useful than ever in deliveringquality code„  Quality as measured by testability and maintainability at aminimum
  • 28. 28Questions„  adam.geras@solvera.ca„  @testfirst

×