Ce n’est qu’un exemple de logiciel défectueux. D’innombrables autres incidents se produisent chaque jour dans tous les secteurs d’activité.

Naturellement, beaucoup d’entre nous auraient pointé du doigt l’équipe d’assurance qualité pour ne pas avoir testé correctement, car elle a toujours été considérée comme la gardienne de la qualité.

Mais cela s’applique-t-il à ce scénario ? Le jeu des reproches s’applique-t-il vraiment à un tel scénario dans le cycle de vie du développement logiciel basé sur la méthode agile d’aujourd’hui ?

La réponse est non.

Chez Zuci, nous avons travaillé avec des clients de divers secteurs pour des consultations sur la qualité des logiciels, et nous avons remarqué qu’un modèle commun émergeait : La qualité est confinée au domaine des équipes d’assurance qualité.

Dans cette édition de Z to A Pulse, nous voulons parler de la prise en compte de l’environnement.

Bonjour chers lecteurs, Bienvenue ! Cette édition de la lettre d’information mensuelle Z to A Pulse vous est présentée par Keerthi V, stratège marketing chez Zuci Systems.

Exemple 1 :

Dans le cadre d’un de ses récents engagements, Zuci Systems s’est associé à un client qui opérait dans le domaine du commerce électronique. Ce client fournissait des solutions aux opérateurs postaux, aux coursiers et aux organisations logistiques dans le monde entier. Ils ont joué un rôle crucial dans l’amélioration de l’expérience client au niveau de la vente au détail et du numérique, ainsi que dans la création de nouvelles sources de revenus et l’optimisation de l’économie de la livraison.

Le volume de transactions que leur logiciel traitait quotidiennement était stupéfiant. Il était évident que le succès de leur entreprise reposait sur la mise à disposition d’un logiciel fiable dans les mains d’utilisateurs satisfaits.

Pour que l’expérience utilisateur soit transparente, le client avait des idées claires sur les lacunes de qualité du produit et cherchait des moyens d’améliorer ses processus d’assurance qualité dans l’ensemble de ses équipes.

Ils souhaitaient qu’un tiers expérimenté et indépendant réalise une analyse des lacunes de leur configuration et de leurs processus d’assurance qualité actuels et suggère des domaines d’amélioration.

Ce fut une expérience intéressante de huit semaines, car nous avons approfondi leur suite d’applications, non seulement du point de vue de l’assurance qualité, mais aussi du point de vue des processus d’ingénierie logicielle, en prenant une vue d’ensemble de leur architecture, de leur code, de leur infrastructure et d’autres domaines pertinents.

Le résultat de nos efforts a été un rapport de 56 pages – une vue consolidée de notre approche de la qualité, couvrant tous les aspects, des exigences à la publication. Il a fourni à notre client une feuille de route pour l’amélioration, mettant en évidence les domaines dans lesquels il pouvait améliorer ses processus et garantir un niveau de qualité plus élevé.

Vous souhaitez lire le rapport ? Faites un petit coucou à sales@zucisystems.com

Chez Zuci, nous croyons en

La qualité est la responsabilité de tous

Ainsi, pour toute mission de conseil ou d’analyse des écarts, nous voulons commencer par comprendre la “culture de la qualité” chez le client.

En effet, la qualité d’un logiciel ne se limite pas aux seuls tests. Il s’agit de porter la casquette d’enquêteur et de creuser plus profondément dans le logiciel pour découvrir les inconnues.

Dans les missions de gap consulting, nous divisons notre approche en deux parties : L’évaluation du processus de test et l’évaluation du processus d’ingénierie. Cela nous permet d’évaluer de manière exhaustive toutes les pratiques suivies dans le cycle de vie du développement logiciel (SDLC).

Dans le cadre de l’évaluation du processus de test, nous nous concentrons sur trois domaines clés :

1. Ingénierie des essais
2. Gestion des tests
3. Gouvernance des tests et conformité.

Pour ce client, nous avons analysé les données de JIRA, sur une période de 12 à 14 mois, afin de mesurer des paramètres cruciaux et d’évaluer la maturité des processus du client.

Voici quelques-unes des conclusions de l’étude :

• Définir l’importance d’une stratégie de test E2E
• Établir la “définition de ce qui est fait” pour une histoire d’utilisateur
• Assurer la traçabilité des exigences jusqu’au code grâce à des outils tels que JIRA, Bitbucket et Azure DevOps.
• Mettre l’accent sur la nécessité du TDD
• Souligner l’importance de disposer d’environnements de test dédiés
• Analyse des causes profondes

Pour mieux comprendre ces résultats, j’ai contacté Dhanalakshmi Tamilarasan, responsable SDET chez Zuci Systems.

Keerthi : Pourquoi une stratégie de test E2E bien conçue est-elle importante ?

Dhana : L’objectif d’une stratégie de bout en bout (E2E) est de définir clairement et de découvrir comment un produit se comporte, à la fois en termes de fonctionnalité et d’aspects non fonctionnels. La stratégie de test doit être un document évolutif et faire l’objet de discussions régulières et cohérentes avec l’ensemble de l’équipe.

Une stratégie de test bien définie définit les lignes directrices de la manière dont nous abordons les tests pour atteindre nos objectifs de test et exécuter les différents types de tests prévus dans notre plan de test. Il englobe divers aspects tels que les objectifs et les approches des tests, les environnements de test, les stratégies et les outils d’automatisation, ainsi que l’analyse des risques avec un plan d’urgence.

En bref, la stratégie de test sert de plan d’action pour réaliser la vision globale du produit.

Keerthi : Y a-t-il des pratiques exemplaires que nous suivons chez Zuci pour concevoir une stratégie de test efficace ?

Dhana : Voici quelques bonnes pratiques à suivre :

• Séances de brainstorming avec les équipes sur tous les aspects du test avant d’aboutir à une stratégie de test.
• Examen par les pairs de la stratégie de test avec d’autres chefs de file
• Examen détaillé et approbation de la stratégie de test par les PME et les propriétaires de produits.

Keerthi : Quelle devrait être la “définition de fait” idéale pour une histoire d’utilisateur ?

Dhana :

Selon Scrum.org, une définition de done (DoD) est une compréhension partagée des attentes que le sprint (ou incrément) en cours doit satisfaire afin d’être remis aux utilisateurs.

La définition de ce qui est fait est un ensemble de règles/liste de contrôle convenu qui doit être complété pour chaque élément de travail au sein de l’équipe/de la version.

Objectifs du ministère de la défense :

• Établir une compréhension commune de la qualité et de l’exhaustivité
• Définir la liste des critères à vérifier dans chaque histoire d’utilisateur
• Assurer l’expédition de l’incrément convenu

Quelques exemples de DoD, mais non limités à

• La couverture de chaque module par l’UT doit atteindre X % avant d’augmenter la RP.
• Tous les modules développés doivent suivre le processus CICD défini.
• Min X % de l’automatisation du sprint à réaliser
• Pas de bogues de priorité 1 et 2 dans l’une ou l’autre des fonctionnalités
• Exigences non fonctionnelles satisfaites
• Mise à jour du document utilisateur

Keerthi : Pourquoi la traçabilité des exigences jusqu’au code par le biais d’outils tels que JIRA, bitbucket et Azure DevOps devient-elle nécessaire ?

Dhana : La matrice de traçabilité joue un rôle important dans la réalisation des aspects clés suivants

• Assurer la couverture des tests de toute fonctionnalité ou histoire d’utilisateur et permettre de tester les bonnes choses.
• Faciliter le triage des défauts, le RCA et l’analyse d’impact
• Réduire les reprises en gardant les défauts et la traçabilité intacts en tant que répertoire de connaissances.

Keerthi : Qu’est-ce que le TDD et quelle différence cela fait-il ?

Dhana : Le développement piloté par les tests (TDD) est un processus de développement de logiciels qui repose sur la répétition d’un cycle de développement très court : le développeur commence par rédiger un cas de test unitaire défaillant qui définit une amélioration souhaitée ou une nouvelle fonction, puis produit la quantité minimale de code pour réussir ce test, et enfin remanie le nouveau code pour qu’il réponde à des normes acceptables.

Le TDD est important parce qu’il permet de s’assurer que les logiciels sont développés en tenant compte de la qualité et de la fiabilité. En écrivant les tests avant le code, les développeurs sont obligés de réfléchir à la conception de leur code et à la manière dont il sera utilisé. Cela peut conduire à un code plus modulaire, réutilisable et testable. En outre, les tests TDD peuvent être utilisés pour détecter les défauts dès le début du processus de développement, ce qui permet d’économiser beaucoup de temps et d’argent à long terme.

Keerthi : La plupart des équipes n’ont pas d’environnement de test dédié. La plupart des tests sont effectués par les développeurs eux-mêmes dans leur environnement local – Pourquoi est-ce une mauvaise pratique ?

Dhana : Les défis liés à l’absence d’environnements de test dédiés sont les suivants :

• L’environnement de développement comporte souvent des données fictives ou un code/construction incomplet qui ne sera pas la version finale à tester.
• Ne pas faire confiance à la couverture et à la qualité des tests
• La reproduction des défauts sera un défi
• Augmentation du nombre de retouches
• Les changements continus dans la construction se produisent pendant le développement, ce qui rend les tests difficiles.

Keerthi : Comment réaliser une ACR ? Pouvez-vous partager un modèle ?
Dhana :

L’ACR sera menée en demandant à tous les membres de l’équipe de participer à une réunion ou à un appel pour examiner chaque défaut. La technique des 5 pourquoi est généralement utilisée pour déterminer la cause première, bien qu’il existe d’autres méthodes.

Actuellement, le RCCA (Root Cause and Corrective Action) gagne en importance. Au cours de cet appel, nous ne nous contentons pas d’identifier la cause première, mais nous déterminons également les mesures correctives à prendre. Cela est essentiel pour éviter que le problème ne se reproduise.

Le RCCA sera réalisé en 2 parties

1. pourquoi a-t-il été injecté ?

Il s’agit d’identifier la cause du défaut introduit du côté du développement.

2. pourquoi n’a-t-il pas été détecté ?

Il s’agit d’identifier la raison pour laquelle le défaut est passé inaperçu lors des tests, qu’il s’agisse de tests UT ou de tests fonctionnels.

Voici un exemple de modèle d’ACR

Il s’agit principalement de l’évaluation du processus de test. Nous reviendrons plus en détail sur l’évaluation du processus d’ingénierie dans les prochaines éditions. Restez à l’écoute !

Question pour vous :

Que signifie la qualité pour chaque équipe dans le cadre du cycle de développement durable ?

Merci de votre lecture ! 😊

Faites-nous part de vos commentaires ou suggestions ci-dessous. Veuillez vous “abonner” pour recevoir les prochaines éditions mettant en lumière certains des sujets les plus passionnants concernant l’excellence en matière d’ingénierie.

Si vous aimez notre contenu, montrez-nous votre soutien en vous abonnant à notre lettre d’information trimestrielle, Sound bytes ici.

La perfection. Toujours.