Découvrez comment intégrer facilement l'analyse statique, les tests unitaires et d'autres méthodes de test de logiciels C et C++ dans votre pipeline CI/CD. Inscrivez-vous pour la démo >>

Questions-réponses avec Max Saperstone de Coveros: Première partie - Premiers pas avec l'automatisation des tests

Par Marc Lambert

19 février 2020

5  min lire

Dans cet ensemble de trois articles de blog, nous avons un aperçu de la manière de créer une stratégie de test efficace et de l'utilisation de l'automatisation des tests dans le cadre de cette stratégie. J'interviewe Max Saperstone, directeur de l'automatisation des tests à Couvertures. Max est un ingénieur de test expérimenté qui se concentre sur l'automatisation des tests dans le processus CI / CD. Il prête main-forte à divers clients pour les aider à lancer leurs efforts de test et d'automatisation. Max est également un développeur agile expérimenté et certifié et est recherché pour des allocutions lors de conférences de test et de développeurs Agile. Nous avons la chance d'avoir l'expérience de Max à ce stade pour discuter de sujets qui nous tiennent à cœur ici chez Parasoft.

Il s'agit de la première partie d'une série en trois parties qui traite des réflexions de Max sur la mise en route de l'automatisation des tests. Une chose est claire, Max aime aider ses clients à prendre du recul et à considérer la situation dans son ensemble avant de se plonger dans l'automatisation des tests. Aider ses clients à répondre à des questions importantes telles que «pourquoi est-ce que j'automatise les tests?» afin qu'ils puissent fixer des objectifs clairs pour leurs efforts. Nous discutons également brièvement des tests d'API et Max semble être sur la même page que nous - les tests d'API sont d'une importance cruciale. Regardons ce que Max a à dire:

Premiers pas avec l'automatisation des tests

Marc Lambert : Salut Max, c'est super d'être à nouveau avec toi. Je sais que votre rôle chez Coveros consiste à aider et à aider les clients avec des stratégies d'automatisation de test efficaces. Pouvez-vous nous dire ce que vous pensez être une stratégie d'automatisation de test efficace? Par où devrait commencer une équipe?

Max Saperpierre : Salut Mark, c'est une excellente question! C'est intéressant parce que, comme vous le savez, ma spécialité est l'automatisation, et malgré cela, lorsqu'une équipe démarre, mon conseil est généralement: «Ne vous contentez pas de vous lancer dans l'automatisation».

Le meilleur point de départ est d’examiner l’assurance qualité dans son ensemble. Donc, la première chose à comprendre est ce que signifie «la qualité dans son ensemble» pour votre projet et comment vous allez le vérifier. Ce n'est qu'après avoir connu la réponse à ces questions que vous pourrez vraiment décider de ce qu'il faut automatiser et de ce que vous ne le font pas veulent automatiser.

Pour moi, c'est toujours l'un des plus grands défis. Je vois beaucoup d'équipes se lancer pour commencer à écrire des scripts Selenium ou des scripts QTP, et elles ont tout un tas de «trucs». Mais finalement, comment ce truc est-il utilisé? Comment gérez-vous les résultats des tests? Comment décidez-vous quand expédier le produit?

Ma recommandation est généralement de prendre du recul et de déterminer ce que vous devez vérifier - et comment le faire. Il existe une méthode vraiment cool appelée le MSCW.

Marc Lambert : Quelle est la méthode MSCW?

Max Saperpierre : La méthode MSCW n'est en réalité qu'un acronyme. C'est quoi Must vous automatisez, quoi Sdevez-vous automatiser, quoi Cvous automatiseriez-vous, et quoi Wn'automatisez-vous pas. L'idée est de consacrer du temps et de réfléchir à votre stratégie d'automatisation, pour déterminer où se situe le meilleur rapport qualité-prix.

Pour moi, cela revient toujours au ROI. Quels sont les tests qui s'exécutent de manière cohérente? Quels sont les domaines de grande valeur de votre application dans lesquels vous ne pouvez tout simplement pas permettre que quelque chose se passe mal? Qu'est-ce qui aura le plus d'impact sur les utilisateurs? Vous commencez par ce qui tombera toujours sous vos «must», et tombez toujours sous vos «devoirs».

Ensuite, vous entrez dans d'autres domaines de vos «pourrais» et «désirs». Par exemple, tester la convivialité, c'est une chose vraiment difficile et difficile à automatiser: comment dire à une machine ce qui semble bien par rapport à ce qui ne l'est pas?

Les intégrations tierces sont un autre domaine difficile à automatiser. Par exemple, supposons que vous ayez une intégration FitBit, vous pourrez éventuellement l'automatiser. Mais cela prendra des semaines ou des mois à faire. Cela vaut-il vraiment la peine de passer à l'automatisation?

Lorsque j'écris une stratégie de test, je passe du temps à déterminer mon plan de test à ce niveau élevé. Quels sont les domaines de l'application qui me tiennent vraiment à cœur? Quels sont les domaines qui seront faciles à automatiser? Je commence généralement par ça.

Marc Lambert : Alors, comment organisez-vous cela?

Max Saperpierre : Bien sûr, cela parle toujours d'un niveau fonctionnel. Dès que vous prenez du recul et réfléchissez à votre stratégie en termes de pyramide des tests et des différents rôles impliqués dans la qualité, car ce ne sont pas que des testeurs. Les développeurs doivent écrire des tests unitaires et d'intégration dans la partie inférieure de la pyramide de test. À un certain moment, les testeurs prennent le relais, comme la pointe d'un iceberg. Sous la surface, vous voulez vous assurer que tout ce code est testé avec des tests unitaires - assurez-vous que le code fait ce que le développeur dit que le code devrait faire. La couche suivante concerne les tests d'intégration, qui garantissent que les différentes parties de l'application fonctionnent réellement comme les autres parties le pensent. Enfin, vous avez les testeurs, ils sont au sommet de l'iceberg et ils veulent vraiment s'assurer que l'application dans son ensemble fait ce que le client final veut réellement.

Si vous ne faites pas correctement ces deux parties sous-jacentes - là où l'automatisation est payante et c'est rapide et facile à ces bas niveaux - les erreurs au niveau supérieur sont difficiles à déboguer et à corriger. Tu n'as aucune idée. «Est-ce un problème fonctionnel? Est-ce un problème de composant? Ou est-ce un problème de code? » Mais si vous savez que toutes ces autres choses fonctionnent correctement, il est très facile de rechercher ces problèmes.

Cependant, si vous savez que tous les tests unitaires et d'intégration ont réussi, il est plus rapide de diagnostiquer les pannes en tant que problèmes fonctionnels probables. La situation inverse, avec une mauvaise stratégie d'automatisation, est une lutte pour identifier la cause première, beaucoup de débogage, un bon problème de stratégie d'automatisation qui est beaucoup plus simple.

Test d'API

Marc Lambert: Ici, chez Parasoft, nous parlons des tests d'API depuis près de deux décennies maintenant, mais l'adoption des tests d'API est encore nouvelle pour de nombreuses personnes. Cela peut être dû à la nature cachée des API, c'est dans la couche entre l'interface utilisateur et le code et de nombreuses personnes ne le voient pas. Quelle est selon vous la voie à suivre? Comment les organisations exploitent-elles vraiment les tests d'API de la manière la plus efficace possible?

Max Saperpierre: C'est une excellente question. J'adore les tests d'API car venant d'un testeur, qui n'a pas nécessairement accès à tout le code, c'est un excellent moyen de faire beaucoup de tests du point de vue de la boîte noire. Ce n'est pas parce que je ne sais pas ce que fait le code que je n'ai pas une bonne compréhension de l'API.

J'espère que je peux voir à quelles entrées une API attend et en sortie qu'elle génère, s'il y a un document WSDL ou swagger qui lui est associé. Les tests d'API me permettent de faire des tests très rapidement car ils sont basés sur les données à ce stade. J'ai un point final, je lance autant de combinaisons différentes d'entrées que je pense être valides, et j'en vérifie toutes les différentes sorties. Je n'ai pas nécessairement vraiment besoin d'en savoir autant sur le code et il existe tout un tas de très bons frameworks qui gèrent cela pour moi.

Donc, du point de vue des testeurs, c'est pourquoi j'aime les tests d'API. De plus, ils sont rapides et généralement non cassants. Si vous avez une organisation qui met en place des contrats et a des points de terminaison bien définis, qui ne seront pas souvent modifiés, il y a très peu de maintenance à effectuer sur les tests d'API et ils vous donnent beaucoup d'informations sur le système.

Marc Lambert: Je pense que ce que vous venez d'évoquer, à propos de la rapidité et de la stabilité des tests d'API, c'est vraiment pourquoi ils sont devenus très précieux. En outre, ils constituent un excellent mécanisme de communication entre les testeurs et les développeurs au sein d'une organisation.

Max Saperpierre: Absolument. En règle générale, lorsque je parle de tests d'intégration aux organisations, les tests d'API en constituent une grande partie. Ils sont rapides, ils vous donnent beaucoup d'informations très précieuses et sont beaucoup plus stables que les tests d'interface utilisateur.

Dans le prochain article, nous parlons à Max de la création d'une stratégie de test et de son point de vue sur la pyramide des tests.

Écoutez plus de Max Saperstone dans notre enregistrement webinaire sur la façon d'être plus efficace dans la fourniture de logiciels de haute qualité avec le développement axé sur le comportement (BDD). En savoir plus.

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.