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 et réponses avec Max Saperstone de Coveros: Troisième partie - Succès et échec avec l'automatisation des tests

Questions et réponses avec Max Saperstone de Coveros: Troisième partie - Succès et échec avec l'automatisation des tests Temps de lecture : 5 minutes

Dans cette troisième partie de ma conversation (lire Partie un et Deuxième partie) avec Max Saperstone, directeur de l'automatisation des tests chez Coveros, nous discutons des succès et des échecs qu'il a connus avec l'automatisation des tests.

Max a trouvé une expérience similaire à ce que nous voyons sur le marché: une mauvaise planification et un manque d'adhésion à tous les niveaux ne sont pas un bon environnement pour réussir. Cependant, lorsque le retour sur investissement de l'automatisation est bien articulé, le succès est plus probable. Jetons un coup d'œil aux expériences de Max dans ce domaine.

Automatisation des tests: succès et échec

Marc Lambert : Concluons cette discussion avec deux dernières questions. La première question est, donnez-moi un exemple où vous êtes allé dans une organisation pour les aider avec l'automatisation des tests et ce fut un succès. Quelle était la raison pour laquelle cela s'est bien passé et quelque chose qui vous a ouvert les yeux en un instant d'ampoule?

Max Saperpierre: Question interessante. L'un des exemples qui me vient à l'esprit est celui où je suis allé dans une organisation qui faisait tout un tas de tests manuels. Une grande partie de leurs tests consistait à saisir des données et à valider le formulaire. Leur défi était de passer des semaines à tester leur système en raison de la complexité et des différentes combinaisons d'entrées nécessaires pour tester l'application. Ils savaient même qu'ils ne couvraient pas tout.

Nous nous sommes assis avec eux et nous avons discuté des exigences et de tout ce qu'ils recherchaient. Ils ont dit: «Vous savez quoi? Honnêtement, nous ne savons pas. Une partie de ce qu'ils faisaient était de saisir manuellement les codes postaux et l'application signalait différents utilisateurs. Pour chaque utilisateur renvoyé, ils devaient effectuer une autre requête afin de s'assurer que les informations étaient correctes.

Nous avons créé et exécuté des scripts pour eux et ce qui s'est avéré était, je pense, trois quarts de million de combinaisons différentes. Il a fallu environ huit heures une nuit pour exécuter tous ces tests. Ils ont examiné les données et nous avons demandé: «Très bien. Eh bien, que faisons-nous avec ça? Ils ont dit: "Nous n'avons aucune idée."

Nous savions que tout cela se trouvait dans leur base de données, mais il n'y avait aucun moyen pour nous de le tester. Donc, quelqu'un s'est réellement assis avec ces données et cela leur a probablement pris plus d'un mois. Ils sont finalement revenus et ont dit: «Nous avons tout examiné et analysé toutes ces données. Tout n'est pas correct. Ils ont trouvé 30 ou 40 écarts différents, mais le fait qu'ils ne les auraient jamais détectés auparavant - ils procédaient essentiellement à un échantillonnage aléatoire.

Ce que nous avons pu faire, c'est prendre cet ensemble de données et, au lieu de créer des scripts pour ces sorties, nous les avons transformés en tests. Cela prenait encore toute la nuit à courir, mais ils ne passaient pas des semaines à analyser les résultats avec une mauvaise couverture. Ces nouveaux tests ont vérifié que toutes les sorties étaient réellement correctes et l'organisation a pu continuer à ajouter de nouveaux clients à sa base de données avec moins de travail impliqué dans le test des résultats.

Non seulement nous avons trouvé des bogues, mais cette nouvelle automatisation a permis au client de garder une trace de tout. Pour moi, cela a été un grand succès. La combinaison de l'automatisation et des efforts manuels intelligents a libéré beaucoup de temps et d'efforts. En outre, un autre succès a été de trouver des bogues qui auraient absolument un impact sur les résultats de l'entreprise s'ils se retrouvaient dans le produit final.

Marc Lambert : Alors, ils ont obtenu une couverture de test complète en exploitant un ensemble de données complet? Plutôt que d'échantillonner au hasard pour essayer de trouver des défauts.

Max Saperpierre: Plutôt. Encore une fois, il s'agissait d'une couverture complète d'un domaine de l'application. Mais c'était l'utilisation de l'automatisation qui était vraiment cool à voir. Cependant, c'était une entreprise coûteuse et si un client veut vraiment que nous jetions tout ce que nous avons sur le problème, nous le ferons. Dans ce cas, c'était un énorme ascenseur pour notre client, et au final, cela en valait la peine pour eux, ce qui était bien.

Marc Lambert: D'accord, dernière question. Qu'en est-il d'un exemple où le projet a complètement mal tourné? Qu'est-ce qui a fait que cette mise en œuvre a mal tourné? Quelles ont été les leçons apprises?

Max Saperpierre: Je travaillais alors avec une entreprise différente de celle que je suis maintenant et un client nous a fait venir et a dit: «Nous avons vraiment besoin de vous pour automatiser nos tests. Nous avons tous ces testeurs manuels qui passent des semaines à faire leurs tests de régression. Ce dont nous avons vraiment besoin, c'est d'automatiser ces tests et d'accélérer le temps de test. »

C'était il y a quelque temps, et naïvement, j'ai dit: "Bien sûr." J'ai commencé à examiner le problème, à écrire des tests et à parler aux testeurs manuels pour savoir à quoi ils passaient le plus clair de leur temps. Après un mois ou deux, j'ai eu une bonne suite de tests et je les ai remis aux testeurs.

J'ai dit: «Voilà. Vous n'avez plus besoin d'exécuter des tests manuels. Ces tests automatisés étudieront pour vous certains des domaines de l'application. »

Ce qui s'est passé, c'est que les testeurs n'exécutaient pas ces tests automatisés - ou ils les exécutaient, puis ils les réexécutaient manuellement. Comme je l'ai appris, une partie de la raison pour laquelle ils ne les exécutaient pas était que les testeurs ne se souciaient pas de les exécuter. Ils ne leur faisaient pas forcément confiance. Ils n'ont pas vu la valeur qu'ils retiraient de l'automatisation. De plus, de la manière dont les tests ont été construits, il ne s'agissait pas de tests de bout en bout complets que les testeurs avaient l'habitude d'exécuter. Les tests ont exercé des parties de l'application dont ils avaient besoin, mais les testeurs devaient encore exécuter de nombreuses autres étapes pour obtenir la couverture nécessaire.

En fin de compte, ils ont dit: «Eh bien, si je dois exécuter ces tests manuels, nous ne gagnons pas vraiment beaucoup de temps.» Le client n'a tout simplement pas vu cette valeur qui leur était ajoutée. Je pense que le principal enjeu de ce projet était vraiment la communication. Nous avons compris ce à quoi les testeurs passaient beaucoup de temps, mais nous ne leur avons pas parlé de la façon dont ils testaient le logiciel et de ce qu'ils aimeraient pouvoir automatiser. Nous devions leur demander: «Si vous pouviez faire absolument n'importe quoi, qu'est-ce que ce serait?»

Nous nous sommes trop concentrés sur les meilleures pratiques. Le problème était que ces pratiques et les tests que nous avons automatisés ne correspondaient pas à leur flux de travail global de qualité, ce dont ils avaient vraiment besoin pour pouvoir alléger une partie du temps d'AQ.

Je pense que nous aurions dû parler de stratégie de plus haut niveau et avoir une meilleure idée de ce que nous aurions pu faire pour réduire immédiatement le nombre de tests manuels. Nous aurions dû nous demander ce que nous pouvions faire pour que les testeurs soient vraiment enthousiastes à l'idée d'essayer d'utiliser? Ou même, à leur avis, qu'est-ce qui a du sens d'automatiser et avec quelle technologie étaient-ils à l'aise?

Il s'est avéré que certains des testeurs ne voulaient même pas cliquer sur «Go» sur leur machine pour exécuter un test automatisé. Cependant, d'autres étaient à l'aise avec l'automatisation et recevaient un rapport par e-mail chaque matin disant: "Cela a fonctionné, c'est fait." Ces discussions, malheureusement, n'ont pas eu lieu très tôt.

Donc, nous sommes revenus et avons réitéré ce projet. Mais il y a certainement eu beaucoup d'efforts dépensés au départ qui auraient pu être sauvés avec plus de discussions sur cette stratégie de test de haut niveau. Et cela nous ramène à ce premier commentaire dont nous parlions.

Marc Lambert : Donc, sans planification, sans adhésion des équipes, il n'y a pas de confiance ou de valeur perçue. Vous sautez aveuglément dans l'automatisation des tests n'a pas vraiment aidé.

Max Saperpierre: Exactement. Il s'agissait d'automatiser les tests pour l'automatisation des tests plutôt que de vraiment déterminer la valeur réelle et comment nous pouvons en tirer le meilleur parti.

Marc Lambert: Génial. Eh bien, merci beaucoup, Max. J'apprécie vraiment le temps passé avec ça. Je pense que c'était une excellente discussion.

É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.