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] :
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 :
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.
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.
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 : et l’union de toutes les parties est égale à l’ensemble total : 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. |
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.
Figure 7 : Cas de tests avec les classes d’équivalences (flèches du dessous) et valeurs limites (flèches du dessus)
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
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 !
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...