Valider la fonctionnalité de l’application
Au fur et à mesure que l’application est générée, validez qu’elle fonctionne comme prévu.
Tests unitaires
Les tests unitaires/de story garantissent que les exigences spécifiées dans une story sont validées avant de fermer la story. Une story/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 aussi 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 à une 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.
Framework de tests automatisés (ATF) de ServiceNow est principalement destiné à automatiser les tests fonctionnels des applications, mais dans certains cas, il peut être utilisé 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é. 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 d’assurance qualité/de test, mais les développeurs doivent collaborer avec l’équipe d’assurance qualité et les propriétaires de processus pour garantir que les cas de test 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.
Framework de tests automatisés
Framework de tests automatisés (ATF) doit être utilisé pour automatiser les tests fonctionnels du système d’applications ServiceNow afin de réduire le temps et les coûts de test et de rendre les tests reproductibles et indépendants de l’interface utilisateur. Lors de la création de scénarios de test, suivez ces directives.
Lors de la création de tests :
- Utilisez des tests paramétrés pour éviter les cas de test en double.
- Suivre une norme de nommage de test.
- <application initiale> : <fonctionnalité testée>
- CSM : résoudre le ticket
- Décrivez le cas d’utilisation de chaque test dans sa description. 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 de ces options 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 en instance de production, mais NE PAS EXÉCUTER LES TESTS DANS LA PRODUCTION.
- Créez des tests autonomes.
- Créez des étapes de test côté serveur ou REST toutes les étapes de test manquantes. Par exemple : vérification du corps de l’e-mail.
- Utilisez l’étape de test côté serveur chaque fois que cela est possible et lorsque les captures d’écran ne sont pas importantes.
- Commencez par l’étape Emprunter l’identité.
- Faites attention à 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 :
- Suivre 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 : « Ceci est un exemple de suite de tests pour tester le plugin/l’application ».
- Fournissez toute information supplémentaire possible dans la description.
- Organiser les suites de tests par domaines de fonctionnalités.
Test de l'acceptation de l'utilisateur
Le test d’acceptation par les utilisateurs (UAT) est un test effectué pour évaluer la conformité de l’application aux besoins de l’entreprise et déterminer si l’application est acceptable pour la livraison. Les utilisateurs, clients ou 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.