DevOps : 6 conseils avant de se lancer dans le testing continu - Blue Soft
19634
post-template-default,single,single-post,postid-19634,single-format-standard,2.2.2,2.2.2-apply-online,ajax_fade,page_not_loaded,,qode_grid_1300,qode-theme-ver-10.1.1,wpb-js-composer js-comp-ver-5.0.1,vc_responsive
 

DevOps : 6 conseils avant de mettre en place du test continu

DevOps : 6 conseils avant de mettre en place du test continu

L’adoption croissante de la culture DevOps et du CI/CD (continuous integration/continuous delivery) pousse les départements DevOps à automatiser leurs pratiques de testing continu. En parallèle, le test manuel est aujourd’hui trop lent, trop cher, pas assez fiable.

Les développeurs ont besoin d’être avertis en quasi-instantané quant aux changements logiciels afin de résoudre rapidement les problèmes liés à la qualité sans pour autant perturber le code. Nous avons donc décidé de mettre en lumière 6 conseils primordiaux avant de penser la refonte de votre méthode DevOps de testing vers du testing continu.

Aux bons DevOps les bons outils

 

outils devops

La jungle des outils DevOps, infographie de Alper Ünal

 

Le test continu ne se résume pas en quelques outils. Mais vous aurez besoin des meilleurs outils pour réussir. D’ailleurs, nous vous invitons à lire notre article sur les outils Devops incontournables.

Premièrement, faites en sorte que tous les outils que vous souhaitiez utiliser s’intègrent bien avec votre IDE (integrated development environment) et vos process. Pour cette étape, il n’existe pas de réponse universelle dans la mesure où chaque organisation possède ses propres outils, architectures, frameworks et API. Par exemple, vos outils devront peut-être permettre des tests au niveau de l’API, prendre en charge les environnements mobiles, hybrides et natifs, répondre à certains rôles techniques, etc.

La précision et la vitesse sont également primordiales. Si un outil ne peut pas répondre à la vitesse de déploiement dont vous avez besoin, ou génère trop de faux positifs, l’adoption est compromise. De la même manière, assurez-vous que les outils prennent en charge tout ce dont vous avez besoin pour créer votre projet de A à Z.

Assurez-vous aussi que les outils prennent en charge la traçabilité afin de retrouver facilement l’origine d’un dysfonctionnement.

De manière générale, il est important d’impliquer toute votre équipe dans ce choix et de bien prendre en compte toutes les spécificités de votre organisation.

Automatisation du testing : une étape cruciale

L’automatisation est essentielle aux tests continus si vous voulez vous émanciper des heures de travail de test manuel. Toutefois, la manière d’automatiser et très importante.

Gardez également à l’esprit que les tests automatisés ne testent généralement pas tous les aspects d’une application (comme l’expérience de l’utilisateur final). Vous avez besoin d’humains faisant des évaluations subjectives. Toutefois, vous pouvez également automatiser ces tests via l’ajout d’un examen d’application. Mais en tous les cas, les humains devront terminer l’évaluation réelle et arbitrer en cas de problèmes potentiels enfouis dans le code.

Être prudent lors de l’ajout de nouveaux tests

Faites-en sorte de maintenir une bonne hygiène lorsque vous ajoutez de nouveaux tests pour un nouveau code. Les nouveaux tests doivent augmenter l’efficacité, pas la diluer. Pensez également à ajouter de nouveaux tests dès que vous avez été confrontés à un bug lors d’une implémentation dans un logiciel.

Ce que vous ne voulez pas faire, c’est ignorer les erreurs de vos tests. Cette forme de complaisance peut s’installer lorsque certains tests tournent mal et sont ensuite ignorés et mis en sourdine. Ne tombez pas dans ce piège. Ne laissez pas les test échoués s’accumuler dans vos projets, car cela ne fait qu’augmenter le risque de  livrer un logiciel final défectueux.

La clé est donc votre capacité à maintenir votre ancienne version test tout en vous assurant de la qualité des nouveaux tests.

Ne jamais lésiner sur la sécurité

Il arrive parfois de négliger la sécurité au détriment de la rapidité de livraison. Cela peut entraîner des vulnérabilités dans le code, conduisant à des ralentissements indésirables des processus.

Lors des tests, traitez les failles de sécurité comme vous le feriez pour tout autre problème dans votre DevOps. La philosophie DevOps vous permet de publier des fonctionnalités et des correctifs plus rapidement que jamais, alors utilisez-les aussi pour corriger les failles de sécurité et les vulnérabilités avant qu’ils ne causent des ravages sur votre application.

Un conseil : si des problèmes de sécurité apparaissent dans la version test, vérifiez leur gravité et définissez un seuil de « risque acceptable » pour votre entreprise. Si ce seuil est dépassé, notifiez-le et faites-le savoir à votre équipe DevOps.

Ignorer les failles ne les fera pas disparaître.

Gardez de l’humain dans votre approche CI/CD

La valeur ajoutée des outils automatisés atteint sa limite là où l’humain a encore un rôle à jouer. Même les meilleurs outils ont besoin de mains humaines.

Par exemple, un outil d’analyse statique ne peut pas comprendre la logique métier. Pour trouver les défauts de la logique métier, vous devez souvent effectuer une révision manuelle du code sécurisé en examinant le code source de l’application ligne par ligne. Bien que ce soit manuel, chronophage, laborieux et sujet aux erreurs, l’analyse manuelle reste la plus efficace pour découvrir les failles dans l’architecture et la conception des applications déployées.

Pour l’instant, seul un expert humain est capable d’interpréter des tests et des résultats. Ainsi, même avec du test continu, l’intelligence humaine doit être intégrée au pipeline CI/CD pour arbitrer si un test continu est suffisant ou si des tests manuels doivent être mis en place.

Impliquer l’équipe QA (Quality Assurance) dans le Process

 

schema devops

 

Quand on travaille en mode Agile et DevOps, ce sont les développeurs qui rédigent et exécutent les tests, pas les équipes d’assurance qualité. Mais rien ne vous empêche de consulter leur expertise pour permettre aux développeurs à rédiger de meilleurs tests qualité/sécurité. L’équipe qualité peut aussi aider à maintenir un certains cadre de tests, corriger les tests irréguliers. L’approche et la manière de penser des équipes QA est fondamentalement différente de celle des développeurs. L’apport de leur point de vue ne peut être que positif.

Si votre équipe d’assurance qualité n’a pas de compétences en interne pour coder, vous pouvez quand même les consulter en amont pour les revues de tests, par exemple.

Chez Blue Soft, nous travaillons quotidiennement avec de nombreux experts et consultants DevOps. N’hésitez pas à nous contacter si vous avez des besoins au sein de votre organisation et que vous souhaitez implémenter des méthodes DevOps de testing continu !