Amélioration des performances des tests automatiques et simplification du code en nettoyant les filtres de recherches

Description de la problématique

Lorsque l'on réalise des tests automatisés, on doit systématiquement se poser la question de la maintenance de ces tests pour essayer de coder les tests de la manière la plus simple afin de pouvoir corriger d'éventuel futur modification de l'application

J'ai lu dans certaines bonnes pratiques qu'il fallait enregistrer toutes les actions sur tous les écrans, cette solution ne me convient pas car elle complique les fichiers UI Test Map de manière conséquente et complique donc la maintenance alors que l'on peut contourner ce problème de manière assez simple.

L'objectif est de simplifier au maximum le fichier uitest sans ralentir les exécutions des tests, en ayant une seule action qui sera appeler pour chaque écran.

Ecriture des tests automatisés suite à la mise en place du template de projet

Suite à la mise en place du template de projet pour les tests, cela implique quelques modifications dans l'écriture des tests automatisés, voici donc les principaux changements.

Pour rappel: l'architecture du template qui a été mis en place à partir du précédent post est la suivante:

Structure d'un projet de tests automatisés dans un contexte Agile Scrum avec Visual Studio 2010

Description de la problématique

Dans le cadre de l'automatisation des tests fonctionnels d'un projet dans un contexte Scrum, nous avons besoin de définir une méthodologie qui sera appliquée à nos différents projets de test. Cette structure doit pouvoir être mise en place simplement et rapidement.

Avec la structure suivante, il suffit de modifier les variables de contexte et quelques autres variables afin d'avoir un projet de test utilisable directement pour d'autres projets.

L'approche que nous avons mise en place pour nos projets est la suivante:

Un "Acceptance Test" est couvert par 1 test automatisé

Une fonctionnalité (PBI) est testée par 1 à n "Acceptance Test" (-> 1 à n tests automatisés par classe/fonctionnalité)

Un ensemble fonctionnel est couvert par 1 à n fonctionnalité (-> 1 à n classes par répertoire/ensemble)

Enregistrement des actions et écriture d'un cas de test

Description de la problématique

Dans un contexte Agile Scrum, nous avons parfois de gros projets à gérer qui s'étale sur une longue période.

Pour les tests de ces projets, l'objectif est d'automatiser au maximum les tests de l'application (les fonctionnalités majeures) de manière simple et facilement maintenable (en cas d'évolution demandée par le Product Owner, on doit pouvoir répondre positivement sans mettre en péril l'exécution des tests automatiques). Ces tests automatiques ont pour but de vérifier que l'application est fonctionnelle tout le long du projet.

Dans cet article nous allons donc voir une première étape qui est l'enregistrement des actions pour l'écriture des tests automatiques.

Description des outils utilisés

Je ne vais pas vous expliquer comment utiliser les outils dans ce post, il existe déjà des tutoriaux sur le sujet, je vais donc juste vous les présenter rapidement pour expliquer le contexte de travail dans lequel nous allons écrire les tests automatisés.

Microsoft Test and Lab Manager 2010

Les principales fonctionnalités de cet outil sont décomposées et réparties dans 2 modules (Testing Center et Lab Center):

• Planification des campagnes de tests

• Définition des tests

• Organisation des tests, des configurations de tests, etc.

• Reporting des bugs

• Suivi de l’évolution des tests au travers des builds 
• Exécution des tests

Intégration des tests dans le cycle projet scrum et l'équipe

Cet article à été co-écrit avec Thibaut DAVID (Voir son Blog)


Définitions utiles à la compréhension de l'article:

Product Backlog Item (PBI): Un PBI correspond à une fonctionnalité de l'application

Exemple de PBI: Administrateur / Ajouter utilisateur /

Acceptance Test (AT): Un AT est un item qui permet de définir les règles de fonctionnement de chaque PBI (1 PBI -> n AT), les AT correspondent à tous les cas de tests permettant de couvrir la fonctionnalité afin de s'assurer de son bon fonctionnement.

1. Les différents types de tests

Dans cet article nous allons voir les différents types de test qui ont été mis en place dans notre SI afin de bien comprendre le contexte de travail. Dans les prochains articles, nous nous attarderons principalement sur les tests fonctionnels automatisés (Coded UI Test) et leurs mises en place.