Ingénieur QA Automation · SDET · Montpellier

Un test doit être un signal, pas un coût.

Je construis l'outillage qui rend les tests utiles : un framework Robot Framework / Appium couvrant Android, iOS, iPadOS, Web et Windows, et la plateforme d'orchestration qui va avec : React, Flask, Robot Framework, de bout en bout.

Ce qui m'intéresse, c'est le moment où un test cesse d'être un coût de maintenance pour devenir un signal fiable. Un test qui échoue au hasard ne protège personne : il apprend à l'équipe à ignorer le rouge.

Robot Framework s'exécute très bien en ligne de commande. Ce qui manque, en équipe, c'est tout ce qu'il y a autour : savoir sur quel environnement part un run, ce qu'il va jouer, ce qui se passe pendant, et où est le rapport après.

Trois partis pris : aucune URL dans les tests, aucun mot de passe versionné, un run qui part d'un contexte explicite. Backend Flask + Socket.IO, frontend React, exécution Playwright.

→ Voir l'interface en ligne Un run réel y est rejoué : logs, étapes, verdict, rapport. Rien n'y est exécuté, les données viennent d'une exécution enregistrée.

Tester la même application sur Android, iOS, iPadOS, Windows et le web, c'est maintenir le même élément cinq fois, ou disperser des if platform == ... dans ses page objects. crosslocator déclare le sélecteur une fois par plateforme et résout le bon à l'exécution, avec détection automatique depuis la session Appium.

pip install crosslocator

Sans dépendance d'exécution. Utilisable depuis Python pur, Appium ou Robot Framework.

Un assistant qui écrit des tests mobiles invente des sélecteurs : il propose ce qu'un développeur aurait écrit, et le test échoue parce que l'application expose autre chose. Ce serveur MCP lui donne l'arbre de l'écran, des sélecteurs qui existent vraiment, et de quoi interagir. Android, iOS, iPadOS et Windows.

pip install mcp-appium

Toutes les sorties sont bornées : un arbre de vue brut saturerait la fenêtre de contexte avant d'avoir rien appris au modèle, et ce qui y entre se repaie à chaque échange suivant.

Le CV est une page HTML sans dépendance, avec sa propre feuille d'impression A4 : le PDF ne peut pas être en retard sur le site. Le blog passe par Jekyll, construit nativement par GitHub Pages.

Automatisation web de bout en bout avec Robot Framework et Browser Library (Playwright), en Page Object Model. Exécutable tel quel, sans configuration ni compte.

Des retours de terrain sur l'automatisation des tests : ce qui coinçait, ce que j'ai mis en place, et le chiffre quand la mesure existe.

• 70 % du temps de mes tests ne testait rien Injecter les données par API plutôt que par l'interface. Et surtout, quand ne pas le faire.
• Le test qui échouait n'était jamais celui qui avait le bug Un teardown ne s'exécute pas quand le processus meurt. Les tests suivants tombent alors très loin du coupable.
• Un bouton, quatre sélecteurs, un seul test Le même élément se trouve de quatre façons selon le système. Où écrire ce choix.

Tous les articles

L'architecture avant le volume. Un framework modulaire vieillit mieux qu'un catalogue de scripts. Un changement d'écran ne doit pas faire tomber dix tests.

L'infrastructure fait partie du test. Banc multi-OS, environnements, données provisionnées par API. Ce qui entoure le test décide de sa fiabilité.

Mesurer plutôt qu'estimer. Temps d'exécution, temps d'affichage, fuites mémoire. Sans chiffre, une lenteur reste une impression que personne ne corrige.

L'IA en pair programming, cadrée par de l'ingénierie. Faire écrire un test par une IA est facile ; le rendre fiable est un problème de qualité, car un test plausible mais faux est pire qu'un test absent. D'où des index générés depuis le code plutôt qu'un dépôt fouillé à chaque fois, des garde-fous qui refusent une écriture non conforme avant qu'elle n'arrive, et chaque vrai défaut transformé en règle écrite qui contraint la génération suivante.

Langages : Python · Robot Framework · JavaScript · SQL · Bash / Batch Automatisation : Appium · Playwright · Selenium · Page Object · BDD / tags Mobile & desktop : Android SDK / adb · Xcode · iPadOS · Windows MAUI / MSIX Développement : Flask · React · API REST · Clean Architecture CI & reporting : Git · CI/CD · Concourse · Nexus · Allure · ELK

ISTQB® Foundation Level.

L'essentiel de mon travail est sous licence privée : le framework de 380 tests, le banc d'exécution multi-OS et la plateforme en service en production. Les dépôts publics ci-dessus reprennent les mêmes partis pris sur des applications de démonstration : ils donnent à voir l'architecture et les décisions, pas l'étendue.

LinkedIn · julien.becheny [at] gmail.com