Aggiunta intenzionalmente di bug per valutare i processi di QA

Question

Come fai a sapere che il maggior numero possibile di bug è stato scoperto e risolto in un programma? Un paio di anni fa ho letto un documento sul debug (penso che fosse una sorta di HOWTO). Tra le altre cose, quel documento descrive una tecnica in cui il team di programmazione aggiunge deliberatamente dei bug nel codice e lo passa al team di controllo qualità. Il processo di controllo della qualità è considerato completato quando tutti i bug deliberatamente noti sono stati scoperti.

Purtroppo, non riesco a trovare questo documento, o uno simile con descrizione di questo trucco. Qualcuno può indicarmi un documento del genere?

EDIT

Per rendere Evgeny felice, mi permetta di parafrasare l'ultima frase del primo paragrafo:

"Il processo di QA non è completo prima di tutti i bug deliberate sono trovati"

Answer 1

Un nome per la tecnica è "Iniezione di guasti". Uno dei libri più vecchi sull'argomento è 'Software Fault Injection: Inoculating Programs Against Errors' di Jeffrey Voas e Gary McGraw.

Answer 2

Non ho mai visto un documento del genere, ma sarei diffidente nel dire che il processo di controllo qualità è "completo" solo perché sono stati trovati i bachi intenzionali. È un buon modo per assicurarti che il tuo team di controllo qualità non diventi troppo pigro, ma non puoi davvero assicurarti di aver eseguito il test su un numero sufficiente di test.

È fondamentalmente impossibile sapere che tutti i bug (o "quanti più bug possibili") sono stati scoperti. Tutto quello che puoi fare è seguire un approccio accurato e ben ponderato per provarci.

Answer 3

Di solito trovo che ci siano un sacco di bug per il controllo di qualità da trovare, senza dover iniettare quelli intenzionali! Preferirei che il mio team di QA continuasse a trovare bug che non avrei mai nemmeno immaginato potesse essere nel sistema.

Come Evgeny, sarei molto cauto nel chiamare il processo di QA completo quando è stata trovata una serie di bug noti. Preferisco utilizzare i criteri di uscita come:

• Tutte le funzionalità definite per questa versione sono state completate?
• Sono stati eseguiti tutti i test test pianificati?
• è il conteggio aperto bug entro i limiti accettati (ad esempio nessun bug di priorità critiche o alti, a meno di 10 bassi bug di priorità, ecc)