Laisser des bogues intentionnels dans le code pour que les testeurs les trouvent
Nous ne faisons pas cela dans notre entreprise, mais l'un de mes amis dit que son chef de projet a demandé à chaque développeur d'ajouter des bugs intentionnels juste avant que le produit passe en QA. Voilà comment cela fonctionne:
- Juste avant que le produit passe en QA, l'équipe de développement ajoute quelques bogues intentionnels à des endroits aléatoires dans le code. Ils sauvegardent correctement le code de travail d'origine pour s'assurer que ces bogues ne sont pas livrés avec le produit final.
- Les testeurs en sont également informés. Ils vont donc tester dur, car ils savent qu'il y a des bogues présents et que ne pas les trouver pourrait être considéré comme un signe d'incompétence.
- Si un bogue (intentionnel ou autre) a été trouvé, il sera signalé à l'équipe de développement pour le corriger. L'équipe de développement ajoute ensuite un autre bogue intentionnel dans une section connexe du code juste avant que le produit passe au contrôle qualité de deuxième niveau. Le chef de projet dit qu'un testeur devrait penser comme un développeur et qu'il/elle devrait s'attendre à de nouveaux bogues dans les sections où des modifications ont été apportées.
Eh bien, c'est comme ça que ça se passe. Ils disent que cette approche présente les avantages suivants.
- Les testeurs seront toujours sur leurs gardes et ils testeront comme des fous. Cela les aide également à trouver des bogues cachés (non intentionnels) afin que les développeurs puissent les corriger.
- Les testeurs se nourrissent de bugs. Ne pas trouver de bugs affectera leur moral. Donc, leur en donner un facile à trouver aidera leur moral.
Si vous ignorez le scénario où l'un de ces bogues intentionnels est livré avec le produit final, quels sont les autres inconvénients que nous devrions considérer avant même de penser à adopter cette approche?
Quelques clarifications:
- Ils sauvegardent correctement le code d'origine dans le contrôle de code source.
- Lorsqu'un testeur trouve le bogue intentionnel, l'équipe de développement l'ignore. Si le testeur découvre un bogue involontaire (d'origine), l'équipe de développement vérifie d'abord s'il est causé par l'un des bogues intentionnels. Autrement dit, l'équipe de développement essaie d'abord de reproduire cela sur le code de travail d'origine et essaie de le corriger si elle le peut.
- Ignorez simplement les problèmes de relation entre l'AQ et l'équipe de développement. J'ai spécifiquement posé cette question sur Programmeurs, pas sur The Workplace. Considérez qu'il existe de bonnes relations entre l'AQ et l'équipe de développement, et ils font la fête ensemble après les heures de travail. Le chef de projet est un gentilhomme gentil, toujours prêt à soutenir les deux équipes (Godsend).
Cela semble absolument fou. Cela demande beaucoup d'efforts pour des avantages très discutables, et la pratique semble basée sur des prémisses erronées:
Que l'AQ ne fonctionnera pas dur à moins qu'ils sachent qu'ils sont testés tous les jours (ce qui ne peut pas être bon pour le moral)
Qu'il n'y a pas assez de bogues introduits involontairement dans le logiciel pour que QA les trouve
Le travail de QA est de trouver des bugs - ce n'est pas le cas; c'est pour assurer la qualité de production du logiciel
Que ce genre de bataille d'esprit entre le développement et l'AQ est en quelque sorte sain pour l'entreprise - ce n'est pas le cas; tous les employés devraient travailler ensemble contre les concurrents de l'entreprise plutôt que les uns contre les autres.
C'est une idée terrible et le chef de projet en question est un idiot/idiot qui ne comprend rien aux gens et à la motivation. Et c'est mauvais pour les affaires.
Pour développer ma description du "travail de QA:" QA devrait certainement trouver des bogues - à la fois dans le code et dans leurs suites de tests - comme un artefact de faire leur travail, mais le rôle ne doit pas être défini comme "vous devez trouver Bugs." Cela devrait être "vous devez maintenir les suites de tests à jour pour tenir compte des nouvelles fonctionnalités et assurer une couverture élevée des tests. Si cela ne donne pas lieu à la recherche de bogues, alors les procédures de test ne sont pas suffisamment sophistiquées pour le produit.
Eh bien, d'après ce que j'ai appris:
- Ce n'est pas une école ni un entretien d'embauche;
- Les testeurs ne sont pas des enfants;
- Ce n'est pas un jeu;
- Cela gaspille l'argent de l'entreprise.
Les QA ne sont pas là uniquement pour trouver bugs mais aussi pour se soucier de la façon dont intuitif est le système, quelle est la courbe d'apprentissage pour l'utilisateur, tilisabilité, et accessibilité en général. Par exemple: "Le système est-il moche?", "L'utilisateur est-il daltonien et tout est rouge et vert?" Ils devraient aussi se plaindre.
Les exigences minimales pour qu'un système réussisse l'AQ sont généralement décrites dans une histoire d'utilisateur pour cette fonctionnalité particulière ou dans la magie du PO voulait que le système soit dans sa tête.
tl; dr
Ce ne sont pas seulement des bugs, les testeurs devraient sortir de cette vue étroite.
Mauvaise idée.
Du point de vue du testeur: "Donc, ils vont tester dur, car ils savent qu'il y a des bogues et ne pas les trouver pourrait être considéré comme leur incompétence." Fondamentalement, les développeurs piègent le code. Peu de gens aiment faire un travail qui est finalement inutile (car les bugs sont connus à l'avance) mais qui affectent encore leur perception. S'il existe des sanctions tangibles pour ne pas avoir trouvé les pièges, plus encore. Et savez-vous que les testeurs réussissent à trouver des bogues? Cela ressemble à un environnement de confrontation toxique; un QA devrait être satisfait si le code qu'il examine est de haute qualité. Bien que s'ils sont payés par le bug ... http://thedailywtf.com/articles/The-Defect-Black-Market
Du point de vue du développeur: les QA sont incités à trouver les bogues que vous connaissez. Cela pourrait bien augmenter la probabilité que de vrais bogues sortent de la porte; les QA passent au moins une partie de leur temps à chercher le type de bug facile à planter, pas vraiment subtil. De plus, il y a une petite chance qu'un piège puisse sortir de la porte.
Je suis totalement d'accord avec les réponses ci-dessus pour expliquer pourquoi cela est mauvais pour la motivation et la gestion des gens généralement horrible. Cependant, il existe probablement de bonnes raisons techniques de ne pas le faire également:
Juste avant que le produit passe en QA, l'équipe de développement ajoute des bogues intentionnels à des endroits aléatoires dans le code. Ils sauvegardent correctement le code de travail d'origine pour s'assurer que ces bogues ne sont pas livrés avec le produit final.
Sur la base de la première déclaration, vous jamais testez réellement votre code de production prévu dans ces deux passes.
J'imagine que vous augmentez considérablement la probabilité d'inclure accidentellement un bogue "intentionnel" dans votre code de production publié lorsque vous essayez de vous précipiter à travers un changement pour un client. Peut causer quelques joues rouges à un moment donné.
J'imagine que cela forme simplement vos testeurs à penser comme vos développeurs (c'est-à-dire comment Tom ajouterait-il un bogue ici), ce qui les rend probablement moins susceptibles de trouver les bogues auxquels Tom n'a pas pensé.
Modifier
Je veux être clair que cette réponse ne parle que du concept de test de votre processus d'AQ, et je ne défends pas la méthodologie spécifique présentée dans la question.
Fin de l'édition
Il y a une raison valable de vérifier si votre test/vérification fonctionne réellement. Permettez-moi de vous donner un exemple de fabrication, mais le principe est le même.
Il est typique lors de l'alimentation de matériel à travers une machine que le chargeur ne puisse pas pousser le matériau suffisamment loin. C'est ce qu'on appelle une "alimentation courte" et pour éviter cela, nous pourrions installer un "capteur d'alimentation courte" (généralement un capteur de type barrage qui est bloqué par le matériau). Ce capteur détecte l'extrémité du matériau lorsqu'il atteint la pleine longueur d'alimentation. À un certain moment du cycle de la machine, nous vérifions que le capteur est bloqué et arrêtons la machine si la vérification échoue.
Maintenant, vous devez penser à la façon dont le test lui-même peut échouer. Par exemple, de la saleté ou d'autres débris peuvent bloquer le capteur et il signalera toujours "OK" et n'arrêtera jamais la machine. En outre, la nature du capteur est que le récepteur s'allume lorsque le faisceau le frappe, donc selon le type de capteur que vous avez installé, vous obtenez électriquement une entrée "ON" lorsque le capteur est non bloqué . Cela signifie que si le câble a été coupé ou que l'alimentation de ce capteur a été coupée, ou que l'entrée a échoué, la logique de votre programme indiquerait "OFF" et cela signifierait "bloqué" ou "OK".
Pour capturer ces modes de défaillance du test, nous insérons généralement une deuxième vérification pour nous assurer que le capteur est réellement débloqué pendant une deuxième partie du cycle. De cette façon, nous vérifions que le test fonctionne toujours (du mieux que nous pouvons).
De la même manière, un service d'assurance qualité peut échouer de plusieurs manières. Les tests automatisés n'ont peut-être pas été exécutés et le rapport examine une ancienne copie des données de test. Peut-être que quelqu'un ne fait pas bien son travail. Tester le département AQ est une chose raisonnable à faire.
De toute évidence, l'inconvénient est qu'un "bogue de test" pourrait passer par le département QA et dans le produit fini. Dans l'industrie manufacturière, il y a parfois des cas où une mauvaise pièce connue, parfois appelée "lapin rouge", est insérée dans le processus (généralement par une personne de l'assurance qualité) et ils regardent cette partie passer par le processus et mesurer le temps qu'il faut pour trouver la pièce et la retirer. Normalement, cette partie est peinte en rouge vif (ou orange) afin de pouvoir être facilement suivie. Étant donné que quelqu'un regarde le processus de passage de la pièce au cours de ce test, la probabilité qu'il en fasse le produit final est pratiquement nulle. Il y a, bien sûr, des histoires apocryphes de quelqu'un qui jette une mauvaise partie connue dans le processus pour "voir si le système peut la trouver", et bien sûr avoir à mettre en quarantaine toutes les pièces finales produites ce jour-là et à les trier manuellement, mais c'est juste un cas de non-réalisation de votre test avec une diligence raisonnable.
Honnêtement, j'appellerais ce comportement manifestement contraire à l'éthique et peu pratique. Le PM a besoin d'une sérieuse reconversion, sinon d'une résiliation.
- Cela démontre un manque fondamental de compréhension du concept d'assurance qualité. Les testeurs ne devraient pas penser comme les développeurs: ils devraient penser comme les utilisateurs finaux. La raison d'être des équipes QA est que les développeurs sont intrinsèquement trop proches du code; Le contrôle qualité est censé maintenir une distance suffisante par rapport au code pour pouvoir capturer ce que les développeurs manquent.
- Cela gaspille l'effort d'AQ. En supposant que ces bogues ne sont pas insignifiants - voir ci-dessous pour quand ils le sont - cela signifie que le contrôle qualité passe du temps et des ressources à enquêter sur des choses déjà connues, alors qu'il pourrait consacrer cet effort à rechercher ce qui n'est pas connu.
- Cela gaspille l'effort du développeur. Pour que les gens d'AQ puissent détecter ces bogues non triviaux, les développeurs doivent d'abord les écrire. Cela nécessite des efforts supplémentaires, dépensés non seulement pour coder les bogues, mais aussi pour prendre en compte les exigences et la conception du logiciel.
- Cela met la production en danger inutile. Ce n'est qu'une question de temps avant que les modifications ne soient fusionnées correctement.
- S'il ne fait pas ce qui précède, alors c'est inutile. Si tous les bogues connus sont triviaux, ils n'attraperont pas les travailleurs de qualité inférieure: ils n'attraperont que les personnes qui ne font aucun travail. Il y a de meilleures façons de le faire.
- Il empoisonne l'environnement de travail. Vos testeurs QA sont des professionnels. Il faut leur faire confiance pour être professionnel jusqu'à ce qu'il y ait une raison réelle de soupçonner le contraire. Quand il y a raison de soupçonner le contraire, il devrait y avoir une enquête appropriée au lieu de ces jeux d'esprit. Tout le reste tue le moral.
Sérieusement. Même si la paranoïa du Premier ministre se révèle bien fondée dans ce cas précis, ce n'est pas quelqu'un qui gère des testeurs.
Personnellement, je me sens mal à l'aise avec cette approche.
La principale chose qui me préoccupe est la possibilité d'insérer des bogues intentionnels. Cela me semble difficile à faire d'une manière prévisible.
Tout changement de code (intentionnel ou non) risque d'avoir des effets secondaires. Ces effets secondaires peuvent bien être révélés lors des tests, mais il peut ne pas être évident (même pour le développeur qui a planté le bogue) quelle est la cause première. Cela ne semble pas "sûr", si vous voyez ce que je veux dire (je parle de mon instinct ici).
De plus, le testeur perdra beaucoup de temps à tester le code qui ne sera pas réellement publié. Une fois les bogues intentionnels supprimés, un nouveau test complet devrait de toute façon être fait, à mon avis. C'est tout l'intérêt des tests. Quelque chose change, n'importe quoi , et vous re-testez tout . Ok Je sais que cela ne se produit jamais dans la pratique, mais c'est à cela que servent les tests de régression.
Donc, globalement, pas convaincu.
En revanche, nous avons tendance à laisser les clients vérifier le travail des équipes AQ, ce qui n'est peut-être pas idéal. Il s'agit d'une boucle de rétroaction très très puissante.
C'est une mauvaise idée pour toutes les raisons déjà données, mais l'ensemencement de bogues est un outil utile à des fins différentes. Vous pouvez l'utiliser pour obtenir une mesure approximative de l'efficacité du processus d'assurance qualité.
Dans son cas le plus simple, disons que vous générez 100 bogues et qu'ils sont représentatifs de la totalité des bogues réels (je sais, peu probable, mais je simplifie). Vous ne dites pas à QA que vous faites cela pour éviter de gâcher l'expérience. À la fin du processus d'assurance qualité, disons qu'ils ont trouvé 60 des 100 bogues prédéfinis (et d'autres vrais bogues). Vous savez maintenant que le contrôle qualité trouve 60% des bogues.
Vous pouvez étendre cela en comptant le nombre de bogues réels QA trouvés et appliquer le faux rapport de bogues. Dans notre exemple, si QA a trouvé 200 vrais bugs, vous pouvez conclure qu'ils n'en ont trouvé que 60%, il en reste donc 133.
Bien sûr, ce n'est qu'une estimation large avec d'énormes barres d'erreur. Il est difficile d'écrire des bugs réalistes et représentatifs. Les bogues que vous écrivez sont susceptibles d'être plus faciles pour QA à trouver parce que les développeurs sont formés pour ne pas écrire de bogues. Il peut être préférable de simuler une classe de bogues tels que les erreurs off-by-one, les erreurs Unicode, les débordements de tampon, etc.
Cela devrait être appliqué à l'ensemble de l'AQ processus qui comprendrait les tests unitaires des développeurs, l'intégration continue et, si disponible, une équipe QA dédiée.
Il s'agit d'un métrique, et ne doit pas être détourné en tant qu'outil de motivation de gestion.
Mauvaise idée.
C'est le genre d'approche logique et binaire que les développeurs apportent souvent, mais c'est démotivant pour les QE. Cela démontre simplement un manque de confiance. Les QE sont souvent placés dans ces situations sans grande contribution de leur part, et ils ont supposé qu'ils étaient d'accord avec cela, et ce n'est pas à eux de suggérer le contraire.
Ce type de réflexion se combine aux QEs qui ne sont que des testeurs manuels et ne sont pas motivés pour comprendre le code réel testé.
Je suis un QE senior et c'est un problème familier dans la plupart des organisations dans lesquelles j'ai travaillé.
Je dirais une mauvaise idée.
Un: les programmeurs vont passer du temps à mettre des bogues délibérés dans le code et à faire des efforts pour enregistrer la bonne version. Bien que les testeurs devraient probablement tester tout, y compris les fonctionnalités avec le bogue planté, lorsqu'ils en trouveront un, ils devront probablement revenir en arrière et réexécuter ce test pour vérifier qu'il s'agissait bien d'un bogue (et non pas que le testeur s'est trompé en quelque sorte). Au minimum, les testeurs vont passer du temps à écrire les bogues plantés. Ensuite, les programmeurs doivent passer du temps à corriger le bogue qu'ils ont planté. C'est beaucoup d'efforts qui pourraient être dépensés pour essayer d'écrire du bon code et d'écrire de vrais bugs.
Deux: Cela envoie un message clair aux testeurs que les programmeurs et/ou la direction pensent qu'ils ne font pas leur travail et doivent être traités comme des enfants. Je ne peux pas imaginer que c'est bon pour le moral. En tant que programmeur, si on me donnait des spécifications ambiguës ou contradictoires pour un programme et que je devais passer beaucoup de temps à les clarifier, puis après avoir perdu des heures ou des jours, mon patron me disait: "Oh, oui, j'ai délibérément mis des déclarations contradictoires dans les spécifications juste pour vous assurer que vous les lisiez vraiment ", je pense que je serais vraiment ennuyé Si cela se produisait régulièrement, cela pourrait bien suffire à me faire chercher un autre emploi.
Dans la vraie vie, tous les changements de code sauf les plus triviaux auront des bugs. Je n'ai jamais eu de problème avec la complaisance des testeurs parce que le premier projet de code qui leur a été donné était souvent parfait à 100%. J'ai dû faire face à des testeurs paresseux qui ne font pas un travail adéquat, mais ils ne l'ont pas fait parce que les programmeurs étaient si parfaits. Le meilleur testeur avec qui j'ai jamais travaillé m'a dit une fois que pour une nouvelle version du logiciel, il s'était fixé un objectif personnel de trouver 100 bugs. D'accord, le fait que 100 soit un nombre réaliste dépend de la taille du produit et de l'ampleur des changements, mais dans notre cas, il a presque toujours réussi à atteindre cet objectif. Parfois, il devait étirer des choses, comme appeler un mot mal orthographié dans un message un "bug", mais bon, il fallait le corriger.
Post script: Si vous faites cela, je parie que tôt ou tard les programmeurs vont délibérément planter un bogue, les testeurs ne le trouvent pas en particulier et les programmeurs oublient de remettre le bon code. Alors maintenant, un bug délibérément planté est expédié au client.
Je ne pense pas vraiment que ce soit une mauvaise idée. Il y a juste beaucoup de choses qui, selon moi, fonctionneraient mieux:
Rendez l'AQ responsable de la qualité comme vous le pouvez. Par exemple, en faisant également supporter leur responsabilité. Cela augmentera leur motivation pour s'assurer que les produits expédiés sont de meilleure qualité. Il faut toujours moins d'efforts pour découvrir vous-même une insuffisance (bogue, fonctionnalité manifestement manquante, comportement contre-intuitif), puis pour comprendre ce que votre utilisateur contrarié essaie d'expliquer. Et confier une partie de cette responsabilité aux développeurs peut augmenter leur motivation à aider le QA à faire son travail du mieux qu'il peut.
Avoir plusieurs équipes d'assurance qualité, qui peuvent rivaliser. Vous devez bien sûr trouver une métrique sensible. Certainement pas seulement le nombre de problèmes. La prise en compte de la gravité du défaut ou de la valeur commerciale (telle que déterminée par les parties prenantes) des améliorations proposées devrait aider.
Il est difficile de dire si l'AQ est "assez bonne". Il est plus facile et peut-être même mieux à long terme de trouver des moyens pour que l'AQ soit "en constante amélioration".
Pourtant, il y a un problème à savoir si vous introduisez des bogues intentionnels: Comment savez-vous que le code "correct" a jamais été correct en premier lieu? Après le 2e contrôle qualité, vous supprimez tous les bogues intentionnels qui n'avait pas été découvert. Il n'y a aucun moyen de savoir que vous ne les remplacez pas simplement par du code qui est cassé d'une manière différente ou que vous n'activez pas un comportement cassé qui était inaccessible auparavant (exemple exagéré: une boîte de dialogue ne s'est pas ouverte à cause d'un bogue intentionnel, mais la boîte de dialogue elle-même est rompue - vous ne le découvrez tout simplement pas parce que les testeurs n'ont pas pu le voir).
Comme d'autres l'ont dit, les développeurs ne devraient pas ajouter délibérément de bogues dans le logiciel, mais c'est une stratégie légitime pour votre suite de tests d'ajouter des bogues dans le logiciel dans le cadre du processus de test.
Cela s'appelle test de mutation . L'idée est d'utiliser un logiciel pour automatiser la création de petits changements dans le code source (appelés mutants). Les changements sont conçus pour créer un comportement différent, par exemple, nous pourrions changer
if x < 10:
print "X is small!"
dans
# we flipped the inequality operator
if x > 10:
print "X is small!"
et un bon test unitaire devrait détecter que le fragment de code mutant ne fonctionne plus comme prévu et tue le mutant. Lorsque le code d'origine réussit le test et que tous les mutants (qui ne sont pas fonctionnellement équivalents) échouent au test, alors vous savez que votre code et vos tests sont forts .
J'aime l'idée. Est-ce le général Patton qui a dit: "Plus vous transpirez en paix, moins vous saignez pendant la guerre."
Mettre des bogues intentionnels "fait perdre du temps" aux testeurs. Mais cela les oblige également à travailler plus dur, ce qui signifie qu'ils feront également un meilleur travail pour trouver les bogues involontaires. (Et vous avez une copie de l '"original" afin que vous n'ayez pas à vivre avec ce que vous avez fait.)
Trouver plus de bugs involontaires vous épargnera probablement plus de chagrin à long terme que le coût du traitement des bugs intentionnels.
De plus, vous pouvez avoir une idée de la qualité de vos testeurs, pas un petit avantage en soi.
Il n'y a aucune base pour une récompense ou une punition sur son propre mérite, mais sur le résultat du comportement que vous visez. Et parfois, il y a des conséquences inattendues. L'objectif est-il d'empêcher l'équipe de contrôle qualité de se relâcher ou de faire en sorte qu'un manager se sente réellement en train de contribuer quelque chose sans se rendre compte qu'il ne fait qu'empêcher.
Résultat positif - L'équipe AQ travaille plus fort pour trouver les bogues. Qui sait, peut-être voient-ils cela comme un défi. C'est un match amical. Ou ils le font simplement parce qu'ils sont surveillés (effet Hawthorne?).
Résultat négatif - Ils peuvent ne pas travailler plus dur et trouver le bogue de toute façon. QA considère cela comme mesquin et contradictoire. Alors maintenant, ils entrent dans la recherche d'hyper-bogues et retournent toutes sortes de petits problèmes difficiles. Cette police ne s'affiche pas correctement lorsque je prends une capture d'écran et la convertis en pdf et la visualise à 500%.
Aucun impact - un son comme celui-ci ne fait aucune différence, alors pourquoi s'embêter? Vous risquez simplement de perdre du temps et d'irriter les gens.
Nous pourrions tous convenir que cela ne fonctionnera pas dans 90% des cas. Cela ne fait pas beaucoup de bien aux 10% restants. Testez les choses par vous-même. Les clients sont-ils plus satisfaits d'une version contenant des bogues de code intentionnels? A-t-elle un impact sur le moral et la productivité des travailleurs dans d'autres domaines? Augmenter le chiffre d'affaires? Tu nous as dit.
Issu d'un monde où les développeurs sont censés écrire et exécuter les tests eux-mêmes, ce silo "testing" "QA" auquel vous faites référence me fait peur et me déroute, alors je vais essayer de répondre dans cette perspective. Soit dit en passant, les ingénieurs qualifiés en AQ, de mon point de vue (comme cela est bien décrit dans la réponse de @ SparK), devraient se concentrer sur les questions plus larges de s'assurer que le logiciel satisfait pleinement les histoires d'utilisateurs et a une "qualité" globale (en ce qui concerne le domaine auquel le logiciel est destiné), au lieu de rechercher des bogues.
Ce qui m'a attiré ici, c'est la mention de @ JamesMcleod de "l'injection de défauts" dans les commentaires à la question. Je pense en fait qu'avoir les développeurs pensent comment ils pourraient injecter des bogues dans le système est une excellente idée pour cibler le concept de défense en profondeur. Aucun bogue ne devrait jamais être suffisant pour faire tomber l'ensemble du système de manière incontrôlée (sans journalisation claire et exploitable), provoquer une corruption des données ou exposer par lui-même une vulnérabilité de sécurité.
Le fait que les développeurs de chaque composant créent des défauts intentionnels, gèrent ceux des autres composants et, dans l'ensemble, adoptent un état d'esprit plus accusatoire à propos de leur logiciel pourrait peut-être faire beaucoup pour améliorer la robustesse du logiciel. Même l'avantage immédiat pourrait être significatif - j'exigerais que lors de chaque injection d'un nouveau type de défaut (qui n'a pas été testé jusqu'à présent), le développeur le couvre immédiatement par un nouveau test, qui sera défini avec un indicateur qui permettre au bogue de vivre dans la base de code sans être dérangé pendant un court moment, puis allumé avant la livraison (et le défaut supprimé), pour se transformer en un test régulier qui rendra la suite de tests plus complète.
Une option connexe est l'utilisation d'indicateurs de fonctionnalité pour désactiver intentionnellement des fonctionnalités dans des composants particuliers afin d'examiner comment d'autres composants gèrent cela. Je voudrais également recommander fortement de lire le livre/article gratuit "Apprendre des premiers intervenants: quand vos systèmes doivent fonctionner" qui décrit des tests aussi approfondis de l'infrastructure logicielle à utiliser par l'équipe Obama pour la Élection de 2012.
Comme d'autres l'ont déjà dit, ce n'est pas le travail de QA de trouver uniquement des bugs. J'irais plus loin et dirais que ce n'est pas du tout leur travail, techniquement. Les développeurs devraient être responsables de garder leur propre code exempt de bogues. Les suites de tests doivent être exécutées avant que le nouveau code ne soit même validé, et si les suites de tests échouent, elles ne devraient jamais arriver en QA en premier lieu. Introduire des bogues intentionnellement signifie que vous ne pouvez certainement pas passer vos suites de tests, alors pourquoi votre code passe-t-il à l'AQ?
Le travail de QA est de valider l'application par rapport aux user stories qu'elle implémente. Ils doivent tester le flux, l'interface utilisateur, etc. et s'assurer que l'utilisateur peut faire tout ce qu'il devrait être en mesure de faire de la manière la plus utilisable et accessible possible. En faisant cela, bien sûr, ils peuvent tomber sur des bugs, mais c'est un effet secondaire de ce qu'ils font, pas de ce qu'ils font. N'oubliez pas que l'assurance qualité signifie assurance qualité, et non sans bug.
Une chose que personne d'autre n'a encore mentionnée: test de mutation .
C'est là qu'un outil automatisé prend votre code source et y insère délibérément des bogues. (Par exemple, supprimez une instruction choisie au hasard, changez un ET en OU, ou quoi que ce soit.) Il exécute ensuite votre suite de tests complète et vérifie si les tests réussissent.
Si tous les tests réussissent, il y a deux possibilités:
- La chose qui a été changée ne fait rien. En d'autres termes, vous avez un code mort.
- La modification a introduit un bogue que votre suite de tests n'attrape pas. Vous avez besoin de plus de tests.
Notez que, contrairement à votre proposition, tout ce que j'ai décrit ci-dessus est automatisé . Vous ne perdez pas le temps des développeurs à insérer manuellement des bogues inutiles. Et vous ne perdez pas le temps des testeurs à trouver des bogues connus. La seule chose que vous utilisez est le temps machine, qui est beaucoup moins cher. (Les machines ne s'ennuient pas de faire le même test 20 000 fois. Les humains cessent de s'en soucier après un certain temps!)
Je dirais que le test de mutation automatisé est une approche bien meilleure que le scénario manuel dont vous parlez.
Notez que si vous demandez à un développeur d'insérer manuellement des bogues, le type de bogue que vous obtenez n'est probablement pas représentatif du type d'erreurs accidentelles que les humains pourraient commettre. (Par exemple, si vous ne vous êtes pas rendu compte qu'il existe une condition de concurrence possible, il est peu probable que vous en insériez une non plus délibérée.) Il reste à voir, bien sûr, si un outil automatisé parvient à être plus objectif.
Ce n'est pas nécessairement aussi fou que cela puisse paraître. Cela dépend plutôt de votre motivation. Si vous cherchez un bâton pour battre votre équipe de test, bien que serait fou. D'un autre côté, l'une des choses les plus difficiles dans le développement de logiciels est de savoir à quel point votre approche de test est efficace.
Donc, si vous le structurez correctement, vous pouvez utiliser cette technique pour estimer combien de bogues non trouvés restent dans le produit que vous êtes sur le point d'expédier. Imaginez donc que vous avez semé artificiellement 100 bogues dans votre build de test, et les testeurs en trouvent 50. Ensuite, vous pouvez déduire qu'il y a une certaine probabilité que s'ils trouvent également 50 bogues non ensemencés, il en reste peut-être 50 à trouver.
Bien sûr, cela pose de nombreux problèmes. Vous pouvez décider d'expédier sur la base de ces statistiques, mais dans la vraie vie, vous pouvez trouver un problème très désagréable ou mille irritations mineures.
Pourtant - la connaissance c'est le pouvoir, et sans cette technique, vous avez encore moins d'idée sur la qualité de votre base de code. Si vous pouvez le mettre en œuvre avec respect et pour les bonnes raisons, je dirais "Pourquoi pas?"
Bien que ce soit une mauvaise idée en général (les autres réponses expliquent parfaitement pourquoi), il existe quelques situations spéciales où l'injection intentionnelle de bogues dans le code de production de manière contrôlée et temporaire peut avoir un sens.
Lorsque vous refactorisez le code de test - et vous devriez, le code de test mérite la même attention aux détails que le code de production - vous voudrez peut-être savoir si le code de test trouve toujours les bogues qu'il est censé trouver.
Vous pouvez alors intentionnellement casser le code de production afin de vérifier si les tests fonctionnent toujours.
Il existe plusieurs niveaux sur lesquels cela est possible:
- Un développeur qui vient de refactoriser un test unitaire peut casser le code de production pour vérifier que le test unitaire trouve toujours ce qu'il est censé trouver.
- Un testeur qui vient de refactoriser un test d'acceptation peut casser le code de production pour vérifier que le test d'acceptation vérifie toujours ce qu'il est censé vérifier.
- Si l'interface est suffisamment stable et robuste (c'est-à-dire basée sur un protocole), l'entreprise peut vouloir conserver une suite de versions de produits défectueuses connues et exécuter des tests par rapport à celles-ci afin de tester le test de régression.
Que ces choses aient du sens dépend. Si je suis développeur et que cela ne me prend qu'une minute pour injecter un bug, tester le test unitaire, supprimer le bug - alors pourquoi pas. Mais je devrais avoir mon éditeur, mon cycle et mon système de contrôle de version sous un si bon contrôle que je ne commettrais/délivrer/archiverais/ne pousserais pas le bogue accidentellement. Il en va de même pour le testeur et le test d'acceptation.
Qu'il soit judicieux pour une organisation de conserver des suites de versions de produits défectueuses connues et de tester la régression, le test dépend. Pour une boutique en ligne, je ne le ferais pas. Pour l'automobile embarquée, l'aérospatiale embarquée, les cartes bancaires ou les cartes de télévision payante, je le ferais.
L'effort requis dépend fortement du degré de découplage entre les tests et le code de production. Plus les tests sont découplés du code de production, moins il y a d'effort pour le faire, plus les tests sont cohérents avec le code de production, plus l'effort est important.
La raison en est simplement la suivante: lorsque vos tests et votre code de production sont cohérents, changer le code de production nécessite de changer souvent les tests, ce qui romprait la dépendance entre les tests et les échantillons de production défectueux. Vous devrez alors également gérer les échantillons de production défectueux. Dans de rares cas, même cela peut valoir la peine, et la moquerie ainsi que l'utilisation intelligente d'un système de contrôle de version peuvent réduire considérablement l'effort, mais cela nécessite des développeurs qualifiés bien au-dessus.
Le concept d'injection intentionnelle de défauts dans le code de production est appelé Sabotage, le défaut injecté est appelé saboteur.
n testeur qui ne prend pas le code à tester directement à partir du référentiel le fait mal. (1)
n développeur qui vérifie le code défectueux connu dans le référentiel fait mal. (2)
Donc, à ce stade, il n'y a déjà aucun moyen pour que ce schéma fonctionne sans que l'une ou les deux parties ne violent les principes de base de la façon dont le développement et les tests doivent être effectués.
(1) Parce que vous devez documenter la version que vous avez testée. Une version étiquetée par un hachage Git ou un numéro de révision SVN est quelque chose que vous pouvez tester, "le code que Joe m'a donné" ne l'est pas.
(2) Parce que vous ne le faites pas, en dehors d'un pilote de test qui attend une défaillance .
Il s'agit d'une tentative d'une raison la plus courte possible de "hauteur d'ascenseur" qui devrait avoir un sens immédiat pour les développeurs, les testeurs et la direction.
Je déconseille d'injecter délibérément des bogues dans CHAQUE build que vous envoyez au QA.
Vous pourriez, de temps en temps, disons une fois par an, faire un "audit QA" secret. Prenez une base de code "testée et fonctionnelle" et autant de petites nouvelles fonctionnalités de votre liste Todo que possible. Mettez-les en œuvre "un peu plus négligemment" que d'habitude. Pensez aux cas Edge, notez-les, mais ne corrigez pas votre code pour en tenir compte. Envoyez-le à QA.
S'ils trouvent plus de bogues de cas Edge qui ne fonctionnent pas que ce que vous avez noté, ce n'est certainement pas votre QA qui a besoin de supervision ... ;-)