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.

1. Agile and QA... ma che ciazzecca? Better Software 2010 Firenze, May 5 th -6 th Stefano Fornari, Funambol CTO

3. QA vs Testing

4. Agile testing

5. QA in our team

6. Q&A

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

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 Development Test Delivery

18. If not done it's not accepted

19. If it's not accepted, there's no value delivered

21. Cross-functional teams

23. produce high-quality software

25. All team members help in any tasks as required by the team

26. Each team member is equally-valued

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?

35. Develop specific testing skills, competences, attitude, practices

36. Share the above between different scrum teams

38. Cultivate and encourage different perspectives

39. Human resources

40. Make sure testing has the same level of attention than development

43. Test first/Test driven development

44. Unit and component testing

45. Fully automated

46. Internal quality

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?

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

62. Critique non functional requirements such as performance, scalability, robustness, security ...

63. Specialized tools/expertise may be required

64. Automation