Initiation aux tests fonctionnels - Philippe Kernevez - October 2009

Copyright © 2009 – OCTO Technology – Licence CC – Creative Commons 2.0 France – Paternité – Pas d'Utilisation Commerciale – Partage des Conditions Initiales à l'Identique

Tests Fonctionnels Automatisés

Philippe Kernévez

[email protected]

JUGL

08/10/2009

Copyright © 2009 – OCTO Technology – Licence CC – Creative Commons 2.0 France – Paternité – Pas d'Utilisation Commerciale – Partage des Conditions Initiales à l'Identique 2

Licence !

Creative Commons

Contrat Paternité

Pas d'Utilisation Commerciale

Partage des Conditions Initiales à l'Identique

2.0 France

http://creativecommons.org/licenses/by-nc-sa/2.0/fr/

AGENDA


!! Des tests ?

!! Tests fonctionnels automatisés

!! Pourquoi ?

!! Quand ?

!! Avec quoi ?

!! Pour quoi ?

!! Qui ?

!! Où ?

!! Démonstration

!! Effets de bord


Des tests ? !

4


Rôle incontournable des tests !

logiciel = complexe, invisible

tester = rendre le logiciel « visible »

rapport qualité/prix des tests


Typologie des Tests !

Tests de recette automatiques

Tests d’ensemble de fonctionnalités

UAT

Tests d’usabilité

Validation de cas d’utilisation

Tests unitaires

Tests d’intégration

Tests de performance

Test de disponibilité

Tests de sécurité

Fonctionnel

Technique

Contrôleur Faiseur


Pourquoi ? !

Tests fonctionnels automatisés


Réduire l’écart entre spécifications et tests !

100

100

100

+25

+50

+100

Pourrait-on détecter ces écarts plus tôt ?


Réduire l’écart entre spécifications et tests !

Elaborer les tests au plus tôt, avant le développement

Réaliser un logiciel qui passe ces tests


Réduire les redondances entre spécifications et tests !

Utiliser un format commun : Les Cas d’Utilisation

Fusionner Cas D’utilisation et Tests sur ces cas


Exemple !


GreenPepper – Octopus MicroFinance !

http://wiki.octopusnetwork.org/display/OPUS/Late+repayment+-+flat+rate+-+based+on+overdue+principal


Quand ? !



Développement itératif !

Ecrire tous les tests puis tout le logiciel ?

Commencer plutôt par une partie du système.


Développement itératif !

Puis répeter le processus par incréments successifs


Chronologie !

Spécification Conception Dev Recette Homologation

Cycle en V :

Tests de recette

automatiques Tests unitaires

Tests de recette / Performances

UAT

Méthodes Agiles:

Itération 1 Itération 2 Itération 3 Itération 4 Itération 5

Tests de

recette

Tests

unitaires

Tests de

recette

Tests

unitaires

Tests de

recette

Tests unitaires et performance

Tests de

recette

Tests de

recette

UAT Tests unitaires et

performance


Evolution du temps consacré à la recette !!"#$"%&%'()!"%

$"*+#%

!","$$"%

!"#$"%&%'()!"%

$"*+#%

!","$$"%

!! Le temps de recette est

concentré en fin de projet

!! A une période critique (proche de la livraison)

!! Longtemps après le

développement de la

fonctionnalité

!! Le temps de recette est mieux

réparti sur la durée du projet

!! Minimisation du risque

!! Diminution du coût (erreurs

détectées plus tôt)


Avec quoi ? !



Limites des tests fonctionnels sur l’IHM!

Automatisation par capture puis re-jeu

!! tests sur l’IHM

!! difficile à automatiser

!! tests élaborés a posteriori

!! changements fréquents

!! maintenance coûteuse

!! édition de script fastidieuse


Framework for Integrated Testing !

Automatisation par construction

!! tests sur les API

!! indépendance à l’IHM

!! tests élaborés à l’avance

!! format tabulaire des tests

!! intégrant des descriptions

!! pas d’édition de scripts


Complémentarité des deux approches !

Tests sur IHM Tests de type FIT

•! Possibilité de valider l’IHM

•! Facilité de création

•! Ne peuvent pas être écrits « à priori »

•! Plus difficiles à maintenir

•! Ecriture « à priori » possible

•! Proche des cas d’utilisation

•!Ne permettent pas de valider l’IHM

•! Win Runner

•! …

•! Fit / Fitnesse / Slim

•! GreenPepper

•!…


Fonctionnement !

!! Fonctionnement

exécute

restitue

Valeurs saisies Valeurs à vérifier


Fonctionnement !

MOA

MOE


Schéma de fonctionnement !

FIT système

testé page de tests

code de

liaison


Repository de tests Fitnesse !

Site intranet

Composé de pages éditables

Intégrant texte et schémas

Organisé en suites de tests

Permet d’exécuter tous les tests

MOA


Pour quoi? !



Types d’utilisation !

!! Tester l’IHM (html) :

!! possible avec FIT, mais pas forcément une solution optimale

!! Tester un progiciel :

!! lorsque la couche métier est exposée via une API java

!! lorsqu’il y a des points d’entrée / sorties fichier

!! Tester des traitements batch

!! sur les fichiers en entrée et en sortie

!! Tester une chaîne d’applications (EAI)

!! aux points d’entrée de la chaîne ou via l’interface des outils EAI


Qui ? !



Conseils d’utilisation!

!! utiliser en collaboration (MOA/MOE)

!! travailler en mode itératif incrémental

!! concevoir les tests au plan métier puis

le code de liaison

!! faire vivre la base de tests

!! factoriser et normaliser les données

de tests

!! masquer les aspects non-fonctionnels

!! surveiller la taille du code de liaison


Où ? !



Exemple d’usine de développement !

Livraison

Développeur

Développeur

! Tests

unitaires

Build

Logiciel Tests de recette

auto.

Indicateurs qualité

Gestion de version

Code source

(logiciel + tests)


Mais aussi… !

Démonstration


Fitnesse : D’autres jeux !


DBFit !


Fitnesse - Industrie !


Effets de bord…!


Méthodologie !

Automatiser les tests permet un développement plus agile :

!! supprime une partie des spécifications au profit des tests

!! réduit le délai de retour d’information sur le système

!! permet un développement itératif incrémental

!! permet d’évaluer correctement la stabilité d’un système

Les tests de recette permettent de piloter le projet :

!! clarifier les besoins exprimés via des exemples concret

!! piloter le projet à l’aide de jalons binaires

!! mesurer l’avancement et la vélocité de l’équipe (nombre de TR

passant par itération)


Pilotage du projet par les tests !

Avancement = TR passants / nb. TR total estimé

Productivité = TR passants / itération


Résultats constatés !

Une mesure plus fiable de la productivité

Le test devient l’unité de mesure (« Ce qui est testé n’est plus à faire ») Des coûts de maintenance maîtrisés

La durée d'homologation d’une application complète n’est plus que de quelques jours

Les anomalies de recette diminuent en nombre et en gravité (« Il n’y a plus de

bug! ») Une gestion de la qualité plus pragmatique

Les indicateurs (tests) permettent de mesurer la qualité intrinsèque du livrable La gestion de la qualité est entièrement intégrée au processus de

développement (refactoring au fil des itérations)

Une meilleure évaluation du risque Un feedback fréquent permet de suivre l’évolution

Un projet peut être arrêté après seulement quelques itérations Des équipes qui restent motivées tout le long du projet

La pression est lissée

Une industrialisation du processus qui est répétable et répété toutes les 3 semaines


Bienfaits colatéraux !

Tester

Documenter ce que fait votre

logiciel par des tests

Collaborer entre les équipes technique et

fonctionnelle en spécifiant par les

tests

Assurer la non-régression en constituant un

harnais de tests

Automatiser les tests pour éviter

les erreurs manuelles

Piloter le projet via une mesure

univoque


Conclusion !


Automatiser ses tests fonctionnels pour

!! Un logiciel plus fiable

!! Moins de stress

!! Une équipe, alignée

!! Un meilleur pilotage

!! Un gain de temps

« Passer des tests manuels aux spécifications exécutables… »


Philippe KERNEVEZ pkernevez@octo,com

Avenue du Théatre, 7!

1010 Lausanne

Tél : +41 21 312 94 15 !

Initiation aux tests fonctionnels - Philippe Kernevez - October 2009

Technology

Transcript of Initiation aux tests fonctionnels - Philippe Kernevez - October 2009