La creazione di un sistema completamente duplicato per la garanzia della qualità (QA) di un'altra pratica errata?

Question

La creazione di un sistema completamente duplicato per la garanzia della qualità (QA) di un'altra pratica errata?

#1 da (5 voti)
#2 da (3 voti)
#3 da (2 voti)

11

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

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

System_B(IN) -> O_B .

Quindi facciamo lo stesso per System_A per generare le proprie uscite, O_A:

System_A(IN) -> O_A .

In qualsiasi momento, si presume che O_B sia l'output previsto e O_A è l'output osservato / effettivo. Implicito è che O_B è la fonte "d'oro" (la verità). Tuttavia, abbiamo incontrato 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 è sbagliato

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) sbagliato nell'ispezione e nell'analisi umana. Le cose passeranno il QA usando questo processo, e gli utenti reali si lamenteranno, e torniamo a cercare che O_B fosse sbagliato dopotutto.

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

E la pista scivolosa? Quindi, non possiamo sostenere che abbiamo bisogno di un altro sistema per testare il "sistema di test"?
Il costo è decisamente proibitivo, poiché gli sviluppatori ora hanno bisogno di apprendere almeno 2 basi di codice, con forse la complessità di System_B più grande di System_A. Come potremmo quantificare quanto bene o male avere System_B intorno all'organizzazione?
Uno dei motivi "convincenti" originali per creare System_B era di "automatizzare" i test. Ora siamo molto orgogliosi di essere completamente automatizzati (perché 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 è completamente automatizzato? È sufficiente questa ragione 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? Per questo, nessuno al lavoro è in grado di fornire una risposta soddisfacente.

Qualche consiglio su questo argomento è apprezzato.

testing unit-testing qa integration-testing acceptance-testing

posta Jane Wayne 09.12.2016 - 04:58

fonte

3 risposte

Leggi altre domande sui tag testing unit-testing qa integration-testing acceptance-testing

Efficienza memoria Haskell - qual è l'approccio migliore? Come faccio a passare i dati in modo orientato agli oggetti in PHP?

score 5 · Answer 1

O_A is wrong, O_B is right

Correzione A

O_A is right, O_B is wrong

Correzione B

O_A is right, O_B is right

Speriamo che siano d'accordo.

O_A is wrong, O_B is wrong

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

Nessun processo cattura tutto. Certo, hai raddoppiato il tuo codice ma pensalo come il 2 in O (2n). Il controllo automatico della qualità fino ai test di integrazione è una cosa meravigliosa. Il test manuale è un trascinamento per l'innovazione. Soprattutto sui cambiamenti trasversali che richiederebbero un test completo. Inoltre, dal momento che i programmatori avranno implementato la stessa cosa, puoi farli gareggiare.

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

The question is this: is it a bad practice to create a "test system" to test the real system?

Se lo è, allora tutti i test sono pessimi.

What about the slippery slope? Then, can't we argue we need yet another system to test the "test system"?

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

The cost is definitely prohibitive, as developers now need to learn at least 2 code bases, with perhaps System_B's complexity larger than System_A. How would we quantify how good or bad having System_B around is to the organization?

Per il numero di clienti soddisfatti che ci pagano per giocare con le armi nucleari. Ti sei liberato del costo del test manuale. Hai creato qualcosa la cui utilità verrà dimostrata ogni volta che un bug viene catturato da esso. I bug sono stati colti in anticipo molto meno di quelli segnalati in ritardo.

One of the original "compelling" reasons to create System_B was to "automate" testing. Now we are very proud that we are fully automated (because System_B generates the input to bootstrap the process of using itself to also generate the output). But I think we've done more harm and introduced more complexity, in an unquantifiable way. Is the job of QA to be fully automated? Is that reason enough to justify to create a parallel system?

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

My real concern is this, even though we all know System_B is wrong (quite often). If System_B is so good at processing the input and its output is the gold source, why not replace System_A with System_B? To that, no one at work is able to provide a satisfactory response.

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

Suppongo che tu abbia inteso che System_A è spesso sbagliato. Non importa quale sia il più sbagliato. Qualunque cosa sia sbagliata è quella che ha bisogno di lavoro. Questi sistemi non decidono il bene e il male, lo fanno gli sviluppatori. Quello che fa il test è produrre un disagio che significa che qualcosa non è giusto. Gli sviluppatori capiscono di cosa si tratta. Ricorda, non c'è nessun gold standard che viene prodotto qui. C'è solo accordo o disaccordo. Il disaccordo richiede che il lavoro debba essere fatto. Parte di quel lavoro è capire dove.

score 3 · Answer 2

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

Questo vale doppiamente se il tuo sistema è di importanza critica e deve essere disponibile 24 ore su 24, 7 giorni su 7. Non è quindi possibile affibbiare il lusso di non disporre di un sistema di controllo qualità, in quanto è necessario ridurre al minimo i tempi di inattività del sistema di produzione. E se si tratta di un sistema 24/7, quindi la replica esatta del sistema di produzione è una raccomandazione molto, molto strong.

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

Di solito è possibile trovare un certo equilibrio ridimensionando alcuni componenti del sistema di controllo della qualità relativi al sistema di produzione, in modo che la maggior parte delle funzionalità possa essere testata correttamente. Di solito sono 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, e quindi è un incubo riprodurre il problema e implementare la correzione mantenendo tempi di inattività minimi consentiti nel sistema di produzione.

score 2 · Answer 3

Ogni volta che provi un sistema devi sapere qual è il tuo risultato previsto.

Il problema con il fatto che un sistema genera questo risultato atteso è ovviamente "come faccio a 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 anche se hai davvero bisogno di un umano per interpretare i requisiti del sistema e produrre manualmente il risultato atteso. Se hai un sistema fallo e controlla solo le differenze, allora stai saltando il test.