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é.
Réponses:
Fix A
Fix B
J'espère qu'ils sont également d'accord.
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.
Si c'est le cas, tous les tests sont mauvais.
Oui, nous pouvons en discuter. Nous appellerons ce 3ème système, system_A. : P
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.
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.
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ù.
la 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.
la 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.
la source