Aggiungi un test unitario per ogni nuovo bug

Nel mio lavoro tutti gli sviluppatori che risolvono un bug devono aggiungere un nuovo test unit che avverte di questo tipo di bug (nel caso si verifichi di nuovo). Se un test unitario non è possibile (ad esempio un problema di progettazione di una pagina Web), il dipartimento QA deve creare un test case per verificarlo manualmente.

L'idea alla base di ciò è che se un difetto non è stato rilevato prima del rilascio del prodotto è perché non esiste un test unitario appropriato per rilevarlo. Quindi lo sviluppatore deve aggiungerlo.

La domanda è: è comune in qualsiasi metodologia di sviluppo software? Questa tecnica ha un nome? Vorrei saperne di più, ma ho bisogno di alcune informazioni per iniziare.

Questo è abbastanza comune. Lo usiamo nel nostro team. Per ogni difetto di produzione, lo sviluppatore deve aggiungere una nota sulla causa principale del problema, aggiungere un test unitario non riuscito e aggiungere un'analisi di impatto del test prima di poter inviare il ticket allo stato di sviluppo per verificare il codice.

Il test unitario fallito deve passare prima di poter inviare il codice alla produzione.

Non penso che questo abbia un nome specifico tranne quel "test di regressione" generale. Questo è molto utile e abbiamo iniziato a vedere un aumento della qualità del prodotto dopo aver iniziato a seguire questo processo.

Assolutamente!

Se sei d'accordo che i test unitari sono una buona cosa, allora ti renderai conto che se c'è un bug allora c'è un test unitario mancante che copre quel percorso di codice.

Quindi ciò che dovrebbe accadere è scrivere un test unitario che mostra che esiste il bug, correggere il bug reale, quindi il test unitario passerà.

Se non si hanno test unitari, questo può essere un buon modo per iniziare a introdurre test unitari in un progetto.

La tecnica è lo sviluppo test-driven. In realtà non si tratta di individuare un bug simile la prossima volta, anche se la serie di test ripetibili è sempre utile. Il punto è che puoi dimostrare che hai isolato ciò che è sbagliato nel codice, dimostrato che è sbagliato, risolto, dimostrato che la correzione è corretta.

C'è una citazione che non riesco a ricordare o trovare, ma all'incirca è: "Ogni errore è un test non ancora scritto".

Cercare di venderlo come test di regressione è una battaglia persa, IMHO. Dato quanto raramente queste cose catturano un bug ripetuto, la maggior parte degli sviluppatori dirà semplicemente "Perché preoccuparsi, quando posso semplicemente risolverlo?"

Questa tecnica è piuttosto comune e, secondo me, il nome migliore è "Defect Driven Testing" (l'ho inventato io stesso e poi l'ho trovato descritto con questo nome molto tempo fa ).

A volte potresti vedere alcune persone chiamare questi test "Test di regressione", ma personalmente trovo un po 'difficile giustificare questo nome. Una definizione un po 'più diffusa (e che, probabilmente, ha molto più senso per questo nome) di "test di regressione" è "eseguire test dopo aver apportato modifiche al codice per assicurarsi che non siano state introdotte regressioni" e il proprio elemento della configurazione che testa ogni ramo in push al repository lo soddisfa.