Agile Testing


Published on

Given at AgilePalooza by Steve Ropa, VersionOne.

Published in: Technology, Education
  • Be the first to comment

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

No notes for slide
  • ______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • Agile Testing

    1. 1. Agile Testing
    2. 2. © 2011 VersionOne 2Steve RopaAgile CoachCertified Scrum MasterCertified Scrum Product Owner19 years software development11 years programming8 years director of development10 years Agile experienceXPScrumWelcome & IntroductionsBlog:
    3. 3. © 2011 VersionOne 3What is Agile After All?
    4. 4. © 2011 VersionOne 4We are uncovering new ways of developing softwareby doing it and helping others do it. Through thiswork we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer Collaboration over contract negotiationResponding to Change over following a planThat is, while there is value in the items on the right,we value the items on the left more.Agile Software Development
    5. 5. © 2011 VersionOne 5• Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software.• Welcome changing requirements, even late indevelopment. Agile processes harness changeforthe customers competitive advantage.• Deliver working software frequently, from acouple of weeks to a couple of months, with apreference to the shorter timescale.• Business people and developers must worktogether daily throughout the project.• Build projects around motivated individuals.Give them the environment and support theyneed,and trust them to get the job done.• The most efficient and effective method ofconveying information to and within adevelopmentteam is face-to-face conversation.• Working software is the primary measure ofprogress.• Agile processes promote sustainabledevelopment.The sponsors, developers, and users should beableto maintain a constant pace indefinitely.• Continuous attention to technical excellenceand good design enhances agility.• Simplicity--the art of maximizing the amountof work not done--is essential.• The best architectures, requirements, anddesignsemerge from self-organizing teams.• At regular intervals, the team reflects on howto become more effective, then tunes andadjustsits behavior accordingly.Principles of Agile
    6. 6. The Agile MindsetSelf organizing teamsEmphasis on customer valueCreating great software, not engineering a processCommunication is keyMentality of sufficiency
    7. 7. © 2011 VersionOne 7• Ten Principles of Agile TestingAgile Testing
    8. 8. © 2011 VersionOne 8How a Testers Life Changes• Tests are not “What Comes AfterDevelopment if We Have Time But WeNever Have Time”• We need to identify and write testsearly and often• Automation baby, Automation• The relationship of acceptance teststo requirements needs to be tight.• Relationship between programmersand testers is tighter• Collaboration over confrontation• Entering Defects is not enough• We are finally being recognized andutilized as a vital part of development,not just a gatekeeper
    9. 9. © 2011 VersionOne 9• Tests are the ultimate in feedback• By writing the tests first, we provide a “goal”• Tests are a conversation, not just writing defects• We are the beginning, middle and end of theconversationProvide Continuous Feedback
    10. 10. © 2011 VersionOne 10• Sometimes, a story needs a little help• Dude’s Law (David Hussman)– V = W/H• Think beyond whether the requirements are met.– Will this actually provide value?– Will the customer want to use it?• And yes, be excellent to each otherDeliver value to the customer
    11. 11. © 2011 VersionOne 11• What is the most useful Agile tool?– The human voice• Defect tracking tools can deceive you, don’t trustthem• Don’t accept “brush offs”• Develop a shared language– Be the bridge between customers and technical teamsEnable face to face communication
    12. 12. © 2011 VersionOne 12• We have a lot of history to overcome– Remember the tester stereotypes?– How many of us have worked in a “silo environment” where testers don’ttalk to stakeholders or programmers?• “How does testing keep up with development?”• Be willing to fail• Be willing to assert your views during planning sessionsHave Courage
    13. 13. © 2011 VersionOne 13• Simple is usually harder to do• Do the simplest thing that could possible work• Many small simple tests will give you more results than a fewlarge complex tests• The power of work not doneKeep it simple
    14. 14. © 2011 VersionOne 14• This is not a formal thing, butan attitude• I have a set of tests– They all pass– I bet I can find two more teststhat will make the producteven better• I don’t have all of my testsautomated– I can automate three new testseach sprint– I’ve been automating three persprint, I bet I can do five.• Refactoring ain’t just forprogrammersPractice Continuous Improvement
    15. 15. © 2011 VersionOne 15• Team culture imbues every aspect of agiledevelopment• Don’t wait for someone to tell you what your roleis.• Take all of the knowledge you can possible getfrom the team– Learn a programming language– Learn a new testing technique– Learn about the financials behind a product.Self Organize
    16. 16. © 2011 VersionOne 16• Software development is a social activity• The technology part is the easy part• Remember:– We value individuals and interactions over processes and tools• All members of the team are equal– You don’t have to assert it– Assume it to be the case, and it will beFocus on People
    17. 17. © 2011 VersionOne 17• We are spending *WAY* too much of our time doingthis to not enjoy it• Find little ways to enjoy it.• Celebrate successesEnjoy
    18. 18. © 2011 VersionOne 18Assuring Quality is not about finding errorsAssuring Quality is about creating the bestproduct the first timeQuality Assurance
    19. 19. © 2011 VersionOne 19• Automated unit tests confirms the code isdoing what we say it will do• Automated Acceptance Tests confirm thecode is doing what we want it to do• Another way of looking at it:– Unit Tests ensure we make the software right– Acceptance Tests ensure we make the rightsoftwareWhat is Acceptance Test Driven Development
    20. 20. © 2011 VersionOne 20• In its purest form, the acceptance test is thestatement or condition that must besatisfied for a story to be complete• Acceptance tests are the closest thing to“requirements” in the agile worldWhat is an acceptance test
    21. 21. © 2011 VersionOne 21• More often than not, this ends up beingQA/Testers• Anyone can write an acceptance test• A product owner who writes goodacceptance tests is worth their weight ingoldWho should write acceptance tests?
    22. 22. © 2011 VersionOne 22• Unit tests are small, light, and never touch the external world• Acceptance tests touch as much of the real world as can betouched.The difference between unit tests and acceptance tests
    23. 23. © 2011 VersionOne 23• There are many forms that an acceptance test can take.• What we want to make sure of is that it is a clear statement ofwhat the user wants to do, and what they expect to seehappen.• An acceptance test is a binary. It can pass or it can fail, thereis no in-betweenWhat does a good acceptance test look like?
    24. 24. © 2011 VersionOne 24• Automate everything possible• Record and playback is fine, but not enough• As with unit tests, don’t be afraid of “hardcoding” some test values.• Don’t forget the “unhappy path”Acceptance Test best practices
    25. 25. © 2011 VersionOne 25• During a sprint, when I find a defect…– I can log a defect into a bug trackingsystem, and hope someone has time towork it before the release– I can write a failing acceptance test thatillustrates the defect.•I talk to the programmer about the issue andthe test•When the test passes, its as if the defect neverexistedInstead of logging a defect…
    26. 26. © 2011 VersionOne 26• We have a lot of different tools in ourbox• They are all good tools by themselves,but the whole is much greater than thesum of its partsBringing the whole thing together