Tests en développement logiciel

Généralités sur les tests

• Les tests sont un ensemble de procédures visant à assurer la conformité d'un système.
• Ils garantissent un niveau de qualité.
• Les tests fonctionnels évaluent les éléments en fonction des besoins, assurant la conformité aux attentes de l'utilisateur final.
• Les tests non fonctionnels concernent les aspects techniques.
• Le test structurel vérifie directement le code.

Le cycle de vie du projet

• Un projet est un ensemble d'activités coordonnées et maîtrisées pour atteindre un objectif précis, avec une date de début et de fin.
• Le besoin correspond aux attentes du client ou des utilisateurs, exprimé de manière claire sans interprétation.
• Un jalon est un événement important dans la réalisation d'un projet, nécessitant un contrôle (ex: livraison d'un livrable ou clôture d'une phase).
• Le cycle de vie d'un projet représente la succession des phases de passage d'un besoin à un système en service.
• Le cahier des charges est un document contractuel exprimant les attendus du projet.

Les équipes d'un projet

• Le cadrage définit le projet.
• Le développement produit le système.
• La qualification valide le système par des tests.
• La livraison client met le système à disposition.
• La recette vérifie le système sur la base des besoins.
• La mise en production met le système fonctionnel en ligne.

Le développeur et le testeur

• Les développeurs écrivent le code, réalisent les tests unitaires et d'intégration, et déboguent.
• Les testeurs trouvent les cas du logiciel, vérifient la cohérence globale, anticipent les problèmes et accordent une grande importance au détail.
• La collaboration entre développeurs et testeurs est essentielle pour améliorer la qualité globale du logiciel.
• Les développeurs effectuent souvent des tests orientés sur le code qu'ils connaissent.
• Les testeurs effectuent les tests en fin de chaîne.

Le test dans un projet

• Les tests sont présents tout au long du cycle de vie du projet (cadrage, réalisation, tests, production).
• Chaque phase comprend des activités spécifiques de test.

Pourquoi tester ?

• Les logiciels sont intégrés dans notre vie quotidienne.
• Les logiciels mal fonctionnels peuvent occasionner des pertes financières, de temps et de réputation, et même des blessures ou la mort.
• Les tests logiciels permettent d'évaluer la qualité du logiciel et de réduire les risques.

Les conséquences d'un logiciel défectueux - exemples

• Financières : décalage de salaires, erreurs de paiement en ligne.
• Image : impossibilité de déclaration pour des personnes en raison de problèmes de serveur.
• Personne : irradiations excessives suite à un scanner défectueux, accidents d'automobile.
• Environnement : utilisation excessive de pesticides avec problèmes de pulvérisation, rejets toxiques de gaz d'échappement suite à un mauvais réglage.

Pourquoi tester (en détails) ?

• Une erreur courante est de considérer que tester se résume à exécuter et vérifier les résultats.
• Le processus de test inclus : planification, analyse, conception, mise en œuvre, suivi et évaluation de la qualité des tests.
• Une autre perception erronée est qu'il se concentre uniquement sur les exigences.
• Les tests permettent de s'assurer que le système répond aux besoins des utilisateurs et des parties prenantes.

Les cycles de développement

• Différents modèles existent (Cascade, V, Incrémental, Itératif) en fonction des spécificités du projet.
• Cascade : chaque phase doit se terminer avant le début de la phase suivante.
• V : le processus de test est lié à chaque étape du développement.

Définitions : test (non) fonctionnel

• Test fonctionnel : évaluer en fonction du besoin pour valider les attentes de l'utilisateur final.
• Test non fonctionnel : concerne les aspects techniques du logiciel.
• Test structurel : vérifie directement le code.

Les différentes techniques de tests

• Les facteurs influençant le choix des techniques : type du système, complexité, règlement en vigueur, exigences règlementaires, compétences des testeurs, risques, objectifs du test, documentation, outils disponibles...
• Modèle de cycle de vie de développement logiciel, utilisation prévue du logiciel, expériences précédentes, types de défauts.

Boîte noire et boîte blanche

• Boîte noire : ignore l'implémentation pour valider la fonctionnalité par rapport aux besoins des utilisateurs (ex: la voiture fonctionne).
• Boîte blanche : considère le code pour tester les mécanismes internes.

L'expérience

• Dans certains cas, les cas de test et les données sont basés sur les connaissances et l'intuition du testeur.
• Les testeurs utilisent leur expérience pour identifier les zones potentiellement défectueuses.
• Les tests exploratoires permettent de découvrir des anomalies.

La boîte noire - partie d'équivalence

• Identifier les partitions de valeurs valides et invalides en entrée et sortie.
• Créer des cas de test.
• Tester une donnée dans chaque partition.

La boîte noire - valeurs limites

• Utiliser les valeurs minimum et maximum des partitions pour repérer les défauts potentiels.
• Tester des valeurs "juste en dessous", "sur" et "juste au dessus" de la limite.

La boîte noire - transitions d'états

• Un système peut se comporter différemment à partir de ses états.
• Les tests de transitions d'états permettent d'identifier les transitions invalides.
• Tableaux d'états et transitions.

La boîte noire - cas d'utilisation

• Chaque cas d'utilisation décrit le comportement d'un acteur vis-à-vis du système.
• Pré-conditions, étapes et résultats attendus.

Les types de tests (TNR)

• Non régression : permet de vérifier qu'une modification ne casse pas des fonctionnalités existantes.
• Unitaire : vérifier un composant de manière isolé.
• Intégration : vérifier l'intégration d'un composant dans le système.
• Performance : vérifier la performance du système.
• Acceptation : vérifier la conformité au besoin du client.

Erreurs, défauts et défaillances

• Une erreur humaine peut générer un défaut qui peut entraîner une défaillance du logiciel.
• Identifier la cause racine des défauts pour améliorer les processus et réduire les défaillances.

Les 7 grands principes

• Exhaustivité : les tests ne peuvent pas être exhaustifs.
• Regroupement : les erreurs sont souvent regroupées.
• Contexte : les tests dépendent du contexte, des données et de l'environnement.
• Temps : tester tôt pour réduire les coûts ultérieurs.
• Pesticides : exécuter plusieurs fois le même cas de test ne suffirait pas pour trouver les problèmes.
• Illusion: croire à l'absence d'erreur seulement parce qu'aucun bug n'est trouvé durant le processus de test.

Les critères d'entrée

• Condition requise pour commencer une activité de test.
• Vérifier la disponibilité des ressources, de l'environnement...

Les critères de sortie

• Conditions qui doivent être satisfaites pour valider l'activité de test.
• Contrôler l'état du projet lors de la sortie.

Les paramètres dans les cas de tests

• Les paramètres sont des variables qui peuvent prendre différentes valeurs pour tester divers scénarios avec le même cas de test.
• Ils rendent les cas de test plus flexibles et réutilisables.
• Ils sont utilisés pour la réduction de la redondance, la couverture étendue, la maintenance simplifiée et la clarté.
• Ils peuvent aussi ajouter de la complexité, rendre le débogage plus difficile et impacter les performances, ainsi que la maintenance.
• Exemple : Nom utilisateur, mots de passe, etc.

Plan de tests

• Un plan de test valide la couverture du périmètre fonctionnel.
• Il contient les cas de tests fonctionnels nécessaires.
• Il définit les objectifs pour identifier les scénarios et les prioriser.
• Son périmètre peut être associé à une version de l'application
• Il est rédigé dès la définition du périmètre.

Construction d'un plan de tests

• Le plan de test fait référence aux SFD, SFG, cas d'usage et stratégie de test.
• Il faut comprendre l'existant pour savoir comment tester l'ajout, les écarts, et les différents scénarios.

La priorité

• Tous les scénarios de tests ne peuvent pas être exécutés.
• Il est important de prioriser ceux qui ont le plus fort impact sur l'utilisateur.
• Les critères de priorisation : fréquence, impact utilisateur, risque, probabilité, conséquences financières.

Le calendrier

• Le calendrier d'exécution doit considérer la priorité.
• Les dépendances entre les cas de test.
• Les tests de non-régression.
• La séquence la plus efficace.

L'effort de tests

• Prioriser les tests est crucial pour estimer l'effort.
• Facturer qui influence l'effort de tests: les caractéristiques d'un produit, les risques, la qualité de base, la taille du produit, la complexité du domaine métier, les exigences, le niveau de détail de la documentation, la conformité aux lois, les personnes impliquées (compétence et expérience), la cohésion et le leadership de l'équipe, les caractéristiques du processus de développement, la stabilité de l'équipe, l'approche de développement, les outils utilisés, la pression des délais, les résultats de tests (nombre et sévérité des défauts trouvés, travail à refaire) et les métriques.
• Techniques pour estimer l'effort : basée sur les métriques (anciens projets similaires) et basée sur l'expertise.
• Les métriques peuvent déterminer la complexité de chaque test (nombre de cas de tests, nombre de RG).

Cas pratique - exemples

• Exemple de gestion de garage: définir les cas de test.
• Exemple de gestion de bibliothèque : définir des tests de non régression pour une nouvelle fonctionnalité (réserver des livres).