Come ridurre gli errori prima del test?

P. Brian Mackey ha ragione sul fatto che TDD sia utile - e qualsiasi test unitario migliorerà drasticamente le cose. Come tester, posso dirvi che una suite di test unitaria riduce drasticamente il numero di bug, e limita i restanti bug funzionali a molte aree prevedibili in cui posso concentrare i miei test (principalmente punti di integrazione / interazioni ambientali). Questo semplifica la copertura del test e rende i test più rapidi.

Altre idee:

• Ottieni il QA coinvolto al più presto . Se non hai almeno uno specialista di QA seduto su tutti o quasi tutti gli incontri, a partire dalla fase di progettazione, ti manca molto valore. I collaudatori esperti possono aiutare a trovare difetti di progettazione, introdurre piccole funzionalità che velocizzano notevolmente i test e possono iniziare a pianificare la strategia di test prima che siano coinvolti in riunioni di progettazione.
• Ottieni buoni, solidi requisiti, facendoli precocemente e sottoponendoti al controllo qualità per esaminarli. Un buon specialista di QA troverà buchi nei requisiti che nessuno ha pensato di risolvere. A volte le cose che sono dettagli minimi per gli sviluppatori sono enormi blocchi per il controllo qualità (ad esempio, le specifiche delle regole aziendali; dev può creare il framework per le regole e quindi aggiungere le regole effettive in seguito con un piccolo sforzo, ma i test non possono essere scritti fino a quando le specifiche sono conosciuti). I peggiori cicli di test che ho visto sono stati quando i BA non hanno ottenuto requisiti chiari, li hanno portati in ritardo o comunicano le modifiche ai requisiti verbalmente agli sviluppatori senza avvisare il QA. Inoltre, l'automazione del test non può essere sviluppata contemporaneamente allo sviluppo del prodotto senza buoni requisiti.
• Sviluppa più in modo incrementale . Non gettare l'intero prodotto sul QA, ma consegnare pezzi durante il ciclo di sviluppo poiché sono finiti per test dei componenti e test di integrazione dei componenti. Le tecniche di sviluppo agili sono ideali per ridurre i cicli di test e distribuirli in modo più fluido durante tutto il progetto in modo da non avere un enorme ringhio alla fine.
• Se hai sviluppatori o tester che leggono il codice che lavora in QA, fagli fare revisioni del codice così come sviluppatori (in modo che uno sviluppatore, un QA riveda le principali modifiche al codice). Ciò consente sia al QA di apprendere il codice base e il sistema, sia una prospettiva focalizzata sulla qualità del codice.
• Utilizza più automazione nella tua procedura di QA . Limita il test manuale ad alcune aree ben definite. I test automatizzati possono essere sviluppati prima che lo sviluppo sul componente sia completato, possano essere eseguiti di notte e richiedono relativamente poche risorse una volta sviluppate. Anche se probabilmente investirai più risorse di test nell'automazione, molto del tempo del tester accadrà prima del "collo di bottiglia del test", quando il tempo del tester è economico.
• Assicurati che gli sviluppatori lavorino e sblocchino i tester con priorità elevata durante l'intero ciclo di sviluppo. Quando scoraggiate un tester dal porre domande, imparare il sistema e, in genere, svolgere il proprio lavoro, acquisite un debito tecnico. Gli sviluppatori potrebbero non rendersene conto perché non si pagano interessi su quel debito fino a quando non si arriva alla fase di test; il costo è esternalizzato dagli sviluppatori.
• Automatizza la configurazione dell'ambiente di test. È molto dispendioso in termini di tempo e la maggior parte dei tester deve farlo almeno giornalmente per tenere il passo con correzioni di bug. Un tester dovrebbe essere in grado di installare l'intero (i) prodotto (i) con un singolo comando.

Utilizza lo sviluppo basato su test. In questo modo testerai e integrerai continuamente funzionalità. Nello sviluppo basato su CRUD, mi piace usare un'interfaccia iCRUD. Questo semplifica l'impostazione dei miei test. Crea solo ConcreteItemX che implementa iCRUD e imposta i 4 test (Crea, Leggi Elimina aggiornamento). Implemenent fino a quando non passano tutti i test.

Risciacqua e ripeti.

È bello testare più tardi la pipa. Non puoi aspettare fino a tarda fase del processo per iniziare effettivamente un vero test a causa del fatto che il costo per correggere un bug aumenta drasticamente nel tempo.

La prima cosa da fare è capire dove si stanno iniettando i difetti e dove vengono rilevati. Anche se sai che troppi stanno scivolando nella fase di test, non sai da dove provengono. Qui puoi applicare le tecniche di tracciamento per l'efficacia della rimozione dei difetti . Semplicemente, crea una matrice di fasi (dato quello che hai detto, le tue fasi sarebbero probabilmente requisiti, progettazione, implementazione, test e campo). Ogni volta che trovi un difetto, tieni traccia di dove l'hai trovato e da dove proviene. Per ogni fase, traccia la percentuale di difetti che sono stati identificati e rimossi.

Una volta che conosci quali fasi specifiche sono problematiche, puoi introdurre modifiche. Esempi di tecniche di qualità includono requisiti, design e revisioni del codice. L'analisi di causa ed effetto può anche essere utilizzata per determinare il motivo dell'iniezione di un difetto e cosa può essere fatto per prevenirlo. Gli elenchi di controllo possono essere impiegati per garantire la ripetibilità dei processi. Esistono numerosi strumenti di qualità, ma finché non sai dove sono i tuoi problemi e cosa li sta causando, fare qualsiasi cosa potrebbe essere uno spreco di risorse.

Raccomando di leggere Metriche e modelli di Stephen Kan nell'ingegneria della qualità del software . Questo è stato il libro di testo utilizzato nel corso di ingegneria del software e di qualità del prodotto della mia università ed è un ottimo libro per comprendere e migliorare la qualità a livello di prodotto e di processo.

Dove è possibile per gli sviluppatori scrivere test di unità, durante le fasi di sviluppo, sono assolutamente d'accordo con il consiglio di P.Brian.Mackey di usare Test Driven Development.

Tuttavia, recentemente abbiamo anche avuto molto valore dall'avere che gli utenti scrivevano cosa avrebbero fatto per testare il sistema prima che lo sviluppo iniziasse : questi sono noti come Test di accettazione degli utenti .

Ogni UAT inizia come un breve elenco puntato, che descrive cosa fa l'utente e dice cosa succederà. Registreranno anche cose come dove trovare i file di input di esempio.

Man mano che la funzionalità viene implementata, l'UAT viene arricchita con ulteriori dettagli, quindi sono una sorta di "documento vivente". Per questo motivo, abbiamo finito per archiviarli su semplici pagine wiki interne, piuttosto che su qualsiasi sistema di gestione dei documenti.

Questi risultati si sono rivelati preziosi in una gamma sorprendentemente ampia di situazioni:

1. Dicono agli sviluppatori esattamente quale sia il comportamento previsto, prima di scrivere il codice
2. Ciò consente di risparmiare tempo speso per l'implementazione di funzionalità errate, solo per sentirsi dire che "no, non era quello che volevamo - correggilo"
3. Servono come una sorta di manuale di istruzioni durante lo sviluppo:
   • per utenti reali, per consentire di provare il software durante la fase di sviluppo
   • per gli sviluppatori che sono nuovi in un progetto
4. Fanno appello a ogni sorta di domande utili su ciò che è necessario, prima ancora che inizi il lavoro - permettendoci di capire quali decisioni dobbiamo prendere, prima che inizi lo sviluppo
5. Forniscono agli sviluppatori una migliore comprensione del pezzo di lavoro, in precedenza - questo rende molto più facile stimare approssimativamente il tempo necessario per ogni fase.
6. E, naturalmente, semplificano anche la verifica del sistema.

Evidenza presumibilmente dice che uno di le migliori cose che puoi fare per ridurre gli errori, anche più del test stesso, è l'ispezione formale del codice.

L'articolo copre anche l'efficacia di molte altre tecniche che potresti prendere in considerazione (anche se le date precedenti al TDD non includono questo: personalmente sarei sorpreso se riuscisse a battere la revisione formale del codice, ma questa è opinione personale e non supportata da qualsiasi cosa).

Ci sono alcune sfide nella tua storia.

Le cose che ti vengono in mente sono un modo di sviluppo più agile (TDD è un grande, ma ci sarà un enorme divario nei test in quanto hai già un prodotto là fuori). L'integrazione continua e il delivery continuo aiuteranno a risolvere problemi di build e integrazione. Inoltre, un numero crescente di test unitari ti consentirà di migliorare la qualità e mantenere una base di regressione che indicherà che le nuove funzionalità interromperanno il codice esistente.

La cosa più difficile da cambiare sarà il processo reale, cose come l'integrazione continua richiedono l'implementazione di un set di strumenti che è una passeggiata nel parco rispetto alla modifica del processo.

Saluti, Carlo

Suggerisco di richiedere agli sviluppatori di test unitario e di impegnare i test sul controllo del codice sorgente insieme al codice. Nulla va a Qa senza una serie di test unitari che sono stati certificati come gestiti dallo sviluppatore. TDD è una grande idea (in cui scrivi i test prima di scrivere il codice) ma chiaramente i tuoi sviluppatori non stavano testando il loro codice, quindi inizia da lì. Solo perché hai un dipartimento di QA non esoneri lo sviluppatore dalla responsabilità di testare il suo codice.

La prossima revisione del codice dovrebbe essere un requisito nella tua azienda. Nessun codice viene realizzato fino alla revisione e ai revisori codificati verrà chiesto di non solo rivedere il codice per la precisione tecnica, ma per la conformità ai requisiti. Anche il codice di lavoro che fa la cosa sbagliata è un bug.

Quindi siediti con i giocatori (sviluppatori e qa) dai progetti falliti e passa attraverso i bug trovati e vedi se ci sono schemi che puoi vedere. Alcuni tipi di errori sono comuni? Allora forse i tuoi sviluppatori hanno bisogno di formazione su questi argomenti. Questa non è una sessione di biasimo, non ti interessa chi ha creato il bug, stai cercando di migliorare il processo e il primo passo è raccogliere i dati su ciò che è andato storto in modo da poterlo prevenire in futuro.

Avanti, i manager danno una buona occhiata al livello di abilità degli sviluppatori che hai. È meno costoso addestrare il personale esistente per migliorare le proprie competenze che licenziarli e assumere nuove persone. Tuttavia, se hai qualcuno che fa ripetutamente gli stessi errori e non impara mai dai loro errori, potrebbe essere il momento di considerare se stanno contribuendo alla compagnia. Vorrei iniziare con la formazione (sospetto che la tua cultura aziendale non abbia probabilmente dato loro la possibilità di migliorare, ho visto gli sviluppatori far riparare le loro cose da qualcun altro e non sapevano nemmeno che fosse cattivo) e poi vedere se gli stessi errori continuano. Poi, tra circa 6 mesi, rivedi le prestazioni e vedi se alcune persone non stanno migliorando di livello che devi avere.