Skip to main content

Note de la rédaction : Bienvenue dans la série Leadership In Test du gourou et consultant en tests logiciels Paul Gerrard. Cette série est conçue pour aider les testeurs ayant quelques années d’expérience—notamment ceux travaillant en équipe agile—à exceller dans leurs fonctions de lead test et de management.

Cet article commence par la base : à quoi sert le test logiciel ? Vous découvrirez les concepts fondamentaux du test logiciel qui structureront votre réflexion au fur et à mesure que vous aborderez l’art et la science de l’assurance qualité logicielle.

Inscrivez-vous à la newsletter The QA Lead pour être informé dès qu’une nouvelle partie de la série est publiée—et approfondissez grâce au cours Leadership In Test de Paul. Si vous le faites, utilisez notre code promo exclusif QALEADOFFER pour bénéficier de 60 $ de réduction sur la formation !

Quand vous êtes responsable des tests sur un projet, il est très probable que les gens supposent que vous êtes l’expert en la matière de tout ce qui concerne les tests. Les autres membres de l’équipe auront sûrement leur propre opinion étayée (ou excentrique) sur les tests ; certains seront peut-être plus expérimentés que vous – ou du moins le diront.

Les attentes vis-à-vis des tests sont souvent irréalistes et même les personnes expérimentées adoptent parfois une attitude désinvolte sur ce que le test peut accomplir. Certains douteront de vos compétences, de votre valeur pour l’équipe, ou même de vos motivations. Ce n’est pas toujours facile.

Au cours de votre carrière en management des tests, vous devrez vous adapter à des circonstances nouvelles et changeantes. Vous rencontrerez des parties prenantes du business et des responsables de projet senior. Vous rejoindrez des équipes de tailles variées, composées de personnes ayant des parcours très divers. Certains auront une grande expérience, d’autres, honnêtement, beaucoup moins.

Want more from The CTO Club?

Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.

This field is for validation purposes and should be left unchanged.
Name*

Votre rôle pourra varier entre celui de testeur, de chef d’une grande équipe ou de personne supervisant le test sur un projet, celui de conseiller une équipe Agile ou encore définir comment intégrer les tests dans un dispositif d’intégration et de livraison continues.

Avant d’utiliser des termes comme test, partie prenante et objectifs de la partie prenante, il vaut mieux être clair sur ce dont il s’agit.

Définition de « Test »

Le mot test s’utilise à la fois comme nom et comme verbe. Il s’agit du test en tant qu’activité et du résultat de cette activité. Il s’agit aussi des personnes ou organisations qui commanditent cette activité et de celles qui utilisent les résultats. C’est aussi à propos de ceux qui se revendiquent testeurs et des systèmes complexes sur lesquels nous travaillons.

Si l’on veut parler d’un test indépendant du contexte, il nous faut une définition du test qui soit, elle aussi, indépendante du contexte. J’ai donc consulté la définition de test sur le site dictionary.com. Parmi la multitude de références au mot « test » et à ses usages, la définition du American Heritage Dictionary s’est révélée la plus adaptée :

Test : (nom) une procédure d’évaluation critique ; un moyen de déterminer la présence, la qualité ou la véracité de quelque chose ; une épreuve

Il n’y a pas qu’une seule définition ; il y en a en fait trois variations. Ce n’est pas si grave, car prises ensemble elles forment la base dont nous avons besoin. Examinons-les de plus près.

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

This field is for validation purposes and should be left unchanged.
Name*

Une procédure d’évaluation critique

L’évaluation critique consiste à porter un jugement éclairé sur la vérité ou la valeur de quelque chose. Un test est une procédure, généralement structurée en une série d’étapes incluant une préparation, l’exécution, la collecte de résultats, leur analyse et leur interprétation. Ceci n’est pas une description définitive d’une procédure de test. Il pourrait y avoir plus d’étapes et on pourrait encore subdiviser ces phases principales.

La procédure ne nécessite pas obligatoirement de documentation préparée, mais certains tests sont ainsi documentés (et les tests automatisés font toujours l’objet d’un script d’une façon ou d’une autre). L’essentiel est qu’il y a une démarche intellectuelle perspicace au cœur du test.

Cette démarche est motivée par le besoin d’évaluer le système testé en regard de son adéquation, de sa cohérence, de son comportement, de sa précision, de sa fiabilité ou de toute autre propriété ou aspect significatif.

Un moyen de déterminer la présence, la qualité ou la véracité de quelque chose

Un test peut déterminer assez facilement la présence (ou l’absence) de quelque chose, mais la « qualité » est une question différente : le terme est chargé de connotations émotionnelles, mais la même définition du dictionnaire nous sauve. La qualité peut être « une caractéristique, propriété ou attribut essentiel ou distinctif ». Nous voyons ainsi qu’un test peut révéler ces propriétés.

Notez que je n’utilise pas le terme « qualité » pour refléter la relation entre l’utilisateur ou une partie prenante et le produit. La qualité, c’est comme la beauté — elle dépend du regard de celui qui utilise. N’entrez pas dans des discussions sur la façon de mesurer la qualité (par le test). J’évite en général le mot commençant par un Q.

Notez que je n’utilise pas le terme « qualité » pour refléter la relation entre l’utilisateur ou une partie prenante et le produit. La qualité, c’est comme la beauté — elle dépend du regard de celui qui utilise. N’entrez pas dans des discussions sur la façon de mesurer la qualité (par le test). J’évite en général le mot commençant par un Q.

Un test peut-il déterminer la vérité de quelque chose ? Eh bien, cela a du sens aussi. Généralement, nous avons besoin de tester une affirmation telle que « ce système répond à une exigence » ou « ce système se comporte d'une certaine manière » ou « ce système est acceptable », etc. Il y a une part de jugement subjectif impliquée, mais nous pouvons voir qu’un ou plusieurs tests pourraient fournir des preuves permettant à quelqu’un d’exercer ce jugement et de prendre une décision.

Un procès

La notion de procès implique que le processus de test d’un système nous aide à évaluer ce système par rapport à ses qualités. Le but d'une telle évaluation est normalement de prendre une décision.

La décision pourrait être d’accepter ou de rejeter le système, mais elle pourrait tout aussi bien consister à révéler ses faiblesses afin qu’elles puissent être corrigées d’une certaine manière. Un test peut également inciter une personne ou une organisation à changer de direction – à repenser une conception ; à assouplir ou modifier une exigence ; à abandonner un composant et recommencer ; à acheter plutôt que construire ou à construire plutôt qu’acheter.

Une façon naturelle de considérer un système en test est qu’il est en procès et qu’il sera jugé d’une manière ou d’une autre.

Définition du test

À partir de notre définition du nom « test », on peut facilement en déduire un verbe.

Tester : (verbe) évaluer de manière critique ; déterminer la présence, la qualité ou la véracité de quelque chose ; effectuer une épreuve.

Jusqu'ici tout va bien.

Mais pas tant que ça, finalement. Malheureusement, le domaine du test est hanté par des problèmes de terminologie. Nous ne pouvons pas présenter ici un glossaire définitif. Pour éviter les malentendus dans vos projets, je vous suggère de demander quel est l'objectif de chaque type de test défini plutôt que de vous fier à une définition supposée.

Les principaux types de tests dont vous entendrez parler

Donner un tutoriel sur chacun de ces types de tests logiciels dépasse le cadre de cet article, mais en tant que testeur logiciel vous entendrez beaucoup parler de ceux-ci (dont certains auxquels vous vous êtes probablement déjà documenté) :

  • Test Boîte Noire
  • Test de régression
  • Test unitaire
  • Test bêta
  • Test manuel
  • Test automatisé ou test d’automatisation
  • Test de bout en bout
  • Test de résistance
  • Test de sécurité
  • Test de performance
  • Test Boîte Blanche
  • Test d’acceptation
  • Test d’intégration
  • Test de charge
  • Test système
  • Test non fonctionnel

Quel que soit le type de test dont vous parlez, mon conseil est de toujours demander quel est l'objectif du test, même si le nom semble largement accepté, comme test unitaire ou test d’acceptation. L’interprétation de ce que cela signifie peut varier d’une équipe à l’autre.

Inscrivez-vous à la newsletter The QA Lead pour être averti(e) lorsque de nouveaux articles de la série seront publiés — et plongez plus en profondeur avec le cours Leadership In Test de Paul. Si vous le faites, utilisez notre code coupon exclusif QALEADOFFER pour bénéficier de 60 $ de réduction sur le cours !

À lire aussi : 7 OUTILS DE BASE POUR L’INGÉNIERIE QUALITÉ ET POURQUOI VOUS EN AVEZ BESOIN