À propos de cet outil
La plupart des équipes savent dire combien de tests automatisés elles ont. Moins nombreuses sont celles qui savent dire si ces tests sont un signal auquel on fait confiance. Cette grille pose douze questions sur ce qui se passe réellement aujourd’hui, deux pour chacun de six domaines : stratégie et périmètre, framework et qualité du code, intégration CI/CD, données de test et environnements, fiabilité et instabilité, et reporting et ownership. Chaque réponse vaut de 0 à 3 points. Chaque domaine est noté sur 100 à partir de ses deux réponses, et le score global est la moyenne des six domaines : une équipe avec un superbe framework qui ne tourne que sur un seul portable ne peut pas obtenir un bon score. Le score global correspond à l’un des quatre niveaux : « Ad hoc » (moins de 35), « Emerging » (35 à 59), « Established » (60 à 84) et « Optimised » (85 et plus). Les domaines les plus faibles sous 80, jusqu’à trois, reviennent sous forme de prochaines étapes concrètes avec des liens vers les leçons et outils qui les couvrent. La notation suit une grille fixe, détaillée dans la FAQ ci-dessous. C’est une base de discussion pour une rétro ou une séance de planification, pas un benchmark par rapport à d’autres entreprises : aucun jeu de données d’autres équipes ne se cache derrière, et rien de tel n’est prétendu.
Mode d’emploi
- Répondez à chaque question avec l’option qui décrit ce que fait votre équipe aujourd’hui. Les ambitions et projets comptent comme l’option où vous en êtes actuellement.
- Votre score s’affiche dès que les douze questions ont une réponse. Les réponses sont enregistrées dans ce navigateur, vous pouvez donc y revenir.
- Lisez la liste « Work on next » (à travailler ensuite) : les domaines les plus faibles d’abord, chacun avec une étape concrète et des liens pour approfondir.
- Utilisez « Copy share link » (copier le lien de partage) pour envoyer le résultat à votre équipe. Le lien contient les réponses : quiconque l’ouvre voit les mêmes scores. « Copy summary » (copier la synthèse) fournit un texte brut pour Slack, un ticket ou un document de rétro.
Ce que mesurent les six domaines
- Stratégie et périmètre : l’automatisation cible-t-elle délibérément les risques, et la plupart des vérifications se situent-elles au niveau le moins coûteux capable d’attraper le bug (unitaire et API avant l’UI) ?
- Framework et qualité du code : le code de test est-il structuré (page objects ou component objects, fixtures, configuration) et relu comme du code de production, et les locators résistent-ils aux changements de balisage ?
- Intégration CI/CD : les tests s’exécutent-ils à chaque changement sans que personne ait à y penser, et combien de temps une pull request attend-elle la réponse ?
- Données de test et environnements : les tests possèdent-ils leurs données et peuvent-ils tourner en parallèle et dans n’importe quel ordre, sur un environnement identique à chaque fois ?
- Fiabilité et instabilité : un build rouge signifie-t-il un vrai problème ? Les attentes fixes (sleep) et les relances jusqu’au vert sont les coupables habituels.
- Reporting et ownership : un échec peut-il être diagnostiqué à partir du rapport de CI, et toute l’équipe, pas seulement la QA, agit-elle en conséquence ?
Utiliser le résultat avec une équipe
Demandez à deux ou trois personnes (un testeur, un développeur, la personne qui gère le pipeline) de remplir la grille séparément, puis comparez les liens de partage. Les divergences sont généralement plus utiles que le score lui-même : si l’un choisit « on every pull request » et l’autre « nightly », l’équipe n’est pas d’accord sur ce que fait le pipeline.
Choisissez un domaine de « Work on next » par trimestre. Faire passer un domaine de 33 à 67 vaut mieux que de disperser l’effort sur les six. Refaites l’évaluation en fin de trimestre avec les mêmes personnes.
FAQ : Évaluation de maturité de l’automatisation des tests
Comment le score est-il calculé ?
Chaque réponse vaut 0, 1, 2 ou 3 points, dans l’ordre où les options sont listées. Chaque domaine a deux questions, donc il est noté sur 6, affiché en pourcentage. Le score global est la moyenne arrondie des six pourcentages de domaine. Niveaux : « Ad hoc » sous 35, « Emerging » 35–59, « Established » 60–84, « Optimised » 85 et plus.
Est-ce un benchmark du secteur ?
Non. La grille est un barème fixe fondé sur des pratiques d’automatisation des tests largement reconnues, pas une comparaison avec d’autres entreprises. Aucun jeu de données d’autres équipes ne se cache derrière, et SDETRole ne collecte pas vos réponses pour en constituer un.
Où mes réponses sont-elles stockées ?
Dans le stockage local de votre navigateur, et dans le fragment du lien de partage (la partie après #) quand vous le copiez. Les navigateurs n’envoient pas le fragment aux serveurs : SDETRole ne reçoit donc jamais vos réponses.
Si j’ouvre le lien d’un collègue, mes réponses seront-elles écrasées ?
Non. Un résultat partagé s’affiche sans être enregistré. Si vous modifiez une réponse, vous créez votre propre copie à partir de ses réponses, et cette copie est enregistrée dans votre navigateur.
Nous n’avons pas encore d’automatisation. Est-ce quand même utile ?
Oui. Répondez honnêtement : vous aurez un score bas dans la plupart des domaines, et la liste « Work on next » vous indiquera par où commencer, généralement la stratégie (quoi automatiser en premier) et la CI (exécution automatique dès le premier jour).