Introduction to Agile Testing for QA

3,576 views
3,511 views

Published on

Slides from my talk at Scrum Day 2009 "Introduction to Agile Testing for QA".

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

No Downloads
Views
Total views
3,576
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • \n
  • \n\n\n
  • \n\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n\n
  • \n\n
  • \n\n
  • \n\n
  • \n\n
  • \n\n
  • \n\n
  • \n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Introduction to Agile Testing for QA

    1. 1. Agile Testing ... where did my issue tracker go?
    2. 2. Objectives
    3. 3. Objectives• To answer these questions:
    4. 4. Objectives• To answer these questions: • Why do we care about quality anyway?
    5. 5. Objectives• To answer these questions: • Why do we care about quality anyway? • Where do testers fit into Scrum teams?
    6. 6. Objectives• To answer these questions: • Why do we care about quality anyway? • Where do testers fit into Scrum teams? • Why do we care about Automated Testing?
    7. 7. Why care about quality?
    8. 8. Why care about quality?• The work of Dr. W. Edwards Deming showed that:
    9. 9. Why care about quality?• The work of Dr. W. Edwards Deming showed that: • When people and organizations focus primarily on quality, then quality tends to increase and costs fall over time.
    10. 10. Why care about quality?• The work of Dr. W. Edwards Deming showed that: • When people and organizations focus primarily on quality, then quality tends to increase and costs fall over time. • However, when people and organizations focus primarily on costs, then costs tend to rise and quality declines over time.
    11. 11. Why care about quality?• The work of Dr. W. Edwards Deming showed that: • When people and organizations focus primarily on quality, then quality tends to increase and costs fall over time. • However, when people and organizations focus primarily on costs, then costs tend to rise and quality declines over time. • http://en.wikipedia.org/wiki/W._Edwards_Deming
    12. 12. Why care about quality?• The work of Dr. W. Edwards Deming showed that: • When people and organizations focus primarily on quality, then quality tends to increase and costs fall over time. • However, when people and organizations focus primarily on costs, then costs tend to rise and quality declines over time. • http://en.wikipedia.org/wiki/W._Edwards_Deming• Quality affects costs and stakeholders generally care a lot about costs.
    13. 13. Teething Problems
    14. 14. Teething Problems • Expect to hear:
    15. 15. Teething Problems • Expect to hear: • “Where is the spec?”
    16. 16. Teething Problems • Expect to hear: • “Where is the spec?” • “I can only test a finished product!”
    17. 17. Teething Problems • Expect to hear: • “Where is the spec?” • “I can only test a finished product!” • “I am a tester and have no interest in development!”
    18. 18. Teething Problems • Expect to hear: • “Where is the spec?” • “I can only test a finished product!” • “I am a tester and have no interest in development!” • “Devs should not be testing - that’s my job!”
    19. 19. Teething Problems • Expect to hear: • “Where is the spec?” • “I can only test a finished product!” • “I am a tester and have no interest in development!” • “Devs should not be testing - that’s my job!” • “How would they like it if I just started coding too?”
    20. 20. Teething Problems • Expect to hear: • “Where is the spec?” • “I can only test a finished product!” • “I am a tester and have no interest in development!” • “Devs should not be testing - that’s my job!” • “How would they like it if I just started coding too?” • “Where do I log issues?”
    21. 21. Teething Problems • Expect to hear: • “Where is the spec?” • “I can only test a finished product!” • “I am a tester and have no interest in development!” • “Devs should not be testing - that’s my job!” • “How would they like it if I just started coding too?” • “Where do I log issues?” • This is normal and means you have skilled and passionate testers that will serve the team well.
    22. 22. Teething Problems • Expect to hear: • “Where is the spec?” • “I can only test a finished product!” • “I am a tester and have no interest in development!” • “Devs should not be testing - that’s my job!” • “How would they like it if I just started coding too?” • “Where do I log issues?” • This is normal and means you have skilled and passionate testers that will serve the team well. • Demonstrate over debate.
    23. 23. So where do testers fit in?
    24. 24. So where do testers fit in?• They don’t “fit in.”
    25. 25. So where do testers fit in?• They don’t “fit in.”• They are an integral “part of” the team.
    26. 26. So where do testers fit in?• They don’t “fit in.”• They are an integral “part of” the team.• So are Devs, BA’s, PA’s, DBA’s, TW’s, etc.
    27. 27. So where do testers fit in?• They don’t “fit in.”• They are an integral “part of” the team.• So are Devs, BA’s, PA’s, DBA’s, TW’s, etc.• A Scrum team is a self organizing Cross-functional team that possesses the skills required to achieve the Sprint objectives.
    28. 28. So where do testers fit in?• They don’t “fit in.”• They are an integral “part of” the team.• So are Devs, BA’s, PA’s, DBA’s, TW’s, etc.• A Scrum team is a self organizing Cross-functional team that possesses the skills required to achieve the Sprint objectives.• Cross-functional Team > a group of Multi-functional individuals.
    29. 29. So where do testers fit in?• They don’t “fit in.”• They are an integral “part of” the team.• So are Devs, BA’s, PA’s, DBA’s, TW’s, etc.• A Scrum team is a self organizing Cross-functional team that possesses the skills required to achieve the Sprint objectives.• Cross-functional Team > a group of Multi-functional individuals.• There will be natural knowledge transfer and overlap.
    30. 30. So where do testers fit in?• They don’t “fit in.”• They are an integral “part of” the team.• So are Devs, BA’s, PA’s, DBA’s, TW’s, etc.• A Scrum team is a self organizing Cross-functional team that possesses the skills required to achieve the Sprint objectives.• Cross-functional Team > a group of Multi-functional individuals.• There will be natural knowledge transfer and overlap.• It’s a good thing!
    31. 31. In Estimation Meetings
    32. 32. In Estimation Meetings • Testers work with the PO to determine acceptance criteria for each story.
    33. 33. In Estimation Meetings • Testers work with the PO to determine acceptance criteria for each story. • Testers use their expertise and experience to highlight potential issues that are often overlooked.
    34. 34. In Estimation Meetings • Testers work with the PO to determine acceptance criteria for each story. • Testers use their expertise and experience to highlight potential issues that are often overlooked. • Their insights often help the team establish a more realistic and consistent story point sizing.
    35. 35. In Estimation Meetings • Testers work with the PO to determine acceptance criteria for each story. • Testers use their expertise and experience to highlight potential issues that are often overlooked. • Their insights often help the team establish a more realistic and consistent story point sizing. • They are good at playing devil’s advocate.
    36. 36. In Planning 1 Meetings
    37. 37. In Planning 1 Meetings • The input is the groomed Product Backlog.
    38. 38. In Planning 1 Meetings • The input is the groomed Product Backlog. • The output is the Sprint Backlog.
    39. 39. In Planning 1 Meetings • The input is the groomed Product Backlog. • The output is the Sprint Backlog. • Testers get another chance to highlight issues and refine story scope and acceptance criteria.
    40. 40. In Planning 1 Meetings • The input is the groomed Product Backlog. • The output is the Sprint Backlog. • Testers get another chance to highlight issues and refine story scope and acceptance criteria. • Along with the rest of the team, testers get to have their say regarding what they can commit to deliver at the end of the sprint.
    41. 41. In Planning 2 Meetings
    42. 42. In Planning 2 Meetings • The team collaborates around the design and initial tasks required to implement each story.
    43. 43. In Planning 2 Meetings • The team collaborates around the design and initial tasks required to implement each story. • This includes designing tests and creating testing tasks to test the acceptance criteria of each story.
    44. 44. In Planning 2 Meetings • The team collaborates around the design and initial tasks required to implement each story. • This includes designing tests and creating testing tasks to test the acceptance criteria of each story. • These tasks include everything the team needs to do to fulfill the teams definition of “done” for each story.
    45. 45. In Planning 2 Meetings • The team collaborates around the design and initial tasks required to implement each story. • This includes designing tests and creating testing tasks to test the acceptance criteria of each story. • These tasks include everything the team needs to do to fulfill the teams definition of “done” for each story. • Automated tests and some exploratory testing should form part of a teams definition of “done”.
    46. 46. Day-to-day Tester
    47. 47. Day-to-day Tester • In the daily Scrum, answer the three questions. Listen carefully to others answers as you will soon be testing their work.
    48. 48. Day-to-day Tester • In the daily Scrum, answer the three questions. Listen carefully to others answers as you will soon be testing their work. • Always work from top to bottom, left to right of the task board.
    49. 49. Day-to-day Tester • In the daily Scrum, answer the three questions. Listen carefully to others answers as you will soon be testing their work. • Always work from top to bottom, left to right of the task board. • Watch for “smelly” burndown chart and raise you concerns early.
    50. 50. Day-to-day Tester • In the daily Scrum, answer the three questions. Listen carefully to others answers as you will soon be testing their work. • Always work from top to bottom, left to right of the task board. • Watch for “smelly” burndown chart and raise you concerns early. • Be busy from day one of the sprint. There are always tests to automate and exploratory testing to be done.
    51. 51. Day-to-day Tester • In the daily Scrum, answer the three questions. Listen carefully to others answers as you will soon be testing their work. • Always work from top to bottom, left to right of the task board. • Watch for “smelly” burndown chart and raise you concerns early. • Be busy from day one of the sprint. There are always tests to automate and exploratory testing to be done. • Sit together with the appropriate team member when accepting a Story or Task for final testing.
    52. 52. Day-to-day Tester • In the daily Scrum, answer the three questions. Listen carefully to others answers as you will soon be testing their work. • Always work from top to bottom, left to right of the task board. • Watch for “smelly” burndown chart and raise you concerns early. • Be busy from day one of the sprint. There are always tests to automate and exploratory testing to be done. • Sit together with the appropriate team member when accepting a Story or Task for final testing. • Communicate your findings early and often.
    53. 53. Day-to-day Tester • In the daily Scrum, answer the three questions. Listen carefully to others answers as you will soon be testing their work. • Always work from top to bottom, left to right of the task board. • Watch for “smelly” burndown chart and raise you concerns early. • Be busy from day one of the sprint. There are always tests to automate and exploratory testing to be done. • Sit together with the appropriate team member when accepting a Story or Task for final testing. • Communicate your findings early and often. • After a conversation, bugs go in the first available task slot.
    54. 54. A Metric Leading to Agility ... Running Tested Features (RTF’s)
    55. 55. Running Tested Features“Nearly every metric can be perverted, since up- and down-ticksin the metric can come from good or bad causes. Teams driven bymetrics often game the metrics rather than deliver usefulsoftware. Ask the team to deliver and measureRunning Tested Features, week in and week out,over the course of the entire project. Keeping this singlemetric looking good demands that a team become both agile andproductive.” - Ron Jeffries
    56. 56. Running Tested Features
    57. 57. Running Tested Features• Running means that the features are shipped in a single integrated product.
    58. 58. Running Tested Features• Running means that the features are shipped in a single integrated product.• Tested means that the features are continuously passing tests provided by the requirements giver — the Product Owner in Scrum parlance.
    59. 59. Running Tested Features• Running means that the features are shipped in a single integrated product.• Tested means that the features are continuously passing tests provided by the requirements giver — the Product Owner in Scrum parlance.• Features mean real end-user features, not techno- features like “Install the Database” or “Get Web Server Running”.
    60. 60. Running Tested Features• Running means that the features are shipped in a single integrated product.• Tested means that the features are continuously passing tests provided by the requirements giver — the Product Owner in Scrum parlance.• Features mean real end-user features, not techno- features like “Install the Database” or “Get Web Server Running”.• http://www.xprogramming.com/xpmag/jatRtsMetric
    61. 61. Picture this...
    62. 62. Picture this... • The desired software is broken down into named features (requirements, stories) which are part of what it means to deliver the desired system.
    63. 63. Picture this... • The desired software is broken down into named features (requirements, stories) which are part of what it means to deliver the desired system. • For each named feature, there are one or more automated acceptance tests which, when they work, will show that the feature in question is implemented.
    64. 64. Picture this... • The desired software is broken down into named features (requirements, stories) which are part of what it means to deliver the desired system. • For each named feature, there are one or more automated acceptance tests which, when they work, will show that the feature in question is implemented. • The RTF metric shows, at every moment in the project, how many features are passing all their acceptance tests.
    65. 65. Picture this... • The desired software is broken down into named features (requirements, stories) which are part of what it means to deliver the desired system. • For each named feature, there are one or more automated acceptance tests which, when they work, will show that the feature in question is implemented. • The RTF metric shows, at every moment in the project, how many features are passing all their acceptance tests. - Ron Jeffries
    66. 66. Automate your tests!
    67. 67. Automate your tests!• Automated testing is one of the most important things an Agile team can do.
    68. 68. Automate your tests!• Automated testing is one of the most important things an Agile team can do.• Repetitive “Monkey clicking” is just bad on all levels - avoid it!
    69. 69. Automate your tests!• Automated testing is one of the most important things an Agile team can do.• Repetitive “Monkey clicking” is just bad on all levels - avoid it!• It all revolves around your Continuous Integration (CI) environment. (You do have one, right?)
    70. 70. Automate your tests!• Automated testing is one of the most important things an Agile team can do.• Repetitive “Monkey clicking” is just bad on all levels - avoid it!• It all revolves around your Continuous Integration (CI) environment. (You do have one, right?)• On every commit to your Source Code Management system the tests should be run and the results made visible to the whole team - immediately.
    71. 71. Responsibilities
    72. 72. Responsibilities • For the teams I work with:
    73. 73. Responsibilities • For the teams I work with: • Unit Tests are written by the Developers.
    74. 74. Responsibilities • For the teams I work with: • Unit Tests are written by the Developers. • Feature Tests are written by the Testers.
    75. 75. Responsibilities • For the teams I work with: • Unit Tests are written by the Developers. • Feature Tests are written by the Testers. • However, on the more experienced teams there is more overlap:
    76. 76. Responsibilities • For the teams I work with: • Unit Tests are written by the Developers. • Feature Tests are written by the Testers. • However, on the more experienced teams there is more overlap: • Testers often help Developers evaluate their Unit Test coverage.
    77. 77. Responsibilities • For the teams I work with: • Unit Tests are written by the Developers. • Feature Tests are written by the Testers. • However, on the more experienced teams there is more overlap: • Testers often help Developers evaluate their Unit Test coverage. • Developers often help Testers write the more tricky Feature Tests.
    78. 78. 1. Write failing Feature Test
    79. 79. 1. Write failing Feature Test2. Drop down to Unit Tests
    80. 80. 1. Write failing Feature Test2. Drop down to Unit Tests 3. Write failing Unit Test
    81. 81. 1. Write failing Feature Test2. Drop down to Unit Tests 3. Write failing Unit Test 4. Get Unit Test to pass
    82. 82. 1. Write failing Feature Test2. Drop down to Unit Tests 3. Write failing Unit Test 4. Get Unit Test to pass 5. Refactor
    83. 83. 1. Write failing Feature Test2. Drop down to Unit Tests 3. Write failing Unit Test 4. Get Unit Test to pass 5. Refactor 6. Step back to Feature Tests
    84. 84. 1. Write failing Feature Test2. Drop down to Unit Tests 3. Write failing Unit Test 4. Get Unit Test to pass 5. Refactor 6. Step back to Feature Tests 7. Refactor
    85. 85. 1. Write failing Feature Test2. Drop down to Unit Tests 3. Write failing Unit Test 4. Get Unit Test to pass 5. Refactor 6. Step back to Feature Tests 7. Refactor 8. Repeat n times
    86. 86. Unit Testing Tools • SimpleTest • PHPUnit • JSUnit • http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
    87. 87. Feature Testing Tools• WebRat (http://wiki.github.com/brynary/webrat)• Selenium (http://seleniumhq.org/)• Watir (http://wtr.rubyforge.org/)
    88. 88. Behavior Driven Development • PHPSpec (http://www.phpspec.org/) • RSpec (http://rspec.info/) • JSpec (http://visionmedia.github.com/jspec/) • Cucumber (http://cukes.info/) • FitNesse (http://fitnesse.org/)
    89. 89. Questions?
    90. 90. http://www.linkedin.com/in/kevinfouriekevin@fourie.org.za@4eek
    91. 91. Image Credits by Eleaf by scoobygirl by boodie131 by rahen z by alandd by Improve It by robpurdie by drewgstephens by km6xo by TeresaHsu

    ×