• Aucun résultat trouvé

Vérification et validation

Dans le document Assurance de la qualité logicielle (Page 48-51)

Les détails de l’activité

Unité 3. Vérification et validation

Introduction à l’unité

Dans cette unité, vous allez découvrir les activités liées aux étapes de vérification et de validation du logiciel. La vérification et la validation du logiciel s’organisent autour des

stratégies de tests et permettent de contrôler le processus permettant d’assurer que le logiciel est conforme à ses spécifications et répond aux besoins du client.

Comme vous le savez déjà dans le but d’assurer la qualité à l’issu du processus de développement, il vous a été dit que le contrôle se passe tout le temps pendant le

développement. Ainsi, le logiciel doit être vérifié et validé à chaque étape du processus de développement du logiciel à l’aide de documents produits aux étapes antérieures. Ainsi, la validation et la vérification commencent avec les exigences où nous pouvons déjà négocier les exigences, ensuite lors de la conception où les processus doivent être bien vérifiés, optimisés et validés, puis l’étape d’implémentation où des tests unitaires doivent être déjà faits et le code révisé, et enfin les tests sur le produit final. Ces deux activités ne doivent pas être confondues. La validation vérifie si les attentes du client sont respectées dans

l’implémentation du logiciel, tandis que la vérification confirme si le produit est conforme à ses spécifications techniques. Malgré toutes ces mesures, des failles peuvent n’apparaître qu’après l’implémentation du produit.

Objectifs de l’unité

À la fin de cette unité, vous devriez être capable de :

• Comprendre les étapes de vérification d’un logiciel.

• Comprendre les étapes de validation d’un logiciel.

• Comprendre les activités liées aux tests d’un logiciel.

• Comprendre les avantages du prototypage.

Termes clés

Validation : Contrôler si le programme implémenté répond aux attentes du client.

Vérification : Contrôler si le programme est conforme à ses spécifications techniques.

Exactitude : Le logiciel fait ce que je veux.

Prototype : un modèle original qui possède toutes les qualités techniques et toutes les caractéristiques de fonctionnement du nouveau produit, mais ne le

remplace pas.

Unité 3. Vérification et validation

Activités d’apprentissage

Activité 3.1 - Définition de la Mission de test Introduction

Dans cette activité, vous allez comprendre ce qu’est la conduite des tests.

Le processus de test est défini pour prendre en compte toutes les activités nécessaires pour assurer les types de tests suivants : la planification, l’analyse, la conception, l’implémentation, l’exécution, le suivi, les rapports sur les résultats et la clôture. Vous pouvez arriver à faire toutes ces activités d’une manière techniquement correcte sans parvenir à sortir un résultat appréciable par l’entreprise/client. Pour avoir des résultats de tests corrects, il faut que chaque responsable de groupe d’essais sache avec quels intervenants travaillés à chaque fois pour pouvoir avoir les bons paramètres en entrée pour espérer avoir des sorties de qualité. Les tests en elle seuls ne garantissent pas la qualité. Il est une fois encore question de la collaboration entre les acteurs afin d’associer les processus de tests à quelque chose qui a un sens pour les intervenants.

En plus des missions de test, la politique d’essai devrait parler de la façon dont les tests s’insèrent dans la politique de la qualité de l’organisation, si une telle politique existe. Si aucune politique de qualité n’existe, il est important d’éviter toute confusion et d’expliquer aux différents acteurs qu’une bonne politique de test ne signifie pas que les exigences qualité seront remplies.

Détails de l’activité

Pour les différents types de tests que nous avons listés en introduction, vous devez proposer un tableau qui récapitule pour chacun d’eux les acteurs principaux et les acteurs secondaires.

Lors des activités de tests, spécifier la tâche de chacun.

Proposez une approche qui selon permettra de pouvoir vérifier tous les processus et d’identifier réellement les vrais failles à chaque étape.

Pour un objectif inatteignable, es ce que des tests peuvent être réalisés ? Justifier à partir de vos lectures.

Quels sont les types de défaut qui peuvent être trouvés lors des tests ? Pour chaque cas dites comment cela pouvait être évité.

Quel document pouvait être élaboré pour contenir les tests à effectuer ? Donnez en les grandes lignes.

Pour assurer les tests et éviter que cela n’impacte les processus mis en place ou n’influence leur résultat, il faut :

- gérer les risques pour la qualité du système ; - instaurer la confiance, surtout avec les autorités ;

Conclusion

Cette activité a présenté le processus de définition de la mission d’essai. La définition d’un tel document est une première étape vers la mise en œuvre d’une démarche qui aboutira sur un logiciel de qualité. Les étapes de préparation et d’éléments de mission d’essai ont également été discutées.

Évaluation

Cette évaluation porte sur l’activité qui vient de se terminer et il est recommandé que vous le fassiez individuellement.

Système de notation

Cette évaluation est notée sur 3 points.

Évaluation

1. Identifiez les intervenants et élaborer une ébauche de mission test pour le site web d’une institution, UVA par exemple. (1.5 point)

5. Selon vous, es-ce que les tests peuvent être pris comme une mesure de l’assurance qualité s’il n’existe pas un document de politique de sécurité dans l’entreprise. Expliquez. (0.75 point)

6. Comment un défaut critique peut-il être évité selon vous ? Expliquez en donnant des exemples. (0.75 point)

Réponses :

1. Mission de tests de l’accessibilité des informations et de l’ergonomie du site web de l’UVA

• Intervenants : Développeur web, architecte web, administrateur de bases de données, administrateur réseau et système, webmaster du site, utilisateurs du site, les employés du service de gestion des formations en ligne, un échantillon d’étudiants, le support technique

• La mission consiste à vérifier les défauts critiques suivants : l’ergonomie permet-il une consultation aisée du site, les informations sont-ils dans les rubriques

appropriées, le site se fige-t-il, la création des comptes pour les étudiants se passe-t-elle toujours bien, …

• Les défauts non-critiques suivants aussi seront à vérifier : le logo de l’UVA est-il clair, es ce que le site donne envie d’étudier, le formulaire d’inscription permet-il de remplir les champs sans se tromper, …

2. Non, car on ne saurait comparer les résultats avec des normes choisies au départ pour le développement et les métriques à mesurer à chaque phase.

C’est le document de politique de sécurité qui sert de support aux tests de conformité pour conduire à l’assurance qualité.

Unité 3. Vérification et validation

3. Un défaut critique peut être évité en faisant suivre chaque phase du développement par tous les acteurs, surtout les utilisateurs finaux, l’expert métier et aussi en faisant valider les spécifications fonctionnelles par le client et son équipe.

Un défaut critique peut être le changement de l’ergonomie sans demander l’avis du client, une spécification mal comprise, une requête non optimisée.

Activité 3.2 - Stratégies de test

Dans le document Assurance de la qualité logicielle (Page 48-51)

Documents relatifs