DEV Community: Daphné Hervé

L'engagement communautaire en tant que QA : quelques idées

Daphné Hervé — Sun, 07 Jun 2026 23:22:02 +0000

La participation à des projets open source n’est pas réservée aux développeurs ! En tant que QA/QE, vous pouvez aussi contribuer, je vous partage mes meilleures idées !
Elles sont à portée de clavier et vos compétences de test sont précieuses !

Répondre aux questions sans réponse

Sur Stack Overflow ou tout forum technique : filtrez sur testing + sans réponse ou bien new. Une réponse bien construite peut débloquer quelqu'un et rester utile pour des centaines d'autres.

Rédiger des articles

Retour d'expérience, tutoriel, comparatif d'outils… Écrire force à structurer sa pensée et à consolider ses connaissances. Et chaque article publié devient une ressource durable pour la communauté. Pas besoin d'être expert pour commencer ; l'honnêteté et la clarté suffisent.

Organiser des événements QA près de chez soi

Meetup, workshop… La communauté testing locale est souvent plus dynamique qu'on ne le pense. Organiser un événement, même modeste, crée du lien, fait émerger des idées et positionne le test comme une discipline sérieuse et vivante.

Prendre la parole en conférence

Le meetup est l'endroit idéal pour commencer : petit comité, public bienveillant et intéressé. Pas besoin d'un sujet révolutionnaire ; un retour d'expérience sincère vaut souvent mieux qu'une présentation parfaite. Et avec un peu d'entraînement, les conférences plus grandes deviennent accessibles.

Tester des projets open source

Le Fedora Project, par exemple, dispose d'une page dédiée aux contributeurs QA. Rejoindre ce type d'initiative, c'est exercer son métier sur de vrais projets, tout en rendant service à des milliers d'utilisateurs.

Créer des collections Postman pédagogiques

À l'occasion d'une conférence sur l'automatisation ou en dehors : construire une collection Postman avec des cas d'usage concrets sur des API open source, c'est offrir aux développeurs un support d'apprentissage immédiatement réutilisable.

Tracker et remonter les bugs

Il y en a beaucoup plus qu'on ne le croit. Un bug bien documenté, avec contexte, étapes de reproduction et impact est un cadeau pour les équipes de développement. C'est aussi un excellent exercice pour affûter son regard critique.

Transmettre aux juniors et aux personnes en reconversion

Un mentorat informel, une revue de CV, une session de pair testing, un retour bienveillant sur un premier portfolio… Ces gestes simples peuvent changer une trajectoire. Et enseigner, c'est aussi apprendre. On ne mesure vraiment ce qu'on sait qu'en l'expliquant.

Co-rédiger un manifeste sur nos pratiques à l'ère de l'IA ?

Appel à contribution
L'IA transforme nos pratiques de test en profondeur. Plutôt que de subir ce changement, pourquoi ne pas le penser collectivement ? J'ai lancé un appel à co-rédaction d'un manifeste sur nos pratiques de test à l'ère de l'IA. Venez contribuer, challenger, enrichir. La communauté mérite une réflexion collective sur ce sujet.

Cette liste n'est pas exhaustive et c'est voulu. L'engagement communautaire prend mille formes, et la meilleure est celle qui vous correspond. Même une petite contribution régulière peut créer de la valeur sur le long terme.

Et si je ne me sens pas légitimes ? Vous ne seriez pas en train de faire un petit syndrome de l'imposteur. Vous n'êtes pas seul.e, appuyez vous sur le collectif ! Et garder ses articles pour soi sans les publier, c'est déjà progresser !
Et si ça ne fonctionnait pas ? C'est possible... n*e vous découragez pas ! *

Et vous, quelle forme d'engagement vous parle le plus ? Des idées à ajouter ? Les commentaires sont ouverts :)

Rédigeons ensemble un traité pour la profession du test logiciel à l'ère de l'IA

Daphné Hervé — Sun, 07 Jun 2026 18:06:19 +0000

J'étais la semaine dernière à Tech Ready, une journée de conférences tech dense et stimulante. Plein de sujets passionnants sur l'IA et le cloud.

En tant que QA je n'ai pas osé prendre la parole dans l'assemblée des développeurs autour de moi, mais une question ne me lâche pas :

Comment peut-on être juge et partie de son propre code ?

Si des tests générés par l'IA peuvent vérifier la qualité du code, quid de la qualité de l'application ?

Si la profession de la qualité logicielle s'est structurée, c'est précisément pour éviter les biais de conception et de réalisation.

Notre métier va changer

L'IA générative bouleverse nos workflows à une vitesse inédite. Les développeurs codent plus vite et le delivery s'accélère. Cela semble vertigineux, ça l'est.
Transformons nos craintes en opportunité.

Les défis concrets pour notre profession

Voici les questions qui me semblent les plus urgentes à adresser collectivement :

1. Comment intégrer la qualité dans un delivery full IA ?

L'IA accélère la production de code. Mais quels points de contrôle mettre en place pour ne pas sacrifier la qualité à la vitesse ? Qui porte ces checkpoints ? Ces garde-fous et à quelle fréquence ? Quels sont les nouveaux rituels ?

2. Comment tester l'IA elle-même ?

Tester un système déterminé, c'est un métier. Tester un système dont les outputs varient, c'est un autre challenge. Vérifier la pertinence des résultats, détecter les dérives et hallucinations, contrôler les risques de sécurité ou d'éthique : sont de nouvelles compétences à développer. Comment amener les QE à s'approprier des outils de plus en plus spécialisés : LLM-as-a-judge ...?

3. Comment faire monter en compétences les QA fonctionnels ?

Beaucoup de profils qualité ont une approche fonctionnelle. L'IA va demander davantage de culture technique comme apprendre à utiliser git par exemple. Comment organiser cette montée en compétences ?

4. Comment utiliser l'IA pour booster nos pratiques ?

L'IA peut nous aider à générer des cas de test, à créer des jeux de données, à analyser des bugs, à prioriser des scénarios. Autant de tâches répétitives dont on peut se dégager pour se concentrer sur ce que les machines ne feront pas : les tests exploratoires, le questionnement, le regard critique.

5. Comment accompagner le changement à l'échelle ?

La conférence qui m'a le plus marquée lors de Tech Ready présentait l'adoption de l'IA par 600 personnes en quelques mois chez Doctolib (super talk de Yankı Sesyılmaz et Julien Tanay). Ce modèle d'accompagnement massif est inspirant. Comment le transposer à la qualité logicielle ?

L'idée : co-rédiger un traité pour notre profession

Face à ces défis, j'ai envie de faire quelque chose de concret : écrire collectivement un document de référence un traité ou un manifeste, qui structure les réponses de notre profession à ces questions.

Une structure possible :

Chapitre	Contenu
📜 Manifeste	Nos valeurs fondamentales, ce qui définit notre rôle
🔍 Constats	Ce que l'IA change concrètement dans nos workflows
🧱 Principes	Ce qui ne doit pas bouger malgré l'IA
🛠️ Pratiques	Comment tester avec l'IA, comment tester l'IA
📚 Formation	Montée en compétences QA fonctionnels et QE
✅ Gouvernance	Points de contrôle qualité dans un delivery IA

Comment contribuer ?

Le document sera ouvert à toutes les contributions. Plusieurs façons de participer :

👇 En commentaire ici : quelle question te semble la plus urgente ?

📝 Via le formulaire de contribution : si tu veux t'engager plus formellement dans la co-rédaction, remplis ce court formulaire : https://framaforms.org/manifeste-du-test-logiciel-a-lere-de-lia-1780832548

Testeurs, QA, QE, Test Managers, leads qualité, développeurs sensibles à la qualité, Product Owners… Apportez votre vision du métier à la discussion !

Pour conclure

La vraie force du testeur, ce n'est pas l'outil qu'il utilise. C'est son esprit curieux, critique, son œil de lynx. Des qualités qu'aucun LLM ne remplace.

À l'ère de l'IA, ne nous contentons pas de prendre le train en marche. Accompagnons le changement, soyons force de proposition.

Méthode "Pipeline first" pour tes tests

Daphné Hervé — Sun, 07 Jun 2026 17:43:12 +0000

"Start with the pipelines first" est un mantra qui a changé ma façon de travailler.

Tu passes des semaines à peaufiner tes tests auto et tu attends que tout soit "parfait" avant de toucher à la CI ?

Quand tu penses que tout est bon tu les intègres enfin dans des pipelines. Mais au lancement, les rapports ne sont pas au bon format, les noms des cas de test sont bancals, le déclenchement ne marche pas comme prévu.
Tu dois tout reprendre. Frustrant, non ?

Pas de panique, c'est un piège classique quand on commence avec les tests auto. La raison principale étant que nous ne sommes pas nécessairement les plus à l'aise sur les tâches DevOps en tant que testeur.se.

Cela peut paraitre lourd dès le début d'un projet... Mais pourtant affronter ta peur de la CI va te faire gagner un temps précieux !
Fini la procrastination, on commence par le plus difficile : les pipelines !

La méthode "pipeline first" :

Voilà l'ordre que je recommande pour chaque nouveau projet :

Installe Cypress ou playwright ou newman ou ce que tu veux car en réalité ça vaut pour TOUS les types de tests auto !
Écris un seul test, ultra-minimaliste. Une simple redirection vers ton site par exemple. C'est tout, pas de data ou de scénario complexe.  
Crée ta pipeline de test, maintenant, Oui oui, déjà.
Peaufine les rapports et le format, JUnit XML, noms de cas de test, artefacts.
Choisis tes triggers (à chaque build, tous les jours (scheduled), selon ton besoin).
Maintenant seulement, seulement maintenant, tu peux coder tes tests !

🎉 Résultat : chaque test que tu écriras sera immédiatement exécuté, rapporté, visible. Ton PO et les dev voient des résultats dès le premier sprint.

Well done !

Et si dans ton entreprise les pipelines sont gérées par les SRE ou les dev ? Demande à voir comment c'est fait, juste par curiosité. Comprendre la technique permet d'améliorer les rapports, le déroulé des tests etc etc. Vous avez un objectif commun : des pipelines robustes et efficientes, autant travailler ensemble :)

[Postman] The variables

Daphné Hervé — Sat, 23 Mar 2024 11:22:47 +0000

From advanced to expert 
For developers and testers.  
         ---------          
Some great tutorials to get all the tips of Postman :

Number 2 : Let's continue the tutorials with the variables.
In the previous tutorial we written some javascript in the test section to get data from the console. Postman offer a storage feature for this data.

That means :

we can use getter and setter inside postman
we can reuse data for a request chain for e2e tests and automation
We can secure bearer token as secret using the variables

For this tutorial we will use the free API of national french repository of adresses (--> documentation - FR)

Create a new request and type this call :

https://api-adresse.data.gouv.fr/search/?q=8+rue+port

Feel free to enter the adresse of your choice ;)

Click the send button to submit the request and enjoy the 5 results.

Alright, it's time to play with variables !

Firstly we will iterate on the results to get each adresse name :

let adresses = pm.response.json()
adresses.features.forEach(adresse => console.log(adresse.properties.label))

Submit the call and enjoy the results in the dev console :

Each adresse label is properly retrieved.
Secondly, we will store the results in a collection variable.

let adresses = pm.response.json()
// Setter
pm.collectionVariables.set("adresse_label_variable", adresses.features[0].properties.label);

Super nice ! And we add a getter :

// Getter
let firstAdresse = pm.collectionVariables.get("adresse_label_variable");
console.log('stored_variable', firstAdresse);

Should be like this :

Well done ! We used setter and getter to store the first result and reuse it in a console.log

Good to know : collectionVariables is not the only way to store data.

CollectionVariable = Manage data into the collection only
EnvironmentVariables = You can reuse data from one collection to another
GlobalVariables = Use it everywhere.

(Official Postman Documentation)

You can find the environment on the right corner at the top :

To see all your collectionVariables go there :

To see the other variable types see here :

In the next tutorial we will learn to use the
environmentVariables and how to store secret data

See all the official postman documentation here

Hope it helps !
Daphné Hervé (API, monitoring and QA automation lover)

[Postman] The dev console

Daphné Hervé — Sat, 23 Mar 2024 11:22:15 +0000

From advanced to expert 
For developers and testers.  
         ---------          
Some great tutorials to get all Postman tips :

Number 1 : we begin the tutorials with the dev console.
The console is very useful when you are coding your front or for testing purpose.

Breaking news - we will write some javascript inside !

For this tutorial we will need the dev console itself just here :

In the left corner on the bottom.

And the test tab in the request part, just here :

Create a get request to the free pokemon api without any parameters just this call :

https://pokeapi.co/api/v2/pokemon

Should be like that :

Press the send button for submitting our request !
Alright, so far everything ok !

Let's take a deeper look to our main subject by clicking the console button on the bottom

All the call informations are properly retrieved.
And so what ?

Wait a minute, I mentioned some javascript, let's go !
Go to the test tab and write some js :

let pokemons = pm.response.json().results
pokemons.forEach(pokemon => console.log(pokemon.name))

Should seems like that :

Click on the send button to see the result in the console !
Awww wow ! We have it ! A wonderful pokemon list !

We achieve our first goal : Use the postman console for debugging or testing.

Additional tips : you can clear the console on the right corner on bottom of postman.

Next steps :

Learning to use variables to do something with the pokemon list or any data you get.
Manage your environnement and keep your infos secret
Go further in the javascript methods
Learn to use the mock server
Go deeper with the automation ... and several very useful things !

Hope it helps !
Daphné Hervé (API, monitoring and QA automation lover)

Test less and cover more with combinations using Pairwise and Pict

Daphné Hervé — Mon, 11 Mar 2024 04:35:07 +0000

Go straight to the point ! 
Test less and cover more, 
sounds good !

When ? You have a lot of data or different behaviors to test.

Who ? For developers and testers who want to reduce their number of tests cases.

How does it work ?

"Pairwise testing is an effective test case generation technique that is based on the observation that most faults are caused by interactions of at most two factors. Pairwise-generated test suites cover all combinations of two therefore are much smaller than exhaustive ones yet still very effective in finding defects"
(Pairwise.org)

In this post we will use PICT to generate efficient combinations of data at entry point of your test cases. Pict is an open source CLI tool developed by Microsoft.

Form your own opinion by using this great online console : https://pairwise.yuuniworks.com/

How to use ?
Download the Pict.exe and open a terminal.
It's an .exe, so you need to be on the same folder or to indicate the right path to the Pict.exe.

Pict my_file_to_combine.txt

💡 Tips : render the results in an external file instead of in the command line interface using a return function :

Pict my_file_to_combine.txt > results.csv

📝 Pict is also available with a container image. Go to the README to have more infos : README on github

Imagine a database with CRUD authorizations combined with user rights. You need to test if the action of the user properly depends on the right authorization.

Some usual exemples :

reader can only see the user-infos-table
contributor can create into the user-infos-table
admin can also update the localization-table
admin is authorized to delete / localization-table ... etc etc.

Without the Pairwise method, we would need to do several iterations for this test to cover all the possibilities.

Let's try the Pairwise method ! Such of entries...

#############################################################
# User's access to your database
#############################################################

userTypes: reader, admin, contributor, editor

accessTypes: view, create, read, update, delete

database name: user-infos, localization

... give the followings results :

userTypes   accessTypes   database name
admin       read          localization
admin       delete        user-infos
contributor create        user-infos
admin       view          localization
editor      create        localization
reader      delete        localization
editor      view          user-infos
contributor update        localization
editor      read          user-infos
editor      delete        localization
editor      update        user-infos
contributor view          localization
admin       create        localization
contributor read          localization
admin       update        user-infos
reader      view          localization
contributor delete        localization

Seems like a .csv file. The first row is the header with all the entries we mentioned.

Without the Pairwise method, in the following case we would need to do at least 32 iterations for this test to cover all the possibilities.

With the Pairwise generation method we get 17 results. Amazing !

Now we can add some additional restrictions :

if [userTypes] = "reader" then ([accessTypes] = "view");

#############################################################
# User's access to your database 
#############################################################

userTypes: reader, admin, contributor, editor

accessTypes: view, create, read, update, delete

database name: user-infos, localization

if [userTypes] = "reader" then ([accessTypes] = "view");

And the results are ...

userTypes   accessTypes   database name
admin       read          localization
admin       delete        user-infos
contributor create        user-infos
admin       view          localization
editor      create        localization
editor      view          user-infos
contributor update        localization
editor      read          user-infos
editor      delete        localization
editor      update        user-infos
contributor view          localization
admin       create        localization
contributor read          localization
admin       update        user-infos
reader      view          localization
contributor delete        localization

More details here about the Pairwise combination method : Pairwise.org

You can find some useful examples of restriction in the official documentation

The time you win with this Pairwise method is precious to any other test action ! Think about exploratory testing !

Hope it helps !
Daphné Hervé (API, monitoring and QA automation lover)

[Postman] Set random numbers in your test name

Daphné Hervé — Mon, 11 Mar 2024 04:26:39 +0000

Love sharing my best postman recipes, today a precious advice

To set dynamically a variable in your test name.

pm.test(["TEST - " + pm.variables.replaceIn('{{$randomInt}}')], function () {
    pm.response.to.have.status(200);
});

You will get random value in the the name on the TSF report.

Appreciate the result :

There is a lot of very useful value with the Faker library :
$timestamp or $randomAlphaNumeric

Take a look here for more details about all the ramdom value that you can use : Official documentation about this topic

Hope it's help !
Daphné Hervé (API, monitoring and QA automation lover)