Conception du plan de test

C'est le document détaillant tous les cas de tests à réaliser et leurs résultats. Ces cas de test seront utiles pour les livrables mais aussi pour les futures versions de l’application. Ils comprennent les pré-requis à respecter, le scénario, le résultat attendu et l'état final du test : passé ou non. Il s’enrichira des nouveaux cas de test issus des nouvelles fonctionnalités ajoutées au produit.

› Livrables : plan de test, liste de chaque cas de test détaillé, rapport.

Exécution du plan de tests

C’est le passage des cas de tests. Il donne lieu à un rapport de passage des tests, qui renseigne sur la qualité du produit, et sera comparé aux prochaines exécutions. Il en découlera la création de tickets dans les outils de bug-tracking.

› Livrables : cas de test complétés, rapport sur les temps passés, rapport sur les statuts, rapport détaillé sur les tickets, compte-rendu du testeur sur les résultats obtenus (et éventuellement les améliorations proposées par le testeur).

Tests exploratoires

L’objectif de cette phase est d’avoir une approche objective de l’application en l’utilisant comme le ferait un client lambda. On pourra ainsi tester l’application dans son environnement cible et détecter des dysfonctionnements, évaluer son ergonomie et ses performances.

› Livrables : reporting sur les temps passés par le testeur, rapport sur les statuts des tickets, liste des tickets des bugs identifiés, compte-rendu sur les résultats obtenus et propositions d'amélioration.

Automatisation des tests

Il s’agit, par le biais d’un développement logiciel, d’utiliser une base de données de jeu d’essai que l’ont saisit de façon automatique dans les écrans d’une application.

Le challenge de la mise en place de tests automatisés concerne surtout le choix des zones à couvrir et le bon compromis entre investissement de départ et temps d'exécution des tests. Car toutes les parties d'un logiciel ne sont pas automatisables et, de plus, le coût de la maintenance des tests automatises peut s'avérer supérieur au temps passé à les mener manuellement.

› Livrables : application développée pour l’automatisation des tests (scripts), listes des tickets de bugs identifiés durant la mission, reporting sur les temps passés, compte-rendu du testeur sur les résultats des tests automatique.

Tests de non-régression

L’objectif de cette étape est de dérouler le plan de test dans une nouvelle version du logiciel et de revérifier les tickets (bugs) traités et validés lors d’une livraison précédente. On vérifie ainsi que la nouvelle version ne fait pas apparaître des bugs là ou il n’y en avait pas dans la précédente. Ces tests sont adaptés dans le cas d'un logiciel destiné à suivre une road-map de plusieurs versions.

› Livrables : base des tests complétés, reporting sur les temps passés, liste des tickets de bugs ajoutés et rapport sur tous les tickets, compte-rendu du testeur sur les améliorations possibles.

Test de l'Aide

La documentation est un outil indispensable aux utilisateurs qui souvent sera mis à profit par l’éditeur pour former ses clients mais aussi éviter des appels vers ses hotliners. Il est alors important de vérifier qu’elle est bien conforme aux fonctionnalités du logiciel et toujours conforme aux nouvelles versions. Le regard d’un ingénieur non spécialisé dans le métier du client et ne connaissant pas le logiciel est souvent un atout pour avoir une vision objective de l’aide d’un logiciel.

› Livrables : reporting sur les temps passés, liste des tickets de bugs ajouté et et rapport sur les tickets (catég, statut…), compte-rendu sur les améliorations possibles.

« Les étapes de notre démarche qualité

Tests unitaires :