Tous les articles
L’expérience utilisateur… Une limite importante des tests systèmes !
La problématique : Le but des tests systèmes (voir Niveaux de test) est de vérifier que l’application correspond bien à ses spécifications (ou fonctionnalités à travers les US). Les tests sont alors écrits en fonctions de ces spécifications (ou US) et des scénarios qui leurs sont reliés. Cela implique donc une limite importante : Sur toute application, l’utilisateur est libre de faire le parcours qu’il souhaite, de faire certains enchainements d’actions qui n’ont ni été anticipés ni même envisagés. Il existe aussi des scénarios non testés car considérés comme cas des cas marginaux et non spécifiés. On peut donc se poser la question
Améliorer la productivité et l’efficacité des tests
Introduction La plupart du temps lorsque j’arrive sur un projet j’entends parler de problèmes avec les tests. Certaines phrases comme celles-ci-dessous sont récurrentes : · Les tests prennent trop de temps · Il y a trop de bugs en productions, les tests sont donc mal faits · Il faut automatiser pour tout améliorer et aller plus vite Je m’aperçois donc de l’existence de 2 problèmes décrits: · La lenteur des tests qui retarde la mise en production (ou Time To Market) · Le manque d’efficacité des tests Et d’un besoin exprimé (je dis bien exprimé, ce n’est pas forcément le besoin le plus urgent !) censé résoudre les 2
Les peurs du testeur
Le testeur, comme toute personne, a des appréhensions et est sujet à des peurs. En voici quelques-unes touchent de nombreux testeurs. Comme pour toutes les peurs il faut savoir les dominer et s’en servir pour s’améliorer. · Avoir un bug majeur/critique qui est passé à travers les tests avant la mise en production de l’application (ou d’une de ses versions). Explication : La peur lors d’une mise en production est commune à l’ensemble des membres du projet. Elle est cependant souvent plus importante chez les testeurs car lorsqu’il y a un bug la responsabilité retombe souvent sur les testeurs… Au moins du point
Retour sur un article qui parle du métier de testeur
On parle de plus en plus du métier du test, notamment à travers des articles publié sur le web. C’est très bien et je m’en réjouis. Donner de la visibilité à ce métier est très important. Néanmoins avec l’arrivée de ces articles écrits par des non testeurs, arrivent certaines imprécisions. Un contact m’a récemment envoyé un lien vers cet Article. Cet article est intéressant et on sent que son auteur a bien senti que le métier de testeur évolue et qu’il va continuer à grandir. C’est pourquoi je souhaite revenir sur certaines de ces imprécisions et de démonter certaine idées reçues.
Priorité vs criticité
Ces 2 concepts sont souvent confondus. Il existe néanmoins des différences importantes entre ces 2 notions. Lorsque l’on découvre un bug et que l’on créé ce dernier il existe généralement 2 champs qui sont les champs Criticité et Priorité. La criticité propose 3 ou 4 champs. J’utilise généralement mineur, majeur et critique. La priorité quant à elle propose généralement aussi 3 ou 4 champs. Prenons P1, P2, P3 par ordre de priorité. La criticité : Pour rappel, la criticité s’évalue grâce à un tableau semblable à celui ci-dessous (plus d’informations sur ce lien) : · Une criticité Mineure correspond à un bug peu gênant