Les outils de tests fonctionnels (appelé aussi outils de capture / relecture) ne constituent qu'un type d'outils parmi tous ceux disponibles sur le marché. Ils permettent certes d'optimiser l'effort de test mais ne doivent surtout pas être considérés comme la seule méthode à adopter pour des tests automatisés. Ils ont en effet des limitations, même lorsque l'on applique les meilleures pratiques.
Tout d'abord, il faut savoir que ce type d'outil se focalise principalement sur les tests effectués via les interfaces graphiques (on parle de tests en boite noire car on ne réalise les tests que via les différents écrans de l'application). Or, pour être le plus efficace possible dans l'exécution de ces tests, il faut également effectuer, en plus des tests en boite noire, des tests en boite grise (basés sur les composants internes de l'application).

La capture / relecture est une fonctionnalité que l'ensemble des outils de tests automatisés proposent aux testeurs. Ils permettent à l'utilisateur d'enregistrer des raccourcis clavier et des mouvements de souris pendant qu'il navigue au sein de l'application. Une fois enregistrées dans un script, ces actions peuvent alors être ré exécuté ultérieurement. Alors que cette méthode peut être bénéfique dans des cas bien spécifiques, il faut savoir que les scripts créés uniquement via des captures comportent des limitations et des inconvénients significatifs. En voici quelque uns, qui peuvent hypothéquer la politique d'automatisation, s'ils ne sont pas traités.

Problèmes liés aux données codées en dur : les scripts sont générés en prenant comme base les interactions de l'utilisateur incluant l'ensemble des données saisies par l'utilisateur ou bien affichées par l'application. Cela pose souvent des problèmes de maintenance car une fois les données modifiées, les scripts deviennent alors  inutilisables. Il est préférable de modifier les scripts pour paramétrer les données saises.

Scripts non modulaires : les scripts générés par les outils de test ne sont généralement pas modulaires, par conséquent ils sont difficiles à maintenir. En effet, il suffit qu'il y ait la moindre modification au sein de l'application, même minime, pour que l'on ne puisse plus, là aussi, réutiliser les scripts.

Manque de standards pour la réutilisation : un des problèmes les plus importants à prendre en compte lors du développement des procédures de test est la possibilité de réutiliser ce qui a été fait précédemment. Etant donné qu'il n'y a pas de standards en ce qui concerne les scripts automatisés, il est fortement recommandé de mettre en place des procédures types afin d'améliorer l'efficacité des tests automatisés. Une bonne approche est de créer des mini scripts isolés s'appelant entre eux (on réduit alors les problèmes de maintenance car chaque script a une fonction bien spécifique :navigation, gestion des messages d'erreurs, gestion des données, ...) mais aussi de suivre des procédures de développement similaires à celles du ou des langages utilisés pour développer l'application.

Ces quelques remarques suffisent à démontrer que la démarche d'automatisation doit suivre une réelle politique de développement, avec sa planification, ses standards et surtout la présence de compétences adéquates.

En suivant ces conseils, on peut certes réduire les différents problèmes associés aux scripts mais il faut bien garder à l'esprit que les outils de capture / relecture ne constituent pas l'unique moyen de répondre à l'automatisation des tests. Il faut en effet des outils additionnels pour permettre d'exécuter les tests de la manière la plus efficace possible tout en atteignant la meilleure couverture possible de l'application.