I prodotti software massicci sono costruiti sopra, tra le altre cose, un'infrastruttura di test ancora più massiccia, contenente letteralmente 1000 test dedicati di diverso tipo.
Tutti questi test sono lì per assicurare che il software abbia la correttezza funzionale progettata in ogni aspetto, e la resilienza per funzionare bene sotto pressione o attacchi (usando stress designati e fuzz test, tra gli altri) in ogni dato momento.
In parole povere - se tutti i test passano in laboratorio per un periodo di tempo sufficientemente lungo, abbiamo una release stabile.
Come ci muoviamo da una release stabile all'altra?
In cima alle release stabili, costruiamo rami in cui arricchiamo il software con nuove caratteristiche. Questo sviluppo causa una naturale instabilità dovuta a una moltitudine di fattori, tra cui i principali sono la mancanza di consapevolezza da parte degli sviluppatori della complessità del software e del suo ambiente di test, la bassa copertura dei nuovi test o semplicemente una codifica sciatta. Questa instabilità si riflette semplicemente nel numero di test che iniziano a fallire come risultato di alcuni sviluppi. I fallimenti sono riconosciuti, e il team si concentra sulla correzione dei problemi rilevati mentre si sforza di ottimizzare la copertura dei test delle nuove caratteristiche. Quando il nuovo ramo si stabilizza, la nuova release candidate può essere spedita ai clienti interni per alcuni test preliminari delle nuove caratteristiche e del comportamento generale. Se tutto va bene, tornando alla definizione originale di stabilità - se non vengono scoperti nuovi difetti per un certo periodo di tempo, sia dal team di sviluppo che dai clienti interni, e il nuovo ramo si comporta bene in laboratorio (avendo risultati di test coerenti con la release principale e stabile), può essere unito alla linea principale, a quel punto possiamo affermare di avere una nuova release stabile.
Il ciclo va avanti, e avanti, in perpetuo.