Découvrez comment la solution Parasoft Continuous Quality permet de contrôler et de gérer les environnements de test pour fournir des logiciels de haute qualité en toute confiance. Inscrivez-vous pour la démo >>

BLOG

Questions-réponses avec Max Saperstone de Coveros: Deuxième partie - Construire une stratégie de test

Questions-réponses avec Max Saperstone de Coveros: Deuxième partie - Construire une stratégie de test Temps de lecture : 8 minutes

Dans cette deuxième partie de ma conversation (la première partie est ici) avec Max Saperstone, directeur de l'automatisation des tests chez Couvertures, nous avons un aperçu de la façon de construire une stratégie de test efficace et ses réflexions sur les outils commerciaux d'automatisation des tests.

Max a trouvé la même situation chez ses clients que chez Parasoft. De nombreuses organisations sont confrontées à des défis avec les tests et la façon dont elles allouent les ressources à chaque phase de test. Max poursuit avec une discussion sur son point de vue sur les outils commerciaux avec une discussion supplémentaire sur les tests sans code.

Stratégie de test et pyramide de test

Marc Lambert: Avoir une stratégie de test API en place signifie que vous pouvez trouver des problèmes très tôt dans le processus et les isoler très tôt est évidemment ce vers quoi l'industrie s'oriente. Mais quand je parle aux gens, ils décrivent leur stratégie de test comme un cornet de crème glacée ou une pyramide inversée. Est-ce ce que vous voyez aussi? Et si oui, quels sont les défis auxquels les équipes logicielles sont confrontées dans ce type de situation de cornet de crème glacée?

Max Saperpierre: J'ai vu toutes sortes de variations sur la pyramide inversée. Certains sont presque un sablier, où il y a beaucoup d'activité en bas et beaucoup en haut, et vraiment pas beaucoup au milieu.

Vraiment, le problème se résume aux coûts et à la vitesse et honnêtement, la vitesse se répercute également sur les coûts. Les tests unitaires sont peu coûteux à exécuter et doivent être exécutés en quelques secondes. Ces tests unitaires devraient vraiment constituer le bas de votre pyramide. Ils doivent être relativement bon marché à créer et à entretenir. S'ils ne font pas partie de ces choses, rapides et maintenables, etc., alors ce ne sont pas des tests unitaires ou vous faites simplement un mauvais travail avec eux.

Une grande partie de ce que je fais est de travailler avec les développeurs, les testeurs et les analystes des exigences. J'ai besoin de comprendre ce qui est vraiment nécessaire pour être testé dans différents domaines, et tout le monde est sur la même longueur d'onde. Par exemple, lorsque vous testez une base de données, ce n'est plus un test unitaire, c'est vraiment un test de composants. Je vois des équipes qui ont un tas de tests unitaires mais avec beaucoup de tests d'intégration mélangés aussi. Un mauvais isolement et des tests unitaires complexes ralentissent le processus de test unitaire.

La raison pour laquelle vous voulez que les tests unitaires soient rapides est d'obtenir rapidement des commentaires, même avant la compilation du code. Vous voulez vous assurer que le code fait au moins ce que le développeur veut. Parce que s'il ne fait pas ce que le développeur veut, il n'y a aucune raison d'aller plus loin.

Les tests fonctionnels, généralement sous la forme de tests d'interface utilisateur, sont intrinsèquement fragiles. Ils sont plus difficiles à entretenir. Alors, pourquoi une équipe en voudrait-elle plus? Je vais dans différentes organisations et ils disent: "Eh bien, l'automatisation ne fonctionne pas pour nous." Et je dis: «Très bien. Eh bien, regardons vos tests. » Ce que je trouve est une combinaison de trois choses: ils ont trop de tests d'interface utilisateur, ils sont trop difficiles à maintenir et ils sont mal écrits. Je leur dis qu'ils peuvent réduire le nombre de tests d'interface utilisateur en raison de toutes ces autres couches de tests (unité et composant) les prenant en charge et lorsqu'ils les améliorent, je peux les aider à rédiger un meilleur test fonctionnel par rapport à ce qu'ils ont aujourd'hui.

Marc Lambert: Vous avez mentionné quelque chose sur lequel je veux revenir, car je vois ce problème depuis que j'ai rejoint Parasoft, il y a 15 ans. Quand quelqu'un dit: «Oui, je fais des tests unitaires», mais quand vous y arrivez, ils ne font pas de tests unitaires, ils sont en fait plus haut dans la pyramide. Comme vous l'avez dit, le simple fait d'utiliser un cadre de tests unitaires ne signifie pas nécessairement qu'ils effectuent des tests unitaires. Pourquoi pensez-vous que c'est? Quel est le défi pour quelqu'un de créer un test unitaire correct ou réel?

Max Saperpierre: Ce n'est certainement pas un incident isolé que j'ai vu à un ou deux endroits. Honnêtement, il est difficile d'écrire un bon test unitaire, par opposition à un test d'intégration ou de système. Si vous voulez faire de bons tests unitaires, vous devez vous moquer de tout ce dont dépend l'unité.

Ecrire des moqueries n'est pas facile. Cela demande plus de travail; cela nécessite plus de bibliothèques. Les développeurs ont en fait du mal avec cela; ils peuvent ne pas savoir comment le faire ou ne pas avoir le temps de le faire. Pour ces raisons, ils peuvent décider de prendre un raccourci pour connecter rapidement une base de données, par exemple, pour ce qui est censé être une solution à court terme. Une semaine plus tard, tout le monde utilise ce même code et il est trop tard pour le changer. La réponse à cela lorsque je signale ces problèmes est: «Eh bien, nous écrivons des tests. C'est mieux que rien. Et ça l'est, mais ces équipes arrivent rapidement à cet endroit où leurs tests ne sont pas aussi efficaces qu'ils pourraient l'être.

Je ne pense pas vraiment que ce soit de l'ignorance pour la plupart. Je pense vraiment que dans la majorité des cas, c'est un manque de temps. En fin de compte, et je le vois dans chaque organisation, la direction se soucie beaucoup plus de faire sortir le produit que de faire les choses correctement, au départ. Donc, ces équipes accumulent de la dette technique et, à court terme, il n'y a pas de problème. Cependant, le vrai problème réside dans le fait que lorsqu'ils ne récupèrent pas et ne réduisent pas la dette, lorsqu'ils vont refactoriser du code ou changer quelque chose, ces «tests unitaires» complexes et non isolés deviennent de plus en plus fragiles, et de plus en plus de choses commencer à se casser. Même si au départ ils avaient de bonnes intentions, cette accumulation de mauvais tests et de dettes techniques cause les problèmes que je vois.

Outils d'automatisation des tests

Marc Lambert: Lorsque vous aidez les clients à déployer leur stratégie de test et que vous avez déterminé où l'automatisation doit être appliquée, ils doivent prendre des décisions technologiques. Par exemple, ils doivent décider s'ils vont utiliser des solutions open source ou commerciales? Ou construisent-ils simplement leur propre cadre? Où recommandez-vous qu'ils commencent le processus de prise de décision?

Max Saperpierre: C'est une excellente question, Mark. Et c'est en fait l'une des questions qui me sont le plus posées: quel outil dois-je utiliser? Quel cadre dois-je utiliser? Le client est généralement sur le point de commencer à faire de l'automatisation ou de se lancer dans les tests d'API. Malheureusement, la réponse que je donne toujours est «Oh, je ne sais pas», parce que je n'aime pas l'approche de l'outil d'abord.

J'aime vraiment que mes clients prennent du recul et réfléchissent à leurs besoins. Que regardent-ils du point de vue de l'analyse des résultats des tests et de la traçabilité? Qu'est-ce qu'ils essaient d'accomplir? Quels niveaux de la pyramide de test veulent-ils que les outils prennent en charge? S'agit-il simplement de tests sur l'interface utilisateur, l'API, les tests unitaires? Quelle est la stratégie globale de test?

Une fois que j'aurai répondu à toutes ces questions. Ensuite, je vais étudier certains des cadres et des outils qui existent sur le marché et prendre des décisions basées sur la recherche des exigences du client. Je suggère toujours de commencer par utiliser un outil open source. Je suis un grand fan d'essayer de faire les choses aussi agiles que possible, et une grande partie de cela est l'expérimentation. Parfois, comme vous le savez, l'échec fait partie de l'expérimentation. Vous pouvez trouver le bon outil, et cela peut fonctionner correctement au départ, ou non. Si vous devez payer de l'argent pour ces outils, l'expérimentation peut coûter cher et vous risquez de ne pas obtenir ce que vous voulez.

Après avoir expérimenté des outils open source, je recommande à mes clients de regarder les outils commerciaux qui ont des périodes d'essai gratuites pour essayer de vérifier les choses. À ce stade, je leur recommande de commencer à analyser davantage les solutions commerciales.

Lors de l'examen des outils open source, l'un des principaux éléments à prendre en compte est le support. Il existe différents frameworks et outils open source et le simple fait qu'ils soient gratuits ne signifie pas qu'ils sont des déchets, mais cela ne signifie pas non plus qu'ils sont bons non plus. Par exemple, il y avait une stigmatisation entourant Selenium et les gens se sont demandé si un outil gratuit pouvait être utile. Maintenant, il y a une énorme communauté qui y contribue et c'est l'outil d'automatisation numéro un pour les tests d'interface utilisateur malgré le fait que vous pouvez simplement aller de l'avant et le télécharger gratuitement.

Être conscient du support disponible est important pour les outils open source. C'est aussi l'un des éléments clés qui différencie les bons projets open source; le soutien de la communauté. Vous posez des questions, les gens obtiennent des réponses assez rapidement. Selenium a une foule de personnes dédiées à répondre aux questions là-bas. Un soutien communautaire comme celui-là, qu'il s'agisse d'outils payants ou gratuits, est vraiment important.

Un danger avec les outils open source est la possibilité de rester coincé avec un bug ou un problème d'utilisation et le projet est abandonné, bien que cela puisse également arriver avec des outils commerciaux. Cependant, si je n'ai pas rendu mes tests portables, c'est un problème que j'ai créé.

Tous ces différents outils et approches comportent des compromis lorsque vous les examinez. Avec le niveau de soutien et de soutien approprié, pour moi, cela rend toujours la communauté open source un peu plus précieuse.

Outils commerciaux

Marc Lambert : S'il y a des problèmes avec le verrouillage des fournisseurs, recherchez-vous une technologie qui peut facilement transférer des tests entre différents frameworks? En d'autres termes, un aspect critique de l'évaluation des solutions commerciales est-il la capacité de passer d'un outil à l'autre et de s'assurer que vous n'êtes pas enfermé dans leur plate-forme?

Max Saperpierre: Oui, cela dépend vraiment. Pour de nombreux fournisseurs, la prise en charge de l'interchangeabilité est une bonne chose et pour certains outils, cela fonctionne très bien. Cependant, lorsque vous faites une première expérimentation, vous ne voulez pas nécessairement commencer avec des outils commerciaux. C'est douloureux si je dois réécrire six suites de tests différentes juste pour essayer six logiciels différents.

Marc Lambert : Alors, open source d'abord jusqu'à ce que vous frappiez un mur, puis cherchez quelque chose qui peut vous aider à aller au-delà de ce mur peut-être?

Max Saperpierre: Probablement. Il existe de nombreuses solutions différentes qui ont une version gratuite ou un modèle «freemium», où vous payez pour des fonctionnalités supplémentaires en plus. Il existe également des versions payantes en plus de cela. Beaucoup de ces outils me plaisent beaucoup, car une fois que je les regarde, je me rends compte que je peux faire toutes ces choses sympas. Pour moi, cela en vaut souvent la peine car si l'outil a toutes les fonctionnalités appropriées et que je peux faire une grande partie de mon développement à l'avance, je n'ai besoin que d'une ou deux licences pour exécuter les outils pendant les builds. Ce n'est pas si mal.

Encore une fois, cela dépend aussi du niveau technique de l'équipe. L'avantage des produits payants est qu'ils ont généralement un support prêt pour vous. si l'équipe n'est pas aussi compétente techniquement avec les outils de test et qu'elle a besoin de plus d'assistance, elle est disponible. En ce qui concerne les produits Parasoft, le support est l'une des choses pour lesquelles les clients paient, ce qui a beaucoup de sens d'un point de vue stratégique.

Test sans code

Marc Lambert: Pour répondre à votre commentaire sur les utilisateurs non techniques, par exemple, quelqu'un qui n'est pas à l'aise avec le codage pour Selenium, les outils de test sans code seraient-ils une solution? Que signifie pour vous ce test sans code? Quelles sont vos pensées?

Max Saperpierre: Je vois des outils d'automatisation de test sans code depuis environ cinq ans à ce stade. Je pense à la première fois que j'ai été mis au courant d'eux, ils étaient vraiment super. J'aime le fait qu'ils peuvent rendre beaucoup de choses relativement simples et certaines d'entre elles vont au-delà du simple aspect sans code. Certains outils vous permettent de plonger en cas de besoin et de commencer à écrire des choses en Java ou Python, par exemple. Avoir la capacité de tester sans code et la possibilité d'ajouter du code si nécessaire est important lorsque vous avez les équipes les moins techniques.

Dans mon esprit, chaque type d'outil a un coût. Vous devez payer plus pour les personnes qui ont une formation en codage et moins d'argent pour les testeurs moins techniques. Cependant, cela pourrait être compensé par la technologie et payer un peu plus pour le support du fournisseur. Donc, je pense que les tests sans code offrent vraiment une excellente solution pour cela.

Le grand défi que je vois est qu'il y a beaucoup d'acteurs différents dans cet espace. Je n'ai pas vraiment vu un fournisseur devancer un autre. Les vendeurs semblent avoir encore un petit pied à terre. Bien que cela signifie qu'il existe certainement un marché en croissance pour les outils d'automatisation des tests, ces outils pourraient ne pas résoudre les principaux problèmes que nous rencontrons dans le domaine de l'automatisation des tests.

J'ai mentionné plus tôt qu'il y avait deux choses que je considère généralement comme des problèmes: les équipes passent trop de temps à maintenir leurs tests parce qu'elles sont fragiles et qu'elles se cassent. L'autre est que les gens écrivent de mauvais tests. Ce sont ce que je considère comme les principaux points faibles de l'automatisation des tests en général. Je ne pense pas que l'automatisation sans code résout réellement ces problèmes. Ils facilitent grandement la rédaction des tests, mais je ne pense pas que ce soit le problème le plus courant. Ces outils facilitent potentiellement l'écriture du même mauvais test.

Un grand nombre de ces problèmes et le manque de succès de l'automatisation sont dus à l'absence de stratégie de test. Je pense que les outils et l'automatisation n'ont pas encore vraiment explosé, ils résolvent certainement des problèmes, mais ils ne résolvent pas le plus gros problème de l'espace.

Dans le prochain article, nous parlons à Max de ses expériences d'échecs et de succès dans les tests et l'automatisation des tests.

Écrit par

Marc Lambert

Vice-président des produits chez Parasoft, Mark est chargé de s'assurer que les solutions Parasoft apportent une valeur réelle aux organisations qui les adoptent. Mark travaille chez Parasoft depuis 2004, travaillant avec un large éventail de clients de Global 2000, des implémentations technologiques spécifiques aux initiatives plus larges d'amélioration des processus SDLC.

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.