Trattare con uno sviluppatore ignorando continuamente casi limite nel suo lavoro

Richiedigli di scrivere test unitari automatizzati per il suo codice. I test delle unità di scrittura costringono a pensare attraverso i casi limite.

Alcuni dettagli:

1. Per assicurarti che non si senta individuato, questo dovrebbe essere istituito per l'intera squadra. Richiede a tutti di scrivere test unitari automatici per il nuovo codice o codice che modificano.
2. Richiedere che i nomi dei test unitari siano descrittivi sul caso che stanno testando.
3. Copri i test delle unità automatizzate nella revisione del codice ad alto livello. Chiedi ai revisori di cercare i casi di test mancati (cioè quei casi limite che perennemente manca). Dopo una certa quantità di feedback da parte del suo team sui casi di mancato rispetto, probabilmente imparerà a prenderli in considerazione prima della revisione.
4. Applica questa regola per l'intero team: se il QA trova un bug, lo sviluppatore responsabile deve il test automatico che conferma l'errore e quindi dimostra che l'hanno risolto. (prima di fare qualsiasi altro lavoro)

Dagli un elenco di controllo, ad es.

• input nulli
• input all'estremità della gamma estrema estrema
• input alla fine del range estremo
• combinazioni
• input che violano le invarianze presunte (ad es. se x = y)

I membri del QA possono aiutarti a trovare la checklist

Dai la lista di controllo a tutti gli sviluppatori, non solo a questa.

Good engineer.

D'accordo.

But there is a problem with him - very often he fails to address edge cases in his code.

È una buona idea che i tecnici non condividono.

Guardare i casi limite è una caratteristica che è presente o no nelle persone. Non ha nulla a che fare con l'essere un ingegnere o un programmatore. Lo sviluppo di questa caratteristica è influenzato dal background culturale, dall'ambiente di vita, dagli eventi dell'infanzia e dalle esperienze di vita. Quindi l'atteggiamento si applica semplicemente a qualsiasi lavoro svolto da un individuo.

Ciò di cui hai bisogno è scoprire se il tuo ragazzo è di quel tipo che non ha sviluppato questo senso (forse ancora). È anche molto probabile che a lui semplicemente non importi per una ragione o per l'altra. Devi analizzare l'intera situazione, se è felice nel suo lavoro. Altrimenti, forse dovresti fare qualcosa per aiutarlo per primo.

Se sta bene con il lavoro ma non ha ancora sperimentato il pericolo dei casi limite, allora puoi iniziare a educarlo. Se lo prende sul serio, potrebbe cambiare modo nel tempo. Anche se sono scettico su questo, puoi comunque provarlo.

Se tuttavia si rivelerà essere quel tipo di persona che non è brava nei casi limite, allora non rimarrai nient'altro che rimuoverlo dalla squadra. Questa caratteristica è essenziale per la programmazione pratica. Purtroppo, senza di essa nemmeno una grande persona non produrrebbe un buon lavoro.

Potresti fare revisioni del codice o revisioni del progetto prima nel processo?

Insegnagli a programmare prima il test. Accoppia con lui. Scriverete i casi di test e scriverà il codice per superare i test.

È possibile che il QA venga coinvolto abbastanza presto nell'aiuto per lo sviluppo delle funzionalità fornendogli un elenco di casi limite all'inizio della pubblicazione? Mentre alcuni potrebbero vedere questo come se non si aspettassero che lo sviluppatore copra tutto, questo potrebbe essere un modo per ovviare a questo problema se tende a perdere quei casi limite che un tester potrebbe facilmente afferrare inizialmente.

L'altra idea che avrei qui è come vede questo problema. È davvero infastidito e ticchettava su se stesso per questo modello o lo vedeva semplicemente normale e non c'era qualcosa per lui che si preoccupasse di risolvere? Certo, questo richiede molta fiducia e lo porta ad essere aperto sulla sua prospettiva, ma penso che qui ci sia un certo grado di empatia che può aiutare se riesci a vedere le cose dal suo punto di vista.

Ci sono un numero infinito di casi limite, che li copre tutti è irrealizzabile. Cosa succede se qualcuno fa #define TRUE FALSE ? Aggiunge casi limite, li controllerai anche tu?

Inoltre, non prenderei in considerazione l'infallibilità di ogni funzione di una classe privata o di una funzione interna.

L'approccio che scelgo per il codice che deve essere molto solido e stabile è:

if(conditions_met)
{
DoStuff();
}
else
{
CrashAppAndDumpMemory();
}

In questo modo si ottengono dump di applicazioni solidi in QA e, al momento del rilascio, l'app è solida e sicura.

Lavorare attorno agli errori è sbagliato. Ok, potresti salvare una funzione se l'handle del file è nullo e restituisce null, ma nella maggior parte dei casi, c'è un errore di progettazione da qualche parte, e l'arresto anomalo dell'app è un modo migliore per costringerti a trovare la causa. La maggior parte dei casi edge limita l'errore nascondendo un problema, ad esempio: il pulsante smette di funzionare. Crash ti dice che alcune ipotesi sul prodotto sono sbagliate e devi correggere la logica che ha causato l'arresto.

Se è un caso limite, ha anche bisogno di essere considerato? Se i casi limite sono importanti, i casi limite devono essere inseriti nei requisiti / funzionalità / storia utente.

Se i casi limite sono stati considerati come parte di un lavoro e i dispositivi devono essere messi in posizione, allora dovrebbero essere parte dell'elemento di lavoro e, per definizione, l'elemento di lavoro non è completo fino a quando il meccanismo per la gestione del caso limite è a posto.

Questo ti dà il compito del team di controllare qualcosa dopo che il lavoro è stato completato durante la discussione post-lavoro e dà allo sviluppatore qualcosa da controllare mentre completa il lavoro.

I casi di catching edge sono il motivo per cui il QA esiste. I programmatori hanno la responsabilità di spingere il lavoro in modo tempestivo. Trascorrere tutto il loro tempo alla ricerca di casi limite è molto inefficiente. Se si dispone di un ciclo iterativo ragionevolmente veloce, questo non dovrebbe rappresentare alcun problema. I casi limite sono vicini all'infinito. Se fosse un problema con i casi "core", sarei un po 'preoccupato. Proprio come gli sviluppatori sono esperti nello sviluppo, un tester dovrebbe essere un esperto in fase di test. Quando un tester trova un problema, lo rimanda allo sviluppo. Lo sviluppatore risolve il problema. Problema risolto. Il tempo per uno sviluppatore di rintracciare ogni caso limite è molto più lungo del ciclo di test iterativo. Inoltre, quando parlo di testing, non intendo i test dell'unità white box, ma i test rigorosamente black box. Scrivere i test delle unità è il ruolo dello sviluppatore e fa parte del processo di sviluppo, non del processo di test.