Quelle documentation de test existe-t-il?

La documentation de test inclut des artefacts utilisés à différentes étapes des tests. Les principaux types :

• Politique de test (Test Policy) : Document de haut niveau définissant les objectifs, approches et principes des tests dans l'organisation.
• Stratégie de test (Test Strategy) : Document plus détaillé décrivant le plan général de test pour un projet ou produit spécifique, couvrant le périmètre, les ressources, le calendrier et les méthodes.
• Plan de test (Test Plan) : Document décrivant en détail les actions spécifiques de test pour une itération ou une version donnée. Inclut :
  • Objectifs et buts des tests.
  • Périmètre des tests (ce qui est testé, ce qui ne l'est pas).
  • Critères d'entrée et de sortie.
  • Types de tests.
  • Environnement de test.
  • Rôles et responsabilités.
  • Calendrier.
  • Gestion des risques.
  • Critères pour suspendre et reprendre les tests.
• Scénario de test / Cas de test (Test Case) : Document décrivant des étapes spécifiques pour réaliser un test déterminé, avec le résultat attendu.
• Liste de vérification (Checklist) : Liste de points ou fonctionnalités à vérifier sans description détaillée des étapes. Utilisée lorsque les étapes sont évidentes ou ne nécessitent pas de formalisation.
• Suite de tests (Test Suite / Test Set) : Collection de cas de test regroupés selon un critère déterminé (par exemple, par fonctionnalité ou type de test).
• Rapport de bug / Rapport de défaut (Bug Report / Defect Report) : Document décrivant une erreur trouvée, incluant les étapes pour la reproduire, les résultats actuels et attendus, l'environnement et la criticité.
• Rapport d'exécution de test (Test Execution Report) : Document résumant les résultats de l'exécution des tests, incluant le statut de réussite/échec des cas, le nombre de bugs trouvés et le progrès global.
• Rapport de clôture de test (Test Closure Report) : Document résumant l'ensemble des efforts de test, incluant le statut final, les leçons apprises et les recommandations.
• Matrice de traçabilité (Traceability Matrix) : Document liant artefacts de test et exigences, aidant à assurer que toutes les exigences sont couvertes par des tests.

Exemple de structure d'un cas de test simple :

Champ	Description
ID du cas de test	Identifiant unique
Nom du cas de test	Brève description du scénario
Objectif du cas de test	Ce qui est vérifié
Préconditions	Conditions nécessaires avant l'exécution
Étapes d'exécution	Séquence d'actions
Résultat attendu	Résultat attendu
Postconditions	État du système après l'exécution

Exemple de rapport de défaut simple :

Champ	Description
ID du défaut	Identifiant unique
Brève description	Résumé du problème en une phrase
Projet / Module	Où l'erreur a été trouvée
Version du produit	Version où l'erreur a été trouvée
Environnement	OS, navigateur, configurations
Étapes pour reproduire	Séquence d'actions pour reproduire l'erreur
Résultat factuel	Ce qui s'est passé
Résultat attendu	Comment cela aurait dû être
Gravité	Impact sur la fonctionnalité (Blocker, Critical, Major, Minor, Trivial)
Priorité	À corriger rapidement ou non (High, Medium, Low)
Auteur du défaut	Qui a trouvé l'erreur
Date de création
Statut	(Nouveau, Ouvert, En cours, Résolu, Fermé, Réouvert)
Assigné à	Développeur, responsable

# Exemple de code pour automatiser un cas de test (extrait)
def test_user_login_successful():
    # Étapes préliminaires
    login_page.open()
    login_page.enter_username("valid_user")
    login_page.enter_password("valid_password")
    
    # Étape d'exécution
    login_page.click_login_button()
    
    # Vérification du résultat attendu
    assert home_page.is_dashboard_displayed()
    # Postconditions (par exemple, déconnexion)
    home_page.logout()

# Exemple de commande pour exécuter un ensemble de tests automatisés
pytest tests/smoke_tests.py

La documentation peut être à la fois formelle (créée selon des modèles) ou informelle, selon la méthodologie de développement et les exigences du projet.