Savoir-faire

Introduction

« The problem is not the amount of unexpected changes in a software project; the problem is our inability to cope with them. »- The software craftsman

Bienvenue dans la deuxième partie. Vous entrez dans le second tunnel de l’aventure, pour vous initier à différentes techniques d’assurance qualité, qui vous aideront à maîtriser les besoins d’évolution logicielle. Et cela en complémentarité avec les boucles de feedback identifiées en première partie. Derrière ces techniques existent les éléments nécessaires pour produire du code et du produit de qualité.

Nous mettrons ainsi l’accent sur l’importance des tests dans la réalisation des solutions. La différence entre un produit A et un produit B, à fonctionnalités égales, est la qualité, tant perceptible que non perceptible par le client final.

Ce principe se retrouve chez les artisans horlogers. Deux montres, d’apparences identiques, n’auraient pas forcément le même prix. En effet, elles ne seraient pas architecturées, montées et testées de la même façon. En développement informatique, le Test avec un grand T est le garant d’un produit de qualité. 

Découvrons-les !

Tant qu’à faire quelque chose, autant...

TDD, au-delà du DD

« Quality is not expensive. The lack of skills is what makes well-crafted software expensive. TDD doesn’t slow developers down. Typing is not a bottleneck. Learning and mastering a new skill, practice, or technology is. » - Sandro Mancuso (The Software Craftsman: Professionalism, Pragmatism, Pride - série Uncle Bob)

Le TDD (Test Driven Development, développement et documentation par les tests) est une technique de développement où les tests sont moteurs du design applicatif. Contrairement à ce que l’on peut parfois entendre, il ne se résume pas à la réalisation de tests unitaires ou à l’utilisation de JUnit dans le cadre de projets Java. Mais en quoi cette distinction nous intéresse-t-elle en tant qu’aspirants craft ?

Rappelons-nous quelques valeurs du manifeste, à savoir la capacité à réaliser des logiciels bien conçus et l’apport constant de valeur. Ces deux aspects se placent sous couvert d’un apport constant de qualité en matière de design et en matière de valeur produit, afin de répondre pertinemment aux attentes des utilisateurs. Le TDD y contribue !

Avant de plonger dans différents étonnements structurant le sujet, il est opportun de parcourir les invariants et principes clés du TDD.

BDD, encore du DD

« BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters. » - Dan North

La communication est un facteur clé dans la réussite de tout projet informatique. Toute équipe, bien que dotée de compétences techniques, peut se retrouver en situation d’échec sur un projet à cause d’une mauvaise gestion de la communication. À l’opposé, une bonne communication entre les différents intervenants d’un projet offre plus aisément des opportunités de succès. Le BDD (Behavior Driven Development) est un dérivé du TDD. Ce process de développement tend à améliorer la communication et les attentes entre techniques (maîtrise d’œuvre) et non techniques (maîtrise d’ouvrage).

Agile Testing

Exploration du domaine de l’Agile Testing

La qualité est toujours attendue par les clients. Même s’ils n’en parlent pas ou qu’ils expriment expressément la volonté d’aller plus vite et de faire moins cher au détriment des phases de tests, au fond d’eux, ils s’attendent toujours, quand même, à avoir un produit de qualité correspondant à leurs attentes.

Les méthodologies agiles s’imposent, de plus en plus, comme un standard pour la réalisation de logiciels. Elles viennent remplacer les rituels séquentiels, à l’image du cycle en V. Dans ce dernier, la qualité fait l’objet d’une phase s’inscrivant en fin de cycle, pour valider la mise en production du logiciel. Pendant cette phase, il est courant de rencontrer des équipes d’assurance qualité dites fonctionnelles. Elles y exécutent pendant plusieurs semaines, tant des tests manuels que des tests automatisés. Voici quelques inconvénients de cette approche :

Dans le monde Agile, il est crucial de tester le plus tôt possible et le plus souvent possible. Il est important de s’assurer de pouvoir capturer et prioriser les besoins des utilisateurs et de les évaluer tout au long du cycle de développement. Une des clés de réussite des projets agiles est d’éviter de concentrer les activités de test au dernier moment, avec une validation ultime pour la mise en production. L’Agile Testing est le domaine qui englobe l’espace de méthodes, rituels et outils et qui instruit correctement la pratique de test au sein des équipes agiles. Les tests n’y font pas l’objet d’une phase discrète. Ils ne sont plus sanctuarisés dans des plans de tests préécrits, rigides et qui font office...

Performance et sécurité

« Anything that can go wrong will go wrong. » - Murphy’s law

La sécurité et la performance font partie de ces aspects applicatifs que l’on catégorise par défaut comme étant des besoins non fonctionnels, pour la simple et bonne raison qu’elles sont souvent considérées comme des notions implicites. Les clients, les utilisateurs finaux, partent du postulat qu’il n’y a pas lieu de spécifier ce qui est évident, ce qui semble être du bon sens, à savoir bénéficier d’une application sécurisée et performante. Et cela au même titre qu’il n’y a pas besoin de préciser que l’on souhaite avoir un système de qualité. Ce sont là des aspects qui s’inscrivent dans le périmètre des tests exploratoires menés dans le cadre de l’Agile Testing. Ils sont non négociables !

L’expérience utilisateur en dépend. Il n’est ni concevable ni acceptable d’offrir une UX moindre, celle où l’utilisateur ne bénéficierait pas du bon niveau de protection de ses données personnelles, d’une intégrité fonctionnelle et de performances raisonnables. Quelque part, la relation qui s’établit entre un utilisateur et une application se révèle être de l’ordre de la relation de confiance.

Dans le cas du Craftsmanship, nous participons activement et proactivement à la création de cette relation de confiance. Sa pérennisation est nécessaire pour la construction de partenariats productifs avec nos clients. Je vous renvoie particulièrement à la quatrième et dernière valeur du Manifesto of Software Craftsmanship.

« Not only customer collaboration, but also productive partnerships. » - 4th craftsmanship value

En tant qu’aspirant craft, vous devez veiller par défaut à la réalisation de solutions sécurisées, performantes et maintenables. En gardant le futur à l’esprit, vous devez intégrer de telles préoccupations dans vos rituels, allant du design jusqu’au monitoring de l’application en production. C’est une préoccupation continue...

Synthèse et exercices