Envie de frissons ? Découvrez les situations et scénarios de test qui vous donneront des sueurs froides : les pires cauchemars des testeurs.
Si vous l’êtes déjà cela vous rappellera sûrement de mauvais souvenirs et si vous ne l’êtes pas encore, n’ayez crainte on vous donne ici toutes les astuces pour conjurer le mauvais sort.
Tester sans stratégie de test / sans project test plan
Une stratégie de test et un/des project test plans sont un pré-requis pour le testeur. C’est le test manager qui est chargé de rédiger ce document.
L’objectif est d’expliquer : On va jouer au test ? Voilà les règles du jeu :
- Pourquoi on teste
- Qu’est-ce qu’on teste (et qu’est-ce qu’on ne teste pas)
- Qui va tester: qui va être informé, consulté, être responsable (= celui qui fait l’action) et être garant pour les différentes activités de test
- Quand tester
- Comment on teste: avec quels outils, quelles ressources, quels organes de gouvernance (= les diverses réunions), quels KPI utiliser dans nos reportings
Sans ce document, on va gérer les événements du projet sans les avoir anticipés, au risque de mal coordonner nos actions.
Ce document permet aussi de mettre noir sur blanc les pratiques qui seront adoptées sur le projet, et donc d’engager les différents validateurs du document.
En fonction du cycle de vie de développement du projet, y compris en Agile, ce document est primordial pour accélérer les actions des différentes parties prenantes.
Sans ce type de document de cadrage, tout comme dans un jeu de société, il y aura de mauvaises stratégies de jeu, des incompréhensions, et parfois (souvent ?) de la triche…
Des exigences approximatives
Lors de l’analyse de test, le testeur doit lire les cahiers des charges/spécifications, afin de créer un référentiel de tests.
Comment rédiger des scénarios de test si, à la lecture de ces documents, on ne sait pas quel est le comportement attendu du produit ?
Des solutions sont possibles, et dépendent du type de projet sur lequel on intervient:
Par exemple, on peut créer des anomalies documentaires lors de la revue des documents. C’est une pratique souvent oubliée sur les projets, mais elle permet d’avoir une documentation propre, ce qui sera, par la suite, un atout pour la maintenabilité du produit.
Si le cycle de vie du projet est trop rapide pour pratiquer des revues, une des solutions possibles est de créer des chartes de test en vue de mener des tests exploratoires, dans lesquels des utilisateurs clés découvriront le produit sous test, et écriront dans les même temps les cas de test qu’ils auront exécutés.
Une des mauvaises pratiques est d’aller voir les développeurs pour savoir ce qu’ils ont compris des spécifications : dans ce cas, le testeur n’est pas impartial quant à la qualité du code.
Un outil de test management inadapté
Qu’il soit non disponible, mal paramétré ou tout simplement pas adapté à ce que l’on souhaite, on va chercher des solutions qui ne seront pas pérennes pour qu’il réponde à notre besoin. Pourquoi tordre le cou à un outil lorsqu’on peut en fabriquer un nouveau ?
Et sans outil de test management, nous ne pouvons pas tracer ce qui a été testé/ce qui n’a pas été testé. Sans outil de test management, nos tests sont des tests simiesques (monkey tests) et nous ne pouvons pas donner de la confiance dans la qualité du système sous test.
Un bon outil de test management nous permet aussi de reporter facilement les bonnes données au management. Sans un outil adéquat, nous risquons de perdre un temps précieux, mais aussi peut-être notre crédibilité.
Des livraisons sans release note
Comment implémenter nos tests (c’est-à-dire définir ce que l’on va tester sur une livraison donnée), si les développeurs ne nous indiquent pas ce qui a été modifié ? Il conviendrait de TOUT tester/retester au risque de perdre un temps précieux ?
Des livraisons sans prévenir
Voilà un des cauchemars qui sent le vécu : des développeurs qui installent une version sans prévenir les testeurs. En tant que testeur, je trouve une anomalie, et quand j’essaie de la reproduire, elle a disparu… De quoi en perdre la tête !
Laisser passer des anomalies
Pourquoi dépenser du temps et de l’argent dans les tests ? C’est bien sûr pour gagner de la confiance dans la qualité du produit. Si on a testé une fonctionnalité, le risque d’un bug sur celle-ci va tendre vers 0.
Lorsqu’on ne détecte pas une anomalie, et qu’elle passe en production, il y a un risque financier/perte d’image de marque/risque de mort ou risque sociétal sur certains produits sous test. On l’a vu il y a quelques années à Fukushima: Les testeurs ont fait l’impasse sur les tests aux limites (tremblement de terre + tsunami), et cela a généré ce que l’on connaît.
Les tests non fonctionnels
Selon la norme ISO25010, les tests non fonctionnels sont :
- les tests de performance (temps de réponse, utilisation de ressource…),
- les tests de compatibilité (ex: est-ce que mon site internet fonctionnera sous Opera? Est-ce que mon application fonctionnera sous iOS15?),
- les tests d’utilisabilité (ergonomie, accessibilité…),
- les tests de fiabilité (robustesse, récupérabilité, disponibilité…),
- les tests de sécurité (confidentialité, intégrité, authenticité…),
- les test de maintenabilité (est-ce que mon code est assez commenté pour que je puisse le faire évoluer plus tard?),
- les tests de portabilité (tests multi-devices)
Ce sont des tests pour lesquels nous avons rarement des exigences. Pourtant, c’est au testeur de les prévoir, et c’est son rôle de les documenter/faire documenter.
Les tests mobiles / multi devices
Aujourd’hui, il existe des milliers de devices différents. Les constructeurs majeurs sortent de nouveaux appareils de plus en plus fréquemment.
Outre les “vieux devices” sur lesquels un support est souvent demandé, il faut s’assurer de la portabilité des logiciels aussi sur les nouveaux devices.
D’abord, il est impossible d’avoir à sa disposition tous les devices existants. Cela représenterait plusieurs milliers d’appareils. Ensuite, il faudrait exécuter les mêmes tests sur tous les devices ?
Imaginons ensuite que sur un mobile donné, nos utilisateurs naviguent avec plusieurs navigateurs différents…
Rappelons alors un des principes fondamentaux du test: le test exhaustif est impossible 🙂
Les tests de non régression
Nous y venons enfin ! Votre mission, si vous l’acceptez: vous devez tester cent fois la même chose, et rester toujours attentif. Dans ce cas, posons, bien entendu, l’hypothèse que nous ne pouvons pas programmer de robot qui testerait pour nous.
Il existe des testeurs qui aiment les tests de non régression, mais ce sont des perles rares. Si vous en connaissez, prenez-en soin !
Les reportings
Nous sommes sur un projet de test, et mes supérieurs me demandent un reporting.
Les indicateurs que j’utilise ne seront jamais parfaits au vu de la situation du projet. Il faut alors redoubler d’ingéniosité, et très souvent tâtonner, pour trouver LE bon indicateur qui sera utile au management.
C’est aussi un moment de la semaine (de la journée?), souvent rébarbatif, où on manipule des données, des chiffres, et où nos compétences de testeur sont souvent mises de côté.
Les patchs de prod
On l’a vu plus haut, un des pires cauchemars du testeur, c’est de laisser passer un bug.
Mais il arrive aussi que des utilisateurs demandent une nouvelle fonctionnalité, tout de suite, en production. Dans ces cas-là, les tests ne sont pas possibles dans les délais impartis. Alors, il ne reste plus qu’à croiser les doigts et fermer les yeux, en espérant que tout se passe bien.
Les attentes irréalistes du management sur l'automatisation
“J’ai une idée: on va paramétrer un robot qui va tester à la place des testeurs, et ça va nous faire économiser plein de temps et d’argent!”
OK, très bonne idée, mais rappelons que :
– Il faut un automaticien pour automatiser
– Il faut un automaticien pour maintenir les scripts d’automatisation, tout au long du projet et de la vie du produit
– Il faut mettre à jour régulièrement les tests automatisés pour éviter le paradoxe du pesticide (et donc nécessité d’un automaticien)
– Il faut des testeurs pour vérifier/reproduire/analyser les anomalies détectées par le robot
– Même avec une automatisation totale des cas de test, les testeurs manuels sont toujours nécessaires
– Le test automatisé n’est pas tout le temps possible
– Avant d’automatiser, il est primordial de calculer un ROI
