Robot Framework est devenu un outil incontournable dans de nombreuses équipes QA pour automatiser les tests Web, API, bases de données et parcours end-to-end. Sa syntaxe lisible permet aux profils techniques et fonctionnels de collaborer facilement.
Mais maîtriser Robot Framework ne signifie pas simplement savoir écrire des mots-clés et exécuter une suite de tests.
Pour un QA Automation Senior, l’enjeu est différent : il faut savoir concevoir une automatisation maintenable, fiable, scalable et intégrable dans une chaîne CI/CD.
Dans cet article, nous allons découvrir 10 techniques avancées de Robot Framework qui permettent de passer d’une automatisation basique à une véritable stratégie d’automatisation professionnelle.
1. Concevoir une architecture de framework maintenable
La première compétence d’un QA Automation Senior n’est pas d’écrire beaucoup de tests. C’est de savoir organiser le code.
Un framework mal structuré devient rapidement difficile à maintenir lorsque le nombre de tests augmente.
Une architecture peut par exemple être organisée ainsi :
robot-framework/
│
├── tests/
│ ├── web/
│ ├── api/
│ └── e2e/
│
├── resources/
│ ├── keywords/
│ ├── pages/
│ └── common/
│
├── libraries/
│
├── data/
│ ├── test_data.json
│ └── users.csv
│
├── config/
│ ├── dev.yaml
│ ├── recette.yaml
│ └── prod.yaml
│
├── results/
│
└── requirements.txt
Séparer les responsabilités
Un test devrait principalement décrire ce que l’on vérifie, tandis que les détails techniques doivent être placés dans des ressources réutilisables.
Par exemple, évitez :
*** Test Cases ***
Login
Open Browser https://example.com chrome
Input Text id=username john
Input Password id=password password123
Click Button id=login
Page Should Contain Welcome
Préférez :
*** Test Cases ***
Successful Login
Open Application
Login With Valid Credentials
Verify User Is Logged In
Cette approche améliore fortement la lisibilité et la maintenance.
Conseil Senior
Un bon framework doit permettre à un nouveau QA d’ajouter un test sans avoir besoin de comprendre toute l’architecture technique.
2. Maîtriser les User Keywords réutilisables
Les User Keywords sont l’un des mécanismes les plus importants de Robot Framework.
Ils permettent de transformer plusieurs actions techniques en une action métier compréhensible.
Par exemple :
*** Keywords ***
Login With Valid Credentials
Input Text id=username ${USERNAME}
Input Password id=password ${PASSWORD}
Click Button id=login
Wait Until Page Contains Welcome
Le test devient alors :
*** Test Cases ***
Customer Can Login
Login With Valid Credentials
Pourquoi cette technique est importante ?
Elle permet de :
- réduire la duplication ;
- améliorer la lisibilité ;
- centraliser les changements ;
- faciliter la maintenance ;
- rapprocher les tests du langage métier.
Attention au piège du « God Keyword »
Un keyword de 100 lignes qui fait tout est difficile à maintenir.
Évitez :
Complete Customer Registration
# 80 lignes...
Préférez plusieurs étapes :
Create Customer Account
Open Registration Page
Enter Customer Information
Submit Registration
Verify Registration Success
3. Utiliser efficacement les variables et la configuration par environnement
Un framework professionnel doit pouvoir fonctionner sur plusieurs environnements :
- DEV ;
- INT ;
- QA ;
- UAT ;
- PREPROD.
Il ne faut surtout pas coder les URLs ou identifiants directement dans les tests.
Évitez :
Open Browser https://recette.myapp.com chrome
Préférez :
Open Browser ${BASE_URL} chrome
Avec :
*** Variables ***
${BASE_URL} https://recette.myapp.com
Puis exécutez :
robot -v BASE_URL:https://qa.myapp.com tests/
Pourquoi c’est important ?
La même suite de tests peut ainsi être utilisée sur plusieurs environnements sans modifier le code.
Exemple
robot -v ENV:QA tests/
ou :
robot -v ENV:UAT tests/
Dans une pipeline CI/CD, cette approche devient particulièrement intéressante.
4. Maîtriser le Data-Driven Testing
Un QA Senior doit éviter de créer un test différent pour chaque jeu de données.
Prenons un scénario de connexion.
Au lieu de créer :
Login valid user
Login invalid password
Login unknown user
Login locked user
on peut utiliser une approche Data-Driven.
Avec le Template :
*** Settings ***
Test Template Login Should Be Rejected
*** Test Cases ***
Invalid Password
john@test.com wrongpassword
Unknown User
unknown@test.com password
Locked User
locked@test.com password
*** Keywords ***
Login Should Be Rejected
[Arguments] ${username} ${password}
Login ${username} ${password}
Verify Login Error
Cette approche permet de séparer :
La logique du test
de
la donnée de test.
5. Automatiser les API avec RequestsLibrary
Robot Framework n’est pas uniquement destiné aux tests UI.
Un QA Automation Senior doit être capable de construire une stratégie combinant :
API + Web + Database.
Avec RequestsLibrary :
*** Settings ***
Library RequestsLibrary
*** Test Cases ***
Create Customer
Create Session api ${BASE_URL}
${response}= POST On Session
... api
... /customers
... json=${customer}
Should Be Equal As Integers
... ${response.status_code}
... 201
On peut ensuite vérifier la réponse :
Should Be Equal
... ${response.json()}[status]
... ACTIVE
Pourquoi privilégier les tests API ?
Les tests API sont généralement :
- plus rapides ;
- moins fragiles ;
- plus faciles à exécuter en CI/CD ;
- adaptés aux validations métier.
C’est pourquoi une bonne stratégie d’automatisation ne doit pas chercher à tout tester via l’interface graphique.
6. Combiner API, UI et base de données dans un scénario E2E
Voici une technique particulièrement utile sur les projets complexes.
Imaginons un site e-commerce.
Le scénario est :
Créer une commande
↓
API
↓
Vérifier la commande dans la base
↓
UI
↓
Vérifier que la commande apparaît dans le compte client
Robot Framework peut orchestrer ces différentes couches.
Exemple simplifié :
*** Test Cases ***
Order Should Be Created Successfully
${order}= Create Order Via API
Verify Order In Database ${order}[id]
Login With Valid Credentials
Search Order ${order}[id]
Verify Order Is Displayed
Cette approche est très puissante pour valider la cohérence entre plusieurs composants d’un système.
Exemple concret
Sur une application comportant un front-office, un backend et un OMS/WMS, on peut vérifier :
Commande Web
↓
API
↓
Backend
↓
OMS
↓
Base de données
Le QA Senior doit être capable d’identifier à quel niveau effectuer chaque validation, plutôt que de tout vérifier via l’interface utilisateur.
7. Gérer correctement les attentes et les tests instables
L’un des problèmes les plus fréquents en automatisation est le flaky test.
Un test flaky peut :
- réussir localement ;
- échouer dans Jenkins ;
- réussir lors d’une seconde exécution ;
- échouer à cause d’un problème de synchronisation.
Une mauvaise pratique consiste à mettre :
Sleep 10s
partout.
Cela ralentit les tests et ne garantit pas leur stabilité.
Préférez :
Wait Until Element Is Visible
... id=confirmation
... timeout=10s
ou un mécanisme d’attente adapté à la bibliothèque utilisée.
Exemple
Mauvais :
Click Element id=submit
Sleep 5s
Element Should Be Visible id=success
Meilleur :
Click Element id=submit
Wait Until Element Is Visible id=success timeout=10s
Approche Senior
Lorsqu’un test échoue, il faut déterminer :
Application bug ?
↓
Donnée incorrecte ?
↓
Environnement instable ?
↓
Problème de synchronisation ?
↓
Erreur dans le test ?
Il ne faut pas simplement relancer le test jusqu’à obtenir un résultat vert.
8. Utiliser les tags pour organiser les campagnes
Les tags Robot Framework sont particulièrement utiles lorsqu’un projet possède plusieurs types de campagnes.
Exemple :
*** Test Cases ***
Login Test
[Tags] smoke regression web
Login With Valid Credentials
Autre test :
Create Customer
[Tags] regression api
On peut alors exécuter uniquement les tests Smoke :
robot --include smoke tests/
Ou les tests API :
robot --include api tests/
Ou exclure certains tests :
robot --exclude flaky tests/
Exemple de stratégie
| Tag | Utilisation |
|---|---|
smoke | Vérifications rapides après déploiement |
regression | Campagne complète |
api | Tests API |
web | Tests UI |
e2e | Parcours métier |
critical | Fonctionnalités critiques |
flaky | Tests à analyser |
Les tags peuvent également être alignés avec les campagnes de tests Jira/Xray.
9. Paralléliser les tests avec Pabot
Lorsque la suite de tests atteint plusieurs centaines de scénarios, le temps d’exécution peut devenir un problème.
Exécuter :
robot tests/
peut prendre plusieurs dizaines de minutes, voire plusieurs heures.
Pabot permet d’exécuter les tests Robot Framework en parallèle.
Par exemple :
pabot --processes 4 tests/
Au lieu de :
Test 1 → Test 2 → Test 3 → Test 4
on peut avoir :
Process 1 → Test 1
Process 2 → Test 2
Process 3 → Test 3
Process 4 → Test 4
Attention
La parallélisation n’est pas simplement une question d’augmenter le nombre de processus.
Il faut vérifier :
- l’isolation des données ;
- les comptes utilisateurs ;
- les fichiers temporaires ;
- les ressources partagées ;
- les données en base ;
- les dépendances entre tests.
Conseil Senior
Un test automatisé doit idéalement être indépendant et reproductible.
Si deux tests utilisent simultanément le même compte ou modifient la même donnée, la parallélisation peut créer des résultats incohérents.
10. Intégrer Robot Framework dans une stratégie CI/CD
La dernière compétence, et probablement l’une des plus importantes pour un QA Senior, est de transformer l’automatisation en véritable Quality Gate.
Une architecture classique peut être :
Developer commit
↓
Build
↓
Unit Tests
↓
API Tests
↓
Robot Framework
↓
Reports
↓
Quality Gate
↓
Deployment
Robot Framework peut être exécuté dans Jenkins, GitLab CI/CD ou d’autres outils d’intégration continue.
Exemple :
robot \
--outputdir results \
tests/
Les résultats peuvent ensuite être exploités par la pipeline.
Exemple de stratégie
Pull Request
Smoke API
+
Tests critiques
Build QA
API
+
Web
+
E2E
Nightly
Régression complète
+
Tests longs
Cette organisation évite de lancer systématiquement plusieurs centaines de tests à chaque commit.
Tableau récapitulatif des 10 techniques
| # | Technique | Objectif | Niveau |
|---|---|---|---|
| 1 | Architecture framework | Maintenabilité | Senior |
| 2 | User Keywords | Réutilisation | Intermédiaire |
| 3 | Variables / environnements | Flexibilité | Intermédiaire |
| 4 | Data-Driven Testing | Gestion des données | Senior |
| 5 | API Testing | Tester le backend | Senior |
| 6 | API + UI + DB | E2E multi-couches | Senior |
| 7 | Synchronisation | Réduire les flaky tests | Senior |
| 8 | Tags | Organisation des campagnes | Intermédiaire |
| 9 | Pabot | Réduire le temps d’exécution | Senior |
| 10 | CI/CD | Industrialiser la QA | Senior |
Les erreurs fréquentes à éviter avec Robot Framework
1. Mettre toute la logique dans les fichiers de test
Les fichiers deviennent rapidement illisibles.
Solution : utiliser des ressources et User Keywords.
2. Utiliser Sleep systématiquement
Sleep 10s
n’est pas une stratégie de synchronisation.
Solution : utiliser les mécanismes d’attente adaptés.
3. Dupliquer les tests
Créer 20 tests presque identiques avec uniquement des données différentes augmente considérablement la maintenance.
Solution : Data-Driven Testing.
4. Tout automatiser via l’UI
Les tests UI sont généralement plus coûteux et plus fragiles.
Solution : utiliser la pyramide de tests et déplacer les validations vers les API ou les couches inférieures lorsque cela est pertinent.
5. Ignorer les tests flaky
Un test qui échoue régulièrement sans être traité réduit progressivement la confiance dans toute la suite automatisée.
Solution : mesurer, analyser et supprimer les causes de flakiness.
6. Ne pas isoler les données
Les tests qui dépendent les uns des autres deviennent difficiles à paralléliser.
Solution : rendre chaque scénario autant que possible indépendant.
Robot Framework : niveau débutant, intermédiaire ou senior ?
| Compétence | Débutant | Intermédiaire | Senior |
|---|---|---|---|
| Syntaxe Robot | ✓ | ✓ | ✓ |
| Locators | ✓ | ✓ | ✓ |
| User Keywords | ✓ | ✓ | |
| Variables | ✓ | ✓ | ✓ |
| API Testing | ✓ | ✓ | |
| Architecture framework | ✓ | ||
| Data-Driven | ✓ | ✓ | |
| Database Testing | ✓ | ✓ | |
| Pabot | ✓ | ||
| CI/CD | ✓ | ✓ | |
| Gestion des flaky tests | ✓ | ||
| Stratégie d’automatisation | ✓ | ||
| Architecture multi-couches | ✓ |
La différence entre un QA qui utilise Robot Framework et un QA Automation Senior qui maîtrise Robot Framework se trouve principalement dans la capacité à prendre des décisions d’architecture et de stratégie.










