Comment choisiriez-vous un framework d'automatisation pour un nouveau projet ?

Choisissez pour l'application et pour l'équipe, pas pour la réputation de l'outil. Alignez le langage sur ce que les développeurs écrivent déjà pour qu'ils puissent contribuer et relire. Regardez ce qu'est réellement l'application (web, mobile, API, bureau) et si l'outil gère ses spécificités comme les iframes, le shadow DOM ou les onglets multiples. Pesez ensuite la vitesse d'exécution, le parallélisme, l'intégration CI, les rapports et la qualité du débogage.

Je commence par ce que nous testons réellement et par ce qui y est difficile. Une application React avec des composants en shadow DOM, des iframes pour le paiement et des téléchargements de fichiers réduit vite le champ, donc je vérifie ces points précis plutôt que de lire un tableau de fonctionnalités. Ensuite le langage, et je le pondère fortement : si l'équipe écrit du TypeScript, la suite est en TypeScript, parce qu'alors les développeurs peuvent la lire, la relire et réparer eux-mêmes un test cassé plutôt que de me le renvoyer. Une suite Java posée à côté d'une base de code JavaScript devient la propriété privée d'une seule personne et meurt quand cette personne part. Après cela, le concret : exécution parallèle native, intégration CI propre, et qualité de la sortie en cas d'échec. Ce dernier point est sous-estimé. Le visualiseur de traces de Playwright, où l'on parcourt le DOM au moment de l'échec avec l'activité réseau à côté, fait gagner tant de temps qu'il trancherait à lui seul. Puis je prototype avant de m'engager. Je prends le parcours le plus laid du produit, en général l'authentification avec une redirection ou quelque chose dans une iframe, et je l'automatise en premier. Si le plus dur est gérable, le reste le sera.