31
Alignement avec les métiers par le test fonctionnel et d’acceptation en projets agiles

presentation Zest au JFTL 2014

Embed Size (px)

DESCRIPTION

Le pilotage des développements par les tests d’acceptation reste un problème difficile à maîtriser dans les projets agiles. D’une part, il est compliqué d’impliquer les analystes métier dans la réalisation de scripts de tests automatisés, et d’autre part les tests de hauts niveaux qu’ils peuvent produire sont souvent difficiles à maintenir et automatiser. L’approche proposée, supportée par une plate-forme appelée Zest, associe la définition des scénarios de tests d’acceptation sur la base d’un DSL (Domain-Specific Language) construit incrémentalement avec des mots d’action, et des fonctions de refactoring qui permettent en permanence d’optimiser les scénarios pour en faciliter l’automatisation et leur maintenance.

Citation preview

Page 1: presentation Zest au JFTL 2014

Alignement avec les métiers par le test

fonctionnel et d’acceptation en projets

agiles

Page 2: presentation Zest au JFTL 2014

Guillaume CoquelleTesteur, Availpro

[email protected]

www.availpro.com

Laurent PYCEO, Smartesting

[email protected] @py_laurent

www.smartesting.com

Page 3: presentation Zest au JFTL 2014

Smartesting en 30 secondes

Editeur de logiciel de test créé en 2003

Sites : Besançon, Paris et Bangalore (Inde)

Notre ADN : Nous croyons au test comme patrimoine de connaissance de l'entreprise et comme vecteur d’efficacité et d'alignement entre les différentes parties prenantes d'une organisation

Clients & Partenaires :

Page 4: presentation Zest au JFTL 2014

Introduction

Page 5: presentation Zest au JFTL 2014

Développement - cycle en V

– Peu de tests fait par les développeurs (pas de TDD)

– 1 release chaque 6 mois

– 1 mois (x5 ingénieurs) pour faire du ‘release testing’ avant déploiement

– Niveau de qualité faible impactant nos clients et retours négatifs

Processus de développement chez Smartesting 2004/06

5

Page 6: presentation Zest au JFTL 2014

Développement agile

– Scrum, TDD, Pair programming

– Mise en place de l’intégration continue

– 1 release client chaque 3 mois (une opérationnelle chaque 3 semaines)

– 1 mois/homme pour faire du ‘release testing’ avant déploiement

– Bon niveau de qualité

Introduction des méthodes agiles - 2006

6

Page 7: presentation Zest au JFTL 2014

DevOps

– Déploiement continue agilité métier

– Plusieurs releases par jour!

– Acceptance Testing Driven Development (ATDD), 100% automatisé…

– … complété par du test exploratoire

Plate-forme de test agile dans le cloud - 2012

7

http://www.thucydides.info/blog/295-does-atdd-really-save-you-time

Avec les pratiques ATDD et TDD, les projets sont livrés 31% plus vite et avec 4 fois moins de défauts

Page 8: presentation Zest au JFTL 2014

Les méthodes agiles conduisent à des itérations courtes (1 à 4 semaines) et une automatisation massive des tests

La chaine de valeur est compressée ⇒ test d’acceptation = spécification

Le test démarre en amont ou en parallèle des développements: Shift left !!!

Notre retour d’expérience

8

Req Manageme

nt & Definition

Test Planning

Execution

Defect manageme

nt

Page 9: presentation Zest au JFTL 2014

9

Notre retour d’expérience

Les propriétés clés des tests d’acceptation pour itérer rapidement :

– Lisibles pour faciliter la communication et permettre le ‘shift left’

– Maintenables aisément pour gérer les impacts des évolutions et nouvelles fonctionnalités

– Automatisables pour une exécution rapide

Page 10: presentation Zest au JFTL 2014

Le développement piloté par les tests d’acceptation

Page 11: presentation Zest au JFTL 2014

Le test et les projets agiles

How Can You Scale Your Agile Adoption? Diego Lo Giugice, Forrester (Fev. 2014)

Page 12: presentation Zest au JFTL 2014

Scrum et le test d’acceptation

PO Développeurs testeurs Scrummaster

Équipe Scrum

Tests d’acceptationTests d’acceptationShift left

Page 13: presentation Zest au JFTL 2014

Acceptance Testing Driven Development (ATDD)

Le test d’acceptation est un outil de communication

Il est la définition du ‘STOP’

Ecrits par le Tester avant le développement

Basés sur un DSL (Domain Specific Language)

Validés par l’équipe projet

Très souvent automatisés

Test en language naturel

Test fixture

Code

Page 14: presentation Zest au JFTL 2014

Acceptance Testing Driven Development (ATDD)

Bénéfices– Améliore la collaboration et communication autours des tests

d’acceptation

– Compréhension partagée de ce que signifie implémentation réussie

– Meilleure couverture des besoins métiers

– Feed-back plus rapide

Challenges:– Nouvelle méthodologie nécessitant rigueur et discipline

– Trouver le bon équilibre personne/processus/outils

Page 15: presentation Zest au JFTL 2014

ATDD & Refactoring

Les tests d’acceptation doivent être continuellement revus et refactoré tout comme le code!

Martin Fowler

Page 16: presentation Zest au JFTL 2014

Test d’acceptation en continu

Page 17: presentation Zest au JFTL 2014

Fonctionnalités clés:

– Définition progressive des mots d’actions métier, permettant de créer un DSL (Domain Specific Language) pour l’écriture des scénarios de test

– Suggestion pour faciliter la réutilisation de mots d’action et limiter la duplication

– Refactoring: la modification de mots d’action métier impacte automatiquement l’ensemble des scénarios de test

– Optimisation: Des fonctions d’inspection permettent d’optimiser en permanence les tests

– Création de scripts pour l’automatisation (Ruby, Java, XML…)

Intégrations actuelles avec:

Zest: test agile dans le Cloud!

17

Page 18: presentation Zest au JFTL 2014

Zest: test agile dans le Cloud!

18

Product OwnerValide les tests d’acceptation

TesteurDéfinit les tests d’acceptation

DéveloppeurAutomatise les tests d’acceptation

Collaboration autour du test

Page 19: presentation Zest au JFTL 2014

Construire de nouvelles entités métiers…

Définition progressive du dictionnaire métier (Action Word). Collaboration autour des tests entre le métier, les testeurs et développeurs

Page 20: presentation Zest au JFTL 2014

…ou construire les entités métiers à partir des tests

Définition progressive du dictionnaire métier (Action Word). Collaboration autour des tests entre le métier, les testeurs et développeurs

Page 21: presentation Zest au JFTL 2014

Le diable DUPLICATION

Page 22: presentation Zest au JFTL 2014

Un principe fondamentale du développement/test

Page 23: presentation Zest au JFTL 2014

Réutiliser, réutiliser, réutiliser !

Permet de construire et maintenir des scénarios de tests consistants pour tout le projet

Propositions

Page 24: presentation Zest au JFTL 2014

Analyser et optimiser le plan de tests en continu

Réduction de l’effort de maintenance mesurable dès la phase d’import

Page 25: presentation Zest au JFTL 2014

Ajouter, supprimer, modifier des scenarios et mots d’action métier

Le refactoring permet de gérer automatiquement les impacts liés aux évolutions permanentes.

Ajout d’un paramètre au mot d’action

Propagation automatiqueaux scénarios l’utilisant

Page 26: presentation Zest au JFTL 2014

Générer les Scripts

L’utilisation de mots d’action métier réduit significativement le coût de l’automatisation et accélère le cycle de test

Page 27: presentation Zest au JFTL 2014

Synthèse

Des tests d’acceptation lisiblesLa définition d’un DSL métier facilite l’alignement de l’équipe autour des tests

Des tests d’acceptation maintenables

Les fonctions de refactoring et optimisation accélèrent la gestion des impacts liée aux évolutions

Des tests d’acceptation automatisables

La structuration et le design des scénarios facilitent la création

de scripts exécutables

Page 28: presentation Zest au JFTL 2014

Retour d’expériencesur le projet Availpro

Page 29: presentation Zest au JFTL 2014

Solution et technologies

v4.5v4.0

Page 30: presentation Zest au JFTL 2014

Bénéfices du déploiement de Zest

Collaboration de tous les acteurs autour du test: Le partage des scénarios permet aux membres des différentes équipes (développement, MOA, qualité) d’avoir une vision identique des tests réalisés: alignement par les tests. L’écriture des scénarios peut dorénavant se faire par tous types individus (technique ou non).

Collaboration instantanée dans la conception: les scénarios sont visibles pour toutes les personnes en temps réel. Pas de décalage comme on pourrait avoir avec des fichiers Excel.

Refactoring: Lors de modifications des fonctionnalités de nos applications, il peut être nécessaire de modifier / ajouter certains paramètres. Ceci est maintenant nettement plus rapide car centralisé et automatique. Gain de producitvité de l’ordre de 50%

Intégration avec JIRA Agile : Gestion de la traçabilité entre les issues (user story, tâche) dans JIRA et les scénarios dans Zest. Indication de l’évolution de l’écriture des scénarios

Intégration avec le framework d’automatisation: Aucune modification dans le code robot nécessaire.

Page 31: presentation Zest au JFTL 2014

Questions / Réponses

www.smartesting.com www.availpro.com