FAQ Tests agiles

Les questions les plus posées

Bien entendu, il existe des méthodes pour y parvenir. L'une d'entre elles consiste à impliquer les testeurs très tôt, dès la phase de définition des besoins, grâce à des méthodes telles que le développement piloté par les tests d'acceptation. Cela permet à tous les acteurs de discuter de la solution et du comportement attendu avant que le développement ne commence pour chaque exigence individuelle. Vous pouvez alors commencer à concevoir les tests avant même qu'il soit possible de les tester.

Tester chaque exigence après qu'elle a été codée est également une possibilité, car vous pouvez spécifier que le test sera une étape avant que la définition de "done" ne soit remplie. Les testeurs peuvent alors commencer à tester avant que l'ensemble du projet ne soit terminé, ce qui est nettement préférable dans un environnement agile. En fonction des compétences techniques des testeurs, il est également possible d'utiliser la programmation en binôme avec les testeurs et les développeurs, mais c'est une méthode qui nécessite un peu plus de compétences.

Une certaine forme de carte mentale et l'apprentissage d'au moins un langage de script à utiliser. Si vous utilisez une carte mentale lorsque vous testez ou planifiez vos tests, vous pouvez en pratique la remettre à un développeur qui pourra suivre exactement ce que vous avez fait graphiquement, sans avoir à lire 14 pages A4 de documentation. Il peut voir où cela s'est mal passé et obtenir un lien vers le rapport de bogue. Tout devient beaucoup plus compréhensible. J'aime Notepad++ et Xe Max, dans lesquels on peut créer de bonnes macros. Ensuite, j'utilise toujours un outil de presse-papiers.

L'utilisation du même tableau agile que le reste de l'équipe, des collègues ou de l'entreprise facilite les choses. Si vous disposez d'un outil que les gens utilisent et regardent, il n'y a aucune raison d'introduire un nouvel outil ou un outil parallèle. Conseils concrets si vous n'avez pas encore d'outil : Asana ou Trello.

Conseils pour motiver les développeurs de votre équipe à assumer une plus grande responsabilité dans la qualité du code que vous développez.

Vous pouvez approcher les développeurs de différentes manières en fonction de leur personnalité. Je ne pense pas qu'il y ait vraiment de processus établi pour cela, mais le plus grand facteur de réussite pour moi est d'approcher les développeurs et de leur proposer de s'asseoir avec eux et de tester pendant un certain temps dès qu'ils ont quelque chose de testable.

Parlez aux développeurs, soyez avec eux, soyez à côté d'eux, demandez-leur comment les choses se passent. Et posez la question de savoir quand vous aurez quelque chose de palpable et de compressible. Ensuite, vous pouvez vous asseoir ensemble et tester, peut-être pendant un quart d'heure, une demi-heure, peut-être une heure entière. Avec un peu de chance, je peux introduire différentes techniques de test, et les développeurs pensent que c'est très amusant d'apprendre quelque chose de nouveau. Et si vous trouvez beaucoup de bogues, il est généralement plus facile de se rapprocher des développeurs, parce qu'ils voient l'intérêt de pouvoir les trouver plus tôt.

Il faut également être très réactif, car certains développeurs veulent périodiquement s'asseoir concentrés et penser par eux-mêmes, et il faut les laisser faire.

Les plus grands pièges se trouvent lors de l'introduction des tests agiles. Les tests agiles consistent simplement à déplacer le travail de qualité vers la gauche - shift left. Cela inclut des activités qui peuvent ne pas être des tests purs, par exemple les revues de code, et vous pouvez avoir la superstition qu'il est très rapide de l'introduire.

Mais il s'agit d'une question de changement culturel. Par conséquent, le plus grand piège est simplement que vous êtes trop pressé, vous pensez que cela ira vite et que tout le monde peut tester. Dans une certaine mesure, oui, mais c'est une question de compétences et d'état d'esprit, tout le monde n'a pas forcément la volonté et la familiarité nécessaires pour devenir un bon testeur. Il faut donc créer une culture et cela prend du temps. Et c'est la première étape - laisser le temps au temps.

Il y a ensuite une superstition dans l'automatisation, qui veut que l'on puisse tout automatiser. Vous appuyez sur le bouton vert de déploiement lorsque vous avez écrit votre code, il est mis en production et tout le monde est content. Il y aura des étapes intermédiaires qui prendront du temps à élaborer, qui seront toujours manuelles et qui devront être travaillées.

Je pense donc qu'une certaine dose de superstition et le fait d'être trop pressé sont les plus grands pièges.

Pour en savoir plus, lisez notre article : https://qestit.com/fr/blog/5-pieges-dans-les-transformations-agiles/

C'est le genre de réponse que vous ne voudrez peut-être pas donner - cela dépend entièrement de la façon dont le rôle de chef de test se présente aujourd'hui dans les différentes organisations.

Mais si l'on considère le responsable des tests dans une équipe agile, je ne pense pas que ce rôle subsistera, mais le responsable des tests deviendra un peu comme une araignée dans la toile. La personne qui regarde ce qui se passe et qui synchronise les équipes. Car je pense que les équipes de test pures disparaîtront, c'est-à-dire les groupes d'AQ.

L'assurance qualité et les tests seront confiés aux équipes et le responsable des tests, s'il subsiste, sera un coach. Il examinera les outils communs, les processus communs, les effets de synergie, etc. Ensuite, le rôle de chef de test sera probablement transféré progressivement vers d'autres rôles, peut-être des rôles de gestion. Et comme l'a dit ma collègue Amanda, il se peut que vous vous penchiez davantage sur les processus agiles que sur les tests, parce que les tests en tant que tels seront intégrés dans l'état d'esprit de la qualité et les activités que vous faites pour simplement augmenter la qualité de ce que vous produisez.

Mais cela ne se fera pas du jour au lendemain et prendra probablement quelques années. Ainsi, le rôle de chef de file des essais restera dans une certaine couleur et sous une certaine forme pendant un certain temps.

Les fois où cela s'est très bien passé, c'est lorsque je me suis assis et que j'ai codé avec un développeur. Nous nous sommes assis tous les deux et avons écrit le code de la fonctionnalité, puis le code de test, et nous avons écrit au niveau de l'unité, puis au niveau de l'indication. Et s'il s'agit de quelque chose de petit et de léger, nous pouvons peut-être le mettre en production tout de suite et voir que c'est fait et sorti dans les trois heures que nous avons passées ensemble au bureau. Tous les éléments sont alors intégrés très naturellement et facilement, et il est généralement très facile pour les développeurs de continuer à travailler aussi tard.

Ils doivent ensuite assumer la responsabilité de la publication de produits moins bons. S'il s'agit de quelque chose de moins critique, il est possible de faire un peu plus d'essais et d'erreurs. L'équipe doit être autorisée à échouer de temps en temps pour progresser.

Je pense que les tests d'acceptation par l'utilisateur ont leur place, même dans le cadre des tests agiles. En effet, il ne faut pas seulement faire les choses de la bonne manière, mais il faut aussi faire les bonnes choses. Et la dernière chance de le valider, c'est d'avoir un test d'acceptation par l'utilisateur à la fin. Il doit être exécuté dans un environnement sacré, très proche de la production, où l'on ne publie pas de déchets, mais où l'on utilise une sorte de bac à sable et où l'on teste d'autres choses.

L'agilité est, après tout, une manière de travailler sur la façon de se développer par petites étapes itératives. Ensuite, le fait que cela ne passe peut-être pas immédiatement en production, c'est une autre question. Il y a donc de grands avantages avec le développement agile, indépendamment de cela.

Le fait que vous ne déléguez pas les tâches à plusieurs niveaux, mais que tout le monde participe pendant le développement. Les tests interviennent tôt, les exigences sont incluses, l'aspect commercial est inclus, et ainsi de suite. Donc, ce processus est excellent. Ensuite, bien sûr, vous voulez le mettre en place assez rapidement aussi, pour pouvoir voir s'il fonctionne. Si vous n'avez pas cette opportunité, c'est un peu malheureux, mais cela ne m'empêcherait pas de faire respecter un processus de développement agile. Parce que ce sont un peu deux choses différentes de toute façon.

Le plus grand changement à opérer concerne la communication et la collaboration entre les différents rôles. La clé du succès consiste à amener les différentes compétences à coopérer plus étroitement dans leur travail quotidien. L'agilité étant une culture plutôt qu'un processus, il s'agit de favoriser une telle culture dans l'ensemble de l'organisation. Cela s'applique également au niveau de la direction, qui doit passer du statut de gestionnaire contrôlant à celui de leader facilitateur, deux concepts très différents. Il est important d'introduire les changements par petits morceaux à la fois.

Un "testeur" peut avoir autant de définitions qu'il y a de... Eh bien, de testeurs. En tant que testeur, que devez-vous savoir pour faire du bon travail dans votre contexte ? Que devez-vous savoir pour résoudre vos problèmes et pour pouvoir aider votre équipe de la meilleure façon possible ?

Pour être un peu plus concret, et ne pas simplement poser des contre-questions, je peux dire que j'ai beaucoup bénéficié de ma capacité à programmer. Cela facilite mon propre travail, car je peux facilement traiter les sorties des fichiers journaux, des bases de données ou similaires pour trouver des informations. Cela me donne également la possibilité, par exemple, de créer des données de test et d'automatiser des tâches répétitives ou chronophages. De plus, il m'est plus facile de transmettre des descriptions de problèmes à d'autres programmeurs de mon équipe, car je peux indiquer la ligne de code exacte qui pose problème, suggérer une solution concrète, voire même apporter mes propres corrections de bugs.

Plus vous en saurez, plus vous vous amuserez ! Il n'y a aucune raison de ne pas apprendre la programmation - ou quoi que ce soit d'autre, d'ailleurs !

Si par "définition de prêt" vous entendez "quand cette exigence documentée est-elle dans un état tel que je puisse, en tant que membre de l'équipe, commencer à mettre en œuvre une solution en étant persuadé qu'elle répondra aux attentes", alors la réponse est l'équipe.

Dans un monde agile, il y a souvent des sessions récurrentes au cours desquelles l'équipe passe en revue les exigences du carnet de commandes avec le propriétaire du produit afin de résoudre toutes les questions et de s'assurer que tout le monde est d'accord sur ce qui doit être fait, pourquoi cela doit être fait et comment, ensemble, nous rendons l'utilisateur final heureux et satisfait de la livraison.

Le meilleur moyen d'inciter les développeurs à renoncer aux jalons est de ne jamais, au grand jamais, pénaliser un développeur qui renonce à un jalon. En effet, s'ils considèrent qu'il est négatif d'abandonner des jalons, ils cesseront de le faire. Mais je fais généralement le contraire : si je découvre un problème, je consacre une heure par jour ou quelque chose du genre à aider le développeur. Le développeur peut avoir besoin d'aide pour trouver des données de test, pour exécuter des tests, pour n'importe quoi.

Il ne faut donc jamais punir les développeurs pour ce qu'ils font. Cela suppose que je puisse et doive approcher les développeurs, qu'il y ait un moyen d'entrer, que je puisse m'asseoir à côté d'eux et parler, avoir une communication. Veillez à ce que votre présence soit positive pour le développeur.

 

Il existe de nombreuses façons différentes de gérer cela. L'une d'entre elles, nouvelle pour moi dans le cadre de la mission actuelle, est que si une équipe construit une API que mon équipe utilisera, il incombe à mon équipe d'écrire des tests d'API dans la base de code de l'autre équipe, de manière à ce que toute l'équipe soit libre de la mettre à jour tant que ses tests de régression réussissent. Je pense que cela s'est très bien passé, parce que nous obtenons exactement la sécurité dont nous avons besoin pour utiliser l'API et qu'ils ont la liberté totale de la mettre à jour quand ils le veulent. Ce fut donc une expérience très agréable pour moi.

Sinon, cela peut facilement devenir très compliqué et encombrant, et chaque version doit être gérée et vérifiée avec les parties prenantes, et ainsi de suite, mais cela a fonctionné très facilement. Et s'il ne s'agit pas d'un cas aussi simple, comme l'API et le client. Peut-être que les deux devraient écrire du code client et ainsi de suite, alors je crois surtout qu'il faut se parler. Les développeurs des équipes, les testeurs, etc. Quelques parties prenantes de chaque équipe doivent simplement s'asseoir, discuter et élaborer un plan commun sur la façon de procéder.

Étant donné qu'il existe de nombreux types d'activités d'AQ qui peuvent être réalisées par des personnes autres que des testeurs, les équipes peuvent être tenues responsables en faisant le plus possible avant le moment des tests de système et d'acceptation.

Plusieurs méthodes différentes appartenant à différents niveaux de test peuvent être appliquées. Qu'il s'agisse de collaborer à l'élaboration des exigences et de rédiger ensemble les critères d'acceptation (par exemple dans le cadre du développement piloté par les tests d'acceptation), ou d'effectuer des revues de code, d'utiliser des outils d'analyse statique du code, d'appliquer la programmation en binôme et, dans le meilleur des cas, le développement piloté par les tests (voir Développement piloté par les tests), lorsque les équipes automatisent les tests d'intégration et les tests du système, de nombreux défauts peuvent être détectés avant qu'ils n'atteignent le stade des tests du système. On peut alors se concentrer sur les tests exploratoires et, à terme, solliciter l'aide des clients ou des représentants des clients au sein de l'organisation pour effectuer les tests d'acceptation.