Vous cherchez une alternative à Testim ?

La différence fondamentale est le paradigme de création des tests. Testim repose sur un enregistreur (recorder) via une extension navigateur : on navigue dans l'application et l'outil capture chaque clic, saisie et assertion pour les convertir en étapes de test. Thunders, lui, part de l'intention : on décrit le scénario en langage naturel et le moteur de parsing génère le test exécutable, assertions et cas limites compris. En pratique, Testim est action-based (on capture ce qu'on fait), Thunders est intent-based (on déclare ce qu'on veut valider). Cette distinction se répercute sur la maintenance, l'accessibilité et la résilience, les points développés ci-dessous.

Un enregistreur fige une séquence d'interactions liées à l'état de l'interface au moment de la capture. Le résultat reste dépendant de la structure du DOM et des sélecteurs sous-jacents, même quand une couche d'IA vient les stabiliser après coup. Thunders inverse la logique : le test décrit l'objectif fonctionnel, et c'est l'IA qui détermine à l'exécution comment l'atteindre. On évite ainsi la re-capture manuelle à chaque évolution du parcours, et on retire la contrainte de devoir rejouer l'application pour créer ou mettre à jour un test.

Le self-healing de Testim fonctionne en construisant une empreinte composite de chaque élément à partir de plusieurs attributs, puis en comparant l'élément modifié à cette empreinte stockée pour retrouver la bonne cible. C'est efficace, mais cela reste une réparation au niveau du localisateur. Plusieurs analyses distinguent d'ailleurs le healing par repli de localisateur (Testim) du healing basé sur l'intention, ce dernier absorbant davantage de changements. Thunders se place sur le registre de l'intention : puisque le test décrit l'action plutôt qu'un sélecteur codé en dur, une refonte d'interface qui casserait une empreinte n'invalide pas l'objectif décrit. C'est ce qui sous-tend l'argument d'une réduction de maintenance pouvant atteindre l'ordre de 80 à 88 %.

L'enregistreur de Testim abaisse la barrière par rapport à Selenium, mais il a une limite nette : dès qu'un test casse ou qu'il faut ajouter de la logique conditionnelle, on retombe dans le JavaScript, ce qui exclut de fait les profils non techniques. Thunders donne à chaque rôle, QA, produit et métier, la même façon de créer, relire et exécuter des tests : le langage courant, sans IDE, sans CLI et sans recours au JavaScript. Un PM ou un analyste peut décrire un parcours de checkout sans connaître ni sélecteurs, ni composants réutilisables, ni code. La création de tests sort ainsi de la seule équipe capable de déboguer des scripts d'enregistreur.

Chez Testim, une couverture d'API complète passe généralement par l'intégration d'un outil séparé ou par des étapes personnalisées bricolées, en dehors du flux de test principal. Thunders unifie les tests d'UI et d'API sur une seule plateforme et dans un seul rapport : on décrit les parcours d'API en langage naturel à côté des tests d'interface, l'authentification et le chaînage des endpoints sont pris en charge automatiquement, et les assertions s'écrivent elles aussi en langage naturel. Il n'y a ni configuration supplémentaire, ni multiplication d'outils, ni licence dédiée à l'API. Une plateforme, un langage, un rapport.

Deux leviers. Côté temps : Thunders revendique une réduction du temps de création des tests de l'ordre de 90 % (d'un cycle spec vers sélecteur à un simple prompt), plus la maintenance évitée grâce à l'approche intent-based. Côté coût et prévisibilité : Testim ne publie pas de tarification en libre-service, les prix restent opaques jusqu'à un échange commercial, et la meilleure valeur s'obtient à grande échelle, ce qui rend le coût difficile à justifier pour les petites équipes. L'argument ROI de Thunders combine donc gain de temps mesurable et modèle plus accessible, là où le retour sur Testim dépend fortement du volume.

Le point de dépendance chez Testim est double : les tests s'exécutent dans un environnement d'exécution propriétaire, et le modèle d'IA que ton équipe entraîne au fil des tests (l'apprentissage des Smart Locators) reste attaché à la plateforme, donc difficile à récupérer si tu la quittes. Thunders réduit ce verrouillage de plusieurs façons. D'abord par l'approche fondée sur l'intention, qui limite la dépendance à un modèle IA spécifique accumulé sur la plateforme. Ensuite par des connecteurs natifs vers GitHub, GitLab, Jenkins, Jira, Linear et Xray, sans code de liaison à maintenir. Enfin par des options d'auto-hébergement et de déploiement on-prem, annoncées comme à venir, qui répondent aux équipes voulant garder la maîtrise de leur environnement d'exécution. L'idée : ne pas enfermer ni les tests, ni l'intelligence accumulée, dans un format propriétaire.

Thunders couvre le web en cross-browser, les applications natives iOS et Android, et les flux API, le tout depuis la même interface en langage naturel. Testim adresse le web, le mobile et Salesforce, mais avec des modules distincts et une expérience historiquement centrée sur le web (certains retours mentionnent des limites côté mobile). L'argument de Thunders est l'unification : un seul langage et un seul flux de travail quel que soit le type d'application testée.

Parce qu'un test Thunders encode une intention (aller au paiement, ajouter un produit, finaliser) et non un sélecteur CSS figé. Testim atténue déjà le problème avec ses Smart Locators, qui comparent l'élément modifié à une empreinte multi-attributs, mais dès qu'un remaniement dépasse ce que l'empreinte reconnaît, l'intervention manuelle revient. Thunders détecte l'écart via son auto-healing basé sur le ML puis réaligne le test sur l'objectif décrit, ce qui lui permet de revendiquer des tests qui survivent aux refontes d'UI sans mise à jour manuelle.

Le langage naturel comme dénominateur commun : QA, dev, PM et analystes travaillent sur les mêmes tests, lisibles par tous, ce qui supprime la traduction entre ce que le métier veut valider et ce que le test technique fait. La collaboration ne s'arrête pas à la rédaction : la création de tickets en un clic envoie les échecs dans Jira, Linear ou GitHub avec le contexte complet, les étapes de reproduction et les captures d'écran, là où Testim garde l'essentiel du reporting à l'intérieur de sa propre interface. Les tests deviennent une documentation vivante mise à jour à chaque exécution, et l'intégration CI/CD native, sans configuration, réduit le travail de plomberie entre outils. L'objectif affiché est de faire de la qualité une responsabilité partagée par toute l'équipe produit.