Pour nous contacter, une seule solution :
Retrouvez-nous également sur Discord en cliquant sur ce lien !
Contact
La conférence dédiée au test & 100% en ligne !
La conférence dédiée au test & 100% en ligne !
Pour nous contacter, une seule solution :
Retrouvez-nous également sur Discord en cliquant sur ce lien !
S’assurer de la qualité dans un environnement micro-services peut s’avérer compliqué. Chez Agicap, nous avons cherché des solutions afin de tester nos micro-services les uns avec les autres de manière reproductible et performante.
Pour cela, nous nous sommes appuyé sur des outils tels que Selenium, Docker dans un contexte Kubernetes et Gitlab CI afin d’automatiser nos tests d’interfaces. Nous vous expliquerons comment nous avons réussi à mettre en place les éléments suivants :
– Environnement à la volée pour chaque merge request et pour chaque test ( applications + base de données + bus )
– Exécution dans gitlab-ci sur des runners Kubernetes dans GKE
– Enregistrement et sauvegarde des vidéos des tests exécutés
Nous vous expliquerons les différentes solutions envisagées et détaillerons celles que nous avons mises en place. Enfin nous ferons un bilan de ce que ces évolutions ont apporté à l’expérience développeur ainsi qu’à notre qualité globale, puis vous parlerons des améliorations encore envisageables.
Building, grow and integrate QA in a company from scratch is a long and complex journey.
This talk will explain how to use the lean startup aproach and methodology, give experience feedback and provide methodological tools to help QA Leads and Managers in that task.
From starting talking with project teams about quality, we’ll explore how to think as an integrated startup to build tools, QA teams, define products and a business plan to grow the quality processes “as a product”. We’ll make parallels with startup topics like investors, venture capitals, lean startup grid, fast development methodologies and others.
We’ll also cross some notions used to build a QA department taken from social network analysis and management principles, as the goal is to see your team as an attractor and establish links to other departments and key contacts inside the company, customers and market networks.
We’ll examine feedbacks from failures, victories, and how to setup a quick failure process for rapid improvement. We’ll try to propose patterns on how to handle different situations from hiring team members, conversion form manual to automation.
L’accélération des cycles de livraisons est un réel enjeu des organisations. L’étude Accelerate mentionne comme une capacité différenciante celle d’augmenter les cycles de livraisons logiciels tout en maitrisant sa qualité.
Les entreprises qui doivent se transformer ont des maturités différentes. Pour certaines livrer tout le trimestre est encore la réalité. Pour celles en cours d’améliorer, quelle est la cible à atteindre : livrer tous les jours ou bien livrer sur le même rythme que les sprints ?
À La Redoute, nous avons fait le choix d’axer les équipes sur des livraisons journalières, dont le périmètre reste bien défini dans le cadre de sprints et de rituels agiles. Ce choix a entrainé une série d’adaptations, contraintes et apprentissages que nous souhaitions partager avec la communauté.
Notre objectif est de pouvoir contribuer aux expériences d’inclusion de la qualité dans des cycles itératifs et incrémentaux. La cible restant bien l’accélération, l’intégration des différents avantages et inconvénients restent clefs pour en capter les bénéfices.
Nous sommes Tea (escalation manager) et Camille (Lead QA) chez Lifen et nous souhaitons proposer une présentation de la gestion des bugs chez Lifen:
– Quel est le rôle de l’escalation manager?
– A quel problème nous sommes nous confronté dans la gestion des bugs ?
– Comment en est on venu à la création d’une équipe dédiée?
– Qu’est ce que l’équipe « fireline » en charge des bugs remontés en production?
Nous proposons de parler de la mise en place de l’équipe fireline, de son quotidien/son organisation et le retour d’expérience des équipes sur le sujet (support, dev, product, QA).
Nous aborderons également les points positifs et négatifs de ce fonctionnement.
Le test exploratoire est défini comme une approche qui combine apprentissage, conception et exécution des tests.
Contrairement à certaines idées répandues, les activités de tests exploratoires demandent de la discipline, une certaine préparation, et sont documentées.
Le principe des tests exploratoires, leur importance, les facteurs de succès mais aussi leurs défauts font l’objet de plusieurs articles et présentations.
Au travers de ce retour d’expérience, j’aimerais montrer comment les tests exploratoires ont une place prépondérante dans mes activités de testeuse dans une équipe agile.
Les atouts du test exploratoire répondent à nos besoins d’optimisation du temps : nous avons pu réduire le temps accordé à la conception seule, tout en privilégiant les activités d’exécution des tests.
De la préparation des tests jusqu’à l’exécution des campagnes de validation de l’application, en passant par les tests d’intégration et la mise en place de tests automatisés ; je m’appuierai sur des exemples de mon quotidien pour illustrer la mise en pratique de cette approche de tests.
Avec le temps, l’augmentation du nombre de scenarios de tests automatisés peut très vite rendre votre code complètement illisible, non réutilisable, surtout très difficile à maintenir et à déboguer.
Pour éviter d’en arriver là, je vous propose de voir à travers des exemples concrets du Framework Cypress (aussi applicable sur d’autres frameworks):
• Comment faciliter l’analyse et le formatage du code ?
• Comment mettre en place un système de nommage des fichiers, fonctions, variables, etc… ?
• Comment faire le design des fonctions ?
• Comment utiliser efficacement les commentaires ?
• Comment exploiter les logs ?
A la fin de cette session, vous devriez savoir pourquoi le fameux concept de « Clean Code » est intéressant pour les tests automatisés, mais surtout être capable de le mettre en place facilement dans votre architecture ou encore savoir comment refactoriser correctement votre code existant.
Avec la quasi-dominance des Framework agiles dans les équipes Tech, la QA doit toujours s’adapter et trouver un meilleur équilibre entre qualité du livrable et fréquence de livraison.
Ce n’est pas aussi simple avec des produits de plus en plus complexes et des technologies aussi diversifiées qu’aujourd’hui.
Une des stratégies de test qui sort du lot serait le RBT (Risk Based Testing)
Cette session visera à tirer profil de tous ce que le RBT peut apporter à la QA, metrics à l’appui.
Il y aura donc deux grandes parties dans la présentation :
1- Implémenter et optimiser une stratégie basée sur les risques (process, tooling, good case practices) …
2- Evaluer l’efficacité (tooling, KPI, OKRs, amélioration continue)
L’idée est de proposer des quick wins et des hacks qui pourront simplifier le tests et réduire ses coûts :
– Shift left
– Test the usage not the product
– Eyes on ROI
– User centric testing
– Data, data data !
– Behind every good decision, there is some metrics
Quelques outils pourront aussi simplifier la mise en oeuvre de telle stratégie, à citer :
– Xray et Jira (avec des petits tips assez sympa) pour le cahier de recette et la couverture des tests
– EazyBI pour la data
– L’automatisation basés sur les risques avec ReadyAPI et Katalon Studio
Les initiatives de test continu sont confrontées à plusieurs problèmes, dont certains sont étroitement liés aux environnements et aux données de test. Les environnements de bout en bout ne permettent pas les déploiements à la demande, car ils sont généralement partagés entre d’autres applications et utilisés par des testeurs manuels.
L’utilisation d’environnements dynamiques, c’est-à-dire d’environnements à la demande créés de toutes pièces pour l’exécution des tests, aidera à résoudre ces deux problèmes : supprimer la collision avec les tests manuels ou d’autres applications, et contrôler les données de test disponibles pour les tests.
Au cours de cette présentation, je ferai une démonstration d’un pipeline de test en continu pour créer l’infrastructure, déployer et bouchonner l’application, exécuter des tests automatisés, et tout détruire à la fin. Chaque étape sera expliquée, vous donnant ainsi la recette complète du succès des tests en continu.
How at checkout.com in the Issuing Team, we’re using Acceptance TDD as a way to collaborate with QA. The objective of the talk is to show how this way of working associated with Continuous Delivery helped us to reduce the feedback loop between QA and Developer. We will show the benefits of using such practices. How identifying at a very early stage potential bugs can help us to avoid back and forth, and replace bug reporting tools as the main communication channel between QA and Dev by git repository. We will also show how Testing Strategy can be impacted by microservices architecture and show some architectural anti-pattern that can make testing complicated and see how DDD and a good understanding of Bounded Context can help you to keep having an efficient testing strategy with microservices.
Après une bref présentation de mon parcours, je présenterai le monde de la voiture avec son cycle de vie particulier, la quantité d’intervenants répartie aux 4 coins de la planète ainsi que les quelques défis classiques que les constructeurs devaient (doivent) relever. Ensuite je ferais un rappel des défis classiques et génériques que tout type de logiciel demande à relever en terme de qualité ; compréhension du besoin, sécurité, robustesse et bien sûr les délais. S’ensuivra les challenges et les contraintes de la rencontre des deux mondes notamment sur les sujets tels que la qualité des données, les niveaux de tests, les choix judicieux des type et techniques de tests et les impacts de la RGPD. Consécutivement je listerai les leçons apprises et ce qui pourrait être transposer dans un autre secteur. Je conclurai sur la voiture aujourd’hui (sortie et mise à jours à distance) ainsi que les défis que les futures voitures autonomes demanderont.
Début 2020, l’équipe QA était le bottleneck de l’équipe Engineering. Nous avons donc passé plus d’un an à essayer de changer cette mentalité en prenant inspiration chez Atlassian et leur équipe de Quality Assistance ou encore du Modern Testing avec Alan Page.
Un an après beaucoup de choses ont changé: création d’une guilde qualité, changement du nom de l’équipe, changement des rôles, sondages, présentations, atelier avec une société externe, …. et surtout beaucoup de communication.
Jerry Weinberg famously said, « Quality is value to someone ». I find this to be the best definition of quality I’ve heard so far. This « someone », for all intents and purposes, is a customer in your target segment. Meaning, it’s someone whose opinion matters for the success of your product. So, if quality is the value provided to our customers, and our customers are those who find value in our products, then we see there is a direct link between our customers and quality. We want our products, services, features, and functionalities to correspond with customer expectations. We can go even further to say quality isn’t just value to a customer, but « quality is value that meets customer expectations ». Expectations are often implied in the way a service is presented. One of the goals of a good Quality Assurance process is, in effect, to manage these expectations. In this talk, we’re going to examine the dynamic between quality and the customer experience. We are going to look specifically within the music streaming sector as I recount my experience at Qobuz, going from the QA to the Customer side of things.