Waterfall project management separates development and testing into two different steps: developers build a feature and then "throw it over the wall" to the quality assurance team (QA) for testing. The QA team writes and executes detailed test plans. They also file defects when painstakingly checking for regressions in existing features that may have been caused by new work.
Beaucoup d'équipes qui utilisent ces modèles en cascade ou d'autres modèles de tests traditionnels constatent qu'à mesure que le produit se popularise, le volume de tests augmente de façon exponentielle. Et l'équipe QA lutte invariablement pour tenir le rythme. Les responsables produit font alors face à un choix malvenu : retarder la livraison ou lésiner sur les tests. (Je vous laisse deviner l'option qui remporte l'adhésion 99 % du temps.) Entre-temps, le développement est passé à autre chose. Donc, non seulement la dette technique augmente, mais la gestion de chaque défaut requiert un changement de contexte coûteux entre deux portions de la base de code. La double peine.
Et, comme si cela ne suffisait pas, les équipes de QA sont généralement gratifiées en fonction du nombre de bugs qu'elles trouvent, ce qui met les développeurs sur la défensive. Et s'il existait une meilleure façon, à la fois pour les développeurs et l'équipe de QA, de réduire le nombre de bugs dans le code, tout en éliminant ces douloureux compromis que les Project Owners sont contraints de faire ? Globalement, les logiciels ainsi développés ne seraient-ils pas de meilleure qualité ?
Bienvenue à l'ère des tests Agile et DevOps.
Migrer des tests traditionnels aux tests agiles
L'objectif des équipes Agile et DevOps est de livrer de façon durable de nouvelles fonctionnalités de qualité. Cependant, les méthodologies de test traditionnelles ne cadrent tout simplement pas avec un framework Agile ou DevOps. Le rythme du développement nécessite une nouvelle approche pour garantir la qualité dans chaque build. Chez Atlassian, notre méthode de test est agile. Examinez attentivement notre approche de test avec Penny Wyatt, Senior QA Team Lead pour Jira Software.
À l'instar de l'amoncellement de dettes sur une carte bancaire, cela commence par une douleur presque imperceptible. Mais l'effet boule de neige est rapide et prive l'équipe de sa cruciale agilité. Chez Atlassian, pour lutter contre l'effet boule de neige de la dette technique, nous habilitons nos développeurs à devenir (ou plutôt, attendons d'eux qu'ils deviennent) d'excellents champions de la qualité. Nous estimons qu'ils apportent des compétences clés qui favorisent la qualité du produit :
- Les développeurs brillent dans la résolution des problèmes au moyen du code.
- Les développeurs qui créent leurs propres tests seront davantage sollicités pour les corriger en cas d'échec.
- Les développeurs qui comprennent les exigences liées aux fonctionnalités et leurs implications au regard des tests créent généralement un meilleur code.
We believe each user story in the backlog requires both feature code and automated test code. Although some teams assign the developers the feature code while the test team takes on automated testing, we find it's more effective to have a single engineer deliver the complete set.
Gérez différemment les bugs des nouvelles fonctionnalités et les régressions des fonctionnalités existantes. Si un bug apparaît pendant le développement, prenez le temps de comprendre l'erreur commise, corrigez-la, puis passez à autre chose. Si une régression survient (une fonctionnalité qui présente soudainement un problème alors qu'il n'y en avait pas auparavant), il est probable qu'elle se reproduise. Créez un test automatisé pour vous protéger contre cette régression à l'avenir.
This model doesn't mean developers work alone. It's important to have QA engineers on the team as well. QA brings an important perspective to the development of a feature, and good QA engineers know where bugs usually hide and can advise developers on probable "gotchas."
Une touche humaine grâce aux tests exploratoires
On our development teams, QA team members pair with developers in exploratory testing, a valuable practice during development for fending off more serious bugs. Much like code review, we’ve seen testing knowledge transfer across the development team because of this. When developers become better testers, better code is delivered the first time.
But isn't exploratory testing manual testing? Nope. At least not in the same sense as manual regression testing. Exploratory testing is a risk-based, critical thinking approach to testing that enables the person testing to use their knowledge of risks, implementation details, and the customers' needs. Knowing these things earlier in the testing process allows the developer or QA engineer to find issues rapidly and comprehensively, without the need for scripted test cases, detailed test plans, or requirements. We find it's much more effective than traditional manual testing, because we can take insights from exploratory testing sessions back to the original code and automated tests. Exploratory testing also teaches us about the experience of using the feature in a way that scripted testing doesn't.
La qualité, si l'on veut la préserver, nécessite un mélange de tests exploratoires et de tests automatisés. Au fur et à mesure du développement de nouvelles fonctionnalités, les tests exploratoires garantissent que le nouveau code respecte le standard de qualité de façon plus globale que les seuls tests automatisés. Ceci passe par la simplicité d'utilisation, l'attrait visuel et l'utilité générale des fonctionnalités, en plus des protections efficaces contre les régressions qu'offrent les tests automatisés.
Le changement peut être difficile, très difficile
I'll leave you with a personal anecdote that nicely summarizes my journey with agile testing. I remember managing an engineering team early in my career that had strong resistance to writing automated tests, because "that work was for QA". After several iterations of buggy code and hearing all the reasons why automated testing would slow the team, I put my foot down: all new code had to be proven by automated tests.
After a single iteration, code started to improve. And the developer who was most adamantly against writing tests turned out to be the one who sprung into action when a test failed! Over the next few iterations the automated tests grew, scaled across browsers, and made our development culture better. Sure, getting a feature out the door took longer. But bugs and rework dropped significantly, saving us huge amounts of time in the end.
Change is rarely easy. But like most things worthwhile, if you can buckle down and create new patterns for yourself, the only question you'll be left with is "Why didn't we do this sooner?!"
