Dix mille villes — L’objectivation et la documentation des tests

Ou bien si ?

J'ai souvent vu des équipes QA entreprendre consciencieusement et avec diligence la tâche héroïque de documenter complètement leurs tests. Pour une version. Puis cette documentation finit par être oubliée. Prend la poussière numérique quelque part sur un réseau. Et ce n'est pas parce que l'équipe QA ne croit plus en son importance. Elle est simplement épuisée par l'effort nécessaire pour la mettre à jour lors de la prochaine version majeure. 

Parce que, dans leur zèle, l'équipe QA a rédigé des descriptions de test incroyablement détaillées, décomposant les choses à un niveau maniaque et microscopique de spécificité extrême. Créant une documentation de test séparée pour chaque facette ou attribut d'une fonctionnalité ou d'une interaction utilisateur. Générant des dizaines de descriptions et tâches de test individuelles pour ce qui n’est fondamentalement qu’une seule tâche de test. C’est comme la personne juste devant vous à la caisse qui insiste pour payer 80 $ de courses en petite monnaie.

Le résultat de ce zèle poussé à l’extrême est la production de centaines, parfois de milliers de descriptions de test pour la publication en question. La QA a, sans s'en rendre compte, rédigé un roman à la Dickens. Le Conte de Dix Mille Villes. En avez-vous déjà lu un ? Moi non plus.

La conséquence, c’est que personne n’a le temps ni la patience de mettre à jour ces milliers de descriptions de test individuelles. Car la priorité sera toujours de tester la prochaine itération du logiciel, puisque c’est cela qui génère des revenus alors que la mise à jour de la documentation de test n’en rapporte pas. 

Mais aussi parce que les applications de documentation de test ne facilitent pas du tout la réalisation de mises à jour massives des enregistrements de documentation. Faire des modifications globales sur des classes de tests peut être fastidieux et peu intuitif dans la plupart des logiciels (c'est aussi vrai pour de nombreux outils de suivi des défauts — même aujourd’hui). Ce qui ajoute au coût en temps et en santé mentale de l’opération.

Le résultat, c’est que toute cette documentation de test méticuleuse finit par être abandonnée. Et tout le temps consacré à la créer est, en fin de compte, gaspillé. Car elle n’est pas réutilisable. C’est un feu de paille. C’est le « I Melt With You » du test logiciel. Pourtant, la documentation de test est absolument nécessaire à une démarche de test systématique et reproductible. D’où le dilemme.

Il existe un moyen de sortir de ce dilemme. Et, aussi douloureux que cela puisse être à admettre, il nous faut chercher la solution dans l’ingénierie. Ou du moins y puiser l’inspiration. Les ingénieurs ont rencontré un problème similaire dans les premières années du développement logiciel commercial. En raison des limitations des langages de programmation de l'époque, ils devaient réécrire le code pour les mêmes attributs, actions et sécurités de base, fonction après fonction. Encore et encore. La gestion de la mémoire et le ramasse-miettes étaient de bons (et dangereux) exemples de ce problème.

En conséquence, les ingénieurs produisaient d’énormes quantités de code redondant et perdaient un temps précieux (Pas que cela dérange toujours les ingénieurs : Ebay existe toujours pour une raison.). Puis quelqu’un, plein de bon sens, a inventé la programmation orientée objet, dans laquelle on peut créer des objets de code héritant par nature d’attributs par défaut. Le même code ne devait plus être réécrit (ou copié-collé) à chaque fois. Ce qui signifiait que la qualité ne dépendait plus de la mémoire d’un ingénieur ni de sa rapidité de frappe. Ce dont la QA lui sera toujours reconnaissante.

C’est une vision très utile pour la QA qui se débat avec l'impasse de la documentation de test. Le concept d’orientation objet tel qu’il existe en ingénierie ne peut pas être appliqué directement à ce problème, mais en tant que métaphore, il est très riche. L’ingéniosité, par définition, s’adapte facilement à de nouvelles situations.

J’ai souvent, dans ma carrière, été confronté à la question de comment créer une documentation de test à la fois complète et concise, exploitable sur l’instant mais aussi aisément réutilisable pour les versions futures. Et la solution que j’ai finalement retenue consiste à appliquer l’idée d’un « objet » à la documentation de test elle-même. 

Je parle ici de bien plus qu’un simple modèle de documentation de test. Ces modèles sont très utiles comme outil de standardisation, bien sûr, mais ils n’apportent rien face à ce problème précis. J’ai élaboré l’idée que les tests pouvaient être documentés de manière à inclure, dans un seul document, tous leurs différents modes, points d’inflexion, flux de travail et conditions particulières. Une fois cette ampoule allumée dans mon cerveau un peu obscur, la réponse m’a paru soudain très simple. Et tout à fait réalisable.

Entrons dans le détail.

Prendre la pilule rouge

La solution consiste à voir chaque test individuel, et donc aussi son artefact de documentation, non pas comme l’affirmation/la description d’un test contre un point de donnée unique ou une condition isolée. Mais plutôt comme une description de toute la matrice (vous voyez le clin d’œil ?) des conditions dans lesquelles la fonctionnalité ou la capacité doit être validée. 

Cela implique une approche holistique de la définition des tests individuels. Une tâche de test cohérente et unique ne peut être fragmentée utilement en dizaines de « tests » indépendants sans, paradoxalement, effacer la spécificité dans l’évaluation de la fonctionnalité dans son ensemble. C'est un cas où l'on ne voit plus la forêt à force de regarder les arbres.

Ici, il est utile de revenir sur le concept de contexte de test. Car pour mettre en œuvre l’idée d’un objet de test de manière efficace, vous devez d'abord être capable de distinguer le noyau inchangeable d’une fonctionnalité de ses contextes secondaires d’application et de fonctionnement. C’est une question que la documentation de test de style atomique élude, si bien que les testeurs n’apprennent jamais à réaliser cette analyse de manière systématique et consciente. Encore un autre inconvénient du modèle atomique.

Pour faire simple, les contextes de test pour une fonctionnalité ou un système sont l’ensemble des conditions, environnements, flux de travail ou états qui peuvent varier indépendamment les uns des autres à l’intérieur des limites de la fonctionnalité elle-même. Les systèmes d’exploitation et leurs versions en sont un exemple flagrant. Les langues étrangères en sont un autre. Les états du système en sont encore un (par exemple, pour un serveur web, cache mémoire activé ou désactivé). Une fois cette distinction comprise, vous trouverez facilement de nombreux autres contextes pertinents selon le type de produits que vous testez.

Une fois cette analyse réalisée (qui devrait de toute façon être la base de toute planification de test professionnelle), vous aurez alors la possibilité de créer des formats de documentation de test compacts qui intègrent cette distinction. Dans le système que je décris, un seul artefact de documentation de test se composera de :

1. Une description de la fonctionnalité ou capacité principale visée par le test.
2. Une liste de tous les contextes dans lesquels la fonctionnalité principale doit être validée.
3. Tout ce que vous auriez de toute façon inclus (préconditions pour la validité du test, ressources et droits nécessaires pour exécuter le test, lien vers les exigences produit concernées, etc.). Rien de tout cela n’est remplacé par ce que je propose.

À ce stade, vous pensez peut-être : « Mais ça risque de faire beaucoup de contextes ! ». C’est vrai. Mais voyez plutôt les choses ainsi. Procéder de cette façon ne vous créera pas plus de travail, cela vous en retire même. Rédiger des plans de test complets devient plus simple grâce à notre liste sélectionnée d’outils de documentation pour les tests logiciels. Cette méthode va en effet réduire considérablement le nombre de tests individuels à créer et à entretenir (ou à refuser de le faire) dans le futur. Alors que dans un système atomique, vous auriez un artefact de documentation par cas, menant à l’impasse décrite en début d’article.

Cette méthode de documentation des tests a cependant certaines conséquences procédurales qui, de prime abord, paraissent inconfortables ou perturbantes. Pas seulement pour la QA, mais aussi pour les autres parties prenantes du projet. Pourtant, si chacun prend le temps d’en comprendre les fondements, il verra que ces conséquences sont en réalité des améliorations. Pour tout le monde.

La principale, c’est que, en regroupant la matrice des contextes de fonctionnalité dans le test principal, cela signifie, logiquement, que si ce test unique échoue dans l’un de ces contextes, alors l’ensemble du test est considéré comme un échec. Même si ce n’est que dans un seul contexte. Je comprends que cela puisse semer la panique dans les rangs de l’ingénierie. Car il peut sembler que vous leur mettez des bâtons dans les roues, en élevant la barre à un niveau impossible pour qu’un test puisse être considéré comme « passé ». Mais ce genre de crainte peut se corriger facilement. Soulignez-leur deux éléments, et un troisième à garder pour vous :

1. Cette méthode diminuera le nombre de bugs détectés sur leur travail lors du test. Car, selon la méthode atomique, l’échec dans chaque contexte aurait généré un bug distinct. Ce qui aurait, au final, gonflé le nombre total de bugs rapportés pour une même fonctionnalité. Ce qui devrait faire sourire les ingénieurs. Et les chefs de projet.
2. Ensuite, utiliser cette méthodologie de test fournit automatiquement le contexte sur la portée réelle de la défaillance fonctionnelle. Car quelle est la première question que l’ingénieur chargé de corriger le bug vous posera systématiquement ? « Euh, est-ce que ça arrive partout, ou seulement dans le contexte X ? » Et au lieu de devoir retourner précipitamment à votre poste pour relancer le test dans le contexte X (car vous l’aviez peut-être oublié lors du test initial ?), vous aurez déjà la réponse. L’ingénieur sera ainsi privé d’une excuse pour éviter de travailler sur le bug (ce que la QA offre en moins de bugs, elle le reprend ensuite).
3. Enfin, l’analyse des contextes pour la documentation de test vous garantit d’avoir bien réfléchi à tous les contextes pertinents lors de la rédaction initiale du test. Ce qui veut dire que vous serez moins susceptible de vivre ces moments de panique – trois jours avant, ou pire, après la mise en production – où vous réalisez que vous avez oublié de tester dans un contexte important. Une QA basée sur la panique n’est jamais très efficace. Ni très agréable psychologiquement.

Dans la machine

Cette méthode de documentation des tests, inspirée de l’objet, réduira drastiquement la quantité d’artefacts de documentation que vous aurez à produire ; vous serez donc bien plus en mesure (et enclin) à les mettre à jour continuellement pour les versions futures.

Le seul bémol à cette approche, c’est que peu d’applications de documentation de tests sont conçues pour documenter les tests de cette façon de manière native. Elles adhèrent généralement au modèle atomique, qui est malheureusement la norme, et ne disposent donc pas de fonctionnalités intégrées pour accueillir facilement le modèle objet que j’ai décrit ici. 

C'est pourquoi, bien souvent, j'ai eu recours à des solutions applicatives beaucoup moins élaborées — comme Excel — qui, en réalité, s'avèrent pour cet usage bien plus flexibles et faciles à personnaliser, parce qu'elles sont généralistes. L'inconvénient de cette stratégie, c'est que les intégrer à Jira et consorts devient laborieux. Mais après tout, peut-être surestime-t-on l'importance de l'intégration.

Quoi qu'il en soit, le fait que de nombreuses applications de gestion des tests et de suivi des défauts rendent diaboliquement difficile la mise à jour en masse de fiches individuelles demeure. Quels que soient les protocoles choisis pour les créer. Mais c'est valable quel que soit votre mode de rédaction de la documentation de test. Un problème à la fois, s'il vous plaît.

Je m'excuse d'avance (ou dans votre cas, avec le recul) de ne pas vous fournir de modèle d'objet de test. Selon mon expérience, fournir des modèles est généralement une mauvaise idée car les gens se contentent d'utiliser votre modèle. La disponibilité de modèles génériques et prêts à l'emploi tend à empêcher et à court-circuiter la créativité de l'équipe elle-même dans l'élaboration d'un modèle vraiment adapté à ses besoins, processus et outils sur le terrain. Pas de rancune donc.

Je reste toujours ouvert à vos questions et suggestions. Il suffit de les publier ou de m'envoyer un message sur LinkedIn.

Et, comme toujours, bonne chance.