Le métier de Testeur logiciel est un des métiers les plus intéressants dans le domaine de l’informatique mais il est souvent méconnu. La demande des profils d’assurance qualité qualifiés est forte par les entreprises qui souvent ne trouvent pas chaussure à leur pied.

Aujourd’hui nous allons parler Argent.

• Combien gagne un Testeur logiciel?
• Quels sont les salaires proposés actuellement sur le marché de l’emploi pour ce type de poste ?
• Quelles sont les évolutions possibles si on veut gagner en responsabilité et en revenus?
• Peut-on devenir indépendant et travailler en tant que Testeur freelance?
• Si je suis Freelance quel TJM puis-je demander pour mes missions?

Nous allons essayer de répondre à ces questions et plus.

Combien gagne un Testeur logiciel?

Pour savoir combien gagne réellement un Testeur logiciel, nous allons nous baser sur les témoignages des testeurs qui exercent déjà. C’est quelque chose que vous pouvez faire chez vous à cet instant même.

Vous allez sur un site d’emploi comme glassdoor.com

Vous tapez le nom du métier qui vous intéresse et la position géographique.

Ici je m’intéresse au métier de Quality Assurance qui est l’appellation de poste choisie par la plupart des témoignages.

Je vais donc renseigner le métier de Quality Assurance

Ensuite je vais taper France dans la position géographique pour voir combien sont payés les testeurs en France.

En validant la recherche nous avons une représentation de la distribution des salaires du minimum au maximum recensé en passant par le salaire moyen.

Par exemple ici nous savons que les testeurs qui ont témoigné ont des salaires annuels commençant par 26000€ jusqu’à 65000€ avec un salaire moyen de 40000€ annuel brut.

En France on raisonne beaucoup en salaire Brut annuel, ce qui n’est pas simple à se représenter tant la fiscalité et les cotisations salariales et patronales sont complexes en France.

Deux personnes qui ont un même salaire brut peuvent recevoir des sommes différentes sur leurs comptes bancaires.

Mais ici nous allons simplifier les choses en donnant un ordre d’idée des salaires net.

Il existe des simulateurs gratuits sur internet pour calculer approximativement les salaires net à partir du brut.

Sur notre exemple alors, selon les témoignages recensés, un Testeur logiciel peut gagner entre 1624€ par mois jusqu’à 4063€ par mois.

Le salaire varie selon la zone géographique, le niveau d’étude du professionnel et d’autres paramètres plus subjectives qui ont un impact pendant les entretiens d’embauche.

Le salaire moyen pour un Testeur junior statistiquement serait de 2500€

Nous allons comparer cela avec les revenus d’un développeur qui gagnerai selon les témoignages entre 30k€ jusqu’à 53k€ ce qui donnerait un salaire net de 1875€ jusqu’à 3313€

Le salaire net moyen pour un développeur junior est de 2500€,

Un développeur et un testeur junior entrent donc dans les mêmes tranches de salaires.

Nous allons voir si le métier de testeur reste intéressant dans le temps quand on l’a exercé pendant plusieurs années.

Une évolution possible d’un Testeur logiciel est de devenir Test Manager.

Nous allons faire une recherche pour voir les salaires associés à ce poste en France.

Un Test Manager serait payé en France selon les témoignages entre 38k€ jusqu’à 79k€ ce qui fait un salaire qui va de 2400€ jusqu’à 5000€ ce qui est juste excellent.

Voyons voir si on évolue de Manager à Directeur combien cela représenterait en salaire.

Un Quality Director gagnerait entre 60K€ jusqu’à 164k€ ce qui correspond à des salaires allant de environ 3750€ à plus de 10000€ par mois ce qui est énorme.

Pour se le représenter nous allons voir les évolutions possibles d’un développeur selon les témoignages recensés.

Un développeur sénior gagnerait entre 30k€ brut annuel jusqu’à 67k€ brut annuel ce qui correspond à un salaire net mensuel allant de 2375€ jusqu’à 4188€ par mois.

Un développeur après quelques années d’expérience et s’il est bon il peut devenir Architecte logiciel.

Un architecte logiciel gagnerait entre 44k€ jusqu’à 79k€ ce qui correspond à un net mensuel allant de 2750€ jusqu’à 4938€ net mensuel.

Et si le développeur devient un Directeur de projet il pourrait gagner entre 3000€ par mois jusqu’à 6375€ par mois ce qui correspond à des brut annuels entre 48k€ jusqu’à 102k€

Les salaires de testeurs et ceux des développeurs peuvent donc exploser avec le temps et peuvent être multipliés plusieurs fois quand on gagne en expérience.

Les salaires des testeurs en Suisse

Nous avons pris des exemples en France mais cela reste vrai dans les autres pays comme la Suisse où les salaires sont encore plus hauts même pour les Juniors.

Un Testeur en Suisse commencerait selon les témoignages à 4834 francs suisse net mensuel jusqu’à 7052 francs net mensuel.

L’indice du francs suisse est généralement un peu plus bas que l’euro.

Un Quality Manager peut dépasser les 9000 francs et le Quality Director peut dépasser les 11000 francs.

La niveau de vie en Suisse est plus cher qu’en France mais il y a des centaines de milliers de personnes de nationalités suisses ou des non suisses qui travaillent en Suisse et résident dans un pays à la frontière, ce qui leur permet de tirer partie en même temps de la hausse des revenus suisses et des prix plus bas des pays à la frontières, on les appelle les frontaliers.

Les frontaliers ne payent les impôts qu’une seule fois et c’est dans le pays où ils travaillent, c’est à dire en Suisse, en sachant que l’imposition en Suisse est bien plus avantageuse qu’en France.

Les salaires suisses exposés précédemment sont net d’impôt.

Les revenus d’un Testeur indépendant

Devenir Freelance est un moyen pour gagner en liberté tout en augmentant ses revenus.

Le TJM est un acronyme pour Taux journalier Moyen qui est le revenu brut journalier.

Le TJM est donc combien est payé le freelance par jour sans extraire les impôts et les cotisations.

Un freelance qui serait payé avec un TJM de 500€ par jour combien devrait il gagner par mois?

Si le freelance a travaillé un mois de 30 jours, ce mois de 30 jours contiendrait 20 jours ouvrables c’est à dire des jours hors weekends et jours fériés.

Les freelance a donc travaillé 20 jours à 500€ par jour, cela fait un revenu brut de 10000€ pendant ce mois

Ce revenu est brut donc pour calculer son revenu net il faut extraire les taxes et les cotisations qu’on doit à l’état.

Le revenu net variera beaucoup selon si on a choisi de se reverser un salaire mensuel, ou des dividendes annuelles, si on a choisit de payer l’impôt sur les sociétés ou l’impôt sur le revenu et du statut de la société.

Mais pour simplifier nos calculs nous allons considérer que le revenu net serait 50% du revenu brut.

Pour découvrir les revenus d’un testeur logiciel indépendant nous allons consulter le site spécialisé freelance-info

En consultant les contribution qui ne sont que les témoignages collectés des freelances, les testeurs logiciels acceptent des TJM allant de 250€ jusqu’à 849€

Le testeur aurait donc des revenus mensuels qui varieront entre 2500€ à plus de 8000€ mensuel.

Ces recensement montre que peu de juniors de 1 à 3 ans d’expérience travaillent en Freelance puis plus les années d’expérience augmentent plus les professionnels préfèrent devenir indépendant que rester salariés.

La plupart des freelances sont recrutés pour des missions par des sociétés de services pour intervenir chez des clients finaux, et un faible pourcentage réalise une prestation directement pour un client final sans intermédiaire commercial.

Portage salarial

Devenir indépendant apporte de la liberté mais pas forcément de la simplicité au début.

Un freelance est un chef d’entreprise qui doit réaliser des factures et suivre soigneusement sa comptabilité.

Ce sont là des tâches administratives qui ne sont pas le cœur de métier d’un Testeur logiciel.

Il peut alors choisir de réaliser lui même ses tâches. ou bien des les déléguer à un comptable professionnel qui les réalisera pour lui contre rémunération. Ce qui constituera des frais supplémentaires à prendre en compte.

Aussi, Le freelance contrairement à un salarié n’a pas un filet de sécurité comme l’assurance chômage quand son contrat se termine.

Quand une mission s’arrête, les revenus s’arrêtent aussi.

Il n’y a pas de période d’intercontrat comme un salarié en CDI (Contrat à durée indéterminée) où lorsque on n’est plus affecté à une mission, on est payé quand même.

Avoir des revenus fluctuants est un risque qui va de paire avec la liberté apportée par l’entreprenariat, quand on est un informaticien expérimenté c’est plutôt rare de ne pas trouver une nouvelle mission.

Il existe toutefois une solution qui permet en même temps de profiter de la liberté d’un freelance et de la sécurité d’un salarié.

C’est le portage salarial.

Le portage salariale est un contrat entre 3 entités, le professionnel, un client et une société de portage.

Le professionnel “porté” travaille comme le ferait un indépendant chez son client mais sans s’occuper des démarches administratives.

La société de portage lui rédige un contrat de travail avec la durée de la mission et s’occupe de toutes les démarches y compris la comptabilité et le règlement des impôts et des cotisations dues

Le professionnel se concentre seulement sur son cœur de métier et laisse à la société de portage le soin de s’occuper de tout le reste contre une rémunération qui varie généralement de 6 à 8% du TJM.

Quand la mission du professionnel se termine pour une raison ou pour une autre, le statut de portage salarial lui permet de bénéficier de l’assurance chômage tout comme un Salarié.

C’est un statut qui apporte un avantage financier intéressant et un équilibre entre liberté et sécurité bien apprécié.

N’hésitez pas à réagir à cet article dans la zone des commentaires.

La conception des tests est l’activité qui permet d’identifier et d’extraire à partir d’une base de test, les éléments suivants :

• Les conditions de test : c’est-à-dire les fonctions à vérifier
• Les cas de test qui décrivent comment ces fonctions seront testés
• Et les données à utiliser pour réaliser les tests

Il existe plusieurs techniques qui permettent de concevoir des tests. Dans ce syllabus de l’ISTQB, 3 techniques seront présentées :

1. Les techniques de conception de tests de type « Boite Noire »
2. Les techniques de conception de tests de type « Boite blanche »
3. Et des techniques de conception de tests basées sur l’expérience

Boite noire :

Les techniques de conception Boite Noire sont aussi appelées techniques de conception basées sur les spécifications.

Ces techniques permettent de juger le produit selon ce qu’il est sensé faire, sans s’attarder sur les détails techniques de sa fabrication.

Les tests conçus selon les techniques boites noire sont directement dérivés de la documentation qui décrit le comportement fonctionnel et non fonctionnel attendu de l’application.

• L’application doit permettre de créer des commandes en ligne
• De consulter les commandes en cours
• De modifier les commandes en cours
• De réaliser des transactions en moins de 5 secondes.
• De permettre à un nombre précis d’utilisateurs de se connecter en même temps.
• Etc..

Toutes ces exigences ne dépendent pas ni du langage de programmation, ni de la base de données utilisés.

Les tests boite noire n’utilisent aucune information concernant la structure interne du système à tester.

Boite blanche :

Les techniques boite blanche par contre sont basées sur la structure interne du système.

Pour réaliser des tests de type boite blanche, il faut connaitre les modules qui composent le logiciel et comment ils sont développés.

Ces tests sont donc réalisés par des intervenants qui ont accès à la structure logicielle de l’application.

Ces techniques boite blanches sont aussi appelées les techniques structurelles ou les techniques basées sur les structures.

Techniques basées sur l’expérience :

A côtés de des techniques boite noire et des techniques boite blanche, il existe des techniques issues de l’expérience de celui qui réalise le test pour détecter les faiblesses de l’application.

Ces techniques ne se basent ni sur la documentation ni sur la structure logicielle mais sur l’intuition de celui qui réalise les tests, qu’il soit développeur, testeur ou utilisateur.

Une technique de conception peut faire partie de plusieurs catégories.

Si on utilise la documentation de spécifications pour concevoir les cas de tests alors on utilise une technique de conception de type boite noire.

Si on utilise la structure interne d’un logiciel pour dériver les cas de tests alors on utilise une technique de conception de type boite blanche.

Caractéristiques habituelles des techniques de conception :

Boite noire :

Les spécifications peuvent être purement textuelle ou elle peuvent contenir des modèles et des diagrammes pour représenter le fonctionnement d’une application.

Le fonctionnement d’une application peut être modélisé sous forme d’un diagramme qui représente les utilisations possibles qu’on peut faire d’un système.

Ce modèle ou diagramme peut représenter des chemins fonctionnels possibles selon les actions de l’utilisateurs.

On peut directement dériver des cas de tests à partir de ces modèles.

Boite blanche :

Des cas de tests peuvent être dérivés du code source de l’application ou à partir de la conception de son architecture logicielle.

Le code source d’une application peut aussi être modélisé sous forme d’un graphe.

Ce graphe reprend toutes les instructions du code source et identifie les chemins d’exécution possibles.

Les cas de test peuvent avoir un bon niveau de couverture de l’application logicielle si les cas de tests vérifient tous les chemins possibles du graphe.

Si les cas de tests ne couvrent pas tous les chemins possibles du graphe alors des cas de test complémentaires peuvent être conçus pour améliorer la couverture du logiciel par les tests.

L’expérience :

Ce type de techniques se base sur :

le niveau d’expertise dans les tests logiciels et le domaine métier testé des personnes qui font les tests.

Ce qui est valorisé dans ce type de test est le degré d’expérience que possède celui qui va faire les tests dans ce même type de produit logiciel qui fera l’objet des tests et de son environnement technique.

Parfois les testeurs ont un tel niveau de recul sur le produit fabriqué qu’ils apportent des check-lists déjà prêtes contenants les défauts et les vulnérabilités possibles que les produits du même type (que celui à tester) ont habituellement, cela apporte un gain de temps et d’efficacité des tests appréciables.

Cet article décrit un processus de développement de test hautement formel.

Ce processus de test est généralement moins formel dans la réalité. Mais la compréhension du processus le plus formel permettra de comprendre plus facilement les processus les moins formels.

Le choix du niveau de formalisme à adopter dépendra du contexte du projet et de ses contraintes.

Plus les contraintes du projet sont fortes (contraintes de temps, exigence de sureté de fonctionnement ou exigences réglementaires réglementaire etc..), plus le processus aura besoin en théorie d’un niveau de formalisme élevé.

Plus les moyens dont dispose le projet sont grands (maturité des tests et des processus de développement, niveau d’expertise des personnes impliquées..etc) moins le processus a besoin en théorie d’un niveau de formalise élevé.

Le test est une comparaison entre le comportement réel d’une application, et le comportement attendu d’une application.

Le comportement réel de l’application est issu de la manipulation de l’application en exécution.

Le comportement attendu de l’application est issu quant à lui d’une documentation qu’on appelle Base de test.

Dans un article précédent, nous avions définit le processus fondamental de test qui se compose de 7 étapes

ANALYSE DE TEST

La deuxième étape du processus fondamental de test est l’Analyse de test.

Pendant cette étape le testeur lit la documentation de la base de test pour en extraire les conditions de test.

Les conditions de test sont tous les éléments qui ont besoin d’être vérifiés par des tests.

Les conditions de test est une liste de ce qui est à tester.

Une condition de test peut être :

• une fonction du système comme Trier, Calculer, Envoyer…
• Une transaction : comme le paiement en ligne, réserver une place, faire une demande sur un site.
• Caractéristique qualité : comme la facilité d’utilisation de l’application, la performance, la fiabilité, la robustesse

• Ou un élément structurel ; comme un menu, un logo, un titre, un bouton…

Les spécifications est la documentation qui décrit le comportement attendu de l’application à développer.

Les exigences sont une représentation atomique de ces spécifications. Au lieu d’avoir un document textuel difficile à manipuler on le structure sous forme d’une liste délimitée d’éléments (les exigences).

Les exigences permettent donc de représenter le comportement attendu de l’application sous forme d’une liste d’éléments à fabriquer.

Les conditions de test sont une liste des éléments à tester

Etablir la traçabilité entre les conditions de tests et les exigences, revient à établir des liens entre les éléments à fabriquer et les éléments à tester.

Une exigence peut nécessiter plusieurs vérifications.

Cela peut alors être représenté ainsi :

Analyse d’impact

La traçabilité entre les exigences et les conditions de test permet de réaliser des analyses d’impact.

Une analyse d’impact a pour objectif de mesurer les conséquences d’un changement dans les exigences.

En établissant la traçabilité, il est facile de trouver grâce aux liens, les éléments qui dépendent d’une exigence et qui seront touchée si cette exigence change.

Cette traçabilité permet aussi de détecter rapidement le niveau de couverture des exigences par les tests. Dans cet exemple (ci-dessus) on voit facilement que l’exigence 4 n’a été couverte par aucune condition de test.

« Pendant l‟analyse de conception des tests, les approches détaillées de tests sont implémentées pour sélectionner des techniques de tests basées sur, entre autres considérations, les risques identifiés « 

C’est une phrase longue et compliquée pour dire que :

L’analyse de risque est une technique pour sélectionner et prioriser les tests à réaliser.

CONCEPTION DES TEST

Pendant la conception des tests, les cas de tests sont créés.

Un cas de test se compose de :

• Un objectif de test : tout test d’avoir avoir un objectif défini à atteindre comme la vérification du fonctionnement d’un élément particulier.
• Une pré-condition d’exécution : qui peut être une liste de pré-requis nécéssaires à l’exécution comme une connexion établie à internet,, être positionné sur la page donnée de l’application pour commencer le test, avoir un compte utilisateur avec des habilitations données etc..
• Le cas de test contient aussi des valeurs d’entrée : comme des actions à accomplir et des données de test à utiliser.
• Des résultats attendus : comme l’affichage d’une nouvelle page ou un message d’erreur etc..
• Des post-conditions : comme être connecté à une machine, un paiement ou une transaction réussie ou en échec…etc

Le standard IEEE 829-1998 décrit les structures des conditions de test et des cas de test.

Il n’est pas nécessaire de lire ces standards mais Il faut retenir leurs noms et les sujets qu’ils traitent car ils peuvent être demandés lors de l’examen de certification ISTQB.

Les résultats attendus sont la référence du testeur qui va exécuter le test pour décider qu’un test est en Succès ou en Echec.

Si le résultat attendu n’est pas défini alors n’importe quel comportement de l’application lors de l’exécution peut être interprété comme un Succès.

Ce qui peut empêcher de détecter un défaut.

Les résultats attendus doivent être extraits de la base de test qu’ils soient des spécifications ou des exigences.

La base de test contient les éléments sur lesquelles se base le concepteur de test pour définir des résultats attendus comme les sorties et messages affichés, les modifications des données stockés la base de données ou des changements d’états à constater comme les états connecté et non connecté.

IMPLEMENTATION ET EXECUTION DES TESTS

L’implémentation des tests est l’étape où les tests sont détaillés.

Les tests ayant été créé lors de l’étape de la conception des tests, ne sont qu’une description générale de ce qui est à vérifier.

L’implémentation des tests définit une procédure de test précise pour chaque cas de test.

La procédure de test est une séquence d’actions concrètes à réaliser lors de l’exécution et des résultats attendus intermédiaires à vérifier suite à chacune de ses actions.

Ces cas de test ainsi implémentés seront priorisés selon la stratégie de test définie par le responsable de test.

Ces cas de test seront donc exécutés selon l’ordre qui a été défini dans cette étape.

Quand le test est manuel la séquence d’actions à exécuter est appelée une procédure de test.

Quand le test est automatique la séquence d’actions à exécuter est appelée Script de test.

Le standard IEEE 829-1998 traite aussi le sujet de spécification de procédure de test.

Le planning d’exécution des tests définit l’ordre d’exécution prévu des tests.

Le planning d’exécution des tests regroupe les procédures de tests manuels et les scripts de tests automatisés.

L’ordre d’exécution est défini sur la base d’une stratégie de test qui prend en compte

• La priorité des exigences à tester : les exigences les plus importantes peuvent être testés en premier
•  Les dépendances entre les tests : Les tests liés l’exigence « annuler une commande » sont à réaliser après les tests de « créer une commande ».
• Les tests de régression : on peut décider dans la stratégie de test de s’assurer que les modifications apportées au logiciel ne l’ont pas détérioré avant de vérifier les nouvelles fonctionnalités.

Comme la revue, L’analyse statique est une technique de test statique.

L’analyse statique est un moyen de trouver les défauts d’un code logiciel avant de l’exécuter.

On dit que l’analyse statique trouve des défauts plutôt que des défaillances parce que les défaillances nécessitent l’exécution du logiciel.

Comme tous les défauts ne produisent pas forcément des défaillances lors de l’exécution, l’analyse statique permet de détecter des défauts difficiles à trouver par les tests dynamiques.

L’analyse statique est généralement réalisée par de développeurs qui utilisent des outils d’analyse statique du code source.

Ces tests sont donc généralement automatisés.

Un outil d’analyse statique permet de parcourir le code source écrit avec un langage de programmation, une page HTML destinée à être lue par un navigateur ou des fichiers de données structurés grâce au langage de balisage XML.

Les outils d’analyse statique peuvent ainsi détecter dans le code source :

• Qu’une variable est mal référencée
• Que les interactions entre des modules ou des composants sont mal définis
• Que des variables sont déclarées mais jamais utilisées dans le code.
• Que des variables sont mal définies dans le code, comme une variable de type entier qu’on manipule comme un tableau.
• Qu’un code ne soit jamais accessible parce qu’il est contenu dans une fonction qui n’est jamais appelée.
• Que des erreurs logiques ont conduit à des boucles infinies, et coince l’exécution du logiciel jusqu’au plantage.
• La complexité dans un code source n’est pas souhaitée, elle augmente le risque de faire des erreurs et donc d’introduire des défauts.
• Les outils d’analyse statiques peuvent être paramétrées pour vérifier le respect des standards de programmation, comme la séparation des couches métier, de vue et de données, le respect des règles de nommage, la déclaration de variables, l’utilisation des commentaires…etc
• L’analyse statique vérifie aussi des règles de sécurités comme les contrôles qui sont faits sur les saisies des champs des formulaires.
• L’outil d’analyse statique aide les développeur grâce à l’auto-complétion lors du codage pour éviter les erreurs de syntaxe et le respect de l’architecture du logiciel.

Cela permet de :

• Détecter des défauts avant l’exécution du code et l’exécution des tests dynamiques.
• Grâce à l’analyse statique l’équipe est informée au plus tôt sur les faiblesses du code ou de sa conception, ce qui peut orienter les tests dynamiques et améliorer leur efficacité.
• Grâce à l’analyse statiques des défauts comme « le code mort » sont détectés alors que c’est impossible de les trouver par des tests dynamiques
• Les dépendances entre les composants du modèle logiciel peuvent introduire des régressions et des comportement indésirables quand ils ne sont pas clairement identifiés. L’analyse statique donne une meilleure visibilité sur les liens et les dépendances entre les différents composants du code.
• Quand le logiciel est bien conçu, la complexité du code est contrôlée et les dépendances entre les différents composants sont maîtrisés, la maintenance du code devient plus facile, et introduire un développement supplémentaire pour faire évoluer le logiciel devient moins risqué pour sa qualité (régressions).
• Les outils d’analyse statiques sont un bon moyen d’accompagner les développeurs pour s’assurer de la bonne qualité des développements.

Les outils d’analyse statique sont aujourd’hui inclus dans les compilateurs comme Eclipse et NetBeans. Le développeur bénéficie alors ces services d’analyse pendant qu’il écrit son code.

L’analyse statique peut aussi être déclenchée par des évènement comme le lancement des tests unitaires, les tests d’intégration ou quand plusieurs développeurs travaillent sur le même logiciel un serveur de gestion de configuration assure la cohérence du code et peut déclencher aussi les traitements de l’analyse statique pendant la mise à jour du code.

Les outils d’analyse statiques sont configurables, le développeur peut choisir les standards de programmations et les règles que le code doit respecter. Sur la base de cette configuration, l’analyse statique génère des messages d’erreurs bloquants qui suscite une correction ou des avertissements qui ne nécessitent pas forcément de correction.

Le choix de la configuration de l’outil d’analyse statique doit être identique pour tous les développeurs qui interviennent sur une même application logicielle.

Il existe plusieurs types de revues.

Quatre variétés vont être présentées un peu plus loin dans cette section.

Une revue peut être plus ou moins formelle selon la rigueur qui est accordée à sa réalisation.

On choisit d’appliquer un type de revue plus ou moins formel selon les contraintes légale ou réglementaire du projet ou la maturité du processus de développement.

Si le projet a des exigences légales ou réglementaires fortes ou que le processus de développement est mature alors les revues seront des revues formelles ou « systématiques ».

Si le projet est nouveau et n’a pas de contraintes légales ou réglementaires alors les revues peuvent être plus informelles.

On choisit le niveau de formalisme aussi selon les objectifs de la revue :

• Trouver des défauts
• Augmenter la compréhension et former les testeurs et les nouveaux membres d’une équipe : parce que la documentation revue est un entrant majeur des tests et le test ne peut pas être efficace si les testeurs n’ont pas compris le besoin initial et comment doit se comporter une application.
• Organiser la discussion et décider par consensus

Une revue formelle doit comporter :

• Les acteurs du projet qui vont réaliser la revue
• Une procédure avec des instructions claire pour les relecteurs sur comment mener la revue
• Les résultats de la revue sont formellement tracés et communiqués.

1. Phases d’une revue formelle (K1)

1. Planification :

 Définir les critères de revues : Définir ce que les caractéristiques auxquelles les relecteurs feront attention lors de la revue

 Choisir le personnel : Choisir les participants qui vont réaliser les revues

 Allouer les rôles : Affecter des rôles précis aux participants : qui sera Manager, qui sera le Modérateur, Qui est l’Auteur, Les réviseurs et le Scribe : tous ces rôles seront détaillés un peu plus loin.

 Définition des critères d’entrée et de sortie pour des types de revues plus formels (p.ex., inspections) :

• Dans un projet, il faut prendre constamment des décisions de quand commencer les tests et quand il faut les clôturer. Pour cela on utilise les critères d’entrée et de sortie.
• Les critères d’entrée sont des éléments objectifs sur lesquels s’appuyer pour décider de commencer les revues
• Les critères de sorties sont des éléments sur lesquels l’équipe se base pour décider objectivement d’arrêter les tests

 Sélectionner la partie des documents à revoir : sélectionner les documents à relire et les chapitres qui seront ciblés en priorité.

 Vérification des critères d’entrée (pour des types de revues plus formels) : Une fois la planification est effectuée il est temps de vérifier si les conditions sont réunies pour commencer les revues.

2. Lancement:

Le lancement est le moment où les participants vont découvrir la documentation à revoir et le mode opératoire de la revue qu’ils vont réaliser. C’est à cette étape que les documents seront distribués aux participants et qu’une présentation leur sera faite sur les objectifs et le déroulement de la revue.

 Distribuer les documents

 Expliquer les objectifs, le processus et les documents aux participants

3. Préparation individuelle :

Pendant cette étape, chaque participant pourra relire le document de son côté avant la réunion de revue et préparer ainsi ses remarques, commentaires et questions.

 Préparer la réunion de revue en revoyant le(s) document(s)

 Ecriture des défauts potentiels, questions et commentaires

4. Examen/évaluation/enregistrement des résultats (réunion de revue):

C’est au cours de cette étape que la revue est réalisée. Les différents participants parcourent collectivement le document en soulevant les points de discussion, en détectant les défauts et en faisant des recommandations sur les corrections potentielles. Cette réunion peut se faire en présentiel ou à distance avec les outils de communication disponibles.

 Discuter ou enregistrer, avec des résultats ou minutes documentés (pour des types de revues plus formels)

 Noter les défauts, faire des recommandations concernant le traitement des défauts, prendre des décisions à propos des défauts

 Examen/évaluation et enregistrement pendant toutes les réunions physiques ou enregistrement de toutes les communications électroniques

5. Re travail :

Cette étape regroupe les travaux de correction des défauts détectés lors de la revue

 Correction des défauts détectés (réalisé généralement par l‟auteur)

 Enregistrer le statut modifié des défauts (dans les revues formelles) : par exemple la production d’une nouvelle version corrigée de la documentation revue.

6. Suivi:

Le Manager pilote les processus de revue, il suit les travaux de correction en vérifiant la prise en compte des défauts détéctés, qu’il n’y a pas de défaut qui a été oublié.

Les participants à la revue fournissent des indicateurs d’avancement sur les documents revues, les défauts détectés et les défauts corrigés.

Ces métriques sont collectés par le Managerpour vérifier (grâce aux critères de sorties définies lors de l’étape de la planification)  si les conditions sont réunies pour clôturer le processus de revue.

 Vérifier que les défauts ont bien été traités

 Récolter les métriques

 Contrôle sur la base des critères de sorties (pour des types de revues plus formels)

2. Rôles et responsabilités (K1)

Il y a 5 rôles principaux que les participants à la revue peuvent endosser :

Le Manager est la personne qui doit prendre des décisions sur quand commencer ou arrêter chaque étape du processus de revue.

Le modérateur est un rôle important dans le processus de revue, le modérateur facilite les interactions entre les participants à la revue, il anime toutes les réunions de l’étape de la planification jusqu’à l’étape de suivi.

L’auteur est celui qui a écrit le document qui sera l’objet de la revue. Si l’auteur n’est pas disponible ce rôle peut être porté par une autre personne qui aura la responsabilité principale sur le document à revoir.

Les réviseurs sont les personnes qui vont concrètement relire les documents pour détecter les défauts. Il est conseillé que les réviseurs aient des profils différents pour multiplier les perspectives. Un document pourrait ainsi être vérifié par un utilisateur qui va vérifier que le document couvre bien un besoin réel, un testeur vérifie que des cas particuliers et des cas limites sont bien pris en compte, un profil technique vérifie bien que ce que décrit le document est techniquement réalisable. Tous les réviseurs émettent des questions et des remarques ou remontent des défauts potentiels. 

Le Scribe garantie la traçabilité, note enregistre tous les points identifiés pendant la réunion.

Des check-lists peuvent être utilisés pour garantir que tous les aspects d’une revue ont été vérifiés, cela permet aussi de rendre les revues plus industrialisées et plus rapide en parcourant les points d’une check-list préétablie.

3. Types de revue

Il existe plusieurs types de revue.

Un document peut faire l’objet de plusieurs types de revue.

Le syllabus définit 4 types de revue de la moins formelle à la plus formelle :

1. La revue informelle
2. La relecture technique
3. La revue technique
4. L’inspection

La revue informelle :

• La revue informelle est la revue la moins contraignante,
• Elle n’obéît pas à un processus préétablie.
• Elle peut se dérouler par la programmation par paires ce qui correspond à deux développeurs qui travaillent ensemble sur une même tâche sur le même poste. Cela diminue fortement le risque d’erreur.
• La revue informelle peut aussi être effectuée simplement quand un profil technique relit seul le document de conception technique ou le code de l’application.
• Les résultats de la revue peuvent être documentées mains ce n’est pas une obligation, les défauts peuvent être corrigés directement au fur et à mesure de leur détection.
• Ce type de revue peut varier d’utilité selon les réviseurs, il n’y a pas de contrainte qui oblige à multiplier les réviseurs et ainsi varier les perspectives : utilisateur, testeur, développeur et opérateur.
• L’objectif principal étant d’améliorer la qualité avec un minimum d’investissement.

La relecture technique :

• La relecture technique est dirigée par l’auteur du document à revoir
• La réalisation de la relecture technique peut être structurée sur la base des scénarios, en traitant le périmètre scénario par scénario, en faisant des répétitions à blanc pour comprendre et assimiler le contenu ou en impliquant des pairs càd des réviseurs qui ont le même profil que l’auteur et qui peuvent apporter un regard critique et enrichir le document revu.
• Il n’y a pas de limite de durée définie pour ce type de revue
• Ce type de revue peut être plus ou moins formel. Il est possible que les réviseurs préparent la revue au préalable mais cela reste facultatif ainsi que la présentation d’un rapport de résultats de revue et la participation d’un scribe.
• Les objectifs de ce type de revue peut-être la relecture pour découvrir et apprendre le contenu du document, la compréhension et l’assimilation du comportement attendu de l’application si c’est un document de spécifications ou tout simplement de trouver des défauts.

La revue technique :

• La revue technique est une revue documentée dont le formalisme varie aussi en pratique de quasiment informelle à très formelle.
• Elle a comme objectifs de regrouper des pairs pour discuter du contenu des documents revus, évaluer les alternatives possibles, recommander des améliorations et décider des corrections.
• La réunion de préparation est incluse.
• Des check-lists peuvent être utilisées.
• Un modérateur formé peut animer la revue
• Un rapport de revue est présenté à la suite de la réunion de revue.

L’inspection :

L’objectif de l’inspection est de trouver des défauts

L’inspection est le type de revue le plus formel de cette liste.

Il inclut toutes les étapes du processus de revu présenté précédemment :

La planification, Les rôles, l’étape de préparation, le rapport de revue, les check-lists, le suivi et les métriques.

4. Facteurs de succès des revues (K2)

Pour qu’une revue soit une réussite :

• Il faut que ses objectifs soient définis à l’avance et assimilés par les participants à la revue.
• Il faut mettre les bonnes personnes aux bons postes
• Plus on teste tôt mieux c’est, les revues interviennent tôt dans le processus de développement, si les testeurs sont impliqués dans les revues, c’est une occasion pour eux d’accéder et d’analyser au plus tôt la documentation de référence (base de test) et ainsi commencer à préparer les tests dès le début du projet.
• Les défauts qu’ils soient détectés lors d’une revue ou lors d’un test classique, doivent être décrits de façon factuelle et neutre pour être acceptés et corrigés par les auteurs ou les développeurs.
• Les interactions avec l’auteur du document revu doivent être respectueux et objectifs. Il ne doit se sentir jugé ou critiqué. Les remarques et commentaires exprimés lors des revues doivent être réalisés avec tact. Les participants doivent alimenter une ambiance de confiance.
• Le choix du type de revue doit prendre en compte les objectif et le contexte du projet.
• Quand le niveau de risque est critique et le niveau de qualité attendu dans un projet est relativement grand, le niveau de formalisme des revues doit s’y adapter. Introduire des check-lists rendra alors les revues plus efficaces ainsi que la définition de rôles précis pour les participants.
• Les participants peuvent suivre des formations ou ils apprendront les responsabilités liées à ces différents rôles, comprendre le processus de revue et apprendre les différentes techniques de revue. Si les revues sont réalisées par un personnel formé, cela ne peut qu’améliorer l’efficacité de détection de défauts.
• Les revues sont des activités à part entière qui doivent être correctement inclus dans le cycle de vie du projet et planifiés par l’encadrement.
• La maturité des activités de revues augmente grâce à l’amélioration continue, les participants à la revue peuvent échanger sur le déroulement des revues précédentes et suggérer des actions pour améliorer l’efficacité des prochaines revues.

Les tests statiques sont les tests qu’on peut effectuer sans avoir à exécuter le logiciel.

Un testeur réalise des tests statiques soit sur le code d’une application, soit sur la documentation du projet.

Il existe deux façons de réaliser les tests statiques :

• Les revues
• Et l’analyse statique

Les revues sont des séances de relecture du code ou d’une documentation qui peuvent être effectués bien avant l’exécution du code de l’application.

Parfois une relecture suffit pour se rendre compte de l’existence d’un défaut dans la documentation ou dans le code.

Le défaut ainsi détecté peut être corrigé en quelques instants par une simple modification dans le document ou le code relus.

Si la revue n’avait pas été faite, le défaut aurait conduit à un incident dont la détection aurait suscité la conception de tests, l’exécution de ces tests, la création de rapports d’incident, la reproduction de l’anomalie par le développeur, la modification du code pour corriger le défaut, la relivraison du logiciel dans l’environnement de test et la réexécution du test pour confirmer la correction du défaut.

Détecter un défaut au plus tôt grâce aux revues fait économiser au projet beaucoup de temps et d’argent.

Les testeurs et les développeurs peuvent réaliser des revues sur tout type de bases de test :

• Spécifications fonctionnelles
• Spécifications techniques
• Cahier d’exigences
• Code source
• Expression de besoin
• Le Plan de test où sont répertoriés les tests à réaliser : si le test n’est pas bon ça peut amener à créer des rapports pour des défauts qui n’en sont pas uns.
• Etc

Relire des documents de spécification avec un œil critique grâce aux revues, permet au testeur d’assimiler le comportement fonctionnel attendu de l’application :

• Détecter les oublis et les omissions,
• Remonter les ambigüités qui résident dans ses documents,
• Et échanger avec les référents métier qui les ont rédigés pour les clarifier et les compléter avant que le développeur se base dessus pour fabriquer la solution logicielle correspondante.

Les revues peuvent être réalisés manuellement mais on peut se servir d’outils de support.

Pour réaliser une revue, le testeur examine un document et au fur et à mesure de la lecture il peut faire des commentaires.

Il peut ainsi souligner un oubli, une ambiguité à clarifier, ou une spécification erronée à corriger.

La revue, l’analyse statique et le test dynamique sont des techniques différentes pour atteindre le même objectif.

Les tests statiques trouvent les défauts et peuvent donc être corrigés directement.

Les tests dynamiques quant à elle trouvent des défaillances, et il faut que le développeur investigue pour trouver les défauts correspondants.

Elles sont complémentaires.

Ces techniques peuvent toutes être utilisés dans un même projet.

Les défauts typiques où les tests statiques sont plus efficaces pour les détester sont :

• Déviations par rapport aux standards
• Défauts d’exigences
• Défauts de conception
• Maintenabilité insuffisante
• Spécifications incorrectes d’interfaces

Vous remarquerez que ce sont des défauts de conception fonctionnelle et technique qui sont introduits avant le codage du logiciel.

La maintenance est l’ensemble des activités effectués sur le logiciel après le déploiement.

Une fois un système logiciel est fabriqué et déployé, il est utilisé pendant des années.

Pour que le logiciel continue à être utilisé au cours des années, il faut que les incidents rencontrés soient corrigés, il faut faire évoluer ses fonctionnalités pour répondre aux nouveaux besoins des utilisateurs, il faut le migrer vers un nouvel environnement pour l’adapter aux nouvelles technologies, ou si nécessaire le supprimer de façon sécurisée en archivant les données importantes.

Toutes ces activités de modification de migration et de suppression sont des activités de maintenance.

Tous les tests associés aux activités de maintenance sont appelés des tests de maintenances.

Les modifications :

Les modifications peuvent être des corrections, des évolutions, ou des changements d’environnement.

Les corrections peuvent se faire à travers des livraisons planifiées à l’avance ou à travers des hot fixes ou des corrections à chaud en cas de détections d’un incident critique dont la correction est urgente.

Les évolutions sont des livraisons généralement planifiées de versions étendues du système logiciel.

Les changements d’environnement sont des mises à jour d’envergure limitée de l’un des éléments qui constituent l’environnement du système logiciel comme le système d’exploitation sur lequel il est basé, la base de données ou il stocke ses données et les logiciels sur étagère COTS dont le système dépend et qui doivent être mis à jour.

Tous ces éléments sont à mettre à jour régulièrement pour entretenir la qualité et le niveau de sécurité du système logiciel.

Les migrations :

Les migrations sont des changements majeurs dans l’environnement.

La taille et les spécificités des changements introduits lors des migration implique de les traiter comme une catégorie de maintenance à part entière.

Si lors d’une migration, la base de données est changée, le schéma de donnée qui est la structure qui organise le stockage et la manipulation de donnée change aussi.

Le changement de schéma de données implique la modification du code du système logiciel pour établir la communication entre l’application et sa nouvelle base de données.

Les tests de maintenance doivent alors vérifier les modifications du logiciel, ses caractéristiques opérationnelles dans sa communication avec la base de données, ainsi que l’intégrité des données récupérées de l’ancienne base et converties vers le format de la nouvelle base de données.

La suppression :

La « mise au rebut » est un terme comptable pour signifier la destruction ou la mise hors service d’un bien.

Une suppression est effectuée quand un système est remplacé par un autre système (et pas seulement sa base de données), ou quand le système est totalement abandonnée et seules ses données sont gardées et stockés grâce à des mécanismes d’archivage.

Les types de tests

Les tests de maintenances incluent donc :

• des tests qui vérifient les parties qui ont été modifiés pour vérifier qu’ils fonctionnent comme prévu,
• et des tests de régressions pour vérifier que les autres parties qui n’ont pas été modifiés n’ont pas été impactés par les changements.

Comme les tests de fabrication d’un nouveau logiciel, les tests de maintenance d’un logiciel existant peuvent être effectués sur plusieurs niveaux et en combinant plusieurs types de tests : fonctionnels, non fonctionnels, structurels, de confirmation et des tests de régressions.

Le périmètre de tests de maintenance est défini selon la criticité des parties modifiés, l’ampleur des des modifications réalisées et la taille du système global.

L’analyse d’impact est une étude qui permet d’identifier les conséquences d’un changement dans un logiciel.

Cette analyse d’impact est utile pour décider de ce qui doit être testé pour prévenir les régressions. Et déterminer les tests de régressions à réaliser.

Les spécifications sont le point de référence pour juger de la conformité d’un logiciel au fonctionnement attendu. 

Négliger de mettre à jour les spécifications complique la réalisation des tests de maintenance parce qu’on ne sait plus ce qui est attendu, et donc normal.

Les testeurs qui ont de l’ancienneté dans le projet peuvent limiter l’impact de l’absence de spécification grâce à la connaissance fonctionnelle qu’il ont du logiciel, mais ces testeurs peuvent ne plus être disponibles s’ils sont en congé ou s’ils quittent le projet.

Il est donc important d’entretenir des spécifications à jour tout au long de la maintenance d’un système logiciel.

Dans le syllabus ISTQB distingue 5 types de test :

1. Les tests fonctionnels 
2. Les tests non-fonctionnels 
3. Les tests structurels
4. Les tests liés aux changements : qui se composent des tests de confirmation et les tests de régression

Le logiciel à tester peut-être modélisé et représenté sous la forme d’un diagramme.

Cette représentation permet aux développeurs de mieux comprendre ce qu’ils doivent fabriquer, et aide les testeurs à concevoir les tests de s’assurer qu’ils couvrent tous les cas de figure importants.

Par exemple :

• Diagramme de transition d’état :
• Diagramme de flux de processus
• Diagramme de contrôle de flux
• La structure de menu
• Modèle de menace de sécurité
• Spécification en langage naturel : en français le moins technique possible

On verra dans le chapitre 4 quelques-unes de ces techniques de modélisation.

1. Tests fonctionnels

Les fonctions sont ce que « fait » le logiciel.

Par exemple pour une application d’une banque :

• Créer un compte bancaire
• Modifier un compte bancaire
• Faire un virement
• Imprimer le RIB
• Commander une carte bancaire
• …etc

Les tests qui vérifient ces fonctionnalités sont appelés « Les tests fonctionnels ».

Le test fonctionnel est de loin le plus populaire parmi les types de test.

Ces tests sont conçus à partir des livrables non techniques qui décrivent le fonctionnement attendu de l’application, comme :

• les spécifications fonctionnelles
• les spécifications d’exigences
• Les cas d’utilisation
• Le fonctionnement attendu de l’application peut ne pas être décrit noir sur blanc dans un document mais il peut être extrait à partir des échanges avec le client ou les utilisateurs.

Les fonctions sont ce que « fait » un composant, un ensemble de composant, un système ou un système de systèmes.

Les tests fonctionnels peuvent donc être réalisé à tous les niveaux de test : test composant, test d’intégration, tests système et tests d’acceptation (ou éventuellement tests d’intégration système).

Les tests fonctionnels exécuté dans chaque niveau se base sur le livrable du niveau de développement correspondant dans le cycle en V.

Comment Dériver des conditions de tests fonctionnelles de ces livrables et les techniques de conception des cas de tests seront couverts dans le chapitre 4 du syllabus.

Les tests fonctionnels vérifient le comportement extérieur d’une entité logicielle, ce comportement est l’ensembles des fonctionnalités que le logiciel fournit indépendamment des choix techniques qui sont fait pour fabriquer ce logiciel.

Ces tests sont donc des tests boite noire car ils ne s’intéressent pas au code et à la structure technique du produit logiciel.

Les tests de sécurité et les tests d’interopérabilité

Les tests de sécurité et les tests d’interopérabilité sont des tests fonctionnels.

 Les tests de sécurité examinent les vulnérabilités du système et les tests d’interopérabilité vérifie la capacité du système à interagir avec d’autres systèmes.

Il y a souvent confusion entre intégration et interopérabilité.

L’intégration s’assure de la communication entre des composants ou des systèmes qui sont fabriqué ensemble. L’intégration est définitive.

L’interopérabilité s’assure de la communication entre des systèmes développés par des éditeurs différents. L’interopérabilité est temporaire et est remise en question à chaque mise à jour d’un des systèmes communicants.

2. Tests non-fonctionnels

Les tests non-fonctionnels n’évaluent ce que « fait » le produit logiciel mais « comment » il le fait.

Est-ce qu’il est rapide ? fiable ? facile d’utilisation ? maintenable ? portable sur des supports différents ? …etc

Des exemples de tests non fonctionnel :

• Test de performances : vérifient que le logiciel est suffisamment rapide en temps d’exécution et en débit.
• Test de charge : déterminent la charge maximale supportée par l’application
• Test de stress : vérifie comment réagit l’application quand elle fait face à sa charge maximale
• Les tests d’utilisabilité : vérifie que l’application est facile d’utilisation et de prise en main.
• Les tests de maintenabilité : vérifient la facilité d’adaptation de l’application à des modification de code ou à des évolutions des environnements extérieurs sans que cela génère des régressions.
• Les tests de fiabilité : vérifient Le degré avec lequel l’application reste disponible malgré les interruptions.
• Les tests de portabilité : vérifient la facilité de transfert de l’application d’un environnement à un autre.

Ces tests non-fonctionnels peuvent être réalisé au niveau des tests composant, au niveau Intégration, au niveau système et par le client au niveau d’acceptation.

Mais la grande différence avec les tests fonctionnels qui sont soit OK soit KO. Les résultats des tests non-fonctionnels sont des valeurs sur une échelle.

Comme le temps de réponse en millisecondes quand on effectue des tests de performance.

Le nombre d’utilisateurs  en connexion simultanés quand on effectue des tests de charge.

L’ISO9126 décrit les caractéristiques qualité qui peuvent faire l’objet des tests non fonctionnels.

Les tests non fonctionnels comme les tests fonctionnels vérifient le comportement du logiciel sans s’intéresser au code. Ce sont donc des tests « boite noire ».

3. Tests structurels

On dit que les tests structurels sont des tests « boite blanche » parce qu’elles se basent sur le code de l’application ou avec des mots plus compliqués : la structure logicielle du système.

Quand le testeur fait des tests boite noire, il ne s’intéresse pas à la structure du code, au langage de programmation, ou aux technologies impliquées. Le testeur conçoit les tests à partir des spécifications et vérifie que le logiciel fournit les services qui ont été prévus dans les spécifications, indépendamment de la technologie utilisée pour le fabriquer.

Quand un testeur fait des tests boite blanche, cela veut dire qu’il peut voir le code et qu’il peut concevoir des tests selon la structure de ce code, pour couvrir et vérifier ses chemins d’exécution possibles.

Comme les autres types de tests, les tests structurels peuvent être réalisés pendant le niveau des tests composants, le niveau d’intégration, ou le niveau des tests système et rarement pendant les tests d’acceptation qui sont généralement effectués par des profils peu techniques comme les utilisateurs.

Le code source d’un logiciel peut être modélisé sous forme d’un graphe composé d’étapes et des transitions qui représentent les instructions du code.

Chaque test déclenche l’exécution d’une partie du code.

Quand les testeurs ont une visibilité sur le code ils peuvent mesurer les chemins et les parties du code couverts par leurs tests. Ce que ne permettent pas les tests boite noire basées sur les spécifications.

Exemple de code :

Lire (Age*) ; * une valeur sur le clavier

Si Age < 18 Alors

Afficher (« Mineur »)

Sinon

Afficher (« Majeur »)

A est une instruction simple.

B est une condition qui crée une bifurcation dans la structure du code. Quand la condition est vrai cela déclenche un traitement c. si la condition est fausse, cela déclenche un traitement d.

Supposant qu’on crée un test 1 avec une valeur à taper sur le clavier de 15.

Test 1 : Age = 15

L’exécution de ce test parcourra le chemin abc. Et l’instruction d ne sera pas exécutée.

Si la campagne de test ne contient que le Test 1 alors la couverture des tests est de 50% parce que le test a couvert la moitié des chemins possibles du code.

Pour augmenter la couverture, on peut concevoir un deuxième test qui va orienter l’exécution vers le chemin qui parcourt l’instruction « d ».

Test 2 : Age = 40

En exécutant la suite de ces deux tests, on a couvert 100% de la structure du code.

Les techniques de couverture sont traitées plus en détail dans le chapitre 4.

Mesurer la couverture du code eut vite devenir un cauchemar si on le fait manuellement, mais heureusement il existe des outils qui le fait à notre place en parcourant les instructions ou les décisions comme les conditions si-alors et les boucles.

Les tests qui se basent sur la structure du code sont surtout les tests sur les premiers niveaux du cycle projet comme le niveau des tests composant et le niveau des tests d’intégration. Ils peuvent être réalisés lors des tests du niveau système et au niveau des tests d’acceptation mais c’est beaucoup moins fréquent

4. Les tests de confirmation et de régression

Les tests de confirmation

Les tests de confirmation sont des tests exécutés une deuxième fois pour confirmer la correction d’une anomalie qui a été détectée lors de la première exécution du test.

C’est compliqué ?

Voici comment cela se produit dans le temps.

Pendant la phase d’exécution. Le testeur exécute des cas de tests.

Lorsque le testeur détecte un incident lors de l’exécution d’un cas de test, le testeur crée un rapport d’incident et l’envoie au développeur.

Le développeur cherche le défaut à l’origine de l’incident grâce au débogage.

Quand le développeur trouve le défaut, il corrige et livre la nouvelle version corrigée du logiciel au testeur.

C’est à ce moment là que le testeur réalise un test de confirmation en vérifiant que l’incident ne se produit plus.

Les tests de régression

Quand on modifie le code d’un logiciel pour ajouter de nouvelles fonctionnalités ou pour réaliser des corrections, on risque de toucher à des parties du logiciel qui fonctionnait correctement, et qui après modification, ne fonctionnent plus comme avant.

C’est ce qu’on appelle des régressions.

Les tests de régression ont pour objectifs de s’assurer que les modifications apportées au logiciel n’apportent pas des régressions dans ce même logiciel ou sa compatibilité avec les autres systèmes avec lesquels il communique.

Plus la modification apportée au logiciel impacte des parties importantes de ses composants, plus le risque de régression est grand, plus le périmètre des tests de régression doit être étendue.

Les tests de confirmation et les tests de régression sont censés être exécutés plusieurs fois, il doit donc être possible de les répéter grâce à des pas de test claires et bien définies.

Tous les types de test vus précédemment peuvent devenir des tests de régression s’ils concernent des caractéristiques ou des parties existantes du logiciel qui ne sont pas censés changer.

Les tests de régression peuvent être réalisés quelques soit le niveau de test.

L’automatisation permet de programmer un test une seule fois et de l’exécuter automatiquement autant de fois qu’on le souhaite de jour ou de nuit.

L’automatisation est un investissement qui a un coût, il faut donc bien choisir les tests à automatiser.

Pour automatiser un test, il est préférable que le test concerne une partie importante du logiciel qu’il faut donc vérifier de façon récurrente, et qui ne subit pas beaucoup d’évolution (pour ne pas avoir à constamment mettre à jour le test).

Les tests de régression étant des tests à exécuter régulièrement, et qui ne changent pas souvent. Ce sont de bons tests à automatiser.

Le syllabus de l’ISTQB définit 4 niveaux de test principaux :

1. Les tests composants
2. Les tests d’intégration
3. Les tests système
4. Les tests d’acceptation

Pour comprendre ces niveaux de test, il faut garder à l’esprit la représentation qui est fait d’un système ainsi que la correspondance qui existe entre les niveaux de développement et les niveaux de test pour fabriquer ce système.

Un système peut être constitué de plusieurs composants ou modules.

Chaque composant interagit avec les autres composants via des interfaces et des protocoles de communication.

Pour qu’un système fonctionne correctement :

• Il faut que chaque composant du système fonctionne bien séparément
• Il faut que chaque composant communique bien avec les composants avec qui il interagie.
• Il faut que toute la chaine de composants fonctionne comme prévu.

Pour fabriquer un système ainsi imaginé, Le cycle en V nous aide à :

1. Concevoir le système du niveau le plus haut au niveau le plus bas.
2. Fabriquer le système et le tester du niveau le plus bas au niveau le plus haut.

À gauche du modèle en V, Chaque niveau de développement (qui est en réalité un niveau de conception sauf le dernier) produit un livrable qui est la base de test et la référence pour le niveau de test qui est à gauche du modèle en V.

• L’expression de besoin produit un livrable qui sera la référence des tests à réaliser au niveau d’acceptation.
• La conception fonctionnelle produit un livrable qui sera la référence aux tests à réaliser au niveau des tests système.
• La conception de l’architecture technique produit un livrable qui sera la référence aux tests à réaliser au niveau des tests d’intégration.
• Les tests composants seront réalisés sur la base de la conception technique et du code de l’application.

Pour comprendre l’utilité de ces niveaux de test et pouvoir les distinguer facilement, le syllabus s’appuie sur les points suivants :

• Les objectifs de test
• La base de test : ce sont les livrables et la documentation de référence sur lesquels on se base pour extraire les cas de test, comme les exigences, les spécifications et les documents de conception fonctionnelles ou techniques.
  • Un test est une comparaison entre le comportement réel d’une application et une « Référence ».
  • Cette « Référence » décrit le comportement attendu de l’application.
  • C’est cette référence qui permet au testeur de juger que ce qu’il a constaté est une anomalie ou pas.
  • Si le système ne fonctionne pas comme décrit dans la documentation de référence alors il y a une défaillance.
  • L’ISTQB appelle cette référence : la base de test.
• Les objets de test : c’est-à-dire ce qui est habituellement testé par le niveau de test, cela peut être une partie technique du système ou un de ses aspect fonctionnels.
• Les défauts et défaillances typiques à trouver
• Les exigences en harnais de test et en support d’outils : c’est-à-dire de quoi s’équiper pour réaliser les vérifications de chaque niveau de test, comme l’environnement de test, les postes de travail, les outils et logiciels, des bouchons et des simulateurs…etc
• Chaque niveau de test peut avoir des approches et des responsabilités qui lui sont spécifiques.
• Tous ces éléments sont précisés lors de la phase de planification. La première phase du processus de test.

1. Les tests Unitaires/de Composants

Les tests composants sont plus populaires sous le nom de tests unitaires.

Les tests de composants est le niveau dont les tests sont généralement les premiers à être exécutés.

Ces tests sont préparés sur la base de la conception technique et du code de l’application.

Les exigences des composants est la description de ce doit faire chaque composant.

Les noms des livrables sont souvent différents d’une organisation à une autre.

Dans ce niveau on teste habituellement des composants si le système est simple.

Cependant on peut aussi être amenés à tester des programmes entiers si le système à tester est lui-même composé de d’autres systèmes et programmes.

Si le projet est une migration d’un ancien système vers un nouveau système en récupérant les données existantes. Ce niveau de test peut comporter des tests sur des programmes de conversion vers le nouveau schéma de données et la manipulation des modules de bases de données.

Les tests composants vérifient le fonctionnement de chaque composant séparément dès qu’il est développé.

Chaque composant peut être isolé du reste de l’application, cela permet de concentrer l’attention et l’effort de test sur les aspects fonctionnels comme non fonctionnel d’un seul composant.

Si une anomalie est détectée, il n’y a pas d’ambiguïté sur son origine.

Parfois, pour qu’un composant fonctionne, il faut absolument qu’il demande une donnée à un autre composant.

Quand cet autre composant n’est pas encore développé ou pas encore testé donc non fiable. Un bouchon peut être utilisé pour le simuler.

Si par contre quand le composant à tester s’attend à des instructions d’un autre composant qui n’est pas encore prêt, Alors les tests peuvent être réalisés en utilisant un Pilote pour simuler le composant indisponible.

Types de test :

 Lest tests composants peuvent être fonctionnels càd ce que le logiciel fait ou non fonctionnels càd comment il le fait.

Les tests non fonctionnels peuvent être des tests de robustesse.

Les tests de robustesse sont des tests qui vérifient le comportement de l’application dans des circonstances exceptionnelles comme le débranchement d’un câble ou une panne de réseau. Un système robuste a une réaction prévisible lors des conditions dégradées.

Les tests structurels sont des tests qui vise à couvrir les chemins d’exécution possibles du code de l’application, en passant par les boucles et les conditions (if-else possibles).

En pratique :

Généralement les tests unitaires sont un code qui teste le code du système. Les tests de ce niveau sont réalisés par le développeur qui a programmé le composant. Dans ce cas les tests sont automatiques puisque c’est du code, et ils sont conçus et exécutés grâce au même environnement de développement et des outils de débogage qui ont servi à développer l’application.

Un framework est une bibliothèque logicielle qui donne un cadre structuré et un squelette à une application.

Des frameworks de tests unitaires existent pour permettre de mieux structurer et de facilement gérer les tests unitaires.

Tester d’abord :

Il est de plus en plus populaire et à juste titre de concevoir les tests avant de développer le code qu’ils vérifient.

C’est une pratique introduite par les approches de développement itératifs qui se servent des tests pour clarifier la conception et de vérifier que les développeurs ont bien compris l’attendu avant même de commencer à coder.

Le code des tests composants est écrit dans un langage de programmation. Il est donc par définition automatisé.

Ces tests échouent bien évidemment au début car les bouts de code qu’elles vérifient n’existent pas encore.

Quand le code de l’application est développé, les tests sont exécutés et les échecs montrent l’existence des défauts à corriger.

L’application est corrigée et les tests sont lancées automatiquement après pendant plusieurs itérations jusqu’à ce que les tests ne trouvent plus de défaut et sont tous au « Vert ».

Cette pratique est appelée « Test First » ou TDD pour Test Driven Development.

2. Les tests d’intégration

Les bases de tes de ce niveau sont tous les livrables du niveau de développement correspondant « Conception technique » comme :

• La conception du système
• L’architecture technique
• Les workflows ou les flux de données et les protocoles de communication
• Les cas d’utilisation qui décrivent les interactions entre les composants.

Les objets tests sont souvent :

• Les sous-systèmes du Système principale.
• Les bases de données
• L’infrastructure comme les postes de travail, les serveurs, les systèmes d’exploitation, les navigateurs web…
• Les interfaces entre les composants
• La configuration système et les données de configuration.

Le niveau de test d’intégration concentre les efforts de test sur les interfaces entre les composants.

Il vise à vérifier les échanges entre les différentes parties d’un système en testant les interactions et leur respect des protocoles de communication établis au préalable.

Tests d’intégration composant vs Test d’intégration système

Si on teste un système simple alors les tests d’intégration seront réalisés sur les interfaces des composants du système.

Si le système est une chaine applicative, elle-même constituée de d’autres système alors l’intégration de ce super-système suscitera des tests sur les interfaces entre les systèmes qui le composent. On appellera alors ce niveau Tests d’intégration Système, car il intègre plusieurs systèmes entre eux.

La portée de l’intégration.

Si on rencontre un dysfonctionnement en réalisant des tests d’intégration entre 2 composants, le défaut d’origine ne peut venir d’un des deux composants.

Par contre, si un dysfonctionnement est détecté pendant des tests d’intégration entre 9 composants.

Trouver le défaut d’origine devient une tâche à part entière qui nécessite un temps d’investigation qui prend du temps avant même d’envisager une correction.

Pour limiter l’impact de ce phénomène, une approche méthodique est nécessaire.

Il existe des stratégies pour bien gérer l’intégration des composants.

Ces stratégies se basent sur la structure logicielle de l’application sous forme d’arborescence selon les dépendances entre composants avec un sommet (top) et des feuilles (bottom).

Quand on commence par intégrer les composants au sommet puis un à un les composants qui en dépendent, la stratégie est appelée Top-Down.

Si on commence par intégrer les composants en commençant par le bas, la stratégie est Bottom-Up.

Si on n’a pas de stratégie et on teste tout en même temps (on connecte tout et on branche le cable d’alimentation) : cela s’appelle Big Bang.

Les tests d’intégration peuvent inclure des tests fonctionnels comme des tests non fonctionnels comme les temps de réponse des interactions.

Les tests sont sensés se focaliser sur les interactions entre les composants pendants les tests d’intégration, des tests de ce que fait chaque composant a dû être couvert pendant le niveau précédent : les tests composants.

Dans l’idéal, les professionnels qui réalisent les tests d’intégration devraient connaitre la structure logicielle de l’application.

Cette connaissance de l’architecture logicielle et du code est utile non seulement pour concevoir efficacement les tests mais aussi pour planifier leur fabrication dans un ordre qui va tenir compte des dépendances entre les composants.

3. Les tests système

Les tests système vérifie le fonctionnement du système dans sa globalité.

Le périmètre de test est la liste de tout ce qui doit être couvert par les tests.

Le périmètre de test doit être précisé dans des documents qu’on appelle Plan de test maître ou Plan de test du niveau système.

La documentation de test va être détaillée dans les prochains chapitres.

Les tests système sont souvent le dernier niveau de test du fournisseur de service qui fabrique et délivre le produit.

Il doit s’assurer que le produit qu’il a fabriqué se comporte conformément aux spécifications présentées au client.

L’environnement de test de ce niveau doit ressembler le plus possible à l’environnement de production dans lequel les utilisateurs finaux vont manipuler l’application.

Cela aide à éviter que l’application fonctionne bien pendant les tests système mais des défaillances apparaissent soudainement dans l’environnement des utilisateurs, parce que cet environnement est différent.

Les tests système sont conçus sur la base des livrables du niveau de conception fonctionnelle comme :

• Les spécifications fonctionnelles
• Les exigences
• Les cas d’utilisation
• Les processus commerciaux
• …

Les noms de ces livrables peuvent être différent d’un projet à un autre et’ d’une organisation à une autre mais elles sont en générale des conceptions de haut niveau du comportement de l’application.

Le niveau des tests systèmes vérifient :

• les exigences fonctionnelles : càd ce que l’application permet faire en terme de fonctionnalités
• Les exigences non fonctionnelles : càd comment elle le fait, est ce qu’elle est performante, est ce qu’elle gère bien des nombres importants d’utilisateurs, et comment se comporte-elle dans des cas exceptionnels comme les pannes de courant et de réseau
• La qualité des données doit aussi être vérifiée

Ces exigences peuvent être explicitement décrites dans les documents de conception, mais elles peuvent aussi être sous-entendues et implicites.

Le testeur doit pouvoir relever ce type d’exigences et aider à les expliciter pendant les échanges avec les rédacteurs des documents de conception.

Ce niveau de test est le premier niveau ou les techniques de conception de test boite noire peuvent être utilisées.

Il est aussi le dernier niveau ou les techniques boite blanche peuvent être utilisées (après les tests composant et les tests d’intégration)

Boite blanche veut dire que le testeur conçoit ses tests en se basant sur la structure technique du produit logiciel : càd le code

Boite noire correspond aux tests qui ne s’intéresse pas à l’architecture technique du logiciel mais à ce que le logiciel permet de faire indépendamment de son implémentation (code, langage de programmation, architecture : etc

Donc :

• Boite blanche : on voit le code (on voit à travers la boite)
• Boite noire : on ne voit pas le code (puisque c’est sombre)

Le niveau Tests système permet d’utiliser les techniques de conception boite noire et boite blanche mais la priorité est aux tests boite noire car elle correspond bien au caractère « haut niveau » des tests système.

Les techniques de conception Boite blanche et boite noire seront détaillées dans les chapitres suivants.

• Tests d’acceptation

Les tests d’acceptation sont réalisés par ceux qui ont exprimé le besoin.

Ce niveau de test relève donc de la responsabilité du Client qui a commandé le produit logiciel ou les utilisateurs qui vont le manipuler.

L’objectif principal des tests d’acceptation n’est pas de trouver des défauts comme le sont les tests système.

L’objectif des tests d’acceptation est d’acquérir de la confiance dans le système en validant qu’il est utilisable et qu’il correspond bien au besoin initial et aux attentes fonctionnelles et non fonctionnelles exprimées.

Si le système fonctionne seul, Les tests d’acceptation sont le dernier niveau de test avant le déploiement dans l’environnement des utilisateurs finaux.

Si le système n’est qu’une brique d’une série d’application interconnectées, Les tests d’acceptation peuvent être suivis de tests d’intégration système pour vérifier qu’il interagit bien avec les autres applications avec lesquels il est sensé communiquer.

4. Les tests d’acceptation

Un client peut valider le produit à plusieurs niveaux de test.

• Il peut faire des tests d’acceptation pour un composant sur étagère « acheté clé en main » quand il est installé ou intégré à un système existant.
• Les tests composants qui sont d’habitude de la responsabilité des développeurs peuvent inviter les utilisateurs pour confirmer que le fonctionnement spécifié du composant est facilement utilisable comme prévu. Impliquer le client ou les utilisateurs aussi tôt permet de s’assurer que la conception satisfait bien ce client et ces utilisateurs au fur et à mesure de l’avancement des développements, et de rectifier tout problème au plus tôt.
• Les tests d’acceptation d’une évolution importante peuvent être tests avant les tests système.

Tests d’acceptation utilisateur

Ces tests valident l’utilisabilité du système càd son ergonomie et sa facilité d’utilisation comme par exemple si la navigation dans l’application est intuitive.

Les tests d’acceptation opérationnels

• Les test de backups et restauration : ce sont des tests qui visent la capacité du système à sauvegarder les données et les restaurer
• La reprise après sinistre : ce sont des tests qui vérifient que l’application réagit bien après un évènement exceptionnel comme une coupure de courant, une panne de réseau etc..
• La gestion des utilisateurs : Les utilisateurs peuvent avoir des rôles différents et des habilitations plus ou moins importantes
• Tâches de maintenance : le logiciel peut être plus ou moins facile à maintenir, selon la conception du logiciel introduire une évolution peut avoir des repercutions. Si le système est complexe et mal conçu, introduire une évolution peut avoir des impacts indésirables sur des parties qui fonctionnaient bien jusque-là. Ce manque de maintenabilité peut mener vers des régressions dans système.
• Chargement des données et tâches de migration : dans les projets de migration, un système A peut être remplacé par un système B ce qui fait hériter le système B des données contenus dans le système A. Des tests sont nécessaires pour valider que les données sont bien récupérées sans omission, altération et sans doublons en respectant le schéma de données du nouveau système.
• Les tests de sécurité sont des tests qui deviennent de plus en plus importants et ils peuvent être périodiquement réalisés dans le niveau d’acceptation opérationnelle.

Tests d’acceptation contractuelle et réglementaire

Les tests d’acceptation contractuelles sont liés à un contrat qui gère les modalités de fabrication d’un logiciel sur mesure. Pendant ces tests d’acceptation, on vérifie que les caractéristiques définis dans le contrat ont été respectés.

Les tests d’acceptation réglementaires sont réalisés pour vérifier la conformité à des exigences réglementaires liées à un pays, au secteur d’activité, ou d’autres obligations légales.

Tests alpha et beta

Les éditeurs d’outils logiciels souhaitent souvent tester leurs applications à une échelle qui s’approche le plus possible des conditions réelles d’utilisation avant de les commercialiser.

Les tests Alpha sont réalisés par des gens qui n’ont pas developpé l’application mais qui sont dans la même entreprise que les développeurs

Les tests Béta sont réalisés par des personnes externe à l’entreprise comme des clients et des utilisateurs.

Les tests qui sont fait sur le site du fabriquant peuvent être appelé :

• des test d’acceptation usine
• ou des tests d’acceptation sur site.