Agile and QA... ma che ciazzecca?


Published on

Ma il ruolo del tester in un team agile a cosa serve? E' una domanda piuttosto ricorrente nella comunità agile, a cui spesso ci si risponde con uno sdegnato "in un team agile non servono persone di QA!".

Approfondendo l'argomento tuttavia, si scopre quanto il testing abbia un ruolo di fondamentale importanza anche in un ambiente agile.

In questo intervento verrà trattato come inquadrare il QA nell'ambito di un processo di sviluppo agile, con riferimento alla realtà del team di sviluppo di Funambol.

  • 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

Agile and QA... ma che ciazzecca?

  1. 1. Agile and QA... ma che ciazzecca? Better Software 2010 Firenze, May 5 th -6 th Stefano Fornari, Funambol CTO
  2. 2. Agenda <ul><li>Do we need QA in scrum?
  3. 3. QA vs Testing
  4. 4. Agile testing
  5. 5. QA in our team
  6. 6. Q&A </li></ul>
  7. 10. QA vs testing Quality assurance is an effort to prevent defects from entering the system
  8. 11. QA vs testing Quality assurance is an effort to prevent defects from entering the system Testing is any activity to discover defects in the system
  9. 12. Test at the end <ul><li>It is hard to improve the quality of an existing product
  10. 13. Mistakes continue unnoticed
  11. 14. The state of the project is difficult to gauge
  12. 15. Feedback opportunity are lost
  13. 16. Testing is more likely to be cut </li></ul>Development Test Delivery
  14. 17. Without test, there is no value delivered <ul><li>If it's not tested, it's not done
  15. 18. If not done it's not accepted
  16. 19. If it's not accepted, there's no value delivered </li></ul>
  17. 20. Agile development <ul><li>Iterative and incremental development
  18. 21. Cross-functional teams
  19. 22. All team shares the same goals </li><ul><li>produce value for the customer
  20. 23. produce high-quality software
  21. 24. the entire team is accountable for quality </li></ul><li>All team participate in the development of value at each stage
  22. 25. All team members help in any tasks as required by the team
  23. 26. Each team member is equally-valued </li></ul>
  24. 27. Agile testing <ul><li>Definition of done </li><ul><li>If a piece of functionality is not acceptable, it is not done
  25. 28. If test tasks are not complete, the team stops and everyone tests. Programmers can't “get ahead” of testers </li></ul><li>Testing takes place at any time </li><ul><li>Testing helps development!
  26. 29. It's impossible to “run out of time” for testing </li></ul><li>Testing must be efficient and cost-effective </li><ul><li>Test automation! </li></ul></ul>
  27. 30. Agile testing quadrants
  28. 31. Quadrant 2 testing: automatic vs manual
  29. 32. The agile testing pyramid
  30. 33. Do we need a QA team at all?
  31. 34. We currently do have a QA team <ul><li>Main responsibilities </li><ul><li>Develop a testing strategy amongst different scrum teams
  32. 35. Develop specific testing skills, competences, attitude, practices
  33. 36. Share the above between different scrum teams
  34. 37. Encourage automation </li></ul><li>Let people express their most potential
  35. 38. Cultivate and encourage different perspectives
  36. 39. Human resources
  37. 40. Make sure testing has the same level of attention than development </li></ul>
  38. 42. Quadrant 1 testing <ul><li>Technology-facing – support the team
  39. 43. Test first/Test driven development
  40. 44. Unit and component testing
  41. 45. Fully automated
  42. 46. Internal quality </li></ul>
  43. 47. Quadrant 2 testing <ul><li>Business-facing – support the team
  44. 48. Define external quality
  45. 49. Define features
  46. 50. Drive development from high level
  47. 51. Driven by examples from the customers
  48. 52. Expressed in business domain language
  49. 53. Help the team to deliver the business value requested by the customer
  50. 54. Automation still under researching? </li></ul>
  51. 55. Quadrant 3 testing <ul><li>Business-facing – critique product
  52. 56. “Critique” as positive constructive word
  53. 57. Business-facing tests that exercise the software to see if it does not quite meet expectations as a overall
  54. 58. Trying to emulate real users usage
  55. 59. Mainly manual
  56. 60. The best tools are senses, brains, intuition, creativity, domain knowledge </li></ul>
  57. 61. Quadrant 4 testing <ul><li>Technology facing – critique product
  58. 62. Critique non functional requirements such as performance, scalability, robustness, security ...
  59. 63. Specialized tools/expertise may be required
  60. 64. Automation </li></ul>