Bonjour chers lecteurs, bienvenue ! Cet article fait partie de la série Z to A Pulse : Report spotlight, où nous publions nos réflexions sur les conclusions de noms réputés tels que : World Quality Report, Gartner, Forrester, etc. Nous analysons leurs conclusions et leurs tendances avec l’aide de nos leaders en ingénierie, puis nous partageons les idées pour vous aider à atteindre l’excellence en matière d’ingénierie. Abonnez-vous en cliquant sur le bouton ci-dessus pour lire les prochaines éditions.

Dans le sujet…

En tant que responsable de la qualité du produit, vous avez fait vos devoirs et obtenu un budget pour l’automatisation des tests.

…Recherche de nouveaux outils “plug and play” sur le marché

…Construire le cadre d’automatisation “parfait

…Mais toujours pas d’avantages réels…

Cela vous rappelle quelque chose ?

Vous n’êtes pas seul !

Le dernier rapport mondial sur la qualité (2022-23) indique que

Nous étudions le sujet de l’automatisation des tests depuis de nombreuses années, et il est décevant de constater que les organisations ont encore du mal à faire fonctionner l’automatisation des tests. Les résultats de l’enquête indiquent que les équipes disposant d’un processus Agile mature tirent généralement plus d’avantages des activités d’automatisation des tests.

Le rapport développe et définit les deux défis les plus courants auxquels les entreprises sont confrontées en matière d’automatisation des tests :

L’automatisation des tests n’est pas toujours naturellement intégrée au processus de développement, mais organisée comme une activité distincte, indépendante du développement et des tests eux-mêmes.

Les équipes donnent la priorité à la sélection des outils d’automatisation des tests, mais oublient de définir un plan et une stratégie d’automatisation des tests appropriés.

Rencontrez notre source :

Saif et Sujatha ont passé plus de 50 000 heures à aider les équipes d’ingénieurs à fournir des produits parfaits et des expériences utilisateur transparentes.

Voici ce qu’ils ont à dire sur le sujet.

L’automatisation des tests n’est pas toujours naturellement intégrée au processus de développement, mais organisée comme une activité distincte, indépendante du développement et des tests eux-mêmes.

Keerthi : Sujatha, je me demande si les équipes d’ingénieurs n’ont pas encore réalisé le SDLC axé sur l’agilité ?

Sujatha : Il existe aujourd’hui de nombreuses interprétations différentes de l’Agile. Pour certaines équipes, Agile = faire les choses rapidement. Cela peut conduire à une situation où l’effort de test est minimisé et où l’équipe se retrouve avec un carnet de commandes d’automatisation des tests.

Généralement, l’automatisation des tests est introduite dans une équipe Agile par la création d’une équipe distincte chargée du développement et de la maintenance des scripts d’automatisation. Cette équipe travaille en parallèle avec l’équipe de développement, qui est chargée de créer de nouvelles fonctionnalités.

Cette approche n’est pas mauvaise en soi. À un moment donné, l’automatisation des tests est nécessaire, et c’est une bonne façon de commencer. Cependant, les deux équipes doivent finalement fusionner, et c’est là que les problèmes surviennent souvent.

Lorsque les deux équipes sont séparées, elles travaillent souvent en vase clos et ne collaborent pas efficacement. Cela peut conduire à des efforts décousus et à un manque de communication. Il en résulte un énorme retard dans l’automatisation des tests, et l’équipe peut ne pas être en mesure de suivre les évolutions du produit.

Pour éviter ces problèmes, les équipes de développement et de test doivent travailler ensemble pour identifier les bons tests à automatiser et utiliser un cadre d’automatisation commun. Cela permettra de s’assurer que l’automatisation des tests est efficace et que l’équipe peut suivre les évolutions du produit.

Vous pourriez être intéressé par :

Enigme de l’automatisation des tests : vue Zuci

Saif : Pour éviter les échecs de la transformation agile, il est utile de garder à l’esprit les points suivants –

1. La sensibilisation à la méthode Agile est le strict minimum requis au sein de l’organisation. Une fois ces éléments mis en place, il est plus facile de prendre de l’élan.
2. Je commence toujours par une matrice dans mon esprit : qui est responsable, qui doit rendre des comptes, qui est le consultant et qui sont les personnes qui doivent être tenues informées. Ce document peut ensuite être publié à l’intention des parties prenantes, ce qui constitue une bonne pratique.
3. Ensuite, il y a les techniques d’estimation. L’approche agile vous offre différentes méthodes comme le poker, l’intuition, etc. pour estimer les efforts qui vous attendent. Cela vous donne également la possibilité de revenir à la ressource qui travaille sur le sprint en question pour obtenir une estimation de l’effort, et il est important de valider leur compétitivité. À ce stade, on peut suggérer, par exemple, d’opter pour la méthode du poker. L’estimation indiquée par la majorité des cartes de poker de la table est prise en compte et les ressources doivent travailler dans cette catégorie d’estimation.
4. Enfin, pour chaque sprint, veillez à ce que les points de récit, la vitesse de l’équipe et les tâches prioritaires soient publiés à l’intention des parties prenantes et des autres personnes concernées. Ainsi, toutes les personnes présentes à la réunion peuvent discuter des déviations ou des priorités ad hoc, et une certaine capacité peut être réservée à ces tâches avant de passer à autre chose.

Les gens devraient commencer à croire que l’approche Agile n’est pas une solution unique à tous les problèmes, mais qu’elle vous aidera à identifier les problèmes à un stade précoce afin que vous ayez le temps de les corriger. Il appartient ensuite aux parties prenantes de prendre les mesures nécessaires.

Si vous minez ces problèmes et les laissez coexister sans les résoudre de manière permanente, vous allez échouer.

Keerthi : Comment savoir si les pratiques agiles de l’entreprise sont suffisamment matures ?

Sujatha : Beaucoup d’équipes essaient d’aller vite, mais elles finissent parfois par aller dans la mauvaise direction. Cela peut se produire lorsque les équipes privilégient la rapidité au détriment de la qualité.

C’est un signal d’alarme si vous vous concentrez sur la création de nouvelles fonctionnalités et ne consacrez pas suffisamment de temps aux tests. Cela peut entraîner des lacunes en matière de qualité qui finiront par vous ralentir.

Il est important de définir des indicateurs pour chaque processus et de les suivre dans le temps. Cela vous aidera à découvrir vos indicateurs avancés et retardés. Si tout semble correct, mais que vous constatez toujours un grand nombre de défauts P0 P1, c’est que quelque chose ne va pas.

Et c’est là que les équipes voudraient faire appel à une tierce partie. Un consultant externe en assurance qualité pourrait venir examiner l’ensemble de vos processus d’ingénierie et de publication et vous donner des recommandations. Ils peuvent vous aider à identifier les domaines dans lesquels vous pouvez améliorer votre qualité et votre rapidité.

Les domaines suivants peuvent être analysés :

Voici un exemple de questionnaire pour évaluer la maturité de votre équipe en matière d’assurance qualité.

Questionnaire d’évaluation :

• Les exigences sont-elles communiquées aux testeurs ? Comment et quand ?
• Les exigences sont-elles formulées de manière suffisamment détaillée dans le DRF ?
• Les exigences sont-elles documentées avec des hypothèses ?
• Le responsable de l’assurance qualité participe-t-il aux discussions/clarifications sur les exigences avec l’analyste commercial, le client ou le développeur ?
• Les exigences sont-elles analysées et comprises à la fois du point de vue du système et du point de vue de l’entreprise par le développeur et l’assurance qualité ?
• Les modifications des exigences sont-elles communiquées aux testeurs ? Comment et quand ?
• Traçabilité des exigences – La traçabilité des exigences par rapport au code est-elle assurée ? Comment?
• Comment les modifications des exigences et du champ d’application sont-elles gérées ? Référentiel/outils ?
• Qui contrôlera (approuvera/rejettera) la modification de l’exigence ? (sorte de comité de contrôle des changements)
• Le changement d’exigence est-il pris en compte de manière détaillée ?
• Quelle est la fréquence à laquelle les changements d’exigences sont acceptés sans compromettre le jalon ?
• Existe-t-il un plan d’expérience pour déterminer la relation de cause à effet ?
• La documentation détaillée est-elle disponible pour les fonctions basées sur les drapeaux ?
• Existe-t-il une documentation sur la préparation des données de test ?

Pour consulter le questionnaire d’évaluation complet sur la planification des tests, les tests, l’analyse générale des métriques de test et l’automatisation, envoyez un “salut” à sales@zucisystems.com ou commentez ci-dessous dans cet article.

En savoir plus : Sujatha briefe – 4 métriques de test logiciel les plus cruciales de sa liste.

Keerthi : Je pense que peu d’entreprises réalisent les avantages de l’automatisation des tests parce qu’elles sont suffisamment mûres dans leurs pratiques de test et que leurs efforts sont décousus. Quand savez-vous que votre organisation est prête pour l’automatisation des tests ?

Sujatha : Votre carnet de régression ne doit pas être trop volumineux ni constituer une longue feuille de route. Essayez de ne pas tout couvrir avec l’automatisation, mais plutôt de couvrir ce qui est essentiel pour l’entreprise. Construisez un backlog d’automatisation de la régression qui peut être réalisé dans un laps de temps plus court et commencez à consommer les scripts dès la semaine 1.

Ensuite, vous devriez lentement introduire l’automatisation dans l’équipe de sprint afin qu’elle puisse travailler sur les histoires d’utilisateurs actuelles et la suite de régression et réaliser l’automatisation en cours de sprint.

Chaque fois qu’une demande de changement est formulée, vérifiez si des scripts de test pertinents doivent être modifiés. Trouvez les cas de test critiques pour l’entreprise et mettez-les à jour dans la suite principale.

Fusionnez l’équipe d’automatisation des tests et l’équipe de sprint afin que l’équipe de régression dispose d’un retour d’information continu en termes de couverture des tests, etc. Cela permettra de s’assurer que la suite de régression est maintenue à jour et que l’équipe est en mesure d’identifier et de corriger rapidement les éventuelles régressions.

Pour l’un de nos clients, l’automatisation de la production était l’un des objectifs à atteindre et nous avons contribué à l’élaboration d’une feuille de route qui l’a aidé à atteindre progressivement ses objectifs.

1. L’équipe de sprint du client était composée d’une équipe de développement et d’une équipe de tests manuels.
2. Les ingénieurs de Zuci spécialisés dans l’automatisation des tests ont été intégrés à l’équipe.
3. Les ingénieurs TA ont travaillé sur la suite d’automatisation UAT
4. Notre équipe s’est entretenue avec le PO et a compris les cas de test critiques pour l’entreprise, essentiels pour l’approbation de la production.
5. Notre équipe a repris le flambeau et a commencé à travailler sur les dossiers de test pour l’automatisation.
6. L’exercice d’automatisation de l’UAT et de la régression s’est déroulé sur une période de 6 mois.
7. Par la suite, nous avons été intégrés dans des équipes de sprint N-1
8. L’automatisation N/In-sprint enfin réalisée

Keerthi : De manière surprenante, le rapport nous apprend que le facteur le plus important pour déterminer l’approche de l’entreprise en matière d’automatisation des tests n’est pas le retour sur investissement, mais la “maintenabilité”.

Sujatha : C’est vrai. Nous constatons que les conversations autour de l’automatisation des tests se déplacent vers la maintenance des tests et les outils de test. Il y a plusieurs raisons à cela. Tout d’abord, tout logiciel est en constante évolution, il est donc important que les scripts de test puissent être facilement mis à jour pour refléter ces changements.

Deuxièmement, les scripts de test peuvent devenir complexes au fil du temps, il est donc important qu’ils soient faciles à comprendre et à maintenir. Troisièmement, l’automatisation des tests peut être coûteuse, il est donc important de s’assurer que l’investissement en vaut la peine.

Voici quelques mesures que les entreprises peuvent prendre pour améliorer la maintenabilité de leurs scripts d’automatisation des tests :

• Utiliser une approche modulaire de l’automatisation des tests
• Utiliser des conventions de dénomination bien définies
• Utiliser des commentaires pour expliquer l’objectif de chaque script de test
• Utiliser un système de contrôle de version pour suivre les modifications apportées aux scripts de test
• Création d’une documentation sur l’automatisation des tests

Pour en savoir plus sur les meilleures pratiques en matière de maintenance des tests, cliquez ici

Keerthi : Quels sont, selon vous, les moyens d’encourager l’association test + développement ?

Sujatha : Il faut commencer par les besoins. Par exemple, lors de la phase de définition des besoins, les développeurs ne s’intéressent généralement qu’à l’amélioration des modules, du code ou de la pile technologique qui relèvent de leur champ d’application.

Mais ce qui peut être fait ici, c’est d’inclure l’équipe de test et le développeur pour analyser et prévoir l’impact des changements d’exigences sur les tests, prendre en compte la testabilité lors de la conception, etc.

Testabilité – Les développeurs peuvent écrire du code en gardant à l’esprit la testabilité en utilisant des techniques telles que les objets fictifs et les identifiants uniques pour les composants visuels et d’interface utilisateur. Cela facilite la tâche des testeurs lors des automatisations et permet de s’assurer que le logiciel est plus facilement testable.

Les développeurs peuvent décomposer les tâches complexes en petits morceaux plus faciles à tester. Par exemple, l’architecture d’une application peut être conçue de telle sorte que les tests deviennent faciles et ne nécessitent pas de multiples étapes.

Saif :

Je pense que la qualité est une responsabilité partagée, et pas seulement celle du testeur.

Dans de nombreuses équipes, les développeurs se contentent d’envoyer des déchets à l’équipe de test et n’assument pas la responsabilité de leur travail. Cela va totalement à l’encontre de l’esprit de l’Agile, car dans l’Agile, si une équipe échoue, c’est toute l’équipe qui échoue.

Les développeurs doivent valider leur code au fur et à mesure qu’ils l’écrivent. Lors de la définition des histoires d’utilisateurs, toute l’équipe, y compris les développeurs, les testeurs manuels et les testeurs automatiques, doit être impliquée. Cela permet de s’assurer que tout le monde a son mot à dire dans la définition de l’histoire et que les critères de “réalisation” sont clairs. Si l’automatisation des tests n’est pas incluse dans les critères de réalisation, la suite du carnet de régression s’accumulera et reviendra hanter l’équipe quelques années plus tard.

Nous devrions encourager les équipes et récompenser celles où les développeurs et les testeurs travaillent ensemble. Cela aidera les équipes à considérer la qualité comme une responsabilité partagée. D’après mon expérience, j’ai vu que cette méthode faisait des miracles et qu’elle contribuait également à garantir que le logiciel soit publié avec moins de bogues et que l’équipe puisse apporter une valeur ajoutée au client plus rapidement.

Les équipes donnent la priorité à la sélection des outils d’automatisation des tests, mais oublient de définir un plan et une stratégie d’automatisation des tests appropriés.

Keerthi : Sujatha, est-ce que ce qui précède signifie : Pour beaucoup d’équipes, un plan n’est qu’une formalité de plus ! Comment examinons-nous le “plan de test” aujourd’hui et donnons-nous le feu vert ?

Sujatha : Traditionnellement, les plans de test sont des documents longs et verbeux. Selon moi, le plan de test peut inclure – ce que nous allons tester pour cette version sur la base des histoires d’utilisateurs et de leur impact. Cependant, avec l’avènement des outils de gestion des tests, les plans de test peuvent désormais être concis et légers.

Les détails tels que les types de tests prévus, les cas de test, la date d’exécution et les attributions peuvent être stockés dans un outil de gestion des tests tel que TestRail, Xray, Zephyr, etc. qui sont intégrés à JIRA, ce qui permet aux équipes de suivre l’évolution de la situation et d’adapter les changements éventuels. De telles intégrations donneraient également un aperçu analytique des versions antérieures afin que l’équipe puisse en apprendre davantage sur les tendances en matière de défauts et planifier en conséquence.

Keerthi : Avez-vous des conseils pour choisir des outils d’automatisation des tests ? Je pense également que le succès de l’automatisation des tests dépendra principalement de l’approche des gens à cet égard et non des outils. Qu’en pensez-vous ?

Sujatha : C’est exact. Les outils d’automatisation des tests qui se synchronisent avec l’environnement de développement sont très utiles. Par exemple, si l’application web est développée en C sharp, écrire le code d’automatisation des tests en C sharp est bénéfique car la logique est facile à comprendre et lorsque nous sommes bloqués, les développeurs sont prêts à nous aider.

Vous bénéficierez également du soutien de l’écosystème des outils, car nous n’apportons rien d’étranger. Là encore, il ne s’agit pas d’une nécessité, mais d’un aspect positif des outils d’automatisation de la sélection. Parfois, il est nécessaire de passer à une autre pile technologique parce que l’actuelle manque de maturité et de disponibilité des compétences pour réaliser certaines choses.

Mais là encore, le succès de l’automatisation des tests ne dépend pas uniquement des outils. Vous devez être clair sur votre demande et élaborer une stratégie :

• Que sommes-nous en train d’automatiser ?
• Comment automatisons-nous ?
• Que faut-il automatiser à quel niveau (interface utilisateur, API, services) ?
• Identifier les points d’échec et en comprendre les raisons
• Identifier les bons outils et les bonnes personnes

Les parcours réussis en matière d’automatisation des tests ne sont pas liés aux outils et aux processus, mais aux personnes et à leur approche de la résolution des problèmes. Il ouvre la voie à tout le reste – Vasudevan Swaminathan, fondateur et PDG, Zuci Systems

Les outils commerciaux peuvent promettre de nombreux avantages, mais si vous ne connaissez pas le “pourquoi” de ce que vous faites, vous êtes voué à l’échec tôt ou tard.

Voici quelques réflexions finales tirées du rapport : Sur quoi les organisations doivent-elles se concentrer ?

• Travaillez plus tôt avec des experts en automatisation de la qualité.
• L’automatisation commence dès la création des exigences ; intégrez une approche axée sur l’automatisation dans les exigences et les récits.
• Obtenez un accord sur les exigences d’automatisation avant de commencer à automatiser.
• Concentrez-vous sur ce qui apporte les meilleurs avantages aux clients et à l’entreprise plutôt que de justifier le retour sur investissement. Passez régulièrement en revue vos outils et vos cadres de travail.
• Prévoyez une feuille de route pour les trois prochaines années au moins.
• Un seul outil ne peut pas tout faire. Choisissez les meilleurs outils pour le travail. N’essayez pas de faire tout avec un seul outil.
• Investissez dans les personnes.
• Arrêtez de courir après les licornes et travaillez avec les personnes que vous avez – elles connaissent votre entreprise.

Question pour vous :

Quel est le degré de maturité de vos pratiques d’automatisation des tests ?

1. 30%
2. 30-60%
3. 60-100%

Merci de votre lecture ! Nous sommes impatients d’approfondir les conclusions du rapport mondial sur la qualité dans nos prochaines éditions.

Si vous aimez notre contenu, montrez-nous votre soutien en –
en vous abonnant à notre lettre d’information trimestrielle, Sound bytes, ici.
et en partageant cet article avec votre équipe. Votre soutien nous est précieux !