01 — Les outils
La boîte à outils du testeur
Les logiciels cités ci-dessous sont donnés à titre indicatif pour illustrer chaque catégorie, pas à connaître par cœur pour l'examen.
Gestion de tests (TMSTest Management System)
Centralise les cas, plans, campagnes et résultats. Trace l'exigence → cas de test → exécution → anomalie.
Outils :
- TestRail
- Xray (Jira)
- Zephyr Scale
- qTest
- TestLink
- Squash TM
Bug tracking
Suivre le cycle de vie des anomalies, prioriser, mesurer.
Outils :
- Jira
- Azure DevOps
- Mantis
- Redmine
- GitHub Issues
- Linear
Gestion des exigences
Stocker les User Stories, exigences et critères d'acceptation. Base de la traçabilité.
Outils :
- Jira + Confluence
- Azure DevOps
- Polarion
- DOORS
Test d'APIApplication Programming Interface
Tester contrats, schémas, scénarios d'intégration côté serveur.
Outils :
- Postman / Newman
- REST Assured
- Karate
- SoapUI
Test UIUser Interface
Automatiser les parcours web (et mobile via Appium).
Outils :
- Cypress
- Playwright
- Selenium
- WebdriverIO
- Appium
Performance
Tests de charge, de stress, d'endurance...
Outils :
- k6
- JMeter
- Gatling
- Locust
- Artillery
Sécurité et qualité de code
Détection précoce des vulnérabilités.
Outils :
- OWASP ZAP
- Burp Suite
- SonarQube
- Snyk
- Dependabot
CI/CDContinuous Integration / Continuous Deployment
Orchestrer l'exécution automatique à chaque commit.
Outils :
- GitHub Actions
- GitLab CI
- Jenkins
- CircleCI
- Azure Pipelines
02 — Le cycle de vie
Le cycle de vie d'une campagne dans un outil de test
Hors syllabus FondationToujours les mêmes étapes : préparer le périmètre, planifier les exécutions, exécuter les cas, gérer les anomalies, puis clôturer avec un rapport clair et traçable.
Préparer
Définir le périmètre, les critères d'entrée, la stratégie. Créer / organiser les suites dans le TMSTest Management System.
Planifier
Construire la campagne : sélection des cas, environnement cible, version testée, testeur•ses assigné•es.
Exécuter
Marquer chaque cas "Réussi" / "Échec" / "Bloqué". Joindre captures, logs, requêtes réseau aux échecs.
Anomalies
Créer le ticket depuis le cas échoué : la liaison cas ↔ bug est automatique quand possible. Suivre puis retester au besoin.
Clôturer
Bilan de campagne : taux de réussite, anomalies ouvertes par sévérité, couverture exigences.
03 — Les outils
Focus sur les outils majeurs
Hors syllabus FondationUn comparatif rapide des outils que vous croiserez le plus souvent en mission ou en entretien. Aucun n'est universellement « le meilleur » ; chacun brille dans un contexte. Cliquez sur une carte pour voir le détail.
Jira + Xray
TMS intégré à Jira
Pour qui : Équipes déjà sous Jira, contexte Agile / SAFeScaled Agile Framework : cadre qui adapte les méthodes agiles aux grandes organisations avec plusieurs équipes.
+ Traçabilité native exigence ↔ cas ↔ bug. Couverture par story directement visible.
− Performances limitées sur très gros volumes, courbe d'apprentissage Jira.
TestRail
TMS dédié
Pour qui : Équipes mixtes manuel + auto, besoin d'un reporting riche.
+ UIUser Interface claire, plans / exécutions, APIApplication Programming Interface RESTRepresentational State Transfer : style d’architecture pour des API web utilisant les méthodes HTTP standards (GET, POST, PUT, DELETE...). complète, intégrations CIContinuous Integration.
− Lien avec Jira via plugin externe, pas natif comme Xray.
Zephyr Scale
TMS Jira (alternative)
Pour qui : Grosses organisations, beaucoup de cas réutilisables.
+ Hiérarchie de dossiers, paramétrage de cas, Gherkin natif.
− Concurrence directe avec Xray, choix souvent dicté par l'historique.
Postman
Test d'API
Pour qui : QA fonctionnels, devs back, tests d'intégration.
+ Collections, environnements, scripts JS, Newman pour la CI.
− Au-delà de 500 requêtes, organisation difficile sans discipline.
Playwright
Automatisation UI
Pour qui : Projets web modernes, multi-navigateur, équipes JS/TSJavaScript / TypeScript ou Python.
+ Auto-attente, génération de code, émulation mobile web (le natif passe par Appium).
− Plus jeune que Cypress, écosystème de plugins encore en croissance.
Cypress
Automatisation UI
Pour qui : Équipes front JS/TS, focus DXDeveloper Experience et debugging visuel.
+ Time-travel (rejeu des étapes), dashboard, snapshots, courbe d'apprentissage douce.
− Pas de support multi-onglets/multi-domaines natif, couverture navigateurs un peu plus étroite que Playwright.
SquashTM
TMS open source centré traçabilité
Pour qui : Équipes avec forte exigence de traçabilité, organisations publiques ou privées orientées open source.
+ Gestion centralisée exigences / cas / campagnes / anomalies, multi-projets, intégration Jira via Xsquash.
− Mise en place et administration plus techniques qu'un logiciel clé en main.
04 — Les différents outils
Les outils qui fonctionnent ensemble
Hors syllabus FondationPour couvrir tout le périmètre de test, ces outils se combinent en stacks cohérentes.
Jira + Xray + Cypress
Stack répandue : exigences et bugs dans Jira, cas et campagnes dans Xray, exécution automatisée Cypress publiée via l'API Xray.
GitHub + Playwright + Allure
Pipeline GitHub Actions, rapports Allure publiés en artefacts, badge de couverture commenté sur la PR.
Azure DevOps + Postman + k6
Tests API Newman sur chaque build, tests de perf k6 en nocturne, résultats poussés dans Azure Test Plans.
SquashTM + Jira
Exigences et anomalies gérées dans Jira, cas de test et campagnes centralisés dans Squash TM, synchronisation via Xsquash.
05 — Bonnes et mauvaises pratiques
Savoir différencier les bonnes et mauvaises pratiques
Hors syllabus FondationBonnes pratiques
- Une seule source de vérité par type d'information (exigence, cas, bug).
- Nommer les cas par intention métier, pas par étape technique.
- Lier systématiquement cas ↔ exigence ↔ anomalie.
- Limiter le nombre de statuts de bug. La complexité tue le suivi.
- Automatiser le reporting : un dashboard vivant plutôt qu'un bilan mensuel statique.
Mauvaises pratiques
- Maintenir des cas de test dans Excel ET dans le TMSTest Management System : double saisie, divergence garantie.
- Outil imposé sans formation : risque que l'outil disparaisse rapidement.
- Trop de champs obligatoires dans le rapport d'anomalie : personne ne les remplit correctement.
- Confondre TMSTest Management System et outil d'automatisation. Ils sont complémentaires.
- Acheter un outil pour résoudre un problème de processus.
A retenir
Ce qu'il faut retenir
Un socle minimal
Un outillage minimal doit couvrir les exigences, cas de test, anomalies et exécution (TMSTest Management System + bug tracking + CI/CDContinuous Integration / Continuous Deployment).
L'outil ne remplace pas le process
Les outils ne remplacent pas le process, mais rendent la traçabilité et le reporting fiables.
Simple et maîtrisé, plutôt que multiple
Mieux vaut un ensemble d'outils simple bien maîtrisé qu'une multitude d'outils mal utilisés.
Le bon outil dépend du contexte
Startup, grand compte régulé ou produit mobile n'auront pas la même combinaison d'outils.
Introduire un outil a son propre cycle
Sélection ou POC, pilote, déploiement, maintenance : à ne pas confondre avec le cycle d'une campagne présenté plus haut.
Mise en pratique
Testez votre compréhension
Une sélection de questions basées sur ce que vous venez de lire.
Que centralise un TMS (Test Management System) ?
Quelle est la première étape du cycle de vie d'une campagne de test ?
Une équipe déjà sous Jira, en contexte Agile, cherche un TMS intégré nativement. Que choisir en priorité ?
Quel outil sert à automatiser des parcours web et mobile (test UI) ?
Quelle est une bonne pratique de gestion et d'outillage ?
Pourquoi acheter un outil pour résoudre un problème de processus est-il considéré comme une mauvaise pratique ?
À savoir
La Minute QA est une aide à la compréhension, pas une formation professionnelle : certains points ne peuvent pas être couverts ici. Pensez à suivre une formation certifiante et à consulter le syllabus officiel ISTQB pour une préparation complète.
Pour aller plus loin