10 techniques avancées de Robot Framework qu’un QA Automation Senior devrait maîtriser

10 techniques avancées de Robot Framework qu’un QA Automation Senior devrait maîtriser

10 techniques avancées de Robot Framework qu’un QA Automation Senior devrait maîtriser

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

TagUtilisation
smokeVérifications rapides après déploiement
regressionCampagne complète
apiTests API
webTests UI
e2eParcours métier
criticalFonctionnalités critiques
flakyTests à 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

#TechniqueObjectifNiveau
1Architecture frameworkMaintenabilitéSenior
2User KeywordsRéutilisationIntermédiaire
3Variables / environnementsFlexibilitéIntermédiaire
4Data-Driven TestingGestion des donnéesSenior
5API TestingTester le backendSenior
6API + UI + DBE2E multi-couchesSenior
7SynchronisationRéduire les flaky testsSenior
8TagsOrganisation des campagnesIntermédiaire
9PabotRéduire le temps d’exécutionSenior
10CI/CDIndustrialiser la QASenior

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étenceDébutantIntermédiaireSenior
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.

Laisser un commentaire