Your SlideShare is downloading. ×
0
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
Agile and QA... ma che ciazzecca?
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

Agile and QA... ma che ciazzecca?

759

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 …

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.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

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

×