Aujourd'hui, le monde célèbre le jour du testeur. A cette occasion, nous avons décidé de vous aider à regarder le travail de ces spécialistes de différents points de vue, afin que la coopération apporte à tous les participants un maximum de bénéfices et un minimum de stress.
Crédit photo: David Goehring CC BY
1. "Vérifiez à nouveau, il n'y a certainement pas de bug"
Commençons par le problème fondamental. Le forum Ars Technica a un vieux fil de discussion dans lequel un développeur parle de la haine profonde des testeurs «pédants». Il est terriblement ennuyé que certains experts en tests passent des heures à rechercher les plus petits bugs. Et ce qui est le plus désagréable, ils les trouvent toujours.
Ce qui pourrait mal tourner : tout le monde n'est pas prêt à admettre ses erreurs. Quelqu'un commence une vieille chanson sur «pas un bug, mais une fonctionnalité», essayant de prouver que tout était prévu. D'autres demandent constamment de revérifier le code et de s'assurer qu'il n'y a pas de bogue. Le testeur essaie juste de bien faire son travail, et au lieu de gratitude, il est envoyé pour un nouvel examen.
Comment être : C'est simple: si le testeur a trouvé une faille dans votre code et que vous comprenez qu'il a raison, il vaut mieux admettre ce fait. Vous avez tous les deux un seul et même objectif: libérer un produit débogué et fonctionnel. L'humour aide à comprendre ce problème. Voici un article dans lequel les testeurs ont rassemblé un «fonds d'or» de déclarations de développeurs essayant de protéger leur code. Nous vous conseillons de les parcourir et d'imaginer comment sonnent ces phrases "classiques" du point de vue du testeur.
2. «Une semaine avant la libération. J'espère que vous n'avez pas prévu d'autres choses pour les deux prochains jours. "
Parfois, le code arrive aux testeurs quelques jours avant la sortie. Ensuite, ils doivent travailler à la hâte. Certains experts en assurance qualité pensent que les collègues sous-estiment simplement leur travail. Apparemment, ils pensent que la recherche de bogues est facile et rapide, ils ont donc reporté le débogage au dernier moment.
Ce qui peut mal tourner : En cas d'urgence, les testeurs non seulement s'énervent, mais perdent leur vigilance. Le manque de temps est l' une des principales raisons pour lesquelles les testeurs ignorent les bogues.
Comment être : Il existe plusieurs modèles de développement. Du point de vue de l'AQ, il existe deux approches principales: en cascade et Agile. Dans le premier cas, les testeurs reçoivent des fragments de code par étapes. Dans le second cas, ils testent le code en parallèle de son écriture.
Agile aide à impliquer très tôt les professionnels de l'AQ dans le projet. Grâce à cela, vous n'avez pas à tester "une heure avant la sortie". De plus, cette approche permet de ne pas trouver de bugs, mais d'empêcher leur occurrence. Si vos testeurs se plaignent d'une pression temporelle constante et manquent des bogues, jetez un œil à cette méthodologie.
Photo: Tim Regan CC PAR
3. «J'ai rapidement modifié le code. Regardez, s'il vous plaît. "
Supposons que votre équipe travaille sur un modèle en cascade et sache comment planifier correctement les phases de développement. Les testeurs obtiennent le code et il semble y avoir suffisamment de temps pour le débogage. Mais les développeurs ont l'habitude de faire un minimum d'efforts à ce stade. Ils reçoivent un rapport de bug détaillé, le lisent superficiellement, éliminent rapidement les erreurs évidentes et envoient le code au prochain cycle de test.
Ce qui peut mal tourner : Le problème est que le code après des changements superficiels revient souvent avec encore plus de bugs. Le testeur a passé du temps à préparer un rapport détaillé, et en réponse, il a reçu une sorte de réponse. Il doit suivre cette voie plusieurs fois de plus simplement parce que le développeur ne veut pas passer du temps sur des "bugs mineurs".
Comment être : Évidemment, ne vous précipitez pas. Mais cela ne suffit pas. Vous devez comprendre pourquoi vous ne portez pas l'attention voulue au rapport. S'il s'agit d'une paresse banale, vous seul pouvez vous aider. Il y a d'autres raisons. Par exemple, vous pensez que les ingénieurs QA vous inondent de rapports de bugs insignifiants. Ensuite, vous devez clarifier cette question au niveau du leadership - si les testeurs vous distraient "dans les détails". Très probablement, la réponse sera oui. Certains chefs de produit demandent même aux développeurs d'ajouter spécifiquement des bogues mineurs au code afin que les testeurs soient toujours sur leurs gardes. Il est important d'adopter cette approche et de traiter les rapports de bogues avec toute l'attention requise.
4. «Il semble que j'ai déjà résolu ce bug. Mais je ne me souviens pas exactement "
Parfois, une approche superficielle est un problème systémique. Dans certaines équipes, les rapports de bogues sont perdus dans le temps et l'espace. Personne ne répond correctement aux signalements, ne signalant pas si le problème a été résolu ou s'il est toujours dans les limbes.
Ce qui peut mal tourner : les développeurs corrigent une sorte de bogue, apportent ce qu'ils pensent être des modifications «mineures» au code, oublient d'en informer les testeurs et envoient le code à la version. Par conséquent, le problème apparaît lorsqu'il est trop tard. Et le testeur est souvent «extrême».
Comment être : Le problème du chaos doit être résolu systématiquement. Le désordre nuit au développement, vous devez donc restructurer complètement le processus de communication en équipe. Ici, il vaut la peine d'utiliser les conseils de base pour établir une communication entre les développeurs et les ingénieurs d'assurance qualité: pour déterminer la terminologie; formuler clairement les exigences; introduire une hiérarchie de priorité pour divers bogues. En ce qui concerne la confusion avec les bogues, il existe de bons conseils pratiques: a) laissez les bogues tout signaler; b) il est alors important de les hiérarchiser; c) tout bogue fermé implique qu'un test fonctionnel sera écrit; d) le statut «résolu» n'est pas attribué par le développeur, mais par le testeur. Cette approche garantit que le problème est vraiment résolu.
Photo: Tim Regan CC PAR
5. «Pourquoi devrais-je tester cela? Je ne suis pas testeur! "
Dans certaines équipes, la responsabilité du débogage incombe entièrement aux testeurs. Les développeurs ne prennent pas la peine de perdre du temps sur les tests unitaires les plus évidents. Ils sont sûrs que ce n'est pas leur travail. Dans l'ensemble, c'est le cas, bien qu'il existe différents points de vue sur la question (avec les points de vue de la communauté peuvent être trouvés ici ).
Ce qui pourrait mal tourner : les testeurs dans cette situation doivent faire face à toutes les lacunes consécutives - même avec les erreurs les plus primitives et les plus stupides. Bien sûr, c'est ennuyeux.
Comment être : De nombreux développeurs préfèrent les tests indépendants avant d'être envoyés au département QA. Cela permet non seulement de soulager les testeurs, mais aussi d'apprendre à regarder le produit du point de vue du critique et de l'utilisateur. On pense que cela est utile pour les professionnels et a le meilleur effet sur le résultat final. Pour ceux qui ne veulent pas se soucier des chèques, il existe des outils automatiques. Ils aident à trouver les bugs les plus évidents. Dans tous les cas, même si l'équipe a des ingénieurs QA, une séparation stricte entre développeurs et QA n'est pas la meilleure approche.
6. «Igor, vous travaillez aujourd'hui en tandem avec Oleg. Vous l'aimerez
Les chefs de produit ne se limitent pas à l'approche en cascade et Agile. Certains aiment expérimenter. Par exemple, organisez des sessions de programmation et de test de paires.
Ce qui peut mal tourner : c'est un moyen efficace d'attraper les bogues, mais cela a aussi des inconvénients - les gens peuvent ne pas être enthousiastes à l'égard des innovations. Un spécialiste de l'assurance qualité, habitué à travailler seul, à un autre étage et sur son équipement, peut simplement être mal à l'aise de quitter l'environnement familier. En outre, il peut ne pas être banal avec l'expérience et les connaissances d'un partenaire. En conséquence, au lieu de tests productifs, les chefs de produit obtiennent deux employés mécontents.
Comment être : Le principal conseil est de ne pas vous couper l'épaule. Les pratiques Agile et DevOps peuvent sembler attrayantes, mais sans une préparation adéquate, elles ne fonctionneront pas.
7. "Je vais prendre votre appareil pour des tests, ça vous dérange?"
Le développeur a le temps de commencer le débogage, il demande au testeur un appareil de test «littéralement pendant 20 minutes» et le laisse pendant de longues heures.
Ce qui peut mal tourner : le plus souvent, le développeur ne remet pas du tout l'appareil à sa place, et s'il le fait, il est complètement déchargé. Étant donné que les testeurs peuvent avoir des tâches parallèles sur cet appareil, cela ne peut qu'énerver.
Comment être : Mettez-vous des rappels, collez des autocollants, faites n'importe quoi, mais veuillez remettre les choses des testeurs à leur place et à l'heure.
Photographie: Dave Allen CC BY
Et le principal conseil aux développeurs et chefs de produits, qui se suggère de tous les précédents: respecter le travail et le temps des autres, et se mettre le plus souvent possible à la place d'un testeur. Après tout, sans lui, le monde entier aurait été au courant de vos bugs.