Friday, April 2, 2010

Quality Assurance

Ho sempre fatto questa equazione:
QA == Test
usando “Test” nell’accezione peggiore per uno sviluppatore: UAT, ergo la mera esecuzione di una check list di test e la verifica che le aspettative vengano rispettate… che barba che noia…
Ora…
non c’è niente di più sbagliato che la mia convinzione di cui sopra, è un po’ che ci ragiono sopra e sono giunto alla conclusione che in un processo strutturato e consolidato in cui QA “spanna” su tutto il processo, perchè QA è come la security non si fa alla fine il giorno dopo la consegna…, un Tester è una figura decisamente intrigante.
Direi che il tester deve avere queste capacità:
  1. Saper scrivere codice il cui scopo è spaccare il codice degli altri;
  2. Saper scrivere codice il cui scopo è distruggere le barriere di security messe in piede dal codice altrui;
  3. Vivere a strettissimo contatto con il team di sviluppo per essere costantemente sincronizzato e portare feedback;
  4. Saper scrivere tool di supporto al testing per rendergli la vita felice;
  5. Avere fantasia nel costruire/immaginare scenari di uso del codice altrui che gli “altrui” non hanno neanche minimamente pensato;
  6. purtroppo :-) …eseguire la mera e noisa check-list;
Queste considerazioni nascono da un meeting interno con 4 guru del team della Security che ci stavano erudendo sulle news che avremmo avuto nel fx 4.0 in materia di CAS, in Corp. ad un MVP Global Summit di un paio di anni fa, in cui Raff fece una domanda del tipo:
Q: Quale è il tade off per cui decidete se testare o non testare?
A: Non c’è trade off, semplicemente testiamo tutto.
E’ ovvio che l’effort per arrivare a testare tutto è notevole e l’investimento su persone e tool interni è sicuramente interessante ma in molti contesti il gioco vale decisamente la candela, soprattutto se la QA la vendi al cliente nel contratto :-) e il cliente ha pure una nutrita schiera di avvocati che il contratto lo leggono molto bene :-P
Quindi?
Se in qualche modo foste interessati intrigati dai cinque punti di cui sopra e foste disposti ad accettare il sesto…
.m

3 comments:

  1. Imported comment, original author: Lorenzo Barbieri

    Quello non è il lavoro del "tester" ma dell'SDET (come lo chiamano a Redmond). Sono due lavori DIVERSI.

    ReplyDelete
  2. Imported comment, original author: Mauro Servienti

    esatto :-) infatti sbagliavo io generalizzando in tester

    ReplyDelete
  3. Imported comment, original author: Alberto

    Il tester è inoltre anche chi definisce i requisiti minimi, almeno io credo, quali ad esempio massimo carico della macchina sopportabile o comunque max num. connessioni contemporanee. Penso che pure questi requisiti facciano parte della quality assurance

    ReplyDelete