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


267

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).

59
"Un test doit penser comme un développeur" ... intéressant. J'aurais pensé qu'il était évident qu'un testeur ne devrait pas penser comme un développeur mais comme un utilisateur.
Trilarion

12
Que se passe-t-il si un bogue introduit intentionnellement recouvre un autre bogue que les testeurs auraient pu trouver si ce bogue intentionnel n'avait pas été introduit? Par exemple, supposons qu'un morceau de code ait un problème de poteau de clôture et que l'équipe de développement n'en soit pas consciente. Un programmeur décide d'insérer une erreur intentionnelle de poteau de clôture à cet endroit. Maintenant, le code a une erreur double fencepost. Supposons que les testeurs détectent l'erreur, mais ne voient pas qu'il s'agit d'une erreur à double barrière. Félicitations! Les testeurs ont trouvé un bogue introduit. Le code d'origine sera restauré pour contenir l'erreur d'origine fencepost. Oops!
David Hammen

20
Je suis un QE. Je préférerais trouver de vrais bugs, merci. Je quitterais cette entreprise comme si elle était en feu. Personne ne perd (intentionnellement) mon temps.
ArjunShankar

7
"Nous ne le faisons pas dans notre entreprise, mais un de mes amis a déclaré que son directeur de la technologie avait demandé à chaque chef de produit d'ajouter des fonctionnalités supplémentaires au début de chaque cycle de développement de fonctionnalités ..."
Marco

3
Je soupçonne que l'ajout de bogues intentionnels crée un risque. Et si un bogue intentionnel corrige quelque chose d'inattendu? L'effet secondaire positif n'est pas signalé, le code est supprimé et un vrai bogue parvient à l'AQ. De par leur nature, ces "bogues intentionnels" de dernière minute seront mal pris en compte, sinon, les bugs font perdre trop de temps aux développeurs.
Jodrell

Réponses:


462

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.


17
Le travail de QA est de trouver des bogues - ce n'est pas le cas; il s’agit d’assurer la qualité de production du logiciel. Cela nécessite quelques éclaircissements. L’isolement et la correction des bogues constituent un processus important dans l’exportation de logiciels de qualité de production.
Krishnabhadra

21
En fait, dans de nombreuses entreprises, le travail de QA consiste à rechercher des bogues. Si de nouvelles fonctionnalités sont ajoutées à un produit et que QA exécute alors une suite de tests qui ne montre aucun bogue, je ne ferai personnellement pas confiance à cette suite de tests. Je pense que c'est incomplet.
Doc Brown le

8
Je suis d'accord, sauf pour le dernier point. Avoir une sorte d’approche contradictoire entre l’AQ et le développement (et les entreprises) est en grande partie inévitable. Chaque groupe a ses propres désirs et son expertise. En tant qu'entreprise, il est essentiel de bien équilibrer ces facteurs. D'après mon expérience, "jouer gentil" conduit simplement les groupes à ne pas faire pression pour leur agenda, conduisant à la stagnation ou au déséquilibre. Les meilleures entreprises que j'ai vues sont celles où le développement, l'assurance qualité et les entreprises insistent pour répondre à leurs besoins, tout en agissant comme un frein contre les autres, menant à un compromis sur le meilleur équilibre pour l'entreprise.
Telastyn le

42
J'ajouterais un autre point: un bogue intentionnel pourrait masquer un vrai qui serait apparu si le bogue intentionnel n'arrêtait pas le processus (en lançant une exception par exemple) auparavant.
nkoniishvt

30
Si j'étais un gars de l'assurance de la qualité et que je découvrais que je perdais mon temps à rechercher et à documenter des bugs de connerie introduits à dessein, je trouverais un nouvel emploi.
Kik

209

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.


26
+1 Fortement d'accord avec les 4 points, surtout le premier. L'approche concurrentielle que tant de nouveaux développeurs apportent reflète souvent leurs 15 années de scolarité précédentes - un environnement extrêmement compétitif - contrairement au lieu de travail où la coopération serait une meilleure approche.
Michael Durrant le

1
Préférez de loin cette réponse à la première réponse.
Pharap

1
"Les responsables de l'assurance qualité ne sont pas seulement là pour rechercher des bogues, mais aussi [...]" - je tiens simplement à dire que, dans de nombreux endroits, les termes test du logiciel et assurance qualité sont utilisés de manière interchangeable. Oui c'est mauvais. Là où je travaillais, nous avions un employé qui utilisait l’état - à chaque réunion du département d’assurance qualité - ce que nous faisons ici n’est pas l’assurance qualité mais le contrôle de la qualité. (Elle pensait que c'était une critique de notre service d'assurance qualité.)
Mario

1. C'est l'école. Chaque jour est un jour d'école. Si vous travaillez dans une discipline d'ingénierie mais que vous ne voulez pas apprendre tous les jours, vous devriez sortir de mon bureau. C'est aussi une interview. Le rendement devrait être mesuré chaque jour pour s'assurer que le ministère en a pour son argent. 2. Si ma carrière m'a appris quelque chose, c'est que l'AQ a la capacité mentale de 14 ans. Ce sont des enfants et doivent être gérés comme un troupeau de moutons.
Gusdor

1. Ce n'est pas une école dans le sens où les gens peuvent collaborer et ne pas rivaliser pour obtenir leurs notes. Il est impossible de copier son travail car les tâches ne doivent être accomplies qu'une seule fois et il n'est pas honteux de demander de l'aide à un collègue. Et 2. Si votre assurance qualité est si mauvaise, votre problème concerne les ressources humaines. Ce sont eux qui devraient quitter le bureau.
SparK

99

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.


32
S'ils paient par bogue, alors ceci
BЈовић

12
"incité à trouver les bugs que vous savez être là" Excellent point. Si une organisation le fait, cela signifie probablement que quelqu'un respire le cou des gens de l'assurance qualité pour s'assurer qu'ils trouvent les insectes plantés. Ce sera donc leur priorité absolue. Que se passe-t-il s’ils se retrouvent et s’imaginent, par exemple, "Hé, les bugs plantés, c’est presque toujours qu’il ne parvient pas à enregistrer un champ sur un écran de montage avec un tas de données" (ou autre). Ensuite, ils passeront énormément de temps à rechercher ce type de bogue et augmenteront leurs chances de rater d’autres types de bogues.
Jay

La première chose qui me vint à l’esprit fut que Wally codera l’autre fourgonnette cet après
Dan Neely

10
> de vrais insectes sortant de la porte. Je faisais de gros tests. Vous commencez avec la thèse que le code (non trivial) a toujours des bogues. QA sont les héros qui les trouvent avant le client. Les insectes sont toujours là. Si vous introduisez des insectes artificiels, vous perdez du temps, vous pourriez dépenser pour trouver les vrais insectes; le temps nécessaire aux tests est limité, vous réduisez la qualité en ajoutant du travail inutile.
RedSonja

58

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é.


43
+1 pour vous n'a jamais réellement tester votre code de production prévu dans ces deux passes. Comment vous pouvez même penser à la publication sans tester le code de production me dépasse; Si vous testez à nouveau sans bogues intentionnels, vous répétez votre effort et gaspillez le premier.
Adamdc78

51

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",


1
Les commentaires ne sont pas pour une discussion prolongée; cette conversation a été déplacée pour discuter .
Yannis

Bonjour à tous. La discussion devenait un peu trop longue pour les commentaires. Comme vous pouvez le constater dans mon précédent commentaire (automatisé), j'ai déplacé tous les commentaires vers un forum de discussion dédié . Si vous souhaitez continuer à discuter de la réponse, veuillez le faire dans cette salle de discussion, et pas ici. Merci.
Yannis

3
L’approche ainsi décrite pourrait être utilisée pour tester l’assurance qualité occasionnellement , et non comme un processus permanent.
Gerlos

30

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.


28

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.


1
J'aime l'idée du pouvoir de boucle de rétroaction!
Jxramos

23

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.


Ce serait le seul moyen de collecter des données utiles. Toutefois, le temps et les efforts nécessaires pour déterminer les tests élémentaires permettant d'obtenir des résultats significatifs briseraient tout budget et tout calendrier. Et même si le budget et le calendrier vous étaient communiqués, vous devrez alors vous assurer que vous avez des personnes qualifiées pour comprendre suffisamment les statistiques et les logiciels pour pouvoir identifier le sous-ensemble de tests approprié. Je ne pense pas que vous obtiendrez tout cela dans un seul projet. Donc, dans la vie réelle, le mieux que cette méthode puisse faire est d’obtenir des chiffres erronés, voire trompeurs.
Dunk

1
L'injection SQL est une bonne chose à faire, car vous pouvez simplement sélectionner n instructions SQL au hasard pour "casser"
Ian

1
Un gros problème est que les bogues intentionnels auront tendance à être très différents des problèmes que vous auriez naturellement - vous pourriez simplement entraîner votre QA à penser comme les programmeurs. Cela détruit à peu près tout l'intérêt de l'assurance qualité: avoir un point de vue plus proche du client que du code. Une grande partie de l'assurance qualité consiste à vérifier l'intégrité des choses que les développeurs pensent intuitivement (soit par ignorance de l'ignorance des utilisateurs, soit par la proximité du code, le temps passé avec l'interface utilisateur, etc.). Les bogues intentionnels ne sont pas un exemple bien distribué.
Luaan

20

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é.


7
Ma femme a fait de l'assurance qualité pendant 8 ans et vient de partir pour le développement - principalement à cause de problèmes de confiance comme celui-ci. C'est juste insultant pour le testeur.
Bryan Boettcher

19

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.


Ce point à propos de la spécification dans "Deux" est une excellente analogie.
Kyralessa

14

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).


5
Si vous laissiez cette première phrase, je vous attribuerais +1 parce que tout le reste est bon :) C'est simplement une idée terrible, mauvais est un euphémisme. Le moyen le plus simple de responsabiliser l’assurance qualité est de garder trace du nombre de bogues qui l’a fait apparaître sur le terrain. Ce seul accomplira TOUT ce que la méthode proposée prétend être ses avantages.
Dunk

@Dunk: Garder une trace de ce nombre ne rendra pas automatiquement votre équipe meilleure, tout comme garder des scores dans un sport ne fait pas de vous le meilleur athlète que vous puissiez être. En fait, les athlètes s'entraînent , c'est-à-dire qu'ils effectuent des tâches artificielles pour augmenter leurs performances de manière contrôlable, ce qui n'est pas sans rappeler ce qui est proposé ici. À moins que vous ne sachiez comment amener les gens à améliorer ce chiffre, cela n'a guère de valeur.
back2dos

Je ne prétends pas que cela améliorera quoi que ce soit. Je prétends seulement que cela va accomplir tout ce que la méthode "insérer de fausses erreurs" accomplira, mais sans tous les coûts et le temps perdu. Cela va donner une indication si trop de défauts passent par le contrôle qualité. Si tel est le cas, le processus ou les personnes doivent être réévalués. La méthode "erreur fausse" ne fournit pas plus d'informations que cela, mais elle fournit en réalité des informations moins utiles. Vos coûts sont donc plus élevés pour un gain moindre en utilisant la méthode "erreur fausse". Comme je le disais, une idée terrible.
Dunk

@Dunk Ensuite, vous n'avez pas lu la question correctement. Cela suggère que cette méthode augmente le moral et la minutie. De plus, le nombre de bogues qui traversent le contrôle qualité ne permet pas de mesurer de manière fiable l'efficacité de l'équipe de contrôle qualité. Il est également affecté par le nombre de bogues introduits par les développeurs. S'ils commencent à utiliser TDD et qu'il y a une diminution soudaine des défauts dans la version, qu'est-ce que cela dit des testeurs? Rien.
back2dos

@Dunk Contrairement à cela, la "fausse erreur" vous donne en réalité plus d'informations, en supposant que la difficulté de les trouver ne fluctue pas de manière erratique (ce qui peut être arrangé). Parce que vous savez combien de défauts artificiels il y a, vous pouvez savoir exactement quel pourcentage d’entre eux ont été capturés dans le QA. Les informations supplémentaires que vous obtenez sont donc l’efficacité de l’AQ dans la détection des défauts artificiels. Et ce nombre est certainement davantage en corrélation avec leur efficacité globale que celui que vous avez suggéré.
back2dos

9

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 .


7

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.


1
Je pense qu'il y a de bonnes parties à cela. Il est préférable de trouver un bogue AVANT que cela tombe dans la nature, et je préfère appuyer sur mon QA interne (c'est pour cela qu'ils sont payés après tout?) Que de répondre à des attaques externes. La chasse aux insectes en fait partie, et tant que ce type de test est géré correctement, je ne vois pas pourquoi cela ne pourrait pas être une partie valable.
WernerCD

1
La copie de "l'original" peut ne pas être exempte de bogues et est également, par définition, non testée (car le code a été modifié pour ajouter des bogues).
Roger Rowland

1
D'après mon expérience, les insectes ne sont pas des animaux isolés et ne restent pas seuls. Le logiciel fait partie d'un système et les bugs - intentionnels ou non - affectent le système . À moins bien sûr que nous ne parlions de logiciels triviaux.
Roger Rowland

18
Il n'y a aucune preuve que cette méthode trouverait même un bogue supplémentaire au-delà des bogues intentionnellement insérés. Il n'y a aucune preuve que cela obligerait l'AQ à travailler plus dur pour trouver des bogues. Ils peuvent essayer moins fort. De plus, comme vous avez perdu tout le cycle de test de la procédure de test d'acceptation tout en testant intentionnellement un code erroné (notre test complet dure 3 semaines), vous devez maintenant tester à nouveau le code qui sera déployé car le code la version n’est pas la même version, donc ses tests sont pratiquement inutiles pour la validation de la version "réelle".
Dunk

6
Je suppose que Patton voulait dire que vous devriez avoir une formation rigoureuse et des exercices sur le terrain en temps de paix. L'analogie serait d'avoir des cours rigoureux dans une école d'informatique ou une formation post-diplôme. Je suis à peu près sûr que Patton ne voulait pas dire que les officiers devraient avoir pour instruction de tirer sur leurs propres troupes par derrière pour garder les troupes sur leurs gardes!
Jay

7

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.


Je suis tout à fait d’accord avec cela, ce qui conduit à des problèmes difficiles à résoudre.
Adam Johns le

@AdamJohns - Vous ne le savez jamais avec certitude, à moins d'essayer de le tester. Il y a de meilleures façons, alors ce serait presque un dernier recours pour moi.
JeffO

7

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.


4
Plutôt que de laisser les développeurs «injecter» des bogues dans le code, leur temps serait bien mieux servi, identifiant comment ces bogues auraient pu entrer dans le système pour commencer, puis corriger le code pour s'assurer que ces bogues ne peuvent pas se produire ou sont traités correctement par les logiciels. L’élaboration d’un projet n’a pas pour objectif de tester le système d’assurance qualité, mais bien de créer un système utilisable, robuste et fonctionnel, capable de répondre aux attentes de ses utilisateurs.
Dunk

4

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.


2

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?"


2

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…


1

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 .


1

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.


1
Ceci est un argument circulaire. Vous dites que "semer des bogues dans une version de test est une erreur, car les développeurs ne devraient pas créer de version avec du code défectueux connu".
Dominic Cronin

@DominicCronin: Rien de circulaire à ce sujet. Tout ce qui est engagé dans le référentiel doit être de la meilleure qualité possible. Il y a tout un tas de raisons à cela - éviter un changement artificiel de lignes de code (par exemple "svn blame" et des fonctions de référentiel similaires). Le danger de "oublier" pour éliminer l'erreur à nouveau. Le problème est que les testeurs pourraient rechercher ce qui a été "ensemencé" en consultant le journal des modifications du référentiel. Beaucoup plus de raisons, avec pratiquement aucun avantage à contrebalancer. Mais je suis à court d'espace, et de toute façon, l'idée était de fournir une , courte raison.
DevSolar

@DominicCronin: Ou, pour le dire autrement - il pourrait être un cas à faire pour « semis » un bug, mais la ligne doit être utilisée bien avant de commettre que la mise en pension. Et d'autre part, tout en ayant le code « tête de série » pour le test pourrait avoir une ou deux choses pour elle, vous devriez ne jamais tester commis code. Les deux idées - chacune étant déjà controversée - ne sont simplement pas liées de manière raisonnable.
DevSolar

0

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 ... ;-)


2
cela ne semble rien offrir de substantiel sur les points soulevés et expliqués dans les 16 réponses précédentes
gnat
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.