Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici

Quelques rappels

Introduction

Ce chapitre propose quelques rappels sur :

  • l’agilité (en général) ;

  • les principes du test selon l’ISTQB ;

  • quelques techniques de test ;

  • et différentes organisations agiles.

Si vous êtes déjà familier avec ces points, n’hésitez pas à passer cette partie du livre.

Les 4 valeurs de l’agile - Rappel du Manifeste Agile

Le manifeste agile propose les valeurs suivantes [Beck 2001] :

images/01DP01.png

Figure 1 : Les 4 valeurs de l’agile

Ces éléments sont des préférences guidées par la notion de valeur ajoutée et les exemples suivants illustrent ce qu’il faut comprendre :

  • De façon générale, l’équipe privilégie toujours une bonne interaction entre ses membres plutôt que la formalisation d’un processus qui viendrait gérer une activité ; en revanche, il peut être vital pour l’organisation de capitaliser les informations produites aux différentes étapes d’un processus complexe : la valeur ajoutée des documents vient justifier leur présence.

  • Intrinsèquement, une belle documentation qui accompagne un logiciel qui ne fonctionne pas n’a jamais satisfait un client ; cependant, les personnes chargées de répondre à la hotline doivent disposer d’un minimum de documentation partagée avec les utilisateurs.

  • Le terme « contrat » peut être perçu comme un document légal ou une spécification « digne de ce nom », voire une US, mais l’usage est souvent légèrement différent, car il est toujours plus simple d’adapter la collaboration pour...

Les 7 principes du test - Rappel ISTQB

L’ISTQB fournit les 7 principes du test :

images/01DP02.png

Figure 2 : Les 7 principes du test selon l’ISTQB

1. Les tests montrent la présence de défauts

L’activité de test montre seulement la présence de défauts, ce qui veut dire qu’elle n’en démontre pas l’absence, mais son déroulement permet de réduire la probabilité de leur présence.

Cette évidence indique aussi que si on ne teste pas, on ne trouvera pas de défauts : « qui cherche trouve », mais il faut commencer par chercher et être capable de trouver, car les tests dépendent d’un oracle (https://en.wikipedia.org/wiki/Test_oracle), mécanisme qui permet d’évaluer la réponse indiquée par l’application testée avec ce qu’elle est censée répondre ; si l’oracle est faux, le test le sera lui aussi et on n’aura rien trouvé !

L’expérience de chacun montre que généralement, ces recherches se situent dans le domaine de l’exactitude fonctionnelle, car par manque de culture et poussée par l’urgence, la facilité poussera l’équipe à conserver le focus sur les seuls tests fonctionnels.

2. Les tests exhaustifs sont impossibles

De nos jours, les systèmes conçus sont d’une complexité telle qu’il est impossible de vérifier toutes les combinaisons qui permettraient de vérifier une éventuelle absence de défaut.

images/I-icone.png

Les limites de notre imagination

La formulation péremptoire de cette impossibilité est à porter au regard du contexte : sur un contexte simple, il sera évidemment simple de tout tester, mais cette apparence cache potentiellement des axes de qualité non imaginés, l’exemple du « bug du Chewing-gum » décrit plus loin dans ce chapitre est un exemple de cette impossibilité. Car lorsque toutes les conditions de qualité sont finies, leur vérification exhaustive n’est qu’une question de retour sur investissement, mais ces conditions sont-elles la vraie vie ou juste une conformité à une modélisation de la réalité ?

Reportez-vous à la section Pensée...

Techniques de test de base

1. Partitionnement de classes d’équivalences et valeurs limites

Lorsqu’une variable influence le comportement de l’application par palier, cette technique peut être utilisée pour identifier tous les tests qui seraient à réaliser.

images/I-icone.png

Définition d’une Partition en mathématiques

Pour comprendre cette notion au nom à rallonge, il suffit de se rappeler ce qu’est une partition au sens mathématique du terme : c’est un découpage d’un ensemble (E) en parties (Pi) toutes disjointes deux à deux :

images/01i01.PNG

et l’union de toutes les parties est égale à l’ensemble total :

images/01i02.PNG

Quant au terme « classe d’équivalence », il vient simplement du fait que, quelle que soit la valeur située sur un intervalle, le comportement restera le même.

images/01DP06.png

Figure 6 : Exemple de partitionnement d’une variable

Le partitionnement de la variable x choisie pour exemple en Figure 6 donne les classes suivantes :

  • Classe 1 : x < A1 (classe invalide)

  • Classe 2 : A1 ≤ x ≤ A2

  • Classe 3 : A2 < x < A3

  • Classe 4 : A3 ≤ x < A4 (classe invalide)

  • Classe 5 : A4 ≤ x < A5

  • Classe 6 : A5 ≥ x

Chaque classe sera ainsi vérifiée par un test (voir flèches du dessous sur la Figure 7).

En complément à ces vérifications, il faudra ajouter les tests de chaque valeur pivot (Ai) ; pour assurer cette partie, on dispose de deux tactiques en fonction de la criticité du test :

  • L’approche « 2 valeurs » avec un test juste avant (ou juste après) le pivot et un autre sur le pivot.

  • L’approche « 3 valeurs » avec un test juste avant, un juste après, et un autre sur le pivot.

Le choix du nombre de valeurs pivots dépendra de la criticité (ou du niveau de confiance).

La Figure 7 montre les tests de valeurs pivots avec les flèches du dessus.

Sur notre exemple, on constate qu’il faudra 21 (6 + 5x3) tests sur l’hypothèse de l’approche 3 valeurs sur les pivots.

images/01DP07.png

Figure 7 : Cas de tests avec les classes d’équivalences (flèches du dessous) et valeurs limites (flèches du dessus)

images/X-icone.png

Le bug de l’an 2000 - la valeur pivot la plus célèbre...

Le Cycle de vie logiciel

1. Projet à l’échelle d’une seule équipe SCRUM

images/I-icone.png

Pourquoi Scrum ?

Depuis plusieurs années, Scrum domine le marché de l’agilité au niveau de l’équipe [VersionOne 2016]. Naturellement, Scrum n’est pas l’agilité, mais en raison de sa représentativité, ce sera peu ou prou votre contexte. En revanche, parce qu’il n’y a pas deux équipes identiques, vous ne trouverez pas parfaitement la même mise en pratique de Scrum partout, alors bien entendu celles qui seront présentées ici tenteront de donner un éclairage qui reviendra régulièrement sur les fondamentaux de l’agilité afin de vous permettre de recentrer la pratique pour l’appliquer à votre propre contexte.

Pour Scrum, il n’y a pas d’équipe dans l’Équipe. Scrum ne reconnaît donc pas la présence d’une équipe de test dans l’équipe de réalisation ; en d’autres termes, le test est idéalement confié à tous, au même titre que d’autres activités telles que l’architecture.

Par ailleurs, l’équipe de développement étant dans son ensemble responsable de la qualité du produit livré, chacun doit participer à la qualité du produit, et aider au test autant que nécessaire !

images/I-icone.png

La répartition des responsabilités

Que ce soit la notion de responsabilité collective ou l’absence d’équipe de test dans l’équipe de réalisation, Scrum vise à ce que chaque membre de l’équipe sache tout faire.

Naturellement, dans la réalité cette vision est nuancée par les appétences et les facilités de chaque individu. On trouvera ainsi une équipe composée de leaders sur un domaine, mais dont la majeure partie du savoir-faire est présent dans toute l’Équipe.

NB : Un corollaire de cette vision est qu’un testeur devrait lui aussi savoir (un peu) coder !

a. Scrum en quelques lignes

Cette section a pour objectif de planter le décor d’une équipe agile de type Scrum.

Cette équipe Scrum comprend trois rôles :

  • le Scrum Master : c’est celui...