Protocole de tests sur mes aides

mes-aides.gouv.fr possède une base de tests fonctionnels accessible à cette adresse : https://mes-aides.gouv.fr/tests

Cet outil de test permet :

• De s'assurer que les résultats du simulateur donnés à l'utilisateur sont justes (éligibilité et montants des aides)
• De faire communiquer l'équipe produit avec les intervenants extérieurs plus facilement qu'avec des documents écrits

Cette page décrit la manière dont est gérée cette base de tests, pour plus d'explications envoyez un mail à [email protected]

Comment créer un test ?

Pour pouvoir créer des cas de tests, il vous faut un compte, que l'équipe peut vous créer sur demande.

Une fois des identifiants obtenus, il suffit de :

• décrire la situation à tester avec l’interface de l’application (comme un usager) ;
• aller jusqu'à la page des résultats en fin de simulation ;
• cliquer sur le lien situé en bas de la page de résultat, à la ligne : « Partenaires : créez un test. » et
• utiliser les identifiants fournis par l'équipe.

Vous serez redirigé vers la page de création du test, la section suivante en détaille les bonnes pratiques.

N'hésitez pas à poser des questions à l'équipe par mail si vous ne comprenez pas comment l'outil fonctionne.

Méthode

Pour que cette base de tests soit maintenue dans le temps et reste de qualité, il est utile de respecter un corpus de règles simples :

• Chaque test doit être facilement identifiable : un nom explicite qui décrit le cas/règle de gestion testée sans ambiguïté, ne pas hésiter à renommer un test dont le nom n'est pas assez descriptif
• Les tests doivent être autoportants : si la règle de gestion testée est complexe, indiquer dans la description du test le détail du calcul, ainsi que les éventuels liens de référence (texte de loi, décret…)
• Les tests ne doivent tester 2 fois la même règle de gestion (par exemple avec des paramètres différents qui n'auraient pas d'effet sur le résultat)
• Par convention, lorsque l'on teste une règle de gestion donnée, on essaye de se mettre dans le "cas nominal" sur les autres règles de gestion. Par exemple, pour tester un plafond de la CMU-C, on essaye de ne pas avoir de forfait logement…
• Un test doit si possible restreindre le nombre de règles de gestion testées à la fois (et s'isoler des effets de bord des autres règles de gestion), de manière que lorsqu'une règle de gestion change, un nombre minimal de tests doit être modifié
• Les tests devront être maintenus autant que le code, leur nombre doit donc être réduit autant que possible, supprimez progressivement les tests qui deviennent obsolètes

De plus, les tests sont catégorisés à l'aide de "mots-clés". L'ordre des mots-clés est important : aller du plus général au plus spécifique. Exemple : rsa - base ressources - forfait logement

Tests créés sur cas réels

Si vous créez un test à partir d'une situation réelle (quand le résultat du simulateur est différent du résultat de l’instruction), il est utile d'indiquer :

• A partir de quel dossier le test a-t-il été créé ?

• Est-ce que le bénéficiaire perçoit des aides qui n'ont pas pu être capturées dans le pavé de ressource ?

• D'où peut provenir l'écart ? (la prise en compte d'autres aides, des règles non prises en compte, autres…)

Ces éléments nous permettront d'identifier la source de l'erreur et d'apporter les corrections nécessaires.