Présentation
Le travail d’un architecte de solutions se poursuit après la conception du système. La tâche qu’il doit ensuite effectuer consiste à s’assurer que le système est déployé et utilisé par de vrais utilisateurs.
Rôle de l’architecte de solutions dans les tests et la mise en service
En général, l’architecte de solutions est l’une des personnes qui connaît le mieux le fonctionnement de la solution. Il peut donc orienter l’équipe de test quant à la manière de la tester.
L’architecte de solutions joue un rôle clé dans les tests. Il doit :
- rester impliqué jusqu’à la fin des tests afin d’en assurer le succès ;
- aider à former l’équipe de test à l’architecture de la solution, afin de s’assurer qu’elle teste correctement tous les composants et toutes les intégrations ;
- effectuer le tri des problèmes complexes qui surviennent pendant les tests, les « exécutions à vide » et après la mise en service ;
- prendre part avec l’équipe de mise en service à la planification et à la mise en œuvre de la stratégie de mise en service.
Présentation des tests
Il est important que des tests appropriés soient menés pour garantir le succès du projet.
Remarque
Les tests doivent être réalisés en continu, de la création du premier composant jusqu’à la mise en service ; ils ne peuvent pas faire l’objet d’une seule étape.
Les tests ne se résument pas à vérifier l’adéquation des fonctionnalités avec les besoins. Bien qu’il soit important de créer et de mettre en œuvre ces types de tests, d’autres aspects d’une solution doivent également être testés. Quelle que soit la mesure testée, le processus est similaire.
Le processus de test comprend les étapes suivantes :
Planifier : examiner la stratégie globale de test, développer le plan de test et effectuer l’analyse nécessaire pour obtenir les mesures de référence. Identifier les principaux scénarios métier à prendre en compte ou non. Documenter les besoins, le cas échéant.
Préparer : configurer les environnements nécessaires pour réaliser les tests de performances, les tests d’acceptation utilisateur, etc. Examiner les données reçues pour la migration, avant et après les tests de migration. Valider la configuration requise de haut niveau, puis développer les scripts nécessaires.
Exécuter : exécuter des scripts de test, analyser les résultats, identifier les goulots d’étranglement potentiels, puis examiner les échecs et les comportements.
Rendre compte : préparer une évaluation détaillée du plan de reporting, des résultats et du plan d’action.
Types de tests
L’architecte de solutions doit avoir son mot à dire au sujet de la quantité et du type de tests requis pour un projet.
Les types de tests courants dans Microsoft Power Platform sont les suivants :
Tests unitaires : réalisés par le créateur de l’application, l’analyste métier, le consultant fonctionnel ou le développeur.
Tests fonctionnels : ils vérifient que la mise en œuvre répond aux exigences.
Tests d’acceptation : réalisés par les utilisateurs, afin d’apporter une approbation formelle.
Tests de régression : ces tests évaluent la régression des fonctions non modifiées ; ils sont généralement effectués à chaque mise à jour du système.
Tests d’intégration : l’objectif est que tous les systèmes intégrés fonctionnent en harmonie. Les tests d’intégration vérifient que tous les éléments fonctionnent ensemble, y compris les services et les données provenant d’autres sources intégrés.
Tests de performance : ces tests sont vérifiés avec la charge maximale et le volume de transactions maximal attendus. Ils sont généralement automatisés et effectués avant la mise en service.
Tests de migration : testent la migration des données afin de s’assurer de la qualité des données. Ces tests sont réalisés en étroite concertation avec des experts qui connaissent les données du client. Ces spécialistes doivent comprendre la transition et la transformation des données ; ils sont en mesure de confirmer la validité des données migrées, avec un contexte approprié.
Tests de reprise après sinistre : un plan de reprise d’activité après sinistre n’est d’aucune utilité s’il ne fonctionne pas.
Tests de mise en production : consistent en des « exécutions à vide » de la solution complète et du processus de mise en service. Ces tests sont généralement réalisés avant la mise en service.
Tous les types de tests ne sont pas obligatoires ; leur utilité est déterminée par la taille et l’étendue du projet.
Tests unitaires
Un test unitaire permet de vérifier si une fonction ou une fonctionnalité donnée de votre application fonctionne correctement. En règle générale, ce sont les créateurs et les développeurs d’applications qui réalisent les tests unitaires. Chaque membre de l’équipe doit vérifier son propre travail avant la remise.
Les tests unitaires sont recommandés, mais non obligatoires. Lorsque vous démarrez, ou si la quantité de code de votre solution est relativement faible, vous pouvez avoir l’impression de passer plus de temps à écrire des tests qu’à créer les fonctionnalités offertes par votre solution. Les avantages des tests unitaires se font véritablement sentir lorsque votre solution augmente en taille et complexité. C’est particulièrement vrai dans le cas du développement côté serveur, où vous pouvez constater des avantages significatifs en termes de débogage local avec des données fictives dans un environnement de test.
Les tests manuels peuvent être réalisés avec toutes les applications, règles métier et plug-ins. Certains tests peuvent être automatisés avec Microsoft Power Apps Studio et Visual Studio. Fake Xrm Easy est un environnement de test unitaire plébiscité pour le développement côté serveur.
L’architecte de solutions doit décider des outils à utiliser pour les tests unitaires et du niveau d’automatisation à utiliser.
Tests d’intégration
L’architecte de solutions doit aider l’équipe de test à comprendre comment tester les composants intégrés.
L’un des avantages de Microsoft Power Platform réside dans ses fonctionnalités robustes d’intégration. L’intégration est l’un des aspects les plus importants de la mise en œuvre des processus métier, car elle permet de s’assurer que celle-ci s’effectue correctement. De plus, elle a un fort impact sur l’adoption globale.
L’architecte de solutions et le client doivent examiner les scénarios de test qui impliquent des intégrations avec d’autres applications métier, afin de s’assurer de créer des scénarios de test de bout en bout. Cet examen oblige probablement le client à prévoir des environnements de test pour ses autres applications.
Chaque intégration sera probablement assortie de sa propre approche de test, qui doit être définie. L’équipe de test doit être impliquée en amont, afin de définir une méthode de test de chaque scénario d’intégration. Les équipes doivent s’assurer que les intégrations nécessaires peuvent être configurées pour prendre en charge les tests.
Un aspect important des tests d’intégration doit s’intéresser aux données qui entrent et sortent de l’intégration. Une grande partie du débat autour des tests de validation des données peut également concerner les données impliquées dans les intégrations.
Les tests d’intégration pouvant impliquer d’autres systèmes, vous devez veiller à utiliser des environnements de test pour tous les composants. Cela permet d’éviter que les tests d’intégration communiquent avec un système actif, puis modifient les données de production par accident. Il arrive que les scénarios de test pilotent les options de configuration de l’intégration de l’application afin de la rendre testable. Il est possible de désactiver les intégrations afin de tester sans appeler l’intégration.
Le processus de création des intégrations est désormais plus simple et donc plus accessible à un nombre accru de personnes dans les équipes de projet. Il arrive souvent que les intégrations soient dissimulées dans des applications canevas Power Apps ou des flux Microsoft Power Automate. Elles passent alors inaperçues, car l’application utilise un connecteur de surface provenant d’une autre source. Le plan doit tenir compte de ces intégrations, comme toute autre intégration, et les tester en conséquence.
Les tests d’acceptation utilisateur (UAT, User acceptance testing)
Les UAT sont réalisés par les utilisateurs finaux afin de donner une approbation formelle et de tester la convivialité du système. Les tests d’acceptation interviennent généralement sous la forme d’un contrôle final avant le déploiement des fonctionnalités. Ils permettent de s’assurer que les éléments créés par les créateurs correspondent bien aux besoins exprimés par l’utilisateur au départ.
Conseils pour obtenir de bons résultats des UAT :
- Testez avec de vrais utilisateurs.
- Choisissez des utilisateurs disposant de niveaux de compétences informatiques différents. Cela permet de recueillir des commentaires diversifiés.
- Ne communiquez pas de consignes aux utilisateurs ; voyez s’ils comprennent le fonctionnement de l’application intuitivement.
- Observez la façon dont les utilisateurs naviguent dans l’application sans assistance, puis déterminez les aspects dont vous pouvez améliorer la conception.
- Lorsque l’utilisateur est bloqué sur un écran, demandez-lui d’expliquer ses attentes.
- Expérimentez avec différents appareils pour vous assurer que les cas de test se comportent de la même manière.
- Dans l’idéal, testez l’application dans l’environnement ou la localisation véritable de l’utilisateur, si l’application utilise des fonctionnalités hors connexion.
- Demandez à vos utilisateurs de tenter de « casser » votre application, par exemple en saisissant des caractères inhabituels dans les colonnes de texte.
- Les utilisateurs testent généralement le « chemin idéal » (celui qu’emprunte un utilisateur lorsque tout se passe parfaitement bien). Demandez-leur également de tester des scénarios tels que l’annulation d’une note de frais au lieu de sa soumission, ou le refus d’une note de frais au lieu de son approbation.
Il se peut que les utilisateurs n’aient pas l’habitude de tester des logiciels. Informez-les du type de commentaires que vous recherchez. Il est souvent utile de fournir un modèle pour les bogues, afin de s’assurer que les testeurs expliquent exactement ce qu’ils faisaient, ce qui s’est passé, ce à quoi ils s’attendaient à la place, et qu’ils communiquent des informations pertinentes sur leur environnement de test (comme le type d’appareil et le navigateur).
L’architecte de solutions doit aider à trier les problèmes signalés par les utilisateurs lors des tests.
Tests de sécurité
Les tests de sécurité sont importants pour garantir la sécurité de l’application et le respect des exigences règlementaires. Ils doivent comprendre une évaluation de la vulnérabilité afin de garantir la sécurité de l’application. Ils doivent également inclure des tests provenant du contexte de sécurité de différents types d’utilisateurs, afin de garantir qu’un niveau approprié de données et de fonctionnalités est disponible.
Les tests de sécurité doivent également examiner le modèle de sécurité au sein de l’application lors de l’accès à ses données et fonctionnalités. Les tests doivent inclure des scénarios avec différents utilisateurs dotés de rôles et de caractéristiques d’accès différents, afin de s’assurer que le modèle de sécurité résiste. Les tests du modèle de sécurité doivent vérifier que le partage ne soit pas trop étendu ou insuffisamment étendu. Une façon d’aborder les tests du modèle de sécurité consiste à créer un compte utilisateur de test dédié pour chaque jeu de rôles majeur.
L’architecte de solutions doit aider à définir le niveau de tests de sécurité à réaliser.