Vous effectuez des tests fonctionnels et vous êtes confrontés à ces défis ?

• Votre produit doit-il être commercialisé plus rapidement ?

• Sa complexité augmente-t-elle au fil des versions ?

• Vos cycles de publication sont-ils de plus en plus courts ?

• Vous devez réduire les coûts des tests ?

Si vous êtes confronté à l’un ou à l’ensemble de ces défis, vous lisez le bon article !

Dans de nombreuses conférences, forums et discussions, nous entendons beaucoup parler de nouvelles pratiques et méthodologies de développement pour résoudre ces problèmes. Mais nos défis en matière d’essais demeurent.

Le test AGILE est une bonne chose, mais il n’est pas suffisant puisqu’il ne résout pas notre problème d’automatisation des tests afin qu’ils puissent être effectués assez rapidement. Alors, comment accélérer la mise sur le marché d’un produit qui devient de plus en plus complexe et qui fait l’objet d’une pression constante pour réduire les coûts ? Il est peu probable que la solution soit de continuer à utiliser des pratiques de test vieilles de plus de 20 ans.

En fait, l’automatisation des tests par l’utilisation de l’enregistrement et de la lecture reste un test manuel. Réduire le backlog d’automatisation des tests est une bonne chose, mais la réalité est que vous ne serez jamais en mesure de coder tous vos scripts de tests de régression. Vous n’avez ni le temps ni le budget pour le faire. Ce n’est donc pas la solution.

Si nous partons de ce point, où est le problème ? Je vois souvent des personnes confondre l’efficacité ou la qualité des tests avec le nombre de tests. Combien de tests avez-vous ? Et alors ? Êtes-vous sûr qu’ils couvrent tous les cas de figure ? Sur la base de vos tests, connaissez-vous la couverture réelle de la fonctionnalité que vous êtes censé tester ? Et si, comme dans de nombreux projets, vous avez des centaines ou des milliers de tests, savez-vous ce que chacun de ces tests fait réellement ? Avez-vous le temps d’exécuter tous ces tests ? Je pense que vous comprenez ce que je veux dire : ce n’est pas le nombre de tests qui importe, mais la qualité et l’exhaustivité de ces tests.

Lorsque vous créez des tests sans modèle du système à tester, la seule façon de juger de la qualité de vos tests est le nombre de tests et peut-être la couverture des exigences. Aujourd’hui, les tests avec des modèles apportent une nouvelle dimension aux tests et cette nouvelle dimension est une nouvelle façon de mesurer la qualité : la couverture fonctionnelle. La couverture fonctionnelle vous donne plus d’informations sur ce que vous testez. Vous ne modéliserez pas les tests ou les scénarios de test, mais la fonctionnalité que vous souhaitez tester sera capturée dans un modèle. Il est toujours préférable de décrire un paysage en montrant une image plutôt qu’en le décrivant avec des mots. En modélisant graphiquement votre fonctionnalité, vous comprendrez mieux la fonctionnalité à tester, vous serez en mesure de couvrir automatiquement tous les aspects de votre fonctionnalité et vous obtiendrez donc de meilleurs tests. Laissez l’outil de conception des tests décrire ce paysage pour vous ! L’outil qui fonctionne de cette manière testera des fonctions que vous n’avez pas vues la première fois ou pas du tout en raison de la complexité de l’application, en particulier les chemins négatifs.

Autre gain de temps et d’amélioration de la qualité, un outil de conception de tests qui génère des cas de test directement à partir d’un modèle du fonctionnement correct attendu du système génère également les oracles de test, c’est-à-dire les résultats attendus lors de l’exécution des cas de test. Ainsi, au final, vous aurez plus de temps pour tester et vous aurez plus de temps pour tester votre application plus en profondeur et SAVOIR ce que vous avez testé et pourquoi. En tant que testeur, cette confiance est une bouée de sauvetage – ou du moins une bouée de sommeil. Mais attention, et je le répète, je ne parle pas de modélisation des tests mais de modélisation de la fonctionnalité à tester. (Si vous voulez savoir pourquoi, veuillez suivre cet autre article :« Comment les tests basés sur des modèles peuvent-ils générer des tests auxquels je ne peux pas penser« ).

En outre, les modèles vous aideront à garder le cap à chaque version de votre application. En cas de changement, vous pouvez rapidement mettre à jour votre modèle et ensuite mettre à jour vos tests et vos scripts de test automatiquement en générant simplement des tests à nouveau. Deuxièmement, entre deux versions d’une application, vous pouvez évaluer votre ancienne suite de tests. Quel pourcentage de vos fonctionnalités est couvert par votre suite de tests actuelle ? Vous pourrez également générer de nouveaux tests pour augmenter la couverture de votre suite de tests et voir quels sont les cas de test précédents qui deviennent invalides en raison de la modification du fonctionnement du système capturé dans le modèle. Vous gérez la complexité chaque fois que vous utilisez et mettez à jour votre modèle. En d’autres termes, je vous recommande de conserver vos connaissances dans un modèle graphique. Votre outil doit générer pour vous des cas de test basés sur la fonctionnalité modélisée et mettre automatiquement à jour vos scripts de test et votre documentation afin que vous disposiez d’une analyse d’impact. Vous gagnerez beaucoup de temps et réduirez certainement les coûts et les délais de mise sur le marché.

Étant donné que l’outil de conception des tests comprend l’ensemble du fonctionnement du système à tester, il génère des cas de test qui couvrent 100 % du fonctionnement du système. C’est très différent de la création manuelle de cas de test ou de scénarios et de l’obtention d’une couverture à 100 % de ce que vous avez écrit à l’origine. Qu’avez-vous manqué ? Vous ne le saurez que lorsqu’un utilisateur trébuchera dessus après la livraison. Espérons qu’il ne s’agira pas d’un bogue critique.

En conclusion, une bonne couverture de test ne signifie pas des centaines et des milliers de cas de test, mais de bons cas de test connus basés sur une couverture fonctionnelle complète. Alors pourquoi ne pas exiger une couverture fonctionnelle de 100 % à chaque fois ?

Lire la suite sur : www.conformiq.com/blog/

Merci de votre lecture ! N’hésitez pas à nous faire part de vos commentaires !