The fundamentals of software testing.
Why do we test? What is a bug? What are the 7 principles of testing and the fundamental process? The solid foundations on which to build a quality approach.
In 5 minutes, understand what software testing is, the 7 ISTQB principles and the main levels of testing.
00 - Summary
1. What is testing?
2. The 7 principles of testing (ISTQB)
3. The fundamental process of software testing
4. Levels and types
5. The human aspect testing
6. Key points to remember
01 - Definitions
What is testing?
Gestion de tests (TMS - Test Management Software)
Centralise les cas, plans, campagnes et résultats. Trace l'exigence > cas > 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 d'exigences
Stocker les User Stories, exigences et critères d'acceptation. Base de la traçabilité.
Outils :
-
Jira + Confluence (Atlassian)
-
Azure DevOps (Microsoft)
-
Polarion (Jama)
-
DOORS (IBM)
Test d'API
Tester contrats, schémas, scénarios d'intégration côté serveur.
Outils :
-
Postman / Newman
-
REST Assured
-
Karate
-
SoapUI
Test UI
Automatiser les parcours web et mobile.
Outils :
-
Cypress
-
Playwright
-
Selenium
-
WebdriverIO
-
Appium
Performance
Charge, stress, endurance, scalabilité.
Outils :
-
k6
-
JMeter
-
Gatling
-
Locust
-
Artillery
Securité et qualité de code
Détection précoce de vulnérabilités.
Outils :
-
OWASP ZAP
-
Burp Suite
-
SonarQube
-
Snyk
-
Dependabot
CI/CD
Orchestrer l'exécution automatique à chaque commit.
Outils :
-
GitHub Actions
-
GitLab CI
-
Jenkins
-
CircleCI
-
Azure Pipelines
02 - The 7 principles
The 7 principles of software tesitng (ISTQB).
These principles guide any testing strategy. Understanding them helps avoid common pitfalls and justify choices to teams and management.
01
Préparer
Définir le périmètre, les critères d'entrée, la stratégie. Créer / organiser les suites dans le TMS.
02
Planifier
Construire la campagne : sélection des cas, environnement cible, version testée, testeurs assignés.
03
Exécuter
Marquer chaque cas "Réussi" / "Echec"/ "Bloqué". Joindre captures, logs, requêtes réseau aux échecs.
04
Anomalies
Créer le ticket depuis le cas échoué : la liaison cas <> bug est automatique (lorsque c'est possible). Suivre puis retester au besoin.
05
Clôturer
Bilan de campagne : taux de réussite, anomalies ouvertes par sévérité, couverture exigences.
05 - Psychology
The human aspect of testing.
The tester is not the developer's adversary. Their role is to provide objective information to improve the product.
Jira + Xray
TMS intégré à Jira
Pour qui : Équipes déjà sous Jira, contexte Agile / SAFe (Scaled Agile Framework).
+ 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.
+ UI claire, plans / exécutions, API REST complète, intégrations CI.
− 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 / TS (JavaScript / TypeScript) ou Python.
+ Auto-attente, génération de code, support web mobile.
− Plus jeune que Cypress, écosystème de plugins encore en croissance.
Cypress
Automatisation UI
Pour qui : Équipes front JS / TS , focus DX (Developer Experience) et debugging visuel.
+ Time-travel (rejeu des étapes), dashboard, snapshots, courbe d'apprentissage douce.
− Limité aux navigateurs Chromium principalement, modèle onglet unique.
03 - The process
The fundamental process of software testing.
A structured process ensures that the test is planned, documented, and repeatable. Each step produces verifiable deliverables.
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 dans la campagne.
GitHub + Playwright + Allure
Pipeline GitHub Actions, rapports Allure publiés en artefacts, badge de couverture commenté sur la PR (pull request).
Azure DevOps + Postman + k6
Tests API Newman sur chaque build, tests de perf k6 en nocturne, résultats poussés dans Azure Test Plans.
05 - Savoir différencier les bonnes et mauvaises pratiques
Les bonnes et mauvaises pratiques
Bonnes 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 > par exemple un PowerPoint mensuel ou un bilan de recette dynamique.
Mauvaises pratiques
-
Maintenir des cas de test dans Excel ET dans le TMS : double saisie, divergence garantie.
-
Outil imposé sans formation - l'outil meurt en 6 mois.
-
Trop de champs obligatoires dans le rapport d'anomalie → personne ne remplit correctement les champs.
-
Confondre TMS (Test Management Software) et outil d'automatisation. Ils sont complémentaires.
-
Acheter un outil pour résoudre un problème de processus.
06 - Key points
In short:
-
Testing helps to reveal flaws, not to prove that a software is perfect.
-
We can't test everything; we have to prioritize according to the risks.
-
Early testing improves quality and reduces costs.
-
A good testing approach combines methodology, appropriate test types, and clear communication.