Avant de débuter ce nouveau chapitre, il me semble intéressant de marquer un petit temps d’arrêt pour vous expliquer ce qu’est une “fonctionnalité”.
J’ai dû employer le mot une petite dizaine de fois depuis le début de ce cours, sans entrer dans le détail.
Une fonctionnalité est une capacité spécifique offerte par un système pour répondre à un besoin identifié. Elle peut être vue comme une action ou un comportement qui fournit une certaine valeur ou un certain bénéfice à l’utilisateur.
Cette fonctionnalité peut être spécifiée en termes d’actions (les utilisateurs peuvent ajouter des produits à leur liste de souhait, les supprimer, etc.). Notre exemple est simple, en règle générale les fonctionnalités sont bien plus précises, mais dans notre cas, c’était pour que vous puissiez en saisir l’idée.
Identifiez chaque exigence
Assurez-vous de la bonne expression de l’exigence
La première étape consiste à identifier chaque exigence, et à s’assurer qu’elle est clairement exprimée. Les exigences doivent être décrites en termes de fonctionnalités concrètes que le système doit être capable de réaliser, plutôt que sous forme de solutions techniques.
Demandez-vous de quel type est cette exigence. Fonctionnelle ou non fonctionnelle ?
Déterminez la pertinence de chaque exigence
Assurez-vous également que chaque exigence est pertinente pour le projet !
Si une exigence n’a pas de lien direct avec le produit final, ou ne contribue pas à la satisfaction des besoins de l’utilisateur final, elle peut être considérée comme inutile, et donc éliminée, sous validation du product owner, bien entendu.
Distinguez les mises à jour des ajouts de fonctionnalités
Lors de cette phase, remarquez si l’exigence que vous êtes en train de lire est une évolution (une mise à jour) d’une fonctionnalité déjà existante, ou si c’est un nouveau besoin qui va être introduit.
En règle générale, il vous sera indiqué dans les spécifications si vous êtes dans un cas ou dans l’autre.
Toutefois, si cela n’est pas explicitement précisé, vous pouvez soit :
demander au product owner ;
comparer avec les spécifications des versions précédentes de l’application.
Ces remarques vont être importantes pour la suite des événements, quand vous viendrez identifier les impacts de ces exigences sur le produit et sur le patrimoine de test.
Un instant, c’est quoi un patrimoine de test ?
Vous pouvez voir ça comme une bibliothèque, mais à la place des livres vous aurez des cas de test et scénarios, qui auront déjà été rédigés pour des campagnes de test précédentes. Cela comprend les tests manuels et automatisés.
Vous y trouverez aussi les jeux de données et les environnements.
Rappel : Questionnez-vous, critiquez tout !
Prendre pour acquis ce que vous lisez est sûrement L’ERREUR numéro 1. Ne vous inquiétez pas, vous la ferez, je l’ai faite et c’est normal ! Même si nous sommes des êtres de presque perfection, le testeur logiciel peut commettre des bévues, mais elles peuvent malgré tout nous rapprocher de notre objectif.
Cet exercice peut sembler aisé, mais il doit être abordé avec la plus grande attention. Voyez ce qui m’est arrivé récemment :
Nous avons eu un nouvel arrivant dans le projet. Cette personne, très compétente dans son domaine, était chargée de l’écriture des spécifications.
Il lui a été confié l’évolution qui consistait à changer les images du site web, dont celle de la page d’accueil.
Dans son analyse, il n’avait pas identifié que l’image qu’il avait demandée aux développeurs d'ajouter était beaucoup trop grande par rapport à ce qui était prévu.
Je sens le vent venir, je lève la main en soulevant la question “Êtes-vous sûr que l’image a la bonne dimension ?” “Oui, pas de souci là-dessus”.
Soit... Je continue, arrive au moment de l’exécution, dans le mille, l’image était partiellement visible, toute l’ergonomie du site était impactée, retour à la case développement.
Tout ça pour vous expliquer que prendre pour argent comptant tout ce que vous lisez, ou ce qu’on peut vous dire, sans le remettre en question, et ce même si deux, trois, quatre personnes sont déjà passées dessus, ne vous mettra pas à l’abri d’une erreur dans les analyses.
Pour cela, pensez QQOQCP !
Voici des exemples de questions correspondant à chaque lettre :
Qui : Qui est impliqué dans le sujet ? Qui doit déclencher la fonctionnalité ?
Quoi : De quoi s’agit-il ? Quels sont les faits, les événements ou les processus liés au sujet ?
Où : Où se déroule le sujet ? Où se situe-t-il dans le système ?
Quand : Quand se déroule le sujet ? Quand la fonctionnalité est-elle déclenchée ?
Comment : Comment l’évolution apportée par cette exigence doit-elle se comporter dans le système ?
Pourquoi : Pourquoi cette évolution est-elle nécessaire ? Qu'apporte-t-elle de plus au système ?
En appliquant cette méthode, vous vous assurez d’avoir identifié les tenants et aboutissants des exigences.
Maintenant que toutes les exigences ont été identifiées et clarifiées, passons à la prochaine étape de l’analyse des exigences.
Définissez les impacts
Nous avons identifié les exigences du projet sous différents angles. Voyons à présent les impacts qu’elles vont avoir sur le système.
Alors déjà, qu’est-ce qu’un impact ?
Un impact peut être défini comme un changement ou une conséquence que l’exigence aura sur une ou plusieurs fonctionnalités du logiciel. Cela peut inclure des modifications du code, des changements dans le flux de travail de l'utilisateur final, des améliorations de la performance, ou des exigences supplémentaires en matière de sécurité ou d’implémentation.
C’est là où l’analyse des exigences que l’on a vue dans la partie Identification de ce chapitre va nous être utile !
Comme vous détenez les conséquences techniques et fonctionnelles des évolutions du projet, posez-vous, et encore une fois, prenez de la hauteur.
Il s’agit désormais de comprendre la portée de l’exigence ; est-ce qu’elle se limite à ce qui est écrit ?
Au départ, vous trouverez certainement ce travail laborieux, mais c’est ce qui fera la différence dans la qualité du travail que vous livrerez.
Je me souviens d’une fois où, sur une évolution dans un formulaire de souscription, il avait été demandé d’augmenter la taille maximale du champ “nom” que les banquiers devaient renseigner dans des formulaires du logiciel.
Jusque-là, vous allez me dire “Rien de bien fou”... C’est ce que je me suis dit aussi : “Allez hop, en 5 min c’est testé et je passe à autre chose”...
Sauf que… cette valeur était récupérée ensuite par le système pour générer le courrier qui était envoyé au client.
Innocemment, je lance les traitements et, grosse erreur, les maquettes des courriers n’étaient pas prêtes. 1 jour d’indisponibilité d’environnement pour le remettre en état, 4 projets, dont le mien, impactés…
J’entends vos pensées qui disent “Oh ça va, 1 journée”, mais c’était 1 journée sur 4 projets différents. Ce qui représentait une petite dizaine de personnes. Donc un peu moins de 10 jours de production perdue, car j’étais passé trop rapidement sur les impacts que pourrait avoir cette simple augmentation de quelques caractères.
Donc, posez-vous, prenez un peu plus de temps pour analyser les impacts que peut avoir une évolution, c’est autant de temps de gagné lors de la phase d’exécution.
Mettez en concurrence les exigences
Soyez un chef d’orchestre organisé, ne mélangez pas les violons avec les tubas !
C’est quoi le rapport ? Il faut m’éclairer, là !
Je m’explique : la mise en concurrence est une technique d’analyse des spécifications. Qui consiste à :
identifier les exigences qui pourraient entrer en conflit ;
identifier les exigences qui pourraient avoir des effets de bord négatifs lorsqu’elles sont implémentées ensemble.
Cela peut aider à déterminer quelle exigence est la plus importante, et à résoudre les éventuels conflits entre elles.
Je vais vous raconter encore une anecdote ; je suis toujours sur mes tests d’envoi de courrier bancaire (hélas, oui…) :
Pour une nouvelle version du produit, il a été demandé d’éditer et d’envoyer un nouveau courrier aux clients sous certaines conditions. Une d’entre elles était que ces clients devaient détenir un certain type de livret, qui était propre aux départements et territoires d’outre-mer.
Sauf que, dans un souci d’économie, la MOA (maître d’ouvrage) a émis une nouvelle exigence, et ce peu de temps avant le début de ma recette. Cette exigence spécifiait que TOUS les courriers à éditer et à envoyer devaient concerner les clients qui résidaient sur le territoire métropolitain (vous la voyez venir, l’incohérence ?).
Évidemment, le type de livret n'était détenu que par des personnes résidant dans les DOM-TOM (à l’époque), donc on n’enverrait jamais ce courrier.
Donc encore une fois, c’est un cas “simple”, qui aurait pu largement être anticipé, mais comme le dernier besoin est arrivé tardivement, j’ai été vite dans mon analyse, et nous nous en sommes rendus compte durant l’exécution.
Pour éviter ce genre de piège, voici quelques conseils :
Identifier les exigences concurrentes : identifiez les exigences qui sont en concurrence les unes avec les autres. Cela peut se produire lorsque deux exigences différentes affectent la même fonctionnalité, ou lorsqu'elles ont des objectifs contradictoires.
Analyser les exigences : pour chaque exigence concurrente, analysez ses objectifs, ses impacts sur le produit et ses risques potentiels.
Prioriser les exigences : une fois que vous avez analysé les exigences concurrentes, déterminez leur priorité. Vous pouvez utiliser des critères tels que l'importance pour l'utilisateur final, l'impact sur la qualité, ou l'urgence, pour déterminer quelle exigence doit être traitée en premier.
Collaborer avec l'équipe de développement : collaborez étroitement avec l'équipe de développement pour comprendre les implications de chaque exigence concurrente, et pour déterminer la meilleure approche pour les résoudre.
Documenter les résultats : documentez les résultats de l'analyse et de la résolution des exigences concurrentes. Utilisez ces informations pour mettre à jour les plans de test, les cas de test et les scénarios de test.
En suivant ces étapes, vous pourrez mettre en concurrence des exigences de manière efficace, et vous assurer que les objectifs du produit sont atteints, tout en évitant les impacts négatifs sur d'autres fonctionnalités ou sur la qualité globale du produit.
À vous de jouer !
Contexte
Votre première lecture des spécifications est terminée. Vous avez apprivoisé les enjeux et finalités du projet.
Andy et vous échangez sur la manière de procéder pour analyser plus spécifiquement ces exigences.
Vous convenez de les répertorier et de les classifier selon différents critères afin de pouvoir mieux les identifier.
Consignes
En reprenant les spécifications, vous analysez toutes les exigences décrites.
Votre mission est de regrouper par fonctionnalité les différentes exigences :
par typologie (IHM, back-office, microservice, etc.) ;
identifier la criticité de chaque exigence ;
relier les exigences aux fonctionnalités (une exigence peut être liée à plusieurs fonctionnalités).
En résumé
Identifiez chaque exigence en définissant si elle est fonctionnelle ou non fonctionnelle, et si elle est clairement exprimée.
Retenez la méthode du QQOQCP pour vos analyses d’exigences.
Un impact est un changement ou une influence que l’exigence aura sur une ou plusieurs fonctionnalités du logiciel.
Mettez en concurrence les exigences du produit entre elles : des incompatibilités peuvent survenir et plus tôt vous les remarquerez, plus vous gagnerez de temps.
Collaborez avec les équipes qui vous entourent : si vous vous posez des questions sur une exigence, il est très probable que quelqu’un avant vous se les soit posées.
À ce stade, vous avez plein de questions sur le contenu des exigences, ne restez pas sur votre faim, on va passer à la rédaction du document de revue d’exigences.
