Hai partecipato a un progetto software che ha superato il budget prestabilito e non ha rispettato nessuna scadenza? Certo che sì, è successo a tutti. In effetti, se non ti è mai capitato, allora sei davvero un caso raro mi piacerebbe sapere la tua opinione.
Nelle prime fasi della mia carriera nel software development, ho imparato l'importanza di lavorare a ritroso rispetto a una deadline. Se un progetto deve essere completato entro una certa data e sappiamo che il test richiederà un certo periodo di tempo, allora possiamo usare queste informazioni per tornare indietro e scegliere una data di scadenza per il nostro progetto. Perfetto, vero?
Beh, non proprio. Anche se pianificare la fase creazione in tempo per eseguire i test manuali abbia ridotto un po' lo stress negli ultimi giorni di realizzazione dei progetti, c'erano ancora troppe sorprese.
Completare la creazione in tempo per i test di QA è un'ottima cosa in teoria, ma nella pratica perde utilità non appena viene identificato il primo bug o difetto.
Quanto tempo ci vorrà per risolvere questo difetto? Quanto influirà sulla tempistica? Verranno introdotti nuovi bug? Come faremo a garantire che ogni correzione venga verificata in tempo per correggere tutto ciò che abbiamo compromesso mentre correggevamo il primo problema?
In definitiva, non sono mai riuscito a trovare la giusta quantità di tempo da dedicare al QA. Inevitabilmente, correzioni affrettate venivano combinate all'ultimo minuto; ho imparato a tenere il mio calendario libero per un paio di settimane dopo i lanci più importanti, in modo da poter valutare tutti i problemi che ci sono sfuggiti (o che abbiamo introdotto).
Il problema, in fin dei conti, non era il tempo disponibile per i test, ma piuttosto la tempistica dei test. Avevo bisogno di fare i test prima e più spesso. Avevo bisogno di un test shift-left.
Se immaginiamo il nostro processo di sviluppo software come una linea temporale che scorre da sinistra a destra, allora il "test shift-left" diventa in qualche modo autoesplicativo. In parole povere, si tratta di eseguire test nelle fasi più precoci, coinvolgendo nella strategia di test i membri del team, compresi i tester, gli sviluppatori e gli stakeholder, e integrando i test sia per le funzioni esistenti sia per quelle nuove più spesso nel ciclo di vita dello sviluppo.