Cosa dovrebbero testare gli sviluppatori prima di inviare il proprio lavoro ai tester? [chiuso]

Is there a checklist the developer must go over before passing their work to testers?

Assolutamente. Idealmente, questa lista di controllo si compone di due elementi:

• Verifica che il ciclo di integrazione continua sia terminato e
• Crea una voce in un sistema di tracciamento bug / funzionalità per le modifiche che vanno a QA

La vera checklist è nascosta dietro la tua strategia di integrazione continua. Poiché questo elenco è gestito centralmente e completamente automatizzato, i singoli sviluppatori non possono lanciare il proprio codice oltre il muro per controllare il QA "dimenticare" per controllare qualcosa di importante prima di inviare il proprio lavoro al team di controllo qualità. Sai che gli sviluppatori spesso diventano "smemorati" sotto la pressione del tempo, giusto?

Il sistema di integrazione continua deve eseguire una compilazione ed eseguire tutti i test di unità e integrazione. Inutile dire che gli sviluppatori devono rendere disponibili nuovi test unitari al sistema di integrazione continua mentre sviluppano nuove funzionalità e correggono i bug.

Gli sviluppatori non devono toccare ciò che esce dal sistema di integrazione continua prima di darlo al QA, nemmeno installare e provare rapidamente. Se il QA afferma che la build non è stata installata, è necessario correggere il ciclo di integrazione continua per assicurarsi che non sputa artefatti non installabili o non funzionanti.

Il secondo passo è piacevole (contrassegnando un bug corretto o una funzionalità completata), così gli sviluppatori raramente, se mai, dimenticano di farlo.

Questo dipende. Ci sono diverse filosofie:

• Test Driven Development vuole che tu scriva Regression / Unit-Test prima ancora di iniziare a scrivere codice.
• il codificatore conosce le parti difficili del codice e potrebbe testare di conseguenza
• un tester indipendente potrebbe trovare errori a cui lo sviluppatore non ha mai pensato. Inoltre, il tester potrebbe avere maggiore familiarità con l'area in cui il software è effettivamente impiegato e potrebbe eseguire alcune convalide ("Stai costruendo la cosa giusta?" Rispetto alla verifica "Stai costruendo bene?").

Quindi il livello di test di ciascun partner dipende dal tuo progetto e dalla tua organizzazione. È importante essere d'accordo su questo livello in anticipo. Ovviamente il codice dovrebbe almeno compilare ed eseguire senza generare errori.

Fa ciò per cui è stato progettato? Getta le eccezioni appropriate quando viene dato un input errato? È utilizzabile? (che si applica alle API e alle interfacce utente).

Il tuo codice dovrebbe essere - per quanto a tua conoscenza - privo di bug prima di darlo ai tester. Dovresti fare tutti i test che devi fare per sentirti a tuo agio con la qualità del tuo codice.

Tutto ciò che puoi in modo tale che il QA non ti risponda, facendo in modo che il tuo manager dica "chiaramente non hai verificato questo deliverable". Potresti avere a disposizione test di unità, integrazione, sistema e manuale (cioè tu). Non riuscire a farlo significherebbe solo sprecare il tempo del controllo di qualità.

Un esperto di QA che ha lavorato per me chiedeva "prove" che gli sviluppatori avessero testato il deliverable. Questo potrebbe essere risultato xUnit, output da script o persino una checklist basata su carta. Basti dire che questo ha impedito agli sviluppatori di inoltrargli l'output della build.

Da un punto di vista del tester, l'errore più grande di uno sviluppatore è quello di fornire un codice che non viene compilato.