I programmatori sono dei cattivi tester?

La domanda sembra chiedere esplicitamente Test di sistema , ecco perché mi riferisco a questa risposta.

Penso che ci sia un'importante distinzione tra l'essere una persona cattiva da scegliere di eseguire test, e in realtà essere cattivi durante i test.

Perché i programmatori non sono bravi a testare:

• Se hai scritto il codice, dovresti (già) aver pensato a quanti più modi possibili che le cose potessero andare storte e averle risolte.
• Se trovare un bug particolarmente disonesto significa che devi quindi andare a risolverlo, in una base di codice di cui potresti essere stufo, allora questo non aiuterà la tua motivazione.

Perché i programmatori sono bravi a testare:

• I programmatori tendono ad essere pensatori logici e sono bravi a lavorare in modo sistematico.
• I programmatori esperti saranno molto bravi a identificare rapidamente i casi limite e quindi a fornire test utili. (Se esiste un processo di test formalizzato, la maggior parte di questi casi dovrebbe già essere stata identificata e testata prima dei test di sistema.)
• I programmatori sono abbastanza bravi a garantire 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 maggior parte dei casi).
• La mentalità è fondamentalmente diversa: "Costruisci un prodotto (funzionante)" vs "Questa cosa non sta andando alla porta con nessun bug (sconosciuto) in esso."
• I tester saranno in genere più efficienti, ovvero eseguiranno più test nello stesso intervallo di tempo.
• I programmatori sono specializzati nella programmazione. I professionisti del QA 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 secondo i requisiti e testarlo come tale. Al mio posto testiamo il nostro codice, quindi testiamo il codice degli altri prima di rilasciarlo nel ciclo di test effettivo e molti più bug sono stati catturati in questo modo rispetto al solo test del nostro codice

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

I programmatori di un solo posto tendono a essere pessimi in fase di testing è l'intero bit "usa l'utente come un utente normale" - non sono utenti normali e non si comportano come loro. Ad esempio:

• I programmatori tendono ad essere molto bravi a ottenere voci di testo giuste. Un problema abbastanza comune che vedo sta conducendo o soprattutto spazi finali. La maggior parte della gente non li sembra, ma i bravi programmatori sono probabilmente religiosi nel rendere le loro stringhe nella giusta stringa senza spazi estranei.
• I programmatori tendono a essere tastieristi, sfruttando schede e altre scorciatoie per accelerare il lavoro. Gli utenti normali tendono ad afferrare il mouse tra i campi.
• I programmatori tendono a capire che 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 (test unitari, test di integrazione, test di regressione) i programmatori sono probabilmente le uniche persone qualificate a essere tester, perché questi tipi di test sono automatizzabili e quindi dovrebbero essere automatizzati, il che richiede programmazione.

Ma non penso che sia di questo che stai parlando, e sono abbastanza sicuro che non sia ciò che Joel Spolsky intende dire: è la parte che rimane, i veri test manuali pratici: trasformare un documento dei requisiti e specifiche funzionali in uno script di test e quindi eseguendo meticolosamente questo script sul prodotto finito.

Essere un buon tester richiede qualità che sono per lo più ortogonali a quelle che fanno 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 tu possa avere entrambi i set di abilità, e in effetti, alcune persone probabilmente lo fanno. Tuttavia, per essere un buon programmatore è necessaria una certa pigrizia (il desiderio di automatizzare le faccende), mentre un tester davvero buono ha bisogno di persistenza (controlla tutti i tremila campi del modulo per incongruenze) e, di conseguenza, anche quei programmatori che avere ciò che serve per essere un tester tipicamente aborre l'idea.

E poi c'è il pregiudizio selettivo: un programmatore che è già coinvolto in un progetto, anche se solo marginalmente, ha già una conoscenza interna della base di codice, e avrà difficoltà a affrontarlo con una mente vuota, da una fine -la prospettiva dell'utente. Non deve nemmeno essere esplicito, come in "So che questo pulsante funziona, quindi annoterò 'pass'"; può essere molto più sottile, e quegli effetti delicati possono portare a mancanze nei casi critici di bordo.

Dalla mia esperienza, sì, i programmatori sono cattivi tester. Troppo spesso ho visto gli altri e me stesso "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. O vogliamo solo superare questa prova con questa o quella funzione.

Ad ogni modo, i test non sono un'abilità che abbiamo appreso e non lavoriamo come programmatori perché siamo bravi a rompere le funzionalità. Inoltre potremmo non avere idea di come fare una corretta pianificazione dei test o tutte le altre cose che il QA fa. Non siamo più qualificati per fare il lavoro di un tester che un tester è 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.

Ci sono diversi livelli di test. Il test di "basso livello" può e deve essere fatto dagli sviluppatori. Penso a unit testig.

D'altra parte, i test di "alto livello" sono totalmente un'altra cosa. In generale, ritengo che gli sviluppatori siano dei cattivi tester non perché manchino delle competenze, ma perché è molto difficile cambiare modo di pensare e modo di lavorare in poco tempo.

Io provo a testare il più possibile i miei codici, ma dopo almeno 10 minuti fatti da un tester, qualcosa da considerare un bug o un miglioramento sorgono. Ciò significa che testare qualcosa che crei è un lavoro duro. Sapete dove cliccare, sapete chi clic, conoscete la logica aziendale, probabilmente sapete come i dati vengono mantenuti. Sei un dio che non cadrai mai.

Che tipo di test intendi? Se intendi test esaustivi completi, allora potrei vedere alcuni razionali per dire 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 può avere una visione del tunnel quando si tratta di cosa il codice deve gestire e ignorare alcuni possibili casi limite che potrebbero non essere stati presi in considerazione. Ad esempio, se costruisco un modulo Web che prende 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 . Ciò che il programma dovrebbe fare in questi casi potrebbe essere discutibile.

Test Driven Development sarebbe un esempio di una metodologia di sviluppo che mette il test in una luce diversa che può dare un'altra vista qui.

I programmatori stanno definendo bene i test quando definiscono i test prima che scrivono il codice. Con la pratica, sono ancora meglio.

Tuttavia, quando si definiscono i test per il codice che hanno scritto, non vanno molto bene. Avranno gli stessi punti ciechi nel test che hanno avuto nello scrivere il codice.

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

Un tipo di test a cui ho assistito in modo particolare ai failover è quello di verificare se il requisito è stato soddisfatto. Quali sviluppatori pensano che qualcosa in un requisito significhi e ciò che i tester pensano che siano spesso due cose completamente diverse.

Riesco a pensare a uno di recente dove è stato chiesto al develoepr di eseguire un'esportazione delta e lo sviluppatore pensava che intendesse ottenere tutti i record che non erano stati inviati una sola volta ei testers pensavano che significasse ottenere nuovi compensi e eventuali modifiche. Dovevano tornare dal cliente per scoprire chi era corretto. Il codice l'ho rivisto e ho fatto la stessa supposizione che lo sviluppatore avesse fatto riguardo al requisito. Perché logicamente se si desidera includere gli aggiornamenti, li avresti menzionati. E di solito sono bravo a individuare quelle cose ambigue perché ero solito usare la parte dell'utente.

Quindi altri sviluppatori che eseguono il test tenderebbero a fare molti degli stessi presupposti perché anche loro farebbero alcune ipotesi come "bene avrebbero avuto più dettagli se volevano dire X vice Y perché ci sono così tanti dettagli da avere una risposta prima Potrei farlo, ma gli scrittori di requisiti non la pensano così, quindi qualcuno che pensa più come i produttori di requisiti deve testare le ipotesi dello sviluppatore e qualcuno che non è uno sviluppatore è la persona migliore per vedere anche che c'è un problema.