1) Planification

Situer les activités de tests dans la stratégie globale de livraison de l’application logicielle
Établir très clairement l’identification de l’application à tester ainsi que la version soumise aux tests

• S’assurer d’établir les canaux de communication afin de recevoirtous les informations pertinentes
• Analyses, spécifications, avis de changement, avis de complétude.
• Définir la portée des tests
• Les différents intervenants (individus, groupes, entreprises)
• Limites de la portée des tests
• Identifier les contraintes
• Budget
• Disponibilité des livrables
• Équipement
• Temps
• Formation manquante

Définir les objectifs du projet de test

• Assurer la sécurité, la performance, …
• Définir l’approche globale du projet de test
• Planification des différents types de tests qui seront utilisés
• Définir les critères d’acceptation et de suspension des tests
• Définir les environnements de tests utilisés
• Besoins particuliers (Réseau, BD, RAM)
• Configurer ou acquérir les outils de test
• Préparer le processus de gestion des anomalies
• Identifier les livrables
• Identifier les ressources impliquées (rôles et responsabilités)
• Produire la cédule des activités de test
• Identifier les risques et souligner les hypothèses

Établir la table de traçabilitédes éléments de test vers les documents de spécification et d’analyse
Le document de plan de test
–Le rédiger
–Le faire approuver
Très important:
–Définir les caractéristiques à tester
•Il s’agit departitionnerl’application à tester en un nombre raisonnable de fonctionnalités indépendantes
–Définir les caractéristiques qui ne seront pas testées

Problème

Premier problème
–«Comment systématiquement partitionner l’application à tester en une liste de caractéristiques à tester ?» 

Les phases de test

Il existe principalement quatre phases de test
–Tests unitaires
Valider le fonctionnement d’une pièce de logiciel en isolation
–Tests d’intégration
Valider l’interaction entre diverses composantes d’un système
–Tests système
Valider le comportement du système dans son ensemble
–Tests d’acceptation (normalement classés dans la catégorie : tests sur site -Fieldtesting)
Valider si le système satisfait les besoins initiaux du client

Concept du test en «V»
Inspiré de Pressman(1992)

En utilisant ce concept, le cycle de vie des tests logiciels consiste à exécuter des tests en s’inspirant des différents niveaux d’abstraction du cycle complet du développement.

On s’intéresse à l’ensemble des défauts

Défauts de spécification, d’analyse, de code
–Permet de détecter très tôt les anomalies
Chaque phase de test valide une portion différente du développement.
–Ce processus de test ne peut exister en l’absence d’un cycle de développement structuré, car dans ce cas, le concept du test en «V» devient inefficace (difficile de valider la bonne portion du développement)
–Par cette approche, le processus de test devient dépendant de lacomplétude des artefacts du cycle de développement
–Avec cette approche, le besoin d’indépendance de l’équipe de test est évident. Il y aurait redondance et la couverture de test serait plus étroite s’il s’agissait des mêmes ressources qui analysent et qui valident (testent) l’application

Résultat final de la planification

Le problème à été partitionné
–Les sous-problèmes sont plus faciles à appréhender
Aucune des caractéristiques documentées n’est oubliée
Le document de plan de test regroupe ces informations en plus des informations organisationnelles 

2) Conception
(s’inspirant de la norme IEEE 829)

1. Rédiger tous les cas de test
2. Établir la table de traçabilité des cas de test vers les documents de spécification et d’analyse
3. Faire réviser et approuver les cas de test
4. Préparer les outils et environnements de test
5. Mettre en place le processus d’archivage
6. Mettre en place la gestion des fichiers de test et des librairies de test
7. Obtenir et installer l’application à tester

Cas de test

Un cas de teste st développé pour tester un objectif bien précis du logiciel.

Un cas de test comporte:
–Des instructions pour préparer
–Des instructions pour exécuter
–Des données d’entrée
–Des conditions d’exécution
–Le résultat attendu/ critère de Succès ou d’Échec
–On retrouve souvent un espace réservé afin de noter le résultat lors de l’exécution du cas de test
La plupart du temps, plusieurs cas de tests destinés àvérifier un même objectif de test sont regroupés dans un scénario de test
–On peut alors dire que chaque cas de test constitue une étape dans le déroulement du scénario

Exemple simplifié d’un cas de test :préparer un fichier d’importation contenant 100 dossiers clients (voir instructions A1), importer les dossiers clients (voir instructions I2). 

Visualiser les dossier clients à l’aide de l’application et vérifier que les dossiers erronés ont été rejetés

Problème

• «Comment établir systématiquement les différents cas de test ?»
• Ou «Comment identifier tous les angles différents pour chaque caractéristique à tester ?»
• Ou «Relativement aux tests, comment identifier le domaine réalisablede chaque caractéristique à tester ?»

Les différents angles de test

Supposons qu’il existe un meta procédure de test qui explore tous les angles d’une meta application

Inspiré de Open-Source Security Testing Methodology Manual (OSSTMM) 2.1.

Domaine réalisable de test

Certains auteurs et organismes élaborent de tels domaines réalisables de test
–Par spécialité
–Par exemple, l’Institute for Security and Open Methodologies(ISECOM), propose plusieurs angles de test concernant la sécurité
On peut transposer ces différents angles de test dans un arbre de domaine réalisable de test (comme dans l’acétate précédente)
Avec un peu de recherche, on peut trouver des domaines réalisables de test pour différentes spécialités.
On peut alors utiliser les différents domaines réalisables de 3 façons (selon les besoins)

a) Tels quels.Chaque fois qu’il faut bâtir de nouvelles procédures de test, on consulte les documents originaux illustrant les différents angles de test.
b) Au sein de son entreprise, créer son propre domaine réalisableen combinant les domaines réalisablesen un seul. Celui-ci devient alors la référence de base pour toutes nouvelles procédures de test
c) Idem + ajouter des angles de test sur des composantes logicielles uniques à sa propre entreprise. Ce domaine réalisable de test permet alors à un apprenti de rédiger rapidement de bonnes procédures de test

Appliquer le domaine

Pour un projet de test en particulier, un sous-ensemble du domaine réalisable de test est utilisé et concrétisé en procédures de test

Types de test

Il existe différents types de test:
Regression testing(tests de régression)
–Tests conçus pour vérifier qu’un changement implanté n’affecte pas des parties inchangées dans le système.
Error-handling testing(tests de gestion d’erreur)
–Tests conçus pour déterminer l’habilité du système à traiter unetransaction incorrecte.
Manual-support testing(tests de support manuel)
–Tests conçus pour déterminer que l’interaction personne-ordinateur fonctionne correctement. Tests réalisés sur la partie non automatique du système (manuelle).
Intersystems testing(tests inter-système)
–Tests conçus pour déterminer la communication de données entre deux systèmes
Control testing (tests de contrôles)
–Tests conçus pour déterminer si le niveau de contrôle du systèmeréduit le niveau de risques du système.
–Contrôle = validation des données, trace, backup, audit, etc.
Parallel testing(tests parallèles)
–Tests se déroulant sur l’ancien et sur le nouveau système pendant une même période de temps pour identifier les différences possibles entre les deux systèmes.
Comparison testing(tests de comparaison)
–Tests conçus pour comparer les forces et les faiblesses par rapport à un produit compétiteur
Usability testing(tests de maniabilité)
–Tests conçus pour évaluer les facteurs humains, l’esthétique, laconsistance et la documentation. Évalue la facilité d’apprentissage, d’opération, de préparation et d’interprétation des données par un utilisateur. Ces tests sont subjectifs.
Smoke testing(tests de qualification)
–Tests conçus pour évaluer que toutes les fonctions d’un build opèrent convenablement avant de continuer les tests. Évalue la qualité du produit avant de passer aux tests intégrés ou de système.
Sanity testing(tests de santé)
–Tests conçus pour évaluer la qualité d’une livraison avant d’être envoyé au client. Évalue les opérations sur les scénarios normaux avec des données normales. Vérifie si la livraison est saine.
End-to-end testing(tests de bout en bout)
–Similaire à un test système. Implique de tester une application complète dans une situation semblable au monde réel telle que l’interaction avec des bases de données, le réseau et autres interfaces ou systèmes
Install / Uninstall testing (tests d’installation / désinstallation)
–Tests conçus pour vérifier une installation et désinstallation complète ou partielle ou une mise à jour

Ad-hoc testing (tests ad-hoc / monkey test)
–Tests créatifs et informels non basés sur un plan ou cas de test. Le testeur apprivoise et apprend le système durant l’exécution de ces tests. Tests aléatoires basés sur la probabilité de trouver une erreur.
–Utile pour déterminer si un module est prêt à être tester formellement ou à la fin d’un projet. Il sert à briser les habitudes séquentielles et la mécanique d’exécution en utilisant une ressource différente ayant une vision et une approche différente.
Exploratory testing(tests exploratoires)
–Similaire au test ad-hoc à l’exception que le testeur connaît le système. Les tests sont orientés mais informels. Chaque étape est analysée afin de déterminer la prochaine.
–On cherche des indices de mauvais fonctionnement ou de comportement suspect et ce afin de se faire un chemin vers une faute latente.

Stress testing(tests de stress)
–Tests conçus pour déterminer si le système peut fonctionner avecun large volume -plus large que normalement attendu.
–Les zones de stress incluent : transactions, tables internes, espace disque, données de sorties, données d’entrées, communication, capacités de l’ordinateur, interaction avec les ressources, etc.
–On assure de pouvoir traiter x transactions par minute, mais jusqu’où le système peut-il en accepter? Documenter le point de rupture.
Load testing(tests de volume)
–Test utilisé pour assurer que le système fonctionne correctementavec les volumes d’entrée spécifiés. Ce test détermine si le système a la capacité de manipuler des volumes larges. Par exemple, dans une application d’achat en ligne créer une liste d’achats d’une centaine d’articles, une liste d’usagers et de mots de passe contenant plusieurs dizaines de milliers d’entrées, simuler le vieillissement de l’application en générant une grande quantité de données journalières
Performance testing(tests de performance)
–Tests conçus pour vérifier le niveau de performance du système dans un contexte comme : la vitesse d’opération, le temps réponse, lavitesse de communication, le temps de traitement d’une transaction, etc.

Recovery testing (tests de récupération)
–Tests conçus pour déterminer si le système peut retourner dans un statut opérationnel après une défaillance ou perte d’intégrité.
Operation testing(tests opérationnels)
–Tests conçus pour vérifier avant la mise en production que les procédures opérationnelles sont claires et que les ressources peuvent exécuter l’application sans problème
–Observations libres de la part des utilisateurs
–Collecter les commentaires de façon non officielle
–Sondage de maniabilité auprès des utilisateurs
–Utiliser un questionnaire
–Tests bêta (attention à la mauvaise publicité pouvant survenir lors d’une activité de Tests bêta)
–Avant le déploiement officiel, donner en exclusivité l’accès à l’application Web à un groupe d’usagers visés

Compatibility testing(tests de compatibilité)
–Tests conçus pour vérifier la compatibilité avec une composante mécanique, logicielle, réseau, interface, environnement, etc.
–Laboratoire équipé des différents environnements
–Prendre garde de ne pas altérer les environnements pendant les tests
–Difficulté d’obtenir les composantes représentant les environnements plus anciens
–Obtenir une ancienne version de fureteur
–Obtenir une ancienne version de système d’exploitation
–Tests bêta: demander aux usagers visés par les tests bêta de communiquer les problèmes de compatibilité
Compliance testing (tests de conformité)
–Tests conçus pour déterminer l’adhérence à des normes, procédures ou guide.
Security testing (tests de sécurité)
–Tests conçus pour déterminer si le système est protégé selon le niveau d’importance des données

Conclusion
Finalement, la réponse à la question initiale:
–«Comment identifier tous les angles différents pour chaque caractéristique à tester ?»

Résumé de la méthode

1. Partitionner l’application à tester quelques caractéristiques à tester selon l’angle de tests d’acceptation, systèmes, d’intégration et de tests unitaires
2. Pour chaque caractéristique à tester, se référer à un domaine réalisable générique de test afin de générer les cas de test selon plusieurs angles différents
3. Pour chaque cas de test, choisir un ou plusieurs types de test
   Domaine réalisable générique

3) Exécution

• Exécuter les tests selon le plan et les procédures de test
• Effectuer la formation requise
• Rapporter les résultats

4) Observation

• Évaluer, analyser de documenter les résultats
• Vérifier le statut de complétude du projet de test
• Évaluer les résultats obtenus selon les objectifs
• Rédiger le rapport de test

Contenu du document de Rapport de test (s’inspirant de la norme IEEE 829)

Synthèse des résultats des tests exécutés sur le système ou sur une de ces composantes
Liste des anomalies connues classées par sévérité
Évaluation du risque actuel du système testé
Métriques pertinentes
On devrait pouvoir diffuser le rapport à un vaste auditoire
–Le rapport est rédigé afin d’être facile à comprendre
–Doit être brefmais complet
–Pointer sur les autres documents pertinents pour le lecteur désirant plus d’informations
•Référence vers les résultats détaillés de test
Amélioration du processus de test/développement

Q: À quels groupes est destiné le rapport de test ?

5) Correction

Recueillir et suivre les anomalies détectées suite à l’exécutiondes tests
Effectuer les tests de régression (ou de non-régression)
Mettre à jour tous les documents produits dans le cadre du projet de test
Évaluer le projet de test qui vient d’être completé (post-mortem)
Effectuer des activités d’amélioration continue des processus
–Améliorer le processus de test
–Ajuster les métriques
–Améliorer le processus de développement
•Il ne faut pas s’en tenir à détecter des problèmes, il faut agirpour éviter d’avoir à les détecter à nouveau dans le prochain projet de test

1) Planification
2) Conception
3) Exécution
4) Observation
>5) Correction