Contrôle empirique des processus

Le concept de contrôle empirique des processus

En 1970, Winston Royce a proposé un processus de développement de systèmes logiciels très linéaire, appelé aujourd'hui "Waterfall" [Royce 1970] [Moustier 2020]. Il savait que cette approche avait peu de chances de succès et son doute peut être expliqué aujourd'hui par le cadre Cynefin [Snowden 2007].

L'importance accordée aux individus et à leurs interactions plutôt qu'aux processus et aux outils dans le manifeste agile [Beck 2001] est une conséquence directe de ce type d'environnement, tandis qu'une approche définitive axée sur les processus est plus applicable aux environnements Cynefin "évidents", où une catégorisation du problème suffit pour appliquer une approche prédéfinie.

Le développement de nouvelles applications est un processus intrinsèquement complexe. Il implique une adaptation régulière des méthodes de travail qui émergent des observations de l'environnement dans lequel la solution évolue, et imaginer des processus bien définis s'avère rapidement lourd et préjudiciable à l'adaptabilité. Cependant, sur un projet de bonne taille, il est nécessaire d'avoir un minimum de structure pour fournir un cadre suffisamment défini pour permettre une interface simple entre les personnes et les équipes, et suffisamment flexible pour supporter l'hypothèse de variabilité [SAFe 2021-3].

Application à la maturité des tests

Que le test soit une étape (comme dans le cas de Waterfall) ou une activité intégrée au développement dans le cycle de vie de votre logiciel, le test a également tout intérêt à être "agile" dans le sens où il devrait permettre la qualité du logiciel et non être une contrainte. Dans cette perspective, les tests devraient également se concentrer sur la valeur de l'importance des personnes et de leurs interactions plutôt que sur le processus de test, et encore moins sur le cas de test.

Un scénario de test si détaillé qu'il permettrait de ramasser un passant dans la rue et de lui faire exécuter le script manuellement est donc un mauvais objectif, car remettre en question le contenu de la solution nécessiterait de mettre à jour tous les scripts avant même de commencer à tester le produit. Il est de bonne pratique de décrire les tests par leur intention plutôt que de manière extensive.

Cette approche de cas de test générique devrait également être complétée par un objectif de test pour consolider cette approche au cas où le scénario serait tellement bouleversé que le testeur pourrait adapter le scénario à la situation testée. Un autre avantage de l'objectif de test est qu'il permet au testeur de tenter d'atteindre l'objectif par tous les moyens à sa disposition ; même s'il rencontre bugs, ce ne sera pas le test qui sera " KO'd ", ces anomalies seront juste des incidents rencontrés (qui méritent évidemment d'être corrigés) mais à un haut niveau rapport de tests, le test dont l'objectif est atteint ne sera pas " KO'd " et l'exigence à laquelle il est rattaché est alors vérifiée.

Dans cet état d'esprit de test intensionnel, il y a en fait la démarche sous-jacente de test exploratoire avec l'objectif (ou même l'idée de scénario) comme charte et une durée plus raisonnable qu'une campagne entière.

La position d'Agilitest sur le contrôle empirique des processus

Pour être automatisé, un scénario écrit par intension nécessite évidemment une description exhaustive de chaque étape et semble empêcher ce principe de "définition grossière" du scénario.

Cependant, agilitest a deux approches :

• le #nocode [Forsyth 2021] qui permet une transcription rapide du script et donc une adaptation très rapide aux changements
• une heuristique particulièrement efficace pour identifier les éléments graphiques sur lesquels repose le script ; cette heuristique est basée sur des critères d'identification qui fournissent une probabilité de reconnaissance de l'élément ; cette approche permet une plus grande adaptabilité aux changements en cours de développement.

‍

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

‍