Valider la fonctionnalité de l’application
Au fur et à mesure que l’application est créée, validez le fait qu’elle fonctionne comme prévu.
Test unitaires
Les tests unitaires/de story permettent de s’assurer que les exigences spécifiées dans une story sont validées avant de la fermer. Une story/unité est une plus petite portion testable d’un système ou d’une application qui peut être configurée et exécutée.
Lorsque la configuration de la story est terminée, les développeurs doivent tester unitairement les fonctionnalités non seulement dans le contexte de cette story particulière, mais également dans d’autres stories connexes qui partagent des composants avec la story actuelle.
Il est recommandé aux développeurs d’affecter la story au propriétaire du processus ou à la partie prenante désignée pour valider que la configuration de la story répond aux résultats escomptés avant de la fermer.
Infrastructure de tests automatisés (ATF) de ServiceNow est principalement destinée à automatiser les tests fonctionnels des applications, mais dans certains cas, elle peut être utilisée pour automatiser les tests unitaires des configurations qui impliquent des includes de script et des règles métier.
Test du système
Les tests du système sont effectués sur un système complet lorsque le développement est terminé. Tester l’interaction globale des composants et des intégrations avec d’autres applications dans le périmètre. Les tests du système sont effectués par l’équipe QA/Testing, mais les développeurs doivent collaborer avec l’équipe QA et les propriétaires de processus pour s’assurer que les scénarios de tests offrent une couverture complète. Les développeurs seront responsables de la résolution des problèmes détectés lors des tests du système.
Infrastructure de tests automatisés
Automated Test Framework (ATF) doit être utilisé pour automatiser les tests du système fonctionnel des applications ServiceNow afin de réduire le temps et les coûts de test, et de rendre les tests répétables et indépendants de l’interface utilisateur. Lors de la création de scénarios de tests, suivez ces directives.
Lors de la création de tests :
- Utilisez des tests paramétrés pour éviter les scénarios de tests en double.
- Suivez une norme de dénomination de test.
- < initiale de l’application > : <fonctionnalité en cours de test>
- CSM : résoudre un ticket
- Décrivez le cas d’utilisation de chaque test dans sa description. Par exemple : exemple qui teste le cas d’utilisation.
- Développez des tests sur une instance de développement et promouvez/exécutez le test sur une instance de test.
- Les clones effacent les tests. Utilisez l’une des options suivantes pour conserver les tests :
- Regroupez les tests dans une application incluse dans le périmètre et chargez l’application dans GIT.
- Enregistrez les tests avant le clone.
- Promouvoir les tests vers l’instance de production, mais NE PAS EXÉCUTER LES TESTS DANS PROD.
- Créez des tests autonomes.
- Créer des étapes de test côté serveur ou REST, toutes les étapes de test sont manquantes. Par exemple : vérification du corps de l’e-mail.
- Utilisez l’étape de test côté serveur dans la mesure du possible et lorsque les captures d’écran ne sont pas importantes.
- Commencez par l’étape Emprunter l’identité.
- Méfiez-vous de la limitation du navigateur.
- Utilisez les journaux de test et les transactions de test pour résoudre les erreurs de test.
Lors de la création de suites de tests :
- Suivez une norme de dénomination de suite de tests. Par exemple : ITSM INT : cas d’utilisation.
- Décrivez la suite.
- Description de la suite de tests : « il s’agit d’un exemple de suite de tests pour tester le module d’extension/l’application ».
- Fournissez toutes les informations supplémentaires possibles dans la description.
- Organisez les suites de tests par domaines de fonctionnalités.
Test d’acceptation par l’utilisateur
Le test d’acceptation par l’utilisateur (UAT) est un test effectué pour évaluer la conformité de l’application aux besoins professionnels et déterminer si l’application est acceptable pour la livraison. Les utilisateurs, les clients ou d’autres personnes concernées autorisées effectuent des tests d’acceptation. Les développeurs seront responsables de la résolution des problèmes détectés lors des tests du système.