Creare un sistema completamente duplicato per l'assicurazione della qualità (QA) di un altro è una cattiva pratica?

Al lavoro abbiamo un sistema abbastanza complicato. Chiamiamo questo sistema, System_A. Il nostro team di controllo qualità ha creato un altro sistema, chiama questo sistema, System_B, per testare System_A.

Il modo in cui viene utilizzato System_B è il seguente. Generiamo input (usando System_B stesso), IN, elaboriamo tali input attraverso System_B e generiamo output, O_B. Quindi il processo è il seguente:

System_B(IN) -> O_B.

Facciamo quindi lo stesso per System_A per generare i propri output, O_A:

System_A(IN) -> O_A.

In qualsiasi momento, si presume che O_B sia l'output previsto e O_A sia l'output osservato / effettivo. È implicito che O_B è la fonte "d'oro" (la verità). Tuttavia, abbiamo riscontrato una combinazione di problemi.

• O_A è sbagliato, O_B è giusto
• O_A ha ragione, O_B ha ragione
• O_A è sbagliato, O_B è sbagliato
• O_A ha ragione, O_B è sbagliata

Chi determina cosa è giusto se si presume che O_B abbia sempre ragione (o cosa è previsto)? Bene, si scopre che O_B a volte (o spesso) sbaglia nell'ispezione e nell'analisi umana. Le cose passeranno il QA usando questo processo e gli utenti reali si lamenteranno, e torniamo a scoprire che O_B era sbagliato dopo tutto.

La domanda è questa: è una cattiva pratica creare un "sistema di test" per testare il sistema reale?

• E la pendenza scivolosa? Quindi, non possiamo sostenere che abbiamo bisogno di un altro sistema per testare il "sistema di test"?
• Il costo è decisamente proibitivo, poiché ora gli sviluppatori devono imparare almeno 2 basi di codice, con forse la complessità di System_B maggiore di System_A. Come potremmo quantificare quanto sia buono o cattivo avere System_B in giro per l'organizzazione?
• Uno dei motivi "convincenti" originali per creare System_B era "automatizzare" i test. Ora siamo molto orgogliosi di essere completamente automatizzati (poiché System_B genera l'input per avviare il processo di utilizzo di se stesso per generare anche l'output). Ma penso che abbiamo fatto più danni e introdotto più complessità, in modo non quantificabile. Il lavoro di QA deve essere completamente automatizzato? Questa ragione è sufficiente per giustificare la creazione di un sistema parallelo?
• La mia vera preoccupazione è questa, anche se sappiamo tutti che System_B è sbagliato (abbastanza spesso). Se System_B è così bravo nell'elaborare l'input e il suo output è la fonte d'oro, perché non sostituire System_A con System_B? A ciò, nessuno al lavoro è in grado di fornire una risposta soddisfacente.

Qualsiasi consiglio su questo problema è apprezzato.

• O_A è sbagliato, O_B è giusto

Correzione A

• O_A ha ragione, O_B è sbagliata

Correzione B

• O_A ha ragione, O_B ha ragione

Speriamo anche che siano d'accordo.

• O_A è sbagliato, O_B è sbagliato

Speriamo che non siano d'accordo, quindi saprai di fare qualcosa al riguardo.

Nessun processo prende tutto. Certo, hai raddoppiato il tuo codice ma pensalo come il 2 in O (2n). Il QA automatizzato fino ai test di integrazione è una cosa meravigliosa. Il test manuale è un freno all'innovazione. Soprattutto su cambiamenti trasversali che richiederebbero un test completo. Inoltre, poiché avrai programmatori diversi che implementano la stessa cosa, puoi farli correre.

Dovrebbero essere persone diverse ad aumentare le probabilità di ottenere diversi bug. Non consiglio di creare il sistema B copiando dal sistema A. Tutto ciò che ti dà è un test di regressione. Puoi ottenere la stessa cosa semplicemente salvando vecchie copie di O_A per confrontarle con quelle nuove.

La domanda è questa: è una cattiva pratica creare un "sistema di test" per testare il sistema reale?

In tal caso, tutti i test non sono corretti.

• E la pendenza scivolosa? Quindi, non possiamo sostenere che abbiamo bisogno di un altro sistema per testare il "sistema di test"?

Sì, possiamo discuterne. Chiameremo questo terzo sistema, system_A. : P

• Il costo è decisamente proibitivo, poiché ora gli sviluppatori devono imparare almeno 2 basi di codice, con forse la complessità di System_B maggiore di System_A. Come potremmo quantificare quanto sia buono o cattivo avere System_B in giro per l'organizzazione?

Dal numero di clienti felici che ci pagano per giocare con le armi da fuoco. Ti sei liberato del costo del test manuale. Hai creato qualcosa la cui utilità verrà dimostrata ogni volta che viene catturato da un bug. I bug rilevati in anticipo costano molto meno di quelli segnalati in ritardo.

• Uno dei motivi "convincenti" originali per creare System_B era "automatizzare" i test. Ora siamo molto orgogliosi di essere completamente automatizzati (poiché System_B genera l'input per avviare il processo di utilizzo di se stesso per generare anche l'output). Ma penso che abbiamo fatto più danni e introdotto più complessità, in modo non quantificabile. Il lavoro di QA deve essere completamente automatizzato? Questa ragione è sufficiente per giustificare la creazione di un sistema parallelo?

La complessità di System_B è meravigliosamente isolata da System_A. Non è più difficile aggiungere funzionalità a System_A perché System_B esiste. È infatti più semplice perché System_B dà loro la sicurezza di andare veloci.

• La mia vera preoccupazione è questa, anche se sappiamo tutti che System_B è sbagliato (abbastanza spesso). Se System_B è così bravo nell'elaborare l'input e il suo output è la fonte d'oro, perché non sostituire System_A con System_B? A ciò, nessuno al lavoro è in grado di fornire una risposta soddisfacente.

È un errore di battitura? System_B è abbastanza spesso sbagliato, quindi è il gold standard che si desidera utilizzare per sostituire System_A?

Suppongo che intendevi che System_A è spesso sbagliato. Non importa quale sia quello sbagliato più spesso. Qualunque sia uno sbagliato è quello che ha bisogno di lavoro. Questi sistemi non decidono giusto e sbagliato, lo fanno gli sviluppatori. Ciò che il test fa è produrre un disaccordo che significa che qualcosa non è giusto. Gli sviluppatori capiscono di cosa si tratta. Ricorda, non esiste un gold standard qui prodotto. C'è solo accordo o disaccordo. Il disaccordo esige che il lavoro debba essere svolto. Parte di quel lavoro è capire dove.

Quando si dispone di un sistema in produzione che viene effettivamente utilizzato dai clienti, è assolutamente necessario disporre di un sistema di controllo qualità per verificare le correzioni dei bug e le nuove funzionalità. Dal punto di vista della qualità, dovrebbe essere il più vicino possibile una replica del sistema di produzione. In questo modo, se si garantisce che il sistema di produzione e il suo sistema di controllo qualità sono identici, ciò che funziona su uno, dovrebbe funzionare sull'altro. In caso contrario, i sistemi non sono identici, gli ingressi non erano identici e / o le uscite sono state male interpretate.

Ciò vale doppiamente se il tuo sistema è di importanza critica e deve essere disponibile 24 ore su 24, 7 giorni su 7. Quindi non puoi offrire il lusso di non avere un sistema di controllo qualità, perché devi minimizzare assolutamente i tempi di inattività del sistema di produzione. E se si tratta di un sistema 24/7, la replica esatta del sistema di produzione è una raccomandazione molto, molto forte.

Ora, l'ovvio inconveniente di questo approccio è il costo. Raddoppia i costi dell'hardware e aumenta i costi di distribuzione e manutenzione. Inoltre, dovrebbe essere implementata una replica continua dei dati dal sistema di produzione al QA, in modo da ridurre al minimo la possibilità di risultati diversi a causa della differenza nei dati con cui funzionano i sistemi.

In genere è possibile trovare un certo equilibrio ridimensionando alcuni dei componenti del sistema di controllo qualità rispetto al sistema di produzione, in modo che la maggior parte delle funzionalità possano essere testate correttamente. Si tratta in genere di server ridondanti, dimensioni dei server o numero di workstation. Tuttavia, la mia esperienza è che alcuni bug si trovano sempre esattamente nella parte che è stata ridimensionata, quindi è un incubo riprodurre il problema e implementare la correzione mantenendo i tempi di inattività minimi consentiti nel sistema di produzione.

Ogni volta che testate un sistema dovete sapere qual è il risultato atteso.

Il problema di avere un sistema che genera questo risultato atteso è ovviamente "come testare quel sistema"

Anche così, non è normale vedere le persone usare fogli di calcolo, ad esempio, per generare serie di risultati attesi.

Alla fine della giornata, però, hai davvero bisogno di un essere umano per interpretare i requisiti del sistema e produrre manualmente il risultato atteso. Se hai un sistema fallo e controlla solo le differenze, stai saltando i test.