Pourquoi DevOps a besoin de tests continus

Les tests continus ne concernent pas seulement l'automatisation. Vrai tests continus pour DevOps aligne les activités de test avec la valeur commerciale. L'objectif des tests continus à l'appui de DevOps est d'éliminer les tests inutiles et de produire des tâches à valeur ajoutée qui conduisent véritablement l'organisation de développement vers une version réussie.

En réponse à la demande actuelle de «Tout continu», la bande transporteuse de livraison logicielle continue de se déplacer de plus en plus vite. Mais étant donné que les tests ont été la principale contrainte du processus de livraison de logiciels, il est déraisonnable de s'attendre à ce que le simple fait d'accélérer un processus perturbé donne de meilleurs résultats.

Une grande analogie pour I Love Lucy fans est la tristement célèbre scène de Lucy et Ethel à l'usine de bonbons, luttant pour suivre le rythme alors que le tapis roulant commence à produire des chocolats de plus en plus vite.

Maintenant que la livraison rapide de logiciels différenciables est devenue un impératif commercial, les équipes de développement de logiciels s'efforcent de suivre le rythme. En réponse à une demande accrue, ils recherchent de nouvelles façons d'accélérer leurs cycles de publication, favorisant ainsi l'adoption de pratiques de développement agiles ou allégées telles que DevOps.

Mais sur la base du nombre de pannes logicielles qui font maintenant la une des journaux quotidiennement, il est évident que l'accélération du SDLC ouvre la porte à de graves répercussions.

Les organisations négligent de supposer que les pratiques d'hier peuvent répondre aux exigences des processus d'aujourd'hui. Il doit y avoir un changement de culture entre le test d'une application et la compréhension des risques associés à une version candidate. Un tel changement nécessite d'aller au-delà de l'approche traditionnelle «ascendante» des tests, qui se concentre sur l'ajout de tests incrémentiels pour les nouvelles fonctionnalités. Bien que cela soit toujours nécessaire, il est tout aussi important d'adopter une approche descendante pour atténuer les risques commerciaux. Cela signifie que les organisations doivent défendre l'expérience utilisateur avec les cas d'utilisation les plus probables dans le contexte d'exigences non fonctionnelles - en permanence.

Pour qu'une automatisation plus avancée se produise, nous devons aller au-delà du pourcentage de réussite / échec des tests vers une compréhension beaucoup plus granulaire de l'impact de l'échec: une nuance qui se perd dans la suite de tests de régression traditionnelle.

Les tests continus, qui consistent à exécuter automatiquement un ensemble de tests conçus pour vérifier si les attentes de l'entreprise en matière de fonctionnalité, de sécurité, de fiabilité et de performances sont satisfaites, sont essentielles pour combler cette lacune. Il fait passer le paradigme d'une approche ascendante pure à un modèle hybride dans lequel les tests descendants sont mis à profit pour protéger l'expérience utilisateur attendue des changements introduits à mesure que l'application évolue. En fin de compte, le test continu réinitialise la question «Avez-vous terminé les tests?» à «le niveau de risque est-il compris et accepté?»

Test: l'éléphant dans la pièce

Au fur et à mesure que les organisations commenceront à accélérer le SDLC, les goulots d'étranglement des processus deviendront évidents. Les tests sont l'un des goulots d'étranglement qui continuent de nuire à l'accélération du SDLC. Au mieux, les tests ont été considérés comme une surcharge inévitable - un événement «temporisé» qui se produit parfois entre la fin du code et la date de publication cible. Au pire, les organisations ont poussé les processus de qualité à post-lancement, forçant un «test d'acceptation client en temps réel».

Les tests ont toujours été l'éléphant dans la pièce. Psychologiquement, la nature malléable des logiciels a donné aux organisations une excuse pour reporter leurs investissements dans les tests. Cependant, ce report se traduit par une dette technique. Au fil du temps, la dette technique s'aggrave, augmentant le risque et la complexité associés à chaque version.

Un autre obstacle à l'accélération du SDLC est l'absence d'un processus de qualité coordonné de bout en bout. Si des données de qualité fiables et holistiques étaient collectées tout au long du SDLC, des points de décision plus automatisés pourraient optimiser les processus en aval.

Test continu: comment cela aide

Les tests continus fournissent une évaluation objective en temps réel des risques commerciaux associés à une application en cours de développement. Appliqué de manière uniforme, il permet aux responsables commerciaux et techniques de prendre de meilleures décisions en matière de compromis entre la portée, le temps et la qualité de la publication.

Les tests continus ne sont pas seulement plus d'automatisation, c'est une réévaluation plus large des pratiques de qualité des logiciels - entraînée par le coût de la qualité d'une organisation, équilibré pour la rapidité et l'agilité. En fin de compte, les tests continus peuvent fournir une évaluation quantitative des risques et produire des tâches réalisables qui aideront à atténuer ces risques avant de passer à l'étape suivante du SDLC.

Figure 1: Atténuer les risques avant qu'ils ne passent à l'étape suivante du SDLC

Par exemple, supposons qu'un détaillant sait que des facteurs d'expérience utilisateur très spécifiques liés à l'application rendent le consommateur plus susceptible d'ajouter des articles à son panier de commerce électronique. Ces mesures, qui sont définies dans le langage commercial et mesurées automatiquement, sont exactement les mêmes critères que ceux utilisés pour accepter une version de logiciel candidate. La question à laquelle la suite de tests doit répondre est de savoir comment les modifications apportées aux applications ont un impact sur cet ensemble de mesures métier. L'objectif est de placer les attentes de l'entreprise et le langage commercial au premier plan du processus de validation - en fin de compte, en protégeant l'utilisateur et la marque.

En matière de qualité logicielle, nous sommes confrontés au besoin d'une véritable réingénierie des processus. Le test continu n'est pas une solution «plug and play». Comme pour toutes les initiatives axées sur les processus, cela nécessite l'évolution des personnes, des processus et de la technologie. Nous devons tenir compte de la nature créative du développement logiciel en tant que discipline, mais nous devons faire face au fait écrasant que les logiciels imprègnent tous les aspects de l'entreprise et que l'échec logiciel présente le plus grand risque pour l'organisation.

Résumé

Compte tenu des attentes de l'entreprise à chaque étape du SDLC, les tests continus fournissent une évaluation quantitative des risques ainsi que des tâches réalisables qui aident à atténuer ces risques avant qu'ils ne passent à l'étape suivante du SDLC. L'objectif des tests continus à l'appui de DevOps est d'éliminer les tests inutiles et de produire des tâches à valeur ajoutée qui conduisent véritablement l'organisation de développement vers une version réussie.

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.