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

Test 1-2-3 avec Mark Lambert de Parasoft: tests basés sur le changement et couverture de code corrélé fusionné

Test 1-2-3 avec Mark Lambert de Parasoft: tests basés sur le changement et couverture de code corrélé fusionné Temps de lecture : 4 minutes

Bienvenue à la deuxième session de Testing 1-2-3! Cette série propose des conversations avec des leaders du secteur des tests logiciels sur un large éventail de sujets de tests logiciels: DevOps, Agile, tests IoT, tests de performances, tests unitaires, données de test, virtualisation des services, nouveau rôle des tests logiciels, impact commercial de la qualité, et plus.

La dernière fois, nous avons présenté notre session inaugurale avec Theresa Lanowitz de voke, où nous avons discuté des tests continus, de la virtualisation des services et du nouveau rôle des testeurs.

Dans cette édition de Testing 1-2-3, nous discutons avec Marc Lambert, Vice-président des produits chez Parasoft sur les tests basés sur le changement, la couverture de code corrélé fusionné et le développement Agile.

Tests agiles et basés sur le changement

Test 1-2-3:  Chez StarWest, tout le monde parle de changement. De nombreuses personnes adoptent de nouvelles façons de développer et de tester des logiciels en réponse à la demande d'une livraison plus rapide et d'une meilleure visibilité sur les risques associés au logiciel qui est publié. Comment voyez-vous ce jeu sur le terrain?

Marque: La chose n ° 1 que je vois ces derniers temps, c'est que les gens veulent connaître l'impact des changements fréquents apportés à leurs applications. Vous pouvez avoir des tests qui couvrent l'ensemble de l'application, mais, en particulier avec la livraison continue, vous ne pouvez pas exécuter tous ces tests pour comprendre l'impact de chaque changement. Avec Agile, tout tourne autour de sprints de 2 ou 3 semaines, et vous êtes vraiment concentré sur les fonctionnalités introduites dans chaque user story. Bien sûr, vous validez chaque histoire et vous assurez qu'elle fonctionne, mais savez-vous vraiment ce que vous avez pu avoir d'autre impact? Des tests exploratoires peuvent révéler quelque chose, mais il n'y a généralement pas de moyen méthodique de savoir si ces changements ont eu des effets secondaires dangereux.

Test 1-2-3:  Donc, en d'autres termes, le défi aujourd'hui est d'obtenir des commentaires au moment du changement afin que vous sachiez si vous pouvez ou non avancer en toute confiance?

Marque: Oui, tout dépend de l'ampleur de l'impact.

Test 1-2-3:  Intéressant. Comment les gens peuvent-ils faire les premiers pas vers la transition vers ce nouveau paradigme?

Marque: Je pense que la première étape consiste à obtenir plus d'informations. Si certaines des données sous-jacentes autour de vos pratiques de test existantes vous manquent, comment pouvez-vous vous attendre à ce qu'elles évoluent, deviennent agiles et soient exploitées de manière à vous aider à atténuer le risque de chaque version candidate?

Couverture de code fusionné et corrélé

Test 1-2-3:  Pouvez-vous nous donner un exemple de ces données?

Marque: Un exemple est de comprendre quelles parties du code sont réellement touchées par des cas de test spécifiques. À général-MarkL_Drawing.jpgParasoft, l'une des choses sur lesquelles nous nous concentrons est d'aider les organisations à obtenir cette traçabilité des tests - la capacité de comprendre quel code un test particulier exerce. La plupart des gens sont familiarisés avec la mesure de la couverture au niveau de l'unité, mais vous souhaitez également obtenir un niveau granulaire de couverture de code pour vos tests manuels et automatisés.

Test 1-2-3: Mais ce sont toutes des pratiques distinctes effectuées à des moments différents au cours des différentes phases du SDLC. Vous avez quelqu'un qui effectue des tests unitaires lorsque le code change (ou peut-être même avant que le code change, s'ils adoptent une approche TDD), vous avez quelqu'un qui effectue des tests de composants, et vous avez un groupe de personnes différent qui vient effectuer des tests de scénario basé sur l'exigence ou la user story elle-même. Compte tenu de tout cela, comment déterminez-vous quel niveau de couverture a réellement été atteint?

Marque: Bien que toutes ces pratiques aient été très cloisonnées dans différentes parties du SDLC, elles sont maintenant toutes condensées en un sprint particulier. Vous devez être en mesure d'agréger les données de test et les informations de couverture de toutes ces différentes techniques exécutées simultanément sur une version particulière. La corrélation est vitale… vous rassemblez toutes ces données, les corrélez avec la construction spécifique passant par le processus de vérification, puis vous fusionnez la couverture entre ces différentes techniques. Chez Parasoft, nous appelons cette couverture corrélée fusionnée.

Version = MC2 (couverture corrélée fusionnée)

Vous voulez savoir comment la fusion et la corrélation de la couverture de code à partir de diverses techniques de test peuvent aider votre organisation à comprendre et à atténuer les risques associés à une version donnée? Lisez notre livre blanc, Couverture complète du code: couverture globale des pratiques de test.

dtp-couverture-dash.pngVous découvrirez comment la couverture des applications aide les équipes à atteindre leurs objectifs de publication, notamment:

  • Comment la couverture des applications aide à atténuer le risque associé à la livraison accélérée
  • Comment collecter la couverture de l'application
  • Comment fusionner et corréler la couverture de code à partir de diverses techniques de test
  • Comment la couverture des applications peut aider les organisations critiques pour la sécurité à atteindre la traçabilité nécessaire pour atteindre les objectifs de conformité
Écrit par

Parasoft

Les outils de test de logiciels automatisés de pointe de Parasoft prennent en charge l'ensemble du processus de développement logiciel, depuis le moment où le développeur écrit la première ligne de code jusqu'aux tests unitaires et fonctionnels, jusqu'aux tests de performance et de sécurité, en exploitant des environnements de test simulés en cours de route.

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