Lasciando bug intenzionali nel codice per i tester da trovare

Questo sembra assolutamente noccioso. Sta spendendo un grande sforzo per un beneficio molto discutibile, e la pratica sembra basata su alcune premesse sbagliate:

• Il QA non funzionerà a dovere a meno che non sappiano che vengono sottoposti a test ogni giorno (il che non può essere positivo per il morale)

• Che non ci sono abbastanza bug introdotti non intenzionalmente nel software per il controllo qualità per trovare

• Il compito del QA è trovare i bug, non lo è; è per garantire che il software sia di qualità di produzione

• Che questo tipo di battaglie di intelligenza tra lo sviluppo e la certificazione di qualità sia in qualche modo salutare per l'azienda - non lo è; tutti i dipendenti dovrebbero lavorare insieme contro i concorrenti della società anziché l'uno dell'altro.

È un'idea terribile e il project manager in questione è un cretino / idiota che non capisce nulla di persone e motivazione. Ed è male per gli affari.

Espandere la mia descrizione del "lavoro di QA:" QA dovrebbe sicuramente trovare bug - sia nel codice che nelle suite di test - come un artefatto di svolgere il proprio lavoro, ma il ruolo non dovrebbe essere definito come "tu devo trovare bug. " Dovrebbe essere "necessario tenere aggiornate le suite di test per tenere conto delle nuove funzionalità e garantire tutta l'alta copertura dei test. Se ciò non si risolve nella ricerca di bug, le procedure di test non sono sufficientemente sofisticate per il prodotto.

Bene, in base a ciò che ho imparato:

1. Non è una scuola né un colloquio di lavoro;
2. I tester non sono bambini;
3. Non è un gioco;
4. Spreca i soldi della compagnia.

Il QA non è lì solo per trovare bug ma anche per preoccuparti di come intuitivo il sistema è, qual è la curva di apprendimento per l'utente, usabilità e accessibilità in generale. Ad esempio: "Il sistema è brutto ?", "L'utente è daltonico e tutto è rosso e verde?" Dovrebbero lamentarsi anche.

I requisiti minimi per il passaggio di un sistema QA di solito sono descritti in una user story per quella particolare caratteristica o in quanto magico il PO voleva che il sistema fosse nella sua testa.

tl; dr

Non sono solo i bug, i tester dovrebbero uscire da questa visione ristretta.

Cattiva idea.

Dal punto di vista del tester: "Così testeranno duramente, perché sanno che ci sono dei bug presenti e non trovarli potrebbero essere considerati come la loro incompetenza". Fondamentalmente gli sviluppatori stanno trappolando il codice. Poche persone amano fare un lavoro che alla fine è privo di senso (perché i bug sono noti in anticipo), ma che comunque influenzano il modo in cui vengono percepiti. Se ci sono pene tangibili per non trovare le trappole esplosive, molto più. E sai che i tester prosperano nel trovare bug? Sembra un ambiente conflittuale tossico; un QA dovrebbe essere felice se il codice che stanno esaminando è di alta qualità. Anche se sono pagati dal bug ... link

Dal punto di vista dello sviluppatore: i controlli di qualità sono incentivati a trovare gli errori che conosci. Questo potrebbe anche aumentare la probabilità che dei veri bug vadano fuori dalla porta; i controlli di qualità stanno trascorrendo almeno una parte del loro tempo alla ricerca del tipo di bug che è facile da piantare, non molto sottile. Inoltre c'è una piccola possibilità che una trappola esplosiva possa uscire dalla porta.

Sono totalmente d'accordo con le risposte precedenti sul motivo per cui questo è negativo per la motivazione e la gestione delle persone in generale terribile. Tuttavia, ci sono probabilmente motivi tecnici validi per non fare altrettanto:

Just before the product goes to QA, the dev team adds some intentional bugs at random places in the code. They properly back up the original, working code to make sure that those bugs aren't shipped with the end product.

1. In base alla prima affermazione, mai verifica effettivamente il codice di produzione previsto in questi due passaggi.

2. Immagino che aumenti notevolmente la probabilità di includere accidentalmente un bug "intenzionale" nel codice di produzione rilasciato quando cerchi di passare attraverso un cambiamento per un cliente. Potrebbe causare alcune guance rosse ad un certo punto.

3. Immaginerei che questo alleni solo i tuoi tester a pensare come i tuoi sviluppatori (cioè come aggiungerebbe un bug a Tom qui) che probabilmente li rende meno propensi a trovare gli errori a cui Tom non ha pensato.

Modifica

Voglio essere chiaro che questa risposta sta solo parlando del concetto di test del processo di QA e non sto difendendo la metodologia specifica rappresentata nella domanda.

Termina modifica

C'è un motivo valido per verificare se il test / controllo funziona effettivamente. Permettetemi di darvi un esempio dalla produzione, ma il principio è lo stesso.

È tipico quando si alimenta il materiale attraverso una macchina che l'alimentatore potrebbe non spingere il materiale abbastanza lontano. Questo è chiamato "short feed" e per evitare ciò potremmo installare un "short feed sensor" (tipicamente un sensore di tipo beam-through che è bloccato dal materiale). Questo sensore rileva la fine del materiale quando raggiunge la lunghezza di alimentazione completa. Ad un certo punto del ciclo della macchina controlliamo che il sensore sia bloccato e fermi la macchina se il controllo fallisce.

Ora devi pensare a come il test stesso può fallire. Ad esempio, alcuni detriti o altri detriti possono bloccare il sensore e segnalerà sempre "OK" e non arresterà mai la macchina. Inoltre, la natura del sensore è che il ricevitore si accende quando il raggio lo colpisce, quindi a seconda del tipo di sensore installato, elettricamente si ottiene un ingresso "ON" quando il sensore è non bloccato . Ciò significa che se il cavo si è tagliato o se è stato perso il potere su quel sensore, o se l'ingresso non è riuscito, la logica del programma dovrebbe essere "OFF" e ciò significherebbe "bloccato" o "OK".

Per catturare queste modalità di errore del test, in genere inseriamo un secondo controllo per accertarci che il sensore sia effettivamente sbloccato durante una seconda parte del ciclo. In questo modo controlliamo che il test sia ancora in funzione (nel miglior modo possibile).

Allo stesso modo ci sono molti modi in cui un dipartimento di QA può fallire. Forse i test automatici non sono stati eseguiti e il report sta esaminando una vecchia copia dei dati di test. Forse qualcuno non sta facendo bene il suo lavoro. Testare il dipartimento QA è una cosa ragionevole da fare.

Ovviamente l'inconveniente è che un "bug di test" potrebbe passare attraverso il dipartimento QA e nel prodotto finito. Nell'industria manifatturiera ci sono casi in cui una parte cattiva nota, a volte chiamata "coniglio rosso", viene inserita nel processo (tipicamente da qualcuno del QA) e guarda quella parte che attraversa il processo e misura quanto tempo ci vuole per trova la parte e rimuovila. Normalmente questa parte è dipinta di rosso brillante (o arancione) in modo che possa essere facilmente rintracciata. Dal momento che qualcuno sta guardando la parte durante il processo durante questo test, la possibilità di farlo diventare il prodotto finale è praticamente nulla. Ci sono, ovviamente, storie apocrife di qualcuno che lancia una nota parte cattiva nel processo per "vedere se il sistema riesce a trovarlo", e ovviamente deve mettere in quarantena tutte le parti finali prodotte quel giorno e ordinarle manualmente, ma questo è solo un caso di non eseguire il test con la dovuta diligenza.

Onestamente, definirei questo comportamento apertamente non etico e poco pratico. Il PM ha bisogno di una seria riqualificazione, se non di una conclusione.

• Dimostra una fondamentale mancanza di comprensione del concetto di garanzia della qualità . I tester non dovrebbero pensare come sviluppatori: dovrebbero pensare come utenti finali. L'intera ragione per avere team di QA è che gli sviluppatori sono intrinsecamente troppo vicini al codice; Il QA dovrebbe mantenere una distanza sufficiente dal codice da poter catturare ciò che gli sviluppatori perdono.
• Spreca impegno QA . Supponendo che questi bug non siano banali, vedi sotto per quando sono, significa che il QA sta spendendo tempo e risorse per indagare su cose che sono già conosciute, quando potrebbero spendere quegli sforzi per cercare ciò che non è noto.
• Spreca impegno dello sviluppatore . Per gli addetti al controllo qualità di catturare questi bug non banali, gli sviluppatori devono prima scriverli. Ciò richiede un ulteriore sforzo, speso non solo nella codifica dei bug, ma anche considerando i requisiti e il design del software.
• Mette la produzione a rischio inutile . È solo questione di tempo prima che le modifiche non vengano incorporate correttamente.
• Se non fa quanto sopra, allora è inutile . Se tutti i bug conosciuti sono banali, allora non cattureranno i lavoratori sotto la media: cattureranno solo persone che non stanno facendo niente. Ci sono modi migliori per farlo.
• Avvelena l'ambiente di lavoro . I tuoi tester QA sono professionisti. È necessario affidarsi a essere professionisti finché non vi è un motivo valido per sospettare il contrario. Quando c'è un motivo per sospettare che è sia il contrario, dovrebbe esserci un'indagine appropriata invece di questi giochi mentali. Qualsiasi altra cosa uccide il morale.

Scherzi a parte. Anche se la paranoia del PM risulta essere ben fondata in questo caso specifico, non si tratta di qualcuno che ha una società che gestisce tester.

Personalmente, mi sento a disagio con questo approccio.

La cosa principale che mi riguarda è la praticità di inserire errori intenzionali . Mi sembra che sia difficile da fare in qualsiasi modo sia prevedibile.

Qualsiasi modifica del codice (intenzionale o meno) rischia di avere effetti collaterali. Questi effetti collaterali potrebbero essere rivelati durante i test ma potrebbe non essere ovvio (anche allo sviluppatore che ha piazzato il bug) quale sia la causa principale. Non sembra "sicuro", se sai cosa intendo (sto parlando dal mio budello qui).

Inoltre, il tester sprecherà un sacco di tempo per testare il codice che in realtà non verrà rilasciato. Una volta che i bug intenzionali sono stati rimossi, a mio avviso dovrebbe essere comunque eseguito un nuovo test completo. Questo è l'intero punto di test. Qualcosa cambia, qualsiasi cosa , e tu prova nuovamente tutto . Ok, so che non succede mai nella pratica, ma questo è il test di regressione.

Quindi, nel complesso, non sono convinto.

D'altra parte, tendiamo a consentire ai clienti di verificare il lavoro dei team di controllo qualità, che forse non è l'ideale. È comunque un ciclo di feedback potente molto .

È una cattiva idea per tutti i motivi già forniti, ma il bug seed è uno strumento utile per uno scopo diverso. Puoi usarlo per ottenere una metrica approssimativa dell'efficacia del processo di QA.

Nel suo caso più semplice, diciamo che si seminano 100 bug e sono rappresentativi dell'intero intervallo di bug reali (lo so, improbabile, ma sto semplificando). Non dici a QA che stai facendo questo per evitare di rovinare l'esperimento. Alla fine del processo di controllo qualità, diciamo che hanno trovato 60 dei 100 bug con seme (e altri bug reali). Ora sai che il QA sta riscontrando il 60% dei bug.

Puoi estenderlo ulteriormente contando il numero di bug reali QA ha trovato e applicato il rapporto bug falso. Nel nostro esempio, se il QA ha trovato 200 bug reali, puoi concludere che ne hanno trovato solo il 60%, quindi rimangono 133.

Naturalmente, questa è solo una stima ampia con enormi barre di errore. Scrivere bug realistici e rappresentativi è difficile. È probabile che i bug che scrivi siano più facili per il controllo qualità perché gli sviluppatori sono addestrati a non scrivere bug. Potrebbe essere meglio simulare una classe di bug come errori off-by-one, errori Unicode, buffer overflow e così via.

Questo dovrebbe essere applicato all'intero QA processo che includerebbe test delle unità degli sviluppatori, integrazione continua e, se disponibile, un team di controllo qualità dedicato.

Questa è una metrica e non dovrebbe essere dirottata come strumento di gestione della motivazione.

Cattiva idea.

Questo è il tipo di approccio logico e binario che gli sviluppatori spesso portano, ma è demotivante per i QE. Dimostra semplicemente una mancanza di fiducia. I QE vengono spesso inseriti in queste situazioni senza molto input da parte loro e presuppongono che siano a loro agio, e non è il loro posto a suggerire il contrario.

Questo tipo di pensiero si combina con i QE che sono solo tester manuali e non è motivato a comprendere il codice reale sotto test.

Sono un senior QE e questo è un problema familiare nella maggior parte delle organizzazioni in cui ho lavorato.

Direi cattiva idea.

Uno: i programmatori passeranno il tempo a inserire errori deliberati nel codice e alcuni sforzi per salvare la versione corretta. Mentre i tester dovrebbero presumibilmente provare tutto, incluse le caratteristiche con il bug piantato, quando ne trovano uno, presumibilmente dovranno tornare indietro e rieseguire quel test per verificare che si sia trattato di un bug (e non che il tester sia confuso in qualche modo). Come minimo, i tester passeranno il tempo a scrivere gli insetti piantati. Quindi i programmatori devono passare il tempo a sistemare il bug che hanno piantato. Questo è un grande sforzo che potrebbe essere speso cercando di scrivere un buon codice e scrivere bug reali.

Due: invia un messaggio chiaro ai tester che i programmatori e / o la direzione pensano che non stiano facendo il loro lavoro e debbano essere trattati da bambini. Non riesco a immaginare che questo sia positivo per il morale. Come programmatore, se mi venivano date specifiche ambigue o contraddittorie per un programma e dovevo dedicare un po 'di tempo a farle chiarire, e poi dopo aver sprecato ore o giorni il mio capo mi disse: "Oh, sì, ho deliberatamente messo delle affermazioni contraddittorie le specifiche solo per essere sicuro che le steste davvero leggendo ", penso che sarei davvero seccato. Se ciò accade regolarmente, potrebbe essere abbastanza per farmi cercare un altro lavoro.

Nella vita reale, tutti i cambiamenti di codice, tranne quelli più banali, avranno dei bug. Non ho mai avuto problemi con i tester che si sentivano compiacenti perché la prima bozza di codice fornita era così spesso perfetta al 100%. Ho dovuto fare i conti con i tester pigri che non fanno un lavoro adeguato, ma non sono riusciti a farlo perché i programmatori erano così perfetti. La miglior persona di test con cui abbia mai lavorato una volta mi ha detto che per una nuova versione del software, si è prefissato di trovare 100 bug. Va bene, se 100 è un numero realistico dipende da quanto è grande il prodotto e quanto ampie sono le modifiche, ma nel nostro caso, è quasi sempre riuscito a raggiungere quell'obiettivo. A volte doveva allungare le cose, come chiamare una parola errata in un messaggio come un "bug", ma hey, doveva essere corretto.

Post script: se lo fai, scommetto che prima o poi i programmatori piangeranno deliberatamente un bug, i tester non lo troveranno particolare ei programmatori dimenticheranno di rimettere il buon codice. Così ora un bug deliberatamente piantato viene spedito al cliente.

Non penso che questa sia un'idea cattiva . C'è solo un sacco di cose che vorrei speculare funzionare meglio:

1. Rendi il QA responsabile della qualità in ogni modo possibile. Ad esempio, supportando anche la loro responsabilità. Ciò aumenterà la loro motivazione per assicurarsi che i prodotti spediti abbiano una qualità superiore. Ci vuole sempre meno sforzo per scoprire un'inadeguatezza (bug, ovviamente manchevole, comportamento contro-intuitivo) per poi cercare di capire cosa sta cercando di spiegare l'utente sconvolto. E mettere un po 'di quella responsabilità anche sugli sviluppatori potrebbe aumentare la loro motivazione per aiutare il QA a fare il loro lavoro nel miglior modo possibile.

2. Avere più team di QA, che possono competere. È necessario trovare una metrica ragionevole, naturalmente. Sicuramente non solo il numero di problemi. Il factoring nella gravità del difetto o il valore aziendale (come determinato dalle parti interessate) dei miglioramenti proposti dovrebbe aiutare.

È difficile dire se il QA sia "abbastanza buono". È più facile e forse anche migliore, a lungo termine, trovare i modi per migliorare "il miglioramento della qualità".

Tuttavia, c'è un problema da tenere presente se introduci bug intenzionali: Come fai a sapere che il codice "corretto" è mai stato effettivamente corretto in primo luogo? Dopo il 2 ° QA rimuovi tutti bug intenzionali che non erano stati scoperti. Non c'è modo di sapere che non stai semplicemente sostituendoli con un codice che è rotto in un modo diverso o che non stai attivando un comportamento interrotto prima irraggiungibile (esempio esagerato: alcune finestre di dialogo non si aprivano a causa di un bug intenzionale, ma il dialogo stesso è rotto - non lo si capisce perché i tester non sono riusciti a vederlo)

Come altri hanno già detto, gli sviluppatori non dovrebbero aggiungere intenzionalmente bug nel software, ma è una strategia legittima per la tua suite di test aggiungere bug nel software come parte del processo di test.

Si chiama test di mutazione . L'idea è di usare il software per automatizzare la creazione di piccoli cambiamenti nel codice sorgente (chiamati mutanti). Le modifiche sono progettate per creare comportamenti diversi, ad esempio, potremmo cambiare

if x < 10:
    print "X is small!"

in

# we flipped the inequality operator
if x > 10:
    print "X is small!"

e un buon test unitario dovrebbe rilevare che il frammento di codice mutante non funziona più come previsto e uccide il mutante . Quando il codice originale supera il test e tutti i mutanti (che non sono funzionalmente equivalenti) falliscono il test, quindi sai che il tuo codice e i tuoi test sono forti .

Mi piace l'idea. È stato il generale Patton a dire: "Più sudi in pace, meno sanguini in guerra".

Mettere bug intenzionali "fa perdere tempo" ai tester. Ma ciò li rende anche più difficili da lavorare, il che significa che faranno anche un lavoro migliore nel trovare bug non intenzionali. (E tu hai una copia dell '"originale" in modo da non dover vivere con quello che hai fatto.)

Trovare altri bug non intenzionali probabilmente ti farà risparmiare più dolore nel lungo periodo rispetto al costo di trattare quelli intenzionali.

Inoltre, puoi farti un'idea di quanto siano bravi i tester, non un piccolo vantaggio in sé.

Non esiste una base per una ricompensa o una punizione per il suo merito, ma sul risultato del comportamento che stai prendendo di mira. E a volte ci sono conseguenze non intenzionali. L'obiettivo è quello di mantenere il team di controllo della qualità di rallentamento o di far sentire a qualche manager come se stesse effettivamente contribuendo a qualcosa senza rendersi conto che si sta solo intromettendo.

Risultato positivo - Il team addetto al controllo qualità lavora di più per trovare bug. Chi lo sa, forse lo vedono come una sfida. È un gioco amichevole. O lo stanno facendo solo perché vengono guardati (effetto Hawthorne?).

Risultato negativo: potrebbero non lavorare più duramente e trovare comunque l'errore. Il QA lo vede come meschino e contraddittorio. Così ora, entrano in un drive di ricerca di iper-bug e restituiscono ogni sorta di piccoli problemi pignoli. Quel tipo di carattere non viene visualizzato correttamente quando prendo una schermata e lo converto in un pdf e lo visualizzo al 500%.

No Impact - mi sembra che questo non faccia differenza, quindi perché preoccuparsi? Rischi solo di perdere tempo e persone irritanti.

Potremmo essere tutti d'accordo sul fatto che ciò non funzionerà il 90% delle volte. Questo non fa molto bene al restante 10%. Metti alla prova le cose per te. I clienti sono più soddisfatti di una versione che presenta i bug intenzionali del codice? Ha un impatto sul morale dei lavoratori e sulla produttività in altre aree? Aumentare il fatturato? Ci hai detto.

Venendo da un mondo in cui ci si aspetta che gli sviluppatori scrivano ed eseguano i test, questo silo di "test" "QA" a cui ti riferisci spaventa e mi confonde, quindi cercherò di rispondere da questa prospettiva. Per inciso, gli ingegneri qualificati di QA, dal mio punto di vista, (come descritto bene nella risposta di @ SparK), dovrebbero concentrarsi sui problemi più grandi di assicurarsi che il software soddisfi pienamente le storie degli utenti e abbia una "qualità" complessiva (rispetto a il dominio a cui è destinato il software), invece di cercare i bug.

Ciò che mi ha attirato qui è la citazione di @ JamesMcleod di "iniezione di difetti" nei commenti alla domanda. In realtà penso che avere gli sviluppatori che pensano a come iniettare i bug nel sistema è una grande idea per focalizzare il concetto di difesa in profondità. Nessun singolo bug dovrebbe mai essere sufficiente a far cadere l'intero sistema in modo incontrollato (senza una chiara registrazione utilizzabile), causare alcun danneggiamento dei dati, o di per sé esporre una vulnerabilità di sicurezza.

Se gli sviluppatori di ciascun componente creano difetti intenzionali, gestiscono quelli di altri componenti e, in generale, inseriscono una mentalità più contraddittoria riguardo al loro software, che potrebbe eventualmente contribuire molto a migliorare la robustezza del software. Anche il beneficio immediato potrebbe essere significativo: richiederei che durante ogni iniezione di questo tipo di difetto (che non era stato ancora testato), lo sviluppatore lo avrebbe immediatamente coperto con un nuovo test, che verrà impostato con una bandiera che consentire al bug di vivere nel codice base indisturbato per un breve periodo di tempo, e quindi attivarlo prima della consegna (e rimuovere il difetto), per trasformarlo in un normale test che renderà la suite di test più completa.

Un'opzione correlata è l'uso di flag di funzionalità per disattivare intenzionalmente le funzionalità in determinati componenti per esaminare il modo in cui gli altri componenti si occupano di ciò. Vorrei anche raccomandare di leggere il libro / articolo gratuito "Imparare dai primi risponditori : Quando i tuoi sistemi devono funzionare " che descrive test approfonditi sull'infrastruttura software che il team di Obama utilizzerà per le elezioni del 2012.

Come altri hanno già detto, non è compito del QA trovare solo bug. Vorrei andare oltre e dire che non è affatto il loro lavoro, tecnicamente. Gli sviluppatori dovrebbero essere responsabili di mantenere il proprio codice privo di errori. Le suite di test devono essere eseguite prima che il nuovo codice venga mai eseguito, e se le suite di test falliscono, non dovrebbe mai farlo passare al QA in primo luogo. L'introduzione di bug intenzionalmente significa che non puoi assolutamente passare le tue suite di test, quindi perché il tuo codice va al QA?

Il compito del controllo qualità è di convalidare l'applicazione rispetto alle storie utente implementate. Dovrebbero testare il flusso, l'interfaccia utente, ecc. E garantire che l'utente possa fare tutto ciò che l'utente dovrebbe essere in grado di fare, nel modo più utilizzabile e accessibile possibile. Mentre lo fanno, naturalmente, potrebbero incappare in bug, ma questo è un effetto collaterale di ciò che fanno, non quello che fanno. Ricorda che QA significa garanzia di qualità, non garanzia di bug-free.

Questo non è necessariamente così folle come sembra. Dipende piuttosto dalla tua motivazione. Se stai cercando un bastone per battere la tua squadra di test, beh, sarebbe pazzo. D'altra parte, una delle cose più difficili nello sviluppo del software è sapere quanto sia efficace l'approccio di test.

Quindi, se lo strutturi correttamente, potresti usare questa tecnica per stimare quanti bug infondati rimangono nel prodotto che stai per spedire. Quindi immagina di aver artificialmente seminato 100 bug nella tua build di test, e i tester ne trovano 50. Quindi puoi dedurre che c'è una certa probabilità che, se trovassero anche 50 bug non affetti, forse ne rimangono ancora 50 da trovare.

Naturalmente, questo è pieno di molti problemi. Potresti decidere se spedire in base a queste statistiche, ma nella vita reale potresti trovare un problema molto sgradevole o mille irritazioni minori.

Ancora: la conoscenza è potere, e senza questa tecnica, hai ancora meno idea della qualità della tua base di codice. Se puoi implementarlo rispettosamente e per i giusti motivi, direi "Perché no?"

Una cosa che nessuno ha ancora menzionato: test delle mutazioni .

Questo è il punto in cui uno strumento automatico prende il codice sorgente e inserisce deliberatamente bug in esso. (Ad esempio, elimina un'istruzione scelta a caso, modifica un AND in un OR o qualsiasi altra cosa.) Quindi esegue l'intera suite di test e controlla se i test superano.

Se passano tutti i test, ci sono due possibilità:

• La cosa che è stata cambiata non fa nulla. In altre parole, hai un codice morto.
• La modifica ha introdotto un bug che la tua suite di test non sta rilevando. Hai bisogno di più test.

Tieni presente che, a differenza della tua proposta, tutto ciò che ho descritto sopra è automatizzato . Non stai sprecando tempo per gli sviluppatori inserendo bug inutili a mano. E non stai sprecando tempo per i tester a trovare bug conosciuti. L'unica cosa che stai usando è il tempo della macchina, che è molto più economico. (Le macchine non si annoiano mai di fare lo stesso test 20.000 volte: gli umani smettono di preoccuparsi dopo un po '!)

Suggerirei che il test della mutazione automatizzata sia un approccio di gran lunga migliore rispetto allo scenario manuale di cui stai parlando.

Nota che se chiedi a uno sviluppatore di inserire manualmente i bug, il tipo di bug che ottieni non è probabilmente rappresentativo del tipo di errori accidentali che gli umani potrebbero commettere. (Ad esempio, se non hai realizzato che c'è una possibile condizione di competizione, è improbabile che tu inserisca anche una deliberata.) Se uno strumento automatizzato riesce ad essere più obiettivo resta da vedere, ovviamente ...

Sebbene sia una cattiva idea in generale (le altre risposte spiegano perfettamente il motivo), c'è qualche situazione particolare in cui intenzionalmente iniettare errori nel codice di produzione in modo controllato e temporaneo può avere un senso.

Quando rifatti il codice di test - e dovresti, il codice di prova merita la stessa attenzione ai dettagli del codice di produzione - potresti voler sapere se il codice del test sta ancora trovando i bug che dovrebbe trovare.

Puoi quindi interrompere intenzionalmente il codice di produzione per verificare se i test funzionano ancora.

Ci sono più livelli su cui ciò è possibile:

• Uno sviluppatore che ha appena effettuato il refactoring di alcuni test di unità potrebbe rompere il codice di produzione per verificare che il test dell'unità trovi ancora ciò che dovrebbe trovare.
• Un tester che ha appena effettuato il refactoring di alcuni test di accettazione potrebbe interrompere il codice di produzione per verificare che il test di accettazione verifichi ancora ciò che deve verificare.
• Se l'interfaccia è stabile e sufficientemente robusta (ad esempio basata su protocollo), la società potrebbe voler mantenere una suite di versioni di prodotti difettosi noti e eseguire test contro di essi per test di regressione del test.

Dipende se queste cose hanno un senso. Se sono uno sviluppatore e mi ci vuole un minuto per iniettare un bug, testare il test dell'unità, rimuovere il bug, quindi perché no. Ma dovrei avere il mio editor, il mio ciclo e il mio sistema di controllo delle versioni sotto un controllo così buono che non avrei accidentalmente commesso / consegnato / check-in / spinto il bug. Lo stesso vale per il tester e il test di accettazione.

Se è logico che un'organizzazione mantenga serie di versioni di prodotti difettosi noti e test di regressione dipende dal test. Per un negozio online non lo farei. Per le schede embedded, aerospaziali incorporate, carte bancarie o pay TV.

Quanto impegno dipende in larga misura dal modo in cui i test sono disaccoppiati dal codice di produzione. Più i test sono disaccoppiati dal codice di produzione, minore è lo sforzo per farlo, più i test sono coesi con il codice di produzione, più lo sforzo.

Il motivo è semplicemente questo: quando i test e il codice di produzione sono coerenti, la modifica del codice di produzione richiede spesso la modifica dei test e ciò interromperà la dipendenza tra i test e gli esempi di produzione difettosi. Dovresti quindi mantenere anche i campioni di produzione difettosi. In rari casi, anche questo può valerne la pena, e il derisione e l'uso intelligente di un sistema di controllo delle versioni può ridurre significativamente lo sforzo, ma richiede sviluppatori ben più esperti.

Il concetto di intenzionale iniezione di errori nel codice di produzione si chiama sabotage , il difetto iniettato è chiamato saboteur .

Un tester che non sta prendendo il codice da testare direttamente dal repository lo sta facendo male. (1)

Uno sviluppatore che sta controllando codice noto in modo errato nel repository lo sta facendo male. (2)

Quindi, in questa fase, non c'è ancora modo per questo schema di funzionare senza che una o entrambe le parti violino le premesse molto basilari su come lo sviluppo e il testing dovrebbero essere fatti.

(1) Perché è necessario documentare quale versione è stata testata. Una versione taggata da un hash Git o un numero di revisione SVN è qualcosa che puoi testare, "il codice che Joe mi ha dato" non lo è.

(2) Perché non lo fai, al di fuori di un test driver che è in attesa di fallito.

Questo è un tentativo di una ragione più breve, "elevator pitch", che dovrebbe avere un senso immediato per gli sviluppatori, i tester e la gestione allo stesso modo.

Mi raccomando di non iniettare deliberatamente bug in OGNI build che invii al QA.

Potresti, di tanto in tanto, diciamo una volta all'anno, fare un "controllo di qualità" nascosto. Prendi una base di codice "testata e funzionante" e tante nuove piccole funzionalità dalla tua lista Todo possibile. Implementali "un po 'più sciatti" di quanto fai di solito. Pensa ai casi limite, scrivili, ma non aggiustare il codice per tenerli in considerazione. Invia a QA.

Se trovano bug di casi limite non funzionanti di quelli che hai annotato, non è certamente il tuo QA che ha bisogno di supervisione ...; -)