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 unitaire
Les tests unitaires/de story permettent de s’assurer que les exigences spécifiées dans un story sont validées avant de fermer le story. Une story ou une unité est une plus petite partie 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.
En tant que bonne pratique, les développeurs doivent affecter la story au propriétaire du processus ou à la personne concernée désignée pour valider que la configuration de la story répond aux résultats attendus avant de fermer la story.
Automated Test Framework (ATF) de ServiceNow est principalement destiné à automatiser les tests fonctionnels d’applications, mais dans certains cas, il peut être utilisé pour automatiser les tests unitaires de configurations qui impliquent des includes de script et des règles métier.
Test du système
Le test du système est effectué sur un système complet lorsque le développement est terminé. Testez 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/Test, mais les développeurs doivent collaborer avec l’équipe QA et les propriétaires de processus pour s’assurer que les scénarios de test offrent une couverture complète. Les développeurs seront responsables de la correction des problèmes détectés lors des tests du système.
Framework de tests automatisés
Automated Test Framework (ATF) doit être exploité pour automatiser les tests système fonctionnels 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 instructions.
Lors de la création des tests :
- Utilisez les tests paramétrés pour éviter les cas de test en double.
- Suivez une norme de dénomination de test.
- <application initiale> : <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.
- Promouvez les tests en instance de production, mais N’EXÉCUTEZ PAS LES TESTS DANS PROD.
- Créez des tests autonomes.
- Créer des étapes de test côté serveur ou REST, il manque des étapes de test. 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 Emprunterl’identité.
- Faites attention à la limitation du navigateur.
- Utilisez les journaux de tests 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 toute information supplémentaire possible dans la description.
- Organisez les suites de tests par domaines de fonctionnalité.
Test d’acceptation de l’utilisateur
Le test d’acceptation par l’utilisateur (UAT) est un test réalisé pour évaluer la conformité de l’application aux besoins professionnels et déterminer si l’application est acceptable pour la livraison. Des utilisateurs, des clients ou d’autres personnes concernées autorisées effectuent des tests d’acceptation. Les développeurs seront responsables de la correction des problèmes détectés lors des tests du système.