Utilisateur:MagP/bac à sable
Cet article ne cite pas suffisamment ses sources ().
Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».
En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?
Le Test fonctionnel ou Recette fonctionnelle consiste à vérifier que l’application répond de façon optimale aux spécifications fonctionnelles qui ont été émises par le client. La Recette fonctionnelle permet non seulement de vérifier et de contrôler les aspects fonctionnels de l’application développée mais également d’apporter les derniers ajustements à la qualité et à l’ergonomie des interfaces.
Aujourd'hui une étape importante du projet informatique[modifier | modifier le code]
Reléguée à la fin du projet, exécutée rapidement et sans méthode, il y a encore quelques années, la recette fonctionnelle se réduisait le plus souvent à passer rapidement quelques tests « in situ » et à faire une démonstration au client. Reposant sur une méthodologie de projet axée principalement sur les aspects techniques le test fonctionnel s’inscrivait dans la lignée des méthodes dites « linéaire ». Ces projets aboutissaient généralement à la livraison d’applications qui fonctionnaient mais qui montraient des défauts, tant techniques que fonctionnels et ergonomiques, dés les premières semaines d’utilisation intensives par les utilisateurs. La survie d’applications développées dans de telles conditions dépendait alors de la capacité des équipes de maintenance à réaliser les modifications et les corrections nécessaires pour rendre l’application utilisable et viable en production. Ainsi, les gains réalisé en économisant sur la recette fonctionnelle durant la phase de projet étaient ré-impactés sur la maintenance et les coûts de correction et d’adaptation nécessaires à l’utilisation de l’application étaient alors bien plus importants, car réalisés après la mise en production, souvent par des équipes différentes de celle qui avaient produit l’application originale. Ces coûts sont d’autant plus élevés qu’ils se font alors ressentir directement sur l’activité même qui est le cœur du métier des utilisateurs en leur faisant perdre en productivité et en organisation. Enfin, il faut évoquer également les projets avortés quelques semaines après leur livraison, car impropres à remplir leurs objectifs fonctionnels de production; ainsi que ceux qui ne sont jamais adoptés et laissés de côté, car incompréhensibles et inadaptés, et pour lesquels les utilisateurs continuent à utiliser leur ancien système. Nombre de ces problèmes peuvent être évités à l'aide d'une recette fonctionnelle adaptée, préparée, planifiée et exécutée rigoureusement. Après avoir été longtemps perçue comme une contrainte, la recette fonctionnelle est reconnue aujourd’hui, avec l’écriture des spécifications fonctionnelles, comme une des étapes majeures du projet informatique, au même titre que les spécifications techniques, les tests unitaires ou la phase d’intégration.
Position de la recette selon les méthodes de Gestion de projet[modifier | modifier le code]
Une recette fonctionnelle peut différer en fonction de la nature de la méthodologie projet employée. Elle peut avoir lieu soit, en une seule fois en fin de projet, soit en plusieurs étapes tout au long du projet.
Méthodes en Cascade[modifier | modifier le code]
Terme utilisé pour décrire un enchainement d'étapes de façon linéaire. C'est ce type de méthode que l'on utilisait avant que la recette apparaisse comme une nécessité au projet informatique.
En effet a aucun moment, les test , qu'ils soient unitaires ou fonctionnels ne sont prévus dans la démarche.
Méthodes en V[modifier | modifier le code]
La branche droite des méthodes en "v" présente les différentes étapes qui vont suivre le codage de l'application pour en vérifier la conformité à chaque niveau de la conception : la recette.
Bien qu'elle présent un avantage au niveau de la préparation en amont de la recette, un inconvénient de cette méthode réside dans son principe linéaire. En effet, il n'est pas rare de voire apparaître, au moment de la recette, des aspects non prévus, soit d'ordre techniques, soit d'ordre fonctionnels, et qui nécessitent de revenir sur des phases déjà terminées.
Méthodes Agiles[modifier | modifier le code]
Ces méthodes intègrent la recette au cœur du développement, permettant ainsi, de raccourcir les cycles de détection et de correction d'anomalies. Elles permettent de s'adapter en permanence pour coller aux besoins du client, au fur et à mesure ou celui-ci se précise. Ces méthodes, par leur souplesse, présentent donc un avantage évident pour la réalisation d'une recette optimale, cependant elle sont moins adaptés pour des projets de grande taille ou touchant à un grand nombre de services et d'activités différentes de l'entreprise où il est nécessaire de poser des jalons pour éviter un manque de coordination.
Les Acteurs de la recette fonctionnelle[modifier | modifier le code]
Au niveau de la recette fonctionnelle, le mieux pour le projet est qu’elle soit exécutée par une équipe qui dépend du client qui en a exprimé le besoin. L’idéal étant de disposer d’une Assistance à Maîtrise d’Ouvrage (AMO) qui peut épauler la Maîtrise d’Ouvrage (MOA). En effet, la MOA connaît parfaitement son métier et ses process fonctionnels. Mais il lui manque la compétence informatique pour définir son besoin, connaître les possibilités et les solutions qu’un système informatique peut lui apporter. Ainsi, une AMO est nécessaire, non seulement pour définir le besoin et rédiger les spécifications, mais également pour préparer et exécuter la recette fonctionnelle.
Encore une fois, il est là aussi préférable de distinguer d’une part les membres de l’équipe qui seront spécialisés dans la gestion du projet et ceux qui seront plus spécialement dédiés à la recette. En effet, comme pour les tests techniques, la recette fonctionnelle nécessite des connaissances et des compétences spécifiques. C’est pourquoi dans le cadre de projets importants, il est préférable de renforcer cette AMO pour cette phase du projet.
Organisation générale de la recette fonctionnelle[modifier | modifier le code]
Stratégie[modifier | modifier le code]
Au fur et à mesure de l’avancement de la recette et des itérations avec les équipes techniques,les tests fonctionnels peuvent s’affiner. Ainsi, en début de recette, il est préférable de passer de simples tests de validation servant à valider la livraison d’une nouvelle version de l’application. Ensuite, des tests détaillés servent à couvrir le maximum de surface du périmètre de l’application. Enfin, quand l’application est consolidée, qu’elle commence à être plus fiable et robuste et que le nombre de défauts devient de moins en moins important, il peut être intéressant de passer au test de bout en bout qui, comme son nom l’indique, couvre l’intégralité du process de l’application. Il peut également être profitable de pouvoir lancer régulièrement, à chaque livraison d’une nouvelle version de l’application, une batterie de tests de non régression qui permettent de valider que les derniers développements ne génèrent pas d’anomalies indésirables dans des périmètres déjà testés et théoriquement validés.
en fonction de la méthodologie de projet[modifier | modifier le code]
En effet, la stratégie de recette et l’exécution des tests va être très différente si on se place dans un contexte Agile ou dans un contexte linéaire. Ainsi, avec une méthodologie qui va comporter des itérations fréquentes et des tests unitaires et fonctionnels étalés sur toute la période des développements, la stratégie de recette va plutôt être évolutive, et requérir une certaine souplesse pour s’adapter aux évolutions régulières de l’application. Par contre, dans une démarche plus standardisée, la stratégie de recette va être de préparer en amont les tests, en se référant aux spécifications fonctionnelles, pour être prêt à les exécuter dès que les développements seront finalisés.
en fonction du périmètre et de la configuration de l’application[modifier | modifier le code]
En effet, on ne va pas effectuer une recette d’une application de gestion lourde avec une quantité de données importante comme on va tester une application Internet reposant sur une base mySQL. L’infrastructure n’a pas la même inertie et ne nécessite pas les mêmes efforts de déploiement et de préparation de l’environnement de recette.
en fonction des contraintes de délai et d’infrastructure inhérentes à l’environnement de l’entreprise[modifier | modifier le code]
L’exemple typique est la présence ou non dans l’entreprise d’une TRA. En effet, une recette nécessite une préparation à l’environnement, une mise en place de l’infrastructure, une montée en compétence sur les métiers et sur la structure du système d’information de l’entreprise. Si cette dernière dispose d’une TRA, toutes ces étapes sont déjà acquises, et la recette dispose déjà d’un environnement, de personnels formés et habitués au système informatique de leur client.
Moyens[modifier | modifier le code]
Une fois que la stratégie de recette est arrêtée, il faut la mettre en œuvre. Pour cela, le chef de projet recette dispose de plusieurs outils sur lesquels s’appuyer. Tout d’abord, une organisation type de l’équipe avec des rôles bien définis en fonction des étapes de recette, avec des rédacteurs de test, des testeurs, des chargés de suivi des outils de recette tels que les administrateurs des environnements de test.
Ensuite, il doit mettre en place un référentiel documentaire reprenant les spécifications techniques, les plans de tests, l’archivage des résultats de campagnes, l’historique des anomalies détectées et corrigées, et enfin toutes les documentations de l’application afin de permettre à chacun des membres de l’équipe de s’y référer à n’importe quel moment. Enfin, en fonction du planning du projet informatique et des dates prévisionnelles de fin des développements, l’équipe peut commencer à planifier les différentes étapes de préparation, de rédaction et d’exécution des campagnes. Ces jalons sont indispensables pour se positionner dans le temps et évaluer régulièrement l’état d’avancement de la recette. Le but étant, bien entendu, de maintenir l’équilibre entre les budgets et les délais qui ont été assignés au projet, et les objectifs de qualités qui ont été fixés.
Les Étapes[modifier | modifier le code]
- Élaboration des cas de test
- Création des jeux de données
- Rédaction des scénarios de test
- Exécution de la recette
Concevoir les cas de test à partir des exigences[modifier | modifier le code]
La conception des cas de test est le cœur de la recette fonctionnelle. Un cas de test désigne une manipulation ou une transaction que l’on va exécuter avec l’application à tester, pour en vérifier le bon déroulement. Par exemple, dans le cas d’un site internet commercial, un cas de test possible est : « un utilisateur accède à son compte client ».
- Quand ?
Comme nous l’avons vu dans notre schéma directeur, cette conception peut commencer dès la rédaction des spécifications fonctionnelles. Mais comme cette activité est la base de la recette, il n’est pas rare de continuer à imaginer des cas de tests tout au long de la préparation et même durant l’exécution de la recette pour s’adapter et tester les livraisons successives de l’application comprenant de nouvelles fonctionnalités.
- Objectifs
L’objectif à atteindre et de couvrir au maximum l’intégralité des exigences fonctionnelles de l’application pour s’assurer que toutes vont être testées, de façon exhaustives, durant la recette. Les exigences sont extraites à partir des spécifications fonctionnelles. Il faut donc concevoir les cas de test en imaginant toutes les actions possibles qu’un utilisateur pourra potentiellement faire avec l’application.
Les premiers tests sont donc facilement transposables des cas d’utilisation tirés des spécifications fonctionnelles. Mais plus on va avancer dans le projet et que l’application va s’enrichir et se complexifier, plus on va découvrir qu’il existe également d’autres possibilités d’actions qu’un utilisateur peut faire et qu’il faut tester. C’est là que réside le cœur de la compétence d’une bonne équipe de recette : se mettre à la place de l’utilisateur et savoir imaginer toutes les manipulations et transactions qu’il sera susceptible d’effectuer dans l’application.
On parle alors de taux de couverture. Ce terme est déjà employé dans le cadre des tests unitaires, puisqu’il mesure la couverture des tests par rapport au code de l’application. Dans le cadre de la recette fonctionnelle, on parle de taux de couverture par rapport aux exigences décrites dans les spécifications fonctionnelles.
Réaliser les jeux de données[modifier | modifier le code]
Un travail qui nécessite rigueur et minutie Un jeu de données est un ensemble cohérent de données permettant de définir un cas de test dans l’application à tester. Par exemple, pour reprendre le cas du client qui se connecte, le jeu de données se compose de son identifiant et de son mot de passe.
- Quand ?
La réalisation des jeux de données commence avec la phase de conception technique qui précède le codage de l’application. Les jeux de données vont accompagner les cas de test, nous verrons pourquoi plus loin. Aussi, comme nous l’avons vu dans notre schéma directeur, il est souvent nécessaire de continuer à créer des cas de test tout au long du processus de recette. Et comme il est indispensable de réaliser autant de jeux de données que de cas de test, cette phase va se poursuivre aussi longtemps que la phase de création des cas de test.
Cette phase ne peut intervenir que quand les équipes techniques ont consolidé le format des données de l’application. En effet, il est indispensable de disposer d’une structure de données finalisée pour réaliser les jeux de test de façon définitive, et ne pas avoir à revenir dessus pour les modifier à chaque évolution technique de la part des équipes de développeurs.
- Objectifs
Le but est de disposer, lorsqu’on va se retrouver en phase d’exécution de recette, de tous les jeux de données correspondants à tous les cas de test décrit auparavant. Un jeu de données peut varier d’une application à l’autre, mais en général, il s’agit d’un ensemble de fichiers contenant les informations codées relatives à un utilisateur dans une situation donnée. Ainsi, il se peut que ces données doivent ensuite être injectées dans une base de données de test sous la forme d’un script SQL, ou envoyées sur un serveur sous forme d’un flux FTP, ou encore chargées manuellement depuis une page HTML en simulant un utilisateur. Quoiqu’il en soit, les données doivent être prévues et organisées dans un format adapté pour être facilement utilisables.
Rédiger les tests fonctionnels[modifier | modifier le code]
Le cas de test se précise et s’enrichit Un test fonctionnel est un cas de test, accompagné de son jeu de données, et dont on va décrire de façon précise le déroulement par étapes. Pour reprendre notre exemple de l’utilisateur qui se connecte sur son compte client, le test comprend une description des actions à exécuter, un jeu de données ainsi qu’un résultat attendu
- Quand ?
La rédaction définitive des tests fonctionnels peut commencer en même temps que la création des jeux de données. En effet, le cas de test décrit un comportement et un résultat attendu. Le jeu de données correspondant va contenir les valeurs des différents paramètres et données nécessaires à ce test. C’est pourquoi ces deux éléments sont indissociables pour composer un test complet. Donc, dès qu’il est possible de créer des jeux de données, il est également possible de finaliser les cas de test pour en faire des tests fonctionnels à part entière.
- Objectifs
L’objectif est de disposer d’un test complet, auto-suffisant, comprenant tous les éléments nécessaires à son exécution. Étant donné que l’on part d’une description de cas de test avec son jeu de données, il ne reste plus qu’à détailler le test fonctionnel pour le finaliser. En effet, comme son nom l’indique, un test fonctionnel doit simuler le fonctionnement de l’application dans son environnement normal, par un utilisateur final. Contrairement au test unitaire, il ne s’agit plus de vérifier la valeur de variables renvoyées par une classe de traitement, mais bien de vérifier que l’application va se comporter comme il est décrit dans les spécifications, lorsqu’un utilisateur va procéder à une transaction donnée, dans l’interface de l’application.
Ainsi, le test fonctionnel doit comporter la description d’une suite d’action précises, qui doivent être exécutées dans un ordre bien précis, afin d’obtenir un résultat ou un comportement déterminé à l’avance. L’exécution de la recette est donc basée sur la prédictibilité des comportements attendus de l’application.
Concevoir les scénarios de tests[modifier | modifier le code]
Les scénarios de test sont constitués autour des périmètres fonctionnels Un scénario de test est composé d’un ensemble cohérent de tests réunis suivant des critères de proximité fonctionnelle. Pour reprendre toujours le même exemple de notre site marchand, on peut réaliser un scénario de test « Connexion » réunissant tous les tests de connexion. Ce scénario comprendrait le cas nominal : l’utilisateur se connecte avec son identifiant et son mot de passe. Il comprendrait également tous les autres cas alternatifs : le mot de passe n’est pas valide, l’identifiant est inconnu, etc…
- Quand ?
La conception des scénarios de test peut commencer une fois que la conception détaillée de l’application est finalisée et validée. La conception des scénarios de test se poursuit donc durant toute la phase de développement qui précède la phase d’exécution de la recette. Les scénarios de test dépendent des transactions et des procédures qui vont être définies durant la conception de l’application. C’est pourquoi il est préférable d’attendre que cette phase soit finalisée et validée pour commencer à regrouper des tests et en faire des scénarios. Cela évite de les modifier à chaque changement dans l’agencement des modules et des composants de l’application au cours des itérations de conception technique et fonctionnelle.
- Objectifs
L’objectif est double : D’une part, on va constituer des scénarios avec des critères de périmètre fonctionnels, comme par exemple : scénario de tests d’interfaces graphiques, scénario de tests transactionnels, etc.. D’autre part, il faut également obtenir des scénarios qui réunissent de tests suivant des critères de phase de projet, par exemple : on va ainsi constituer des scénarios de tests exhaustifs, de tests de validation, etc...
Le but étant de rassembler les tests afin d’obtenir des scénarios cohérents qui couvrent un périmètre fonctionnel bien délimité. Au final, chaque recette fonctionnelle étant unique et dépendant de la nature de l’application testée, il faut savoir s’adapter et organiser ses scénarios pour répondre au mieux à ces deux critères : périmètres fonctionnels et phases de projet.
Concevoir les campagnes de tests[modifier | modifier le code]
La campagne de test est orientée vers l’exécution de la recette On va parler de campagne de test pour désigner l’exécution groupée d’un ensemble déterminé de scénarios sur une livraison donnée de l’application.
On constate que, jusqu’à présent, on était dans le domaine de la conception des tests, nous rentrons à présent dans le domaine de leur exécution.
- Quand ?
Cette phase se situe généralement au tout début de la recette fonctionnelle et est rapide, puisqu’il suffit juste de regrouper des scénarios. Les scénarios de tests doivent être finalisés et prêts à être exécutés. La réalisation des campagnes de test peut alors commencer, dès que les développements sont en phase de finalisation et que l’application va commencer ses cycles itératifs de livraisons successives. Une campagne de test doit être exécutée sur chaque nouvelle livraison de l’application, en suivant les cycles de développement et de correction successifs. Chaque nouvelle campagne va dépendre de la nature des corrections et des évolutions qui ont été apportées à l’application et qui sont contenues dans la nouvelle livraison.
- Objectifs
L’objectif est de tester chaque livraison de l’application afin de tester, d’une part, si les anomalies détectées précédemment ont été corrigées, et d’autres part, si des régressions n’ont pas fait leur apparition.
Exécution de la recette fonctionnelle[modifier | modifier le code]
On rentre dans la phase d’exécution de recette lorsque les développements sont au stade ou l’application fonctionne et est autonome. A ce stade, elle n’est pas encore exempte d’anomalies mais est suffisamment robuste pour être utilisée dans les conditions proches de la réalité. Ainsi, elle peut être démarrée et utilisée dans l’environnement de recette.
Présentation générale[modifier | modifier le code]
La phase d’exécution de la recette fonctionnelle commence avec la livraison en recette de la première livraison de l’application à tester. Elle va se terminer avec la signature par le client du PV de recette, lorsqu’il aura la certitude que l’application ne comporte plus d’anomalies majeures ou bloquantes.
La recette fonctionnelle est constituée d’une succession de cycle de campagnes Entre ces deux étapes, de nombreuses livraisons successives de l’application vont être testées au fur et à mesure ou les équipes de testeurs vont découvrir des anomalies et où les équipes de développement vont les corriger. Il faut bien distinguer deux notions bien distinctes dans une recette fonctionnelle : une livraison de l’application et une version de l’application :
Une nouvelle livraison désigne une nouvelle mise à disposition des testeurs de l’application, avec simplement des corrections sur des anomalies par rapport à la livraison précédente. Remarque : on utilise également souvent le terme de « release ». Une nouvelle version de l’application comprend, en plus de la livraison, une ou plusieurs évolutions des spécifications fonctionnelles par rapport aux versions précédentes, par exemple : une nouvelle fonctionnalité ou une transaction modifiée dans son déroulement.
Il est très important de bien distinguer les différences entre ces deux notions. En effet, dans le cadre d’une nouvelle livraison, les tests n’ont pas besoin d’évoluer alors que pour une nouvelle version, les fonctionnelles ont changé et les tests doivent être adaptés. Nous verrons plus loin les différences entre un cycle de recette portant sur une livraison ou sur une nouvelle version.
Étape de validation[modifier | modifier le code]
Valider la livraison pour entamer un cycle de recette A chaque nouvelle livraison, on va systématiquement procéder à une campagne de validation. C’est encore plus vrai lors de la première livraison de l’application. Les scénarios de validation reposent sur des tests simples destinés à tester les composants et transactions de base de l’application : la conformité des interfaces, les fonctionnalités de base, etc… L’objectif est de vérifier que l’application est un minimum stable et consolidée avant de se lancer dans les tests détaillés.
Les tests exhaustifs et le taux de couverture[modifier | modifier le code]
Couvrir le maximum de surface fonctionnelle de l’application L’étape durant laquelle on exécute les campagnes de tests fonctionnels exhaustifs intervient dès lors que le passage en recette de l’application est validé.
L’objectif principal est de vérifier, de façon exhaustive, que l’application livrée répond intégralement à toutes les exigences décrites dans les spécifications fonctionnelles. En d’autres termes, il faut s’assurer du plus haut taux de couverture possible pour la recette.
Etape des tests fonctionnels détaillés spécifiques[modifier | modifier le code]
Vérifier le périmètre où des corrections ont été apportées Lorsqu’on a passé l’étape de la campagne de tests exhaustifs qui a couvert l’intégralité de l’application et que l’équipe de recetteurs a remonté une première vague d’anomalies, l’équipe projet va entrer dans une suite de cycles itératifs de livraisons de l’application et de campagnes de tests. C’est lors de ces cycles que l’on va utiliser les campagnes de test détaillés spécifiques. Un test fonctionnel détaillé spécifique va servir à tester uniquement le composant ou le périmètre applicatif dans lequel il y a eu des développements pour corriger une anomalie ou faire une évolution fonctionnelle. C’est pourquoi les scénarios de tests fonctionnels vont avoir un périmètre limité, comme par exemple se concentrer sur un seul composant, mais ils vont conserver une densité de test aussi importante que les tests exhaustifs. L’objectif est de cibler la campagne de test sur le périmètre ou le composant qui a été l’objet d’une correction ou d’une évolution.
Étape de non régression[modifier | modifier le code]
Vérifier la stabilité de l’application au cours de cycles successifs Les tests de non régression vont avoir lieu en fin de cycle de recette. Ils servent à détecter une éventuelle régression suite aux développements faits sur la release en cours de recette. Une campagne de tests de non régression se compose d’un ensemble de scénarios de tests fonctionnels simples et rapidement exécutables, qui vont couvrir un périmètre très large de l’application mais avec une densité moins importante qu’une campagne exhaustive.
L’objectif principal est de compléter les tests fonctionnels spécifiques qui n’ont couvert qu’un périmètre restreint et spécifique de l’application.
Étape des tests utilisateurs[modifier | modifier le code]
Un gain pour la qualité et la conduite du changement Une étape qui peut être très enrichissante pour le projet, si les délais et les budgets le permettent sont les tests utilisateurs. Ils consistent à mettre l’application en situation avec les utilisateurs finaux. Les gains sont multiples. D’une part, les meilleurs testeurs ne rivaliseront jamais avec la manipulation d’un utilisateur final qui a ses habitudes et ses « trucs » pour faire son métier. Ensuite, c’est un très bon moyen d’avoir un retour sur l’ergonomie et les interfaces, mais surtout sur les fonctionnalités de l’application. Si le projet est structuré de telle manière pour que cette étape soit prévue, alors, c’est un vrai atout pour le projet en matière de définition du besoin fonctionnel. Les retours des utilisateurs doivent être analysés et donner lieu à des précisions du besoin et des spécifications fonctionnelles initiales. Ce concept est au cœur des méthodologies de type « Agile » car leurs concepteurs ont compris que le besoin client devait être au cœur du projet. Les gains d’une telle démarche se feront sentir non seulement sur la qualité finale de l’application mais aussi et surtout lors de la mise en production et de la conduite du changement.
Étape des tests de bout en bout[modifier | modifier le code]
Une batterie de tests exhaustifs « in situ » Les tests dits « de bout en bout » sont théoriquement la dernière étape de la recette fonctionnelle. Ils interviennent en toute fin de recette, une fois que les cycles successifs de détection et de correction ne remontent plus d’anomalies. Ils doivent valider que la recette a bien été exécutée et qu’il ne reste plus de périmètre non couvert par les tests.
L’objectif principal est de vérifier, de façon exhaustive, que l’application livrée répond à toutes les exigences décrites dans les spécifications fonctionnelles qui ont été validées par l’équipe projet. En particulier, les tests de bout en bout doivent vérifier un parcours complet de l’utilisateur tout au long des fonctionnalités de l’application, en un seul et unique test global et homogène, et non plus en plusieurs tests morcelés et composites.
Le PV de recette[modifier | modifier le code]
Le Saint Graal des équipes de développement Le PV de recette est le document qu’attendent tout particulièrement les équipes techniques et les développeurs. En effet c’est le sésame qui va leur ouvrir les portes du déploiement et de la mise en production. L’objectif principal est de signifier par ce document la garantie que l’application ne présente pas d’anomalies majeures ou bloquantes. En effet, il ne sera jamais possible de garantir, de façon catégorique, qu’une application sera exempte de toute anomalie ou défaut. Par contre, à la suite d’une recette exécutée en respectant une méthodologie rigoureuse, il est possible de garantir que les risques sont limités de voir apparaître une anomalie importante ou provoquant un blocage de l’application.
Le PV de recette est quasiment un document contractuel qui engage les équipes de recette, les AMO ainsi que la MOA, pour signifier qu’ils acceptent le déploiement de l’application. C’est également un document qui va déclencher la facturation de la prestation de développement des équipes techniques, que ce soient des équipes internes, ou des prestataires extérieurs. C’est donc un document capital qui marque de façon très significative le passage du projet de l’état de recette à l’état de production, et qui va avoir des conséquences commerciales.
Industrialisation de la Recette fonctionnelle[modifier | modifier le code]
Il existe plusieurs types d’outils pour assister les équipes de recette. En effet le temps ou les équipes assuraient travaillaient sur une feuille Excel semble bien révolu, et les budgets consacrés à la recette fonctionnelle sont en augmentation constante. Ce n’est pas étonnant quand on sait que, à titre d’exemple, sur un projet comme une application pour une sonde spatiale, 80% du budget total de développement est consacré aux tests. Ainsi, pour répondre à ce besoin croissant de rationalisation et d’industrialisation, il existe aujourd’hui sur le marché de nombreux outils spécialisés pour chaque domaine de la recette fonctionnelle.
Tierce recette applicative[modifier | modifier le code]
La TRA présente les avantages de concentrer sur une seule équipe l’ensemble des missions de recette et ainsi de capitaliser sur les compétences de personnels qualifiés et dédiés. En particulier, cette solution apporte de réels bénéfices dans des organisations importantes, qui doivent piloter un nombre important de projets simultanément, et dont le système d’information évolue régulièrement. En particulier, la TRA permet : Les compétences spécifiques en recette permettent d’améliorer la qualité des livrables et de garantir zéro anomalie critique en production La méthodologie permet de garantir le respect des dates de livraison, la traçabilité des travaux, la transparence et la capitalisation des connaissances grâce à des reportings réguliers. L’industrialisation permet d’obtenir rapidement des gains de productivité sur l’activité recette Enfin, la délégation à un prestataire de l’activité recette permet de dégager des ressources en interne afin de les positionner sur des taches spécifiques AMO
Outils Logiciels[modifier | modifier le code]
voire "w:Test management tools".
Les normes de qualité : un besoin de standardisation[modifier | modifier le code]
Parmi les plus répandues:
- Capability Maturity Model Integration (CMMI)
- Information Technology Infrastructure Library (ITIL)
- ISO 25000 / SQUARE
- La certification ISTQB
Les normes de qualité émises par les différents organismes ne sont pas concurrentes mais plutôt complémentaires.
On constate que CMMI est plutôt orienté vers les projets et les processus, tandis que ITIL couvre plutôt le périmètre de l’infrastructure de l’entreprise de services et de l’exploitation des applications. Ils sont ainsi complémentaires et peuvent être mis en œuvre conjointement : ITIL pour définir la structure des services, et CMMI pour optimiser les projets.
On constate également la complémentarité d’une équipe de testeurs certifiés ISTQB et du respect des normes ISO 25.000 dont l’association permet également de couvrir un bon périmètre des domaines de l’entreprise. N’étant pas exhaustive, on peut considérer que cette solution, plus simple à mettre en œuvre, et plus légère, est mieux adaptée aux petites structures.
Notes et références[modifier | modifier le code]
Thomas Barjou, Comment améliorer la qualité et créer de la valeur ajoutée pour le projet informatique, en s’inscrivant dans une démarche de rationalisation et d’industrialisation de la recette fonctionnelle : Mémoire de fin d'étude génie du traitement de l'information,
Bruno Legeard, Fabrice Bouquet et Natacha Pickaert, Industrialiser le test fonctionnel, DUNOD,
Jean-François Pradat-Peyre et Jacques Printz, Pratique des tests logiciels, DUNOD,