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

10 façons de gagner du temps grâce aux pratiques de qualité agiles

Par Parasoft

27 janvier 2011

12  min lire

Le désir d'adopter l'agilité vient généralement du développement. Après tout, l'agilité a été créée par les développeurs pour les développeurs. Mais sans une stratégie robuste de qualité agile qui réponde efficacement aux exigences de l'entreprise, les équipes agiles resteront bancarisées.

Pour éviter cela, vous pouvez étendre les pratiques de qualité agiles bien connues pour vous assurer que votre logiciel répond aux besoins de l'entreprise de manière efficace et efficiente. Voici comment:

1. Étendez la qualité au-delà de l'assurance qualité

Dans le développement agile, tous les membres de l'équipe, du développeur au chef de produit, doivent avoir une conscience aiguë de la qualité tout au long du processus, la qualité faisant partie intégrante de leur flux de travail quotidien et de multiples tâches qualité exécutées simultanément. Cela permet découverte et correction plus rapides des défauts… réduisant le temps, les efforts et les coûts nécessaires pour éliminer chaque défaut.

Par exemple, à un moment donné, les tâches suivantes peuvent être exécutées en même temps:

  • Contrôle qualité effectuant des tests fonctionnels de haut niveau sur une exigence pour l'itération actuelle.
  • Les développeurs écrivent des tests unitaires et du code pour un autre.
  • Un chef de produit, soucieux de la fiabilité / performance globale du produit, ajustant la politique qualité de l'équipe pour répondre à cette préoccupation.

Pour intégrer la qualité dans les activités quotidiennes des différents membres de l'équipe, vous pouvez suivre cette répartition des tâches:

Rôle Tâches
Responsables du développement / Scrum Masters
  • Répartition des besoins
  • Établissement de directives de codage
  • Définition de la stratégie de test de développement
  • Estimation du coût de développement
  • Suivi des travaux en cours
Développeurs
  • Exigences de lecture
  • Exigences de mise en œuvre
  • Temps de suivi
  • Suivi des modifications
  • Exigences de test
  • Participer à des revues de code par les pairs
  • Suivre la politique qualité
Testeurs d'assurance qualité
  • Examiner les efforts de test des développeurs
  • Effectuer des tests supplémentaires des exigences
  • Travailler de manière itérative pendant le développement
  • Détecter et signaler rapidement les défauts
  • Recherche de la cause des défauts
  • Influencer la politique de développement
Gestionnaires de produits
  • Exigences d'écriture
  • Fixer des délais
  • Suivi des progrès et des coûts
  • Surveillance de l'état de qualité de haut niveau
  • Ajuster les exigences et les horaires

2. Adoptez la politique en équipe

La politique n'est pas traditionnellement associée aux tests de développement agile, et de nombreux « agilistes » purs craignent que toute la notion de politique contredise la nature collaborative et légère des processus agiles. Pourtant, nous avons constaté que de nombreuses équipes travaillant avec des méthodologies de développement agiles apprécient réellement d'avoir des attentes claires concernant la façon dont le code doit être écrit et testé. Avec des attentes clairement définies, l'équipe n'a pas besoin de perdre du temps à essayer de comprendre exactement ce qui est attendu à quel moment - ou à retravailler constamment le code pour remédier aux malentendus.

Vous pouvez commencer par mettre en œuvre une politique qui formalise simplement les pratiques de codage et de qualité que l'équipe suit déjà. Ensuite, à partir de cette base de référence, vous pouvez introduire progressivement de nouvelles politiques que l'équipe a discutées et acceptées de suivre.

Les modifications éventuelles de la politique peuvent ensuite être discutées lors de réunions debout quotidiennes ou lors des révisions de code. Cela permet aux membres de l'équipe de fournir des commentaires précieux concernant les améliorations de politique (par exemple, affiner une règle d'analyse statique pour autoriser certaines exceptions) et les extensions (par exemple, exigeant une couverture de test supplémentaire sur un module que l'AQ rapporte comme étant particulièrement bogué).

En plus de s'assurer que toute l'équipe est à bord, il est également essentiel de s'assurer que l'application de la politique sert de guide et non d'intrusion. Idéalement, une infrastructure automatisée vérifie automatiquement la conformité en arrière-plan et fonctionne de manière invisible à moins que les attentes convenues ne soient pas satisfaites. À ce stade, il détermine quel membre de l'équipe doit être averti et lui rappelle d'exécuter les tâches requises pour répondre aux attentes convenues.

Essentiellement, l'infrastructure automatisée fonctionne comme un système d'électrocardiogramme connecté à un patient hospitalisé, mesurant constamment l'activité électrique. Si tout va bien, il s'exécute discrètement en arrière-plan. Mais si les lectures commencent à se stabiliser, des alarmes retentissent et les gens comprennent qu'une action est nécessaire.

3. Utilisez les tests automatisés pour détecter autant d'erreurs que possible avant le contrôle qualité

Si des défauts résultant d'un code mal implémenté sont constamment transmis au contrôle qualité, cela se traduit finalement par:

  • Tests d'acceptation moins approfondis par QA,
  • Cycles d'assurance qualité fréquents / longs qui ont un impact sur l'échéance et la portée de l'itération, et / ou
  • Les défauts se glissant dans les produits libérés, puis nécessitant une correction / correction pendant le temps imparti pour une itération ultérieure.

De nombreux défauts de ce type pourraient être détectés par des tests de développement entièrement automatisés, des tests pouvant être effectués sur le serveur d'intégration ou à partir du bureau en un seul clic.

Le point de départ est d'avoir une politique de codage efficace et de la mettre en œuvre avec une analyse de code statique. L'analyse de code statique vérifie les anti-modèles connus dans les constructions de code source et signale chaque occurrence d'une correspondance. Il peut être exécuté rapidement et est garanti pour trouver tous les cas de code qui correspondent à un modèle.

Le codage défensif peut rendre le code immunisé contre de nombreuses catégories de défauts, y compris de nombreux défauts extrêmement difficiles à détecter lors des tests, en éliminant leurs causes profondes.

Par exemple, vous pouvez prévenir de nombreuses causes de:

  • Exceptions
  • Les impasses
  • Conditions de course
  • Notifications manquées
  • Boucles infinies
  • Problèmes d'initialisation
  • Problèmes d'utilisation de la mémoire
  • Problèmes de sérialisation
  • Corruption de données
  • Fuites de ressources et de mémoire

Tous les types de défauts ne peuvent pas être évités par une analyse de code statique. Mais chaque défaut que vous pouvez éviter est un défaut de moins qui ralentit l'itération de l'équipe. L'assurance qualité n'est pas obligée de trouver et de documenter le défaut. Le développement n'est pas obligé d'arrêter ce qu'il fait, de rafraîchir sa mémoire du code problématique, de corriger le code et de vérifier que le problème est résolu. Et l'assurance qualité n'a pas à tester à nouveau la modification du développeur.

Pour rechercher les types de défauts qui sortent du cadre de l'analyse statique, essayez les techniques suivantes, qui ne nécessitent toutes deux aucun effort manuel supplémentaire:

  • course analyse statique des flux de données pendant la nuit. L'analyse des flux de données simule statiquement les chemins d'exécution des applications, qui peuvent traverser plusieurs unités, composants et fichiers. C'est comme tester sans exécuter le code. Avec le flux de données, vous pouvez «tester» un grand nombre de chemins d'exécution sans avoir à écrire ou exécuter un seul scénario de test.
  • Activer détection des erreurs d'exécution au fur et à mesure de l'exécution de vos tests fonctionnels existants (tests unitaires et tests manuels ou scriptés). Cela vous aide à exposer les défauts critiques qui n'apparaissent qu'au moment de l'exécution (par exemple, les écrasements de fichiers) et à vous concentrer sur la cause première du plantage de l'application, de son exécution lente ou de son comportement imprévisible. Les résultats indiquent des erreurs qui se sont réellement produites lors de l'exécution. Ainsi, les défauts sont signalés avec une précision sans précédent.

De plus, nous recommandons fortement examen du code par les pairs, ce qui nécessite des efforts, mais c'est le seul moyen efficace d'exposer les défauts de haut niveau liés à la logique, à la conception, etc. Le conseil n ° 10 discutera de certaines façons d'utiliser l'automatisation pour rationaliser les révisions de code.

4. Faites évoluer en permanence votre politique de qualité en réponse aux défauts détectés

Lorsque vos efforts de développement ou de test d'assurance qualité révèlent des défauts qui ont dépassé la politique de qualité de votre équipe, ne corrige pas seulement ce défaut et passe à autre chose.

C'est comme un constructeur automobile remarquant qu'une voiture est sortie de la chaîne de montage avec une installation de frein défectueuse, réparant les freins de cette voiture et espérant que le problème ne se reproduise plus. Une approche plus sûre - qui permettrait d'économiser beaucoup de temps, de tracas et de chagrin à long terme - consisterait à examiner la chaîne de montage, déterminer comment ce problème a été introduit, puis corriger sa cause première.

En termes de processus de développement logiciel, cette approche implique de travailler avec le développement et l'assurance qualité pour:

  1. Isoler la cause première de ce type général de défaut.
  2. Déterminer comment modifier le processus de développement pour l'empêcher.
  3. Déterminez comment mesurer si c'est le cas, la modification est effectivement pratiquée.

Dans de nombreux cas, un changement de politique de codage fera l'affaire: par activer ou reconfigurer certaines règles d'analyse statique, vous pouvez trouver toutes les autres instances de code existant sujettes au même type de défaut, et vous pouvez également vous assurer que le code nouveau ou modifié évite le piège connu. Souvent, la détection des erreurs d'exécution et le flux de données sont statiques analyseurs de code vous indiquera même les règles d'analyse statique précises que vous pouvez suivre pour éviter les défauts spécifiques qu'elles exposent.

D'autres fois, la résolution peut impliquer de modifier la façon dont le code est développé, testé ou d'ajouter à une liste d'éléments à examiner lors des inspections de code manuelles.

En fin de compte, cela immunise votre processus de test de développement logiciel contre bon nombre de vos défauts logiciels les plus courants.

5. Gérer la complexité du code

Étant donné que le code trop complexe s'est avéré à maintes reprises plus lent, plus difficile et plus risqué à mettre à jour et à étendre qu'un code plus simple, il est utile de se concentrer sur un code complexe, par exemple, toute classe ou méthode dont la complexité cyclomatique est 10 ou plus. Ce code peut fonctionner correctement pour le moment, mais cela pourrait causer un chagrin considérable à l'équipe lorsque ce qui semblait être une simple extension de fonctionnalité finit par nécessiter une réécriture à grande échelle.

En utilisant les calculs de métriques pour l'un de vos projets faciles à gérer comme guide, définissez des limites et des seuils réalistes pour les métriques sélectionnées, puis assurez-vous que les membres de l'équipe sont alertés lorsque les métriques sont en dehors de la plage prescrite. Cela réduira le temps et les efforts nécessaires pour modifier et étendre le code dans les itérations suivantes. Cela aidera également les nouveaux développeurs à se mettre à niveau plus rapidement.

6. Étendez le TDD et les tests fonctionnels avec des tests de régression générés automatiquement

Si vous pratiquez déjà le développement piloté par les tests (TDD) et les tests de régression automatisés en continu, vous disposez d'une excellente base pour déterminer quand les modifications changent ou interrompent votre fonctionnalité précédemment validée. Pourtant, si vous voulez vraiment être assuré que vos modifications ne modifier ou interrompre certains comportements d'application que vous n'avez pas testés explicitement avec vos cas de test TDD, plus étendu les tests de régression est nécessaire.

Extension de la suite de tests TDD

Une option consiste à passer beaucoup de temps à écrire beaucoup plus de cas de test. Mais qui a le temps pour ça? Une approche beaucoup plus simple consiste à générer une batterie de tests de régression qui vous aideront à vérifier le comportement de l'application 

  • Générer automatiquement une ligne de base en créant des cas de test qui capturent les fonctionnalités actuelles du code du projet. Dans la plupart des cas, une telle suite de tests peut être générée pendant la nuit en utilisant outils de tests unitaires automatisés. Parce que votre objectif est d'établir une ligne de base comportementale plutôt que de vérifier la fonctionnalité actuelle de l'application, il n'est pas nécessaire de revoir - ni même de jeter un coup d'œil - les tests générés ou les assertions/ observations / résultats atteints.
  • Détecter les changements par rapport à cette ligne de base en exécutant ces tests par rapport à votre base de code évolutive sur une base régulière. En règle générale, il suffit d'ajouter ces nouveaux cas de test à votre infrastructure de test de régression automatisée actuelle. Lors des tests ultérieurs, les échecs de test ne seront signalés que si le comportement actuel du code ne correspond pas au comportement capturé dans la suite de tests de base.

Le résultat est un moyen simple et efficace de déterminer quand et comment vos modifications de code ont un impact sur votre code-même les parties de l'application qui ne sont pas couvertes par les tests fonctionnels / TDD que vous avez écrits manuellement.

Rester synchronisé

Le seul travail requis est de synchroniser la suite de tests avec les modifications apportées à l'application. Lorsque les développeurs arrivent au travail chaque matin, ils examinent et répondent à tout échec de test signalé pour leur code. Ce faisant, ils soit corriger les défauts fonctionnels dans leur code, soit mettre à jour la suite de tests pour refléter le comportement correct du code.

7. Réduisez la complexité des tests des développeurs

Les systèmes que les équipes agiles construisent aujourd'hui gagnent en taille et en complexité. Par conséquent. les développeurs ont souvent du mal à tester les composants spécifiques sur lesquels ils ont travaillé car ces composants fonctionnent dans le cadre de systèmes complexes-ils sont connectés au monde extérieur, les systèmes de staging sont difficiles à établir et à maintenir, chaque test nécessite une configuration considérable, etc.. Il peut être possible d'exécuter un test une fois, mais vous devez vraiment exécuter tous les tests de votre équipe quotidiennement afin d'être immédiatement alerté au cas où vos modifications constantes finiraient par casser des fonctionnalités précédemment vérifiées.

Le suivi des cas de test permet à l'équipe de tester en continu des parties de l'application sans avoir à gérer le système compliqué. À l'aide d'une technologie de traçage telle que Parasoft Tracer, vous pouvez créer des cas de test unitaires qui capturent les fonctionnalités spécifiées dans les exigences.

Depuis l'interface graphique de l'application ou à l'aide d'un client de test SOA ou Web, il vous suffit d'exercer vos cas d'utilisation pendant que le traçage est activé. Au fur et à mesure que le cas d'utilisation est exécuté, la technologie surveille tous les objets créés, toutes les données qui entrent et sortent, puis elle vous crée un Test de l'unité cela représente cette opération - et met même en place les conditions initiales appropriées.

Vous pouvez alors prendre ceci cas de test unitaire et exécutez-le sur une machine distincte, loin du système d'origine. Cela signifie que vous pouvez utiliser une seule machine, telle que le serveur d'intégration continue ou même un bureau de développeur standard, pour reproduire le comportement d'un système compliqué lors de votre procédure de vérification. Ajoutez tous ces tests à votre suite de tests de régression, exécutez-la en continu et vous serez immédiatement alerté si cette fonctionnalité que vous avez capturée est affectée par vos modifications de code.

Essentiellement, cela vous aide à aborder la complexité des systèmes actuels de deux manières:

  • It définit automatiquement des conditions de test réalistes, vous soulageant du travail fastidieux et fastidieux qui serait autrement nécessaire pour y parvenir.
  • It vous donne un cas de test que vous pouvez exécuter indépendamment du système—Un cas de test que vous pouvez exécuter en continu et de manière entièrement automatique.

8. Réduisez la complexité des tests de bout en bout grâce à la virtualisation des services

Les équipes agiles travaillent généralement sur des applications hétérogènes distribuées (par exemple, SOA, Web, Cloud) où un ou plusieurs composants sont incomplets, évolutifs, instables, inaccessibles ou indisponibles pour les tests. Les méthodologies agiles nécessitent des tests de régression continus et automatisés (si possible), mais comment pouvez-vous exécuter des tests fonctionnels automatisés de bout en bout tous les soirs lorsque les parties du système testé ne sont pas facilement disponibles? Si vous retardez les tests jusqu'à ce que tout soit prêt et disponible pour les tests, vous risquez de vous glisser dans un paradigme semblable à une cascade.

Une façon de relever ce défi consiste à émuler le comportement des composants nécessaires. Essentiellement, vous construisez et déployez des actifs virtualisés qui émulent (virtualisent) le comportement, les performances et les données des applications. Ceci est réalisé en appliquant un concept connu sous le nom de virtualisation des services.

La virtualisation des services a été conçue pour émuler le comportement des services Web indisponibles et en évolution, puis a évolué au-delà des protocoles de service canoniques pour prendre en charge plusieurs types de messages et protocoles — JDBC, MQ, JMS, etc. Cette virtualisation étendue des services réduit radicalement le temps de configuration, la surcharge matérielle et les efforts de gestion des données impliqués dans la mise en place et la gestion d'un environnement de développement / test réaliste et durable.

La virtualisation de service idéale devrait viser des actifs virtualisés qui peuvent :

  • Remplacez les différents points de terminaison dans l'architecture du système (services, applications, mainframes, procédures stockées, etc.) ainsi que d'émuler le comportement de l'application au niveau de l'unité.
  • Be ajouté à l'environnement de test pour remplacer le comportement de divers composants qui, autrement, empêcheraient votre équipe d'exercer et de valider efficacement le processus métier de bout en bout.
  • Be géré et partagé dans un environnement d'équipe, et facilement déployé entre les serveurs partagés et les postes de travail des utilisateurs. Les données commerciales utilisées par les actifs virtualisés peuvent être facilement gérées avec des feuilles de calcul ou diverses autres sources de données.

Avec de tels actifs virtualisés, vous pouvez remplacer les systèmes, méthodes ou composants dépendants autrement, cela empêcherait l'équipe de valider efficacement les exigences à tester ou de vérifier que les problèmes détectés ont été résolus efficacement.

Par exemple, envisagez un système de provisionnement de compte basé sur les services qui perd des commandes. Pour résoudre ce problème, l'équipe de développement doit tester l'application fixe dans un bac à sable sécurisé qui émule les flux de transaction de l'environnement de production - ou risquer de casser le système lors du redéploiement de l'application. Grâce à l'émulation, l'équipe peut exercer ses services en contexte, sans affecter les transactions commerciales normales des partenaires.

Ce concept n'est pas nouveau, mais il devient de plus en plus important à mesure que les systèmes d'entreprise deviennent de plus en plus distribués et hétérogènes. De plus, cette complexité accrue rend nécessaire d'élargir le concept d'émulation pour aller au-delà des services et inclure également d'autres composants système essentiels (par exemple, la base de données, l'interface Web, le courtier, etc.) et de pouvoir émuler le divers protocoles qui coexistent généralement dans ces systèmes.

9. Refaites le test uniquement au besoin

Bien que les méthodologies agiles recommandent des tests automatisés chaque fois que possible, un certain degré de test manuel est toujours requis. Chaque fois que l'application est mise à jour, l'équipe d'assurance qualité répète généralement tous les tests manuels ou passe un temps considérable à essayer de déterminer lequel de ces cas de test pourrait être lié à la partie de l'application qui a changé. Quoi qu'il en soit, beaucoup de temps est perdu.

Grâce aux tests basés sur les changements, l'équipe peut voir instantanément quelles exigences sont affectées par les changements récents et quels tests doivent être exécutés à nouveau. Cela permet d'économiser énormément de temps et de ressources d'assurance qualité qui pourraient être mieux appliqués aux tâches à valeur ajoutée.

Pour activer les tests basés sur les changements, les exigences sont automatiquement corrélées avec les tests, le code source et les tâches de développement / test. Une fois ces corrélations en place, le niveau actuel de vérification pour chaque exigence ou tâche (y compris l'état de réussite / échec de la tâche et la couverture) peut être évalué à tout moment en remontant vers tous les tests associés.

De plus, l'équipe peut instantanément obtenir une évaluation objective de quelles exigences fonctionnent réellement comme prévu, quels défauts sont résolus et quelles exigences et quels défauts doivent encore être testés. Cette visibilité en temps réel des besoins réels et de l'état des défauts vous aide à éviter les surprises de fin de cycle qui menacent de faire dérailler les calendriers et les budgets.

10. Utilisez l'automatisation pour optimiser les réunions debout

Les réunions debout sont une partie importante des processus agiles et constituent un forum idéal pour maintenir les problèmes de qualité au premier plan du développement. Pour maintenir ces réunions à la durée recommandée de 15 minutes (tout en laissant un peu de temps pour couvrir la qualité), il est important de rationaliser ce qui est couvert et un  résoudre les problèmes plus complexes «hors ligne».

Deux stratégies qui vous aident à optimiser ces réunions sont:

  • Distribution et suivi automatisés des tâches.
  • Flux de travail automatisé de révision du code par les pairs.
Distribution et suivi automatisés des tâches

Bon nombre des aspects les plus ennuyeux et fastidieux des réunions debout peuvent être éliminés grâce à la distribution et à la surveillance automatisées des tâches.

À l'aide d'un système de gestion du développement logiciel tel que Parasoft DTP, le manager ou le scrum master convertit les exigences et les problèmes en tâches de travail exploitables et mesurables qui sont ensuite automatiquement distribuées directement à l'EDI du développeur responsable (selon des affectations manuelles ou des directives prédéfinies).

Lorsqu'un développeur est prêt à commencer à travailler sur une tâche assignée, il la marque comme «en cours», travaille sur la tâche comme d'habitude, puis la marque comme «terminée» lorsqu'elle est terminée. Sans interrompre le flux de travail du développeur, vous pouvez automatiquement suivre quels fichiers sont liés à la tâche donnée et combien de temps est passé à travailler sur ces fichiers. Les informations d'état en temps réel sont toujours disponibles dans le système.

Le suivi est essentiel pour évaluer les progrès actuels de l'équipe et sa capacité à se préparer aux réunions de stand-up. Il tient également l'assurance qualité bien informée de ce qui est prêt pour les tests.

Automatisation du workflow de révision de code par les pairs

La révision du code implique généralement de longues réunions fastidieuses qui nécessitent une préparation considérable. Un système de révision de code automatisé peut aider l'équipe à rationaliser les révisions de code en:

  1. Identifier code mis à jour à partir du contrôle de code source ou du système de fichiers local.
  2. Des le code avec des réviseurs désignés.
  3. Alertes le réviseur et lui permettant de revoir le code dans son IDE.
  4. Tracking la progression de chaque élément d'examen jusqu'à la clôture.

L'équipe est alors libre de se concentrer sur l'examen par les pairs proprement dit: un processus créatif qui ne peut (et ne doit pas) être automatisé.

Les révisions de code ne doivent pas nécessairement couvrir chaque ligne de code. Par exemple, certaines équipes peuvent préférer examiner uniquement les segments les plus dangereux de leur code (par exemple, les zones de la base de code les plus sensibles à la sécurité ou sujettes à des blocages). Les attentes concernant la révision du code doivent être discutées avec l'équipe et définies dans la politique qualité.

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.