Perché lasciare / non lasciare che gli sviluppatori testino il proprio lavoro

Come altri (e voi stessi) hanno notato, gli sviluppatori dovrebbero testare il proprio codice unitario. Tuttavia, dopo questo, qualsiasi prodotto non banale dovrebbe essere testato anche da persone indipendenti (dipartimento QA e / o il cliente stesso).

Normalmente gli sviluppatori lavorano con la mentalità sviluppatore di "come fare questo lavoro?" . Un buon tester sta pensando a "come rompere questo?" - una mentalità molto diversa. I test unitari e TDD insegnano agli sviluppatori a cambiare i cappelli in una certa misura, ma non si deve fare affidamento su di essi. Inoltre, come altri hanno notato, c'è sempre la possibilità di requisiti di incomprensione. Pertanto i test finali di accettazione devono essere condotti da qualcuno il più vicino possibile al cliente .

Lo sviluppatore sa come funziona il loro codice e cadrà l'abitudine di testare il codice in base a questa conoscenza.

Lo sviluppatore troverà difficile rimuovere se stesso dalla mentalità di "come funziona" invece di "come dovrebbe funzionare".

Per questo motivo è meglio avere qualcuno con un alto grado di obiettività per testare il programma i.e QA o Test Engineers

Test dei tester per interrompere, Semplice. Questo tipo di pregiudizio è necessario per scoprire davvero i fermi di scena.

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

Suppongo che tu non abbia un team dedicato a fare i test in base alla tua dichiarazione. Tuttavia, avere un team dedicato ai test aiuterà davvero gli sviluppatori a testare il loro codice nel modo in cui lo hanno codificato. Ciò non significa che una volta che hai un team di controllo qualità di qualche tipo, puoi già effettuare test come responsabilità degli sviluppatori.

Developers usually use nets with huge holes for catching bugs. As a result, smaller bugs escape.

Perché gli sviluppatori non sono bravi a cercare di infrangere il loro codice. La loro mente segue semplicemente il percorso corretto di inserimento dei dati e 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 professionisti.

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

Inoltre, come dici tu, uno sviluppatore sa cosa ha scritto, ma un gruppo di test sa cosa avrebbe dovuto essere scritto. A volte, questi due concetti non coincidono. 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 di controllo qualità sa tutto.

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

Avendo lavorato con un team di QA e senza, posso dirti che apprezzo al 100% il lavoro che fanno e diranno che sono una parte preziosa del team del software. Quando hai un team di QA, è molto più facile rilasciare il tuo codice, b / c sai che è stato testato a fondo e ciò significa che avrai meno chiamate 3am.

Gli sviluppatori dovrebbero testare il proprio codice.

I tester indipendenti non solo testano per rompere, ma testano le assunzioni non dichiarate e non definite che gli sviluppatori hanno fatto durante la codifica.

Gli sviluppatori dovrebbero testare il proprio lavoro. Lasciare che gli sviluppatori spingano il lavoro non testato a un team di QA, oppure i loro colleghi sviluppatori sono davvero cattivi. Spreca il tempo di sviluppatori e tester, e rovina le relazioni.

Tuttavia, ciò non è sempre sufficiente. È probabile che gli sviluppatori seguano un percorso felice attraverso il sistema, o siano ciechi di 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 specifiche e implementazione. Questo può portare a un effetto di Whispers cinesi sul dispiegamento finale. È meglio che chiunque abbia definito il requisito o la segnalazione di bug verifichi che funzioni nel modo desiderato.

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

Perché non dovresti fare test-cases?

1. Sei soggettivo , poiché i bug trovati sono scritti da te (o dai tuoi colleghi).
2. Anche tu costoso per l'azienda per eseguire test di casi. (Lo spero).

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

I piani del tuo progetto non soddisfano i test degli utenti? Se gli utenti riescono a testarlo, si possono intercettare bug prima della post-implementazione che nel mio mondo non è una cosa negativa.

Gli sviluppatori non dovrebbero testare il proprio codice perché è simile a giudicare l'arte di tuo figlio. Ti sembrerà bella in ogni caso, e hai davvero bisogno di un professionista per sottolineare i difetti. I test unitari d'altra parte sono simili a garantire che il tuo bambino non stia cercando di dipingere con il piombo.

Nel caso in cui voi VERAMENTE non volete assumere il QA, convincete gli sviluppatori a scrivere codice di prova per altri sviluppatori. Questo è un buon primo passo: presto vedrai sviluppatori che richiedono risorse di QA perché la maggior parte del tempo viene speso a testare il codice di altri per problemi, oltre a CR.

Non solo gli sviluppatori proteggono il loro codice, se non si rendono conto di un caso particolare o interpretano erroneamente una specifica nel modo in cui sviluppano qualcosa, quindi mancheranno quei casi quando testano il loro codice.

Anche le tecniche e le abilità per i test sono molto diverse.

La maggior parte dei test effettuati da un team di test è funzionale (che un prodotto funziona secondo le specifiche) e la scatola nera (il team di test non vedrà il funzionamento interno di un'applicazione). I tester funzionali non devono preoccuparsi di come funzionano le cose, hanno solo bisogno di concentrarsi sul loro operato.

Nella mia esperienza, almeno nella mia piccola organizzazione, l'utente finale deve testare. Quasi tutti i progetti che riceviamo non forniscono tutte le informazioni necessarie e lasciano sempre alcuni dettagli. Lo sviluppatore è sempre a svantaggio di test perché non sa come fare 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 fai il loro lavoro.

Gli sviluppatori interpretano erroneamente e interpretano erroneamente i requisiti e i responsabili dei requisiti spesso non riescono a specificare le cose fondamentali. Se nessuno tranne i test degli sviluppatori, 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 inoltre scrivono i loro test basandosi sulla propria interpreazione del requisito che troppo spesso non è ciò che era realmente inteso. Quindi i test passano ma il requisito non è stato rispettato. Quando si effettuano test su persone diverse, quella persona può avere un'idea diversa dei requisiti e spesso si trovano i luoghi in cui il reperimento è stato scarsamente espresso da come diverse persone lo interpretano in modo diverso. È molto meglio scoprirlo nei test piuttosto che dopo che tu vada a vivere.

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

Il prossimo passo è il lavoro dei responsabili della qualità per scoprire cosa gli sviluppatori non vedono quando scriviamo il codice. Uno sviluppatore pensa in 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 un utente che utilizza la stringa completa. Può essere che l'utente lo faccia anche tu, ma casualmente quando inserisce un carattere speciale come% & $ ^ nel testo e ciò interrompe l'applicazione non sembra buono all'utente finale. Uno sviluppatore non può e non pensa 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 cosa 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 in genere più di un pezzo viene fatto nello stesso momento e entrambi andranno in produzione. Lo sviluppatore potrebbe testare solo il suo pezzo e pensa che funzioni bene, ma il test di regressione generale deve essere fatto per tutti i pezzi che vengono spinti, oltre a scoprire che la combinazione di due pezzi diversi potrebbe rompere l'applicazione e lo fa non sembra buono neanche Dobbiamo anche considerare gli scenari di test del carico e altre cose di cui i tester sono più a conoscenza.

Infine dobbiamo passare attraverso UAT (User Acceptance Test) per vedere se il pezzo che abbiamo fatto è quello che ci si aspetta. Generalmente, anche se i requisiti arrivano tramite BA, l'utente finale potrebbe non sapere esattamente come sembra e potrebbe pensare che non è quello che si aspettavano o potrebbe voler aggiungere qualcos'altro per farlo sembrare migliore o per qualche ragione che potrebbero scartare pezzo intero come pensano che il pezzo non sarebbe andato con la già disponibile funzionalità.

Come spiegato sopra, questi sono molto importanti e non possono essere eseguiti dallo sviluppatore da soli e sono assolutamente necessari affinché l'applicazione funzioni correttamente. 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 come del tutto.

I commenti sopra sollevano grandi punti.

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

Requisiti e 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 una persona separata, fornisce anche la propria interpretazione dei requisiti durante la creazione del piano di test e l'esecuzione dei test.

Quando le attività di test vengono svolte indipendentemente dalle attività di sviluppo e gli output di entrambi sono "d'accordo", fornisce 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 con l'etichetta "Quantità" e inserirà "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à "~~ unicorns ROX !!! ~~". Un utente esperto proverà anche "-12 1/2".

Speriamo 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 loro codice. Sanno che sono stranezze, è un po 'strani comportamenti. Tendono a testare intorno alle piccole idiosincrasie che conoscono così bene. Non sono abbastanza obiettivi a riguardo. I team di test lo trattano come una scatola nera. Scrivono matrici di dozzine o centinaia di casi di test e le attraversano metodicamente per vedere cosa farà il codice. Spesso escogitano scenari che il team di sviluppo non si sognerebbe mai.

Un altro motivo è il tempo. Per i progetti di grandi dimensioni che sono costruiti in fasi, il team di sviluppo costruirà lo Stage 1. Quindi i tester lo testeranno mentre lo Stage 2 è in fase di sviluppo ei difetti dello Stage 1 sono stati corretti. Questo va avanti per tutte le fasi, quindi la fase in fase di test è la precedente che è stata costruita.

I want to gather some arguments as to why letting a developer testing his/her own work as the last step before the test goes into production is a bad idea, because unfortunately, my place of work sometimes does this (the last time this came up, the argument boiled down to most people being too busy with other things and not having the time to get another person familiar with that part of the program - it's very specialised software).

I test non sono facoltativi per uno sviluppatore. Uno sviluppatore deve testare il codice che ha scritto. In quale altro modo può essere certo, che il compito è stato portato a termine con successo? È necessario scrivere una sorta di test di automazione (unittests) o eseguire il lavoro di controllo "è la macchina che fa quello che voglio che faccia" manuall (usando la GUI, chiamando il comando sulla riga di comando o qualsiasi altra cosa).

Tutto ciò che viene testato dopo questo è "solo" test aggiuntivi da parte di altre persone (colleghi, QA, ...). Non c'è alternativa al test diretto da parte di uno sviluppatore. Tutti quelli che mi dicono che uno sviluppatore non ha bisogno di testare (o addirittura non gli è permesso) il codice / caratteristica che ha scritto semplicemente ha una comprensione zero di come si sta sviluppando il software.

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

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

Ragioni per cui potrebbe essere corretto per lo sviluppatore eseguire il test finale

• C'è abbastanza copertura per i test ... Esistono test delle unità, esiste un ambiente di test di integrazione ed è utilizzato, test dell'interfaccia utente, test esplorativi, ecc. Quindi un test finale è meno rigoroso di un finale "run through"
• Esiste una serie di casi di test scritti da un SQA / Tester professionista che qualcuno (uno sviluppatore) può / deve seguire esplicitamente
• Il rischio di fallimento della funzionalità / prodotto / modulo è stato in qualche modo attenuato a livelli bassi (lasciare che il professionista verifichi le aree ad alto rischio e un test "principiante" il rischio più basso)
• La realtà della situazione aziendale è che rilasciando un prodotto con potenziali difetti è meglio che ritardare il rilascio
• Lo sviluppatore in questione è in realtà un tester molto qualificato ed è in grado di apportare modifiche mentali ai ruoli
• La modifica è una correzione di bug effettuata sul campo dallo sviluppatore quando il sito del cliente viene chiuso o altrimenti perde entrate a causa del fatto che il sistema è offline (una patch che verrà riportata in ufficio e testata / rilasciata in un versione controllata ASAP)

Motivi per cui uno sviluppatore non dovrebbe eseguire il test

• Qualsiasi altra cosa

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

Nota: Generalmente sono a favore del fatto che gli sviluppatori facciano i test, ma sono dannatamente sicuro che il primo punto elenco esista ...

Gli esseri umani, essendo umani, tendono a soffrire di pregiudizi cognitivi - dove il loro giudizio in due scenari quasi identici sarà diverso, 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 a dover testare il proprio codice, al contrario del codice scritto da un collega, il test eseguito sul proprio codice è di pessima qualità.

Questo non vuol dire che lo sviluppatore abbia la colpa direttamente - il suo cervello userà il pregiudizio che lo hanno scritto, per rinforzare il fatto che credono sia giusto, e eseguirà solo controlli di base, al contrario di uno sviluppatore che sta guardando il codice di qualcun altro, eseguirà controlli più approfonditi.

Ci sono migliaia di esempi là fuori dove è stata messa in atto una procedura per prevenire pregiudizi cognitivi, o comunemente noti come "The Human Factor", come sistemi computerizzati nel controllo del traffico aereo, per evitare che due diversi velivoli occupino lo stesso spazio aereo allo stesso tempo, alle procedure mediche messe in atto in modo che più di un medico debba dare una diagnosi.

È giunto il momento che l'industria IT si muova verso un atteggiamento più professionale e mette in atto procedure per impedire il test del proprio codice.

• Eeveryone dovrebbe testare - Develpers test code, QA'ers test function, Marketing test messaging. In questo modo tutti condividono le stesse filosofie e il linguaggio intorno ai test che è metà della battaglia.

• Il test è una manutenzione di routine e di solito uso le analogie per confrontare . Per esempio l'olio per auto cambia analogia. Non devi mai 'cambiare il tuo petrolio. Ma lo fai regolarmente comunque. Lo stesso per lavarsi i denti. C'è un motivo per mantenerli tutti i giorni - non si rompono 'oggi', si tratta di domani e di futuri e di fare un investimento.

• Tutti dovrebbero condividere la responsabilità da testare. Un team di QA è importante, ma rende il "testing" come qualcosa che solo il team di controllo qualità fa diventare un'attività "separata" che non è integrata allo sviluppo del prodotto e al flusso di lavoro che non è una buona cosa.

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

  1. Pronuncia "hmm, abbiamo un test per questo " come primo commento.
  2. Apporta qualsiasi correzione includi test per il problema , prima di riprodurre, poi risolvi.

Nella mia azienda, creiamo applicazioni finanziarie piuttosto complesse. La nostra politica generale è che lo sviluppatore dovrebbe assicurarsi che non si verifichino errori tecnici. Fondamentalmente, prova tutto ciò che puoi per romperlo, date le risorse dell'utente. Quando non riesci a trovare un errore di runtime, invialo 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 i test non erano di loro competenza. 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 di un negozio al dettaglio non prova i vestiti per te, ti aiutano solo con i "dettagli tecnici" come trovare vestiti della giusta misura.

Un problema è che gli sviluppatori hanno poco incentivo a rompere il loro codice: poche persone sono disposte a cercare difetti nei propri lavori o sono disposti a commettere errori. Avere un team separato aiuta a garantire che le cose si spezzino.

Un ruolo di Quality Assurance è essenziale, tra le altre ragioni, in modo che qualcuno possa verificare che lo sviluppatore abbia compreso i requisiti. Lo sviluppatore non può fare questo controllo da solo perché se pensassero di aver frainteso avrebbe chiesto chiarimenti.