Uno sviluppatore può eseguire test in modo efficiente? [duplicare]

Mi considero un ottimo tester tra gli sviluppatori . Sono molto severo sul modo in cui vengono scritti i test automatici, compresi i nomi dei test significativi per l'azienda o il dominio, non permettendo ai test di impigliarsi nei dettagli dell'implementazione, ecc. Nella mia azienda ho aiutato (insieme a un tester) a introdurre Tecniche BDD e test di accettazione utilizzando per la prima volta il linguaggio Gherkin.

In altre parole, mi interessa molto dei test del software, per uno sviluppatore . Ho passato molto tempo a leggere James Bach, Google Testing, Adam Goucher, Ben Simo, ecc. - probabilmente più di un sacco di testers veri leggono. E non mi dispiace dirti che il mio team (uno tra i tanti) ha pubblicato costantemente rilasci con i più bassi bug e meno gravi bug.

Ma non sono un tester . Sarei inorridito se il project manager venisse da me un giorno e mi informasse che avrei assunto tutte le mansioni di test. Qui ci sono solo i problemi più gravi con questo approccio:

1. Non provo come . La maggior parte degli sviluppatori non ama testare. E quando le persone continuano a dover fare qualcosa che non vogliono fare, bruciano. Di solito cito la mancanza di un vero team di QA come uno dei motivi principali per cui ho lasciato la mia precedente azienda.

2. I test esplorativi (anziché scrivere il codice di test automatizzato, che gli sviluppatori dovrebbero fare o almeno riesaminare) sono un'attività molto manuale. È inefficiente semplicemente perché la programmazione a livello di esperti / esperti ha un ROI molto maggiore rispetto ai test a qualsiasi livello. Abbiamo un team interfunzionale con un tester 2: 3: il rapporto di sviluppo e tuttavia i tester spesso riescono a malapena a tenere il passo perché hanno altri compiti (gestione del rilascio, regressioni, ecc.). Semplicemente non ha senso per gli sviluppatori testare.

3. Gli sviluppatori e i tester hanno una mentalità completamente diversa. È difficile da spiegare a meno che / non abbiate avuto la possibilità di lavorare al loro fianco. I buoni tester tenteranno di fare cose che non sono descritte da nessuna parte nelle specifiche, cose che gli sviluppatori non avrebbero mai pensato in un milione di anni, in genere sulla base del fatto che sembra stupido agli sviluppatori. Ma i tester stanno testando l'utente , non lo sviluppatore, il che significa che devono provare intenzionalmente a fare cose stupide, testare tutto in contrasto con un insieme ben noto di percorsi felici e tristi. È molto interessante avere uno sviluppatore, un tester e un BA / product manager nella stessa stanza e parlare di un bug controverso; otterrai una prospettiva totalmente diversa da ciascuna.

4. Gli sviluppatori sanno troppo . Poiché hanno costruito (o contribuito a costruire) una caratteristica particolare, sanno esattamente quali condizioni iniziali dovrebbero essere messe in atto per farlo funzionare e quasi sempre prendono scorciatoie nei loro test, come modificare direttamente i database o modificare temporaneamente la configurazione File. Anche se non fanno nessuna di queste cose, sanno ancora esattamente quali passi prendere e in quale ordine. I tester - o davvero, chiunque sia non uno sviluppatore - mancherà di queste conoscenze e / o della capacità di prendere quelle scorciatoie e testerà letteralmente il sistema da un capo all'altro, e l'"integrazione" è precisamente dove il maggior numero di bug di solito tende a materializzarsi.

Il modo migliore che riesco a pensare per riassumerlo in meno parole è:

• Gli sviluppatori si concentrano sul design
• I tester sono focalizzati su attività
• I project manager sono focalizzati su funzionalità
• Il resto dell'azienda si preoccupa del prodotto

Se non si ottiene un feedback adeguato da tutti questi gruppi diversi, la qualità del prodotto e l'efficacia complessiva del team ne risentiranno. Notevolmente.

Gli sviluppatori dovrebbero non essere responsabili per i test. Se ti viene chiesto di gestire tutti i compiti di prova, corri per le colline. È un lavoro a tempo pieno che richiede un set di abilità molto diverso dalla programmazione.

P.S. Se dovessi indovinare perché gli sviluppatori quasi universalmente detestano i test, direi che probabilmente è perché non produce nulla nel senso che fa la codifica. Creare scenari di test è più una disciplina analitica che una vera e propria creatività, e la sandbox creativa è una ragione importante per cui sviluppatori come programming . Non è coding che mi piace, di per sé; sta vedendo i frutti delle mie fatiche.

L'obiettivo finale di un tester è quello di produrre esattamente ciò che gli sviluppatori non vogliono conoscere: un elenco di motivi per cui devono smettere di lavorare su quella nuova e interessante funzionalità e tornare a aggiustando qualcosa che pensavano fosse già stato fatto. Non è un'attività divertente, per uno sviluppatore.

Direi che il problema è meno che gli sviluppatori non amano i test piuttosto che gli sviluppatori che conoscono il flusso che hanno immaginato che l'utente sta utilizzando il loro prodotto, quindi tendono a rimanere inconsciamente in quel percorso felice. I tester, d'altra parte, non sanno quali passi lo sviluppatore si aspetta che l'utente prenda, così si allontaneranno dal percorso e scopriranno cosa si interrompe quando lo fai.

Inoltre, ci sono alcune cose che non vedi o che non hai mai guardato per cominciare. Ad esempio, se copio e incolla il testo che viene mostrato sullo schermo da un documento che proviene direttamente dal client, spesso non lo guardo per errori di battitura o grammaticali.

Ciò che ottieni da un tester che non è uno sviluppatore è un insieme di nuovi occhi. Prova come potrebbe, uno sviluppatore non può guardare il suo prodotto come qualcuno che non l'ha mai visto. Così può finire per attraversarla molte volte e non vedere più cose. Questo non è il miglior uso del suo tempo, dal momento che non sarà mai in grado di darti quello che un paio di occhi freschi farebbe. Inoltre, è probabile che sia relativamente costosa per tale compito.

Se uno sviluppatore ha una vasta conoscenza in azienda o nel campo di per sé, allora è possibile che uno sviluppatore collauda in modo efficiente.

Un problema è che gli sviluppatori amano codificare e non codificano molto nei test. Un altro problema è che lo sviluppatore probabilmente si sta concentrando sul compito da svolgere (che si tratti di creare un nuovo schermo o correggere bug esistenti) che non sarà in grado di testare altre parti del codice perché lo sviluppatore si aspetta che dal momento che / non ha cambiato la logica delle altre parti del programma, quindi il programma dovrebbe comportarsi esattamente come prima. Sono colpevole di entrambi questi problemi. :)

Ci sono diversi aspetti che rendono difficile per uno sviluppatore essere un tester. Non è un compito impossibile, ma trovare uno sviluppatore esperto nell'essere un tester non è una cosa comune.

Lo sviluppatore sostiene che il sistema funzioni correttamente. Ogni cosa che hanno scritto e fatto in precedenza sta portando a codice correttamente funzionante. Ogni caso limite è già stato testato come parte della scrittura del codice. Ogni caso d'uso è già stato codificato. Ogni percorso del codice è stato pensato. Quando l'applicazione viene consegnata a una fase di test, lo sviluppatore ritiene che funzioni correttamente.

Il tester è il sostenitore del sistema è rotto in modi strani e sottili - e capiranno come. A volte ciò comporta solo l'iterazione di passare attraverso una serie di script di test. Altre volte questo sta cercando di abusare del sistema in modi che lo sviluppatore non ha mai pensato (cosa succede se faccio triplo clic qui invece di fare doppio clic? Cosa succede se inserisco l'indirizzo di broadcast di rete nel punto in cui dovrei inserire l'indirizzo IP del router?). Queste sono spesso cose che esistono solo al di fuori delle specifiche aziendali.

Nota la frase sopra "abusare del sistema in modi che lo sviluppatore non ha mai pensato". Lo sviluppatore del codice ha una difficilissima immaginazione di nuovi modi di romperlo che non ha già codificato. Ciò riduce l'efficienza dello sviluppatore come tester.

Talvolta i test sono noiosi come noiosi per uno sviluppatore. Non è visto come un processo creativo - non c'è niente da costruire. Questa è spesso la mentalità dello sviluppatore. Molti sviluppatori diventano ansiosi e demotivati se non scrivono codice troppo a lungo. Prendere uno sviluppatore e spostarli dalla codifica (dove potrebbero scrivere il prossimo ciclo di funzionalità o la prossima applicazione) in un punto in cui tutto ciò che stai facendo è eseguire la stessa cosa più e più volte è decisamente noioso. E quindi gli sviluppatori non lo fanno spesso bene.

È stato trovato un bug e ora lo sviluppatore è tornato al codice: trovare il bug e correggerlo. Esiste il passaggio da un mindset (test) a un altro (in via di sviluppo) - Human Task Switch Considerated Harmful . Questi interruttori non avvengono rapidamente. Ci sono i lati concreti del passaggio dove lavori fisicamente (non hai lo sviluppatore testare il prodotto sulla propria postazione di sviluppo personalizzata che va ben oltre ciò su cui verrà eseguito il prodotto ... giusto?).

Tutto sommato, mentre gli sviluppatori possono essere testers, gli sviluppatori sono raramente efficienti tester rispetto a chi vuole fare test e può mantenere la mentalità del sistema non funziona bene.

Grazie per la citazione dal nostro libro Test automatico del software - un libro che abbiamo scritto 14 anni fa.

È interessante notare che dalle risposte qui possiamo vedere che alcuni sviluppatori concordano sul fatto che ancora non amano i test, perché invece, dalla mia esperienza, a loro piace concentrarsi sullo sviluppo di funzionalità.

Alcuni eseguono davvero un buon test dell'unità di lavoro, ma test di integrazione e / o sistemi di test dei sistemi più ampi non fanno realmente parte della descrizione del loro lavoro. Di qui la necessità di un ruolo di test separato che possa concentrarsi su "altri" test da quello delle attività di test di sviluppatori / unità e componenti.

Beh dipende da che tipo di test stai parlando. Se fai riferimento ai test di unità o ai test di integrazione, credo che dovrebbe essere fatto solo dagli sviluppatori, dal momento che il loro codice si baserà molto su di esso.

Se test manuale o test automatico, ad esempio, credo sia un lavoro per tester; molto probabilmente gli sviluppatori non copriranno tutti i flussi solo quelli principali.

So in a work place, if a member from dev has to perform a testing part, wouldn’t he’ll do it efficiently?

Ovviamente è un po 'di genralizzazione ma sì, più spesso gli sviluppatori non saranno efficaci tester. Il test è una vera e propria abilità, devi entrare nella mente degli utenti anche essere in grado di trovare efficacemente tutti i modi in cui il software può essere usato e abusato. Un sacco di test (cioè test di carico) richiedono conoscenze e licenze per strumenti specializzati.

And why developers don't like testing?

Di nuovo una generalizzazione (alcune persone lo fanno). Le persone a cui non piace tendono a non gradirlo perché è difficile, non sanno quello che stanno facendo e ci vuole molto tempo per lo sviluppo.