1. Les bases du test logiciel
| Terme | Définition simple |
|---|---|
| QA | Quality Assurance. Démarche pour garantir la qualité d’un logiciel. |
| Testeur QA | Personne qui vérifie qu’une application fonctionne correctement. |
| Test logiciel | Action de vérifier qu’un logiciel respecte les attentes. |
| Anomalie / Bug | Problème constaté dans l’application. |
| Erreur | Mauvaise action humaine, souvent côté développeur ou conception. |
| Défaut | Problème présent dans le code ou dans la conception. |
| Défaillance | Quand le problème apparaît réellement à l’écran ou à l’utilisation. |
| Exigence | Besoin attendu par le client ou l’utilisateur. Exemple : “l’utilisateur doit pouvoir se connecter”. |
| Critère d’acceptation | Condition précise qui permet de dire qu’une fonctionnalité est réussie. |
| Recette | Phase où l’on vérifie que l’application est conforme aux besoins métier. |
2. Documents et livrables QA
| Terme | Définition simple |
|---|---|
| Plan de test | Document qui explique quoi tester, comment, avec quels moyens et dans quel ordre. |
| Stratégie de test | Vision globale des tests à réaliser sur un projet. |
| Cas de test | Scénario précis à exécuter pour vérifier une fonctionnalité. |
| Scénario de test | Suite d’actions représentant une situation utilisateur. |
| Jeu de données | Données utilisées pour tester. Exemple : email valide, mot de passe invalide. |
| Cahier de recette | Ensemble des tests à réaliser pendant la recette. |
| Rapport de test | Bilan des tests exécutés : réussis, échoués, bloqués, anomalies trouvées. |
| PV de recette | Procès-verbal confirmant que la recette est acceptée ou refusée. |
| Matrice de traçabilité | Tableau reliant exigences, cas de test et anomalies. |
3. Types de tests
| Terme | Définition simple |
|---|---|
| Test fonctionnel | Vérifie que la fonctionnalité marche selon le besoin métier. |
| Test non fonctionnel | Vérifie la performance, sécurité, accessibilité, compatibilité, etc. |
| Test manuel | Test exécuté à la main par un testeur. |
| Test automatisé | Test exécuté par un script ou un outil. |
| Test unitaire | Test d’un petit morceau de code, souvent fait par les développeurs. |
| Test d’intégration | Vérifie que plusieurs composants fonctionnent bien ensemble. |
| Test système | Test de l’application complète. |
| Test de régression | Vérifie qu’une modification n’a pas cassé l’existant. Très important. |
| Smoke test | Test rapide pour voir si l’application est suffisamment stable pour être testée. |
| Sanity test | Vérification rapide après une correction ou une petite modification. |
| Test exploratoire | Test libre où le testeur explore l’application sans script détaillé. |
| Test d’acceptation | Vérifie que le produit est acceptable pour le client ou le métier. |
| UAT | User Acceptance Testing. Tests d’acceptation réalisés côté utilisateur ou métier. |
| Test de performance | Vérifie la rapidité et la stabilité de l’application sous charge. |
| Test de sécurité | Vérifie les failles possibles : accès non autorisé, injection, données sensibles. |
| Test de compatibilité | Vérifie le fonctionnement sur plusieurs navigateurs, appareils ou OS. |
4. Techniques de test
| Terme | Définition simple |
|---|---|
| Boîte noire | Tester sans connaître le code interne. Tu testes comme un utilisateur. |
| Boîte blanche | Tester en connaissant le code interne. |
| Boîte grise | Mélange des deux : tu as quelques infos techniques, mais pas tout. |
| Classe d’équivalence | Regrouper des données similaires pour éviter de tout tester. |
| Valeur limite | Tester les limites. Exemple : minimum, maximum, juste avant, juste après. |
| Table de décision | Tableau utilisé quand plusieurs conditions donnent plusieurs résultats. |
| Transition d’état | Tester les changements d’état. Exemple : commande “créée”, “payée”, “annulée”. |
| Test positif | Vérifier que l’application fonctionne avec des données valides. |
| Test négatif | Vérifier que l’application réagit correctement avec des données invalides. |
5. Anomalies et tickets
| Terme | Définition simple |
|---|---|
| Ticket | Fiche créée dans un outil comme Jira pour suivre une tâche ou une anomalie. |
| Rapport d’anomalie | Description structurée d’un bug. |
| Étapes de reproduction | Actions permettant de retrouver le bug. |
| Résultat attendu | Ce qui aurait dû se passer. |
| Résultat obtenu | Ce qui s’est réellement passé. |
| Sévérité | Niveau d’impact du bug sur l’application. |
| Priorité | Urgence de correction du bug. |
| Bloquant | Bug qui empêche de continuer les tests ou d’utiliser une fonction essentielle. |
| Mineur | Bug peu gênant, souvent visuel ou sans gros impact. |
| Critique | Bug très grave, souvent lié à une perte de données, paiement, sécurité, connexion impossible. |
| Rejeté | Bug refusé car non valide, déjà connu ou pas reproductible. |
| Corrigé | Le développeur a fait une correction. |
| Retest | Le testeur vérifie qu’un bug corrigé est bien résolu. |
| Non reproductible | Le bug ne peut pas être reproduit avec les informations données. |
6. Environnement et cycle de vie
| Terme | Définition simple |
|---|---|
| Environnement de développement | Zone utilisée par les développeurs. |
| Environnement de test | Zone où les testeurs vérifient l’application. |
| Préproduction / Préprod | Environnement proche de la production. |
| Production / Prod | Version réellement utilisée par les utilisateurs. |
| Build | Version compilée ou livrée de l’application. |
| Release | Version officielle livrée aux utilisateurs. |
| Versioning | Gestion des versions d’un logiciel. |
| Déploiement | Mise en place d’une nouvelle version sur un environnement. |
| Rollback | Retour à une version précédente en cas de problème. |
7. Agile, Scrum et projet
| Terme | Définition simple |
|---|---|
| Agile | Méthode de travail par petites étapes régulières. |
| Scrum | Cadre Agile très utilisé en entreprise. |
| Sprint | Période courte de travail, souvent 1 à 3 semaines. |
| User story | Besoin utilisateur écrit simplement. Exemple : “En tant qu’utilisateur, je veux me connecter…” |
| Backlog | Liste des choses à faire sur le projet. |
| Product Owner / PO | Personne qui priorise les besoins métier. |
| Scrum Master | Personne qui aide l’équipe Scrum à bien fonctionner. |
| Daily meeting | Réunion courte quotidienne de l’équipe. |
| Sprint planning | Réunion de préparation du sprint. |
| Sprint review | Réunion de présentation du travail terminé. |
| Rétrospective | Réunion pour améliorer la façon de travailler. |
| Definition of Done / DoD | Liste des conditions pour dire qu’une tâche est vraiment terminée. |
8. Outils fréquents
| Terme | Définition simple |
|---|---|
| Jira | Outil de suivi des tâches, bugs et projets Agile. |
| Confluence | Outil de documentation souvent utilisé avec Jira. |
| Xray | Extension Jira pour gérer les tests. |
| TestRail | Outil de gestion de cas de test. |
| Squash TM | Outil de gestion des tests très utilisé en France. |
| Postman | Outil pour tester les API. |
| Playwright | Outil d’automatisation de tests web. |
| Selenium | Outil connu pour automatiser les tests web. |
| Git | Outil de gestion de code source. |
| GitLab / GitHub | Plateformes pour héberger du code et gérer des projets. |
| CI/CD | Automatisation des tests, builds et déploiements. |
9. API et web
| Terme | Définition simple |
|---|---|
| API | Interface qui permet à deux systèmes de communiquer. |
| Endpoint | Adresse précise d’une API. |
| Requête | Demande envoyée à une API ou un serveur. |
| Réponse | Ce que le serveur renvoie. |
| GET | Méthode API pour récupérer des données. |
| POST | Méthode API pour créer des données. |
| PUT | Méthode API pour remplacer/modifier complètement une donnée. |
| PATCH | Méthode API pour modifier partiellement une donnée. |
| DELETE | Méthode API pour supprimer une donnée. |
| Code HTTP 200 | Succès. |
| Code HTTP 400 | Mauvaise demande côté utilisateur/client. |
| Code HTTP 401 | Non authentifié. |
| Code HTTP 403 | Accès interdit. |
| Code HTTP 404 | Ressource introuvable. |
| Code HTTP 500 | Erreur serveur. |
| JSON | Format de données très utilisé dans les API. |
10. Automatisation de test
| Terme | Définition simple |
|---|---|
| Script de test | Code qui exécute automatiquement un test. |
| Sélecteur | Élément utilisé pour cibler un bouton, champ ou lien dans une page web. |
| Assertion | Vérification dans un test automatisé. Exemple : vérifier qu’un message apparaît. |
| Fixture | Préparation commune avant les tests. Exemple : ouvrir le navigateur, se connecter. |
| Headless | Exécution d’un test sans afficher le navigateur. |
| Headed | Exécution d’un test avec navigateur visible. |
| Test flaky | Test instable qui réussit parfois et échoue parfois sans raison claire. |
| Pipeline | Chaîne automatisée qui peut lancer les tests à chaque modification du code. |
| Coverage / couverture | Pourcentage de code ou de fonctionnalités couvert par les tests. |