Le document aborde l'importance de la qualité dans l'agilité, soulignant que la livraison d'un logiciel opérationnel est prioritaire et que l'automatisation des tests, y compris les tests de régression, est essentielle pour maintenir la vélocité de l'équipe. Il insiste sur la nécessité d'intégrer les testeurs dès le début du processus de développement et d'adopter des stratégies DevOps. Enfin, il met en avant l'émergence d'un nouveau type de testeur, capable de leadership et d'une maîtrise variée des technologies.

1. Pas d’agilité sans qualité
Agile Tour 2018
Le 15 Novembre 2018

2. Pas d’agilité
sans qualité

3. • Les individus et leurs interactions avant les processus et les
outils.
• Un logiciel qui fonctionne plutôt qu’une documentation
exhaustive.
• La collaboration avec les clients plutôt que la négociation
contractuelle.
• L’adaptation au changement plutôt que le suivi d’un plan.
Valeurs de l’agilité

4. • Un logiciel qui fonctionne plutôt qu’une documentation
exhaustive.

5. Un logiciel qui fonctionne plutôt
qu’une documentation exhaustive
• Livrer fréquemment un logiciel
opérationnel.
• Notre plus haute priorité est de satisfaire
le client.
• Un logiciel opérationnel est la principale
mesure de progression d'un projet.

6. En développant de façon itérative…
Pour obtenir un logiciel opérationnel à
chaque sprint, nous devons tester en
conséquence.
Donc, nous devons effectuer des tests de
régression des itérations précédentes.
N’est-ce pas?
Si 5% d’effort sont nécessaires
pour les tests de régression d’un
sprint…
Après 4 sprints, j’ai besoin de
20% !

7. Vous faite vos tests de régression MANUELLEMENT!
Lequel est «VOTRE» mensonge ?
• Le logiciel livré est opérationnel «à un niveau production».
Mais ce n’est pas vrai, depuis le sprint 3, nous n’avons plus le temps de faire
tous les tests de régression. On est optimiste!
• L’équipe maintient son niveau de vélocité.
Mais ce n’est pas vrai, depuis le sprint 3, on passe trop de notre temps en
tests manuels de régression.
Les tests de régression automatisés ne sont pas une option !

8. Super, vous automatisez les tests !
Les Unit Tests sont souvent hors cible.
L’automatisation des tests d’unité n’est pas
suffisante !
Maintenant, soyons déprimés !
@Test
public class ExampleTest {
public void testExample() {
assertTrue(true);
}}
– « Oui, l’équipe automatise les tests depuis un certain temps. »
– « Tests d’intégration ou de bout-en-bout ? » rétorquais-je.
– « Euh … »
J’insiste alors: « Quel niveau de test ? »
– « Ben oui, des Unit Tests »
– « !?!?! »

9. Super, certains d’entres-vous testent !
• Les programmeurs testent leurs
programmes en fonction de ce qu’ils
comprennent que leur programmes doivent
faire.
• Les testeurs testent pour que le « logiciel
fonctionne ».
L’objectif est le ATDD mesure le logiciel
désiré et la satisfaction du client !
Les testeurs ont leurs propres
paradigmes et pratiques.
STORIES
DESIGN
CODE
TESTS
PROGRAMMEURS
TESTS
TESTEURS

10. Wow! Vous avez des testeurs professionnels …
• Ils réfléchissent aux scénarios sous l’angle ATDD.
• Les tests de régression sont automatisés mais pas uniquement
les tests unitaires.
… mais c’est difficile de faire tout cela dans un sprint.

11. Le principe « Shift Left »

12. Le principe « Shift Left »
25 $ 100 $ 250 $
1 000 $
16 000 $
1%
85%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
- $
2 000 $
4 000 $
6 000 $
8 000 $
10 000 $
12 000 $
14 000 $
16 000 $
18 000 $
Code Tests unitaires Tests fonctionnels Tests d'intégration Déploiement et
production
Pourquoi est-ce important ?
Coûts
% de création
d'anomalies
% de détection
d'anomalies

13. Le principe « Shift Left »
25 $ 100 $ 250 $
1 000 $
16 000 $
1%
85%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
- $
2 000 $
4 000 $
6 000 $
8 000 $
10 000 $
12 000 $
14 000 $
16 000 $
18 000 $
Code Tests unitaires et
fonctionnels
Tests d'intégration
et de déploiement
Tests d'intégration Déploiement et
production
Nous cherchons à maximiser le « Shift Left »
Coûts
% de
création
d'anomalies
% de
détection
d'anomalies
Nous voulons que ceci se
produise durant un Sprint.
Sinon, nous nous mentons à
nous-mêmes.

14. Pour réussir un « Shift Left », on a besoin de …
Travailler sur un environnement réaliste dès le début
du processus de développement
• Avec des données vraisemblables
• Masquage des données
• Volume suffisant
• (Re) génération rapide des données.
• Avec des interactions vraisemblables avec
l’écosystème
• Avec les environnements nécessaires.
• « Stubbing » intelligent des systèmes
périphériques
• Pour aussi tester le déploiement

15. Pour réussir un « Shift Left », on a besoin de …
• Les testeurs doivent faire partie de la stratégie
DevOps.
• Les testeurs doivent maîtriser les outils CI/CD.
• Les testeurs doivent faire partie intégrante de
l'équipe de développement dès le début.
Pas après !
Tout cela en même temps que le code.

16. Un logiciel qui fonctionne plus
qu’une documentation exhaustive
• Livrez fréquemment un logiciel
opérationnel.
• Notre plus haute priorité est de satisfaire
le client.
• Un logiciel opérationnel est la principale
mesure de progression d'un projet.

17. Pour ne pas mentir …
• Nous devons automatiser les tests de régression
• Cette automatisation être effectuée jusqu'aux tests d'intégration
• ATDD doit guider notre approche de test
• Toute cette automatisation doit être faite « à l'intérieur » du sprint
• Nous devons donc maîtriser les concepts et les outils de DevOps
• Les testeurs participent activement à la stratégie du projet et sont complètement
intégrés à l'équipe. Il y a une seule équipe.

18. Un nouveau type de testeur émerge!
• Connaissances de plusieurs technologies.
• Impliqué et intégré dans l'équipe.
• Maîtrise de ses propres paradigmes.
• Debout! Avec leadership!
• Comprendre la valeur que les bonnes pratiques apportent!
• Les gestionnaires se doivent de soutenir la transformation.

19. 410 St-Nicolas, Bureau 101
Montréal, QC H2Y 2P5
4 Robert Speck Pkwy, 15ème étage
Mississauga, ON L4Z 1S1
www.askidact.com
François Bonetto
francois.bonetto@askida.com

20. Atteindre le «done»
Livrer de la valeur
Obtenir du «feedback»
Livrer de la qualité