D'une manière générale, le cycle de vie d'un SI peut être scindé en deux grandes phases, d'une part la phase de conception et de développement, et d'autre part, la phase de maintenance et d'évolution [32]. Dans cette optique, le « modèle de développement en V » constitue une approche traditionnelle30 du développement et du test logiciel [5] comme le montre le schéma ci-après.
29 Il existe des techniques et des outils permettant de générer automatiquement des cas de test à partir à partir d'un modèle de test définissant l'ensemble des comportements attendus à tester sur le logiciel, voir [2]. Cette méthode permet de réduire la maintenance des cas de test à la seule maintenance du modèle de test.
30 Par opposition aux méthodes agiles (itératives et incrémentales) plus récentes et censées résoudre les insuffisances des méthodes traditionnelles de développements logiciel (SCRUM, XP...). D. WATKINS montre dans [5] qu'une itération de développement d'une méthode agile peut être ramenée à un cycle en V.
Selon la norme IEEE 610 [39], le modèle en V correspond à une « une structure décrivant les
activités du cycle de développement logiciel, depuis la spécification des exigences jusqu’à la maintenance. Le modèle en V illustre comment les activités de tests peuvent être intégrées dans chaque phase du cycle de développement. ».
En général, les activités liées à la rédaction du cahier des charges et au test de recette sont prises en charge par la maîtrise d'ouvrage (MOA) qui représente le client. Les autres activités étant de la responsabilité de la maîtrise d'œuvre (MOE) choisie pour réaliser le SI (c-à-d le fournisseur), avec une implication plus ou moins importante de la MOA dans les activités de spécification, de conception et de test. Dans ce contexte, la MOA réalisera au minimum les tests de recette et d'exploitation ainsi que les test de non-régression. Les autres tests étant du ressort de la MOE, voire effectués conjointement (p. ex. les tests de performances).
5.5.2 Les tests de recette
Le test de recette (ou d'acceptation ou recette utilisateur) est effectué par la MOA et précisément par des représentants des utilisateurs et des experts métier, éventuellement assistés par la MOE. Ce test doit confirmer la réponse du logiciel aux exigences du cahier des charges et donner confiance dans le logiciel avant sa mise en production. Le représentant des utilisateurs teste le logiciel en reproduisant les tâches qu'un utilisateur accomplirait lors de l'utilisation normale du logiciel (p. ex. dérouler un processus de bout en bout).
Pour s'aider dans sa tâche, le testeur peut s'appuyer sur les techniques de test suivantes : • tests de type boîte noire et d'exécution basés sur les exigences du cahier des charges,
• tests de convivialité pour vérifier l'interface graphique du logiciel (est-elle intuitive, cohérente, facile d'emploi...) et les fonctions d'aide en ligne (sont-elles satisfaisantes...). • tests pour vérifier la documentation à destination des utilisateurs,
• tous les types de tests non-fonctionnels selon les objectifs de test poursuivis. 5.5.3 Les tests d'exploitation
Le test d'exploitation (ou d'acceptation par le service exploitation) est effectué par la MOA et précisément par des représentants des utilisateurs du service exploitation, éventuellement assistés par la MOE. Ce test doit confirmer la réponse du logiciel aux exigences d'exploitation du cahier des charges avant sa mise en production et son ouverture aux utilisateurs du service exploitation. Le représentant des utilisateurs teste le logiciel en reproduisant les tâches types qu'un utilisateur du service exploitation accomplirait lors de l'utilisation normale du logiciel.
Pour s'aider dans sa tâche, le testeur peut s'appuyer sur les techniques de test suivantes :
• tests de type boîte noire et d'exécution basés sur les exigences d'exploitation du cahier des charges,
• tests de convivialité de l'interface graphique, • tests de la documentation d'exploitation du logiciel.
5.5.4 Les tests de non-régression
Le test de non-régression (ou de régression) est effectué par la MOA ou par la MOE en fonction du cycle de développement en V. Par exemple, les tests de non-régression peuvent s'appliquer aux tests unitaires ou de recette. Il permet de vérifier le bon fonctionnement du logiciel après avoir été modifié ou étendu (modification de l'environnement de production, amélioration ou évolution fonctionnelle...).
Pour s'aider dans sa tâche, le testeur peut s'appuyer sur les techniques de test suivantes :
• tests de type boîte noire basés sur la documentation existante et éventuellement sur la documentation des nouvelles exigences.
L'utilisation d'outils spécialisés qui permettent de simuler des actions d'un utilisateur sont particulièrement efficaces pour ce type de test (p. ex. Selenium31 ou HP Quality Center32).
31 Selenium est une suite d'outils permettant d'effectuer des tests fonctionnels d'application web. 32 HP Quality Center est une suite de logiciels de tests éditée par HP Mercury.
Comme l'a montré cette troisième partie, le test permet d'une part, de vérifier la conformité du logiciel aux exigences spécifiées et d'autre part, de détecter les anomalies compromettant la possibilité de l'utiliser.
Dans ce contexte, la mise en œuvre d'un processus et de techniques spécifiques aux tests permet de contribuer à l'efficacité de l'étape de recette fonctionnelle en apportant des bonnes pratiques, des outils et des méthodes.
La quatrième partie du présent mémoire se propose de détailler les différents étapes du projet RFSI. Pour cela, j'exposerai les éléments de cadrage du projet et les travaux préliminaires qui ont mis en valeur la problématique et les difficultés rencontrées pendant l'étape de recette fonctionnelle d'un SI.
Enfin, je présenterai les activités d'ingénierie qui ont permis aboutir à la conception et à la réalisation d'une solution répondant à cette problématique et satisfaisant les besoins identifiés.
6 Une solution adaptée aux besoins de la Région
Dans le jargon de la DSI, le terme « solution » désigne un ensemble d'éléments hétérogènes qui répondent à une problématique donnée. Dans le cas du projet RFSI, il s'agit de trouver une solution permettant d'optimiser l’organisation et de simplifier l'étape de recette pendant la phase de réalisation des projets fonctionnels menés par le pôle Études. Dans la plupart des cas, une solution se concrétise par une organisation cible, de la documentation, des logiciels et des matériels mis en œuvre dans le cadre de prestations (installation, paramétrage, formation...) assurées par la MOE.