Cosa fa il Software Tester?
Il Software Tester controlla che l’applicazione funzioni “correttamente”.
Questa è la prima cosa che mi è venuta in mente, ovviamente il problema è, a questo punto, decidere come si fa a dire se l’applicazione funziona “correttamente”.
Prima di sviluppare un pezzo di software si dovrebbero avere ben chiari i requisiti del prodotto, requisiti che possono definire non solo cosa il sistema deve fare ma anche come lo deve fare, spesso, infatti, si hanno dei vincoli stringenti sulla quantità di memoria massima che il processo può usare, o sul tempo massimo di risposta dello stesso, o di ridondanza, tipo salvare i dati in diversi formati e\o in diversi posti.
Il Software Tester, anche se a me piace parlare di più di Quality Assurance, deve controllare che il sistema rispetti questi requisiti, e per fare ciò esegue una serie di test per controllare che il sistema non abbia dei difetti, bugs, cioè degli errori nelle istruzioni, che causano dei malfunzionamenti, cioè dei comportamenti difformi dalle specifiche. Il piano di test, meglio se costruito prima di iniziare gli stessi, consiste in una raccolta di test, cioè di una serie di cose da fare che provocano dei risultati attesi in base alle precondizioni del sistema.
Ovviamente il tempo a disposizione per i controlli non è infinito per cui le tecniche di testing ci vengono in aiuto per selezionare i casi di test che aggiungono più valore al nostro piano di test.
Quality Assurance vs Bug Hunter
Per “più valore” intendo quei test la cui esecuzione aumentano la nostra fiducia di corretto funzionamento (specifiche qualitative e quantitative) del sistema sotto controllo.
Questa è la visione da Quality Assurance che deve assicurare la qualità del sito.
Per “più valore” intendo quei test la cui esecuzione permettono di scoprire quanti più bugs possibili.
Questa è la visione da “bug hunter”.
Ad una prima lettura le due frasi potrebbero sembrare simili e comunque si potrebbe fare l’equazione qualità del sito = pochi o nessun bug… in realtà non è proprio così.
Penso che la visione da bug hunter sia una parte di quella del quality assurance, infatti un software con 0 bug non necessariamente è un software di qualità, perchè magari è difficilmente usabile, oppure è molto lento nella risposta e magari lo stesso software con alcuni bug risulta essere migliore per l’utente finale.
Inoltre riflettiamo sul fatto che abbiamo, in genere, poco tempo per testare un prodotto… è meglio spendere quel poco tempo per trovare un bug dovuto al combinarsi di due-tre fattori oppure verificare se lo scenario principale di utilizzo funziona o meno? Direi meglio assicurarsi che gli scenari principali funzionino correttamente…
Quality Assurance… è meglio
Penso che la visione del Quality Assurance sia la migliore perchè una visione a largo spettro e credo alla fine più vicina al prodotto finale e quindi all’utente. Non dobbiamo mai dimenticarci, infatti, degli utenti del prodotto e del motivo per cui è stato costruito.
Per essere un buon QA oltre alle conoscenze tecniche, oltre ai prodotti che possono essere utilizzati in modo da facilitare i controlli è necessario avere anche uno spirito critico propositivo e bisogna essere curiosi, sperimentare per trovare nuovi approcci e nuove metodologie.
Tecnici o no?
Seconde me, si. Bisogna essere tecnici anche se non necessariamente il QA deve esser stato prima uno sviluppatore, anzi. Credo che sia meglio che il QA non abbia mai fatto lo sviluppatore perchè la mentatilità è totalmente differente. Bisogna esser tecnici perchè pemette di avere un linguaggio comune con gli sviluppatori, perchè permette di automatizzare i test. Sono fortemente convinto che i test manuali devono essere lasciati come seconda scelta. Prima i test automatici, se si possono fare, quanto tempo ci vuole per implementarli e gli eventuali benefici in termini di riusabilità, di continuos delivery si possono ottenere, poi il rimanente non automatizzabile deve essere coperto da test manuali. Anche se i test automatici possono essere creati con il supporto degli sviluppatori, è meglio che il QA abbia le nozioni base per costruirli in autonomia o quasi…
