Comment développer un plan d'assurance qualité

Assurance qualité: adore ou déteste, tu ne peux pas vivre sans. Derrière chaque site Web performant, de nombreux tests sont nécessaires pour en vérifier la qualité. Et chaque processus de test commence par un plan d'assurance qualité (ou également appelé plan de test).

Ce petit guide expliquera ce qu'est un plan d’assurance qualité, qui le crée, pourquoi il est important d’en avoir un et les étapes à suivre pour le créer.

Qu'est-ce qu'un plan d'assurance qualité?

Le plan d'assurance qualité (ou également appelé plan de test) est un document détaillé, qui comprend les composants suivants:

• La stratégie de test pour le site web
• Quels sont les objectifs de test?
• Quelles sont les ressources disponibles – main d’œuvre, outils logiciels et matériels?
• Quel sera le calendrier des tests?
• Quelle est l'estimation pour le test?
• Que doit-on livrer avant, pendant et après tout le processus de test?

Qui crée et maintient le plan de test?

Une fois le plan de test défini, il est temps de décider qui crée et conserve le document. La réponse est simple: le plan de test est créé par l'équipe d'assurance qualité qui participe directement au processus de test.

Pourquoi le plan de test est-il si important?

Avant de procéder à la création d’un plan de test, voyons pourquoi il est important d’en avoir un pour votre site Web.

• Il déterminera la quantité et le type de travail nécessaire pour valider la qualité de l'application testée.
• Il aide les personnes qui ne font pas partie de l'équipe d'assurance qualité (équipe de gestion, développeurs et même les clients) à comprendre l'objectif et l'approche du processus de test du site Web.
• Le plan de test ressemble à un livre de règles: il définit toutes les règles et procédures que l'équipe doit suivre pendant le processus de test.
• Enfin, le document contient des aspects importants tels que la stratégie de test, la portée du test et les estimations, qui peuvent être examinés par l'équipe de gestion et réutilisés dans des projets similaires à l'avenir. De cette manière, le plan de test prend en charge la création de processus stables et l’accumulation de savoir-faire.

Création de votre premier plan de test

Maintenant que nous avons fourni les réponses aux questions de base «Quoi», «Qui» et «Pourquoi», la prochaine étape consiste à apprendre à créer un plan de test. Il existe de nombreux modèles sur lesquels votre plan de test peut être basé.

Quelques exemples peuvent être trouvés ici. Le processus est décrit en huit étapes avec une explication fournie pour chacune d’elles. Par souci de commodité, lors de l'explication de chaque étape, le terme «projet» sera utilisé au lieu de «site Web», car le document est également applicable à différents types d'applications logicielles.

1. Analyse du produit

Celui-ci est basique: savoir quel est le produit. Commencez par vous familiariser avec la documentation du projet – Pourquoi, at-il été créé, qui l’utilisera, comment fonctionnera-t-il, comment sera-t-il présenté et dans quel environnement (matériel et logiciel) sera-t-il exécuté? Ce dernier point est très important lorsque vous testez la compatibilité sur différentes plates-formes – appareils, navigateurs Web, systèmes d’exploitation, etc.

2. Développer la stratégie de test

La stratégie de test est un document très important, développé par le gestionnaire de tests. Il définit les objectifs de test avec les efforts de test et les coûts pour l'ensemble du processus.

Il y a plusieurs choses à faire ici:

• Définir le périmètre de test – Vous devez décider lequel des composants testés de votre site Web sera “portée"Et lesquels -"hors de portée”. Les composants "in scope" comprendront tout ce qui sera testé sur le site Web, tandis que les éléments "hors champ" seront omis. Avoir une portée de test précise présente deux avantages:
  • Tout le monde saura avec précision quels tests seront effectués.
  • Tous les membres de l'équipe impliqués comprendront clairement ce qu'il faut tester et ce qui ne l'est pas.

Pour déterminer la portée d'un projet de test, prenez en compte les besoins du client, le budget du projet, les spécifications du produit et, surtout, les compétences et le talent de l'équipe de test.

• Identifier le type de test – En fonction du type de projet, le type de test approprié doit être sélectionné. Il existe une multitude de types de tests et il est impossible de les appliquer tous, en particulier lorsque le temps et l’argent sont des contraintes. L'idée est de sélectionner celles qui sont pertinentes pour le projet et ses caractéristiques spécifiques et d'établir des priorités.

Vous trouverez plus d'informations sur les différents types de tests ici.

• Documenter tous les risques et problèmes liés au projet – Cela pourrait inclure des éléments tels que des membres de l'équipe qui ne possèdent pas les compétences requises, des estimations incorrectes, des calendriers serrés. Essayez de prévoir tous les problèmes et risques potentiels et suggérez un plan d’action afin de les résoudre.
• Plan la logistique de test et qui effectuera les tests et quand cela sera fait.
  • Comment décider qui effectuera les tests? Dans l’idéal, la personne la plus compétente serait en mesure de comprendre le point de vue du client, d’atteindre la plus haute qualité possible, de porter une attention particulière aux détails et d’être un joueur d’équipe.

En fonction du budget, les tests peuvent être réalisés en interne (par les équipes internes d'assurance qualité) ou confiés à une agence spécialisée.

• Quand doit-on commencer le test? Les tests doivent commencer lorsque la spécification est prête, que toutes les ressources humaines sont disponibles et que l'environnement de test a été défini.

3. Définir les objectifs du test

En règle générale, l’objectif est de rechercher le plus grand nombre possible de défauts logiciels, de les corriger et de s’assurer que le site Web testé ne contient pas de bogues avant sa publication. Cependant, produire un produit 100% exempt de bogues est presque impossible, il est donc essentiel d'identifier et de corriger tous les bogues jugés critiques pour la fonctionnalité du produit, puis de recourir à des mises à jour et des correctifs post-lancement.

Afin de définir les objectifs du test, deux étapes doivent être effectuées:

• Énumérez toutes les fonctionnalités du site Web qui devront être testées.
• Sur la base de cette liste, définissez l'objectif général des tests.

4. Définir les critères de test

Les critères de test sont les directives sur lesquelles la procédure de test peut être basée. Il existe deux types de critères l:

• Critères de suspension – Lorsque ces critères sont remplis, les tests doivent être suspendus jusqu'à ce que l'équipe de développement puisse résoudre tous les problèmes qui pourraient entraîner le respect du critère. Une fois cela fait, les tests peuvent continuer. Par exemple, si le critère de suspension veut que 45% des cas de test échouent, lorsque le taux d'échec est atteint, les tests s'arrêtent et l'équipe de développement doit résoudre tous les problèmes des cas ayant échoué.
• Critère de sortie – Répondre à ce critère signifie que la phase de test a été complétée avec succès. Les critères de sortie incluent des résultats de tests ciblés et sont nécessaires avant de passer à la phase de développement suivante. Les critères de sortie les plus courants pour terminer ou terminer le processus de test sont les suivants:
  • Les délais sont respectés ou le budget est épuisé.
  • Tous les tests ont été exécutés (en règle générale, c’est obligatoire), sauf s’il existe une raison claire de ne pas couvrir à 100% les tests.
  • Tous les bogues critiques / de haute priorité ont été résolus.
  • Une couverture suffisante des exigences et des fonctionnalités du site Web a été fournie.
  • Atteindre le pourcentage ciblé de cas de test réussis ou le rapport entre les tests réussis et le nombre total de tests exécutés. Il s'agit d'une métrique qui calcule le pourcentage des cas de test précédents.

Le calcul se fait avec la formule suivante:

Pourcentage de tests ayant abouti = (Nombre de tests ayant abouti / Nombre total de tests ayant été exécutés) * 100

5. Planifier les ressources

Le plan de ressources est un résumé de tous les types de ressources (ressources humaines, équipements, matériaux, etc.) nécessaires au processus de test. Cette étape est très importante car elle aide à déterminer la quantité de ressources nécessaire pour les tests et aide ainsi à préparer le calendrier et les estimations corrects.

Voici comment couvrir les ressources recommandées pour un projet:

• Ressources humaines – Dressez la liste de tous les membres de l’équipe qui participeront au processus de test, ainsi que de leur rôle.
• Ressources système – Toutes les ressources non humaines nécessaires au test du projet: serveurs, outils de test, matériel informatique, réseaux, environnements de test, etc.

6. Planification des environnements de test

Un environnement de test comprend tous les composants (logiciels, matériel, configuration réseau, etc.) nécessaires pour effectuer les tests requis pour votre site Web.

Quelques exemples de différents types d’environnements:

• Environnement de test – Par exemple, la configuration locale du site Web où l'équipe de développement peut travailler / tester ses corrections de bogues et ses modifications de code sans craindre de casser une fonctionnalité qui aurait une incidence sur l'expérience de l'utilisateur. Une fois qu'ils ont fini de travailler sur une fonctionnalité ou une correction de bogue, celle-ci peut être transmise à l'équipe de test pour des tests supplémentaires.
• Environnement de transfert – La mise en scène est similaire à la production en ce qui concerne le contenu, la configuration, etc. C'est ici que les correctifs de bogues et les nouvelles fonctionnalités seront testés avant que le déploiement en production ne soit effectué. Il est fortement recommandé d'effectuer des tests de transfert avant de déployer quoi que ce soit en production. Ainsi, l’équipe de test peut détecter tous les problèmes susceptibles de se produire en production et faire épargner à tout le monde un mal de tête.
• Environnement de production – C'est ce que voit l'utilisateur final.

7. Préparation du calendrier des tests et des estimations de temps

• Estimations de test – C'est le temps nécessaire pour terminer le processus de test. Par souci de précision, il est préférable de diviser l’ensemble du processus en petites tâches et de fournir une estimation pour chacune d’elles. Ensuite, vous pouvez les additionner pour voir combien de temps il faut pour tout finir.

Vous trouverez quelques bonnes pratiques pour effectuer des estimations de test ici.

• Calendrier du projet – Un calendrier solide aidera la direction (en particulier le responsable des tests) à se faire une idée précise de la progression du travail sur le site Web. Il faut un certain nombre de choses importantes pour préparer un bon calendrier:
  • La date limite pour l'achèvement du projet – Celui-ci devrait venir en premier car il définira le délai dans lequel le programme de tests doit s’inscrire.
  • Jours ouvrables et disponibilité des employés – Cela aide à mieux organiser les activités de test dans le calendrier.
  • Estimation d'exécution du projet – Combien de temps faudra-t-il pour effectuer toutes les tâches liées au test de votre site Web?
  • Risque de projet – La connaissance des risques potentiels permet d'allouer du temps supplémentaire pour les gérer.

8. Tester les livrables

Les livrables de test incluent tous les documents, outils, rapports, etc. produits et mis à jour à l'appui des tests. Les livrables sont différents selon la phase du projet:

• Livrables, fournis avant le début des tests: plan de test, scénarios de test et spécifications de conception de test
• Livrables fournis lors du processus de test: scripts de test, journaux d'erreurs, données de test, etc.
• Livrables, fournis après la conclusion du test: résultats de test, rapports de défaut, notes de publication, instructions d'installation / procédure de test

Envelopper les choses

Comme on peut le constater, le plan de test couvre des processus importants et contient beaucoup d'informations essentielles nécessaires au test d'un site Web. Tout documenter faciliterait la gestion et le suivi du flux de travail et créerait les meilleures pratiques.