Sistema quality assurance (QA)

Prima di ogni rilascio si costruisce una scheda “Piano” che definisce il perimetro del collaudo: le nuove funzionalità, le aree più rischiose e i dispositivi e browser di copertura. Quando la release candidate è pronta, si passa a “Esecuzione”, dove i tester percorrono gli scenari e registrano l'esito di ogni caso. Ogni difetto scoperto genera una scheda “Bug report” con passi di riproduzione, risultato atteso ed effettivo e grado di gravità; uno sviluppatore se ne fa carico e lo corregge. Il bug corretto torna in “Verifica”, dove un tester diverso dal suo autore lo collauda e si assicura che la correzione non abbia rotto altro. Quando i bug critici si azzerano, la scheda madre passa a “Lancio” con una raccomandazione formale, e i numeri confluiscono in “Report”: quanti casi eseguiti, quanti bug trovati e in quali aree si concentrano i difetti.

La chat è la sala operativa durante il collaudo: un bug critico che ferma il rilascio vi si annuncia subito, e la domanda se un comportamento sia intenzionale o un errore si risolve con lo sviluppatore in un minuto, invece di generare un report respinto. Ma la regola è ferrea: ciò che si decide in chat si registra sulla scheda del bug stessa — la bacheca è lo storico, non la memoria.

Il QA manager scrive il “Piano”, distribuisce l'esecuzione e possiede la decisione di raccomandare il lancio — ed è lui a fermare il rilascio se restano bug critici. I tester eseguono e scrivono i bug report con uno standard uniforme; gli sviluppatori ricevono i bug report, correggono e li rimandano in “Verifica”. Il principio del sistema: il tester non verifica la correzione di un bug che ha scritto lui stesso, e il lancio è una decisione documentata con i numeri, non una sensazione generale che tutto sembri a posto.