Perché lasciare / non consentire agli sviluppatori di testare il proprio lavoro

Voglio raccogliere alcuni argomenti sul perché consentire a uno sviluppatore di testare il proprio lavoro come ultimo passo prima che il prodotto entri in produzione è una cattiva idea, perché sfortunatamente il mio posto di lavoro a volte lo fa (l'ultima volta che è arrivato , l'argomento si è ridotto alla maggior parte delle persone che sono troppo occupate con altre cose e non hanno il tempo di far conoscere un'altra persona a quella parte del programma - è un software molto specializzato).

Ci sono piani di test in questo caso (anche se non sempre), ma sono molto favorevole a creare una persona che non ha apportato le modifiche che sono state effettivamente testate durante il test finale. Quindi ti sto chiedendo se potresti fornirmi una buona e solida lista di argomenti che potrò sollevare la prossima volta che ne parleremo. O per fornire contro-argomenti, nel caso in cui pensi che questo vada perfettamente bene, specialmente quando ci sono casi di test formali da testare.

Come altri (e te stesso) hanno notato, gli sviluppatori dovrebbero testare il proprio codice. Tuttavia, in seguito, qualsiasi prodotto non banale dovrebbe essere testato anche da persone indipendenti (dipartimento di controllo qualità e / o cliente stesso).

Gli sviluppatori normalmente lavorano con la mentalità degli sviluppatori di "come farlo funzionare?" . Un buon tester sta pensando a "come risolverlo?" - una mentalità molto diversa. Unit testing e TDD insegnano agli sviluppatori a cambiare i cappelli in una certa misura, ma non dovresti fare affidamento su di essi. Inoltre, come altri hanno notato, esiste sempre la possibilità di incomprensioni. Pertanto, i test di accettazione finale devono essere condotti da qualcuno il più vicino possibile al cliente .

Lo sviluppatore sa come funziona il loro codice e si abituerà a testare il proprio codice in base a questa conoscenza.

Lo sviluppatore troverà difficile rimuoversi dalla mentalità di "come funziona" invece di "come dovrebbe funzionare".

Per questo motivo è meglio convincere qualcuno con un alto grado di obiettività a testare il programma, ovvero QA o Test Engineers

Testers da rompere, semplice. Questo tipo di pregiudizio è necessario per scoprire davvero i tappi dello spettacolo.

Gli sviluppatori DEVONO testare il loro lavoro. È una responsabilità implicita.

Presumo che tu non abbia un team dedicato a fare i test in base alla tua dichiarazione. Tuttavia, avere un team dedicato ai test sarà di grande aiuto poiché gli sviluppatori tendono a testare il proprio codice nel modo in cui lo hanno codificato. Ciò non significa che una volta che hai una squadra di controllo della qualità di qualche tipo, puoi già eseguire i test come responsabilità degli sviluppatori.

Gli sviluppatori di solito usano reti con enormi buchi per catturare i bug. Di conseguenza, scappano piccoli bug.

Perché gli sviluppatori non sono bravi a provare a rompere il proprio codice. La loro mente segue semplicemente il percorso corretto di immissione dei dati e l'interazione con l'applicazione. Molti bug sono il risultato dell'interazione con il sistema come un ragazzo normale . Gli sviluppatori non sono utenti normali. Sono utenti professionali.

Ci sono alcuni buoni motivi per avere un team di test dedicato. Innanzitutto, come accennato in precedenza, gli sviluppatori sono molto bravi a testare il funzionamento del loro codice, ma non a romperlo.

Inoltre, come dici tu, uno sviluppatore sa cosa hanno scritto, ma un team di test sa cosa avrebbe dovuto essere scritto. A volte, questi due concetti non corrispondono. Uno dei compiti del team di test è assicurarsi che il software soddisfi i requisiti. In molti casi, uno sviluppatore conosce molto bene solo alcune parti del sistema, ma il team addetto al controllo qualità sa tutto.

Il che porta al prossimo motivo, i team di test eseguono test di integrazione completi. Il pezzo di codice che hai appena scritto potrebbe funzionare bene da solo, ma potrebbe interrompere altre funzionalità che non conoscevi.

Avendo lavorato con un team di controllo qualità e senza, posso dirti che apprezzo il 100% del lavoro che svolgono e diranno che fanno parte del team di software. Quando hai un team di controllo qualità, rende il rilascio del codice molto più semplice, perché sai che è stato accuratamente testato e ciò significa che riceverai meno chiamate alle 3 del mattino.

Gli sviluppatori dovrebbero testare il proprio codice.

I tester indipendenti non solo testano di rompersi, ma testano anche le ipotesi non dichiarate e indefinite che gli sviluppatori hanno fatto durante la codifica.

Mi aspetto che lo sviluppatore esegua alcuni test iniziali prima di eseguire qualsiasi modifica e di accertarsi che il codice funzioni. Mi aspetterei quindi che lo sviluppatore inserisca nei casi di test le conoscenze specifiche relative alla "scatola bianca". Ad esempio, dettaglia ogni altra area del codice che potrebbe essere stata interessata.

L'obiezione principale agli sviluppatori che testano il proprio codice è che stai testando solo un punto di vista. Lo sviluppatore ha letto e interpretato la specifica. Speriamo che le specifiche siano chiare, complete e inequivocabili, ma non è sempre così. Lo sviluppatore potrebbe aver frainteso parte delle specifiche. Se testano il proprio codice, questo non verrà catturato poiché troveranno che la funzione funziona come previsto.

Diverse persone tenderanno inoltre a utilizzare un prodotto in modo diverso e di conseguenza a seguire percorsi diversi attraverso il codice. Uno sviluppatore si sarà assicurato che il codice funzioni per loro, ma potrebbe non aver considerato un caso limite che un altro tester potrebbe trovare.

Gli sviluppatori dovrebbero testare il proprio lavoro. Consentire agli sviluppatori di inviare il lavoro non testato a un team addetto al controllo qualità o ai loro colleghi sviluppatori è un'idea davvero negativa. Spreca il tempo di sviluppatori e tester allo stesso modo e rovina le relazioni.

Tuttavia, ciò non è sempre sufficiente. È probabile che gli sviluppatori seguano un percorso felice attraverso il sistema o siano ciechi rispetto ad alcune idiosincrasie a cui sono stati esposti più e più volte durante lo sviluppo.

Un altro punto è che possono esserci diversi livelli di comunicazione tra specifica e distribuzione. Questo può portare a un sussurro cinese sull'effetto finale schierabile. È meglio se chiunque abbia definito il requisito o la segnalazione di bug verifica che funzioni nel modo desiderato.

Come sviluppatore sei responsabile del tuo codice, dovresti testarlo. Does the feature work as expected?Se la risposta è sì, il gioco è fatto.

Perché non dovresti fare casi di prova?

1. Sei soggettivo , poiché i bug trovati sono scritti da te (o dai tuoi colleghi).
2. Sei troppo costoso per la società per eseguire case-test. (Io spero).

In genere, gli sviluppatori non saranno, nella maggior parte dei casi, quelli che utilizzano il codice, tranne in alcuni casi specializzati. Quindi l'ultimo passaggio di test prima della promozione in un sistema di produzione dovrebbe essere il test di accettazione dell'utente, UAT. In genere [dovrebbero essere] più familiari con ciò che si aspettano che faccia il pacchetto. E sono generalmente più capaci di spezzare le cose con flussi di ingresso sconosciuti a qualcuno che non lo usa quotidianamente.

I piani del tuo progetto non soddisfano i test degli utenti? Se fai testare gli utenti, potresti riscontrare bug prima della post-implementazione che nel mio mondo non è un male.

Gli sviluppatori non dovrebbero testare il proprio codice perché è simile a giudicare l'arte di tuo figlio. Ti sembrerà bellissimo in entrambi i casi, e hai davvero bisogno di un professionista per evidenziare i difetti. Test unitari d'altra parte è simile a garantire che il bambino non stia cercando di dipingere con il piombo.

Nel caso in cui ragazzi davvero NON volete assumere il controllo qualità, fate scrivere agli sviluppatori codice di test per altri sviluppatori. Questo è un buon primo passo: presto vedrai gli sviluppatori che richiedono risorse di controllo qualità perché la maggior parte del loro tempo viene speso per testare il codice di altri problemi, oltre a CR.

Non solo gli sviluppatori sono protettivi nei confronti del proprio codice, se non si rendono conto di un caso particolare, o interpretano erroneamente una specifica nel modo in cui sviluppano qualcosa, allora perderanno quei casi quando testeranno il loro codice.

Anche le tecniche e le competenze per i test sono molto diverse.

La maggior parte dei test da parte di un team di test è funzionale (che un prodotto funziona secondo una specifica) e black-box (il team di test non vedrà il funzionamento interno di un'applicazione). I tester funzionali non devono preoccuparsi di come funzionano le cose, devono solo concentrarsi sul loro funzionamento.

Nella mia esperienza, almeno nella mia piccola organizzazione, l'utente finale deve testare. Quasi ogni progetto che riceviamo, non riescono a fornire tutte le informazioni necessarie e tralasciano sempre alcuni dettagli. Lo sviluppatore è sempre in svantaggio di test perché non sa come svolgere il lavoro dell'utente, quindi mentre sa che il software funziona in base alle informazioni che gli sono state fornite, non sa se aiuterà l'utente finale fanno il loro lavoro.

Gli sviluppatori hanno letto e interpretato male i requisiti e i responsabili dei requisiti spesso non riescono a specificare le cose chiave. Se nessuno, tranne lo sviluppatore, verifica, nessuno troverà queste disconnessioni prima di andare in diretta. Quando gli sviluppatori testano, sanno troppo su come dovrebbe funzionare e non provano le cose stupide che gli utenti potrebbero provare. Gli sviluppatori scrivono anche i loro test in base alla propria interpretazione del requisito, che troppo spesso non è ciò che realmente intendeva. Quindi i test passano ma il requisito non è stato soddisfatto. Quando si hanno test di persone diverse, quella persona può avere un'idea diversa dei requisiti e spesso si trovano i luoghi in cui il risveglio è stato scarsamente espresso da come diversamente due persone diverse lo interpretano. Molto meglio scoprirlo nei test rispetto a quando vai in diretta.

Lo sviluppatore dovrebbe fare i test iniziali in modo da sapere che il pezzo che abbiamo codificato funzionerebbe nel modo in cui dovrebbe funzionare, secondo i requisiti che abbiamo. Quindi abbiamo fatto i test normali e abbiamo scritto Test unit per il codice che abbiamo scritto.

Il prossimo passo è il lavoro dei QA per scoprire cosa non vedono gli sviluppatori quando scriviamo il codice. Uno sviluppatore pensa a un livello superiore ma l'utente potrebbe non pensare allo stesso livello. Quando lo sviluppatore sta testando il suo pezzo e deve inserire del testo in una casella di testo, potrebbe sempre inserire una stringa completa pensando che anche l'utente lo farebbe. Potrebbe essere anche l'utente a farlo, ma a caso quando inserisce un carattere speciale come% & $ ^ nel testo e questo interrompe l'applicazione non ha un bell'aspetto per l'utente finale. Uno sviluppatore non può e non penserà a tutte le possibilità che potrebbero accadere perché non è addestrato a pensare in quel modo. Quando si tratta di un QA (tester) pensano sempre a ciò che l'utente potrebbe fare per rompere questa applicazione e provare ogni cosa stupida nel libro, non gli utenti sono stupidi ma non dovremmo lasciare nulla al caso.

Ora dobbiamo anche capire che generalmente più di un pezzo è stato fatto contemporaneamente ed entrambi andranno in produzione. Lo sviluppatore ha potuto testare solo il suo pezzo e pensare che funzioni bene, ma il test di regressione generale deve essere fatto per tutti i pezzi che vengono spinti e per scoprire che la combinazione di due pezzi diversi potrebbe interrompere l'applicazione e lo fa neanche un bell'aspetto. Dobbiamo anche considerare gli scenari di test del carico e altre cose che i tester conoscono meglio.

Infine, dobbiamo passare attraverso l'UAT (User Acceptance Test) per vedere se il pezzo che abbiamo fatto è quello che ci si aspetta. Generalmente sebbene i requisiti superino le BA, la persona finale potrebbe non sapere esattamente come appare e potrebbe pensare che non sia quello che si aspettavano o potrebbe voler aggiungere qualcos'altro per renderlo migliore o per qualche motivo potrebbe eliminare pezzo intero come pensano che il pezzo non andrebbe con la funzionalità già disponibile.

Come spiegato sopra, questi sono molto importanti e non possono essere eseguiti solo dallo sviluppatore e sono assolutamente necessari per il corretto funzionamento dell'applicazione. Il management può dire che questo è un approccio conservativo ma è l'approccio migliore. Possiamo apportare alcune modifiche a quanto sopra detto, ma non possiamo evitare nel complesso.

I commenti sopra sollevano grandi punti.

Un altro non menzionato in precedenza è che avere un codice di prova individuale separato agisce come un controllo aggiuntivo sui requisiti e se il sistema li implementa correttamente.

I requisiti e la documentazione non sono perfetti e spesso l'implementazione è il risultato dell'interpretazione dei requisiti da parte di uno sviluppatore.

Quando il test viene eseguito da un individuo separato, forniscono anche la propria interpretazione dei requisiti durante la creazione del piano di test e l'esecuzione dei test.

Quando le attività di test vengono eseguite indipendentemente dalle attività di sviluppo e i risultati di entrambi "concordano", si ottiene un'ulteriore conferma che il sistema è corretto e corrisponde realmente all'intenzione originale dei requisiti.

Un programmatore, durante il test, vedrà una casella di testo etichettata "Quantità" e immetterà "1". Un programmatore di grande esperienza eseguirà quindi un test di follow-up con il valore "2".

Un utente vedrà una casella di testo con l'etichetta "Quantità" e inserirà "~~ ROX unicorni !!! ~~". Un utente esperto proverà anche "-12 1/2".

Si spera che un tester sia lì da qualche parte per avvisare il programmatore di ciò che l'utente sperimenterà quando fanno queste cose.

Uno dei motivi è che gli sviluppatori sono troppo vicini al proprio codice. Sanno che sono stranezze, sono piccoli comportamenti strani. Essi tendono a testare intorno alle piccole idiosincrasie che conoscono così bene. Non sono abbastanza obiettivi al riguardo. I team di test lo trattano come una scatola nera. Scrivono matrici di dozzine o centinaia di casi di test e li esaminano metodicamente per vedere cosa farà il codice. Spesso escogitano scenari che il team di sviluppo non avrebbe mai immaginato.

Un altro motivo è il tempo. Per progetti di grandi dimensioni che vengono costruiti in più fasi, il team di sviluppo costruirà la Fase 1. Quindi i tester lo testeranno mentre la Fase 2 viene costruita e i difetti della Fase 1 vengono corretti. Questo vale per tutte le fasi, quindi la fase in fase di test è la precedente che è stata costruita.

Voglio raccogliere alcuni argomenti sul perché consentire a uno sviluppatore di testare il proprio lavoro come ultimo passo prima che il test entri in produzione è una cattiva idea, perché sfortunatamente il mio posto di lavoro a volte lo fa (l'ultima volta che è arrivato , l'argomento si riduce a molte persone che sono troppo impegnate con altre cose e non hanno il tempo di far conoscere un'altra persona a quella parte del programma - è un software molto specializzato).

I test non sono facoltativi per uno sviluppatore. Uno sviluppatore deve testare il codice che ha scritto. In quale altro modo si può essere certi che l'attività è stata eseguita con successo? Devi scrivere una specie di test automatici (unittest) o eseguire il lavoro di controllo "è la macchina che fa quello che voglio che faccia" manuall (usando la GUI, chiamando il comando dalla riga di comando o altro).

Tutto ciò che viene testato successivamente è "solo" un test aggiuntivo da parte di altre persone (colleghi, QA, ...). Non esiste alternativa ai test diretti da parte di uno sviluppatore. Chiunque mi dica che uno sviluppatore non deve testare (o addirittura non è autorizzato a farlo) il codice / funzionalità che ha scritto ha semplicemente una comprensione zero di come il software viene sviluppato.

Viene testato da qualcuno che non ha familiarità con il codice, che ti piaccia o no. La domanda è se vuoi che qualcuno sia il tuo cliente.

Ottima domanda Nella tua situazione, esistono casi di test - a volte - e il software sembra essere abbastanza complesso da rendere pratico un novizio alla velocità del prodotto. Dici anche che il test eseguito è il test finale prima della produzione

Ragioni per cui lo sviluppatore potrebbe fare il test finale

• C'è abbastanza copertura del test ... Esistono test unitari, esiste un ambiente di test di integrazione e viene utilizzato, test dell'interfaccia utente, test esplorativi, ecc., Ecc. Quindi un test finale è meno un rigoroso criterio di accettazione di un finale " correre attraverso "
• Esiste una serie di casi di test scritti da un SQA / tester professionale che qualcuno (uno sviluppatore) può / deve seguire esplicitamente
• Il rischio di guasto della funzione / prodotto / modulo è stato altrimenti mitigato a livelli bassi (lasciare che il professionista collauda le aree ad alto rischio e un "principiante" test il rischio più basso)
• La realtà della situazione aziendale è che il rilascio di un prodotto con potenziali difetti è meglio che ritardare il rilascio
• Lo sviluppatore in questione è in realtà anche un tester molto qualificato ed è in grado di apportare mentalmente il cambio di ruoli
• La modifica è una correzione di bug apportata sul campo dallo sviluppatore quando il sito del cliente viene chiuso o altrimenti perde entrate a causa del sistema offline (una patch che verrà riportata in ufficio e testata / rilasciata al più presto in una versione controllata )

Ragioni per cui uno sviluppatore non dovrebbe eseguire i test

• Qualunque altra cosa

In generale, sembra che tu sia sulla buona strada per attaccare la soluzione reale: chiedi all'esperto SQA di generare i casi di test ...

Nota: sono generalmente favorevole a lasciare che gli sviluppatori facciano i test, ma mi assicuro che esista il primo punto elenco ...

Gli esseri umani, essendo umani, tendono a soffrire di pregiudizi cognitivi - dove il loro giudizio in due scenari quasi identici differirà, semplicemente a causa di alcune cose che sono cambiate - una cosa che ho notato in 8 anni di sviluppo, è che quando uno sviluppatore si trova di fronte al test del proprio codice, al contrario del codice scritto da un collega, i test eseguiti sul proprio codice sono di qualità molto peggiore.

Questo non vuol dire che lo sviluppatore sia direttamente in errore: il suo cervello utilizzerà il pregiudizio che lo hanno scritto, per rafforzare il fatto che credono che sia giusto e eseguirà solo controlli di base, al contrario di uno sviluppatore che sta guardando il codice di qualcun altro, effettuerà controlli molto più approfonditi.

Ci sono migliaia di esempi là fuori in cui è stata messa in atto una procedura per prevenire la distorsione cognitiva, o comunemente nota come "The Human Factor", come i sistemi computerizzati nel controllo del traffico aereo, per impedire a due diversi aeromobili di occupare lo stesso spazio aereo nello stesso tempo, alle procedure mediche messe in atto così più di un medico deve dare una diagnosi.

È giunto il momento che il settore IT passi a un atteggiamento più professionale e metta in atto procedure per impedire il collaudo del proprio codice.

• Tutti dovrebbero testare: codice test Develpers, funzionalità test QA'ers, messaggistica test marketing. In questo modo tutti condividono le stesse filosofie e lo stesso linguaggio attorno ai test che è metà della battaglia.

• Il test è una manutenzione ordinaria e di solito utilizzo delle analogie per confrontare . Ad esempio l'analogia del cambio dell'olio per auto. Non devi mai 'cambiare' il tuo olio. Ma lo fai regolarmente comunque. Lo stesso per lavarsi i denti. C'è una ragione per cui li mantieni quotidianamente: non si romperanno "oggi", è tutto su domani e giorni futuri e fare un investimento.

• Tutti dovrebbero condividere la responsabilità di testare. Un team addetto al controllo qualità è importante, tuttavia fare dei "test" come qualcosa che solo il team addetto al controllo qualità fa diventare un'attività "separata" che non ha integrato nello sviluppo del prodotto e nel flusso di lavoro, il che non è una buona cosa.

• Quando qualcosa si rompe in produzione, fai due cose:

  1. Dì "hmm, abbiamo un test per questo " come primo commento.
  2. Effettuare qualsiasi correzione include test per il problema , prima di riprodurre, che correzione.

Nella mia azienda realizziamo alcune applicazioni finanziarie piuttosto complesse. La nostra politica generale è che lo sviluppatore dovrebbe garantire che non si verifichino errori tecnici. Fondamentalmente, prova tutto il possibile per romperlo, date le risorse dell'utente. Quando non è possibile trovare un errore di runtime, inviarlo ai BA per il test. Abbiamo avuto alcuni sviluppatori che si sono persi nel testare i requisiti aziendali fino al punto di esaurirsi, ma solo perché tutti quei test non erano di loro responsabilità. A meno che non ci sia un errore evidente che è chiaramente visibile, lo inviamo alle persone che vengono pagate per capire l'output. Inoltre, gli utenti dovrebbero avere un ruolo reale nella verifica dei risultati. L'addetto alle vendite in un negozio al dettaglio non prova i vestiti per te, ti aiutano solo con i "dettagli tecnici" come trovare vestiti della giusta taglia.

Un problema è che gli sviluppatori hanno pochi incentivi a infrangere il proprio codice: poche persone sono disposte a cercare difetti nei propri lavori o sono disposte a commettere errori. Avere un team separato aiuta a garantire che le cose vengano rotte.

Un ruolo di controllo della qualità è essenziale, tra le altre ragioni, affinché qualcuno possa verificare che lo sviluppatore abbia compreso i requisiti. Lo sviluppatore non può fare questo controllo da solo perché se pensavano di aver frainteso ciò richiederebbe un chiarimento.