[ISTQB expliqué] 1.2 Que sont les tests

By Anir RADID | ISTQB Fondation

Sep 02

Cet article explique – paragraphe par paragraphe – le contenu de la section 2 « Que sont les tests » du chapitre 1 du syllabus ISTQB Fondation « Testeur Certifié ».

Contexte

L’exécution des tests n’est en réalité que la partie émergée de l’iceberg, les tests englobent plusieurs autres activités à accomplir avant et après l’exécution des tests.

Cette section ne fait que présenter en surface quelques activités qui se déroulent avant et après l’exécution des tests. Ces mêmes activités seront revues et traitées en détails dans les chapitres suivants.

Nous allons les parcourir rapidement pour se faire une idée sur leurs significations.

  • La planification et le contrôle est la première activité de test qui consiste à préparer et organiser les tests selon les contraintes du projet. Cette mission est généralement accomplie par un responsable des tests.
  • La sélection des conditions de tests est une activité d’analyse permettant de lister les éléments à tester et à vérifier « les conditions de test » :
    • Par exemple, pour une calculatrice je voudrais vérifier les opérations d’addition, de soustraction, multiplication et division. Je les considère alors comme les 4 conditions de test à couvrir par mes tests.
  • La conception de test est l’activité qui donne naissance à des tests. Durant cette phase, on écrit des tests de façon scriptée c’est à dire pas à pas, et action par action pour décrire la façon de les exécuter.
    • Par exemple, pour la condition de test Addition d’une calculatrice, je peux faire un test de 5+10, un autre test 0+100, 4+(-17) ..etc
    • Plusieurs tests peuvent être conçus pour la même condition de test.
  • La vérification des résultats : Le résultat obtenu lors d’une exécution doit être comparée avec le résultat attendu.
  • L’évaluation des critères de sortie : ces critères définis lors de la planification, permettront de faciliter la prise de décision au cours du projet d’arrêter ou de continuer les tests.
  • L’information sur le processus et le système en cours de test: est l’activité de « reporting », qui permet de communiquer sur l’avancement des tests et la progression de la qualité du logiciel.
  • La réalisation et la finalisation des activités de clôture: la clôture et une phase de prise de recul, de capitalisation sur les tests qui ont été réalisés et l’expérience acquise pour s’améliorer dans les projets à venir.
  • Revue de documents, Revue de code et analyse statique: Les tests ne se font pas toujours sur des logiciels en cours d’exécution, les revues et les tests statiques permettent de relire la documentation et le code source du logiciel pour détecter des défauts avant même qu’ils soient livrés ou le code exécuté.

 

 

La différence entre « tests dynamiques » et « tests statiques » et que les tests dynamiques sont réalisés sur un logiciel en cours d’exécution alors que les tests statiques sont effectués sur du code source (non exécuté) et sur de la documentation.

Qu’ils soient statiques ou dynamiques les tests fournissent des informations sur le produit logiciel. Des informations qui pourrait servir pour améliorer la qualité du produit ou améliorer l’efficacité du processus de sa fabrication.

On avait dit précédemment que les tests n’améliorent pas directement la qualité du logiciel mais bien les activités de développement qui corrigent les défauts.

Faire des tests c’est comme faire un diagnostic médical, le diagnostic donne des informations sur l’état de santé d’une personne. Pour cela, il est possible d’utiliser des approches statiques comme des radios et scanners ou des approches dynamiques en mesurant les capacités physiques du patient en lui faisant faire des exercices par exemple.

Les tests fournissent toujours des informations sur le produit logiciel et sur le projet. Mais l’obtention de ces informations peuvent êtres motivés par des objectifs divers et variés.

  • On peut réaliser des tests pour trouver des défauts, comme c’est le cas des tests par l’équipe qui réalise le produit et qui veut trouver toutes les anomalies possibles et les corriger avant de livrer le produit au client.
  • Le client en recevant le produit fait aussi des tests de sont côté pour acquérir de la confiance sur son niveau de qualité et vérifier qu’il peut l’utiliser conformément au besoin qu’il a exprimé.
  • Les tests fournissent des informations sur la qualité du logiciel pour la prise de décision durant les réalités des projets ou il faut faire des arbitrages entre d’un côté la qualité mesurée par les tests et de l’autres côté les contraintes de cout et de délai.
  • Les tests dans les processus de développement les plus matures permettent pas seulement de détecter les erreurs mais de les prévenir et d’empêcher des défauts de s’introduire dans le logiciel, des approches de développement orienté par les tests comme le TDD, BDD et ATDD permettent de spécifier par des tests le comportement attendu de l’application et d’écrire les tests avant même d’écrire le code qu’ils vont tester.

Plus on teste tôt mieux c’est. C’est un principe qu’il faut toujours garder à l’esprit.

Faire des revues de documents équivaut à relire des documents de spécifications, grâce à cette relecture, le testeur vérifie la cohérence des documents, chasse les ambiguïtés et les omissions avant même que le développeur commence à programmer, ce qui lui permet d’écrire un code propre en s’appuyant sur des documents de spécifications complets et cohérents.

 

La revue de documents ne permet pas seulement de détecter des défauts dans les documents mais prévient aussi l’introduction de défauts dans le code du logiciel. Car si les défauts de la documentation n’ont pas été trouvés, celles-ci auraient induit en erreur le développeur qui aurait introduit de nouveaux défauts dans le code. La revue de document permet donc aussi bien de détecter les défauts que de les prévenir.

Les objectifs peuvent être différents selon les points de vue des tests réalisés :

  • Les tests de développement : sont les tests réalisés par l’équipe qui fabrique et délivre le produit, comme les tests de composants, les tests d’intégration et les tests système qui sont des niveaux de tests qui vont être traités dans les chapitres suivants : l’objectif principal de ces tests est de trouver des défauts pour les corriger.
  • Les tests d’acceptation : ce sont des tests réalisés par « le client » qui réceptionne le produit, pour qu’il puisse acquérir de la confiance sur la capacité du produit à répondre à ses attentes.
  • Evaluer la qualité du produit : Les tests fournissent des informations sur la qualité du logiciel pour la prise de décision durant les réalités des projets ou il faut faire des arbitrages entre d’un côté la qualité mesurée par les tests et de l’autres côté les contraintes de coût et de délai.

 

Rappel :

  • On peut réaliser des tests pour trouver des défauts, comme c’est le cas des tests par l’équipe qui fabrique le produit et qui veut trouver toutes les anomalies possibles et les corriger avant de livrer le produit au client.
  • Le client en recevant le produit fait aussi des tests de son côté pour acquérir de la confiance sur son niveau de qualité et vérifier qu’il peut l’utiliser conformément au besoin qu’il avait exprimé.
  • Les tests fournissent des informations sur la qualité du logiciel pour la prise de décision durant les réalités des projets où il faut faire des arbitrages entre d’un côté la qualité mesurée par les tests et de l’autres côté les contraintes de coût et de délai.

 

Les tests de maintenance : Ces tests sont déroulés sur un logiciel existant qui subit des évolutions pour vérifier que ces modifications n’introduisent pas de nouveaux défauts.

Les tests d’opération : sont des tests qui couvrent des aspects non fonctionnels de l’application comme ses délais de réponse, sa réactivité quand il est sollicité par un nombre important d’utilisateurs. Le fonctionnel c’est ce que l’application permet de faire (en général ce sont ses fonctionnalités), le non fonctionnel est comment l’application le fait (facilité d’utilisation, délai de réponse, non coupure de service..)

Tester permet de détecter des défauts et c’est la tâche du testeur,

De-buguer permet comme son nom l’indique de défaire des bugs, càd de corriger des défauts. Le debuguage est une tâche réalisée par le développeur.

Quand un testeur trouve un incident, il le communique au développeur qui réalise un debugging pour mettre le doigt sur le défaut dans le code qui a causé la défaillance afin de le corriger.

L’histoire ne s’arrête pas là. Le testeur doit reprendre la main après la correction, en réalisant le test à nouveau sur son environnement de test pour confirmer que le défaut a bien été corrigé, et non seulement sur le poste du développeur. Ces re-test sont appelés : les tests de confirmation.

 

Ce qu’il faut retenir :

Que sont les tests ? (K2)

  • LO-1.2.1 Rappeler les objectifs habituels des tests. (K1)
  • LO-1.2.2 Fournir des exemples pour les objectifs des tests lors des différentes phases du cycle de vie logiciel (K2)
  • LO-1.2.3 Faire la différence entre tester et déboguer (K2)

 

Le test englobe plusieurs activités et non seulement l’exécution.

Les objectifs habituels des tests sont :

  • Trouver des défauts
  • Acquérir de la confiance sur le niveau de qualité
  • Fournir de l’information utile aux prises de décision
  • Prévenir des défauts

Tester permet de détecter des défauts et c’est la tâche du testeur, Debuguer permet de corriger des défauts et c’est une tâche du développeur.

Faites des commentaires en bas de la page, ça me fait plaisir et ça permet d’améliorer le contenu de des articles.

 

 

About the Author

Consultant de génération Y, Anir RADID partage ses connaissances et expériences dans le domaine des Tests Logiciels.