Remettez l'agilité dans le développement agile avec des tests basés sur le changement

Le sale petit secret du développement agile

Agile est souvent mal vendu à la haute direction comme moyen de plus rapidement time-to-market, lorsque l'objectif est vraiment plus précise livraison au marché. Le sale secret que nous ne disons à personne, c'est que cela a en fait un coût… un temps de mise sur le marché plus lent! Oui, nous publions plus souvent (c'est-à-dire «plus tôt»), mais il faut finalement plus de temps pour mettre la fonctionnalité complète sur le marché. Pourquoi est-ce que cela prend plus de temps alors que tout ce que nous faisons est de diviser le problème en petits morceaux? Eh bien, de loin le plus grand coupable est la détection des défauts en fin de cycle et les goulots d'étranglement introduits par les mesures visant à réduire le risque.

Une grande partie de la vitesse promise du développement agile est déçue par les changements de code incrémentiels, en particulier leur impact sur les tests et la stabilité globale du système. Chaque sprint se termine généralement par un tiret jusqu'à la ligne d'arrivée, car l'AQ / les tests se concentrent sur la validation de la nouvelle fonctionnalité implémentée. Ensuite, en raison d'un manque de compréhension de l'impact indirect des modifications de code, les organisations doivent effectuer une régression complète à l'approche de la publication. Cela découvre souvent de nombreux problèmes en fin de cycle, ce qui entraîne des heures tardives et des décisions commerciales difficiles.

Il doit y avoir une meilleure façon!

Concentrez-vous sur le risque

En raison de la complexité des bases de code d'aujourd'hui, chaque changement de code, aussi inoffensif soit-il, peut avoir un impact subtil sur la stabilité de l'application et finalement «casser le système». Ces conséquences involontaires sont impossibles à découvrir grâce à une inspection manuelle, les tests sont donc essentiels pour atténuer le risque qu'ils représentent, mais à moins que vous ne compreniez ce qui doit être repositionné, vous ne pouvez pas réaliser une pratique de test efficace. Si vous testez trop à chaque sprint, vous perdez de nombreux gains réalisés par le développement agile. Si vous testez trop peu, vous vous exposez à une détection tardive.

Ce qu'il faut, c'est un moyen d'identifier les tests qui doivent être réexécutés et de concentrer les efforts de test (tests unitaires, tests fonctionnels automatisés et tests manuels) sur la validation des fonctionnalités et du code associé qui sont impactés par les modifications les plus récentes. En utilisant une combinaison des moteurs d'analyse de code de Parasoft (Jtest, test C / C ++, dotTEST) et du Process Intellligence Engine (PIE) dans Parasoft DTP, les développeurs et les testeurs peuvent comprendre les changements dans la base de code entre les versions et accéder au promesse d'Agile. C'est appelé Test basé sur le changement.

Les tests basés sur le changement (CBT) permettent au sprint de continuer

La clé est de savoir quels tests sont disponibles pour valider les changements de code, et c'est ici que la couverture corrélée de Parasoft livre les marchandises. En comprenant lesquels de ces fichiers ont changé et quels tests spécifiques ont touché ces fichiers, le moteur d'analyse de DTP (PIE) peut analyser le delta entre deux versions et identifier le sous-ensemble de tests qui doivent être réexécutés. L'image ci-dessous montre un widget du tableau de bord DTP qui affiche un diagramme à secteurs des résultats de l'analyse CBT. Ce graphique montre le sous-ensemble de tests disponibles pour valider les modifications de code, classés en fonction de leur statut de test: réussi, échoué, incomplet et nécessitant un nouveau test.

Cette vue de haut niveau indique qu'il existe un certain nombre d'échecs que le code modifié a introduit et qu'il existe un certain nombre de tests qui n'ont pas encore été exécutés mais qui sont disponibles pour valider davantage les modifications.

 

 

 

 

 

 

 

 

Un statut de Réussir, échouer, or Couverture indique que ces tests ont déjà été exécutés par rapport à la construction, soit dans le cadre d'un processus de test entièrement automatisé (comme une étape de construction pilotée par CI), soit lors du test de la nouvelle fonctionnalité. Les tests avec le statut de retester, cependant, il s'agit soit de tests manuels qui n'ont pas encore été exécutés, soit de tests faisant partie d'exécutions d'automatisation dont l'exécution n'est pas planifiée pendant le sprint en cours.

En creusant plus profondément dans le graphique, nous pouvons rapidement avoir un aperçu de l'endroit où les changements se sont produits dans le code, de la corrélation entre les tests existants et de ces changements et de l'endroit où les ressources de test doivent être concentrées.

À partir de là, nous pouvons créer un plan de test, en traitant les cas de test échoués et incomplets avec la priorité la plus élevée, et en utilisant les recommandations de re-test pour concentrer la planification d'exécutions automatisées supplémentaires et prioriser les efforts de test manuel.

L'explorateur de violations dans DTP fournit l'interface pour définir et gérer le plan de test. En parcourant les tests et les résultats, l'explorateur révèle des détails sur chaque cas de test. En utilisant le Priorisation pour définir les métadonnées de test, les utilisateurs peuvent attribuer des propriétaires, des actions et définir la priorité à chacun des cas de test.

Comment appliquer un flux de travail CBT

Alors, comment cela aide-t-il un processus agile? Simplement, c'est la possibilité d'identifier rapidement et succinctement où vos ressources de test doivent être appliquées. En testant uniquement ce qui est nécessaire par rapport à tout (ou simplement en devinant), le temps de test est considérablement réduit. La qualité monte et le sprint se fait à temps.

Comment cela fonctionnerait-il dans la pratique? Bien que les résultats de l'analyse des tests basés sur le changement (CBT) puissent être utilisés de plusieurs manières différentes, je suggérerais que le flux de travail suivant soit le plus pratique pour concentrer les efforts de test basés sur les sprints;

• Identifiez votre base de référence. Il s'agit de la version avec les efforts de test terminés que vous souhaitez utiliser pour un nouveau test ciblé. En règle générale, ce serait la construction à partir de la fin du sprint ou de la version précédente.
• Exécutez les tests unitaires et les tests fonctionnels automatisés disponibles. Intégrez des tests automatisés dans votre processus CI et mesurez / surveillez les résultats CBT par rapport à la dernière version. Cela vous permet de voir comment vous faites et de planifier l'effort de nouveau test.
• Fermez l'espace de re-test. Tester par rapport à la version cible et soumettre les résultats des efforts de re-test pour analyse; et réexaminer les résultats de la TCC.
• Réinitialisez votre base de référence. À la fin du sprint, déplacez la ligne de base vers la construction sur laquelle vous avez finalisé les tests et réinitialisez / répétez pour le sprint suivant.

Conclusion

Nous devons augmenter la productivité des tests dans le développement agile. Les tests sont un goulot d'étranglement majeur pour une livraison continue avec trop de défauts identifiés à la fin du cycle de publication en raison de tests erronés. Pour obtenir les meilleurs résultats, concentrez vos efforts de test sur l'impact des changements que vous apportez et débloquez l'agilité pour accélérer la mise sur le marché.