Le service d'assurance qualité (QA) recherche les bogues dans le logiciel. Les méthodes varient d'une entreprise à l'autre, mais cela est généralement effectué par des employés qui connaissent le logiciel. Ils l'utilisent de diverses manières et essaient de trouver les bogues que les développeurs ont manqués.
Le terme AQ peut faire référence au processus lui-même, à l'organisation, ainsi qu'à un testeur individuel au sein de cette organisation. En règle générale, les testeurs d'une organisation d'assurance qualité sont appelés «AQ». Dans cet article, par souci de cohérence, nous utiliserons l'abréviation courante QA au lieu du «testeur d'assurance qualité» plus précis.
Différentes entreprises ont des responsabilités différentes en matière d'AQ pour la qualité globale du produit. Parfois, le terme «assurance qualité» n'est pas entièrement applicable à ce service s'il ne recherche que les bogues et compte leur nombre.
Les personnes suivantes sont problématiques au sein du service AQ:
Tuyau d'incendie
Un testeur qui rapporte tellement de rapports de bogues si rapidement que l'équipe de développement ne finira jamais.
- Peut muter en alarmistes
- C'est dangereux en combinaison avec un chef de projet comme les statistiques
- Probabilité de correction: élevée
- Danger pour le projet: élevé
Le problème
Si un bogue est détecté, il est important de faire un rapport clair et de l'attribuer immédiatement au développeur approprié. Cependant, certains testeurs sont capables de trouver des bogues plus rapidement que l'équipe de développement ne les a corrigés. Pour cette raison, la liste des bogues ne cesse de s'allonger et tous ne peuvent jamais être fermés.
À première vue, il peut sembler qu'il y ait un problème avec la qualité du produit, mais ce n'est pas toujours le cas. Contrairement à un testeur conventionnel, qui fonctionne avec un programme très buggé, un tuyau d'incendie génère une avalanche de rapports avec une ou plusieurs propriétés caractéristiques:
- Leurs rapports sont mal détaillés, ce qui permet de signaler plus rapidement plus d'erreurs.
- De nombreux bogues sont des doublons d'autres, car ils ne sont que des variantes d'une raison principale.
- Il n'y a pas de temps pour reproduire l'erreur, car il suffit de la voir une fois pour rédiger un rapport.
Les testeurs de tuyaux d'incendie apparaissent souvent sous la pression directe ou indirecte de l'entreprise:
plus vous trouvez d'erreurs, mieux vous faites votre travail . Cela conduit au fait que les testeurs d'assurance qualité, qui surveillent attentivement la cause réelle des erreurs et les signalent de manière claire et concise, sont considérés comme moins productifs que les tuyaux d'incendie qui émettent le nombre maximal de rapports par unité de temps.
Les activités de ces testeurs peuvent semer la panique dans le projet, car il semble que le produit soit de mauvaise qualité, et le projet est désormais en retard. Leur influence sur le moral peut être immédiate et dramatique: l'équipe de développement prie d'interrompre le flux des rapports de bogues.
Solution
Avant de fixer un tuyau d'incendie, il est essentiel de l'identifier avec précision et de ne pas le confondre avec un contrôle qualité efficace qui entre en collision avec un système très poussiéreux. Les preuves les plus claires proviennent des plaintes des développeurs:
- La plupart des erreurs sont des doublons.
- De nombreux bogues ont les mêmes causes profondes évidentes, ils peuvent donc être signalés comme un seul bogue.
- Les messages d'erreur ne contiennent pas de détails.
Pour remédier à la situation, le tuyau d'incendie doit être expliqué qu'il n'y a pas d'incitation à signaler un grand nombre d'erreurs, et l'objectif est d'améliorer la qualité du système et d'aider les développeurs. Après cela, la qualité du produit devrait s'améliorer au même rythme (ou mieux), mais sans panique.
Le procureur
QA, qui après chaque bug trouvé accuse les développeurs de ne pas tester leur programme.
- Peut muter en alarmistes
- C'est dangereux en combinaison avec un chef de projet comme les statistiques
- Probabilité de correction: élevée
- Danger pour le projet: faible
Le problème
Théoriquement, un développeur peut trouver et corriger tout bogue avant de transférer le produit au service QA. Par conséquent, certains testeurs perçoivent chaque erreur trouvée comme une autre preuve que les développeurs ne testent pas assez bien leur travail. Cet argument irréfutable permet au procureur d'exprimer encore plus fort une opinion dédaigneuse sur l'équipe de développement.
Le procureur ronge le moral de l'équipe. Au lieu d'aider à améliorer la qualité du produit, il essaie de prouver que l'équipe de développement ne fait pas le travail. Chaque erreur est ajoutée au tas de preuves que les développeurs s'appuient excessivement sur le contrôle qualité au lieu d'identifier eux-mêmes les bogues.
Malheureusement, les procureurs sont créés à la suite d'un processus typique et assez prévisible:
- Une erreur critique a été détectée en production.
- Le testeur est accusé de manquer ce bug.
Cela se produit trop souvent, et donc QA se défend naturellement en utilisant un argument irréfutable.
Solution
Avant de corriger un accusateur, une organisation doit d'abord arrêter de blâmer le contrôle qualité pour les bogues de production. Ceux qui le font doivent être formés aux méthodes plus productives pour améliorer la qualité des logiciels.
Lorsque l'organisation a cessé de blâmer QA pour les bogues en production, vous pouvez corriger le testeur-accusateur en l'invitant à changer d'avis et d'attitude.
Il faut lui dire que les développeurs ne sont que des gens et que tout le monde a tendance à faire des erreurs. Le département QA doit compenser cette propriété humaine naturelle des développeurs, agissant comme une protection contre les erreurs affectant les clients. De plus, en raison du processus de codage fastidieux et fastidieux, il est très facile pour un développeur de ne pas voir la forêt derrière les arbres: il est tellement concentré sur la résolution d'un problème spécifique qu'il oublie de vérifier des choses apparemment évidentes.
Changement d'attitude: nous devons nous rappeler que nous travaillons tous en équipe, les camarades ne devraient pas se blâmer pour avoir commis des erreurs, mais devraient aider à les corriger pour le bien de l'équipe. Il est particulièrement important pour l'AQ d'établir des partenariats avec l'équipe de développement pour le bien du projet, et le processus ininterrompu de détection des bogues, de rapport et du cycle de vie de leur correction est crucial pour la qualité du produit.
Alarmiste
QA, qui déclare que l'ensemble du produit a un niveau de qualité inacceptable, alors que son opinion est basée uniquement sur une impression superficielle.
Le problème
À la base, différentes fonctionnalités d'application ont une qualité différente. Certains peuvent être relativement simples ou développés par des développeurs hautement qualifiés, et il y a donc peu ou pas d'erreurs. D'autres sont relativement sophistiqués ou développés par des développeurs moins expérimentés - et sont donc pleins de bugs. L'alarmiste n'a pas eu la chance de rencontrer immédiatement une zone de mauvaise qualité - et
sans autre enquête, il a annoncé que l'ensemble du produit ne convenait pas .
Vous pouvez beaucoup parler de la façon dont les développeurs de pneus QA perdent leur temps (voir un testeur du type
trompeur ), mais il s'agit d'une double situation. En fait, trop souvent, le développeur donne consciemment un logiciel de qualité médiocrement testé pour obtenir une récompense pour le travail effectué ou pour affirmer qu'il a respecté le délai. Lorsque QA commence à tester un tel système, il rencontre immédiatement beaucoup d'erreurs que le développeur aurait dû voir. Par conséquent, il est clair qu'il extrapole ce qu'il a vu à l'ensemble du produit et revendique une qualité extrêmement faible.
Un alarmiste a généralement une certaine autorité dans le département AQ, et son opinion est respectée. Plus le niveau de son autorité est élevé, plus l'impact sur le projet est destructeur. Un scénario typique est le suivant:
- Le produit est transféré à QA.
- Un alarmiste commence à tester une zone de mauvaise qualité.
- L'alarmiste arrête tous les tests et informe les autorités d'un grave problème de qualité du produit.
Il s'agit d'un cas classique de jeter un enfant avec de l'eau. Parfois, le contrôle qualité fait le bon choix, en particulier lorsque l'équipe de développement a la réputation de transférer des logiciels non vérifiés vers le contrôle qualité. Mais il arrive que l'alarme se déclenche à cause d'un développeur faible, dont le code a été le premier à venir chez un fabricant de panique.
Solution
Un testeur devient alarmiste s'il a été abandonné à plusieurs reprises par une équipe de développement. Si elle fournissait toujours des logiciels de haute qualité, il n'y aurait aucune raison de se méfier. Mais si le testeur devenait alarmiste, il serait difficile pour l'équipe de développement de reprendre confiance, surtout si l'équipe a vraiment des développeurs un
éléphant dans la boutique de porcelaine et
incompétents .
En règle générale, dans les grandes équipes de développement, le code de faible qualité provient des développeurs individuels, pas de l'équipe entière. Par conséquent, il est impératif que le travail de développeurs moins compétents soit testé en dernier, ou qu'il ne tombe pas dans l'alarmiste. Cependant, cela cache le vrai problème qu'il y a des
développeurs dans l'équipe
qui affectent négativement le projet .
Scientifique
Un testeur qui passe la plupart de son temps à documenter des bugs, sans en trouver de nouveaux.
- Peut muter chez les opprimés
- Dangereux lorsqu'il est combiné avec un chef de produit tel qu'un auteur de brevet
- Probabilité de correction: élevée
- Danger pour le projet: faible
Le problème
Trouver des problèmes dans le système peut être aussi excitant que la chasse au trésor. Et quand vous trouvez ce trésor, il n'est pas moins intéressant de résoudre le puzzle. On peut faire valoir qu'un testeur qui considère le processus de recherche d'erreurs de cette manière est idéal. Mais un problème se pose s'il cherche à documenter soigneusement son fascinant voyage. Au lieu de se concentrer sur le problème principal, le développeur est obligé de lire une longue histoire avec de nombreux détails inutiles, en essayant de sélectionner les informations pertinentes.
Le scientifique perçoit littéralement l'exigence de «documenter soigneusement les bogues». Il les décrit sous la forme d'une histoire de texte, et non d'une brève description avec une séquence claire d'étapes de reproduction. La lecture de tels rapports prend beaucoup de temps et, à la fin, on ne sait toujours pas exactement quel est le problème. En règle générale, une telle description comprend plusieurs bogues, tout en se référant à une large zone du système, et non à un problème spécifique.
La principale plainte des développeurs lorsqu'ils reçoivent des messages d'erreur de scientifiques est que le rapport signal / bruit est trop faible. Ils passent du temps à parcourir le courant de la conscience, à la recherche de détails spécifiques. C'est une perte de temps pour le développeur et le testeur.
Solution
Un scientifique en assurance qualité est facile à corriger en lui apprenant à rédiger les bons rapports. Souvent, la correction a lieu instantanément dès qu'ils expliquent ce qui est exigé de lui. Le moyen le plus efficace d'enseigner le bon style est de réécrire un ou plusieurs rapports dans le format correct, qui servira de modèle pour l'avenir. En conséquence, un testeur enthousiaste rédigera des rapports clairs et concis d'erreurs qui ne peuvent être rendues plus idéales.
Trompeur
Un contrôle qualité, qui signale souvent des erreurs de manière inexacte, conduit le développeur dans le mauvais sens lorsqu'il essaie de reproduire et de résoudre le problème.
- Peut muter en alarmistes
- C'est dangereux en combinaison avec un chef de projet comme les statistiques
- Probabilité de correction: élevée
- Danger pour le projet: élevé
Le problème
Le rapport d'erreur doit inclure les éléments suivants:
- La capacité de déterminer qu'il y a effectivement une erreur
- Possibilité de définir les étapes de lecture d'un bug
- Une description complète de l'erreur, souvent avec une cause première
- Étapes claires pour jouer un bug
À l'une de ces étapes, le rapport peut induire le développeur en erreur, ce qui lui fera perdre du temps:
- S'il n'y a pas d'erreur, le développeur passe du temps à chercher un problème qui n'existe pas
- Si l'erreur ne peut pas être reproduite, le développeur passe du temps sur sa reproduction
- Si l'erreur n'est pas décrite correctement, le développeur passe du temps à rechercher une cause racine trop spécifique ou trop large
- Si les étapes de reproduction sont inexactes, le développeur passe du temps à essayer de les interpréter ou peut ne déclarer aucun bogue, bien qu'il le fasse
Parfois, un développeur est confus à cause d'une simple erreur de testeur. Mais un testeur trompeur génère souvent de tels rapports, provoquant un mécontentement considérable parmi les développeurs. Si la situation continue, le testeur perdra éventuellement la confiance des développeurs, et ceux-ci cesseront de corriger même de vrais bugs, rejetant de tels rapports d'erreur.
Solution
Le contrôle qualité trompeur est souvent bon pour trouver des bogues, mais ne les documente que mal. Par conséquent, cela vaut la peine de le former.
L'une des méthodes les plus efficaces consiste à surveiller le développeur, qui, sur la base de son rapport, tente d'identifier le problème. Asseyez-vous simplement à côté du développeur qui a reçu l'un de ses rapports et observez calmement (sans interférence) comment le développeur essaie de le comprendre. Habituellement, cela mènera à une conversation saine sur la meilleure façon de signaler les bogues, ce qui bénéficiera à la fois au développeur et au contrôle qualité.
Opprimé
QA, qui est battu par les développeurs à un point tel qu'il est peu probable qu'il rapporte des erreurs, craignant l'intimidation de leur part.
Le problème
Il n'y a peut-être pas de plus grande manifestation d'indulgence que l'attitude typique des développeurs envers l'assurance qualité. De plus, on peut souvent voir que des développeurs agressifs intimident ouvertement le testeur, même s'il signale une erreur naturelle dans leur code. Pour contrer cela, un contrôle qualité réussi lorsque vous travaillez avec des développeurs agressifs devrait avoir les caractéristiques suivantes:
- Déjà gagné la grande confiance des développeurs, donc ses bugs sont toujours pris au sérieux.
- Capable de montrer non moins d'agressivité et de persévérance dans un différend avec un développeur qui ne reconnaît pas le bogue.
Malheureusement, peu de testeurs ont de telles caractéristiques, donc les développeurs essuient souvent leurs pieds à leur sujet et accusent principalement QA de détecter un nouveau bogue. Aussi illogique que cela puisse paraître, il s'agit d'une image typique dans les conditions suivantes:
- Le développeur a un sens élevé de son importance (voir un développeur tel qu'une prima donna )
- Le développeur estime qu'il sait mieux que le testeur le fonctionnement du système (voir un développeur comme un preneur d'otages )
Une fois que le contrôle qualité est complètement battu au fil du temps, il évite généralement la confrontation avec des développeurs hostiles pour réduire le stress. En conséquence, les bogues de ces développeurs spécifiques sont rarement signalés, bien qu'ils puissent exister. En règle générale, une situation n'est détectée que lorsque des problèmes surviennent dans la production et une enquête commence pour expliquer pourquoi le service de test n'a pas détecté de bug. Un testeur déprimé fournira l'une des explications suivantes:
- Il a parlé avec le développeur et il a dit que ce n'était pas une erreur.
- Il a déposé un rapport de bogue, mais le développeur l'a rejeté.
- Il a trouvé une erreur, mais "ne pensait pas que c'était assez important".
Un personnage passif rend souvent difficile de reconnaître un AQ opprimé. La clé sera d'analyser les développeurs avec lesquels ce contrôle qualité travaille - à la recherche de signes évidents d'hostilité.
Solution
Les développeurs se moquent très souvent directement des testeurs. Ainsi, ils doivent être traités comme tous les hooligans:
- Exigez d'arrêter immédiatement de vous moquer de l'AQ et de vous abstenir de tout comportement agressif.
- Former la communication professionnelle.
- Ignorez si le développeur ne peut pas corriger son comportement.
Dans les cas particulièrement graves, le service du personnel devra intervenir, surtout si la situation a dégénéré en hostilité ouverte.
Il est triste que cette situation soit la norme plutôt que l'exception. La seule différence est le degré d'hostilité.
Clicker aléatoire
Contrôle qualité qui recherche les erreurs par méthode de clic aléatoire.
- Peut muter dans un tuyau d'incendie
- Dangereux lorsqu'il est combiné avec un chef de produit tel qu'un auteur de brevet
- Probabilité de correction: faible
- Danger pour le projet: faible
Le problème
La recherche de bogues dans le système s'effectue par deux méthodes principales:
- Selon le plan de test en traitant méthodiquement la liste des cas de test.
- Errant au hasard dans l'application pour tenter d'émuler les actions de l'utilisateur.
La rédaction d'un plan de test est une tâche qui prend du temps, et rien ne garantit qu'au moment où le test commence, le plan sera toujours pertinent après une modification des exigences. Cela peut conduire au fait que le testeur abandonne complètement les plans de test et interagit simplement avec l'application dans l'espoir de trouver des bogues.
En effet, une interaction accidentelle avec l'application révèle des erreurs, notamment à un stade précoce du développement du produit. Cependant, à mesure que le produit vieillit, trouver des erreurs de cette manière sera beaucoup plus difficile, car les bogues restants sont cachés dans les cas limites. Cela conduit à un faux sentiment de sécurité, comme si l'application ne contenait aucune erreur, bien qu'elle n'ait tout simplement pas été testée comme il se doit.
Il est important de se rappeler qu'une interaction aléatoire avec l'application reste une méthodologie acceptable, car elle peut révéler des situations qui ne sont pas documentées dans le plan.
Mais ce n'est qu'un ajout au plan de test, pas un remplacement.Solution
Un clicker aléatoire peut apparaître dans l'un des deux cas suivants:- On ne lui a pas appris à tester correctement l'application.
- Il évite activement de rédiger un plan de test.
Si le problème est le manque de formation, vous devez le fournir. Cependant, dans ce cas, le testeur peut encore entrer dans la deuxième catégorie, ne souhaitant pas établir de plan de test, même s'il sait qu'il doit le faire.La rédaction d'un bon plan de test nécessite un niveau d'organisation, de diligence et de concentration rare. En conséquence, certains types de personnes aiment ce travail, mais la plupart n'en ont pas. Si vous êtes très chanceux, un clicker aléatoire trouvera les caractéristiques nécessaires pour rédiger de bons plans de test, mais la probabilité est faible.Fortement audacieux
, -, .
Le problème
Signaler correctement un bogue est un processus long et difficile sur le plan cognitif, et certains QA ne veulent pas faire assez d'efforts. En règle générale, ce sont des testeurs dotés de certains droits: ils estiment qu'ils n'ont pas à essayer de choisir la formulation. Ils regardent souvent les développeurs avec mépris et ne pensent pas que cela vaut la peine de passer du temps sur une sorte d'analyse des erreurs: une déclaration générale suffit aux développeurs pour oser découvrir ce qui se passe.Les rapports de bogues typiques d'un testeur imprudent contiennent les phrases suivantes:- "Ça ne marche pas."
- "Il est encore cassé."
- "Le problème serait évident si vous utilisiez réellement cette fonctionnalité."
- "Je ne sais pas pourquoi ils l'ont raté."
- "Vérifiez bien la prochaine fois"
- "Je ne sais pas pourquoi nous ne pouvons pas l'implémenter correctement"
De toute évidence, les développeurs ne sont pas très satisfaits des rapports qui utilisent des phrases similaires au lieu d'étapes pour reproduire l'erreur. Cela est rarement fait par un analyste QA professionnel, mais on le trouve souvent si un autre employé de l'entreprise qui a été invité à rechercher des bogues signale une erreur. Cela se produit généralement lorsqu'il reste peu de temps avant la sortie et qu'il n'y a pas suffisamment de testeurs. À la suite d'une telle "aide", le chaos se produit généralement, car les rapports sont rejetés par les développeurs, ce qui provoque encore plus de controverse dans l'équipe, ce qui aggrave encore l'indignation.Solution
En général, les testeurs professionnels devraient être chargés de trouver les bogues. Malheureusement, il existe une opinion dans l'industrie selon laquelle tout le monde peut rechercher des bogues, mais ce n'est pas le cas. Il est plus exact de dire que n'importe qui peut détecter une erreur, mais en règle générale, seuls les spécialistes professionnels de l'assurance qualité peuvent identifier les erreurs importantes cachées dans les situations limites et les signaler de telle manière que le développeur puisse immédiatement comprendre, reproduire et, par conséquent, corriger ce bogue.Un testeur imprudent estime qu'il a parfaitement le droit à de tels rapports frivoles. S'il entre dans le département QA, il devrait être averti de corriger son comportement contre-productif. Si la recherche de bogues ne relève pas de sa responsabilité directe, il devrait lui être interdit de signaler des erreurs jusqu'à ce qu'il apprenne à le faire de manière professionnelle.Il est souvent beaucoup plus efficace de simplement retirer le testeur audacieusement insouciant que d'essayer de le réparer. Par ses actions, il indique clairement qu'il ne veut pas s'engager dans des tests, donc les retirer est dans l'intérêt commun.Voir aussi: