Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Agile Testing Agile Ottawa April 2015

1.169 visualizaciones

Publicado el

Agile Testing examines software from the customer point of view, and requires that the entire team tests the product to deliver value.

According to James Bach, testing is the questioning of a product in order to evaluate it.


Agile Testing takes the fundamentals of software testing, and provides options for testing products delivered in Agile workflows. It focuses on early involvement of testers, defect prevention, quick feedback loops, test automation, and exploratory testing.


This presentation will start with selected ideas from Agile Testing, and

More Agile Testing, then Dag Rowe will tie in ideas from other practices and practitioners, notably BDD and Specification by Example

Publicado en: Software
  • Sé el primero en comentar

Agile Testing Agile Ottawa April 2015

  1. 1. Agile Testing Agile Ottawa April 2015
  2. 2. What is Testing? ●Testing seeks to discover threats to the value of software ●Questioning a product in order to evaluate it o James Bach ●Testing is done to find information o With that information critical project decisions can be made
  3. 3. What is Agile Testing? Agile testing applies the agile mindset ● It suggests attitudes and activities that help to deliver valuable software Applies to both ●Testing on an agile team ●Using agile testing on a traditional team
  4. 4. The Agile Testing Mindset ● The whole team is responsible for quality o ‘QA will find it’ isn’t accepted ● Testing is not a phase, it’s an ongoing activity
  5. 5. The Agile Testing Mindset ● Short feedback loops ● Continuous improvement ● Collaboration o How can I help?
  6. 6. Why Bother? ● To fix defects as close to when they were introduced as possible ● To keep the project moving forward o By continually providing test feedback as the product is developed
  7. 7. The Whole Team Approach
  8. 8. Separate Teams
  9. 9. Cross Functional Team
  10. 10. Agile Testers
  11. 11. Agile Testers Principles for agile testers ● Provide continuous feedback ● Focus on delivering value ● Prioritize high bandwidth communication
  12. 12. Agile Testers Need to be critical thinkers ● Challenge assumptions Need to be problem solvers ● Fix problems, not symptoms Need to be good communicators ● They are required to give feedback
  13. 13. Agile Testers Need to learn the business domain ● Take the customer’s point of view Need to think differently ● Ask the what if questions
  14. 14. Agile Testers and Feedback Give feedback ● With empathy for the customer ● With empathy for the developers
  15. 15. Giving Feedback ● Have a positive intent o You are trying to help people ● Take responsibility for the feedback o Provide and gather context ● You must be clear o Otherwise your feedback is ineffective
  16. 16. Receiving Feedback ● Assume a positive intent o People want to do their best work ● Give people the benefit of the doubt o People have bad days ● Thank people for constructive feedback o You want to improve to do your best work
  17. 17. Feedback Skills for Agile Testers ● Active listening o Listen to learn o Don’t jump to conclusions Feedback Steps from Jurgen Appelo ● Provide context ● List observations ● Express emotions ● Sort by value ● Offer suggestions
  18. 18. Agile Testers Trust is like money ● It can take years to earn it and it only takes minutes to lose it
  19. 19. Agile Testers and Programming It is important to be technically aware ● Take a holistic view of your technical environment Everyone cannot be good at everything ● A technical context enhances collaboration
  20. 20. Agile Testers and Programming So does this mean testers need to program? ● Definitely maybe Test automation enables agile testing ● Agile testing is not sustainable without automation Instead of the individual look at the team ● The team needs to be able to program
  21. 21. T Shaped Testers The T represents depth of knowledge and breadth of knowledge T Depth Breadth
  22. 22. T Shaped Testers Depth is the tester’s specialized knowledge ● Integration testing ● Exploratory testing ● Etc Depth Breadth T
  23. 23. T Shaped Testers Breadth is the tester’s generalized knowledge ● Programming ● Configuration management ● Databases ● Etc Depth Breadth T
  24. 24. Square Shaped Teams
  25. 25. Test Automation
  26. 26. Test Automation You can apply agile skills to any test project ● But automation enables agile testing to succeed
  27. 27. Test Automation Why? ● Manual testing takes a long time ● Manual testing is expensive ● You want to free your testers to do more valuable work
  28. 28. Test Automation More reasons ● It provides earlier feedback more often ● It is a form of documentation ● It enables Continuous Integration and Continuous Delivery
  29. 29. Testing vs. Checking Checking ● Things that machine could do o Expected results are well defined Testing ● Things that a human must do o Observe o Explore o Infer
  30. 30. Testing vs. Checking
  31. 31. More ● Cost ● Time ● Fragile More tests
  32. 32. Agile Test Quadrants
  33. 33. Exploratory Testing
  34. 34. Exploratory Testing Exploratory testing ●Relies on a tester’s freedom ●Relies on a tester’s responsibility What is it? ●Testing without expected results
  35. 35. Exploratory Testing Exploratory testing is simultaneous ● Learning ● Test design ● And test execution James Bach
  36. 36. Exploratory Testing How do you do it if you don’t have an expected result? ● Use test heuristics ● Use experience and domain knowledge What is it not? ●Undisciplined ●Undocumented
  37. 37. Test heuristics? ● A ‘rule of thumb’ for testing software o Using experience to find defects Heuristics
  38. 38. Variable Analysis ● Identify anything whose value can change. ● Goldilocks o Too Big, Too Small, Just Right ● Starvation o CPU, Memory, Network, or Disk at maximum capacity Elisabeth Hendrickson - Test Heuristics Cheat Sheet Heuristics Examples
  39. 39. I'm not schooled in the science of human factors, but I suspect surprise is not an element of a robust user interface Chip Rosenthal
  40. 40. Exploratory Testing Design ● Look for interesting test variations Executing ● When you think of the test Learning ● Discover behaviour, look for clues about defects Steering ● Take those clues and exercise the code more
  41. 41. Exploratory Testing Ideas ● Persona testing ● Test tours Tools ● Notes ● Mind maps ● Atlassian Bonfire ● QTest eXplorer
  42. 42. SBE, and BDD
  43. 43. Shift Left in the SDLC We want to test early and often ● How do we start to prevent defects even before code is written?
  44. 44. Shift Left in the SDLC Involve test throughout the Software Development Lifecycle Prevent defects ● By collaborating early and often o Business, dev, and test ● By challenging requirements early
  45. 45. Build the Right Thing, Build it Right Testers can help: ● Build the right thing o That meets the customers needs o Might not be what they asked for ● Build it right o Well designed, coded, tested
  46. 46. A Build the Right Thing Pyramid
  47. 47. SBE and BDD Specification by Example (SBE) Behaviour Driven Development (BDD) Both methods involve testers earlier in the SDLC ● To discover the right thing to build Both methods use business language ● This allows Business, Dev, and Test to collaborate
  48. 48. SBE and BDD Specification by Example (SBE) uses process patterns to collaborate ●Defines scope from business goals ●Gathers key examples ●Refines examples ●Automates testing of the examples
  49. 49. SBE and BDD Behaviour Driven Development (BDD) ● Defines tests first ● Captures examples of desired system behaviour ● Automates testing of those examples
  50. 50. SBE and BDD People get distracted by automation tools It isn’t about the tools ● It’s about the conversations ● It’s about gaining a shared understanding Paraphrasing Liz Keogh
  51. 51. The Outside-In Approach Friends build products Enemies only build documentation Pragmatic Marketing
  52. 52. Stories and SBE, BDD Stories are a lightweight method to frame desired system behaviour As a student I want to register for a course So that I can graduate Who What Why
  53. 53. Stories Note: The story ● Can’t be coded yet o It needs more detail ● It isn’t testable yet
  54. 54. Specification Workshops You need to get the details, SBE and BDD suggest a conversation Discuss the story in a specification workshop to ● Understand how it should behave ● Discover enough detail to develop and verify ● Create shared understanding o Business o Dev o Test
  55. 55. Who is in that workshop? Why? Business QADev The solution we want
  56. 56. Examples Refine the examples from the Specification Workshop using the Given When Then format to ● Define a story’s scope ● Make the story testable ● Give you the story’s key details Don’t create an example for everything ● You’ll get lost in the details
  57. 57. Example GIVEN Java 101 has >= 1 places available WHEN Sarah registers for Java 101 THEN Sarah is registered in Java 101 Postcondition Event Precondition Details documented collaboratively
  58. 58. A Vacation Photo
  59. 59. Shared Understanding The document is nothing, but documenting is everything ●Gerald Weinberg paraphrasing D. Eisenhower
  60. 60. Key Success Factors ●Use the whole team approach ●Adopt the agile testing mindset ●Automate regression tests ●Provide and get feedback ●Build the team’s core agile practices ●Collaborate with the business, and development ●Look at the big picture
  61. 61. The Outside-In Approach Quality is about being prepared for the usual so you have time to tackle the unusual. ● Adam Geras
  62. 62. Dag Rowe ● @dagrowe ● ca.linkedin.com/in/dagrowe Thanks to Pythian for sponsoring the pizza, and venue! www.pythian.com
  63. 63. Sources ●Agile Testing: A Practical Guide for Testers and Agile Teams ●More Agile Testing: Learning Journeys for the Whole Team ●User Story Mapping: Discover the Whole Story, Build the Right Product ●Specification by Example: How Successful Teams Deliver the Right Software ●http://dannorth.net/introducing-bdd/
  64. 64. Sources ●http://watirmelon.com/tag/software-testing- pyramid/ ●http://www.duncannisbet.co.uk/test-automation- basics-levels-pyramids-quadrants ●http://www.satisfice.com/blog/archives/category/te sting-vs-checking ●https://mysoftwarequality.wordpress.com/tag/softw are-quality/ ●http://www.developsense.com/blog/2012/02/braidi ng-the-stories/
  65. 65. Sources ●https://mysoftwarequality.wordpress.com/tag/softw are-quality/ ●http://www.skillsyouneed.com/ips/active- listening.html ●http://lizkeogh.com/2011/09/22/conversational- patterns-in-bdd/ ●http://lisacrispin.com/downloads/AgileVancouverA gileTestersDifferent.pdf ●http://www.slideshare.net/jurgenappelo/feedback- wrap
  66. 66. Sources ●https://soundcloud.com/techwell/keep-agile- testing-agile-an ●http://joecolantonio.com/testtalks/42-paul-gerrard- shift-left-a-new-model-for- testing/?utm_source=twitter&utm_medium=podcas t&utm_campaign=shift_left_test_talks ●http://joecolantonio.com/testtalks/34-janet-gregory- agile-testing/ ●http://www.slideshare.net/ColomboCampsCommu nity/what-is-an-agile-tester-henrik-kniberg

×