Team di test? Si, grazie! TORINO, 26 febbraio 2013 Fabrizio Accatino fhtino@gmail.com
Premessa esperinza dal campo no teoria astratta sul testing my tips focus su black-box testing (funzionale)
Difficile controllare... ... il risultato atteso ... la regressione
Introduzione: alcuni spunti Terminologia: debug, unit-test, test team, test driven development, ... Tipologie: black-box, gray-box, white-box testing Perimetro: componente, applicativo, sistema, integrazione fra sistemi Figure: committente, project-manager, analisti, sviluppatori, team di test Tempi: chi scrive i test? quando? chi li esegue?
Perchè fare test? fanno emergere bug :) simulazione utente feedback simile a quello dell'utente ambienti complessi system integration e prove su sistemi "reali" verifiche di non regressione soprattutto con software in continua evoluzione
Team dedicato: PRO e CONTRO sollecita sia gli sviluppatori che il committente scrive o aiuta a scrivere i test individua casi non previsti durante la progettazione indicazioni su miglioramenteto del monitoring (più log, più viste amministrative, più allarmi, ecc.) obbliga il resto del team a formalizzare requisiti CONTRO: costo deve essere organizzato ed integrato nel processo
My tips usare un tool di gestione dei test usare un tool di bug-tracking iniziare a scrivere i test appena possibile organizzare i test in suite per poterli ripetere dotarsi di tools per automatizzare i test necesario avere ambienti separati per sviluppo, test e produzione versionare le applicazioni strutturarsi per rilasciare versioni beta a gruppo selezionato di tester ed utenti