I test non dovrebbero essere utilizzati solo per dimostrare che una funzionalità funziona, ma anche per scoprire il prima possibile che una modifica abbia causato il blocco di una funzione.
I vantaggi del test più spesso sono che in genere avrai più tempo prima del prossimo grande traguardo per trovare e risolvere il problema che causa il fallimento dei test, e poiché il tempo che intercorre tra le esecuzioni del test è breve, c'è solo un limite numero di modifiche che potrebbero aver introdotto il problema.
Attualmente sto lavorando anche a un prodotto incorporato e abbiamo organizzato le nostre attività di test in questo modo:
- Lo sviluppo viene eseguito secondo il modello Git Flow: le modifiche vengono apportate sui rami delle funzionalità e sono integrate nel software principale solo dopo una revisione (riuscita). In parallelo con la recensione, vengono eseguite le unittests (su una macchina di compilazione) e un test di integrazione limitato (sull'hardware di destinazione reale). Questo test di integrazione limitato richiede circa 20 minuti.
- Ogni notte, se vengono apportate modifiche al ramo principale del software, viene eseguita un'analisi di regressione di quasi tutti i test di integrazione. Questa esecuzione di test richiede circa 5 o 6 ore per l'esecuzione sull'hardware di destinazione ed esclude solo i casi di test che richiedono una quantità eccessiva di tempo.
- Ogni fine settimana vengono eseguiti i test che richiedono molto tempo (in genere tra 10 e 24 ore per testcase).
Una storia / funzione non è considerata completata fino a quando il codice non è stato integrato nel ramo principale del software e la sessione di test notturno non mostra problemi (che possono essere attribuiti alle modifiche apportate per la storia / funzione).
Oltre a questi test di integrazione interna, ci sono anche altri team che eseguono test di integrazione a livello di sistema per verificare quanto il nostro prodotto funzioni in un ecosistema più ampio.
Il vantaggio di questo modo di lavorare è che ottieni un feedback più rapido quando il tuo cambiamento rompe qualcosa che non intendevi, ma richiede un modo di lavorare in cui il work-in-progress non è mescolato con il lavoro che era già completato.