Tests d'exploitabilité

Que sont les tests d'opérabilité ?

Une fois qu'un composant logiciel ou un système a été développé, il est ensuite publié à l'intention des utilisateurs et des personnes qui doivent notamment le vendre, l'acheter, l'enseigner, l'apprendre, l'utiliser, maintenir, le supporter et, après un certain temps, le déclasser. Chacune de ces parties prenantes fournit des contextes et des attentes différents, et donc des questions de test différentes, conformément au 6e principe de test " Les tests dépendent du contexte " [ISTQB 2018].

Par exemple, afin de faciliter les activités de vente et d'achat, la solution doit être mise à disposition pour des démonstrations et des essais de la manière la plus conviviale possible. Du côté du vendeur, plus la solution est facile à déployer et à utiliser, plus il se sent en confiance et plus les démonstrations sont faciles. Outre l'instabilité sous-jacente et les tests de convivialité, la préparation à la perspective de vente devrait faire partie du backlog du produit. Par conséquent, les multiples contextes dans lesquels le produit sera utilisé devraient être un axe de qualité à prendre en compte.

Pour développer chaque axe, la technique de cartographie par empathie peut être utilisée [Osterwalder 2010]. Cette technique est très utile pour découvrir ce qui devrait avoir un impact sur ces nombreux profils. Il est relativement simple de dessiner une telle figure sur un tableau et de laisser les parties prenantes donner leur avis sur chaque partie de la carte.

‍

S'il n'est pas possible d'atteindre les parties prenantes directes, la technique du persona peut être introduite pour que les personnes participant à l'atelier de cartographie par empathie fournissent ces aperçus comme si elles incarnaient un profil spécifique. Cette technique consiste à fournir un faux profil avec suffisamment d'informations pour personnifier l'état d'esprit d'un stéréotype d'utilisateur [Hendrickson 2013][Moustier 2019-1]. Idéalement, ce stéréotype devrait provenir du marketing, mais des personae supplémentaires peuvent être générés à des fins de test spécifiques (disons "Kevin, un geek de 28 ans qui adore essayer des ready-made skiddies pour casser la sécurité des systèmes").

Impact sur la maturité des tests

Le facteur clé pour permettre des tests d'opérabilité efficaces est la capacité à récupérer les besoins des parties prenantes qui font partie du système. Une façon efficace de découvrir leurs besoins est appelée "Gemba walk". Cette technique consiste à aller sur le terrain, là où tout se passe, au lieu de concevoir les choses dans des salles de réunion. Cet état d'esprit "aller et voir" peut être institutionnalisé avec le concept X-Teams. Ce concept établit un rôle d'"ambassadeur" avec des capacités de mise en réseau personnel. Cette proximité réduit les distances avec les parties prenantes et facilite les choses.

Avec cette approche, il semble que la distance ne se compte pas en kilomètres mais surtout en termes de connaissances, d'empathie et de préoccupations. L'objectif est d'être aussi proche que possible des préoccupations des parties prenantes, en termes de sujet et de temps. En termes de système, ces "silos" établissent différents contextes dans lesquels les croyances, les valeurs, les méthodes de travail et les besoins sont générés à partir de leur propre environnement. Le modèle Panarchy fournit une vue sur les cycles de changement de contexte (alias "écocycle") et leur interaction. Lorsqu'il est combiné avec les goulots d'étranglement systémiques, les contraintes d'apprentissage et de testabilité, il apparaît qu'il existe différents niveaux d'adhésion aux contextes extérieurs comme le propose le modèle PanTesting:

• 1. Repérer les contextes auxquels vous devez vous conformer
• 2. Établir des liens avec les parties prenantes et les préoccupations appropriées.
• 3. Organiser les connexions pour intégrer les changements du contexte extérieur.
• 4. Anticiper les changements de contexte au moment où ils se produisent pour choisir la meilleure approche d'adaptation.
• 5. Fusion avec le contexte extérieur

Ces approches devraient permettre à l'équipe de disposer de critères d'acceptation efficaces dans des contextes extérieurs et, en définitive, d'améliorer à la fois le DoR et le DoD.

D'après l'approche Panarchy, il apparaît que le produit n'est pas seulement influencé par des questions commerciales et technologiques comme dans les quadrants de test agiles [Marick 2003][Bach 2014]. En essayant d'intégrer différentes perspectives ainsi que des questions organisationnelles qui ont un impact sur la qualité du produit et le rendent opérable à partir des nombreux contextes, d'où cette proposition de " quadrants de test agiles renouvelés " :

‍

Le quadrant "Supporting Lean-Agile" est lié aux activités de test qui faciliteront le flux de livraison, notamment en faisant tout en même temps, en introduisant des éléments provenant de contextes extérieurs avec les approches X-Teams ou Panarchy, voire la gestion de la dette technique.

Le quadrant "Supporting Testing" est là pour améliorer la transparence notamment par la testabilité et les revues grâce à des techniques qui peuvent être appliquées à tout niveau du SDLC allant de la rédaction des Epics/US aux phases de post-déploiement.

Le quadrant "Supporting Dev" concerne le codage et l'automatisation, qui soutiendront également les activités de test telles que l'automatisation et Jidoka, mais aussi l'artisanat logiciel qui promeut les tests unitaires et le TDD, la qualité du code et le remaniement, la modularité et l'ancrage des composants.

Et enfin, le quadrant "Supporting consumers and assets" qui s'occupe non seulement de l'utilisation quotidienne de l'entreprise et de l'utilisateur final par rôle (utilisabilité, accessibilité, ...) mais aussi de toutes les parties prenantes impliquées dans le flux de valeur opérationnel [SAFe 2021-45] telles que

• Vente / Achat (disponibilité des produits, ...)
• Formation / Apprentissage / Partage (documentation, communauté, ...)
• Assistance aux clients (gestion des erreurs, suivi, MTBF, MTTR, ...)
• Infrastructure(sécurité, performance, compatibilité, ...)

Chaque quadrant est soutenu par tous les autres.

Le point de vue d'Agilitest sur cette pratique

Agilitest facilite l'automatisation des tests fonctionnels et de performance avec un connecteur construit entre Agilitest et Octoperf pour faciliter les tests de performance. Agilitest est alors principalement présent dans le quadrant "Supporting consumers and assets", il est soutenu par les 3 autres.

De plus, comme Agilitest est basé sur le #nocode [Forsyth 2021], il facilite le flux de livraison.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍