L’automatisation des tests : à la conquête du graal
Une vision idyllique de l’automatisation des tests
Disposer de tests automatisés est sans conteste la solution idéale pour avoir la capacité à rejouer ses tests à chaque version de l’application et éviter ainsi les régressions. Les premiers pas avec les outils d’automatisation confirment généralement cet idéal, mais ….
Une réalité pas toujours rose
Il apparait que cet idéal ne se réalise pas toujours selon les projets et les contextes :
- Les fonctionnalités et l’interface graphique de l’application ne sont pas assez stables ; elles changent à chaque version et nécessitent d’intervenir sur les scripts d’automatisation pour changer les tests. Le coût de maintenance des tests automatisés devient trop important.
- Les jeux de données des tests ne sont pas stables dans le temps et il est difficile de contrôler les résultats, et analyser chaque résultat prend autant de temps que faire le test.
- La visibilité sur la couverture réelle des tests est assez faible. On a des tests automatisés mais savoir s’ils sont pertinents par rapport aux risques de régressions liés aux évolutions réalisées est une autre question. En gros, on joue les tests mais on n’évite pas les régressions.
Bref, la réalité telle qu’on la rencontre chez nos clients : il y a parfois des tests automatisés, et lorsqu’il y en a, cela ne représente que 20% à 40% de l’ensemble des tests.
Pour les tests manuels qui restent, il faut donc développer une stratégie efficace car les délais et les ressources disponibles font qu’il est rare de pouvoir rejouer 100% de ses cas de test à chaque version.
Définir une stratégie de test de non-régression
Identifier les risques de régression
Pour définir une stratégie de test efficace, il est nécessaire de disposer d’une vision des risques. Sinon, il est difficile de sélectionner les tests pertinents.
Pour autant, en-terme de régression, cette vision des risques est difficile à obtenir. Comme évoqué dans un post précédent sur l’incompréhension entre développeurs et testeurs, les développeurs n’arrivent pas à fournir aux équipes de test des informations fiables sous une forme exploitable pour les testeurs : pas moyen d’identifier réellement les fonctionnalités impactées et encore moins les risques.
Notre technologie réalise, à chaque version, une « photo » de l’application et compare ensuite chaque photo pour identifier précisément les changements réalisés et leurs impacts fonctionnels. Ainsi on a une vision précise des risques à couvrir à chaque version qu’elle soit majeure ou mineure.
Identifier les bons cas de test
Au-delà d’identifier les risques, il est nécessaire de sélectionner les cas de test qui couvrent effectivement ces risques. Plus il existe de cas de test, plus cette sélection est difficile.
Notre technologie est unique: à chaque exécution d’un test, son empreinte réelle sur l’application est enregistrée. On identifie précisément ce qui est testé dans l’application (le code exécuté) par chaque test. C’est le « Test Learning System » Kalistick et cela se fait automatiquement.
Pour découvrir cette technologie, inscrivez-vous à notre webinar !
En corrélant cette prise d’empreinte avec l’analyse de la version, notre plateforme identifie les scénarios à jouer pour couvrir ces risques de régression.
Prioriser les tests selon les enjeux métiers
Au-delà de l’identification des tests, il est souvent nécessaire de les prioriser. Lorsque le temps vient à manquer et que l’on ne peut exécuter tous les tests, il faut être certain d’avoir commencé par les bons. C’est l’approche Risk Based Testing.
En identifiant chaque module fonctionnel de l’application, la plateforme Kalistick permet d’y associer un niveau de criticité métier. Celui ci est ensuite utilisé de manière croisée avec les empreintes et les modifications pour sélectionner et prioriser les scénarios.
Un assistant intégré à plateforme Kalistick permet d’affiner sa stratégie de test jusqu’à obtenir un nombre de scénario qui peuvent être réalisé dans les délais prévu pour les tests et avec les testeurs disponibles.
Des indicateurs fiables de couverture des tests
Durant toute la phase de test, la plateforme Kalistick apporte une vision précise de l’avancée de la couverture des risques, en identifiant les éléments de l’application testée et ceux restant à tester. Ainsi, il est possible d’identifier les éventuels « trous » dans la raquette des tests pour les combler avant la mise en production.
Cette vision de la couverture valorise la complémentarité entre les tests automatisés et les tests manuels, car après une campagne de test automatisée, elle permet d’identifier les points qu’il reste à tester et les tests manuels les plus pertinents.
En conclusion, avec Kalistick il est possible de définir des stratégies de test de régression qui équilibrent délais, coûts et couverture des risques, et de les adapter à chaque contexte d’entreprise, de projet, et de version.
Pour en savoir plus sur cette technologie unique et innovante, nous vous invitons à participer à un webinar. Inscrivez vous ici gratuitement !
