La création d'un système complètement dupliqué pour l'assurance qualité (AQ) d'un autre est-elle une mauvaise pratique?

Au travail, nous avons un système assez compliqué. Appelons ce système, System_A. Notre équipe QA a créé un autre système, appelez ce système, System_B, pour tester System_A.

La façon dont System_B est utilisé est la suivante. Nous générons des entrées (en utilisant System_B lui-même), IN, traitons ces entrées en retour via System_B et générons des sorties, O_B. Le processus est donc le suivant:

System_B(IN) -> O_B.

On fait ensuite de même pour System_A pour générer ses propres sorties, O_A:

System_A(IN) -> O_A.

À tout moment, on suppose que O_B est la sortie attendue et O_A est la sortie observée / réelle. Implicite est que O_B est la source "d'or" (la vérité). Cependant, nous avons rencontré une combinaison de problèmes.

O_A a tort, O_B a raison
O_A a raison, O_B a raison
O_A est faux, O_B est faux
O_A a raison, O_B a tort

Qui détermine ce qui est juste si O_B est supposé avoir toujours raison (ou ce qui est attendu)? Eh bien, il s'avère que O_B a parfois (ou souvent) tort lors de l'inspection et de l'analyse humaines. Les choses passeront l'AQ en utilisant ce processus, et les vrais utilisateurs se plaindront, et nous revenons à la conclusion que O_B était mauvais après tout.

La question est la suivante: est-ce une mauvaise pratique de créer un "système de test" pour tester le vrai système?

Et la pente glissante? Alors, ne pouvons-nous pas affirmer que nous avons besoin d'un autre système pour tester le "système de test"?
Le coût est définitivement prohibitif, car les développeurs doivent maintenant apprendre au moins 2 bases de code, avec peut-être la complexité de System_B plus grande que System_A. Comment pourrions-nous quantifier le bien ou le mal d'avoir System_B dans l'organisation?
L'une des raisons «convaincantes» originales de créer System_B était «d'automatiser» les tests. Maintenant, nous sommes très fiers d'être entièrement automatisés (car System_B génère l'entrée pour amorcer le processus d'utilisation elle-même pour générer également la sortie). Mais je pense que nous avons fait plus de mal et introduit plus de complexité, d'une manière non quantifiable. Le travail d'AQ doit-il être entièrement automatisé? Est-ce une raison suffisante pour justifier la création d'un système parallèle?
Ma véritable préoccupation est la suivante, même si nous savons tous que System_B est erroné (assez souvent). Si System_B est si bon pour traiter l'entrée et sa sortie est la source d'or, pourquoi ne pas remplacer System_A par System_B? À cela, personne au travail n'est en mesure d'apporter une réponse satisfaisante.

Tout conseil sur cette question est apprécié.

— Jane Wayne
source

Vous avez oublié le système C: celui qui décide lequel a raison, si A et B ne sont pas d'accord.

— Robert Harvey

Plus sérieusement, la navette spatiale avait cinq ordinateurs de bord: 3 exécutant le logiciel de vol, un qui vérifiait qu'ils étaient tous d'accord et un cinquième exécutant un logiciel écrit en utilisant les mêmes spécifications mais un fournisseur différent, juste au cas où le impensable est arrivé. Que vous décidiez ou non de passer à ce niveau de rigueur dépend entièrement de vous, mais il existe un précédent.

— Robert Harvey

Vous savez une chose, c'est que chaque fois que System_A et System_B sont en désaccord, l'un d'eux a un bug. Cela vous aidera à trouver des bogues dans les deux systèmes. Si System_A est le seul "important", cela vous a aidé à trouver des bogues dans System_A, mais pas tous. C'est un peu la même idée derrière la vérification formelle.

— user253751

Quelque chose qui ne ressort pas clairement de votre question: les systèmes A et B exécutent-ils la même base de code ou des bases de code différentes? Si ces derniers, alors quand ils ne sont pas d'accord, vous devez les considérer tous les deux faux et identifier les raisons pour lesquelles ils ont donné des réponses différentes.

— kdgregory

Et quant à votre question réelle ("est-ce une mauvaise pratique"): uniquement s'il n'y a aucune raison de revérifier vos opérations. Et dans une utilisation commerciale typique, il n'y en a pas. Si vous utilisez la navette spatiale, comme l'a fait remarquer Robert Harvey, c'est le cas. Et il y a certaines applications, comme le trading d'actions ou les prévisions météorologiques, où vous pouvez avoir deux systèmes qui ne sont pas d'accord et ils sont tous les deux valides (sinon nécessairement "corrects").

— kdgregory

Réponses:

O_A a tort, O_B a raison

Fix A

O_A a raison, O_B a tort

Fix B

O_A a raison, O_B a raison

J'espère qu'ils sont également d'accord.

O_A est faux, O_B est faux

J'espère qu'ils ne sont pas d'accord, vous saurez donc faire quelque chose.

Aucun processus n'attrape tout. Bien sûr, vous avez doublé votre code, mais pensez-y comme le 2 en O (2n). Une assurance qualité automatisée jusqu'aux tests d'intégration est une chose merveilleuse. Les tests manuels sont un frein à l'innovation. Surtout sur les changements transversaux qui nécessiteraient un test complet. De plus, comme différents programmeurs implémenteront la même chose, vous pouvez les faire courir.

Il devrait y avoir différentes personnes pour augmenter les chances d'obtenir différents bogues. Je ne conseille pas de créer le système B en copiant à partir du système A. Tout ce qui vous donne est un test de régression. Vous pouvez obtenir la même chose simplement en enregistrant les anciennes copies d'O_A pour les comparer avec les nouvelles.

La question est la suivante: est-ce une mauvaise pratique de créer un "système de test" pour tester le vrai système?

Si c'est le cas, tous les tests sont mauvais.

Et la pente glissante? Alors, ne pouvons-nous pas affirmer que nous avons besoin d'un autre système pour tester le "système de test"?

Oui, nous pouvons en discuter. Nous appellerons ce 3ème système, system_A. : P

Le coût est définitivement prohibitif, car les développeurs doivent maintenant apprendre au moins 2 bases de code, avec peut-être la complexité de System_B plus grande que System_A. Comment pourrions-nous quantifier le bien ou le mal d'avoir System_B dans l'organisation?

Par le nombre de clients satisfaits qui nous paient pour jouer avec des pistolets nerf. Vous vous êtes libéré du coût des tests manuels. Vous avez créé quelque chose dont l'utilité sera prouvée chaque fois qu'un bogue est détecté. Les bogues détectés tôt coûtent beaucoup moins cher que les bogues signalés tardivement.

L'une des raisons «convaincantes» originales de créer System_B était «d'automatiser» les tests. Maintenant, nous sommes très fiers d'être entièrement automatisés (car System_B génère l'entrée pour amorcer le processus d'utilisation elle-même pour générer également la sortie). Mais je pense que nous avons fait plus de mal et introduit plus de complexité, d'une manière non quantifiable. Le travail d'AQ doit-il être entièrement automatisé? Est-ce une raison suffisante pour justifier la création d'un système parallèle?

La complexité de System_B est merveilleusement isolée de System_A. Il n'est pas plus difficile d'ajouter des fonctionnalités à System_A car System_B existe. C'est en fait plus facile car System_B leur donne la confiance d'aller vite.

Ma véritable préoccupation est la suivante, même si nous savons tous que System_B est erroné (assez souvent). Si System_B est si bon pour traiter l'entrée et sa sortie est la source d'or, pourquoi ne pas remplacer System_A par System_B? À cela, personne au travail n'est en mesure d'apporter une réponse satisfaisante.

Est-ce une faute de frappe? System_B se trompe souvent, c'est donc l'étalon-or que vous souhaitez utiliser pour remplacer System_A?

Je vais supposer que vous vouliez dire que System_A a souvent tort. Peu importe celui qui se trompe le plus souvent. Celui qui a tort est celui qui a besoin de travail. Ces systèmes ne décident pas du bien et du mal, les développeurs le font. Le test produit un désaccord qui signifie que quelque chose ne va pas. Les développeurs comprennent ce que c'est. N'oubliez pas qu'il n'y a pas d'étalon-or produit ici. Il n'y a qu'un accord ou un désaccord. Le désaccord exige que le travail soit fait. Une partie de ce travail consiste à déterminer où.

— candied_orange
source

Lorsque vous avez un système en production qui est réellement utilisé par les clients, avoir un système d'assurance qualité pour vérifier les corrections de bogues et les nouvelles fonctionnalités est un must absolu. Du point de vue de la qualité, il doit s'agir d'une réplique aussi proche que possible du système de production. De cette façon, si vous vous assurez que le système de production et son système d'assurance qualité sont identiques, ce qui fonctionne sur l'un devrait fonctionner sur l'autre. Si ce n'est pas le cas, alors les systèmes ne sont pas identiques, les entrées n'étaient pas identiques et / ou les sorties ont été mal interprétées.

Cela va d'autant plus si votre système est essentiel à la mission et doit être disponible 24/7. Vous ne pouvez alors pas vous offrir le luxe de ne pas avoir de système d'assurance qualité, car vous devez absolument minimiser les temps d'arrêt sur le système de production. Et s'il s'agit d'un système 24/7, la réplique exacte du système de production est une recommandation très, très forte.

Or, l'inconvénient évident de cette approche est le coût. Il double les coûts matériels et augmente les coûts de déploiement et de maintenance. De plus, une réplication continue des données du système de production vers l'AQ devrait être mise en œuvre, afin de minimiser la possibilité de résultats différents en raison de la différence des données avec lesquelles les systèmes fonctionnent.

Un certain équilibre peut généralement être trouvé en réduisant la taille de certains composants du système d'assurance qualité par rapport au système de production, de sorte que la plupart des fonctionnalités peuvent être correctement testées. Il s'agit généralement de serveurs redondants, de la taille des serveurs ou du nombre de postes de travail. Cependant, d'après mon expérience, certains bogues se trouvent toujours exactement dans la partie qui a été réduite, puis c'est un cauchemar de reproduire le problème et d'implémenter le correctif tout en maintenant le temps d'arrêt minimal autorisé dans le système de production.

— Vladimir Stokic
source

Chaque fois que vous testez un système, vous devez savoir quel est votre résultat attendu.

Le problème avec un système qui génère ce résultat attendu est évidemment «comment puis-je tester ce système»

Même ainsi, il n'est pas habituel de voir des gens utiliser des feuilles de calcul par exemple pour générer des ensembles de résultats attendus.

À la fin de la journée, vous avez vraiment besoin d'un humain pour interpréter les exigences du système et produire manuellement le résultat attendu. Si vous avez un système, faites-le et ne vérifiez que les différences, alors vous sautez vos tests.

— Ewan
source