La problématique :
Le but des tests systèmes (voir Niveaux de test) est de vérifier que l’application correspond bien à ses spécifications (ou fonctionnalités à travers les US).
Les tests sont alors écrits en fonctions de ces spécifications (ou US) et des scénarios qui leurs sont reliés.
Cela implique donc une limite importante :
Sur toute application, l’utilisateur est libre de faire le parcours qu’il souhaite, de faire certains enchainements d’actions qui n’ont ni été anticipés ni même envisagés. Il existe aussi des scénarios non testés car considérés comme cas des cas marginaux et non spécifiés. On peut donc se poser la question suivante :
Qu’arrive-t-il lorsque qu’un scénario non prévu est effectué par un utilisateur ?
Par définition ce scénario n’est pas couvert par les tests systèmes… La réponse à cette question est donc simple : On ne sait pas !
L’application peut « Crasher », retourner sur sa page d’accueil … ou tout simplement continuer de fonctionner correctement. C’est simple sur ces scénarios, les tests systèmes n’apportent aucune visibilité.
Certes, il est évidemment impossible de tester tous les scénarios et quasiment impossible (et surtout inintéressant dans la quasi-totalité des cas) d’avoir une application sans bug. Néanmoins il est obligatoire que l’application soit utilisée d’une manière non prévue par les spécifications et il faut donc avoir un minimum de visibilité là-dessus.
Prenons un exemple :
Nous avons ici un parc vu de haut.
En bleu, les zones non piétonnes dédiées à la végétation.
En vert, les zones prévues pour les piétons.
En rouge, les zones dédiées non piétonnes dédiées à la végétation mais empruntées par les promeneurs (comme un raccourci)
Les scénarios de raccourci ne sont pas prévus mais il va falloir prévoir quelque chose pour faire face à cette situation car on ne se sait pas comment la végétation du parc va réagir ou réagit s’il est déjà ouvert.
· L’idéal est lorsque le problème est anticipé et que le parc n’est pas encore ouvert (retour marketing ou expérience du testeur). Il est alors possible d’ouvrir le parc à seulement quelques personnes et voir comment ils agissent et comment le parc réagit. (une bêta test)
· Si le parc est déjà ouvert et que cela affecte fortement la végétation, on peut tenter de limiter l’utilisation de ces chemins non prévus. Il est possible d’ajouter des panneaux ou de mettre des barrières (intégration de messages d’avertissement) …
· Il est également possible de baliser de nouveaux chemins passant par ces raccourcis (en mettant à jour les spécifications et les campagnes de test), surtout si cela n’affecte pas ou peu la végétation (modification des spécifications).
· Enfin, il est également possible de ne rien faire si cela ne pose pas de problème majeur. Il serait tout de même avisé d’inclure l’utilisation de ces parcours dans les tests de régressions si les utilisateurs les affectionnent.
Les solutions du test :
Afin d’avoir une meilleure visibilité de la qualité d’une application avant sa mise en production, le test a plusieurs outils, en voici 2 :
– Les tests exploratoires qui permettent de tester l’application sans suivre des scénarios écrits à l’avance et permettant de sortir des sentiers battus.
– Les tests d’acceptance qui peuvent être sous plusieurs formes : tests bêta, tests du Product Owner en Scrum, tests du marketing, Crowd testing…
Comme vous pouvez le constater, il n’y a pas de solution cadrée comme l’on peut cadrer les tests systèmes, d’intégration ou unitaires. Afin de limiter ces problèmes il faut connaitre l’application, les utilisateurs et faire des tests d’un point de vue utilisateur.
Ce type de test est fortement dépendant du testeur et de ses connaissances et il est compliqué de le remplacer par un automate ou même de limiter l’impact du changement de testeur par des tests bien écrits et de bons processus.
Néanmoins ces tests restent nécessaires afin d’assurer la qualité souhaitée pour l’application.
Conclusion :
Les tests ce n’est pas que les tests système, et ce, même si les « testeurs » travaillent principalement sur ces tests (les tests unitaires, d’intégration et d’acceptance étant généralement exécutés et conçus par d’autres membres du projet).
Ce n’est pas parce que les tests système sont tous bons que l’application est bonne pour les utilisateurs !
De même la qualité d’une application ne peut pas être assurée uniquement par une équipe. La qualité d’un logiciel est le fruit d’un travail d’équipe. Cette équipe est composée par l’ensemble des membres du projet.
N’hésitez pas à rejoindre le groupe Le métier du test
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
