La plupart des Business Analysts débutants, lorsqu’ils sont initialement enrôlés dans des activités de test logiciel, ont l’impression qu’on leur parle chinois. UAT, test d’intégration, test fonctionnel… Mais de quoi s’agit-il ?
Dimitri Hammerer, reconverti en 2022 avec succès comme Business Analyst en systèmes d’information après une première carrière dans la Marine Nationale, a choisi de vous partager dans cet article les bases du test à connaître pour ne pas vous sentir submergé par le jargon technique.
Alice me contredira peut-être (NDE : effectivement, je ne serais pas aussi catégorique, mais c’est l’expérience de Dimitri, et sans doute celle de nombreux autres BA reconvertis 😉 ) mais, lorsque l’on devient Business Analyst, une des premières missions qui nous est généralement dévolue est la rédaction des spécifications à destination des développeurs : que ce soit des user stories, des cas d’usages ou des spécifications fonctionnelles et non fonctionnelles.
Ensuite, on étend progressivement son champ de compétences au gré des missions qui nous sont confiées :
- Soit vers l’élicitation du besoin client (et sa transcription en exigences lors de la phase de cadrage d’un projet) ;
- Soit vers le test du produit (que ce soit avant livraison au sein de l’équipe de maitrise d’œuvre ou lors de la recette en tant qu’assistance à maitrise d’ouvrage).
Dans cet article, je vais vous détailler les grands principes du test logiciel au cours d’un cycle de développement logiciel en V comme au sein des équipes Agiles.
Pourquoi tester ?
James Reason a théorisé tout au long de sa vie les modèles qui peuvent conduire à la défaillance d’un système complexe. Le plus connu est le modèle des plaques (ou tranches de fromage) qu’il a publié en 2000. Je le trouve particulièrement adapté à la compréhension de l’intérêt du test logiciel.
Par nature, l’être humain est faillible. Il est donc parfaitement normal que tout le monde commette des erreurs. Ces erreurs peuvent intervenir à différents moments du cycle de développement logiciel (cadrage, conception ou codage) et sont à l’origine de défauts dans le code informatique ou les documents nécessaires à sa conception. Si ces défauts ne sont pas détectés, lorsque la partie du code concernée par le défaut est exécutée, elle risque alors de conduire à une défaillance du logiciel. Selon sa gravité, la défaillance aura des conséquences plus ou moins impactantes.
L’objectif du test est justement de détecter les défauts avant la mise en production (usage opérationnel) du logiciel pour éviter qu’ils n’engendrent des défaillances.
Quand doit-on tester ?
Tout dépend du mode de développement de votre logiciel. Pour faire simple on va distinguer deux grands types de développements :
- En cycle en V, lorsque le besoin est clairement déterminé et figé ;
- Agile, lorsque le besoin n’est pas clairement défini ou qu’il est évolutif.
Le test dans un contexte de développement en V
Le cycle en V de développement d’un logiciel implique 9 grande phases :
- 4 phases de conception
- Une phase de réalisation proprement dite du logiciel
- 4 phases de test correspondant à chacune des phases de conception.
Chaque phase de test correspond à ce qui est aussi appelé un « niveau de test », en partant du niveau le plus proche de la réalisation du logiciel on trouve :
- Les tests unitaires : réalisés au niveau des composants du logiciel par les développeurs, ils visent à vérifier leur bon fonctionnement individuel. Par exemple, vérifier que le bouton d’ajout au panier d’un site de e-commerce ajoute bien le produit visé dans la base de données correspondante.
- Les tests d’intégration : réalisés au niveau de l’interface utilisateur par les développeurs (et parfois par l’équipe de test), ils visent à vérifier le comportement fonctionnel et non fonctionnel des interfaces entre les différents composants, voire entre les différents sous-systèmes du logiciel. Par exemple, sur le site de e-commerce précédent, vérifier que lorsque le client ajoute un article dans son panier avec le bouton cité dans les tests unitaires, le produit visé apparaît par la suite dans le panier de l’intéressé.
- Les tests système ou de validation : réalisés au niveau de l’interface utilisateur par l’équipe de test (qu’ils soient spécialistes du test ou business analystes), ils visent à vérifier que le logiciel répond bien aux spécifications du client avant la livraison. On entend aussi parler de tests « bout en bout ». Par exemple, sur le site de e-commerce précédent, vérifier que lorsque l’achat d’un bien est validé, le stock de ce produit est bien décrémenté de la quantité commandée par le client.
- Les tests de recette : réalisés au niveau de l’interface utilisateur par la maitrise d’ouvrage (le client), ils visent à accepter ou rejeter le logiciel fourni par la MOE en vérifiant davantage que le logiciel va bien répondre au besoin métier. On en distingue 4 grands types :
- Les fameux UAT (User Acceptance Tests) réalisés par le métier (utilisateurs finaux) pour vérifier que leur besoin est bien couvert ;
- Les OAT (Operational Acceptance Tests) réalisés par les administrateurs du système pour vérifier que les fonctions dont ils auront besoin (sauvegarde, modification de droits…) sont bien opérationnelles ;
- Les tests réglementaires réalisés pour vérifier que le logiciel répond bien à certaines contraintes réglementaires (par exemple dans le milieu de l’aviation) ;
- Les tests alpha ou bêta qui permettent à des personnes externes au projet de donner leur avis sur le logiciel. Les tests alpha sont réalisés par des collaborateurs de l’entreprise tandis que les tests bêta sont réalisés par des personnes externes à l’entreprise (les fameux « bêta testeurs » qui sont parfois choisis parmi les plus grands fans de la marque).
Le test dans un contexte Agile
Rappelons tout d’abord que dans le cadre Agile le plus connu, Scrum, il n’y a pas de rôle spécifique de testeur. Seuls coexistent le Scrum Master, le Product Owner… et bien sûr d’équipe de développement. La question que devra alors se poser l’équipe Agile sera : « Doit-on ajouter un rôle spécifique de testeur ou répartir ce rôle entre le Product Owner et d’équipe de développement ? ».
J’ai tenté de faire des recherches sur le sujet mais les avis sont extrêmement variés, je me contenterai donc de vous indiquer mon approche, qui ne doit surtout pas vous servir de loi immuable, mais plutôt de base de réflexion.
Je ne suis pas pour créer un rôle de testeur spécifique car il contribuerait à déresponsabiliser l’équipe Scrum, j’ai donc inventorié les différentes actions liées au test qu’il faut répartir au sein de l’équipe :
- Concevoir les critères d’acceptation de la user story (généralement une partie de la « definition of ready »).
- Exécuter les tests unitaires liés aux composants ajoutés à la user story.
- Exécuter les tests d’acceptation définis précédemment. Je ne suis pas pour ajouter les concepts de tests d’intégration et tests systèmes qui sont très propres au cycle en V… bien qu’il s’agisse à ce niveau de tests de validation.
- Concevoir, exécuter, et surtout automatiser, les tests de non-régression. En effet, les méthodes Agiles étant incrémentales, l’automatisation des tests de non régression est un facteur clé de vélocité de l’équipe.
- Analyser les tests en échecs pour préparer le débogage du logiciel.
- Vérifier le bon respect de la « definition of done » de la story avant de la valider.
Le point 1 est à mon sens de la responsabilité du PO lorsqu’il conçoit sa user story. Il est d’ailleurs préférable qu’il valide ces éléments directement avec la maitrise d’ouvrage au préalable.
Le point 2, comme dans le cycle en V, est de la responsabilité de l’équipe de développement.
Les point 3, 5 et 6 sont plus flous, afin de libérer un maximum de temps au PO, je serais plutôt d’avis de les confier à l’équipe de développement… A condition que la rédaction des critères d’acceptation soit suffisamment claire.
Le point 4 est le seul qui pourrait nécessiter de faire appel à un spécialiste du test, rompu à leur automatisation… mais une équipe Agile suffisamment expérimentée pourrait aussi le confier à son équipe de développement.
Cet article vous a été proposé par Dimitri Hammerer, reconverti en 2022 avec succès comme Business Analyst en systèmes d’information après une première carrière dans la Marine Nationale.
