Test

Bene, non vuoi bug evidenti. Rilasciare velocemente non significa che dobbiamo rilasciare cose che rompono l'applicazione o che hanno un aspetto brutto.

È una buona idea testare qualcosa prima del rilascio. Il test è, come ogni altra cosa, un argomento vasto e ci sono diverse scuole su come farlo. Ovviamente non stiamo parlando di una "fase di test" alla vecchia scuola di gestione del progetto.

Aspettare di testare tutto alla fine di un progetto può sembrare divertente oggi, ma era una pratica comune e lo è ancora in molti progetti a cascata. Fortunatamente, la maggior parte si è spostata. Aspettare con il test e i sviluppatori si sono spostati e hanno dimenticato, e quasi è un nuovo progetto per correggere tutte le piccole cose.

Oggi le aziende usano il testing continuo, che deve avvenire in un ambiente di test prima che il ticket/storia/correzione vada in produzione (venga rilasciato).

In questo modo, possiamo codificare funzionalità, testarle, dare feedback, codificare di nuovo e continuare a testare finché non siamo soddisfatti del risultato. Possiamo rilasciare ogni volta che è pronto su base per funzionalità.

In molti processi di sviluppo, lo sviluppatore codifica qualcosa, poi lo testa un po' sul computer locale e poi commette il codice e fa una richiesta di pull per la revisione dei pari (nel caso migliore). Poi è nell'ambiente di test.

Qui, alcuni sviluppatori amano passare a una squadra di QA ("Assicurazione della qualità") che prende in carico la responsabilità del test e "assicura" che abbia "la giusta qualità". Questo sembra buono sulla carta. Non farlo! Almeno non così.

Leggi di più in "Il Playbook del CTO" disponibile su Amazon/Kindle.