DevOps - Le Test dans le continuous testing - neolians

Notes de l'éditeur

• #3: Présentation de 25’ Fin à 1:00
• #4: Fin à 2:00 Le DevOps est la contraction des deux mots Anglais « Development » et « Operations », ou traduit respectivement en Français « Développement » et « Exploitation ». Il s’agit d’un mouvement dont le but est de définir un ensemble de règles et de techniques permettant aux différentes équipes (développement, tests et exploitation) de communiquer efficacement, ainsi que travailler à la fois en coopération et de manière optimale, le tout afin d’améliorer la qualité du produit. Ce petit schéma situe la place du DevOps parmi les autres entités d’un projet : les équipes de développement tentent de répondre à des spécifications fonctionnelles en provenance du métier ou du client. Elles travaillent dans leur propre environnement avec leurs outils optimisés pour les développements et ne se soucient pas de l’impact que peut avoir leurs codes lors de la phase d’exploitation qui, généralement, exécute l’application sur un environnement différent. Les équipes placées du côté de l’exploitation tentent de répondre à des requis non fonctionnels tels que les performances ou la stabilité du système. De ce fait, elles sont plus enclin à minimiser l’impact des modifications afin de conserver ces performances, et cela peut constituer un goulot d’étranglement pour l’ajout de nouvelles fonctionnalités aux applications.
• #5: Fin à 3:00 Le but principale de Devops est l’optimisation, la réduction du temps pour livrer. Donc livrer plus souvent, plus rapidement mais toujours en gardant un niveau d’exigence qualité élevé. Qui dit niveau d’exigence qualité élevé dit obligatoirement la présence d’un effort de test. Donc la brique test est importante afin de garantir la qualité à tous les niveaux développement, opération. ANIMATION Le focus est que contrairement à des méthodologies Waterfall où le test apparaît à la suite du cycle de développement, à des methodologies Scrum/Agile qui se concentre sur le block Développement, lors d’une approche DevOps, le test apparait tout au long de la chaine de production, sur toutes les phases de livraison Dans DevOps, les tests ne sont pas à la fin du cycle de release- il est maintenant intégré au cycle principal / début des cycles de développement et sont au centre afin de delivrer un produit de qualité. In DevOps, testing is not at the end of the release cycle — it is now brought into the mainstream/beginning of development cycles. Developers and system engineers get the code in the right environment for Continuous Integration and Continuous Delivery and those stakeholders enable Continuous Testing and Continuous Monitoring processes in which QA engineers then validates that the team  has built the right application, by seeing and testing if it functions and performs as designed. It is a fundamental role for testing teams to align their test design, test automation, and test case development with DevOps — not only to verify that code changes work but that the changes do not break the product. A key differentiator of DevOps is testing maturity. An organization can automate their integration, testing, delivery, and monitor it, but still have issues with the intelligence of test orchestration and automation, which can lead to a bottleneck if this is not resolved beforehand.
• #6: Fin à 4:00 Le but principale de Devops est l’optimisation, la réduction du temps pour livrer. Donc livrer plus souvent, plus rapidement mais toujours en gardant un niveau d’exigence qualité élevé. Dev Ops se découpe en plusieurs axes.
• #7: Fin à 5:30 Continuous Integration: Gestionnaire de source, compilation, packaging de l’application, test unitaire Continuous Delivery: Capacité à livrer le produit sur different environnement (test, recette, preprod, demo, performance, ….) Continuous Testing: Validation du produit sur les différents environnements Continuous deployment and Monitoring: avant une mise en production déploiement, contrôle du serveur Une des particularité de devops dans sa version ultime dont on a parlé est la suppression de la notion séquentielle. On essaie de faire l’ensemble des étapes en parallèle. Du developpement aux operations…. Les développeurs et les ingénieurs Système livre le code dans le bon environnement pour la Continuous Integration et le Continuous Delivery . Ensuite, ils permettent le lancement du Continuous Testing et du Continuous Monitoring dans lesquels les ingénieurs QA valident alors que l'équipe a construit la bonne application, en voyant et testant si elle fonctionne et fonctionne comme prévu. Les testeurs ont un rôle fondamental dans les équipes afin d'aligner leur conception de test, l'automatisation des tests et le développement de cas de test avec DevOps, non seulement pour vérifier que les changements de code fonctionnent mais que les modifications ne rompent pas le produit. Un facteur de différenciation clé de DevOps est la maturité du test. Une organisation peut automatiser l’intégration, la tester, la livrer et la surveiller, tout en ayant des problèmes avec l'intelligence de l'orchestration de test et de l'automatisation,
• #8: Fin: 7:00 On va essayer de décrire un exemple de process A Droite: les environnement Au centre: les différentes étapes A Gauche les outils: Config Management DataBase: ex puppet,…. 1, on a une idée, un besoin DTO: Dev Test ops Deploy system: Ansible, …
• #9: Fin 8:30 Les principes du test logiciel appliqué à DevOps On veut tester en permanence et en continu Comme tout système de test: Tester Tôt plus on test tôt, plus il est facile de corriger les défauts, et moins ils reviennent cher et plus on a de chance que les défauts soit corrigé avec un minimum d’impact. On ne doit pas se limite pas au code livré, on doit pouvoir tester, revoir également les spécifications (cf ISTQB) Tester tôt, on se doit de tester toute la chaîne. On doit pouvoir aussi appréhender les problème de mise en production, d’upgrade, de sécurité, de performance. Pour cela, monter les tests sur l’ensemble des environnement est important. Par exemple si on ajoute une fonctionnalité, un nouveau concept, ne pas oublier les script de mise à jour de base pour passer d’une version N à N+1, c’est pareil pour l’installation. Il est ballot de s’apercevoir au moment de la mise en prod qu’il manque un alter table ou que dans la configuration Websphere on a oublié un paramètre car l’ensemble des tests ont été réalisé sur un environnement Apache Tester Vite: Tester c’est exécuter et également analyser les résultats. Tester ne se limite au lancement de test, il faut également analyser les résultats en cas de Failure dans les tests. Il faut etre capable de prendre les actions correctives Avoir des tests Fiable pour minimiser l’analyse C’est également Tester mieux, optimiser, choisir les technique de test, les zones à tester les plus adequat Tester Souvent: Vérifier les impacts, être sûr en permanence de la qualité d’un livrable. Par exemple: un éditeur à des cycles standard de livraison de 9 semaines, et des cycle de dev de 3 semaines. Il a besoin de livrer pour un nouveau client. Cette livraison n’intervient pas en fin de cycle mais en milieu de cycle. Il a besoin de s’assurer que la livraison en milieu de cycle est correct, il a besoin d’être sur de la qualité de son produit. Tester automatisé c’est la conséquence. La multiplication des branches, des environnements rend le nombre d’exécution important. Le test manuel ne peut répondre à l’ensemble de ces sollicitations donc L’automatisation est necessaire. Le test automatisé ne se limite pas au test automatique, c’est l’ensemble du processus qui doit être automatisé afin de gagner du temps au déclenchement, à la parallélisation des efforts, à la mise en place des pré-requis de test,la publication des résultats, … Mais Qui teste, où tester et Que tester
• #10: durée: 2’30 Fin 9:30 Que tester: devOps n’apporte pas de nouveauté par rapport au Standard de l’ISTQB. Il implique une plus grande collaboration entre les différents acteurs. En s’affranchissant de la notion séquentielle, Les acteurs ont plus de lien entre eux. En mettant le focus sur la rapidité de livraison, l’ensemble des acteurs BusinessAnalystes, developpeur, intégrateur, ingenieur IT, ingenieur qualité ont besoin de collaborer sur la notion de qualité général du produit et des processus Quand tester: * Une des axiome du continuous testing est tester Souvent. Donc il est necessaire d’optimiser le Quand et le Quoi afin d’obtenir une efficacité optimale Pour chaque phase, action, on a besoin de définir, en fonction de la maturité des équipes et des process, les types de test, leur fréquence à planifier, exécuter.
• #11: Durée 2’30 Fin 12:00 Je voudrais faire un focus particulier sur les environnements ou l’on exécute les tests. En effet en tant que testeur on se focalise généralement essentiellement sur un seul environnement (recette) sur lequel on va dérouler l’ensemble de nos tests. Dans une approche DevOps, le but est de livrer le plus rapidement possible. Pour livrer, on passe par différents environnements. Dans une approche Continuous testing, avec un focus sur l’automatisation, on développe des scripts soit de test ou soit IT. Le coût d’un script est essentiellement dans son développement, son ROI est dans la fréquence d’utilisation. Donc il est très intéressant, optimal de pouvoir lancer les scripts sur les différents environnements intermédiaire afin de s’assurer de la qualité finale du livrable. Sur chaque environnement, on va tester différemment et pas forcément les même choses: en environnement de dev: test unitaires, revue de code, test statique d’analyse de code, compilation, … En environnement d’integration: la mise à jour de l’environnement, la communication entre les différents modules, les tests minimaux Recette: tests fonctionnel bout en bout, mise à jour d’un environnement incrémental Pre-prod: performance, mise à jour d’environnement, …. Production: surveillance de la disponibilité du service, des performances, test d’acceptation, ….
• #12: Durée 1’00 Fin: 13:00 Objectif: Le cycle de livraison est appelé à se réduire, il faut donc s’assurer sur l’ensemble de la chaîne de la qualité Un impact est de diminuer les risques business Challenges: On est dans processus très automatisé, il faut que l’ensemble des acteurs, métiers communique, et que les processus spécifique à chaque métier s’intègre les uns aux autres, les dépendance sont importantes dans la chaîne d’où une maturité importante La gestion des différent environnement avec leur contraintes, leur mise à jour, les types d’actions autorisée. Par exemplesur un environnement de Prod afin de vérifier la disponibilité d’un service, le passage de transaction doit être bridé Les analyses de test: Multiplication des execution => multiplication des analyses. Si il y en a trop, si on ne peut pas analyser certains tests (si trop long, trop instable, …), il n’est plus interessant de les passer car ils nous apportent rien, seulement du bruit, du temps perdu Le but n’est pas de tester plus mais de tester Mieux. Tester les bonnes choses au bon moment, le but n’est pas de tout tester tout le temps car on va se trouver confronter au pb precedent.Le but n’est pas d’avoir 10 heures de test, car test on les bonnes choses, les fonctionnalité utilisées, le code modifiés,… La notion de couverture de code est un indicateur pour augmenter la couverture et la confiance dans les tests. Un facteur de différenciation clé de DevOps est la maturité du test. Une organisation peut automatiser l’intégration, la tester, la livrer et la surveiller, tout en ayant des problèmes avec l'intelligence de l'orchestration de test et de l'automatisation,
• #13: Fin 14:00 Les 4 différentes phases de mise en production d’un projet 1, Développement 2, Déploiement sur des environnements distinct (Dev, test, Intégration, Recette, preprod,…) 3, Test validation, contrôle sur l’environnement choisi 4, Livraison Le but est de maximiser l’automatisation afin de réduire les temps d’attente. Par exemple etre capable d’utiliser les 24h d’une journée pour gagner du temps et non être limité au 8h de travail humain par jour Ici on a des phases standard, mais ou est la spécificité de la méthodologie DevOps.
• #14: Fin 17:00 Outil: Config Management DataBase: ex puppet,…. Deploy system: Ansible, …
• #15: Fin 20:00 Utilisation de 50 Vms pour tester 6 lignes de produits en permanence (7,10 8,1; 8,2, 8,4, 8,5, 8,6) et différentes branches Execution des MAT: environ 1heure Installation et execution sur environ 30 Vms en parallèles Execution des MAT: environ 8heures Installation et execution sur environ 30 Vms en parallèles Test sélectifs: Utilisation de Coverity Test advisor, et intégration dans le flow: Execution de seulement des tests impacté, par les changement de code
• #16: Fin à 4:00 Le but principale de Devops est l’optimisation, la réduction du temps pour livrer. Donc livrer plus souvent, plus rapidement mais toujours en gardant un niveau d’exigence qualité élevé. Dev Ops se découpe en plusieurs axes.
• #17: 1 slides – 5’