L'automatisation des tests permet de gagner du temps, non seulement pour la première exécution, mais surtout pour les suivantes.
Bien que la technicité soit un atout dans ce domaine, ce n'est certainement pas l'atout majeur puisqu'au delà des langages et des technologies, les notions de conception, de couverture, de lisibilité et de maintenabilité distinguerons les bons scripts des inutiles.
Au fil de mes expériences je peux noter en automatisations ces points qu'il me semble nécessaire de vérifier :
Les tests autos ne doivent pas être des "one shot" mais ils doivent rester un maximum fonctionnel sur des environnements différents et être réutilisables plusieurs fois notamment pour de la non régression.
Et oui être technique ne suffit pas! Il peut être nécessaire d'utiliser des techniques de conceptions et d'identifier aussi bien des cas valides que des cas invalides. Rédiger des cas de tests c'est un art et solliciter le regard des autres n'est pas de trop!
Il faut donc couvrir un maximum d'aspect mais toujours avec un minium de cas de test. Penser au temps d'exécution et s'essayer de construire un patrimoine pertinent et sans redondance.
Un script clair et lisible c'est la base, ne négligez pas la structure et les commentaires pertinents. Le "turn over" ça arrive dans toutes les entreprises et il faut penser au personnes qui pourraient repasser derrière vous et tenter de vous relire.
Le dernier point est crucial, que ce soit à l'aide de langages ou d'outils low-code / no-code, il est primordial de comprendre la notion "d'objet" si chère à certains langages de programmation. Un objet / module s'il est le même dans plusieurs script doit être modifiable en un seul point tout comme les actions / fonctions / méthodes qui se répètent. Afin d'éviter lors d'un changement de refaire la même modification sur plusieurs script.
En automatisation web, on appel ce principe le Page Object Model, autrement connu sous le nom de POM.
Et vous? Quelles sont vos recommandations?