Introduction

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.

Test de conception et de code

1. Préparation des tests pour la conception et le code

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 1994], il est donc primordial de fournir les clés pour améliorer cette phase.

Testeur traditionnel

Si vous êtes un Testeur « traditionnel », prenez connaissance de cette section, les notions qui y sont abordées restent centrées sur le test afin que vous puissiez coacher les Développeurs et les encourager à produire un bon code !

a. Responsabilité collective

Ce principe poussé par Scrum est une très bonne chose pour le code généré par l’équipe, car il permet à chacun de pouvoir intervenir sans risquer de marcher sur les plates-bandes d’un autre développeur et il multiplie du même coup les opportunités de revues de code.

Cette démarche est propice aux pratiques proposées par le Software Craftsmanship notamment :

la programmation sans égo car :

si le code est la propriété d’une personne de façon institutionnalisée ou par crainte des réactions de son auteur, il est évident que ce monopole paralyse l’équipe en cas d’absence ;
le code qui est produit ne saurait être parfait dès sa première écriture et il devra être refactoré (ou de façon plus académique « réusiné ») à plusieurs reprises afin d’améliorer sa maintenabilité, mais aussi pour ajouter progressivement les petites modifications attendues au fil de l’implémentation des US ;

éviter le code arbitraire car, sans explication le code pourrait être modifié sans avoir pris en considération les raisons des choix d’implémentation, ce qui pourrait le casser.

Les 10 commandements de la programmation sans égo

Gerald Weinberg est à l’origine de la formulation. Il fournit dix commandements [Weinberg 1998] :

1. Comprendre et accepter que l’on commettra des erreurs.

2. Vous n’êtes pas le code.

3. Peu importe votre...

Ingénierie des tests d’intégration

Dans une approche en « V », la génération des Tests d’Intégration (TI) peut commencer lorsque l’on a au moins deux composants qui sont définis et que leurs interfaces sont spécifiées. Dans un contexte agile, les TI peuvent être générés au même moment que les TU. Par ailleurs, dans la mesure où un PIC (voir plus loin dans ce chapitre) est mis en place, ils devront être automatisés et dans la mesure où les moyens essentiels à la mise en place des TI sont les pilotes et les bouchons déjà rencontrés lors de l’élaboration des TU, il arrive que les TI soient codés sur le même framework que les TU.

Intégration et Déploiement

L’usage du terme « intégration » dans la culture française introduit quelques ambiguïtés sur la pratique des tests d’intégration.

Bien souvent, sur de gros SI qui ne sont pas encore en Fast IT, on trouve une équipe qui intègre tous les modules des différentes équipes dans un environnement et les tests se bornent à vérifier que le déploiement s’est bien déroulé. On a ainsi introduit une confusion sur le terme de « test d’intégration » entre le déploiement de composants sur une plateforme et la vérification de l’imbrication de composants entre eux.

Dans ce document, les tests d’intégration seront à prendre au sens [ISTQBG], à savoir des tests d’imbrication des composants entre eux ; l’intégration de composants dans un environnement sera appelée « déploiement ».

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 corner cases - les cas complexes situés dans les recoins de l’application ; un peu comme lorsque l’on utilise un balai dans une pièce pour en faire le ménage, les coins sont difficiles d’accès et toujours difficiles à nettoyer !

Valeur ajoutée...

Stratégies d’automatisation

Pour l’agilité, l’automatisation est une clé, encore plus lorsque le projet embarque du DevOps dans son framework.

Selon Bruno Legeard [Legeard 2017], les raisons de l’automatisation sont :

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.

Tandis que les deux premières causes sont liées à la performance de l’activité de test, la troisième est clairement liée aux principes DevOps ; ainsi, avec une démarche agile, on est dans un contexte où l’accent est mis tôt ou tard sur l’automatisation que SAFe et bien d’autres points de vue encouragent fortement, car elle permet de réduire les coûts de Mise en production (MEP).

SAFe indique aussi que les coûts de MEP seront cumulés avec le manque à gagner d’une version qui tarde à être disponible et générer du chiffre d’affaires, et en déduit un délai de mise en production optimal. La réduction des délais de MEP par l’automatisation des tests permet de réduire les délais et les coûts d’exécution des campagnes de tests de régression.

Figure 20 : Impact de l’automatisation sur les coûts selon SAFe

Ce modèle peut évidemment être questionné notamment sur :

l’allure de la courbe de manque à gagner qui n’est pas forcément linéaire, par contre il est évident que si la fonctionnalité attendue a une certaine valeur ajoutée, le manque à gagner est forcément croissant ;
le coût de conception et de maintenance des tests automatisés, d’où la nécessité de définir une stratégie d’automatisation des tests.

1. Difficultés d’automatisation des tests

Dans une démarche d’automatisation, il existe plusieurs difficultés, qui résident sur un plan technologique, de développement...

Environnement technique du test

Le contexte du projet forge la façon dont l’application sera testée, autant sur les aspects technologiques (OS, web, mobile) que sur le processus de génération du produit, notamment avec l’agilité ou un processus d’intégration continue.

La bonne vieille campagne de test qui validait l’intégralité du produit et conçue dès l’obtention des spécifications est clairement abandonnée, car tout simplement impossible.

Le Testeur agile devra donc adapter sa stratégie de test en fonction de ces contextes, conformément aux principes [ISTQB].

1. Alpha Testing et Beta Testing

Le terme viendrait des conventions de test d’IBM dans les années 70 (voir https://en.wikipedia.org/wiki/IBM_Product_Test) qui préparaient la mise en circulation de nouveaux produits par deux phases :

Phase A - Alpha testing : cette phase consistait à réaliser des vérifications sur la conception et la faisabilité, avant toute annonce ;
Phase B - Beta testing : durant cette phase, des tests de vérification logiciels et matériels était conduits pour permettre le processus d’expédition au premier Client (« First Customer Ship » - Première livraison Client).

Cet héritage a été transformé vers :

Alpha testing : implication de quelques utilisateurs auprès de l’équipe de développement pour obtenir des retours en amont ;
Beta testing : implication de quelques utilisateurs en avant-première sur les premières versions du produit.

Cette distinction permet d’effectuer une mise en production incrémentale :

en partant d’une bonne réactivité sur les bugs souvent identifiés avec un effet « point de vue du Candide » rendu possible par les nouveaux regards sur le produit en Alpha Testing ;
avec une phase intermédiaire en Beta Testing où le produit passe des tests de laboratoire (l’étape de vérification) aux tests sur le terrain (étape de validation).

Vérification et Validation

Pour [CMMI], la Vérification est un contrôle d’une exigence en mode in vitro, c’est-à-dire dans les conditions idéales...

Versant technique du test