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

DevOps apporte des impacts à l'échelle El Nino sur les tests logiciels

DevOps apporte des impacts à l'échelle El Nino sur les tests logiciels Temps de lecture : 4 minutes

Slams! Dépasse! Fait des ravages!

C'est le genre de langage utilisé dans les manchettes d'aujourd'hui décrivant la première avancée d'El Nino en Californie - et il est tout aussi applicable à l'impact de DevOps sur les tests logiciels.

Avec DevOps, le déluge constant de nouvelles fonctionnalités crée indéniablement une perturbation torrentielle des tests traditionnels. De nombreuses équipes gardent à peine la tête hors de l'eau en essayant de s'assurer que chaque nouvelle exigence fonctionne réellement avant son déploiement. Alors, comment pouvez-vous vous assurer que chaque «petit changement» n'introduit pas d'effets secondaires qui se répercutent sur l'application et rendent l'utilisateur final plus frustré qu'un conducteur sur une autoroute californienne inondée?

Comment les tests logiciels sont-ils impactés par DevOps et Agile?

Traditionnellement, les tests ont été un événement limité dans le temps. Vous attendiez que le développement produise une version viable, puis il y avait un temps pour le contrôle qualité pour exercer ce dont ils avaient besoin pour tester. Lorsqu'ils sentaient qu'ils avaient «terminé les tests» ou qu'ils n'avaient plus de temps, les tests s'arrêtaient.

Avec l'essor de l'Agile et du DevOps, deux choses principales se sont produites:

  • Le temps de fin de cycle (déjà réduit) consacré à l'exercice de l'application a complètement disparu.
  • Les méthodes de test en vigueur (tests manuels et tests GUI) sont devenues obsolètes car elles étaient trop lentes, trop longues, coûteuses et fragiles pour un monde de courtes itérations et de changements constants.

Pour publier en toute confiance malgré la vitesse et la fréquence des cycles de publication actuels, nous devons cesser de demander «Avons-nous terminé les tests» et mettre l’accent sur «La version candidate présente-t-elle un niveau de risque commercial acceptable?» Si nous pouvons répondre à cette question, nous pouvons déterminer si l'application est vraiment prête à progresser dans le pipeline de livraison.

Compte tenu de l'augmentation des coûts et de l'impact des défaillances logicielles, les entreprises ne peuvent plus se permettre de lancer une version susceptible de perturber l'expérience utilisateur existante ou d'introduire de nouvelles fonctionnalités qui exposent l'organisation à de nouveaux risques de sécurité, de fiabilité ou de conformité. Pour éviter cela, l'organisation doit passer de la validation des exigences ascendantes à l'évaluation des exigences système associées aux objectifs commerciaux globaux, par exemple via des tests continus.

En quoi consiste le passage des tests automatisés aux tests continus?

L'automatisation des tests est une étape critique dans la transition vers les tests continus. Cependant, si l'un de vos tests automatisés échoue, savez-vous ce que cela signifie vraiment? Cela indique-t-il un risque commercial critique ou simplement une violation d'une norme de dénomination que personne ne s'engage vraiment à suivre de toute façon? Et que se passe-t-il en cas d'échec? Existe-t-il un flux de travail clair pour hiérarchiser les défauts par rapport aux risques commerciaux et traiter les plus critiques en premier? Et pour chaque défaut qui justifie une correction, existe-t-il un processus pour exposer tous les défauts similaires qui auraient déjà été introduits, ainsi que pour éviter que ce même problème ne se reproduise à l'avenir? C'est là que la différence entre automatisé et continu devient évidente.

À évoluer des tests automatisés aux tests continus, vous avez besoin des éléments suivants:

  1. Des attentes métier clairement définies, avec des risques métier identifiés par application, équipe et version.
  2. Les défauts sont automatiquement classés par ordre de priorité par rapport aux moteurs commerciaux et savoir comment atténuer ces risques avant la mise en service de la version candidate.
  3. Tester en continu dans des environnements de test complets à l'aide de la simulation - ceci est essentiel pour protéger l'expérience utilisateur actuelle de l'impact du changement.
  4. Boucle de rétroaction pour la prévention des défauts - recherche de modèles qui émergent et utilisation de cette opportunité pour concevoir et mettre en œuvre des pratiques de prévention des défauts qui empêchent l'introduction de défauts similaires.

Les tests manuels ont-ils une place dans DevOps?

En termes simples, vous devez automatiser autant que possible. L'automatisation doit devenir la norme pour les tests modernes. Cela étant dit, certaines choses ne peuvent pas être automatisées, de sorte qu'un certain degré de test manuel peut être inévitable. Pour vous assurer que les tests manuels ne deviennent pas un goulot d’étranglement dans votre pipeline de livraison, vous devez vous assurer qu’il ne s’agit pas de votre chemin critique. processus de livraison automatisé.

Comment le concept de «QA» doit-il évoluer pour DevOps?

Même si le terme «AQ» est dérivé de «l'assurance qualité», le rôle d'AQ des équipes de développement logiciel s'est plus ou moins concentré sur les tests tactiques. Pour que les initiatives de processus collaboratifs plus modernes (DevOps, lean, agile…) prennent racine, le rôle de l'AQ doit revenir à l'assurance qualité. Dans ce cas, le contrôle qualité est chargé de définir et d'activer un processus proactif continu qui identifie et prévient les risques commerciaux tout au long du cycle de vie du logiciel.

Si QA = Quality Assurance, alors le QA se concentrant sur la création et la gestion de scripts de test fonctionnel semble étrange; cette tâche n'est ni préventive ni orientée processus. Le concept de qualité et la manière dont il est défini est une responsabilité organisationnelle et commerciale qui doit se refléter dans la culture de l'entreprise. Les tests ne sont que l'une des nombreuses activités qui garantissent que les objectifs de qualité organisationnels sont atteints.

Comment les technologies de simulation s'intègrent-elles dans DevOps et les tests continus?

Une fois que les organisations ont commencé à accélérer leur pipeline de livraison de logiciels pour Agile et DevOps, elles atteignent souvent le point où elles doivent tester, mais ne peuvent pas exercer l'AUT car un environnement de test complet n'est pas encore prêt. De nombreuses équipes utilisent des technologies de simulation telles que l'EaaS et la virtualisation des services pour contourner ces obstacles.

Pour vraiment protéger l'expérience de l'utilisateur final, nous devons tester et défendre de manière agressive l'expérience de l'utilisateur final à travers les transactions clés de bout en bout. Avec les systèmes actuels, ces transactions passent par un grand nombre de composants différents, il est donc très difficile de les intégrer dans un seul environnement de test par étapes - cloud ou non. La simulation nous aide à contourner ce problème. Pour l'environnement simulé le plus réaliste, nous devons vraiment comprendre comment les composants fonctionnent dans un environnement opérationnel et le transférer dans la simulation.

Quelle est la différence entre «Environnements en tant que service» et «Virtualisation des services»?

Les piles d'applications qui sont sous votre contrôle (prêtes pour le cloud) peuvent être importées et imagées via un élastique EaaS dans un cloud. La virtualisation des services vous permet ensuite de simuler le comportement des dépendances que vous ne pouvez pas facilement imager (par exemple, les services tiers, les régions SAP, les mainframes, les API non encore implémentées, etc.) ou celles que vous souhaitez stabiliser à des fins de couverture de test. .

Le résultat est que les équipes informatiques ou les administrateurs d'environnement peuvent facilement configurer des environnements de développement / test complets que les testeurs et les développeurs peuvent rapidement (et simultanément) configurer et provisionner à la demande.

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