Lasciando bug intenzionali nel codice per i tester da trovare

Non lo facciamo presso la nostra azienda, ma uno dei miei amici afferma che il suo project manager ha chiesto a tutti gli sviluppatori di aggiungere bug intenzionali poco prima che il prodotto passasse al QA. È così che funziona:

1. Poco prima che il prodotto passi al QA, il team di sviluppo aggiunge alcuni bug intenzionali in punti casuali nel codice. Eseguono correttamente il backup del codice originale funzionante per assicurarsi che tali bug non vengano spediti con il prodotto finale.
2. Anche i tester sono informati di questo. Quindi testeranno duramente, perché sanno che ci sono bug presenti e che non trovarli potrebbe essere considerato un segno di incompetenza.
3. Se è stato trovato un bug (intenzionale o meno), verrà segnalato dal team di sviluppo per la correzione. Il team di sviluppo aggiunge quindi un altro bug intenzionale in una sezione correlata del codice appena prima che il prodotto passi al QA di secondo livello. Il responsabile del progetto afferma che un tester dovrebbe pensare come uno sviluppatore e dovrebbe aspettarsi nuovi bug nelle sezioni in cui sono state apportate modifiche.

Bene, ecco come va. Dicono che questo approccio ha i seguenti vantaggi.

1. I tester saranno sempre pronti e testeranno come un matto. Ciò li aiuta a trovare anche bug nascosti (non intenzionali) in modo che gli sviluppatori possano risolverli.
2. I tester si nutrono di bug. Non trovare alcun bug influenzerà il loro morale. Quindi dare loro una facile da trovare aiuterà il loro morale.

Se ignori lo scenario in cui uno di questi bug intenzionali viene spedito con il prodotto finale, quali sono gli altri svantaggi che dovremmo considerare prima ancora di pensare di adottare questo approccio?

Alcuni chiarimenti:

1. Eseguono correttamente il backup del codice originale nel controllo del codice sorgente.
2. Quando un tester rileva il bug intenzionale, il team di sviluppo lo ignora. Se il tester rileva un bug non intenzionale (originale), il team di sviluppo controlla innanzitutto se è causato da uno qualsiasi dei bug intenzionali. Cioè, il team di sviluppo cerca prima di riprodurlo sul codice di lavoro originale e cerca di risolverlo se può.
3. Ignora i problemi di relazione tra QA e il team di sviluppo. Ho fatto specificamente questa domanda sui programmatori , non su The Workplace . Considera che esiste un buon rapporto tra QA e il team di sviluppo, e fanno festa insieme dopo l'orario di lavoro. Il project manager è un simpatico, vecchio signore, sempre pronto a supportare entrambe le squadre (Godsend).

Sembra assolutamente folle. Si sta impegnando molto per un beneficio molto discutibile e la pratica sembra basata su alcune premesse errate:

• Che il QA non lavorerà sodo a meno che non sappiano di essere testati ogni giorno (il che non può essere buono per il morale)

• Che non ci siano abbastanza bug introdotti involontariamente nel software da trovare per il QA

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

• Che questo tipo di battaglia di ingegno tra sviluppo e QA sia in qualche modo salutare per l'azienda - non lo è; tutti i dipendenti dovrebbero lavorare insieme contro i concorrenti dell'azienda anziché tra di loro.

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

Per espandere la mia descrizione del "lavoro di controllo qualità:" il controllo qualità dovrebbe sicuramente trovare bug - sia nel codice che nelle loro suite di test - come un artefatto nel fare il loro lavoro, ma il ruolo non dovrebbe essere definito come "devi trovare bug ". Dovrebbe essere "è necessario mantenere aggiornate le suite di test per tenere conto delle nuove funzionalità e garantire un'elevata copertura dei test. Se ciò non comporta la 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 dell'azienda.

Il QA non è lì solo per trovare bug ma anche per preoccuparsi di quanto sia intuitivo il sistema, qual è la curva di apprendimento per l'utente, l' usabilità e l' accessibilità in generale. Ad esempio: "Il sistema è brutto ?", "L'utente è daltonico e le cose sono rosse e verdi?" Dovrebbero anche lamentarsi.

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

tl; dr

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

Cattiva idea.

Dal punto di vista del tester: "Quindi testeranno duramente, perché sanno che ci sono bug presenti e non trovarli potrebbero essere considerati come la loro incompetenza". Fondamentalmente gli sviluppatori stanno intercettando il codice. Poche persone amano fare un lavoro che alla fine è inutile (perché i bug sono noti in anticipo) ma che influenzano ancora il modo in cui vengono percepiti. Se ci sono punizioni tangibili per non aver trovato le trappole esplosive, di più. E conosci i tester che 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 se sono pagati dal bug ... http://thedailywtf.com/articles/The-Defect-Black-Market

Dal punto di vista dello sviluppatore: i QA vengono incentivati ​​a trovare i bug che sai che ci sono. Ciò potrebbe aumentare la probabilità che veri e propri bug escano dalla porta; i QA stanno trascorrendo almeno un po 'del loro tempo a cercare il tipo di bug facile da piantare, non molto sottile. Inoltre c'è una piccola possibilità che una trappola esplosiva possa uscire dalla porta.

Concordo pienamente con le risposte sopra riportate sul perché questo è negativo per la motivazione e per la gestione delle persone in generale terribile. Tuttavia, ci sono probabilmente validi motivi tecnici per non farlo anche:

Poco prima che il prodotto passi al QA, il team di sviluppo aggiunge alcuni bug intenzionali in punti casuali nel codice. Eseguono correttamente il backup del codice originale funzionante per assicurarsi che tali bug non vengano spediti con il prodotto finale.

1. In base alla prima affermazione, in questi due passaggi non testerai mai il tuo codice di produzione previsto.

2. Immagino che aumenti enormemente la probabilità di includere accidentalmente un bug "intenzionale" nel tuo codice di produzione rilasciato quando provi a eseguire una modifica per un cliente. Potrebbe causare alcune guance rosse ad un certo punto.

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

modificare

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

Fine modifica

C'è un motivo valido per verificare se il test / controllo funziona davvero. Lasciate che vi dia un esempio dalla produzione, ma il principio è lo stesso.

È tipico quando si alimenta materiale attraverso una macchina che l'alimentatore potrebbe non spingere il materiale abbastanza lontano. Questo si chiama "alimentazione breve" e per evitare ciò potremmo installare un "sensore di alimentazione breve" (in genere un sensore di tipo a fascio passante che è bloccato dal materiale). Questo sensore rileva la fine del materiale quando raggiunge l'intera lunghezza di avanzamento. Ad un certo punto del ciclo della macchina controlliamo che il sensore sia bloccato e fermiamo 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 fermerà 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 viene tagliato o l'alimentazione viene persa per quel sensore, o l'ingresso non è riuscito, la logica del programma dovrebbe leggere "OFF" e significherebbe "bloccato" o "OK".

Per rilevare queste modalità di errore del test, di solito 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 effettivamente operativo (nel miglior modo possibile).

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

Ovviamente lo svantaggio è che un "bug di prova" potrebbe passare attraverso il reparto QA e nel prodotto finito. Nel settore manifatturiero a volte ci sono casi in cui una parte cattiva conosciuta, a volte chiamata "Coniglio rosso", viene inserita nel processo (in genere da qualcuno del QA) e osservano quella parte passare attraverso il processo e misurare quanto tempo impiega trova la parte e rimuovila. Normalmente questa parte è dipinta di rosso brillante (o arancione) in modo da poter essere facilmente rintracciata. Dal momento che qualcuno sta osservando il processo durante questo test, la possibilità che arrivi al prodotto finale è praticamente nulla. Ci sono, naturalmente, storie apocrife di qualcuno che lancia nel processo una parte nota nota per "vedere se il sistema riesce a trovarla",

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

• 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'intero motivo per cui i team addetti al 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 mancano.
• Spreca sforzi di controllo qualità . Supponendo che questi bug non siano banali - vedi sotto per quando lo sono - significa che il QA sta spendendo tempo e risorse per indagare su cose che sono già note, quando potrebbero spendere quello sforzo per cercare ciò che non è noto.
• Spreca lo sforzo degli sviluppatori . Affinché gli addetti al controllo qualità possano cogliere questi bug non banali, gli sviluppatori devono prima scriverli. Ciò richiede ulteriori sforzi, non solo per la codifica dei bug, ma anche per la considerazione dei requisiti e della progettazione del software.
• Mette la produzione a rischio inutile . È solo questione di tempo prima che le modifiche non vengano integrate correttamente.
• Se non fa quanto sopra, allora è inutile . Se tutti i bug conosciuti sono banali, allora non cattureranno i lavoratori scadenti: cattureranno solo le persone che non lavorano affatto. Ci sono modi migliori per farlo.
• Avvelena l'ambiente di lavoro . I tuoi tester di qualità sono professionisti. Dovrebbero essere ritenuti affidabili per essere professionali fino a quando non vi è motivo effettivo di sospettare diversamente. Quando v'è motivo di sospettare in caso contrario, non ci dovrebbe essere una vera e propria indagine, invece di questi giochi mentali. Qualsiasi altra cosa uccide il morale.

Sul serio. Anche se la paranoia del primo ministro risulta essere fondata in questo caso specifico, questa non è una persona che ha attività di gestione dei tester.

Personalmente, mi sento a disagio con questo approccio.

La cosa principale che mi riguarda è la praticità dell'inserimento di bug intenzionali . Questo mi sembra difficile da fare in qualsiasi modo prevedibile.

Eventuali modifiche al codice (intenzionali o meno) rischiano di avere effetti collaterali. Questi effetti collaterali possono essere rivelati durante i test ma potrebbe non essere ovvio (anche per lo sviluppatore che ha piantato il bug) quale sia la causa principale. Non sembra "sicuro", se sai cosa intendo (sto parlando dal mio istinto qui).

Inoltre, il tester sprecherà molto tempo a testare il codice che non verrà effettivamente rilasciato. Una volta che i bug intenzionali sono stati rimossi, un nuovo test completo dovrebbe essere fatto comunque, secondo me. Questo è il punto centrale del test. Qualcosa cambia, qualsiasi cosa , e riesegui tutto di nuovo . Ok, lo so che non succede mai in pratica, ma questo è il test di regressione.

Quindi, nel complesso, non convinto.

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

È una cattiva idea per tutti i motivi già indicati, ma il seeding di bug è uno strumento utile per uno scopo diverso. Puoi usarlo per ottenere una metrica approssimativa di quanto sia efficace il processo di QA.

Nel suo caso più semplice, diciamo che si seminano 100 bug e sono rappresentativi dell'intero arco di bug reali (lo so, è improbabile, ma sto semplificando). Non dici al QA che lo stai facendo per evitare di rovinare l'esperimento. Alla fine del processo di QA, supponiamo che abbiano trovato 60 dei 100 bug seminati (e altri bug reali). Ora sai che il QA sta trovando il 60% dei bug.

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

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 da trovare perché gli sviluppatori sono addestrati a non scrivere bug. Potrebbe essere meglio simulare una classe di bug come errori off-by-one, errori Unicode, overflow del buffer e così via.

Ciò dovrebbe essere applicato all'intero processo di controllo qualità che includerebbe test dell'unità di sviluppo, integrazione continua e, se disponibile, un team dedicato al controllo qualità.

Questa è una metrica e non deve essere dirottata come strumento motivazionale di gestione.

Cattiva idea.

Questo è il tipo di approccio logico e binario che spesso portano gli sviluppatori, 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 si è presunto che stiano bene con esso, e non è il loro posto per suggerire diversamente.

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

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

Direi una cattiva idea.

Uno: i programmatori impiegheranno del tempo a inserire bug deliberati nel codice e ad impegnarsi per salvare la versione corretta. Mentre i tester dovrebbero presumibilmente testare tutto, comprese le funzionalità con il bug piantato, quando ne trovano uno presumibilmente dovranno tornare indietro e rieseguire quel test per verificare che si trattasse effettivamente di un bug (e non che il tester si sia confuso) in qualche modo). Come minimo, i tester passeranno del tempo a scrivere i bug piantati. Quindi i programmatori devono passare il tempo a correggere il bug che hanno piantato. Questo è un grande sforzo che potrebbe essere speso cercando di scrivere un buon codice e scrivere veri e propri bug.

Due: invia un messaggio chiaro ai tester che i programmatori e / o la direzione pensano di non svolgere il proprio lavoro e devono essere trattati come bambini. Non riesco a immaginare che questo faccia bene al morale. Come programmatore, se mi venissero fornite specifiche ambigue o contraddittorie per un programma e dovessi dedicare un sacco di tempo a chiarirle, e dopo aver perso ore o giorni il mio capo mi ha detto: "Oh, sì, ho deliberatamente messo dichiarazioni contraddittorie in le specifiche solo per essere sicuro che le stessi davvero leggendo ", penso che sarei davvero infastidito. Se ciò accadesse regolarmente, potrebbe essere sufficiente per farmi cercare un altro lavoro.

Nella vita reale, tutti tranne i cambiamenti di codice più banali avranno bug. Non ho mai avuto problemi con i tester che diventano compiacenti perché la prima bozza del codice che gli è stata data è stata così spesso perfetta al 100%. Ho avuto a che fare con tester pigri che non fanno un lavoro adeguato, ma non sono riusciti perché i programmatori erano così perfetti. Il miglior test con cui abbia mai lavorato una volta mi ha detto che per una nuova versione del software, si è prefissato un obiettivo personale per trovare 100 bug. Va bene, se 100 sia un numero realistico dipende da quanto è grande il prodotto e da quanto sono ampi i cambiamenti, ma nel nostro caso, è quasi sempre riuscito a raggiungere quell'obiettivo. A volte doveva allungare le cose, come chiamare una parola scritta male in un messaggio come "bug", ma ehi, doveva essere risolto.

Post script: Se lo fai, scommetto che prima o poi i programmatori pianificheranno deliberatamente un bug, i tester non troveranno quello in particolare e i programmatori dimenticano di rimettere il buon codice. Quindi ora un bug piantato deliberatamente viene spedito al cliente.

Non penso proprio che sia una cattiva idea. Ci sono solo un sacco di cose su cui vorrei speculare meglio:

1. Rendi il QA responsabile della qualità in ogni modo possibile. Ad esempio, fornendo supporto anche la loro responsabilità. Ciò aumenterà la loro motivazione per garantire che i prodotti spediti abbiano una qualità superiore. Ci vuole sempre meno sforzo per scoprire una inadeguatezza (bug, caratteristica ovviamente mancante, comportamento controintuitivo) da soli, quindi per cercare di capire cosa sta cercando di spiegare l'utente sconvolto. E affidare una parte di tale responsabilità anche agli sviluppatori potrebbe aumentare la loro motivazione per aiutare il QA a svolgere il proprio lavoro nel miglior modo possibile.

2. Avere più team di controllo qualità, che possono competere. Ovviamente devi trovare una metrica ragionevole. Sicuramente non solo il numero di problemi. La fattorizzazione della gravità del difetto o del valore commerciale (come determinato dalle parti interessate) dei miglioramenti proposti dovrebbe aiutare.

È difficile stabilire se il QA sia "abbastanza buono". A lungo termine è più facile e forse anche meglio trovare modi per far sì che il QA sia "in costante miglioramento".

Tuttavia, c'è un problema da tenere presente se si introducono bug intenzionali: come si fa a sapere che il codice "corretto" è mai stato effettivamente corretto in primo luogo? Dopo il 2 ° QA rimuovi tutti i bug intenzionali che non sono stati scoperti. Non c'è modo di sapere che non si sta semplicemente sostituendoli con un codice che è stato rotto in un modo diverso o che non si sta abilitando un comportamento rotto che prima non era raggiungibile (esempio esagerato: alcune finestre di dialogo non si aprivano a causa di un bug intenzionale, ma la finestra di dialogo stessa è rotta - semplicemente non lo scopri 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 utilizzare il software per automatizzare la creazione di piccole modifiche nel codice sorgente (chiamati mutanti). Le modifiche sono progettate per creare comportamenti diversi, ad esempio, potremmo cambiare

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

dentro, come moto a luogo, andare da dentro a fuori: I put my hand inTO my pocket = metto la mano in tasca

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

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

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

Mettere bug intenzionali "perde tempo" per i tester. Ma ciò li rende anche più impegnativi, il che significa che faranno anche un lavoro migliore nel trovare bug involontari. (E hai una copia dell '"originale" in modo da non dover convivere con quello che hai fatto.)

Trovare più bug non intenzionali ti farà risparmiare più dolore a lungo termine che i costi di gestione di quelli intenzionali.

Inoltre, puoi avere un'idea di quanto siano buoni i tuoi tester, non un piccolo vantaggio in sé.

Non esiste una base per una ricompensa o una punizione per i suoi meriti, ma sul risultato del comportamento che stai prendendo di mira. E a volte ci sono conseguenze indesiderate. L'obiettivo è impedire al gruppo addetto al controllo qualità di rallentare o far sentire un manager come se stesse davvero contribuendo a qualcosa senza rendersi conto che si sta solo mettendo in mezzo.

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

Esito negativo: potrebbero non funzionare di più e trovare comunque il bug. Il QA lo considera meschino e contraddittorio. Quindi ora, entrano nell'unità di ricerca di hyper-bug e restituiscono ogni sorta di piccoli problemi pignoli. Quel font non viene visualizzato correttamente quando faccio uno screenshot e lo converto in pdf e lo visualizzo al 500%.

Nessun impatto - il suono per me in questo modo non fa differenza, quindi perché preoccuparsi? Rischi solo di perdere tempo e di irritare le persone.

Siamo tutti d'accordo sul fatto che questo non funzionerà il 90% delle volte. Ciò non fa molto bene all'altro 10%. Metti alla prova le cose per te stesso. I clienti sono più soddisfatti di una versione che ha i bug del codice intenzionale? Incide sul morale e sulla produttività dei lavoratori in altre aree? Aumentare il fatturato? Ci dite

Proveniente da un mondo in cui gli sviluppatori dovrebbero scrivere ed eseguire i test da soli, questo silo "testing" "QA" a cui ti riferisci fa paura e mi confonde, quindi cercherò di rispondere da questa prospettiva. A parte questo, dal mio punto di vista, i tecnici qualificati del QA (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à" generale (per quanto riguarda il dominio a cui è destinato il software), invece di cercare bug.

Ciò che mi ha attratto qui è la menzione di @ JamesMcleod di "iniezione di difetti" nei commenti alla domanda. In realtà penso che far pensare agli sviluppatori come poter iniettare bug nel sistema sia un'ottima idea per indirizzare in profondità il concetto di difesa. Nessun singolo bug dovrebbe mai essere sufficiente per far crollare l'intero sistema in modo incontrollato (senza una chiara registrazione utilizzabile), causare la corruzione dei dati o di per sé esporre una vulnerabilità di sicurezza.

Fare in modo che gli sviluppatori di ciascun componente creino difetti intenzionali, gestiscano quelli di altri componenti e nel complesso entri in una mentalità più contraddittoria nei confronti del loro software, potrebbe forse fare molto per migliorare la robustezza del software. Anche il vantaggio immediato potrebbe essere significativo - richiederei che durante ogni iniezione di un nuovo tipo di difetto (che non era stato finora testato), lo sviluppatore lo coprisse immediatamente con un nuovo test, che verrà impostato con una bandiera che consentire al bug di vivere nella base di codice indisturbato per un breve periodo, quindi accendere prima della consegna (e rimuovere il difetto), per trasformarsi in un test regolare che renderà la suite di test più completa.

Un'opzione correlata è l'uso dei flag delle funzionalità per disattivare intenzionalmente le funzionalità in determinati componenti per esaminare il modo in cui altri componenti lo gestiscono. Vorrei anche raccomandare vivamente di leggere il libro / articolo gratuito "Imparare dai primi soccorritori: quando i tuoi sistemi devono funzionare" che descrive test così approfonditi dell'infrastruttura software che il team di Obama dovrà utilizzare 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 bug. Le suite di test dovrebbero essere eseguite prima ancora che venga eseguito il commit del nuovo codice e, se le suite di test falliscono, non dovrebbero mai arrivare al QA in primo luogo. L'introduzione intenzionale di bug significa che non puoi assolutamente superare le tue suite di test, quindi perché il tuo codice andrà al QA?

Il compito del controllo qualità è convalidare l'applicazione rispetto alle storie utente che implementa. Dovrebbero testare il flusso, l'interfaccia utente, ecc. E assicurarsi 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, ovviamente, possono imbattersi in bug, ma questo è un effetto collaterale di ciò che fanno, non di quello che fanno. Ricorda che QA significa garanzia di qualità, non garanzia senza errori.

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

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

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

Tuttavia, la conoscenza è potere e senza questa tecnica hai ancora meno idea della qualità della tua base di codice. Se riesci a implementarlo rispettosamente e per le giuste ragioni, direi "Perché no?"

Una cosa che nessun altro ha ancora menzionato: test di mutazione .

Qui è dove uno strumento automatizzato prende il tuo codice sorgente e inserisce deliberatamente dei bug in esso. (Ad esempio, eliminare un'istruzione scelta casualmente, modificare un AND in un OR o altro.) Quindi esegue l'intera suite di test e controlla se i test hanno superato.

Se tutti i test superano, allora 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 suite di test non sta rilevando. Hai bisogno di più test.

Nota che, a differenza della tua proposta, tutto ciò che ho descritto sopra è automatizzato . Non stai sprecando il tempo degli sviluppatori inserendo manualmente inutili bug. E non stai sprecando il tempo dei tester a trovare bug noti. L'unica cosa che stai usando è il tempo della macchina, che è molto più economico. (Le macchine non si annoiano di fare lo stesso test 20.000 volte. Gli umani smettono di preoccuparsi dopo un po '!)

Suggerirei che il test di mutazione automatizzato sia un approccio molto, molto migliore rispetto allo scenario manuale di cui stai parlando.

Nota che se chiedi a uno sviluppatore di inserire manualmente dei bug, il tipo di bug che ricevi non è probabilmente rappresentativo del tipo di errori accidentali che gli umani potrebbero fare. (Ad esempio, se non ti sei reso conto che esiste una possibile condizione di gara, è improbabile che ne inserisca una deliberata.) Se un strumento automatizzato riesce a essere più obiettivo resta da vedere, ovviamente ...

Sebbene sia una cattiva idea in generale (le altre risposte spiegano perfettamente il perché), ci sono alcune situazioni speciali in cui può essere utile inserire intenzionalmente bug nel codice di produzione in modo controllato e temporaneo.

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

È quindi possibile rompere intenzionalmente il codice di produzione per verificare se i test funzionano ancora.

Esistono più livelli su cui è possibile:

• Uno sviluppatore che ha appena eseguito il refactoring di un test unitario potrebbe violare il codice di produzione per verificare che il test unitario trovi ancora quello che dovrebbe trovare.
• Un tester che ha appena eseguito il refactoring di un test di collaudo potrebbe violare il codice di produzione per verificare che il test di collaudo verifichi ancora ciò che dovrebbe verificare.
• Se l'interfaccia è abbastanza stabile e robusta (ovvero basata su protocollo), l'azienda potrebbe voler mantenere una suite di versioni di prodotto difettose note ed eseguire test contro di esse al fine di testare la regressione del test.

Se queste cose abbiano un senso dipende. Se sono uno sviluppatore e mi ci vuole solo un minuto per iniettare un bug, testare l'unità test, rimuovere il bug - allora perché no. Ma dovrei avere il mio editor, il mio ciclo e il mio sistema di controllo della versione sotto un controllo talmente buono da non commettere / consegnare / fare il check-in / spingere accidentalmente il bug. Lo stesso vale per il tester e il test di collaudo.

Se ha senso per un'organizzazione mantenere suite di versioni di prodotto difettose e test di regressione noti, il test dipende. Per un negozio online non lo farei. Vorrei utilizzare le carte bancarie per il settore automobilistico, aerospaziale, bancario o pay TV.

Quanto impegno dipende fortemente da quanto sono disaccoppiati i test dal codice di produzione. Più i test sono disaccoppiati dal codice di produzione, minore è lo sforzo per farlo, più coerenti sono i test con il codice di produzione, maggiore è 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ò spezzerebbe la dipendenza tra i test e i campioni di produzione difettosi. Dovresti quindi conservare anche i campioni di produzione difettosi. In rari casi anche questo può valere la pena, e il deridere e l'uso intelligente di un sistema di controllo della versione possono ridurre significativamente lo sforzo, ma richiede sviluppatori ben al di sopra.

Il concetto di iniettare intenzionalmente guasti nel codice di produzione si chiama sabotaggio , l'errore iniettato si chiama sabotatore .

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

Uno sviluppatore che sta eseguendo il check - in del codice noto nel repository sta eseguendo un errore. (2)

Quindi, in questa fase, non esiste già alcun modo per far funzionare questo schema senza che una o entrambe le parti violino le premesse basilari di come dovrebbero essere fatti lo sviluppo e i test.

(1) Perché è necessario documentare quale versione è stata testata. Una versione taggata da un hash Git o da 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 driver di test che prevede errori.

Questo è un tentativo di una ragione più breve possibile, "ascensore pitch", che dovrebbe avere un senso immediato sia per gli sviluppatori che per i tester e la gestione.

Sconsiglio di iniettare deliberatamente bug in OGNI build che invii al QA.

Di tanto in tanto, potremmo dire una volta all'anno, un "audit di controllo qualità" nascosto. Prendi una base di codice "testata e funzionante" e quante più piccole nuove funzionalità dal tuo elenco Todo possibile. Implementali "un po 'più sciatti" di quanto fai di solito. Pensa ai casi limite, scrivili, ma non correggere il codice per tenerli in considerazione. Invialo al QA.

Se trovano più bug non funzionanti di quelli che hai scritto, non è certo il tuo QA che necessita di supervisione ... ;-)