Introduction

Lisez ceci avant de passer au chapitre suivant

Même si vous n’y comprenez rien au code, ou même si vous n’aimez pas ça, retenez que la connaissance technique est un énorme facilitateur pour le test. Elle permet :

- d’anticiper ou de comprendre des problèmes sur le produit et les tests ;

- d’aider les développeurs à voir d’autres voies qu’ils pourront exploiter pour améliorer la testabilité et le produit lui-même dès sa conception ;

- de propulser l’industrialisation des tests par la mise en œuvre de tests techniques ou avec l’automatisation.

Par ailleurs, il n’est pas rare d’entendre parler de « tests techniques ». Ce sont généralement des tests qui impliquent suffisamment de connaissances sur le monde du développement pour être capables d’implémenter les tests. C’est le cas des tests de charge ou de sécurité (voir chapitre Tests non fonctionnels). La triste vérité est que culturellement, le test est prioritairement axé sur les fonctionnalités et le métier. Cette culture a orienté toute une génération de testeurs qui n’a fait que répondre à une demande du marché qui n’a compris que l’image d’Épinal du test : une liste...

Le Software Craftsmanship (SC ou « Craft »)

Pour entamer ce voyage dans la technique, commençons par ouvrir un plan du métro. Téléchargez-le depuis http://tinyurl.com/sw-craftsmanship-map, ça vous évitera de vous plaindre parce que c’est écrit trop petit.

Figure VI-1 : Cartographie incomplète du « Software Craftsmanship »

Dans la même lignée, vous trouverez chez bbv.ch une cartographie interactive sur la qualité logicielle : https://quality.bbv.ch/.

Au chapitre Avant-propos, vous aviez pu voir une première carte d’un métro souterrain. Celle proposée dans ce chapitre-ci serait comme un métro aérien. Cette seconde carte réunit quelques dizaines de pratiques liées à la qualité logicielle, certaines ont un lien pour commencer à découvrir la rue desservie par la station. Ces lignes traversent différents quartiers tels que :

le codage ;
le refactoring ;
l’architecture ;
le métier ;
les Ops ;
le centre-ville qui est à la croisée de tous ces quartiers ;

Il y a aussi certaines banlieues dangereuses telles que :

la dette technique ;
l’inconsistance technologique ;
le mur de la confusion ;
l’interruption du business.

Si vous survolez les différentes stations dans cette ville, vous pourrez déjà en reconnaître certaines qui ont déjà...

Test de conception et de code

Commençons notre découverte de cet obscur domaine afin de vous permettre de tester au plus tôt, d’autant que dans une équipe agile, tout le monde teste, et le développeur est le premier concerné : c’est à son niveau qu’environ la moitié des anomalies sont générées [Beizer 1990], il est donc primordial de partager les clés pour améliorer cette phase.

Comment utiliser ce chapitre si vous n’avez aucune légitimité pour parler technique ?

L’échange régulier avec les développeurs de votre équipe est la clé. N’hésitez pas :

- à leur poser des questions sur des parties de ce chapitre qui sont obscures pour vous ;

- faites leur éventuellement lire certaines parties pour qu’ils vous expliquent ;

- demandez simplement si ce ne serait pas applicable à leur contexte ;

- appliquez la stratégie de la concierge (voir chapitre Tests non fonctionnels à la section Migrations impliquant la reprise des données).

1. Prévenir les défauts dans le code

a. Responsabilité collective du code

La responsabilité collective est un concept du domaine de l’éthique politique que Max Weber, un des fondateurs de la sociologie, a conceptualisé sous le terme « Ethique de responsabilité et éthique de conviction » [Weber 1919].

Pour voir le parallèle entre la responsabilité collective du code et ce concept de Weber, vous pouvez déjà vous représenter ce concept par la dualité « personne n’est coupable / tout le monde est responsable ». L’engagement des développeurs envers la qualité et la fiabilité du code est similaire à l’engagement politique. Par ailleurs, le développeur est régulièrement amené à naviguer entre la recherche de solutions techniques idéales (les convictions du savant) et la prise en compte des implications pratiques (la responsabilité du politique).

Pour y parvenir, Weber propose la notion de « neutralité axiologique », ou science libre de jugements de valeur, posture méthodologique qui vise à ce que le savant...

Ingénierie des Tests d’Intégration (TI)

Traditionnellement, une fois que les unités ont été réalisées et testées, vous pouvez commencer à vérifier que ces unités parviennent à communiquer comme prévu, c’est le test d’intégration.

Le but des TI est d’assurer la bonne communication entre au moins deux composants. Ils viennent en complément de la vérification de la conformité des interfaces réalisée en TU et permettent d’adresser :

les problèmes de compatibilité entre les composants ;
les questions de portabilité de chaque composant dans un environnement donné.

Ces deux aspects de l’ISO 25010 sont parfois confondus, en fonction de la culture de votre interlocuteur :

une personne plutôt portée sur le développement évoquera plutôt la compatibilité, c’est-à-dire l’interopérabilité entre les composants, et la question de coexistence harmonieuse avec d’autres produits ;
une personne plutôt portée sur les Ops pensera en termes de portabilité, c’est-à-dire l’installabilité, la remplaçabilité, et l’adaptabilité.

1. Tests d’interopérabilité

À ce jour, il n’est pas rare de voir des organisations plutôt basées sur une approche par composants (voir le chapitre Quelques rappels), avec des équipes différentes qui ne se parlent qu’au moment de la livraison, c’est-à-dire au moment où leurs composants doivent s’interfacer avec ceux des autres équipes.

Généralement, une spécification, un « contrat d’interface », est définie comme point de départ du développement. Ce contrat fournit le comportement de chacun des composants qui partagent cette interface : le(s) producteur(s) et le(s) consommateur(s).

Que les développeurs aient recours au CDD, ou simplement au contrat d’interface comme point de départ du développement, les différences de compréhension d’une interface, ou le manque de spécification (ex. : un format de date non spécifié) peuvent amener des erreurs au moment...

Stratégie d’automatisation

Les raisons qui poussent à l’automatisation sont [Legeard 2017] :

près de 80 % des entreprises introduisent l’automatisation pour optimiser la couverture des tests de régression ;
60 % l’utilisent pour réduire la durée d’exécution des campagnes de test ;
un peu plus de 50 % viennent à l’automatisation suite à une démarche d’intégration continue.

Quatre ans plus tard, Legeard et al. relancent une étude similaire pour mesurer que les 3/4 du temps, l’automatisation des tests fait partie des tâches attribuées aux testeurs [CFTL 2021].

Pour James Bach, « le test est un défi intellectuel qui est bien plus qu’un processus mécanique et répétitif » [Bach 02-2014], cette section va tenter de vous apporter le nécessaire pour que vous puissiez dépasser cet amer constat en développant votre propre stratégie d’automatisation qui est en fait, plus large que la simple exécution de scénarios de vérifications.

En effet, l’image d’Épinal du test fait croire que tester c’est exécuter des scénarios de vérification de bon fonctionnement d’un produit. De même, ce que nous entendons généralement par « automatisation des tests » est en fait une vérification automatisée. Effectivement :

les scénarios de tests sont conçus pour vérifier la conformité d’une exigence fonctionnelle ;
les scénarios de tests, ce n’est pas le test [Bach 02-2014] ;
le bon fonctionnement ne suffit pas pour qu’un produit soit un bon produit : les ENF contribuent largement au succès d’une application ;
le test est plus qu’un processus mécanique et répétitif : de bons tests, tout comme la programmation, sont un processus intellectuel de l’ordre du défi [Bach 02-2014].

En conséquence des abus réguliers de langage, la première question qui émerge dans l’automatisation est « quels tests devons-nous automatiser ? ». C’est un peu comme si l’engagement dans l’automatisation était...

Environnement technique du test

Le contexte technique influence le test par ses spécificités. Dans cette section, nous allons examiner ces spécificités techniques à chaque moment où des éléments techniques sont disponibles pour être testés.

1. Environnement d’intégration

Commençons par regarder ensemble la phase de fabrication du produit, car la façon dont le produit va être généré va influencer la façon dont vous allez pouvoir le tester.

a. Branching Model

Le « Branching Model » correspond à l’intégration en continu de tous les développements réalisés par les développeurs, alors que le produit est encore sous la forme de fichiers sources, regroupés dans un outil de gestion de version.

Dans ce genre d’outil, il faut imaginer que le code évolue, au fil des mises à jour (ou « commits »), comme un arbre. Les lignées d’évolutions suivent des branches sur lesquelles les développeurs travaillent. Certaines de ces branches obéissent, par convention, à un objectif particulier, comme le « tronc » (ou « trunk » en anglais, aussi appelé « mainline » ou « master »). Ainsi, vous trouverez sur « master » le code qui correspond à ce qui est déployé en production.

En plus de créer des branches, l’outil de gestion de version permet aussi de fusionner (on dit aussi « merger ») les branches entre elles. Un « branching model » correspond au cheminement du code source dans les branches, jusqu’à parvenir sur la branche qui reflète le code de production.

Dans cette section, vous ne verrez que deux modèles de branches, les plus courants à ce jour, mais il en existe bien d’autres. Faites preuve de curiosité et allez en découvrir si le sujet vous intéresse.

Feature Branch

La plupart du temps, un développeur crée une branche de développement pour ajouter une fonctionnalité, puis il merge sa branche sur master.

Le merge est un moment privilégié pour une revue de code par un pair, si le développement...

Versant technique du test