Tous les articles
Marc Hage Chahine: Passionné Test Logiciel – Interview #1
Bonjour, qui êtes-vous, quel est votre métier et quelles sont vos activités professionnelles ? Je suis Marc Hage Chahine et travaille dans le test logiciel depuis fin 2011. J’ai pu au cours de mes 5 premières années travailler sur de nombreux projets, rencontrer de nombreux experts du test ce qui me permet depuis 1 an de faire des missions d’expertises, de commencer à animer des conférences et de multiplier mes connaissances. Pouvez-vous décrire simplement votre métier ? Le test c’est avant tout un travail de communication et un travail d’équipe. Je travaille au sein d’une équipe projet afin de leur donner de la
Que faire lorsque l’équipe de test est un goulot d’étranglement?
Il arrive souvent que l’on dise dans les entreprises que les tests sont la cause du retard des projets. Je ne suis évidemment pas d’accord avec cela plus plusieurs raisons (détaillées dans différents articles), néanmoins il arrive que sur certains projets, le nombre de testeurs soit insuffisant par rapport au nombre de développeurs et aux tâches qui lui sont assignées. Par exemple : Le temps nécessaires au testeur représente 50% du temps de développement, par contre il n’y a que 1 testeur pour 5 développeurs… le test devient donc, avec une vision totalement objective, un goulot d’étranglement. Comment faire pour régler ce
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