Présentation de l’atelier Examen de la stratégie de test

  • 15 minutes

Le but de Success by Design est d’assurer un résultat client réussi lors de l’implémentation de Microsoft Dynamics 365. Voici les objectifs de l’atelier Examen de la stratégie de test :

  • Favoriser la communication et la compréhension : l’atelier Examen de la stratégie de test est conçu pour engager une conversation sur la stratégie de test favorisant une compréhension générale sur l’ensemble de l’équipe d’implémentation concernant les objectifs des tests, les types de tests, la couverture et la planification des tests, ainsi que l’approche de la validation de la solution.
  • Identifier les risques et les problèmes : en examinant à la fois globalement et généralement la stratégie de test, vous pouvez identifier les problèmes et risques liés à l’approche de conception ou d’implémentation de la solution qui auraient un impact négatif sur le résultat.
  • Fournir des recommandations : sur la base des risques identifiés, cet atelier fournit des recommandations pour vous aider à mieux gérer et atténuer les risques.

L’atelier Examen de la stratégie de test peut se dérouler en personne pour des projets complexes, auquel cas il se présente généralement sous forme d’atelier unique couvrant tous les sujets requis. L’atelier se déroule le plus souvent à distance.

Les sections suivantes couvrent les aspects généraux de l’atelier Examen de la stratégie de test et fournissent un échantillon des types de questions abordées dans chaque section.

Stratégie de test globale

La stratégie de test couvre l’approche et le plan généraux permettant de confirmer que la solution sera adaptée à l’utilisation en production. Cette rubrique se concentre sur la réponse à des questions telles que les suivantes :

  • Une stratégie de test documentée est-elle en place ?
  • La stratégie de test reflète-t-elle les besoins et circonstances de ce projet ?
  • La stratégie de test est-elle exprimée dans un langage en rapport avec le projet et compréhensible par les parties prenantes concernées du projet et de l’entreprise ?

Mappage de l’étendue du projet à celle des tests

L’étendue des tests dépend clairement de celle du projet. Cette section examine la mesure dans laquelle l’étendue du projet est couverte par celle des tests.

Cette rubrique aborde la question suivante : comment, et dans le cadre de quelle phase de test ou de quel type de test, les domaines fonctionnels de l’étendue du projet doivent-ils être testés ?

Par exemple, prenons les domaines d’étendue suivants :

  • Processus d’entreprise
  • Besoins métier
  • Besoins de conception
  • Données (à des fins d’utilisation fonctionnelle, de migration, d’interfaçage, de reporting/décisionnel, etc.)
  • Couverture géographique
  • Domaines personnalisés
  • Modifications de processus
  • Sécurité
  • Exigences réglementaires
  • Objectifs du projet

Cette rubrique aborde également la question suivante : comment, et dans le cadre de quelle phase de test ou de quel type de test, les domaines non fonctionnels de l’étendue du projet doivent-ils être testés ?

Par exemple, prenons les domaines d’étendue suivants :

  • Performances
  • Convivialité
  • Opérabilité
  • Maintenabilité
  • Récupération d’urgence
  • Continuité des activités
  • Autres domaines pertinents pour ce projet

Plan de test général

Des tests sont menés tout au long du projet et le plan de test général définit la structure permettant de montrer comment les différents types et phases de tests s’appuient les uns sur les autres pour fournir une validation incrémentielle et complète de la solution. Cette rubrique se concentre sur la réponse à des questions telles que les suivantes :

  • Comment le plan de test général s’intègre-t-il au plan du projet ?
  • La planification des tests reflète-t-elle la stratégie de test ?
  • L’ensemble des types et phases de tests sont-ils reflétés avec précision dans le plan de test ?
  • Le plan de test prévoit-il suffisamment de temps et de ressources pour mener des tests en fonction de la taille et de la complexité du projet ?
  • Le plan de test montre-t-il que le temps et les ressources alloués aux différents domaines de test sont proportionnels au risque présenté pour l’entreprise ?

Phases et types de tests

Les tests menés dans une application métier telle que Dynamics 365 comportent plusieurs facettes, et les phases et types de tests représentent la validation des différentes couches et dimensions de la solution. Cette section examine l’exhaustivité de certains attributs importants de définition de test et de gestion de test des phases et types de tests clés.

Les tableaux suivants présentent une vue des domaines à définir pour chaque type de test :

Tests : Définitions clés

Phase de test/Type de test Objectifs clés Documents source Couverture des tests Critères d’entrée Critères de sortie
Saisissez le titre de la phase de test (par exemple Tests d’intégration ou Tests d’acceptation utilisateur) ou les types de tests clés (par exemple Tests de performance ou Simulation de basculement). Saisissez les objectifs clés à atteindre par chaque phase de test. Répertoriez le type de document/le domaine d’exigence permettant de définir le contenu des cas de test et les critères d’acceptation (autrement dit, ce qui sert de définition pour valider le résultat de test). Déterminez les domaines de l’étendue du projet à valider par cette phase, par exemple : - Processus d’entreprise de bout en bout et configuration associée - Fonctions spécifiques - Données migrées Définissez les critères d’entrée à remplir afin que cette phase de test soit considérée comme prête à démarrer l’implémentation formelle. Définissez les critères de sortie à remplir par les résultats de test afin que cette phase de test soit considérée comme atteignant son objectif et de pouvoir sortir formellement de cette phase.

Gestion des tests

Phase de test/Type de test Préparation des tests Implémentation des tests Reporting des tests Outil(s) d’administration des tests Propriété des tests
Saisissez le titre de la phase de test (par exemple Tests d’intégration ou Tests d’acceptation utilisateur) ou les types de tests clés (par exemple Tests de performance ou Simulation de basculement). Brève description de la préparation des tests devant remplir les critères d’entrée des tests (par exemple écriture de script de test, besoins en matière de données ou environnements). Brève description de l’implémentation des tests concernés (rôles effectuant les tests ou cycle de vie d’un défaut). Définissez le mode de reporting de la progression des tests et le mode d’analyse et de reporting des résultats/de la qualité, par exemple : - Reporting pour utilisation de projet interne - Reporting auprès des principales parties prenantes de l’entreprise Déterminez les outils permettant de stocker, consulter et gérer le cadre de test, les cas de test et les résultats de test. Pensez également aux outils permettant de mapper les cas de test aux besoins/à l’étendue, comme Azure DevOps, Kira ou Microsoft Excel. Définissez le responsable du résultat des tests concernés.

Les informations des tableaux précédents s’appliquent à tous les types de tests. Voici quelques phases et types de tests clés susceptibles d’être couverts :

  • Tests unitaires
  • Tests fonctionnels/de processus
  • Tests d’intégration système
  • Tests de bout en bout
  • Tests d’acceptation utilisateur (UAT)
  • Tests de régression

Voici quelques types de tests non fonctionnels clés susceptibles d’être couverts :

  • Tests de performances
  • Validation des données
  • Tests de sécurité

Cette liste n’est pas exhaustive et selon la nature du projet, d’autres types de tests peuvent être pertinents, comme les tests de point de vente (PDV) pour les magasins de détail ou les tests de scanneur pour les applications d’entrepôt.

Voici des questions supplémentaires particulièrement pertinentes pour une phase/un type de test donné(e) susceptible de ne pas être couvert(e) de manière adéquate par les catégories précédentes :

  • Les cas de tests fonctionnels ont-ils été définis à partir des besoins et/ou des scénarios métier ?
  • Les tests fonctionnels couvrent-ils tous les modules fonctionnels ?
  • Les scripts de test fonctionnel sont-ils validés auprès des utilisateurs métier ?
  • La stratégie de test d’intégration système explique-t-elle la création d’un environnement de test de type production pour mener des tests d’intégration système ?
  • Une méthode a-t-elle été définie pour synchroniser/resynchroniser tous les systèmes participants aux tests d’intégration système ?
  • Les cas de test de bout en bout ont-ils été validés avec le propriétaire de chaque module fonctionnel ?
  • La stratégie de test de bout en bout prend-elle en compte les tests de convivialité ?
  • Les principales parties prenantes des tests UAT ont-elles été identifiées ?
  • Le plan de test UAT documente-t-il clairement le rôle de chaque partie prenante lors de la phase de test UAT ?
  • Avez-vous établi un plan de communication clair lors des tests UAT avec toutes les parties prenantes requises ?
  • Chaque processus principal a-t-il été décomposé pour comprendre des sous-processus ?
  • Les scénarios de test ont-ils été hiérarchisés lors des tests UAT ?
  • Le plan de test UAT comprend-il l’approvisionnement de l’environnement de test UAT approprié ?
  • Avez-vous prévu une formation utilisateur avant les tests UAT pour les testeurs ?
  • Une définition adéquate a-t-elle été établie pour l’ensemble de tests de base qui constituerait une suite de tests de régression ?
  • Un processus est-il en place afin d’identifier les changements récents (à un niveau général) relatifs aux tests de régression ?
  • Le plan de test comprend-il l’automatisation des tests de régression ?
  • Un processus a-t-il été défini pour les tests de validation des données ?
  • Les parties prenantes adéquates de l’entreprise ont-elles été identifiées pour mener les tests de validation des données ?
  • Un plan est-il en place pour mener des tests de bout en bout sur les données migrées ?
  • Les tests de validation des données comprennent-ils des états sur le rapprochement des données et des plans associés ?
  • Les domaines clés relatifs aux tests de sécurité ont-ils été identifiés ?
  • Le plan de test exige-t-il que tous les rôles et privilèges de sécurité nécessaires soient définis et renseignés avant les tests UAT ou d’intégration système ?
  • La stratégie de test de sécurité comprend-elle les besoins de sécurité de votre organisation ?

Outils

La planification, la préparation, la réalisation et le reporting des tests nécessitent une gestion importante. Pour les projets les plus simples, ce processus peut être géré au moyen de feuilles de calcul, mais cette solution peut devenir fastidieuse et difficile à suivre pour un projet plus complexe. La plupart des projets utilisent une forme de logiciel de gestion des tâches. En outre, de nombreuses organisations utilisent des outils d’automatisation pour planifier, créer et exécuter des tests et rendre compte des résultats de test. Cette rubrique se concentre sur la réponse à des questions telles que les suivantes :

  • Quels outils d’administration de test permettent de mapper les tests aux demandes source (matrice de traçabilité) et de quelle manière ?
  • Quels outils d’administration de test permettent de gérer l’identification et le stockage des cas de test ?
  • Quels outils d’administration de test permettent de gérer la répartition des ressources et suivre le cycle de vie complet d’un test (création et exécution du test, collecte des résultats, journalisation des défauts, puis résolution et nouvelle tentative) ?
  • Quels outils permettent d’automatiser l’exécution des types de tests et la collecte des résultats ?