www.clubagile.org

Tests Agiles

Rencontre agile GrenobleJeudi 19 Mai 2011

Nicolas PELLOUX-PRAYER – Amaris

Email : npellouxprayer@gmail.com

Twitter: @npelloux

Sylvain FRANCOIS - Kalistic

Email : sylvain.francois@kalistick.fr

Twitter: @syllant

Johan Martinsson - Indépendant

Email : martinsson.johan@gmail.com

Twitter: @johan_alps

www.clubagile.org

Evénements

26 et 27 mai 2011 – Paris

conf.agile-france.org

www.clubagile.org

Evénements

www.breizhcamp.org

www.clubagile.org

Evénements

7 juin 2011 – Lyon

lyon.clubagile.org

www.clubagile.org

• Historique• Coût d'un bug• Approche classique• Catégorisation des tests• Apport des principes Agiles• Pourquoi faut-il soigner sa pyramide de tests• Indicateurs de qualité• « Tester juste »• Spécificités d’un projet agile

Plan

www.clubagile.org

Un peu d’histoire…

1968 => Génie logiciel

www.clubagile.org

• Tests décorrélés

• Rôle de la QA

• Centré sur la doc

www.clubagile.org

Tests décorrélés

www.clubagile.org

• Dernier rempart

• Tensions avec le dev

Rôle de la QA

www.clubagile.org

Documentation

• Lourd

• Utile ?

www.clubagile.org

Coût de détection

1.Détection d’un bug

2.Impact

3.Résolution

www.clubagile.org

Agile testing quadrant

www.clubagile.org

Soutien de l’équipe

• les tests de gauche sont là pour aider l’équipe !

• Q1 aide à construire la qualité interne du logiciel

• Q2 définit les features que le client souhaite et la qualité externe

• Fournissent un feedback rapide et un guide aux développeurs

www.clubagile.org

Critique du produit

• Q3 permet de savoir si le produit est efficace et adapté.

• Q4 permet d’évaluer la performance, robustesse et sécurité.

• Les tests de critique produit pourront fournir des entrées pour les carrés de gauche.

www.clubagile.org

Approche agile

www.clubagile.org

Individus et interaction

• Responsabiliser l’équipe

• Tout le monde teste

www.clubagile.org

Alléger les procédures

• Doc => Checklist

• Priorisation des tests

• Esprit critique

• Cf. Exploratory testing

www.clubagile.org

Adaptation au changement

• Tester au plus tôt

– TDD

• Tester plus vite

– Automatisation des tests

• Tester plus souvent

– Intégration Continue

www.clubagile.org

Attention au « Done – Done »

Développement

ET

Tests !

www.clubagile.org

Références

• Elisabeth Hendrickson

• Lisa Crispin

• Cem Kaner

www.clubagile.org

Indicateurs de qualité

pour les tests

unitaires et fonctionnels

Sylvain FRANCOISDirecteur R&D

www.clubagile.org

• Start-up lyonnaise (2007)

• Plateforme SaaS– Qualité des développement

– Optimisation de la phase de test / validation

• Forte activité R&D– Développement orienté Agile

– Vraie activité de recherche

www.clubagile.org

Tester, c’est bien.

Bien tester, c’est mieux.

Indicateurs de qualitédes tests

« Tester juste »

www.clubagile.org

Sommaire

• La vision « Tester Juste »

• … appliquée aux tests unitaires

• … appliquée aux tests fonctionnels

• Spécificités pour un projet Agile

www.clubagile.org

La vision

« Tester Juste »

www.clubagile.org

Tester coûte cher

… ROI souvent difficile à mesurer

Temps

Coûtcumulé

Tests manuelsTests automatisés

ROI

www.clubagile.org

Le coût de l’automatisation

• Conception / mise en œuvre

– Profils experts

• Analyse des résultats

• Licences produits / TCO

• Coûts matériels (à la demande sur le Cloud)

• Maintenance des tests

• Délais d’exécution

www.clubagile.org

La question : que tester ?

• Souvent difficile de tout tester

• Quelques critères de choix :

– Ancienneté du code

– Intérêt / criticité pour le client

– Risques techniques

– Résultats des tests précédents

– Charge de test / Planning

www.clubagile.org

Collaboration développeur - testeur

• Pierre d’achoppement récurrente

• Objectifs parfois différents

• Vision code / vision fonctionnelle

• Outils différents

(idem pour développeur – exploitant)

www.clubagile.org

Le « Tester Juste »

appliqué aux

Tests Unitaires (TU)

www.clubagile.org

Précisions sur les tests unitaires

• Test isolé d’une méthode de code

• Utilisation de frameworks de TU

– JUnit, TestNG, MSTest, NUnit, …

• Utilisation de bouchons (« mocks »)

• Automatisables

• TDD (Test Driven Development)

www.clubagile.org

Inconvénients du TDD

• Niveau d’acceptation des TU dans les projets

• Toute méthode mérite-t-elle d’être testée ?

• Difficulté de tester certains traitements

• Refactoring du code testé

• Pertinence des TU ?

www.clubagile.org

Mesurer la couverture des TU

• Outils de coverage

– Enregistrent l’exécution

– Résultat : taux de code exécuté (%)

– Exemples :

• Java : JaCoCo, Cobertura, EMMA, …

• C# : MSCoverage, NCover, dotCover, …

• Pertinence du taux de couverture ?

• Coût pour atteindre les 100%

100%

Effort

Couverture

www.clubagile.org

Proposition : cibler ses TU

• Prioriser les TU selon :

– Le risque fonctionnel / métier

– Le risque technique

– L’effort de test

• Mesurer le niveau de test

– Mais de manière pragmatique

www.clubagile.org

Le TestRelevancyIndex (TRI) [1/2]

• Index créé par Kalistick + CETIC (labo de recherche)

• Qualifie l’intérêt de chaque traitement à être testé

– méthode, classe, composant, …

• Basé sur des métriques unitaires– Complexité, paramètres, variables, dépendances, bugs, …

• … et sur le risque métier

• Ajuste l’objectif de couverture

www.clubagile.org

Le TestRelevancyIndex (TRI) [2/2]

Couverture des TU pondérée par le TRI

www.clubagile.org

Le « Tester Juste »

appliqué aux

Tests Fonctionnels

www.clubagile.org

Notre vision

• Privilégier les tests sur le code modifié

– Les nouvelles fonctionnalités

– Les risques de régression

• Vérifier ce qu’ont couvert les tests

– Après leur exécution (coverage)

• Enrichir le référentiel / plan de test

• Faciliter la collaboration développeur - testeur

www.clubagile.org

Identifier les modifications du code

Régressions

Nouveautés,

Corrections

Bugs dormants

« Old good code »

Niveau

de

risque

Co

de

mo

dif

iéC

od

e n

on

mo

dif

ié

Modifications non tracées

Modifications tracées

Bugs non critiques

RAS

www.clubagile.org

Questions cibles

• Qu’est-ce qui a changé entre 2 versions ?

– Consolider sa stratégie de test

• Les modifications ont-elles été testées ?

– Eviter les régressions

• Quels scénarios de tests doivent être joués ?

– Plan d’action concret pour les testeurs

www.clubagile.org

Le testeur est mon ami

• Objectifs :

– Indicateurs exploitables par le testeur

– Améliorer la collaboration testeur – développeur

• Le défi : remonter du code au testeur

– Modéliser les fonctionnalités de l’application

– Réutiliser le référentiel de test

• HP Quality Center, TestLink, …

www.clubagile.org

Exemple de rendu [1/3]

Couverture globale des tests fonctionnels et unitaires

www.clubagile.org

Exemple de rendu [2/3]

Couverture par fonctionnalités

www.clubagile.org

Exemple de rendu [3/3]

Fiche User Story (dans l’outil JIRA)

Fonctionnalités impactées

www.clubagile.org

Les spécificités pour

un projet Agile

www.clubagile.org

Rôle développeur - testeur

• Dans la littérature Agile : un seul profil

– Dans la réalité ?

• Le testeur Agile est plus proche du code

– Plus à même d’analyser les résultats de couverture

www.clubagile.org

Risque d’instabilité plus élevé

• Adaptabilité aux besoins

– Mise à jour des User Stories

– Mise à jour des cas de test

• Techniques de développement à risques

– Refactoring

– Qualité du code !

Besoin accru d’automatisation des tests

www.clubagile.org

Processus de livraison agile

• Rythme de livraison plus soutenu

– Notion de « Continuous Delivery »

– Besoin de sécuriser la livraison

• Indicateurs de DONE

– Inclure la couverture des tests fonctionnels ?

www.clubagile.org

http://blog.kalistick.com

http://twitter.com/kalistick

http://www.kalistick.com

mailto:sylvain.francois@kalistick.fr

www.clubagile.org

Et vous ?