Add Test Case to the Task Board TFS

Problem description

Default TFS Scrum Board is too restrictive, we have to customize the Board in order to have a better owerview of the current sprint.

Here is an example of the default Task Board (3 columns and only Task in the Board)

Objective: Integrate the Test Case in the Board, add new status to Scrum Board, ensure the status change by drag and drop

Warning: Make sure to conserve a copy of original Xml file.

Ajouter les Test Case au Scrum Board TFS

Description de la problématique

Dans un contexte Scrum avec des équipes délocalisées, il est important d'avoir un outil qui centralise les informations et qui permet d'avoir une vision global du Sprint en cours.

Le Scrum Board de TFS est de base trop restrictif, il faut donc personnaliser le Task Board afin de répondre au mieux à nos besoins.

Dans le cadre de cet article, nous allons voir comment intégrer les Test Case (et les colonnes correspondantes)au Board afin de pouvoir tout gérer depuis le Web Portal.

Voici à quoi ressemble le Scrum Board de base dans TFS 2013 (3 colonne et uniquement des Tasks)

Objectif: Intégrer les Test Case au Scrum Board, ajouter des statuts au Scrum Board, assurer le changement de statut par glisser déposer.

NB: avant de faire les modification des fichiers Xml, assurez vous de garder une copie des originaux au cas ou il faudrait revenir en arrière.

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