Kaltoum MAISON

Tester un logiciel?

Que ce soit un logiciel grand public, comme par exemple un site web, ou un logiciel répondant à une demande spécifique, les enjeux des tests sont importants.
Nous avons tous à l'esprit certaines sociétés dont la production de logiciel n'a pas été à la hauteur de la demande de qualité de ses clients et dont l'image de marque en a grandement pâti.
Ce que nous ne voyons peut être pas assez, ce sont ces projets dont la démarche qualité est si pointilleuse qu'ils n'y survivent pas: des produits annoncés avec des retards trop importants, ou encore des gouffres financiers impossible à combler qui viennent les plomber.

Le juste milieu est l'étude préalable des risques et des enjeux : le fameux triangle coût / qualité /délais. L'étude préalable définit les besoins, et à partir de là, une priorité peut être donnée dans la qualité des développements futurs. Cela impacte la qualité demandée pour lesdites fonctionnalités, et donne une ligne directrice à la méthodologie des tests.
Une fois ce périmètre bien établit, les spécifications produit incontournables sont identifiées, et justifies un investissement dans la qualité, et les spécifications accessoires où la qualité sera peut être mieux gérée dans une livraison future, si le besoin se fait sentir.

Au sein d'une même fonctionnalité produit, par exemple "envoyer un email" (oups, courriel devrait on lire ;-), on définit des sous fonctionnalités. Dans notre exemple, cela sera "arrive bien à l'adresse demandée", ou encore "le titre de l'email apparaît en gras".
Pour chacune d'entre elle, des cas de tests peuvent être envisagées. De la même manière qu'il faut savoir quelle fonctionnalité produit a un impact important sur la satisfaction utilisateur final, on doit avoir à l'esprit la chaîne des sous fonctionnalités de priorité basses ou à l'opposé très haute. Dans notre exemple, ce que l'on doit tester et valider en premier est que l'email arrive bien à destination, et tant pis si d'aventure le titre n'est pas en gras comme on le voulait.
Une fin de projet arrive à grand pas, et les plans de tests ne sont pas tous déroulés comme prévu? Il suffit alors de gérer les tests à réaliser en fonction des risques identifiés: les priorité hautes en premier, et ainsi de suite jusqu'à l'expiration du délais.

Vous l'avez compris, le test de logiciel est quelque chose de logique. En gardant bien à l'esprit dès le départ ce que l'on veut comme qualité, le test peut être une plus-value. De la même manière une personne trop axée sur la qualité pure d'un logiciel peut être un frein dans un projet.