Laisser des bugs intentionnels dans le code pour que les testeurs puissent les trouver

Nous ne faisons pas cela dans notre entreprise, mais un de mes amis a dit que son chef de projet avait demandé à chaque développeur d’ajouter des bogues intentionnels juste avant que le produit ne passe au contrôle qualité. Voilà comment cela fonctionne:

1. Juste avant que le produit ne passe à l'assurance qualité, l'équipe de développement ajoute des bogues intentionnels à des emplacements aléatoires du 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.
2. Les testeurs sont également informés à ce sujet. Ils vont donc faire des tests difficiles, car ils savent qu'il existe des bugs et que ne pas les trouver peut être considéré comme un signe d'incompétence.
3. Si un bogue (intentionnel ou non) a été trouvé, il sera signalé à l'équipe de développement pour qu'il le corrige. L'équipe de développement ajoute ensuite un autre bogue intentionnel dans une section connexe du code juste avant que le produit ne passe au contrôle qualité de second niveau. Le responsable de projet indique qu'un testeur doit penser comme un développeur et qu'il doit s'attendre à de nouveaux bogues dans les sections où des modifications ont été apportées.

Eh bien, voici comment ça se passe. Ils disent que cette approche présente les avantages suivants.

1. 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.
2. Les testeurs se nourrissent de bugs. Ne pas trouver de bugs affectera leur moral. Donc, leur donner un facile à trouver aidera leur moral.

Si vous ignorez le scénario dans lequel l'un de ces bogues intentionnels est expédié avec le produit final, quels sont les autres inconvénients à prendre en compte avant même de penser à adopter cette approche?

Quelques clarifications:

1. Ils sauvegardent correctement le code d'origine dans le contrôle de source.
2. Lorsqu'un testeur trouve le bogue intentionnel, l'équipe de développement l'ignore. Si le testeur découvre un bogue non intentionnel (d'origine), l'équipe de développement vérifie d'abord s'il est causé par l'un des bogues intentionnels. En d’autres termes, l’équipe de développement essaie d’abord de reproduire cela dans le code de travail original et essaie de le réparer s’ils le peuvent.
3. Ignorez simplement les problèmes de relation entre l'AQ et l'équipe de développement. J'ai spécifiquement posé cette question sur les programmeurs , pas sur le lieu de travail . Considérez qu’il existe de bonnes relations entre l’AQ et l’équipe de développement, qui se retrouvent après les heures de travail. Le chef de projet est un gentil et vieux gentleman qui est toujours prêt à soutenir les deux équipes (Godsend).

Cela semble absolument noisette. Il déploie beaucoup d'efforts pour un bénéfice très discutable, et la pratique semble reposer sur des postulats erronés:

• Ce QA ne travaillera pas dur à moins qu'ils sachent qu'ils sont testés chaque jour (ce qui ne peut pas être bon pour le moral)

• Qu'il n'y ait pas assez de bugs introduits par inadvertance dans le logiciel pour que le contrôle qualité puisse trouver

• Le travail de QA est de trouver des bogues - ce n'est pas le cas. c'est pour s'assurer que le logiciel est de qualité de production

• Que ce genre de bataille d'esprit entre développement et assurance qualité 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 gestionnaire de projet en question est un imbécile / imbécile 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:", le QA devrait bien être de trouver des bogues - à la fois dans le code et dans leurs suites de tests - comme un artefact de leur travail, mais le rôle ne devrait pas être défini comme "vous devez trouver bogues." Cela devrait être "vous devez maintenir les suites de tests à jour pour prendre en compte les nouvelles fonctionnalités et assurer une couverture étendue des tests. Si cela ne permet pas de trouver des bogues, les procédures de test ne sont pas suffisamment sophistiquées pour le produit.

Eh bien, sur la base de ce que j'ai appris:

1. Ce n'est pas une école ni un entretien d'embauche;
2. Les testeurs ne sont pas des enfants.
3. Ce n'est pas un jeu
4. Cela gaspille l'argent de l'entreprise.

Le groupe d’assurance-qualité n’est pas seulement là pour trouver des bogues, mais aussi pour s’inquiéter du caractère intuitif du système, de la courbe d’apprentissage pour l’utilisateur, de la convivialité et de l’ accessibilité en général. Par exemple: "Le système est-il laid ?", "Est-ce que l'utilisateur est daltonien et tout est en rouge et vert?" Ils devraient se plaindre aussi.

La configuration minimale requise pour qu'un système réussisse l'assurance qualité est généralement décrite dans une user story pour cette fonctionnalité particulière ou dans quelle magie le bon de commande voulait que le système soit dans sa tête.

tl; dr

Ce ne sont pas que des bugs, les testeurs devraient sortir de cette vision étroite.

Mauvaise idée.

Du point de vue du testeur: "Ils vont donc faire des tests difficiles, car ils savent qu'il y a des bogues et ne pas les trouver pourrait être considéré comme une incompétence." Fondamentalement, les développeurs sont en train de piéger le code. Peu de gens aiment faire un travail qui est finalement inutile (parce que les bugs sont connus à l'avance) mais qui affecte toujours la façon dont ils sont perçus. S'il existe des sanctions tangibles pour ne pas trouver les pièges, plus encore. Et savez-vous que les testeurs ont du succès à trouver des bugs? Cela ressemble à un environnement conflictuel toxique; Une QA devrait être satisfaite 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 bugs que vous savez être là. Cela pourrait bien augmenter le risque de voir de vrais insectes sortir de la porte; Les QA consacrent au moins une partie de leur temps à rechercher le type de bogue facile à planter, pas vraiment subtil. De plus, il y a une petite chance qu'un piège puisse sortir de la porte.

Je suis tout à fait d’accord avec les réponses ci-dessus pour expliquer pourquoi c’est mauvais pour la motivation et pour la gestion des personnes en général tout simplement abominable. Cependant, il existe probablement de bonnes raisons techniques pour ne pas le faire aussi:

Juste avant que le produit ne passe à l'assurance qualité, l'équipe de développement ajoute des bogues intentionnels à des emplacements aléatoires du 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.

1. Sur la base de la première déclaration, vous ne testez jamais réellement le code de production souhaité dans ces deux passes.

2. 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 modifier rapidement un client. Peut causer quelques joues rouges à un moment donné.

3. J'imagine que cela entraîne simplement vos testeurs à penser comme vos développeurs (comment Tom ajoutera-t-il un bogue ici), ce qui les rend probablement moins susceptibles de trouver les bogues auxquels Tom n'a pas pensé.

Modifier

Je tiens à préciser que cette réponse ne concerne que le concept de test de votre processus d'assurance de la qualité, et je ne défends pas la méthodologie spécifique décrite dans la question.

Terminer la modification

Il existe une raison valable de vérifier si vos tests / contrôles fonctionnent réellement. Permettez-moi de vous donner un exemple de fabrication, mais le principe est le même.

Lorsque vous introduisez un matériau dans une machine, il est typique que le chargeur ne le pousse pas suffisamment. Cela s'appelle une "alimentation courte" et pour éviter cela, nous pourrions installer un "capteur d'alimentation courte" (généralement un capteur de type barrage traversant qui est bloqué par le matériau). Ce capteur détecte la fin du matériau lorsqu'il atteint la longueur totale d'alimentation. À un moment donné du cycle de la machine, nous vérifions que le capteur est bloqué et arrêtons la machine en cas d'échec de la vérification.

Vous devez maintenant réfléchir à la manière dont le test peut échouer. Par exemple, certaines saletés ou autres débris peuvent bloquer le capteur qui signalera toujours "OK" sans jamais arrêter la machine. En outre, la nature du capteur est que le récepteur s'allume lorsque le faisceau le frappe. Ainsi, en fonction du type de capteur que vous avez installé, vous obtenez électriquement une entrée "ON" lorsque le capteur n'est pas bloqué . Cela signifie que si le câble est coupé ou si l'alimentation de ce capteur est coupée ou si l'entrée échoue, la logique de votre programme se lira "OFF" et signifiera "bloqué" ou "OK".

Pour détecter ces modes d'échec du test, nous insérons généralement une seconde vérification pour nous assurer que le capteur est réellement débloqué pendant une seconde partie du cycle. De cette manière, nous vérifions que le test fonctionne toujours (du mieux que nous pouvons).

De même, un service d'assurance qualité peut échouer de plusieurs manières. Peut-être que les tests automatisés n'ont pas été exécutés et que le rapport examine une ancienne copie des données de test. Peut-être que quelqu'un ne fait pas son travail correctement. Tester le service d'assurance qualité est une chose raisonnable à faire.

Évidemment, l’inconvénient est qu’un "bogue de test" pourrait passer par le service d’assurance qualité et aboutir au produit fini. Dans l'industrie manufacturière, il arrive parfois qu'une mauvaise partie connue, parfois appelée "Red Rabbit", soit insérée dans le processus (généralement par une personne de l'assurance qualité) et qu'elle surveille cette partie tout au long du processus et mesure le temps nécessaire trouvez la pièce et retirez-la. Normalement, cette partie est peinte en rouge vif (ou en orange), ce qui permet de la suivre facilement. Étant donné que quelqu'un surveille le déroulement de la pièce au cours de cet essai, les chances de la transformer en produit final sont pratiquement nulles. Il y a bien sûr des histoires apocryphes de quelqu'un qui a jeté une mauvaise partie connue dans le processus pour "voir si le système peut la trouver",

Honnêtement, je dirais que ce comportement est manifestement contraire à l'éthique et irréalisable. Le Premier ministre a besoin d’une sérieuse formation, sinon d’une cessation.

• Cela démontre un manque fondamental de compréhension du concept d'assurance qualité . Les testeurs ne devraient pas penser comme des développeurs: ils devraient penser comme des utilisateurs finaux. La raison d'être des équipes d'assurance qualité est que les développeurs sont trop proches du code; QA est supposé maintenir suffisamment de distance par rapport au code pour pouvoir détecter ce que les développeurs manquent.
• Cela gaspille les efforts d'assurance qualité . En supposant que ces bugs ne sont pas anodins (voir ci-dessous pour savoir quand ils le sont), cela signifie que QA consacre du temps et des ressources à la recherche d'informations déjà connues, au moment où ils pourraient consacrer leurs efforts à la recherche de renseignements inconnus.
• Cela gaspille les efforts des développeurs . Pour que les personnes responsables de l'assurance qualité puissent attraper ces bogues non triviaux, les développeurs doivent d'abord les écrire. Cela nécessite encore des efforts supplémentaires, consacrés non seulement à coder les bugs, mais également à prendre en compte les exigences logicielles et la conception.
• Cela met la production en danger inutile . Ce n'est qu'une question de temps avant que les changements ne soient correctement intégrés.
• S'il ne fait pas ce qui précède, alors c'est inutile . Si tous les bugs connus sont triviaux, ils ne prendront pas les travailleurs non conformes aux normes: ils ne captureront que les personnes qui ne travaillent pas du tout. Il y a de meilleures façons de le faire.
• Cela empoisonne l'environnement de travail . Vos testeurs d'assurance qualité sont des professionnels. On devrait leur faire confiance pour être professionnels jusqu'à ce qu'il y ait une raison réelle de suspecter le contraire Quand il y a des raisons de suspecter le contraire, il devrait y avoir une enquête appropriée à la place de ces jeux de l'esprit. Tout le reste tue le moral.

Sérieusement. Même si la paranoïa du Premier ministre s’avère bien fondée dans ce cas précis, ce n’est pas quelqu'un qui a une entreprise qui gère des testeurs.

Personnellement, cette approche me met mal à l'aise.

Ce qui me préoccupe principalement, c’est l’aspect pratique de l’insertion intentionnelle de bogues. Cela me semble difficile à réaliser de 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 au cours des tests, mais il se peut que la cause première ne soit pas évidente (même pour le développeur qui a créé le bogue). Je ne me sens pas en sécurité, si vous voyez ce que je veux dire (je parle de mon ventre ici).

En outre, le testeur perdra beaucoup de temps à tester du code qui ne sera pas réellement publié. Une fois que les bogues intentionnels ont été supprimés, un nouveau test complet devrait être effectué, à 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 l’essentiel des tests de régression.

Donc, dans l'ensemble, pas convaincu.

Par ailleurs, nous avons tendance à laisser les clients vérifier le travail des équipes d’assurance qualité, ce qui n’est peut-être pas idéal. C'est une boucle de rétroaction très puissante cependant.

C'est une mauvaise idée pour toutes les raisons déjà données, mais l'ensemencement de bogues est un outil utile dans un but différent. Vous pouvez l'utiliser pour obtenir une mesure approximative de l'efficacité du processus d'assurance qualité.

Dans le cas le plus simple, supposons que vous générez 100 bogues et qu’ils soient représentatifs de l’ensemble 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é, supposons qu'ils aient trouvé 60 des 100 bogues d'origine (et autres bogues réels). Vous savez maintenant que l’assurance qualité trouve 60% des bogues.

Vous pouvez aller plus loin en comptant le nombre de vrais bogues trouvés par le contrôle qualité et en appliquant le faux ratio de bogues. Dans notre exemple, si QA a trouvé 200 bogues réels, vous pouvez en conclure qu'ils n'en ont trouvé que 60%, donc il en reste 133.

Bien sûr, il ne s’agit que d’une estimation large avec d’énormes barres d’erreur. Écrire des bogues représentatifs et réalistes est difficile. Les bogues que vous écrivez seront probablement plus faciles à trouver pour le contrôle qualité, car 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 uniques, les erreurs Unicode, les dépassements de mémoire tampon, etc.

Cela devrait s'appliquer à l'ensemble du processus d' assurance de la qualité , qui comprend les tests d'unité de développeur, l'intégration continue et, le cas échéant, une équipe d'assurance de la qualité dédiée.

Ceci est une métrique et ne devrait pas être détourné en tant qu'outil de motivation de gestion.

Mauvaise idée.

C’est le type d’approche logique et binaire que les développeurs utilisent souvent, mais elle est démotivante 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 cela suppose qu'ils sont d'accord avec cela, et ce n'est pas à eux de suggérer le contraire.

Ce type de réflexion combine les QE comme testeurs manuels et non comme motivation pour comprendre le code réel testé.

Je suis un QE senior et il s'agit d'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 délibérément des bugs dans le code et à faire des efforts pour sauvegarder la bonne version. Alors que les testeurs devraient vraisemblablement tout tester, y compris les fonctionnalités du bogue implanté, s’ils en trouvent un, ils devront probablement revenir en arrière et relancer ce test pour vérifier qu’il s’agissait bien d’un bogue (et non que le testeur s’était confondu). en quelque sorte). Au minimum, les testeurs vont passer du temps à écrire les bugs plantés. Les programmeurs doivent ensuite passer du temps à corriger le bogue qu’ils ont créé. C’est beaucoup d’efforts que l’on pourrait consacrer à écrire du bon code et à écrire de vrais bogues.

Deux: cela indique clairement 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 cela soit bon pour le moral. En tant que programmeur, si on me donnait des spécifications ambiguës ou contradictoires 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 ajouté des déclarations contradictoires. 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 me suffire pour me 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, car le premier projet de code qu'ils avaient reçu était si souvent parfait à 100%. J'ai eu à faire face à des testeurs paresseux qui ne font pas un travail adéquat, mais ils n'ont pas réussi à le faire parce que les programmeurs étaient si parfaits. Le meilleur testeur avec lequel j'ai jamais travaillé m'a dit que pour une nouvelle version du logiciel, il s'était fixé comme objectif personnel de trouver 100 bogues. D'accord, si 100 est 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 "bogue" dans un message mal orthographié, mais bon, il devait être corrigé.

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 et les programmeurs oublient de remettre le bon code. Alors maintenant, un bogue délibérément planté est envoyé au client.

Je ne pense pas vraiment que ce soit une mauvaise idée. Je suppose que beaucoup de choses fonctionnent mieux:

1. Rendez l'AQ responsable de la qualité de toutes les manières possibles. Par exemple en faisant supporter leur responsabilité également. Cela les incitera davantage à faire en sorte que les produits expédiés soient de meilleure qualité. Il faut toujours moins d'effort pour découvrir soi-même une insuffisance (bogue, caractéristique manquante, comportement contre-intuitif), puis pour essayer de comprendre ce que votre utilisateur contrarié tente d'expliquer. Et attribuer une partie de cette responsabilité même aux développeurs pourrait accroître leur motivation à aider le service d'assurance qualité à faire son travail du mieux possible.

2. Avoir plusieurs équipes d'assurance qualité, qui peuvent le concurrencer. Vous devez bien sûr trouver une mesure raisonnable. Certainement pas seulement le nombre de problèmes. Il serait utile de prendre en compte la gravité du défaut ou la valeur commerciale (telle que déterminée par les parties prenantes) des améliorations proposées.

Il est difficile de dire si l'AQ est "assez bonne". Il est plus facile et peut-être même meilleur à long terme de trouver des moyens pour que l'AQ soit "en constante amélioration".

Néanmoins, il y a un problème à connaître si vous introduisez des bogues intentionnels: comment savez-vous que le code "correct" a déjà été correct en premier lieu? Après le deuxième contrôle qualité, vous supprimez tous les bogues intentionnels non découverts. Il n’ya aucun moyen de savoir que vous ne les remplacez pas simplement par du code cassé d’une autre manière ou que vous n’activez pas un comportement cassé inaccessible auparavant (exemple exagéré: une boîte de dialogue n’a pas été ouverte à cause d’un bogue intentionnel, mais le dialogue lui-même est brisé - vous ne le découvrez pas simplement parce que les testeurs ne l'ont pas vu).

Comme d'autres l'ont dit, les développeurs ne devraient pas ajouter délibérément des bogues dans le logiciel, mais c'est une stratégie légitime pour votre suite de tests d'ajouter des bogues au logiciel dans le cadre du processus de test.

C'est ce qu'on appelle le test de mutation . L'idée est d'utiliser un logiciel pour automatiser la création de petites modifications dans le code source (appelées 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 équivalents du point de vue du fonctionnement) échouent au test, vous savez alors que votre code et vos tests sont puissants .

J'aime l'idée. Le général Patton a-t-il dit: "Plus vous transpirez en paix, moins vous saignez à la guerre."

Mettre des bugs intentionnels "fait perdre du temps" aux testeurs. Mais cela les oblige également à travailler plus fort, ce qui signifie qu'ils seront également plus efficaces dans la recherche de bogues non intentionnels. (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 non intentionnels vous épargnera probablement plus de chagrin à long terme que le coût du traitement des problèmes 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 d’assurance qualité de rester calme ou de donner l’impression à un responsable de contribuer réellement quelque chose sans se rendre compte qu’il ne fait que gêner.

Résultat positif - L’équipe d’assurance qualité s’efforce davantage de trouver des bogues. Qui sait, peut-être y voient-ils un défi. C'est un jeu amical. Ou ils font juste parce qu'ils sont surveillés (effet Hawthorne?).

Résultat négatif - Ils peuvent ne pas travailler plus fort et trouver le bogue de toute façon. QA considère cela comme une affaire mesquine et accusatoire. Alors maintenant, ils se lancent dans une recherche d'hyper-bugs et génèrent toutes sortes de petits problèmes difficiles. Cette police ne s'affiche pas correctement lorsque je prends une capture d'écran et que je la convertis au format PDF que je visualise à 500%.

No Impact - ça me semble que ça ne fait aucune différence, alors pourquoi s'en faire? Vous risquez juste de perdre du temps et d'irriter les gens.

Nous pouvons tous convenir que cela ne fonctionnera pas dans 90% des cas. Cela ne fait pas beaucoup de bien aux 10% restants. Testez les choses pour vous-même. Les clients sont-ils plus satisfaits d'une version contenant les bogues de code intentionnels? Cela at-il un impact sur le moral et la productivité des travailleurs dans d’autres domaines? Augmenter le chiffre d'affaires? Tu nous as dit.

Venant d'un monde où les développeurs sont censés écrire et exécuter les tests eux-mêmes, ce silo de "tests" "QA" dont vous parlez me fait peur et m'embrouille, je vais donc essayer de vous répondre dans cette perspective. En passant, les ingénieurs QA qualifiés (de mon point de vue, comme décrit dans la réponse de @ SparK), devraient se concentrer sur les problèmes plus vastes consistant à s’assurer que le logiciel satisfait pleinement les récits des utilisateurs et présente 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 est la mention de @ JamesMcleod de "l'injection de défaut" dans les commentaires à la question. Je pense en fait que faire réfléchir les développeurs sur la manière dont 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 suffire à détruire le système entier de manière incontrôlée (sans journalisation exploitable claire), à ​​provoquer une corruption des données ou à exposer lui-même une faille de sécurité.

Demander aux développeurs de chaque composant de créer des défauts intentionnels, de gérer ceux d’autres composants et de s’engager dans un état d’esprit plus contradictoire à propos de leur logiciel pourrait grandement contribuer à l’amélioration de la robustesse du logiciel. Même l’avantage immédiat pourrait être considérable - lors de chaque injection d’un nouveau type de défaut (qui n’avait pas encore été testé), le développeur devait immédiatement le couvrir par un nouveau test, qui serait associé à un drapeau. laissez le bogue vivre dans la base de code sans être dérangé pendant un court instant, puis activé avant la livraison (et le défaut éliminé), pour se transformer en un test régulier qui rendra la suite de tests plus complète.

Une option connexe consiste à utiliser des indicateurs de fonctionnalité pour désactiver volontairement des fonctionnalités dans des composants particuliers afin d’examiner la manière dont d’autres composants traitent ce problème. Je recommande également vivement de lire le livre / article gratuit "Apprendre des premiers intervenants: quand vos systèmes doivent fonctionner", qui décrit de tels tests approfondis de l'infrastructure logicielle devant être utilisée par l'équipe Obama pour les élections de 2012.

Comme d'autres l'ont déjà dit, ce n'est pas à QA de rechercher uniquement des bogues. J'irais plus loin en disant que ce n'est pas du tout leur travail, techniquement. Les développeurs doivent être tenus de garder leur propre code exempt de bogues. Les suites de tests doivent être exécutées avant même que le nouveau code ne soit validé, et si les suites de tests échouent, il ne devrait jamais être rendu au contrôle qualité en premier lieu. L'introduction intentionnelle de bogues signifie que vous ne pouvez absolument pas réussir vos suites de tests, alors pourquoi votre code est-il envoyé au contrôle qualité?

Le travail du contrôle qualité 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 doit pouvoir faire, de la manière la plus utilisable et la plus accessible possible. Ce faisant, ils peuvent bien sûr 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 pas assurance sans bug.

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 d’essais, ce serait dingue. D'autre part, l'une des choses les plus difficiles du développement logiciel est de savoir l'efficacité de votre approche de test.

Ainsi, si vous le structurez correctement, vous pouvez utiliser cette technique pour estimer le nombre de bogues non fondés dans le produit que vous êtes sur le point d’expédier. Alors, imaginez que vous ayez introduit artificiellement 100 bogues dans votre version de test et que les testeurs en trouvent 50. Ensuite, vous pouvez en déduire qu'il est fort probable que s'ils ont également trouvé 50 bogues non ensemencés, il en reste peut-être 50.

Bien sûr, cela pose de nombreux problèmes. Vous pouvez décider d’expédier en fonction de ces statistiques, mais dans la réalité, vous pourriez trouver un problème très grave, ou mille irritations mineures.

Toujours - la connaissance est le pouvoir, et sans cette technique, vous avez encore moins idée de 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?"

Une chose que personne d’autre n’a encore mentionnée: le 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 OR, ou autre.) Il exécute ensuite votre suite de tests complète et vérifie si les tests réussissent.

Si tous les tests réussissent, alors il y a deux possibilités:

• La chose qui a été changée ne fait rien. En d'autres termes, vous avez du code mort.
• La modification introduit un bogue que votre suite de tests ne détecte 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 bugs inutiles. Et vous ne perdez pas de temps aux testeurs à trouver des bugs 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 se soucier après un certain temps!)

Je suggérerais 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 réalisez pas qu'il existe une condition de concurrence critique, il est peu probable que vous en insériez une délibérément.) Il reste à voir si un outil automatisé parvient à être plus objectif…

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 dans lesquelles l’injection intentionnelle de bogues dans le code de production de manière temporaire et contrôlée peut avoir un sens.

Lorsque vous reformulez 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 supposé trouver.

Vous pouvez alors intentionnellement casser le code de production afin de vérifier si les tests fonctionnent toujours.

Il y a plusieurs niveaux sur lesquels cela est possible:

• Un développeur qui vient de refactoriser certains tests unitaires 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 refacturer un test d'acceptation pourrait casser le code de production pour vérifier que le test d'acceptation vérifie toujours ce qu'il est supposé vérifier.
• Si l’interface est suffisamment stable et robuste (c’est-à-dire basée sur un protocole), la société peut souhaiter conserver une suite de versions de produits défectueuses connues et effectuer des tests sur ces dernières afin de tester le test de régression.

Que ces choses aient un sens dépend. Si je suis développeur et que cela ne me prend qu'une minute pour injecter un bogue, tester le test unitaire, supprimer le bogue - alors pourquoi pas. Mais je devrais avoir mon éditeur, mon cycle et mon système de contrôle de version sous un tel contrôle que je ne commettrais pas accidentellement / délivrer / enregistrer / pousser le bogue. Il en va de même pour le testeur et le test de réception.

Cela dépend de la pertinence pour une entreprise de conserver des suites de versions de produits connues et des tests de régression connus. Pour une boutique en ligne, je ne le ferais pas. Pour les cartes bancaires ou les cartes de télévision payantes intégrées dans l’industrie automobile, dans l’aérospatiale, je le ferais.

L'intensité de ces efforts dépend fortement de la manière dont les tests sont découplés du code de production. Plus les tests sont découplés du code de production, moins il est nécessaire de le faire, plus les tests sont cohérents avec le code de production, plus l'effort est grand.

La raison en est simple: lorsque vos tests et votre code de production sont cohérents, la modification du code de production nécessite la modification fréquente des 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 en valoir la peine, et la moquerie ainsi que l'utilisation intelligente d'un système de contrôle de version peuvent considérablement réduire l'effort, mais cela nécessite des développeurs bien au-dessus de la main.

Le concept d'injection intentionnelle de fautes dans le code de production s'appelle sabotage , la faute injectée s'appelle saboteur .

Un testeur qui ne prend pas le code à tester directement à partir du référentiel le fait mal. (1)

Un développeur qui enregistre un code défectueux connu dans le référentiel ne le fait pas correctement. (2)

Donc, à ce stade, il n’existe déjà aucun moyen pour ce système de fonctionner sans l’une des parties, ni avec les deux, en violation des principes fondamentaux 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 marqué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 un échec.

Il s’agit là d’une tentative de la "raison la plus courte possible" 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 version que vous envoyez à QA.

Vous pouvez, de temps en temps, disons une fois par an, faire un «audit d’assurance qualité». Prenez une base de code "testée et fonctionnelle", et autant de petites nouvelles fonctionnalités de votre liste Todo que possible. Implémentez-les "un peu plus négligemment" que vous le faites habituellement. Pensez aux cas extrêmes, écrivez-les, mais ne corrigez pas votre code pour les prendre en compte. Envoyez-le à QA.

S'ils trouvent plus de bogues non fonctionnels que ce que vous avez écrit, ce n'est certainement pas votre QA qui a besoin de supervision ... ;-)