Ancora sui betatester…

Avevo promesso che sarei ritornato sull’argomento, per cui mantengo la parola: questo post ha come scopo spiegare cosa fa un betatester “professionista” e, in qualche modo l’evoluzione di questa figura nel tempo.

Il betatester

Credo sia chiaro e fuori discussione lo scopo del betatesting e delle persone che lo seguono. Da Wikipedia:

“Più precisamente il beta testing (o beta-verifica) è una fase di prova e collaudo di un software non ancora pubblicato, con lo scopo di trovare eventuali errori (bug). Questa operazione può essere svolta da professionisti specializzati, oppure, molto spesso, da semplici amatori, chiamati beta tester.

La loro importanza è legata, oltre al test dei sistemi operativi, anche ai programmi minori poiché tendono a comportarsi diversamente in base all’hardware su cui girano, per cui conviene avere la possibilità di provarli su più hardware differenti.”

Il succo del discorso è semplice: provare e riprovare qualcosa finchè un determinato prodotto non è ritenuto sufficientemente pronto per essere rilasciato all’esterno.

Cosa significhi esattamente pronto è materia di aperta ed accesa discussione tanto che ogni azienda ha e applica appositi criteri per stabilirlo. Non a caso in quelle di una certa dimensione esistono apposite “divisioni” di “controllo qualità” (“QA“) il cui scopo è garantire il rispetto di opportuni standard di qualità in tutta la filiera dello sviluppo, testing incluso.

Il problema relativo ai betatester è che è sempre difficile trovarne di validi. Ancora una volta Wikipedia sintetizza bene il problema:

“La ricerca di beta tester su Internet, tuttavia, non risulta affatto facile dato che spesso per testare un programma si necessita di conoscenze informatiche e di programmazione non comuni all’utente medio.”

Fare il betatester non è affatto un discorso semplice: se sulla carta chiunque può esserlo, nella realtà è bene distinguere le varie “aree operative” e quindi il tipo di testing. Personalmente – magari in un modo tutto sommato un po’ rozzo – ne distinguo principalmente due.

Vediamoli…

1. Testing operativo

Il testing operativo/funzionale, ossia provare un prodotto e trovare i problemi “macroscopici” che compaiono durante l’uso, è qualcosa relativamente alla portata di chiunque.

Anzi, è bene avere a disposizione degli utenti-medi, meglio se non troppo competenti in materia informatica.

Serve cioè gente che sia in grado di fornire delle descrizioni attendibili per i problemi che trova ma senza la forma mentis dello sviluppatore, che è portato a fare le cose sempre in un certo modo, influenzato cioè dalla sua conoscenza approfondita della materia.

Dopotutto, per una questione pratica, difficilmente chi scrive un programma è anche la persona giusta per trovarne tutti i bug.

Un esempio di questo genere di test è l’Hallway testing, che rientra non a caso nei test di usabilità:

“Hallway testing (or Hall Intercept Testing) is a general methodology of usability testing. Rather than using an in-house, trained group of testers, just five to six random people, indicative of a cross-section of end users, are brought in to test the product, or service.

The name of the technique refers to the fact that the testers should be random people who pass by in the hallway.”

2. Testing interno

Per testing interno intendo quel genere di prove che vengono svolte internamente ad un’azienda per garantire che determinate cose, anche a basso livello, funzionino.

Parlo quindi di qualcosa dietro le quinte e che viene normalmente gestito da gente con una certa competenza in ambito informatico.

C’è da dire che la figura del tester si è molto evoluta molto nel tempo, di pari passo con lo sviluppo di nuove efficaci metodologie di test che tendono ad automatizzare il più possibile ogni fase di controllo.

In pratica da un tester che controlla più o meno manualmente gli errori di qualcun altro (“giocare con i giocattoli altrui”), si è passati via via ad una figura professionale precisa e sempre più specializzata. In molte aziende di una certa dimensione, il tester non è più visto come un non-programmatore o un programmatore di serie B, un’ultima ruota del carro, bensì un programmatore di tutto rispetto, il cui scopo è produrre codice per testare altro codice. Il trionfo della cosiddetta test automation.

Naturale quindi che, in determinate aziende, questo tipo di “betatester evoluto” venga indicato con altri nomi, spesso altisonanti. E’ il caso del “Software Development Engineer in Test” (SDET) di Microsoft (*), le cui principali mansioni sono (da MicrosoftJobsBlog):

• Participating in design and code inspections.
• Writing infrastructure tools and code to exercise our products.
• Understanding in exquisite detail how customers will use the product.

Si tratta di una figura professionale che ha quindi uno scopo preciso e ben delineato: controllare il controllabile, sia a basso che ad alto livello, automatizzando il più possibile.

Per rimarcare ancora il valore di uno SDET rispetto ad un “comune” betatester:

“At Microsoft we generally consider SDETs to be full-blown Software Engineers that also happen to have a strong focus on software quality, attention to detail and care deeply about making the best product possible. [...]“

La dimostrazione di tutto ciò è facilmente visibile in post come How we test the compiler performance e How we test the compiler backend sul sito del team di sviluppo di Visual C++, che vi invito a leggere a compendio di quanto appena scritto.

Ah, le paghe degli SDET normalmente sono molto buone…

Conclusioni

Con questo post spero di aver raggiunto il mio scopo, ossia spiegare cosa fa un “betatester nel 2010” e perchè esso sia davvero importante per un’azienda.

Che ne pensate?

(*): questo non è un post “pubblicitario”. Microsoft è citata in quanto “famosa” per identificare in un modo preciso e in qualche modo “aulico” i suoi “betatester avanzati”.