I programmatori eseguono test

1. Avere il programmatore in prova le sue caratteristiche può essere un miscuglio. Da una parte il programmatore può essere "troppo familiare" con il blocco di codice e semplicemente il test conosce bene i parametri di tipo pass / fail. D'altra parte, se quel programmatore che è "troppo familiare" con il loro codice è diligente nel far funzionare la funzione, avrà più conoscenze sui casi marginali che potrebbero causare problemi, poiché conoscono il funzionamento interno della funzione e potenziali scappatoie al suo interno.

2. Penso che ciò avvenga il più delle volte. Penso che la maggior parte dei negozi di programmazione là fuori siano in piccoli gruppi, o sotto molta pressione per fare le cose. Questo non gli offre il lusso di un QA / tester dedicato nel loro gruppo, quindi tutti devono prendere la loro parte. Ci sono ancora una discreta quantità di negozi "solitari" là fuori, dove ogni sviluppatore è essenzialmente responsabile per l'intero ciclo di vita della propria app. Questo è il mio caso.

3. Tornerò al n. 1 per questo. Penso che un programmatore sia in grado di testare il proprio lavoro, al di fuori del modello TDD, poiché hanno una conoscenza approfondita di come funziona la loro funzione. Devono fare attenzione a "fare un passo indietro" e essere in grado di coprire problemi specifici e ampi con il codice (come "fat fingering", un campo di immissione del testo - cosa succede?), Ma può essere fatto.

Gli sviluppatori che testano il codice degli altri non dovrebbero essere invece dei test da parte di uno specialista di QA focalizzato, ma sarebbe in più da testare con un tester focalizzato. Gli sviluppatori sono esperti nel pensare a come far funzionare il prodotto. I tester sono le uniche persone del team (BA, PM, sviluppatori, ecc.) Che sono focalizzati a capire come il prodotto potrebbe fallire. È una mentalità molto diversa. Pensa al tuo "tempo di inattività", ad es. Quando stai tracciando progetti nella tua testa mentre fai la doccia. Pensi, "Oh, scommetto che questo sarebbe un buon modo per affrontare questa caratteristica!" o pensi, "Ehi, dovrei vedere se riesco a far fallire quel codice se faccio QUESTO!"? Il lavoro non avviene solo in ufficio, e gli sviluppatori probabilmente non lavoreranno per rompere il codice nel loro "tempo libero". I tester dovrebbero anche accumulare un'ampia varietà di conoscenze sugli strumenti e le tecniche di test e sperimentare la scelta tra loro che gli sviluppatori non hanno e pensare intuitivamente in termini di copertura.

Allo stesso tempo, l'esperienza interdisciplinare è una cosa molto buona, e c'è sempre un vantaggio nel lavorare con il codice di altri sviluppatori. Avere uno sforzo maggiore nei test prima che un QA specifico / una persona che esegue test osservi il codice probabilmente produrrà un codice di qualità migliore, che probabilmente si tradurrà in una più rapida revisione del test, una migliore copertura del test e potrebbe anche ridurre (ma non eliminare) il numero di tester dedicati che sono necessari.

Se davvero devi fare dei compromessi a causa della bassa disponibilità di titoli o se il pool di abilità per il controllo qualità è eccezionalmente negativo, sei certo che questa configurazione sarebbe meglio di niente, ma l'obiettivo dovrebbe essere comunque quello di ottenere un vero tester prima che la squadra cresca troppo.

Non ho mai visto un cattivo metodo di test.

I programmatori dovrebbero testare il proprio codice? Sì, ovviamente.

Le altre persone dovrebbero testare il loro codice? Sì, ovviamente.

Il test di copertura è una buona idea? Sì.

Il test Monte-Carlo è buono? Sì.

Possiamo avere quello che consideriamo un setup abbastanza buono per i test, e poi una nuova persona fa qualche test. Indovina un po? Trovano problemi che non sono stati trovati prima.

Un segno che la qualità sta diventando buona è quando la percentuale di problemi riscontrati nei test che non sono realmente corretti si avvicina al 100%.

Esiste un movimento di sviluppo ampio e in crescita chiamato Test Driven Development o TDD. Non pretendo di essere un esperto e in realtà ho faticato a capire come fare questo metodo di default, ma il succo è che lo sviluppatore prima scrive un test fallito quindi scrive il codice per passare quel test.

Il concetto ha molti punti di forza. Uno è che hai una grande serie di test. Un altro è che poiché questo viene fatto in molti piccoli incrementi, lo sai subito se rompi qualcosa. Una delle cose che ho visto con questo metodo e altri "mandati" di testare tutto è che non si ottengono gli sviluppatori che girano mettendo funzionalità extra perché sono interessanti o pulite. C'è sempre un costo per una funzionalità e molte volte uno sviluppatore non vede o sente quel costo. Con TDD lo fanno, dal momento che scrivi un test case prima di scrivere codice.

Ci sono estensioni su questa teoria e anche la scrittura del test alla fonte dei requisiti in cui l'esperto di business scrive una serie di test funzionali che costituiscono la specifica e quindi gli sviluppatori sviluppano quella serie di casi di test.

Quindi con TDD lo sviluppatore scrive molti test, alcuni discutono per un rapporto di 1: 1 per linee di codice di test per linee di codice.

Penso che sia responsabilità di un programmatore fare una discreta quantità di due diligence prima di controllare un pezzo di codice e firmarlo, questo significa:

• Scrittura di test unitari approfonditi.
• Testare quel codice in uno scenario di utilizzo reale e provare a suddividerlo - ad esempio interagire con esso come verrebbe utilizzato nella produzione.

...

• Quindi un altro programmatore dovrebbe rivedere quel codice e i test delle unità.

• Quindi un tester dedicato / persona QA dovrebbe testare quel codice.

Non penso che ci sia una scusa per non fare il primo 3. E non penso che ci sia una scusa per non fare l'ultimo passo, ma avendo un test dedicato per il tester ogni bit di codice è costoso e le aziende più piccole (almeno pensano) che questo è un lusso che non possono permettersi.

Personalmente, non credo che test specifici debbano essere mai esclusi dall'equazione. Penso che sia necessario trovare persone che almeno non sviluppino lo stesso prodotto (o magari un modulo di grandi dimensioni), che consentirebbe ad altri programmatori di testare, a patto che non abbiano realmente idea di quale sia l'implementazione. Penso che la cosa più importante sia che lo facciano o meno, gli sviluppatori dovrebbero essere in grado di funzionare come tester, ei tester dovrebbero essere in grado di funzionare come sviluppatori. Avere sia basi di conoscenza che familiarità rende lo sviluppo, i test e la comunicazione tra i due molto più facili.

1. Sì, anche se non "funzionano come test del software". Scrivere test fa parte del lavoro di un programmatore. Inoltre, scrivere buoni test è un'abilità. Non essere in grado di testare correttamente le tue caratteristiche non è un difetto nei test, è un indicatore di mancanza di abilità *.

2. Lo spero di sicuro.

3. Mentre un programmatore può testare completamente il proprio lavoro, potrebbe esserci un valore in un processo QA esterno. Raramente, però, ho trovato che fosse il caso.

L'obiettivo del test è triplice:

1. Per guidare lo sviluppo
2. Per gestire la modifica
3. Fornire riservatezza

I test degli sviluppatori possono e dovrebbero servire a tutti questi scopi. Se il test degli sviluppatori è sufficiente per loro, non c'è bisogno di ulteriori test.

* La programmazione accoppiata rende ancora più difficile scrivere test così dannosi perché non testerai mai le tue funzionalità.

Girando intorno a questo - penso che ci sia un grande valore nel reclutare almeno un po 'di persone per il team che sono più bravi a testare di quanto non lo siano nella codifica. È un insieme di competenze che è diverso dallo sviluppo e penso - anche con TDD e altre pratiche agili - che qualcuno con un buon occhio per i test sia inestimabile per la qualità del prodotto.

Quindi, è facile chiedersi: i tester dovrebbero essere codificanti tanto quanto i programmatori stanno testando.

IMO - sì, dovrebbe esserci almeno un po 'di mix. Avere una prospettiva dall'altra parte della produzione di un prodotto ti tiene ben arrotondato e può generare nuove intuizioni.