I programmatori sono cattivi tester?

So che sembra molto simile ad altre domande che sono già state poste, ma in realtà è leggermente diverso. Sembra essere generalmente considerato che i programmatori non sono bravi a svolgere il ruolo di test di un'applicazione. Per esempio:

Joel on Software - I primi cinque (sbagliati) motivi per cui non hai tester (enfasi il mio)

Non pensare nemmeno di provare a dire ai diplomati del college che possono venire a lavorare per te, ma "tutti devono fare un periodo in QA per un po 'prima di passare al codice". Ho visto molto di questo. I programmatori non sono buoni tester e perderai un buon programmatore, che è molto più difficile da sostituire.

E in questa domanda , una delle risposte più popolari dice (di nuovo, la mia enfasi):

Gli sviluppatori possono essere tester, ma non dovrebbero essere tester. Gli sviluppatori tendono a evitare involontariamente / inconsciamente di utilizzare l'applicazione in un modo che potrebbe romperla. Questo perché l'hanno scritto e per lo più testato nel modo in cui dovrebbe essere usato.

Quindi la domanda è : i programmatori non sono bravi nei test? Quali prove o argomenti ci sono a sostegno di questa conclusione? I programmatori non sono bravi a testare il proprio codice? Esistono prove che suggeriscono che i programmatori sono effettivamente bravi nei test?

Cosa intendo per "test?" Lo faccio non unit testing media o qualsiasi cosa che è considerato parte della metodologia utilizzata dal team di software per il software di scrittura. Intendo un qualche tipo di metodo di garanzia della qualità che viene utilizzato dopo che il codice è stato creato e distribuito a tutto ciò che quel team di software chiamerebbe "ambiente di test".

La domanda sembra porsi specificamente sui test di sistema , quindi è a questo che mi riferisco durante questa risposta.

Penso che ci sia un'importante distinzione tra l'essere una persona cattiva per scegliere di eseguire i test e l'essere effettivamente cattivi nei test.

Perché i programmatori non sono bravi nei test:

• Se hai scritto il codice, avresti (dovuto) già pensato a quanti più modi possibile che le cose potessero andare male e ti sei occupato di loro.
• Se trovare un bug particolarmente negligente significa che devi andare a risolverlo, in una base di codice di cui potresti essere stanco, questo non aiuterà la tua motivazione.

Perché i programmatori sono bravi nei test:

• I programmatori tendono ad essere pensatori logici e bravi a lavorare in modo sistematico.
• I programmatori esperti saranno molto bravi a identificare rapidamente i casi limite e quindi a elaborare test utili. (Se esiste un processo di test formalizzato, la maggior parte di questi casi dovrebbe essere già stata identificata e testata prima del test dei sistemi.)
• I programmatori sono abbastanza bravi a assicurarsi che tutte le informazioni utili vengano inserite in una segnalazione di bug.

Perché i programmatori sono cattivi tester:

• I programmatori sono più costosi dei tester (nella stragrande maggioranza dei casi).
• La mentalità è fondamentalmente diversa: "Costruisci un prodotto (funzionante)" vs "Questa cosa non esce dalla porta con nessun bug (sconosciuto) al suo interno."
• I tester saranno generalmente più efficienti, ovvero eseguiranno più test nello stesso lasso di tempo.
• I programmatori sono specializzati nella programmazione. I professionisti del controllo qualità sono specializzati nei test.

Penso che i programmatori non siano bravi a testare il proprio codice .

Ci piace credere che il nostro codice funzioni perfettamente in base ai requisiti e testarlo come tale. Al posto mio testiamo il nostro codice, quindi testiamo l'altro codice prima di rilasciarlo nel ciclo di test effettivo e molti più bug sono stati rilevati in questo modo che semplicemente testando il nostro codice

I programmatori sono sicuramente le persone giuste per testare alcune parti del sistema: in alcuni casi sono gli unici che potrebbero essere in grado di farlo in modo efficace.

Un posto in cui i programmatori tendono ad essere molto cattivi nei test è l'intero bit "usa l'interfaccia utente come un normale utente" - non sono utenti normali e non si comportano come loro. Per esempio:

• I programmatori tendono ad essere molto bravi a ottenere le voci di testo giuste. Un problema piuttosto comune che vedo è lo spazio iniziale o soprattutto quello finale. La maggior parte della gente non li sembra, ma i bravi programmatori sono probabilmente religiosi nel rendere le loro corde la stringa giusta senza spazi estranei.
• I programmatori tendono ad essere tastieristi, sfruttando le schede e altre scorciatoie per accelerare il lavoro. Gli utenti normali tendono ad afferrare il mouse tra i campi.
• I programmatori tendono a capire cosa dice il sistema piuttosto che ignorare i messaggi di errore e semplicemente fare clic su OK.

Quindi, gli utenti normali fanno molte cose che i programmatori non fanno. Non puoi fare affidamento completamente sul team di sviluppo per UAT.

A livello tecnico (unit test, test di integrazione, test di regressione) i programmatori sono probabilmente le uniche persone qualificate per essere tester, perché questi tipi di test sono automatizzabili e dovrebbero quindi essere automatizzati, il che è qualcosa che richiede programmazione.

Ma non credo sia quello di cui stai parlando, e sono abbastanza sicuro che non sia nemmeno quello che intende Joel Spolsky - è la parte che rimane, il vero test manuale pratico: trasformare un documento dei requisiti e le specifiche funzionali in uno script di prova e quindi meticolosamente eseguendo questo script sul prodotto finito.

Essere un buon tester richiede qualità per lo più ortogonali a quelle che lo rendono un buon programmatore. C'è un po 'di sovrapposizione - devi essere in grado di pensare analiticamente, hai bisogno di una certa affinità con i computer in generale - ma a parte questo, le abilità di un tester sono molto diverse. Questo di per sé non significa che puoi avere entrambi i set di abilità, e in effetti, probabilmente alcune persone lo fanno. Tuttavia, per essere un programmatore davvero bravo richiede una certa pigrizia (il desiderio di automatizzare le faccende domestiche), mentre un tester veramente bravo ha bisogno di persistenza (controlla se tutti i tremila campi del modulo sono incoerenti) e, di conseguenza, anche quei programmatori che avere quello che serve per essere un tester in genere detesta l'idea.

E poi c'è il pregiudizio selettivo: un programmatore che è già coinvolto in un progetto, anche se solo marginalmente, ha già qualche conoscenza interna della base di codice e avrà difficoltà ad avvicinarlo con una mente vuota, dal punto di vista dell'utente finale . Non deve nemmeno essere esplicito, come in "So che questo pulsante funziona, quindi noterò solo 'pass'"; può essere molto più sottile, e questi effetti sottili possono portare a perdere casi critici durante i test.

Dalla mia esperienza, sì, i programmatori sono cattivi tester. Troppo spesso ho visto gli altri e me stesso andare "Huh, ma l'ho provato prima di fare il check-in!" di fronte a un tester che riproduce il bug di fronte a te.

Perché? Beh, non sono sicuro del perché, ma forse è perché vogliamo vedere le cose che funzionano. Oppure vogliamo solo superare il test di questa o quella funzionalità già.

Ad ogni modo, test non è un'abilità che abbiamo imparato e non lavoriamo come programmatore perché siamo bravi a rompere le funzionalità. Inoltre, potremmo non avere idea di come effettuare una corretta pianificazione dei test o tutte le altre cose che fa il QA. Non siamo più qualificati per fare il lavoro di un tester di quanto non sia qualificato per implementare la tua nuova pipeline di rendering 3d.

Come nella domanda, test non significa nulla di automatizzato ma in realtà test utilizzando il programma.

Esistono diversi livelli di test. I test "di basso livello" possono e devono essere eseguiti dagli sviluppatori. Penso a unit testig.

D'altra parte, i test "di alto livello" sono totalmente un'altra cosa. In generale, penso che gli sviluppatori non siano dei buoni tester non perché mancano di abilità, ma perché è molto difficile cambiare modo di pensare e lavorare in poco tempo.

Uso per provare a testare i miei codici il più possibile, ma dopo almeno 10 minuti fatti da un tester, emerge qualcosa da considerare un bug o un miglioramento. Ciò significa che testare qualcosa che crei è un duro lavoro. Sai dove fare clic, sai quando fai clic, conosci la logica aziendale, probabilmente sai come vengono conservati i dati. Sei un dio che non cadrai mai.

Che tipo di test intendi? Se intendi test esaustivi completi, allora potrei vedere alcuni razionali per dire di sì, anche se sospetto che la maggior parte delle persone sarebbe povera in questa categoria se si considerano tutte le possibili combinazioni di input come un requisito per tali test.

Posso riconoscere che lo sviluppatore che progetta il software potrebbe avere una visione a tunnel quando si tratta di gestire il codice e ignorare alcuni possibili casi limite che potrebbero non essere stati considerati. Ad esempio, se creo un modulo Web che accetta un numero, n, e quindi stampa da 1 a n sullo schermo, potrei perdere alcuni casi speciali come se non viene inserito nulla o qualcosa che non è un numero naturale come e o pi . Che cosa dovrebbe fare il programma in questi casi può essere discutibile.

Test Driven Development sarebbe un esempio di una metodologia di sviluppo che mette i test sotto una luce diversa che potrebbe dare un'altra visione qui.

I programmatori stanno benissimo definendo i test quando definiscono i test prima di scrivere il codice. Con la pratica, stanno ancora meglio.

Tuttavia, quando definiscono i test per il codice che hanno scritto, non fanno molto bene. Avranno gli stessi punti ciechi nei test che avevano nello scrivere il codice.

L'uso dei programmatori per eseguire i test manuali è semplicemente stupido. Il test manuale è abbastanza stupido da solo; costringere i programmatori a farlo è estremamente sciocco. È costoso e allontana i programmatori competenti.

Un tipo di test che ho visto in particolare fallire i devlopers è test se il requisito è stato soddisfatto. Ciò che i devlopers pensano qualcosa in un requisito significa e ciò che i tester pensano che ciò significhi sono spesso due cose completamente diverse.

Ne posso pensare a uno di recente in cui è stato chiesto a develoepr di fare un'esportazione delta e lo sviluppatore ha pensato che significava ottenere tutti i record che non erano stati inviati una volta e che i tester pensavano che significasse ottenere nuovi reclutamenti e modifiche. Dovevano tornare dal cliente per scoprire chi aveva ragione. Ho rivisto il codice e ho fatto lo stesso presupposto che lo sviluppatore ha fatto in merito al requisito. Perché logicamente se si volessero includere aggiornamenti, li avresti menzionati. E di solito sono bravo a individuare quelle cose ambigue perché ero solito essere sul lato dell'utente.

Quindi altri sviluppatori che fanno i test tenderanno a fare molte delle stesse ipotesi perché anche loro farebbero alcune ipotesi come "beh, avrebbero avuto più dettagli se intendessero X vice Y perché ci sono così tanti dettagli a cui rispondere prima che io possa fare Ma i redattori dei requisiti non la pensano in questo modo, quindi qualcuno che pensa più ai redattori dei requisiti deve testare i presupposti dello sviluppatore e qualcuno che non è uno sviluppatore è la persona migliore per vedere anche se c'è un problema.