Blog

Echanges avec Bouzid Belmahdi, Consultant SAP chez QESTIT    

Brownfield, Greenfield : ces termes vous disent-ils quelque chose ?  Si vous envisagez une migration SAP ou travaillez activement à la transition vers SAP S/4HANA, les notions de brownfield et greenfield méritent toute votre attention. Ces approches incarnent deux stratégies distinctes pour implémenter ou migrer des systèmes SAP, chacune adaptée à des contextes spécifiques et à des objectifs différents.  

Echanges avec Asmae Rhnimi, Test Lead chez QESTIT    

Les plateformes SAP, telles que SAP S/4 HANA, ERP R3, CSP et Ariba, offrent des solutions logicielles complètes pour aider les entreprises à gérer, automatiser et optimiser une large gamme de processus métier. Qu’il s’agisse de la chaîne d’approvisionnement, des ressources humaines, de la gestion de la relation client (CRM) ou de la gestion des relations avec les fournisseurs (SRM), ces plateformes fournissent une infrastructure essentielle pour rationaliser les opérations, améliorer l'efficacité et intégrer les dernières innovations technologiques dans les business model des entreprises.

Dans un contexte où la transformation numérique est devenue indispensable pour maintenir la compétitivité, de nombreuses entreprises se demandent comment assurer la durabilité de leurs systèmes d'information. SAP S/4HANA, la dernière solution ERP de SAP, offre non seulement un traitement plus rapide des données et des analyses en temps réel, mais permet aussi de transformer les processus métier grâce à des technologies avancées. Dans cet article, nous allons expliquer pourquoi cette migration a du sens. 

Lorsque l'on parle de migration de systèmes, plusieurs raisons stratégiques peuvent motiver cette démarche. Moderniser l'infrastructure informatique est souvent une priorité, surtout lorsque les systèmes anciens deviennent obsolètes et difficiles à maintenir, à intégrer et à faire évoluer. En adoptant des plateformes plus récentes, les entreprises peuvent profiter de fonctionnalités avancées telles que l’IA et des interfaces utilisateur modernisées, augmentant ainsi la productivité et optimisant la prise de décision. 

Le domaine informatique, en particulier dans le cadre du développement agile, évolue à une vitesse grandissante. Pour s'adapter à ce rythme effréné, les nouvelles technologies, notamment l'Intelligence Artificielle (IA), se positionnent comme des alliés précieux, permettant non seulement d'accélérer la cadence, mais également de fournir un soutien essentiel dans ce processus de transformation rapide.    Il existe de nombreuses IA, certaines spécialisées et d’autres généralistes.Les IA spécialisées peuvent générer du code sans nécessiter une expertise approfondie en programmation ou résumer des pages web entières avec une URL.Les IA plus généralistes peuvent aider les informaticiens à différents niveaux. Elles peuvent accélérer la rédaction de code, clarifier ou corriger des spécifications, ou encore aider à la rédaction des cas de tests, sujet de cet article!    L’IA et le test   Les tests sont primordiaux durant le cycle de développement d’un projet informatique quelle que soit la méthodologie envisagée (ex. cycle en V ou agile). Ils permettent de détecter et corriger au plus tôt des dysfonctionnements graves ou mineurs. La correction des éventuels bugs avant la livraison permet de rendre le produit fiable aux yeux des utilisateurs finaux.    Néanmoins, le test est souvent le parent pauvre d’un projet : le temps de test est réduit par rapport aux autres phases d’un projet ce qui peut compromettre leur exhaustivité. On teste de façon approfondie si on a le temps. Il convient donc d’utiliser ce temps au mieux.   L’intégration de l'IA dans le processus de test permet d'optimiser l'utilisation du temps alloué à l’équipe QA. L’IA peut en effet nous aider à utiliser au mieux le temps disponible en générant des cas de test dans divers langages, notamment en langage naturel, en Gherkin, en anglais même. Bien évidemment, l’IA ne donne pas nécessairement une réponse 100 % conforme aux attentes du logiciel de test mais la réponse obtenue permet de réduire considérablement la charge de travail et de gagner du temps en fournissant une première ébauche de cas de tests.    Un outil d'IA utile   Parmi ces IA, Gemini développée par Google et accessible via l’URL suivante https://gemini.google.com/app avec un simple compte Gmail, est efficace pour sa capacité à interpréter des instructions en langage naturel et à produire des cas de tests correspondants.    Son interface est assez intuitive car elle se compose d’une zone de texte dans laquelle on peut saisir sa requête, ses spécifications ou ses User Stories; des informations pouvant également être soumises par dictée vocale grâce au micro placé dans le champ de la requête.Les réponses obtenues peuvent être plus ou moins abouties suivant le degré de précision de la requête. Si les réponses fournies ne sont pas conformes ou satisfaisantes, un bloc dépliable permet de voir 3 autres suggestions fournies par l’IA. Il est également possible de relancer la requête.De la même façon, une formulation alternative des réponses, plus longue ou plus professionnelle par exemple, peut être demandée.Les réponses obtenues peuvent ensuite être copiées dans le presse papier pour être collées dans notre outil de test.    Gemini est facile à prendre en main et permet de garder un historique de ses requêtes. Toutefois, il est important de rester vigilant quant à la qualité des réponses fournies par l'IA, qui peuvent parfois être incomplètes ou imprécises.    Voici un exemple de cas de test Gherkin sur Gemini:     Après le clic sur le bouton de recherche, le résultat de la requête s’affiche ainsi     L’IA fournit plusieurs résultats :      De même, on peut ajouter un nouveau prompt pour avoir le résultat en anglais      La réponse détaille plus ou moins des cas de tests, et le testeur QA peut en rajouter, ou en enlever, suivant la granularité qu’il souhaite donner à sa campagne.   L’IA face à l’expertise humaine   Bien que l'IA ait fait d'énormes progrès dans la rédaction automatisée des cas de tests, elle ne peut pas encore remplacer complètement le travail d'un testeur. La rédaction des cas de tests ne se limite pas seulement à traduire des spécifications en instructions, mais nécessite également une compréhension approfondie du contexte et des exigences du projet. Les testeurs apportent une expertise critique dans l'identification des scénarios de test pertinents, la détection des failles potentielles et la validation de la logique des tests.    L'IA peut certainement faciliter et accélérer le processus en proposant des suggestions initiales et en automatisant certaines tâches répétitives. Cependant, la rédaction manuelle reste indispensable pour garantir la qualité et la pertinence des cas de tests. De plus, les testeurs apportent un élément de discernement et de créativité qui est difficile à reproduire par des algorithmes.    Pour résumé   En conclusion, l’IA peut être une aide précieuse pour initier ses cas de tests, simplifier et accélérer le processus mais une intervention humaine et clarification manuelle des exigences reste souvent indispensable pour garantir la pertinence et l'efficacité des tests générés. De bien des côtés, l’IA, qui devient omniprésente dans notre société, peut nous faciliter la vie mais comme tout outil son utilisation doit être réfléchie pour voir pleinement les bénéfices.   

Le test basé sur le risque est une méthode qui priorise le test des fonctionnalités logicielles en fonction du risque associé à une erreur et de l'impact potentiel de cette erreur sur l'utilisateur ou le système. En se concentrant sur les domaines présentant le plus de risques, cette approche permet une utilisation optimale des ressources et du temps disponibles. Dans cet article, nous vous présentons quelques méthodes courantes pour effectuer des tests basés sur les risques et quelques modèles utiles que vous pouvez télécharger.   Identification des risques: La première étape consiste à identifier les risques potentiels du logiciel. Il peut s'agir des bugs les plus susceptibles de se produire, des domaines très complexes, des nouvelles fonctionnalités et des fonctionnalités qui ont connu de nombreux problèmes par le passé. Le risque peut également inclure des facteurs externes tels que l'intégration avec des systèmes tiers.   Brainstorming - Réunir une équipe transverse, comprenant des développeurs, des testeurs, des analystes commerciaux et des utilisateurs, pour réfléchir aux risques potentiels. Liste - Utiliser des listes de vérification prédéfinies basées sur des projets antérieurs, des types d'erreurs connues et des normes industrielles pour identifier les risques. Fault Tree Analysis (FTA) - Cette technique permet d'analyser les causes des erreurs potentielles du système. Voici une liste pour identifier les risques dans les projets logiciels. Elle peut servir de point de départ pour l'évaluation des risques au début d'un projet et être régulièrement mise à jour tout au long du cycle de vie du projet.   Liste de contrôle pour identifier les risques dans les projets logiciels   Les modèles sont en anglais. Evaluation et hiérarchisation des risques: Une fois les risques identifiés, ils doivent être évalués et classés par ordre de priorité. Pour ce faire, on évalue généralement la probabilité d'occurrence de chaque risque et l'impact potentiel si le risque se concrétise. Parmi les méthodes couramment utilisées à cette fin figure l'utilisation de matrices de risques où l'on croise la probabilité et l'impact.   La matrice des risques - Créez une matrice des risques dans laquelle vous croisez la probabilité de chaque risque avec son impact potentiel. Cela permet de hiérarchiser visuellement les risques. Le diagramme de Pareto - Cet outil permet d'identifier et de se concentrer sur les risques qui auront le plus d'impact sur le projet, souvent appelés « les quelques risques importants ». Nous avons préparé un modèle de matrice des risques, accessible via le formulaire. En utilisant une matrice des risques, vous pouvez visualiser et gérer efficacement les risques de votre projet, ce qui contribue à une meilleure prise de décision et augmente les chances de réussite du projet.   Création des cas de test: Les cas de test sont développés pour cibler spécifiquement les risques les plus prioritaires. Cela permet de s'assurer que les parties les plus critiques du système sont testées de manière approfondie.   Les scénarios d'utilisation : Élaborer des cas de test basés sur des scénarios d'utilisation réalistes susceptibles d'être affectés par les risques identifiés. Scénarios de test basés sur les risques : Rédiger des scripts de test détaillés qui se concentrent sur l'exploration et la vérification des domaines présentant les risques les plus élevés. Deux autres modèles sont disponibles : l'un contient un exemple de ce à quoi pourrait ressembler un script de test détaillé et l'autre concerne la rédaction de scénarios d'utilisation, également suivis d'un exemple concret.   Modèle réaction de scénarios    Modèle script de test   Exécution des tests et suivi: Une fois les tests conçus et préparés, ils sont exécutés en fonction de la priorité fixée. Pendant la phase de test, il est important de documenter et de suivre attentivement les résultats des tests, en particulier lorsque des erreurs sont détectées. Cela permet d'évaluer le niveau de risque au cours du projet.   Les outils de gestion des tests - Utilisez des outils tels que JIRA, TestRail ou Zephyr pour gérer les cas de test, surveiller l'exécution et documenter les résultats. Les outils de test automatisés - Utilisez l'automatisation le cas échéant, en particulier pour tester les domaines à haut risque et pour les tests de régression. Réévaluation des risques: Les risques doivent être réévalués régulièrement tout au long du cycle de vie du projet. Si de nouveaux risques apparaissent ou si des changements apportés au projet affectent l'évaluation initiale des risques, il peut être nécessaire de réviser le plan de test et les priorités de test.   Les réunions d'examen régulières - Organiser des réunions régulières pour réévaluer et mettre à jour les évaluations des risques sur la base des résultats des tests et d'autres mises à jour du projet. Les feedbacks - Mettre en place un mécanisme de retour d'information rapide des testeurs vers l'équipe de projet afin de traiter et de réévaluer les risques en permanence. Reporting et prise de décision: Enfin, il est important de communiquer les résultats des tests et les risques restants à toutes les parties prenantes. Cela permet à la direction de prendre des décisions en toute connaissance de cause sur la mise à disposition du logiciel, sur la base d'un niveau de risque acceptable.   Les tableaux de bord - Utilisez des tableaux de bord pour obtenir une vue d'ensemble de l'état d'avancement des tests et des risques restants. Les rapports détaillés - Créer des rapports détaillés mettant en évidence les résultats des tests, les risques identifiés et les recommandations pour les étapes suivantes. Et oui, vous l'avez deviné, nous avons un modèle pour vous. Celui-ci vous aidera à créer un rapport détaillé sur les résultats des tests, les risques identifiés et les recommandations. Il permettra également aux parties prenantes de comprendre rapidement l'état d'avancement du projet et les mesures à prendre.    Modèle rapport de test détaillé   L'utilisation de ces méthodes et outils peut améliorer de manière significative la qualité et l'efficacité des tests basés sur le risque, en garantissant que les ressources sont utilisées là où elles ont le plus d'impact sur la réduction du risque dans votre projet et le plus d'impact potentiel sur le succès et la qualité du projet.

Se lancer dans l'automatisation des tests nécessite une planification et une préparation minutieuses. Avant de se lancer dans la création de scripts et la sélection d'outils, il est essentiel de poser des bases solides. Cela implique de comprendre les conditions préalables et de faire les préparatifs nécessaires pour assurer une transition en douceur vers les tests automatisés.      Comprendre la demande et ses exigences   La première étape consiste à bien comprendre l'application à tester. Cela comprend :   Fonctionnalité : Comprendre les principales fonctionnalités et les flux d'utilisateurs de l'application.  Pile technologique : Se familiariser avec les technologies utilisées dans l'application, car cela influencera le choix de l'outil.  Exigences en matière de tests : Identifier ce qui doit être testé, y compris les fonctionnalités spécifiques, les critères de performance et les scénarios d'utilisation.      Définir des objectifs clairs pour l'automatisation des tests   Établissez des objectifs clairs pour ce que vous voulez réaliser avec l'automatisation des tests. Ces objectifs peuvent être les suivants    Améliorer la couverture des tests : Veiller à ce qu'un plus grand nombre de parties de l'application soient testées.  Accélérer le processus de test : Réduire la durée des cycles d'essai.  Améliorer la précision des tests : Minimiser l'erreur humaine dans les tests.      Constituer une équipe qualifiée   Constituer une équipe avec la bonne combinaison de compétences. Cette équipe doit comprendre des membres ayant les compétences suivantes    Expertise technique : Compréhension des langages de programmation et des cadres de test.  Tester les connaissances : Connaissance approfondie des principes et méthodologies d'essai.  Compétences en résolution de problèmes : Capacité à résoudre les problèmes et à optimiser les cas de test.      Mise en place d'un environnement de test   La mise en place d'un environnement de test dédié est essentielle. Il s'agit notamment de :   Exigences matérielles et logicielles : Veiller à ce que l'infrastructure nécessaire soit en place.  Access to Necessary Data: Fourniture de données d'essai qui reproduisent des scénarios réels.  Isolement de la production : L'environnement de test doit être séparé de l'environnement de production afin d'éviter toute interférence.      Développer une stratégie d'automatisation des tests   Une stratégie bien définie doit donner les grandes lignes :    Champ d'application de l'automatisation : Déterminer les tests qui seront automatisés et ceux qui resteront manuels.  Sélection du cadre et des outils : Choisir les cadres et les outils en fonction de la pile technologique de l'application et des exigences en matière de tests.  Intégration dans les processus de développement : Planifier l'intégration de l'automatisation des tests dans les processus de développement et de déploiement existants.    Conclusion   La préparation est la clé de la transition vers l'automatisation des tests. Comprendre l'application, fixer des objectifs clairs, constituer une équipe compétente, établir un environnement de test et développer une stratégie globale sont des étapes vitales qui jettent les bases d'une automatisation des tests réussie. Avec ces éléments en place, les organisations peuvent se lancer dans l'automatisation des tests en toute confiance, ce qui se traduit par des processus de test plus efficaces, plus précis et plus fiables. 

Ces dernières années, l'émergence de plateformes low code et no-code a considérablement transformé les processus de développement d'applications, en démocratisant l'accès au développement et en répondant à la demande de livraison rapide. Cet article explore l'impact de ces plateformes sur l'automatisation des tests.    Aperçu rapide   Les plateformes low code et no code visent à rationaliser le développement d'applications en proposant des interfaces intuitives et des fonctionnalités de type "glisser-déposer", ce qui permet aux utilisateurs de créer des applications sans avoir à se plonger dans de longues lignes de code. Pour saisir l'importance de ces approches, examinons d'abord quelques chiffres clés :    La pandémie de Covid-19 a agi comme un catalyseur pour l'adoption d'outils no-code, 82 % des utilisateurs ayant commencé à les utiliser au cours de cette période. Cette vague d'adoption met en évidence l'agilité et l'adaptabilité offertes par ces plateformes en temps de crise.  En outre, les prévisions de Gartner selon lesquelles, d'ici 2024, les outils low-code représenteront plus de 65 % de l'activité de développement d'applications en disent long sur le potentiel de transformation de ces plates-formes. Cette prédominance prévue souligne la reconnaissance croissante des approches low-code et no-code en tant qu'éléments essentiels du paysage de développement moderne.  Un rapport de Redhat a révélé que l'utilisation de solutions no code low code peut réduire le temps de développement des applications jusqu'à 90 % par rapport aux approches traditionnelles. Cette réduction du temps de mise sur le marché souligne non seulement les gains d'efficacité et de productivité facilités par ces plateformes, mais aussi leur capacité à révolutionner la vitesse et l'agilité avec lesquelles les applications sont mises sur le marché.    Impact sur l'automatisation des tests   L'automatisation des tests est essentielle pour garantir la fiabilité et l'efficacité des applications. Les projets d'automatisation réussis nécessitent une méthodologie rationalisée reposant sur un cadre bien défini, englobant une planification méticuleuse, une conception robuste des cas de test et une couverture complète.    De plus, avec l'accélération des cycles de développement des logiciels, les stratégies d'automatisation doivent s'adapter rapidement aux itérations rapides et aux versions fréquentes tout en maintenant une qualité irréprochable. Cela nécessite un ajustement rapide des cadres et des scripts d'automatisation.    Face à ces défis, il est essentiel de choisir le bon outil d'automatisation, car il doit également s'aligner sur les objectifs du projet. Des facteurs tels que la facilité d'utilisation, l'évolutivité, la compatibilité et la prise en charge de diverses technologies doivent être pris en compte. Les plateformes low code et no code se présentent comme des solutions viables, offrant des interfaces intuitives, des flux de travail rationalisés et des composants de test préconstruits. Ces plateformes offrent un environnement convivial pour la création et l'exécution des cas de test, rationalisant ainsi l'ensemble du cycle de vie des tests.   Cycles de développement rapides    En rationalisant le processus de test et en réduisant le besoin de scripts manuels, les plateformes low code et no-code accélèrent les cycles de développement. Les équipes peuvent rapidement créer et exécuter des cas de test, identifier les bogues et apporter des améliorations aux logiciels, le tout dans des délais plus courts. Cette agilité dans l'automatisation des tests s'aligne sur le rythme rapide du développement des logiciels modernes, où des mises à jour et des versions fréquentes sont essentielles pour rester compétitif sur le marché.    Évolution    Ces plateformes fournissent des composants de test prédéfinis et des modèles personnalisables, ce qui permet aux équipes d'adapter leurs cadres d'automatisation à l'évolution des exigences du projet et aux progrès technologiques. Qu'il s'agisse d'augmenter les efforts de test pour des projets plus importants ou d'intégrer de nouvelles fonctionnalités dans des applications existantes, la flexibilité des plateformes low-code et no-code permet des ajustements transparents sans compromettre la couverture ou la qualité des tests.    Plates-formes adaptées aux créateurs   Le côté adapté à l'utilisateur ou, pourrions-nous dire, adapté pour le créateur de ces plateformes rationalise le processus de test, permettant aux équipes de concevoir, d'exécuter et d'analyser rapidement les tests, ce qui facilite en fin de compte la livraison plus rapide d'un logiciel de haute qualité.    Inclusivité    Traditionnellement, l'automatisation des tests a été perçue comme une entreprise complexe et gourmande en ressources, nécessitant des compétences spécialisées et des connaissances approfondies en matière de codage. Cependant, avec l'avènement d'outils à low code ou no-code, l'automatisation des tests est devenue plus accessible à des personnes ayant des antécédents et des compétences variés. Cette inclusion élargit le réservoir de talents et enrichit la qualité globale des initiatives d'automatisation des tests.    Collaboration    Les plateformes low code et no code favorisent la collaboration entre les services informatiques et les acteurs de l'entreprise, garantissant ainsi de manière plus accessible que les applications qui en résultent répondent aux besoins et aux attentes spécifiques des parties prenantes.    La montée en puissance des plateformes low code et no code a redéfini le paysage du développement d'applications et de l'automatisation des tests. Ces plateformes démocratisent non seulement l'accès au développement, mais rationalisent également les processus de test, en favorisant la collaboration et en accélérant les délais de livraison. Grâce à leurs interfaces intuitives et à leur conception inclusive, elles permettent à diverses équipes de créer efficacement des logiciels de haute qualité. En bref, les plateformes low code et no code marquent un tournant vers une approche plus accessible, plus collaborative et plus agile du développement et des tests de logiciels.    Sources: Gartner forecasts worldwide low-code development technologies market to grow 20% in 2023, Gartner, 2022 Research Intelligent process automation analyst paper, Redhat, 2018 State of Low Code Whitepaper,  Mendix, 2021 

Être un test lead à distance présente de nombreux défis. Vous aurez besoin de gérer les différences culturelles et d'établir un environnement propice à la collaboration et à la confiance. Aujourd'hui, alors que de plus en plus d'entreprises et d'organisations travaillent avec des équipes externalisées et/ou opèrent à distance depuis la pandémie, il est important de réfléchir à la meilleure façon de travailler avec son équipe. En instaurant d'emblée la confiance au sein de celle-ci, vous augmentez vos chances d'avoir une équipe plus performante. Je vous livre ici mes trois meilleurs conseils pour créer cette confiance solide et cruciale.   Que vous soyez test lead, chef de projet, coach ou que vous occupiez toute autre fonction de responsable, la confiance est ce qui fait la différence lorsqu'il s'agit de constituer une équipe. La question de la confiance peut être délicate et c'est souvent quelque chose qui est facilement négligé ou du moins qui n'est pas pris en compte quotidiennement. Cependant, la question de la confiance devrait toujours figurer à l'ordre du jour et, idéalement, être une priorité des managers, chaque jour et lors de chaque réunion. Que ce soit à distance ou sur site.   Ne pas instaurer la confiance entre vous et votre équipe est un moyen infaillible de créer du stress et des conflits au sein de l'équipe. Cela se traduit par des performances médiocres à l'intérieur de celle-ci et, en fin de compte, par des résultats médiocres. Il y a bien sûr de nombreuses façons pour vous, en tant que dirigeant, d'instaurer la confiance, mais voici trois facteurs qui, selon moi, sont importants pour réussir :   Pour gagner la confiance, il faut la donner.   Ce n'est probablement une surprise pour personne, mais je crois que tous les membres de votre équipe seront plus enclins à se donner les moyens de réussir grâce au respect et à la confiance donnés par le manager. Céder régulièrement son autorité est toujours un bon moyen d'instaurer la confiance et de gagner le respect. Par exemple, lorsque vous organisez des réunions, pourquoi ne pas faire tourner la responsabilité et laisser différentes personnes diriger la réunion ? Ensuite, essayez de déléguer la prise de décision à des collègues ou à l'ensemble de l'équipe aussi souvent que possible.   L'information doit toujours circuler.   Les membres de votre équipe s'épanouiront plus facilement s'ils comprennent le contexte de leur travail, s'ils réalisent qu'ils font partie d'un ensemble plus vaste et que leur travail est important pour la réussite du projet. Tenez toujours votre équipe informée des hauts et des bas, ainsi que de ce qui est discuté lors des réunions de projet, des comités de pilotage ou de toute autre information utile permettant à votre équipe d'avoir une vue d'ensemble du projet. Votre transparence montre que vous faites confiance aux membres de votre équipe lorsque vous partagez des informations importantes avec eux.   Faire preuve d'initiative.   N'oubliez pas de montrer que vous n'êtes qu'un être humain. Si vous faites une erreur, admettez le. Si vous souhaitez obtenir un retour d'information sur vos performances, demandez le et faites quelque chose de positif avec les informations reçues. Lorsque vous recevez un feedback, il est également important de ne pas oublier d'en faire part aux membres de votre équipe et de les remercier pour leur contribution. Lorsque quelque chose ne va pas, c'est vous, en tant que chef, qui devez prendre le premier "coup", oser vous mettre sous le feu des projecteurs et assurer les arrières des membres de votre équipe. Par la suite, lorsque la situation a été maîtrisée, encouragez votre équipe à partager, à vous faire un retour pour connaître leur ressenti, positif comme négatif. Utilisez vos propres erreurs pour enseigner aux autres !

Le paysage de l'automatisation des tests est riche d'une variété d'outils et de technologies, chacun conçu pour répondre à des besoins de test spécifiques. Il est essentiel de comprendre ces outils et leurs capacités pour automatiser efficacement les processus de test dans le cadre du développement de logiciels.     Catégories d'outils d'automatisation des tests   Les outils d'automatisation des tests peuvent être classés en plusieurs catégories, chacune ayant un objectif différent :   Outils de tests unitaires : Ces outils sont utilisés pour tester des unités ou des composants individuels du logiciel. Les exemples incluent JUnit pour Java et NUnit pour les applications .NET. Outils de test d'intégration : Ils se concentrent sur les tests des interfaces et des interactions entre les composants ou les systèmes. Des outils comme Postman et SoapUI sont populaires pour les tests d'API et de services. Outils de test fonctionnel et de régression : Pour tester la fonctionnalité d'une application dans son ensemble, des outils tels que Selenium et QTP (QuickTest Professional) sont couramment utilisés. Outils de test de performance : Ces outils, comme JMeter et LoadRunner, évaluent les performances des applications dans diverses conditions. Outils de test mobile : Des outils spécialisés pour les applications mobiles, comme Appium et Espresso, répondent aux besoins de test uniques des plateformes mobiles.     Principaux éléments à prendre en compte pour le choix de l'outil   Le choix de l'outil adéquat implique plusieurs considérations clés :   Compatibilité avec l'environnement de développement : L'outil doit s'intégrer de manière transparente à l'environnement de développement et de test existant. Facilité d'utilisation et courbe d'apprentissage : Les outils doivent être conviviaux, accompagnés d'une documentation adéquate et bénéficier du soutien de la communauté. Évolutivité et flexibilité : L'outil doit être capable de gérer des charges de test croissantes et de s'adapter à l'évolution des exigences du projet. Coût et licence : Les contraintes budgétaires et les modèles de licence sont également des facteurs importants dans le processus de décision.     Technologies émergentes dans l'automatisation des tests   Le domaine de l'automatisation des tests est en constante évolution, avec l'apparition de nouvelles technologies qui améliorent ses capacités :   L'intelligence artificielle (AI) et l'apprentissage automatique (ML) : L'IA et le ML sont de plus en plus utilisés dans l'automatisation des tests pour l'analyse prédictive, l'optimisation des suites de tests et la génération de tests intelligents. Outils de test basés sur le cloud : Les plateformes cloud offrent des solutions évolutives, flexibles et rentables pour l'automatisation des tests, permettant d'accéder à un large éventail d'environnements et de configurations de test. Conteneurisation et virtualisation : Des technologies comme Docker et Kubernetes facilitent la création d'environnements de test isolés et reproductibles, améliorant ainsi l'efficacité et la cohérence de l'exécution des tests.     Conclusion   Le choix des outils et des technologies d'automatisation des tests est un aspect critique qui influence l'efficacité du processus de test. En évaluant et en sélectionnant soigneusement les outils appropriés, et en se tenant au courant des technologies émergentes, les équipes peuvent garantir une stratégie d'automatisation des tests solide et efficace qui s'aligne sur les besoins de leur projet.

L'automatisation des tests, lorsqu'elle est exécutée correctement, peut changer la donne en matière de développement de produits. Toutefois, il est essentiel de connaître et d'éviter les pièges les plus courants pour en exploiter pleinement le potentiel.     Piège 1 : Dépendance excessive à l'égard de l'automatisation   On pense souvent à tort que tous les tests devraient être automatisés. Cependant, tous les tests ne se prêtent pas à l'automatisation.   Stratégie : Prioriser les tests à automatiser en fonction de leur fréquence d'exécution et de leur impact. Maintenir un équilibre entre les tests manuels et automatisés pour obtenir des résultats optimaux. Gain en matière de développement de produits : Cet équilibre permet de réaliser des essais plus complets, en veillant à ce que les contrôles détaillés et les aspects plus généraux de l'expérience de l'utilisateur soient couverts.   Piège 2 : Planning inadapté   Se lancer dans l'automatisation des tests sans une planification adéquate peut conduire à des résultats chaotiques et inefficaces.   Stratégie: Développer une stratégie claire d'automatisation des tests, en définissant les objectifs, la portée, la sélection des outils et l'intégration dans le processus de développement. Gain en matière de développement de produits : Proper planning ensures that test automation aligns with the product goals, enhancing the efficiency and effectiveness of the development process.   Piège 3 : Choisir les mauvais outils     La sélection d'outils qui ne correspondent pas aux exigences du projet ou à la pile technologique peut entraver le processus de test.   Stratégie: Évaluer les outils en fonction de leur compatibilité avec la pile technologique, de leur facilité d'utilisation, du soutien de la communauté et de leur évolutivité. Gain en matière de développement de produits : Les bons outils permettent d'augmenter considérablement la vitesse et la précision des tests, d'accélérer les cycles de développement et d'améliorer la qualité des produits.     Piège 4 : Négliger la maintenance des tests   Les tests et les cadres doivent être régulièrement mis à jour pour rester adaptés à l'évolution des applications.   Stratégie: Allouer du temps à l'examen régulier et à la maintenance des scripts de test afin de garantir leur efficacité au fil du temps. Gain en matière de développement de produits : Les tests actualisés restent pertinents et efficaces, ce qui réduit le risque de laisser passer des défauts et permet de maintenir des normes élevées pour les produits.     Piège 5 : Compétences insuffisantes en matière de tests   L'automatisation des tests nécessite une combinaison de connaissances en matière de tests et de compétences techniques.   Stratégie : Investissez dans la formation et le développement des membres de l'équipe ou embauchez des personnes possédant les compétences nécessaires. Gain en matière de développement de produits : Une équipe de test qualifiée améliore la qualité des tests automatisés et manuels, ce qui a un impact direct sur la fiabilité et l'aptitude à la commercialisation du produit.     Piège 6 : Absence de contrôle continu   Ne pas surveiller en permanence le processus d'automatisation des tests peut conduire à des défauts négligés et à des inefficacités.   Stratégie Mettre en œuvre des outils et des pratiques de surveillance pour vérifier régulièrement les performances et l'efficacité de l'automatisation des tests. Gain en matière de développement de produits :: Le contrôle continu permet d'identifier et de rectifier immédiatement les problèmes, ce qui garantit un cycle de développement harmonieux et efficace.     Piège 7 : Ignorer la gestion des données de test     Une mauvaise gestion des données de test peut entraîner des tests non représentatifs et inefficaces.   Stratégie: Établir des procédures solides pour la création, la gestion et la maintenance des données d'essai afin d'en garantir la pertinence et la qualité. Gain en matière de développement de produits :: Des données d'essai de qualité garantissent que les essais sont réalistes et représentatifs, ce qui permet de réaliser des essais de produits plus fiables et plus pertinents pour le marché.   Richard Bradshaw, connu sous le nom de @FriendlyTester, énumère les principales causes d'échec dans l'automatisation des tests.   commencer par la sélection des outils l'utilisation d'un seul framework séparer la stratégie de test de la stratégie d'automatisation l'automatisation à un stade avancé du cycle de développement l'automatisation d'une faible testabilité supprimer les éléments humains l'exécution de tous les tests à chaque construction se concentrer uniquement sur l'automatisation de l'interface utilisateur s'efforcer d'obtenir une couverture de code de 100 % sans tester les tests eux-mêmes)     Conclusion   En évitant ces pièges courants de l'automatisation des tests, les entreprises peuvent tirer des avantages significatifs de leur cycle de développement de produits. Ces avantages comprennent une efficacité accrue, une meilleure qualité du produit, une mise sur le marché plus rapide et un produit final plus robuste et plus fiable. Reconnaître et relever stratégiquement ces défis ouvre la voie à un parcours d'automatisation des tests fructueux et couronné de succès.

Être consultant signifie souvent passer d'une mission à l'autre sans interruption. Il s'agit d'une activité passionnante et stimulante, qui exige un développement constant pour éviter de s'enliser dans la routine et les vieilles habitudes, mais aussi d'être conscient de soi pour éviter l'épuisement professionnel. C'est pourquoi il peut être judicieux de profiter du temps qui s'écoule entre deux missions pour réfléchir, mais surtout pour apprendre de nouvelles choses. Dans cet article, j'ai donc pensé partager avec vous la façon dont, en tant que consultant QA senior en test et assurance qualité, j'ai utilisé le temps entre deux missions pour améliorer mes connaissances et mes compétences et rester motivé. Je vous donnerai également quelques conseils sur la manière de tirer le meilleur parti de votre temps "libre" en tant que consultant.   Pensez à vous et à votre carrière   Lorsque vous êtes en mission, il est facile de vous concentrer entièrement sur les besoins et les exigences du client et d'oublier vos propres objectifs, vos intérêts et votre propre développement en tant que consultant. Mais entre deux missions, vous avez enfin le temps de penser à vous et à votre carrière. Que voulez-vous réaliser en tant que consultant ? Quels sont les domaines dans lesquels vous souhaitez vous développer ? Quels types de missions recherchez-vous ? Avec quels clients voulez-vous travailler ? Il est essentiel de réfléchir à ces questions et d'avoir une vision claire de votre avenir en tant que consultant. Cela peut vous aider à trouver votre créneau, votre passion et votre orientation.   Créer un plan de développement   Lorsque vous avez une idée claire de ce que vous voulez faire en tant que consultant, il est temps d'élaborer un plan pour y parvenir. Vous pouvez commencer par faire une analyse de l'état actuel de vos connaissances et de vos compétences. Que savez-vous faire ? Que devez-vous améliorer ? Quelles sont les compétences demandées sur le marché ? Vous pouvez utiliser différents outils pour établir une cartographie des compétences, par exemple l'analyse des lacunes en matière de compétences. L'analyse des écarts de compétences est un outil qui vous aide à identifier et à mesurer la différence entre les connaissances et les compétences que vous possédez et celles dont vous avez besoin pour accomplir votre travail en tant que meilleur consultant test. Grâce à l'analyse des écarts de compétences, vous pouvez classer par ordre de priorité les domaines dans lesquels les écarts sont les plus importants et planifier la manière dont vous les développerez. Vous pouvez ensuite fixer des objectifs concrets et des délais pour votre développement et choisir les méthodes et les ressources que vous utiliserez pour les atteindre. Vous avez la possibilité de participer à des cours, des webinaires, des ateliers, des conférences, des réunions de mise en réseau ou des programmes de mentorat. Vous pouvez également lire des ouvrages professionnels, des articles, des blogs et écouter des podcasts dans votre domaine, ainsi que dans celui du développement personnel. Les occasions d'apprendre de nouvelles choses sont nombreuses, tant en ligne qu'en personne.   Apprenez ce que vous voulez à votre rythme et de la manière que vous préférez   L'un des avantages de la mobilité est que vous pouvez apprendre à votre rythme et de la manière qui vous convient le mieux. Vous n'avez pas à vous adapter au rythme, à l'horaire ou aux préférences du client. Vous pouvez choisir ce que vous voulez apprendre et comment vous voulez l'apprendre. Vous pouvez également être plus concentré et plus efficace, car vous disposez de 39 heures par semaine à consacrer à votre formation. Par exemple, vous pouvez vous plonger dans un sujet qui vous intéresse ou essayer quelque chose de complètement nouveau qui vous met au défi. Vous pouvez également varier votre apprentissage en utilisant différents formats et en combinant la théorie et la pratique, par exemple en apprenant un concept à partir de tutoriels pratiques sur YouTube ou de cours Udemy, puis en le testant dans le cadre d'un projet réel.   Travailler dur comme d'habitude tout en récupérant   Le fait d'être entre deux missions n'est pas seulement une chance d'apprendre de nouvelles choses, c'est aussi une chance de se reposer et de récupérer. Le métier de consultant peut être stressant et exigeant et il est important de prendre soin de sa santé et de son bien-être. C'est pourquoi il peut être bon de profiter de l'occasion pour faire des choses qui vous donnent de l'énergie, de la joie et de la détente. Il peut s'agir, par exemple, de faire de l'exercice à la salle de sport ou de rencontrer d'autres consultants. Il existe également une différence entre travailler pour répondre aux exigences des clients et décider soi-même de sa semaine de travail. Vous travaillez à 100 % dans les deux cas, mais il y a une grande différence pour le cerveau si vous n'êtes responsable que de vous-même ou d'un client. Lorsque vous êtes entre deux missions, vous pouvez fixer vos propres limites, routines et priorités. Vous pouvez également renforcer votre relation avec votre société de conseil, après avoir été plus ou moins déconnecté de vos collègues consultants. Par exemple, vous pouvez participer à des activités internes, échanger des expériences, donner et recevoir un retour d'information ou simplement discuter et vous amuser.   Stimulez votre motivation et vos performances   Le fait d'être entre deux missions peut également être l'occasion de stimuler votre motivation et vos performances. Après avoir effectué une mission pendant un certain temps, vous pouvez vous sentir à l'aise et perdre un peu de votre motivation. Mais lorsque vous êtes entre deux missions, vous pouvez être plus engagé et désireux d'apporter de la valeur à un nouveau client. Vous pouvez également mettre en valeur vos nouvelles connaissances, compétences et certificats, ce qui vous rend plus attractif et compétitif sur le marché. L'un des meilleurs moyens de maintenir la motivation est d'obtenir diverses certifications qui prouvent que vous avez appris quelque chose et que vous avez réussi un examen. Vous recevrez non seulement une reconnaissance, mais aussi une récompense. C'est donc une situation "gagnant-gagnant", tant pour vous que pour vos futurs clients, lorsque vous vous perfectionnez.   Pourquoi les clients devraient vous choisir comme consultant   En mettant à profit le temps qui s'écoule entre deux missions, vous n'investissez pas seulement dans votre propre avenir, mais vous offrez également des avantages uniques à vos futurs clients. C'est l'occasion de vous perfectionner et de développer votre offre. C'est un investissement dans votre avenir, qui peut vous donner de grands avantages lorsque vous êtes à la recherche de nouvelles missions. Mais ce n'est pas seulement vous qui y gagnez, mais aussi vos futurs clients. Entre deux missions, vous avez l'occasion d'apprendre les dernières tendances et pratiques en matière d'informatique et d'assurance qualité, que vous pouvez ensuite utiliser pour résoudre les problèmes des clients et créer de la valeur pour eux. Vous avez également la possibilité d'améliorer vos connaissances, vos aptitudes et vos certifications, que vous pouvez ensuite présenter pour prouver votre compétence et votre professionnalisme. Enfin, vous avez la possibilité d'accroître votre motivation et vos performances, que vous pouvez ensuite transférer à votre travail afin d'assurer une qualité élevée et la satisfaction du client. En tant que consultant entre deux missions, vous n'êtes pas seulement une ressource disponible, mais un partenaire attrayant. Les clients devraient donc vous choisir comme consultant parce que vous avez quelque chose de plus à offrir. Vous n'avez pas seulement une expérience pratique, mais aussi un engagement. Vous n'avez pas seulement des connaissances, mais aussi de la curiosité. Vous n'avez pas seulement des compétences, mais aussi de l'ambition. Vous êtes un consultant qui grandit et se développe continuellement entre deux missions - ce qui, je le sais, est très demandé sur le marché.     Au mois de décembre, des consultants basés dans différents pays ont donné leurs meilleurs conseils pour rester à jour en vidéo.   Pour en savoir plus sur ces conseils, cliquez sur l'image ci-dessous.

Chaque système est unique et possède ses propres conditions. Qu'il s'agisse d'un système avec ses propres ajustements, d'un développement par des tiers ou entièrement interne, chacun demande une approche adaptée à l'automatisation des tests. Cette personnalisation est essentielle pour répondre aux besoins spécifiques des systèmes complexes, réglementés ou hérités.    Une automatisation de test efficace va au-delà de la simple exécution de scripts ; elle nécessite une approche stratégique intégrée dans le cycle de développement logiciel. Cela optimise non seulement l'efficacité des tests, mais améliore également de manière significative la qualité globale du logiciel.    Établir des objectifs clairs pour l'automatisation des tests   Établir des objectifs précis est primordial dans l'automatisation des tests. Ces objectifs devraient être en accord avec les objectifs plus larges du projet logiciel. Par exemple, réduire le temps des tests de régression ou améliorer la couverture des tests. Avantages : Des objectifs clairs garantissent des efforts ciblés et une allocation efficace des ressources, ce qui conduit à des processus de test plus efficaces. Risques : Sans objectifs spécifiques, les efforts d'automatisation des tests peuvent manquer de direction, entraînant une perte de ressources et des inefficacités.    Choisir les bons outils   Le choix des outils est un facteur critique dans l'automatisation des tests. Considérez la compatibilité avec la pile technologique, le support pour les types de tests et le soutien de la communauté. Avantages : Les bons outils simplifient le processus de test, améliorent la précision et renforcent la productivité de l'équipe. Risques : Des outils inappropriés peuvent entraîner des problèmes d'intégration, des courbes d'apprentissage plus longues et des tests inadéquats, affectant finalement la qualité et le calendrier du projet.    Créer un cadre d'automatisation des tests efficace   Un cadre robuste est la base d'une automatisation des tests réussie. Il devrait offrir des directives claires et soutenir la scalabilité. Avantages : Un cadre efficace garantit la cohérence des tests, réduit les coûts de maintenance et s'adapte aux changements du projet. Risques : Sans un cadre solide, les scripts de test peuvent devenir ingérables et sujets aux erreurs, augmentant les coûts de maintenance et diminuant la fiabilité des résultats des tests.    Intégrer l'automatisation des tests dans le processus de développement   Incorporer l'automatisation des tests dans le processus de développement, notamment via l'intégration continue (CI), est essentiel. Avantages : L'intégration garantit un retour immédiat sur les changements de code, favorisant une culture de qualité et réduisant le temps de mise sur le marché. Risques : Ne pas intégrer l'automatisation des tests peut entraîner une découverte tardive des défauts, des flux de travail disjoint et une augmentation du temps et des coûts de correction des bogues.    Surveillance et Rapports   Les mécanismes de surveillance et de reporting efficaces fournissent des informations précieuses. Avantages : Ils aident à évaluer l'efficacité de la stratégie d'automatisation des tests et facilitent la prise de décision pour les améliorations. Risques : Sans surveillance appropriée, les inefficacités peuvent passer inaperçues, entraînant des processus sous-optimaux et une diminution du retour sur investissement dans l'automatisation des tests.    Mises à Jour Régulières et Maintenance   L'automatisation des tests nécessite un affinement continu. Avantages : Les mises à jour régulières maintiennent le processus de test en accord avec les changements logiciels, assurant son efficacité et sa pertinence. Risques : Négliger la maintenance peut rendre l'automatisation des tests inefficace avec le temps, car elle perd sa synchronisation avec l'application qu'elle est censée tester.    Conclusion   Une approche stratégique de l'automatisation des tests, comprenant l'établissement d'objectifs clairs, la sélection d'outils appropriés, un cadre solide et une intégration approfondie dans le processus de développement, est cruciale. Cette approche, complétée par une surveillance diligente et une maintenance régulière, élève non seulement l'efficacité du processus de test, mais améliore également considérablement la qualité globale du logiciel. Négliger ces stratégies peut entraîner une perte de ressources, des coûts accrus et des produits logiciels de qualité inférieure.   

La plupart des changements sont généralement difficiles à gérer, mais réussir les transformations agiles s'est avéré être un défi majeur pour la plupart des organisations et des équipes. L'une des raisons est que les transformations agiles entraînent souvent des changements dans l'organisation, dans les méthodes de travail et dans la culture en même temps ! Cela exige beaucoup de la part de tous les individus, car ils sont affectés tout en effectuant le changement. Cela augmente le risque d'échec, et les changements effectués de la mauvaise manière rendent les gens confus, frustrés et désengagés.    Pour vous faciliter la tâche, voici quelques-uns des écueils les plus fréquents que nous constatons et que nous vous recommandons d'éviter.    Mise en œuvre "du haut vers le bas"   La direction de l'entreprise ou de l'organisation a décidé que l'agile est le nouveau noir et que tout le monde doit devenir agile ! Des décisions sont prises quant à l'introduction d'une certaine méthode dans l'ensemble de l'organisation. Souvent, cela se fait sans impliquer les employés, que ce soit dans la décision ou dans le choix de la méthode, et sans communiquer l'objectif de la transformation et ce sur quoi on se concentre. La culture n'est évoquée qu'en passant, voire pas du tout. Lorsque la méthode est pleinement mise en œuvre, la direction assure le suivi, coche la case agile, se félicite et qualifie le "projet" de réussite.     Ce type de changement aboutit rarement à quelque chose qui est conforme aux principes agiles et a généralement pour conséquence que vous vous éloignez des méthodes de travail agiles après un certain temps, en disant que vous travaillez de manière "agile" ou "inspirée par l'agile". Au lieu de cela, il est préférable d'expliquer pourquoi vous avez besoin d'un changement, quels sont les objectifs. Et d'impliquer les équipes à la fois dans le choix de la méthode et dans son adaptation à leurs besoins. Il n'est pas nécessaire que tout le monde fasse de la même manière, tant que tout le monde tire dans le même sens. Le rôle des managers est de devenir des leaders, d'agir comme des facilitateurs et de créer les bonnes conditions pour que les équipes réussissent à atteindre les objectifs.    Absence de mandat   Une grande partie de la culture agile repose sur l'autonomie des équipes et sur leur mandat pour prendre des décisions concernant le produit. Malheureusement, c'est rarement le cas. Les managers veulent souvent continuer à prendre des décisions sur le produit et la technologie, au lieu de confier la responsabilité aux équipes et de les laisser faire leur travail. Par habitude, vous vous concentrez sur les détails concernant les solutions, les livraisons et le produit final parce que vous avez généralement de l'expérience dans ces domaines. Cela conduit à une microgestion, à de longs processus décisionnels, à une pensée bureaucratique et, dans des cas extrêmes, à des intrigues politiques au sein de l'organisation. Ces problèmes sont dus au fait que les managers continuent d'agir comme des managers au lieu d'adopter le "servant leadership" qui est un élément important de la culture agile.    Cela est principalement dû au fait que très peu de méthodes agiles parlent de la manière dont le leadership devrait fonctionner dans un environnement agile, et que vous continuez avec le même style de leadership que vous avez toujours eu. Il existe peu d'organisations qui, même avant une transformation agile, ont travaillé avec un leadership au service des autres, dans lequel vous, en tant que dirigeant de l'entreprise, êtes un facilitateur pour les équipes, en vous concentrant sur les individus et les équipes qui atteignent leur plein potentiel. Au lieu de cela, les dirigeants continuent à vouloir contrôler au lieu de se contenter de "simplement" suivre la situation.    Manque de gestion du retour d'information   Il est courant que les critiques et les plaintes concernant les méthodes de travail, les décisions, le leadership ou la culture générale soient étouffées, freinées ou ne soient pas prises au sérieux. L'un des quatre points du programme Modern Agile consiste à faire de la sécurité une condition préalable pour tous. La sécurité se présente sous différentes formes, mais la sécurité psychologique est un facteur décisif pour le bien-être, l'engagement et la productivité au travail. Si vous taisez trop souvent les critiques et les mécontentements, cela conduit également à mettre fin à l'implication dans les améliorations. Il est donc important d'agir sur les insatisfactions et de chercher ensemble des solutions. Saisissez les problèmes, rendez-les visibles et sollicitez l'aide des personnes concernées pour trouver des solutions et des moyens d'aller de l'avant.    Mauvais choix de méthodes et de mesures   Il n'y a pas de taille unique - un mantra que je répète constamment dans mon travail. Il n'existe pas de méthodes de travail parfaitement adaptées à toutes les situations de travail, à toutes les organisations ou à toutes les équipes. Malheureusement, beaucoup ne le comprennent pas et, au lieu d'adapter la méthode en fonction des besoins, on impose des méthodes - souvent les mauvaises - et tout le monde doit s'adapter. L'accent est mis sur la mise en œuvre de la méthode, on définit les mauvais objectifs que l'on veut atteindre avec le changement, et on définit les mauvais indicateurs de performance ou KPI. Cela crée des plans qui sont de toute façon replanifiés, du temps perdu à faire des estimations de temps, à se concentrer sur des détails qui ne créent pas de valeur pour le produit ou l'équipe. Au lieu de ce qui crée de la valeur ou améliore la délivrabilité. Introduire Scrum "selon les règles" et mesurer servilement la vélocité, ajuster le processus vers une vélocité plus élevée et ensuite comparer la vélocité entre les équipes est un exemple classique de ce qu'il ne faut PAS faire pour réussir votre transformation agile.    Culture - ou absence de culture   Beaucoup de gens parlent des méthodes agiles qu'ils utilisent, mais très peu des comportements qu'ils promeuvent ou de la culture qu'ils favorisent. Aucune méthode ne permet de devenir agile, mais les bonnes méthodes peuvent créer les conditions de l'agilité. Concentrez-vous sur les objectifs que vous souhaitez atteindre grâce à l'agilité plutôt que sur la méthode à utiliser. Il est tout à fait possible d'être agile sans suivre un seul processus ou une seule méthode. Tout est une question d'état d'esprit. L'absence d'un état d'esprit agile, d'une culture appropriée et d'une ouverture aux idées et au changement ne rendra jamais une organisation agile. Au contraire, la promotion des bons comportements et d'une culture qui favorise l'amélioration continue, en mettant l'accent sur la création de valeur, la collaboration, l'ouverture et la transparence, et la méthode de travail choisie, quelle qu'elle soit, finiront par donner de très bons résultats - à condition d'y consacrer du temps !    En résumé   On ne fait pas de l'agile, on est agile.     Trouvez les bons changements de comportement qui vous rapprochent des objectifs agiles et faites en sorte que ces comportements deviennent des habitudes. Le changement prend du temps. Soyez patient et comprenez qu'il s'agit d'un voyage permanent. En tant que dirigeant d'une organisation, concentrez-vous sur la connaissance de ce qui se passe, et non sur le maintien du contrôle. Pensez à l'amélioration continue et vous réussirez quelle que soit votre méthode de travail. Bonne chance dans votre transformation agile ! 

Agile - un concept souvent mal compris. L'idée fausse la plus répandue est que l'agilité concerne un certain type de méthode de travail que de nombreuses personnes pensent qu'il suffit d'introduire pour prétendre travailler de manière agile. Malheureusement, la vérité est loin d'être aussi simple. L'agilité est davantage une culture et un état d'esprit permettant d'atteindre certains objectifs et n'a pas grand-chose à voir avec une méthode de travail spécifique. C'est aussi la raison pour laquelle il existe tant de méthodes différentes classées comme agiles. Il peut y avoir beaucoup de différences entre ces méthodes, mais elles ont un dénominateur commun : elles favorisent ou créent les conditions nécessaires pour atteindre les objectifs agiles.    Les objectifs agiles   Créer de la valeur rapidement    La valeur consiste à présenter quelque chose qui justifie l'acquisition/l'utilisation d'un produit ou d'un service pour le client ou l'utilisateur. Elle doit apporter quelque chose et présenter un avantage concurrentiel par rapport à d'autres options. La nature de la valeur diffère selon le type de produit ou de service. Il peut s'agir de valeurs mesurables ou non. Il peut également s'agir de choses qui n'apportent rien aux utilisateurs finaux, mais qui aident les équipes qui développent le produit ou leur propre entreprise d'une manière ou d'une autre. Cependant, toutes les valeurs doivent être hiérarchisées les unes par rapport aux autres, car il est difficile de "tout avoir" si l'on veut créer rapidement de la valeur. En effet, la vitesse est importante dans ce contexte. Toutefois, elle ne doit pas se faire au détriment de la qualité, car cela peut avoir des conséquences fatales pour le produit ou la marque.    Maximiser les collaborations    Vous voulez également maximiser la collaboration dans le développement des produits. Veillez à ce qu'il y ait le moins possible de situations de malentendus et de mauvaise communication, et à ce que vous puissiez en subir les conséquences. En réunissant les bonnes personnes et les bonnes parties prenantes pour résoudre les problèmes, nous créons moins de malentendus en cours de route et nous obtenons de meilleures solutions. C'est l'un des facteurs les plus importants qui influent sur la capacité de livraison des équipes et sur les délais de développement des produits.    Maximiser l'adaptabilité   L'adaptation consiste à être capable de modifier rapidement son produit ou ses services pour répondre aux besoins du marché. Par exemple, lors de la pandémie, de nombreuses entreprises ont dû repenser leur stratégie et se contenter de rencontrer leurs clients par voie numérique. Mais il peut aussi s'agir d'adapter les méthodes de travail, les horaires, les ressources ou d'autres éléments qui affectent les opérations internes. Ce qu'il faut retenir, c'est que les décisions ne devraient pas prendre beaucoup de temps à planifier, à repenser ou à faire différemment.     Quelle est votre capacité d'adaptation ?    Minimiser le travail inutile     Aujourd'hui, de nombreux processus sont très lourds, avec beaucoup de choses qui doivent être faites conformément aux processus, mais qui n'ajoutent rien au produit. Par exemple, certains types de contrôles et de rapports. La documentation détaillée dans l'industrie MedTech ou les normes relatives au fonctionnement des systèmes de sécurité dans l'industrie automobile sont des exemples de phénomènes qui ne peuvent être contournés pour des raisons juridiques. Toutefois, il est possible de supprimer de nombreuses autres tâches inutiles. Réfléchissez à votre processus de travail. Est-il possible de minimiser quoi que ce soit ?    Comment atteindre les objectifs ?   Comme indiqué, il n'y a pas de procédure, méthode, ou une liste de contrôle à cocher pour atteindre l'objectif d'agilité. des objectifs, mais essentiellement un une culture et un état d'esprit qui vous permettent de travailler une culture et un état d'esprit qui vous permettent de travailler flexible et efficace. C'est un changement culturel qui doit s'opérer. Cependant, il existe des méthodes, des processus et des outils qui permettent de créer les conditions nécessaires pour travailler de manière agile !    Des processus de décision courts    Lorsque vous avez une longue liste de personnes qui doivent être impliquées dans chaque décision, le processus de prise de décision prend beaucoup de temps, ce qui se traduit par un travail et un développement lents et inefficaces. Des processus décisionnels courts facilitent l'adaptation et l'avancement du travail. Maximiser les collaborations ne signifie pas avoir autant de collaborations que possible, mais plutôt avoir des collaborations efficaces et qui résolvent les problèmes rapidement. Dans le meilleur des mondes agiles, les équipes de développement ont un mandat fort pour prendre des décisions sur le produit. Cela exige beaucoup de la culture et des dirigeants de l'entreprise pour que cela fonctionne.    Une responsabilité transparente    La transparence sur qui fait quoi, quelles décisions sont prises et par qui, facilite le développement. Si une personne ou un groupe est responsable d'un domaine spécifique, il est utile qu'il soit transparent dans ses processus de prise de décision et dans ses décisions à venir. En étant ouvert, le reste de l'équipe sait comment penser et peut s'aligner sur leur travail continu pour atteindre les mêmes objectifs. Il est stupide de faire des courses séparées, de se retrouver un mois plus tard et de se rendre compte que l'on n'est pas sur la même longueur d'onde. Mais la transparence ne concerne pas seulement les décisions, elle concerne aussi la culture relative aux propositions d'amélioration, aux critiques et aux changements. Sans transparence, le travail se fait dans les caniveaux et à différents niveaux hiérarchiques, ce qui, entre autres, nuit à l'efficacité et à la communication.    Shift left     Le décalage à gauche est une façon de penser où le travail d'assurance qualité commence plus tôt dans le processus de développement. Vous essayez de trouver les défauts, les erreurs ou les fautes potentielles le plus tôt possible, et vous travaillez de manière proactive pour prévenir les erreurs au lieu d'être seulement réactif pour les détecter. Cela s'applique non seulement aux tests, mais aussi aux exigences, à la conception, à la qualité du code, aux méthodes de travail et à tous les autres aspects qui affectent la qualité finale du produit.     Plus les défauts sont détectés tôt, moins ils sont coûteux et plus il est facile de les corriger. Cela permet également d'économiser du temps pour l'ensemble du projet, plutôt que de trouver des erreurs à la fin du développement du produit.      L'amélioration continue    Il n'existe pas de méthode ou de processus parfaits, ce qui signifie que la première itération de votre méthode de travail sera loin d'être parfaite. L'un des aspects les plus importants de la méthode agile est d'en prendre conscience et de s'efforcer d'améliorer les choses en permanence. Faites des rapprochements réguliers sur votre façon de travailler, sur le fonctionnement des collaborations, sur l'aide ou l'obstruction des processus, sur l'évolution du produit, sur l'opinion de vos utilisateurs et sur ce qui se passe sur le marché, et agissez sur la base des informations que vous obtenez. De cette manière, vous vous assurez de ne jamais être à la traîne ou même de devenir obsolète. Qu'il s'agisse de l'entreprise ou du produit. Il vaut mieux apprendre rapidement de ses erreurs que de les laisser vous coûter cher pendant longtemps.      Comment atteindre les objectifs ?   Pour résumé    Travailler de manière agile, c'est privilégier la communication entre les individus plutôt que les processus et les outils, et donner la priorité aux bonnes choses pour le produit, le service ou l'entreprise. Les processus et les outils ne sont pas sans importance, mais ceux qui résolvent réellement le problème, c'est-à-dire les personnes, sont plus importants. Il s'agit de collaborer efficacement pour trouver des solutions valables aux bons problèmes. Examinez l'état actuel de vos processus de prise de décision et de votre communication. Pouvez-vous les améliorer ou les rendre plus efficaces ?    Pour que la qualité finale soit optimisée et crée de la valeur, je recommande de revoir l'ensemble de votre processus de développement et de veiller à ce que l'assurance qualité intervienne le plus tôt possible. Essayez de trouver des défauts ou des erreurs potentielles dans tous les domaines du développement.     Si vous ne pouvez vous concentrer que sur une seule chose, faites en sorte que ce soit l'amélioration continue. Si vous y travaillez de manière cohérente et systématique, la plupart des autres choses s'arrangeront d'elles-mêmes avec le temps.  

L'intelligence artificielle (IA) a changé et continuera de changer l'assurance qualité, ce qui signifie que nous, en tant que testeurs, devons être prêts. Les outils de test alimentés par l'IA automatiseront les tâches répétitives, prédiront les problèmes et amélioreront l'efficacité et la précision. Cela laisse plus de temps pour les tâches créatives, mais impose en même temps de nouvelles exigences aux testeurs. Ceux qui ont la capacité de travailler avec des systèmes basés sur l'IA et de bénéficier de tests avec l'IA seront très demandés. L'automatisation des tests à l'avenir ne consiste pas à opposer les testeurs à l'IA, mais plutôt à savoir comment tester à l'aide de l'IA.    Voici comment les testeurs peuvent bénéficier de l'IA dans leur travail.    Générer des scénarios de test   Avec l'IA, il est possible de générer des cas de test de différentes manières et une méthode courante consiste à utiliser l'apprentissage automatique. L'apprentissage automatique est un type d'IA qui permet aux ordinateurs d'apprendre à partir de données sans être explicitement programmés. Dans les tests, l'apprentissage automatique peut être utilisé pour apprendre à connaître le logiciel et son comportement. En analysant le code, l'IA peut identifier des sources potentielles d'erreurs. Ces sources d'erreur peuvent ensuite être utilisées pour générer des cas de test conçus pour détecter les erreurs potentielles avant qu'elles ne se produisent.    Le traitement du langage naturel (NLP) est une autre branche de l'IA qui permet à l'interaction entre l'homme et l'ordinateur d'imiter autant que possible le langage naturel. L'utilisation du NLP signifie que les testeurs n'ont pas à apprendre de nouvelles règles ou syntaxes pour différents langages de programmation. La création et la maintenance de scripts de test peuvent être longues et fastidieuses, mais avec l'automatisation sans script grâce au NLP, les scripts sont écrits en langage naturel et l'un des avantages est la faible courbe d'apprentissage. Contrairement à la plupart des outils d'automatisation qui nécessitent des connaissances en programmation. Un autre avantage est l'amélioration de la compréhension et de la lisibilité qui permet à tous les rôles au sein de l'équipe de réviser les cas de test si nécessaire. L'utilisation d'un anglais simple permet à tous les membres de l'équipe de créer des cas de test, et les propriétaires de produits ou les chefs de projet peuvent intervenir et augmenter la couverture et la qualité des tests.    En analysant la documentation et les besoins des utilisateurs, l'IA peut identifier des scénarios d'utilisation potentiels. Ces scénarios peuvent ensuite être utilisés pour générer des cas de test qui simulent la manière dont les utilisateurs se serviront du logiciel. Au fur et à mesure que l'intelligence artificielle apprend des tests précédents, analyse les résultats et trouve des modèles cruciaux, il sera possible de trouver des cas de test répétitifs ou moins importants et d'améliorer la suite de tests.    Test visuel   Il n'est pas rare que des exigences telles que la fourniture d'une expérience utilisateur cohérente, qu'un utilisateur ait Firefox sur son ordinateur portable ou Chrome sur son smartphone, soient posées. De plus, les utilisateurs ont de plus en plus besoin d'accéder aux applications sur différents appareils tels que les tablettes et les wearables. Pour les testeurs, cela peut signifier un nombre inhumain de cas de tests d'interface utilisateur sur tous les navigateurs et appareils. Il est donc impossible de suivre le rythme et le besoin de vérification visuelle par l'IA peut devenir une solution appropriée.    Les tests visuels d'intelligence artificielle consistent à générer, analyser et comparer des images afin de détecter d'éventuels changements dans les valeurs des pixels, connus sous le nom de "différences visuelles". Un programme de test est nécessaire pour exécuter les tests visuels en combinaison avec un cadre d'automatisation du navigateur pour imiter le comportement de l'utilisateur. Des captures d'écran sont réalisées à des moments précis et utilisées comme résultats attendus lors de comparaisons ultérieures. Pendant l'exécution du test, toute modification éventuelle déclenche une capture d'écran et est comparée à l'image de référence. En cas d'écart, le test est marqué comme ayant échoué et un rapport automatique est généré pour que l'assurance qualité puisse l'examiner.    Auto-réparation et tests adaptatifs   L'automatisation des tests alimentée par l'IA peut être auto-réparatrice, ce qui signifie qu'elle peut s'adapter aux changements dans le logiciel ou l'environnement de test sans nécessiter d'intervention manuelle. Cette caractéristique est précieuse dans les environnements de développement agiles où les changements sont fréquents. Les tests qui échouent sont découverts au cours du processus de test, et nombre d'entre eux échouent en raison d'une mauvaise maintenance. Cela signifie que l'assurance qualité passe du temps à corriger les bogues des tests alors qu'elle pourrait le faire pour le logiciel. La maintenance manuelle des tests peut également retarder le développement et le lancement du produit. L'automatisation des tests à autorégénération réduit (voire élimine) la maintenance manuelle des tests. Cela permet de réduire le nombre de tests échoués et d'avoir une vision plus actualisée de l'état des tests.    Trop souvent, les tests échouent en raison de modifications apportées aux objets ou à leurs propriétés dans l'interface utilisateur. C'est là que le modus operandi d'auto-réparation alimenté par l'IA s'avère utile. Les objets peuvent être détectés même après que leurs propriétés ont été modifiées, ce qui élimine la nécessité de modifier le script.    Au lieu de faire échouer le test, l'IA modifie automatiquement le script pour l'adapter aux nouvelles propriétés de l'objet. La fonction d'autoréparation permet de gratter, d'évaluer, de sélectionner et de modifier le script en fonction des besoins en une fraction de seconde. Cela permet de gagner du temps et d'ajouter une couche supplémentaire d'automatisation pour réduire encore l'intervention manuelle.    Pour résumé   L'IA est en cours de développement et a un grand potentiel pour prendre en charge les tâches "traditionnelles" du testeur telles que la création, l'exécution et la maintenance des cas de test. L'IA a la capacité d'analyser de grandes quantités de données et de fournir des scénarios de test complets qui conduisent à des niveaux de couverture plus élevés et à une meilleure identification des bogues potentiels. La précision et la rapidité augmentent, ce qui permet de réduire le nombre de bogues et d'accélérer les mises en production. La nouvelle ère des tests basés sur l'IA entraîne une augmentation de la production et soulage les testeurs d'une partie de leur charge de travail. À l'avenir, les testeurs ne seront pas "simplement" des testeurs, mais devraient devenir des penseurs stratégiques ayant une compréhension approfondie des aspects techniques et des exigences de l'entreprise.    Il peut sembler que le testeur sera remplacé à l'avenir, mais les compétences humaines ne doivent pas être sous-estimées. L'IA ne vaut que ce que valent les données sur lesquelles elle a été formée et ne peut remplacer l'intuition ou la créativité humaine. Bien sûr, elle est prometteuse lorsqu'il s'agit d'automatiser des tâches répétitives, mais elle ne peut pas remplacer la pensée critique et les compétences en matière de résolution de problèmes que possède le testeur. L'IA ne peut pas apporter l'intelligence émotionnelle nécessaire pour comprendre le produit du point de vue de l'utilisateur et s'identifier à son expérience. Cette limitation signifie que l'IA peut manquer des erreurs qui ont un impact négatif sur l'expérience de l'utilisateur. L'avenir de l'assurance qualité réside dans la recherche d'un juste équilibre entre l'IA et les tests humains, où les outils basés sur l'IA aident le testeur à accomplir ses tâches de manière plus efficace et plus précise. Les testeurs désireux de s'informer sur l'IA et d'investir dans des outils de test alimentés par l'IA seront bien placés pour réussir dans l'avenir de l'automatisation des tests. 

Peut-on réellement tout tester ?    Il est impossible de tout tester, c'est pourquoi vous devez réfléchir aux risques qui existent dans votre projet de développement. Avec ce point de départ, vous pouvez élaborer une stratégie de test en planifiant soigneusement l'ordre des tests en fonction de leur priorité, minimisant ainsi les risques associés. En effet, en déterminant quelle fonctionnalité ou quel aspect du produit est le plus critique pour le succès global du projet, vous pouvez vous assurer que ces éléments sont testés en premier. Cette approche garantit que votre stratégie de test est alignée sur les objectifs du projet de développement. Dans cet article de blog, je vais décrire comment élaborer une stratégie de tests basés sur les risques.    L'importance des tests réside également dans une perspective commerciale, influencée par le secteur dans lequel votre logiciel est développé. Par exemple, dans des domaines comme la banque, l'assurance, la technologie médicale ou le secteur public, la fiabilité est cruciale pour maintenir la réputation et la confiance des clients. Même une petite erreur, comme une faute d'orthographe, peut ébranler la confiance envers l'ensemble de l'entreprise. Cependant, dans certains cas, l'urgence de mettre un produit sur le marché peut primer, et il est possible de tolérer quelques défauts dans la première version. Cela dit, dans tous les projets, il existe un équilibre entre le temps , le coût et la qualité. Si la qualité est prioritaire, cela peut impacter le temps et le coût. Si le temps est le facteur prédominant, cela peut influencer à la baisse le coût et la qualité.      En d'autres termes, les facteurs temps , le coût sont également des paramètres importants pour la planification des tests. Il est possible que vous testiez "trop" de cas par rapport aux priorités du projet. L'effort de test doit être aligné sur les objectifs du projet, tout comme l'ensemble des activités de développement. Lors de la planification des tests, que ce soit la création de cas de test, de scénarios ou la préparation des conditions pour des tests exploratoires, une liste exhaustive des éléments à tester est générée. Cependant, tous les tests ne revêtent pas la même importance. Certaines fonctionnalités du système sont plus critiques et sont utilisées fréquemment, tandis que d'autres le sont moins. Divers facteurs, tels que la complexité des exigences et du développement, influent également sur le niveau de test nécessaire. L'approche risk-based testing repose sur une analyse de risque, qui peut être effectuée à différents niveaux de test, comme les tests système ou les sprints. Le type d'analyse du risque sélectionné importe moins que la prise en compte de la probabilité et de l'impact des différents aspects, tels que leur importance commerciale, leur complexité d'implémentation ou de données. Il est également crucial d'intégrer les considérations de temps, de coût et de qualité évoquées précédemment.      COMMENT EFFECTUER UNE ANALYSE DE TEST BASÉE SUR LE RISQUE   Une analyse de test basée sur le risque peut être réalisée de différentes manières; cette proposition vous montre comment procéder. Il se peut que cette méthode ne corresponde pas à votre situation et à votre projet, mais nous espérons que vous en tirerez quelques bons conseils.    1. Désignez une personne -de préférence le Test Lead - que l'on nommera dans cet article : Risk Manager. Cette personne dirigera l'analyse de test basée sur les risques.   2. Les risques doivent, tout d'abord, être identifiés dans le cadre de la mission, ce qui peut être fait de manière classique à l'aide de post-it. Ou pourquoi ne pas utiliser le Mind Mapping, où l'on note les risques - élevés et faibles. Il est préférable de faire cela en groupe, dans une salle commune par exemple, afin de s'inspirer les uns des autres, de devenir plus créatif et de sortir des sentiers battus.     3. Lorsque la collecte des risques est terminée, ceux-ci doivent être regroupés, ce qui se fait généralement par fonctions ou par domaines. Mais il peut y avoir d'autres façons de regrouper les risques qui conviennent mieux à la mission. Le regroupement est effectué par le Risk Manager.        4. Le Risk Manager convoque une nouvelle réunion d'analyse des risques au cours de laquelle il présente les risques et leur regroupement. Les participants peuvent maintenant commenter et ajouter des nouveaux risques, ces derniers peuvent être décomposés de manière plus détaillée si nécessaire. À l'issue de cette réunion, le mapping des risques doit être prêt et les conditions préalables doivent être réunies pour effectuer une analyse de risque dans laquelle la probabilité et les conséquences sont évaluées.   5. Le Risk Manager organise un nouvel atelier au cours duquel l'analyse de risques proprement dite est effectuée. Exemples de participants: test lead, testeur expérimenté, client, architecte IT, Chef de projet, Product owner / Manager system, développeur expérimenté.   6. Les probabilités et conséquences doivent être évaluées pour chaque risque. Commencez par examiner la probabilité que le risque se produise, 1-4 et entrez-la dans la feuille de calcul.    Probabilité  Lorsqu'il s'agit des probabilités, nous prenons en compte différents facteurs qui affectent la probabilité que le risque se produise.      Continuez à évaluer les conséquences de chaque risque. Masquez la colonne Probabilité afin qu'elle n'affecte pas la pondération des conséquences.      Conséquence  Il est important d'identifier toutes les parties prenantes concernées et de se demander si certaines d'entre elles sont plus importantes que d'autres et, si c'est le cas, comment les pondérer.        7. Multipliez la probabilité par la conséquence et vous obtenez une valeur de risque. Répartissez les risques en fonction de leur valeur de risque :   1-4 = moindre 5-9 = pondérée 10-16 = élevée         8. Décidez de la manière d'éliminer les risques :   Faut-il éliminer tous les risques en même temps, en commençant par ceux dont la valeur de risque est la plus élevée et en procédant à une élimination descendante ? Faut-il commencer par la fonction/le domaine concerné(e) et éliminer ensuite les risques ? Faut-il commencer par les livraisons/prints ? Faut-il rédiger des cas de test/scénarios ou prévoir des conditions pour des tests exploratoires pour les risques ayant une faible valeur de risque ?    9. Commencez à travailler avec les risques qui ont la valeur de risque la plus élevée :   Vérifiez si le risque peut être lié à une exigence ou l'équivalent, notez-le dans la colonne "Exigence liée" Identifiez un ou plusieurs cas de test/scénarios/conditions pour les tests exploratoires ou équivalents qui vérifient que le risque est éliminé. Rédigez les au niveau de l'en-tête pour avoir une vue d'ensemble de l'ampleur du travail de test.     10. Maintenant que les bases sont posées, il est temps d'entrer dans le vif du sujet en rédigeant les cas de test, les scénarios et les conditions pour les tests exploratoires avec un niveau de détail minutieux.   Assignez des responsables à chaque cas de test, scénario ou condition pour les tests exploratoires. Commencez par établir une structure générale pour avoir une vision d'ensemble du nombre de tests requis. Il est mieux d'utiliser un outil de test car poursuivre sur une feuille Excel peut s'avérer fastidieux compte tenu de sa complexité croissante. Rédigez les cas de test, les scénarios et les prérequis pour les tests exploratoires avec attention aux détails. Déterminez si chaque cas de test ou scénario doit être exécuté automatiquement ou manuellement. Assurez vous que tous les cas de test et scénarios sont examinés avant leur exécution. Si possible, établissez l'ordre d'exécution des cas de test et des scénarios. Il est conseillé de tester en priorité les éléments présentant un risque élevé, bien qu'il puisse être nécessaire de valider en premier une fonctionnalité de base avant d'entreprendre d'autres tests.   Pour une couverture exhaustive des exigences, en parallèle des tests détaillés, vérifiez dans quelle mesure les exigences sont testées. À partir des étapes précédentes où les risques, les exigences et les tests ont été cartographiés, vous pouvez désormais repérer les exigences dépourvues de tests définis. Identifiez ces lacunes et documentez les de préférence dans un nouvel onglet de la feuille Excel ou tout autre outil de suivi utilisé.    12. Effectuez les étapes 3 à 10 pour les exigences qui n'ont pas été couvertes par l'analyse des risques. A titre d'exemple, gérez les exigences de la même manière que le risque, c'est-à-dire en produisant une valeur de risque, qui vous aidera à planifier l'ordre dans lequel les tests doivent être produits et réalisés.    13. Vous avez maintenant un système qui sera testé avec une couverture complète des exigences et vous avez éliminé tous les risques élevés en ayant des cas de test/scénarios/tests exploratoires qui garantiront que toutes les fonctionnalités importantes sont testées.    14. Au moment de la prochaine livraison/ du prochain sprint, il est utile d'effectuer un suivi de l'analyse des risques précédents et de se poser les questions suivantes :   La probabilité/conséquence du risque peut-elle être modifiée ? Les tests effectués ont-ils permis d'éliminer le risque, en tout ou en partie ? Y a-t-il eu de nouveaux risques ou de nouvelles exigences qui doivent être traités de la manière décrite ci-dessus ?   15. Lors de la planification de la livraison/du sprint à venir, procédez de la même manière que celle décrite ci-dessus, mais les tests de régression doivent également être identifiés à ce stade. Un conseil est alors de sélectionner les cas de test/scénarios/tests exploratoires pour lesquels des écarts ont été trouvés et corrigés et de sélectionner les cas de test/scénarios/tests exploratoires ayant une valeur de risque élevée.   —   J'espère que cela vous sera utile sur le moment. Tous les tests sont différents et vous devez improviser pour qu'ils conviennent à l'organisation, au niveau de test ou les sprints sur lesquels vous travaillez actuellement. 

Les tests unitaires et d'intégration sont des sujets dont on parle souvent et qui d'une certaine manière sont surtout lié à l'automatisation des tests. Mais que signifient ces tests en pratique et comment sont-ils utilisés ? C'est ce que vous découvrirez dans cet article !   Tests unitaires - tester les plus petites unités   Les tests unitaires testent les plus petites unités d'une application, afin de s'assurer qu'elles fonctionnent comme prévu. Ces tests sont fortement liés à la mise en œuvre réelle, plutôt que de vérifier si un système fonctionne comme prévu d'un point de vue opérationnel. Dans le cadre du développement piloté par les tests (TDD), les tests unitaires sont utilisés pour définir la manière dont une unité doit être formulée et vérifier que des paramètres d'entrée et des conditions de sortie donnés produisent des résultats corrects. Au lieu d'écrire le code de production d'abord et les tests unitaires ensuite, on écrit d'abord des tests unitaires qui, bien sûr, ne fonctionnent pas et ne donnent pas de résultats corrects. Sur la base de cette situation, le code de production est autorisé à se développer en créant ce qui est nécessaire pour que le test unitaire réussisse. Les tests unitaires devraient être considérés comme un complément important au cours du développement, plutôt que comme un type de test suffisant pour vérifier la qualité.   Tests d'intégration - tests permettant de vérifier que toutes les unités fonctionnent ensemble   Les tests d'intégration permettent de vérifier que toutes les unités d'une application fonctionnent ensemble. Dans ces tests, l'application peut être appelée de l'extérieur telle qu'elle est destinée à être utilisée par l'utilisateur ou d'autres systèmes. Cela signifie qu'ils ne sont pas liés à la solution de la même manière que les tests unitaires et qu'ils n'ont donc pas besoin d'être affectés dans la même mesure et que la solution ne doit pas, par exemple, être remaniée. Les tests d'intégration sont parfaits pour les tests de régression et peuvent être construits pour trouver les bugs le plus tôt possible. Mettre en évidence la testabilité de l'application pour ces tests est une condition préalable. Comment s'authentifier auprès d'une application devant faire l'objet d'un test d'intégration, et qu'en est-il de la configuration de l'application si le service doit être testé localement sur un ordinateur professionnel ?   Prenons une simple analogie :   Un dispositif interne dans une application peut être comparé à une pièce sous le capot de votre voiture, comme la courroie de ventilateur. Pour garantir la qualité de la courroie de ventilateur, celle-ci sera testée séparément, et des éléments tels que la résistance, la durée de vie et le frottement du matériau seront vérifiés. Toutefois, ce n'est pas la présence d'une courroie de ventilateur qui importe au conducteur, mais le fait que la voiture soit robuste et qu'elle ait besoin d'un système de refroidissement du moteur qui fonctionne. Si le constructeur automobile mettait au point une méthode entièrement nouvelle pour refroidir le moteur, les essais internes pour tester les courroies de ventilateur seraient inutiles, mais les essais de la voiture resteraient inchangés du point de vue du conducteur. On pourrait utiliser les mêmes tests basés sur le conducteur pour juger que la voiture se conduit aussi bien, voire mieux, avec le nouveau système de refroidissement.   Une technique similaire pour des objectifs différents   Même si l'objectif des tests unitaires et des tests d'intégration est différent, ils peuvent souvent être élaborés à l'aide des mêmes techniques. Par nature, les tests unitaires doivent être écrits dans le même langage de programmation que le code testé pour être plus efficaces. Cela nous aide à trouver les erreurs de compilation dues aux mises à jour, ce qui rend le retour d'information aussi rapide que possible. Ces tests n'ont que peu ou pas de dépendances vis-à-vis de l'infrastructure, et sont donc libérés des défis liés aux environnements de test, aux données de test et aux dépendances vis-à-vis d'autres systèmes. C'est ce qui fait des tests unitaires le type de test le plus fiable.   En utilisant les bons outils, vous pouvez dans de nombreux cas obtenir les mêmes avantages pour les tests d'intégration. Vous aurez besoin de conditions préalables pour appeler l'application de l'extérieur et à travers, où le bon support client et la technologie de mocking doivent être utilisés. Il est également fréquent que vous deviez exécuter l'ensemble de l'application comme prévu afin d'accéder à l'ensemble de la pile technologique.   Pour résumé    Les tests unitaires et les tests d'intégration sont deux conditions préalables importantes pour développer des logiciels de qualité. Ensemble, ils forment les premiers tests automatiques qui sont des conditions préalables absolues pour pouvoir livrer de nouveaux logiciels à une fréquence élevée dans un court laps de temps. En choisissant le bon outil, vous obtiendrez un niveau élevé de confiance dans ces tests. Ils fourniront un soutien pour les nouveaux développements et un sens justifié de la qualité pour les changements.

Il est temps de rencontrer un autre membre de QESTIT.

Acquérir plus de compétences dans le domaine Agile permet d'optimiser la flexibilité et l'efficacité des projets, favorisant ainsi une meilleure adaptation aux changements rapides du marché. De plus, la maîtrise des principes Agile facilite la collaboration ainsi que la communication et la productivité au sein des équipes.   Présentation   La certification ISTQB Testeur Technique Agile est une certification ISTQB avancée au même titre que la certification test manager ou la certification automatisation. À ce titre cette certification est complexe et demande une bonne maitrise des bases du test… et de l’Agile. On aborde dans cette dernière les différents aspects auxquels un testeur travaillant dans une équipe Agile pourra être confronté. Cela va des exigences à l’intégration continu en passant par l’automatisation et les approches de test.Cette certification a pour but principal d’offrir un panel des activités liées à la qualité d’un produit Agile en proposant des bonnes pratiques pour répondre aux différents contextes auxquels on doit faire face.   Pré-requis   Afin de pouvoir passer la certification testeur ISTQB avancée testeur technique Agile il faut, au choix :   La certification ISTQB fondation dans une version 4.0 ou supérieure La certification ISTQB fondation et la certification ISTQB extension Agile Nous conseillons également une expérience des tests dans un contexte Agile d’au moins 2 années.   Contenu La certification ISTQB avancée testeur technique Agile aborde de nombreux sujets autour de la qualité dans un contexte Agile. Le syllabus contient ces parties :   L’ingénierie des exigences   Cette partie est très complète. On y aborde différentes méthodes pour gérer les exigences dans un contexte Agile avec, par exemple la présentation et la manipulation des storyboard, story mapping ou encore les principes INVEST des US. Les tests en Agile   C’est la partie la plus développée !On y aborde les tests unitaires, le TDD, le BDD et l’ATDD. Suite à cela les approches de tests avec l’inclusion des tests basés sur l’expérience (principalement les tests exploratoires) sont présentées avec des exemples permettant d’orienter les efforts de test sur chaque types de test en fonction du contexte. Enfin, cette partie se finit avec des bonnes pratiques liées à la qualité de code (revue, refactoring…) qui peuvent s’avérer également bien utiles pour le test.   L'automatisation   Ce n’est pas l’aspect le plus important de cette certification mais l’Agile ne peut être traitée sans parler d’automatisation des tests. La certification parle des différentes activités à automatiser puis présente les approches de Data Drivent Testing et de tests pilotés par les mots clés (KDT) avant d’aborder le principe de niveau d’automatisation pour aider à déterminer jusqu’à où automatiser.   Le déploiement et la livraison continue   Cette partie est assez courte mais intéressante. Elle aborde les sujets d’intégration, de livraison et de déploiement continu à travers leur intérêt mais aussi les contraintes liées à ces derniers. Différentes stratégies sont alors présentées pour aider à répondre efficacement aux besoins et contraintes. Dans les faits il est très souvent nécessaire d’appliquer plusieurs de ces stratégies en parallèle, comme il est indiqué dans le syllabus, pour pouvoir être efficace dans se démarche de test continu.   La virtualisation   Présentation, intérêts et contraintes liées à la virtualisation des services dans le test.   Intérêt La certification ISTQB avancée testeur technique Agile est très complète. Les principaux intérêts de passer cette certification sont :   On y apprend forcément des choses ! En tant que testeur Agile on est généralement spécialisé sur les parties techniques ou fonctionnelles. La certification permet de découvrir des sujets que l’on n’a pas forcément l’habitude d’aborder. De même, les sujets sont assez poussés ce qui permet, même quand on connait un sujet d’avoir quelques billes supplémentaires.   C’est un marqueur différenciant sur son CV ! Cette certification est peu présente. Sa rareté et son sujet : test Agile avancé font que cela peut faire la différence entre 2 CV et donc permettre plus facilement d’avoir une mission qui nous intéresse.     Formation ISTQB Avancé - Testeur Technique Agile Formez vous avec nous dès maintenant !        

Être agile ou adopter une approche agile n'est pas limité à un domaine ou une industrie particulière. C'est une méthode qui vise à améliorer les résultats finaux, en embrassant le changement et l'amélioration continue pour en tirer le meilleur parti possible. Comme John Steinbeck a dit un jour : "La capacité à penser différemment aujourd'hui par rapport à hier distingue les sages des bornés" ; une leçon qui s'applique à tous, qu'ils évoluent dans le domaine des technologies de l'information ou non.   Accueillir les changements   Imaginez que vous tapissez une pièce. Il est trois heures de l'après-midi par une journée d'été ensoleillée. Il fait chaud. Vous êtes fatigué. Vous êtes à mi-chemin de la pose de la pièce suivante lorsque votre cher partenaire entre dans la pièce et vous dit qu'il pense que vous devriez choisir un papier peint différent de celui que vous avez acheté et qui décore maintenant près de la moitié de la pièce. Comment votre réaction à ce scénario se traduit-elle dans votre imagination ?   Le deuxième principe du Manifeste Agile stipule : "Accueillez favorablement les changements de besoins, même tard dans le projet.". Ne pas accepter ou tolérer. Accueillir. Même les adeptes du développement agile se sentiraient probablement frustrés dans le scénario ci-dessus. Comment pouvez-vous alors vous qualifier d'agile si vous ne faites qu'accepter - et non "accueillir" - ces changements ?   Dans le scénario décrit ci-dessus, il est concevable que votre partenaire ait vu quelque chose que vous n'avez pas vu. Son désir de changer les choses n'est pas dû à la méchanceté ou à l'arrogance, mais à la volonté d'obtenir le meilleur résultat possible. Malgré cela, nous avons du mal à ne pas considérer le travail comme un gâchis. Quelle est la signification concrète d'accueillir les changements à un stade avancé du processus ?   L'importance de voir les améliorations   Pour saisir la nécessité de modifier ou même d'abandonner le travail effectué, il est nécessaire d'avoir une vision améliorée du résultat final. Sans une vision claire de l'avenir améliorée, il est difficile de justifier pourquoi recommencer ou apporter des changements maintenant, ce qui peut entraîner de la frustration.   De nombreuses entreprises éprouvent des difficultés à communiquer clairement et à inspirer la vision qu'elles ont. Pour elles, il est évident que le nouveau changement est meilleur ! Tout le monde devrait s'en rendre compte, n'est-ce pas ? Mais il s'agit maintenant de développer des systèmes, et non de poser du papier peint. Dans le développement de systèmes, il ne s'agit pas d'un travail qui a duré des heures ou des jours. Il s'agit plutôt d'un travail qui a duré des semaines, des mois, voire des années. Et ce n'est pas seulement notre propre travail, mais aussi celui de nos collègues qui peut être mis à l'écart. Les enjeux sont plus importants.   Le succès est déterminé par l'utilisateur   Lorsque les appareils photo numériques ont pris de l'ampleur au début des années 2000, deux entreprises se sont adaptées au nouveau marché, et deux ne l'ont pas fait. Nikon et Canon sont devenus des acteurs majeurs de la photographie numérique. Kodak et Polaroid ont fait faillite. Quelle leçon pouvons-nous en tirer ?   De toute évidence, il ne suffit pas d'innover pour réussir en tant qu'entreprise. Kodak a inventé l'appareil photo numérique mais n'a pas pu, ou n'a pas voulu, modifier son modèle d'entreprise pour tirer profit de cette nouvelle invention. L'innovation ne suffit pas. Ce que nous pensons être bon ne l'est pas toujours et ce que nous ne pensons pas être bon peut devenir notre avenir. Peu importe ce que nous pensons, ce sont les clients et le marché qui, en fin de compte, décident de ce qui réussit et de ce qui échoue. Et que veut le client ? Parfois, il n'en a aucune idée jusqu'à ce qu'il en fasse l'expérience.   Nous ne sommes jamais plus rapides que l'ensemble   Vous pourriez ressentir maintenant une inspiration pour revoir votre approche du travail, afin de faire du changement une force plutôt qu'une résistance. Il est important de garder à l'esprit que notre travail professionnel s'inscrit souvent dans une chaîne plus vaste qui ne relève pas toujours de notre contrôle personnel. Nous ne sommes jamais plus rapides que l'ensemble. Si vous travaillez sur le développement d'un système, par exemple, il peut y avoir des phases telles que l'analyse des besoins, la conception ou la budgétisation qui se déroulent avant que vous n'interveniez. Lorsque nous cherchons à maximiser notre flexibilité, il est essentiel de prendre en compte l'ensemble de la chaîne, depuis la conception jusqu'à l'utilisation. Bien sûr, il est bénéfique d'apporter régulièrement de petits changements, et nous ne devrions jamais cesser de chercher comment nous, en tant qu'individus, pouvons devenir plus flexibles dans notre travail. Cependant, lorsqu'une décision est prise des mois voire des années avant que nous ne commencions à travailler, et peut-être même prise par quelqu'un qui n'est plus impliqué, nous sommes confrontés au défi de modifier ces décisions.   Est-il alors possible de mesurer notre flexibilité ? Oui, en se posant la question suivante : "Si la décision que je m'apprête à prendre est erronée, combien de temps avant que l'erreur ne se manifeste ? " Si vous travaillez dans le domaine du développement de produits, la réponse est probablement que ce n'est que lorsque vos clients utilisent votre produit pour de vrai. C'est là que des méthodes telles que le prototypage et les tests A/B pour créer des expériences entrent en jeu.   En fin de compte, il s'agit surtout de la culture que nous avons. Vous êtes peut-être en train de lire ces lignes en pensant que cela ne fonctionnerait jamais pour vous. Ce n'est pas votre façon de travailler. Mais si vous pensez que ce serait une bonne chose, alors vous êtes peut-être la bonne personne pour changer les choses dans votre organisation.   Pour résumé   Lorsqu'un changement se produit, c'est toujours parce que quelqu'un fait quelque chose de différent. Examinez donc la longueur de la chaîne de décision et voyez s'il est possible de la raccourcir. Observez les résultats attendus et vérifiez s'ils sont effectivement atteints. Essayez des choses et échouez. Souvent. Et apprenez quelque chose de nouveau de l'échec. Préparez vous à être surpris par les résultats. Mettez à l'écart vos préférences - ne vous attachez pas trop à vos propres idées. Accueillez les changements, les opportunités et les leçons qu'ils impliquent.   C'est ma façon de voir l'agilité. Mais qui sait ? Au moment où vous lirez ces lignes, j'aurai peut-être changé d'avis.

Le BDD (Behaviour Driven Development) est une approche popularisée par Dan North en 2003, et issue du TDD (Test Driven Development), dont elle est complémentaire.   Pourquoi faire du BDD ? Précisément pour répondre aux problèmes courants avec les spécifications en mode Agile :   Pas d’explications formalisées sur le contexte  Spécifications interprétables différemment selon les profils ou acteurs Pas forcément à jour   BDD est aussi une pratique Agile, visant à synchroniser les différents acteurs développant une fonctionnalité, en définissant clairement ce que cette pratique doit accomplir. L’objectif du BDD est bien de concevoir des tests d’acceptation, illustrant le comportement de la fonctionnalité, grâce à des méthodes comme les 3 amigos ou l’example mapping. La démarche du BDD est généralement effectuée en 3 étapes : la découverte, la formulation, et l’automatisation.   Les bonnes pratiques   La synchronisation des acteurs se fait à l’aide d’exemples co-conçus illustrant le comportement de la fonctionnalité : c'est la découverte de l’User Story, souvent réalisée grâce à la réunion des 3 amigos (profils client, développeur et testeur), qui permet d’avoir une compréhension commune du besoin, et d’écrire des scénarios d’acceptation pour valider les critères d’acceptation.   La formulation de ces exemples est réalisée grâce à un langage commun, Gherkin, facilement compréhensible des différents profils des 3 amigos. Ce langage Gherkin est un langage formaté pour écrire des tests structurés dans un langage dit naturel, et a priori compréhensible par tous. Les tests en Gherkin sont écrits avec les 4 éléments de base : GIVEN / WHEN / THEN … AND (ETANT DONNE un certain contexte, QUAND je fais une action, ALORS j’ai un résultat1 ET un résultat2).   A partir de cette formulation structurée (et formatée) du comportement de la fonctionnalité, il est possible d’intégrer ces exemples dans un outil logiciel, comme Cucumber par exemple, qui va interpréter ce langage Gherkin pour exécuter des tests d’acceptation automatisés, adaptés à ces exemples. C’est l’étape d’automatisation.   Les dérives   BDD est désormais utilisé dans de nombreuses entreprises, pour tester, au plus près des utilisateurs, le comportement de certaines fonctionnalités. Mais si la compréhension commune du besoin est obtenue grâce à l’application de BDD, il n’en demeure pas moins des confusions sur cette pratique Agile, qui peuvent conduire à certaines dérives. Quelles sont-elles ?   Le BDD est considéré uniquement comme de l’automatisation   On perd alors l’apport primordial du BDD : la capacité à avoir tous la même compréhension de l’attendu    L’écriture et la conception des scénarios est réalisée uniquement par le PO ou le testeur   Dans ce cas les exemples existent. Malheureusement leur qualité est souvent insuffisante car elle n’a pas fait l’objet du regard de différents profils.   L’absence d’écriture de scénarios d’acceptation   Il arrive que des réunions de synchronisation soient effectuées mais qu’au final aucun scénario ne ressort. C’est problématique dans le sens où une grande partie des informations se voit perdue car oubliée. De même cela force à avoir plus de personnes à ces réunions ce qui demande alors un plus fort investissement.   Des tests non compréhensibles par tous les profils   Un test BDD doit être compris de toute les personnes de l’équipe (et des fois au-delà). Ecrire des tests qui ne sont pas compris de tous ne permet pas de s’assurer que tout le monde a compris la même chose. En général cela ne permet pas non plus au métier de vraiment valider ce qui sera développé.   Le BDD est réalisé en cours de sprint   En cours de sprint ne veut pas dire en cours de développement. Mais, même dans le cas où le BDD est fait avant le développement ce déroulement impact l’équipe qui a du s’engager à délivrer une US qu’elle n’avait pas forcément bien compris.   L’utilisation du Gherkin considéré comme faire du BDD   Le Gherkin est un langage. Le BDD peut prendre d’autres formes… tout comme il est possible de faire des tests en gherkin qui ne sont pas du BDD (ex : l’outil Karaté propose des tests en gherkin non compréhensibles par des profils fonctionnels).   Toutes ces dérives peuvent exister, et il convient de rappeler en synthèse la démarche de cette pratique agile BDD : avant le sprint, la pratique BDD consiste, par la découverte, à valider une compréhension commune du besoin par tous les acteurs, cette compréhension étant formulée à travers des exemples, des critères d’acceptation et des scénarios d’acceptation, qui seront ensuite implémentés dans un outil de conception et d’exécution des tests automatisés. L’application des différentes étapes de cette démarche permettra de lutter contre les dérives de BDD et surtout sur les confusions actuellement rencontrées sur les différents termes autour du concept de BDD.

Je dois tester un logiciel, quel outil dois-je choisir ?   Une gestion efficace des tests de logiciels nécessite l'utilisation d'outils spécialisés pour garantir des résultats de haute qualité. Ces outils facilitent diverses activités telles que l'organisation des exigences logicielles, la tenue d'un répertoire de tests, l'exécution de campagnes de tests, la gestion des bogues, l'établissement de liens entre des éléments connexes et la production de rapports. Cependant, avec les nombreuses options disponibles, le choix du bon outil peut s'avérer difficile.   Si certains outils comme HP ALM, aujourd'hui propriété de Microfocus, ont traditionnellement dominé le marché, l'outil le plus populaire aujourd'hui est le plugin JIRA : XRay. Néanmoins, l'outil le plus populaire n'est pas forcément le plus adapté à vos besoins spécifiques, et le choix d'un outil nécessite une prise en compte attentive de votre contexte unique.   Chez QESTIT, nous comprenons les défis liés à la sélection du meilleur outil et nous avons mené une étude de marché complète pour aider les testeurs et les entreprises à prendre des décisions éclairées. Dans cet article, nous partagerons les résultats de notre étude pour vous aider à choisir le meilleur outil de gestion des tests pour vos besoins.     Les ALMs évalués lors de notre étude sont : Spira, XStudio, SquashTM, XRay, Service Now. Nous avons analysé et manipulé l’ensemble de ces outils afin de pouvoir noter chacun des différents critères et sous-critères présentés.     Vous souhaitez consulter notre étude de marché ?   Téléchargez le document ici

J'ai écrit un article en septembre 2020 sur les outils d'automatisation sans script. J'y parlais d'outils ayant deux objectifs distincts :Être accessible à tousCela signifie que ces outils sont conçus pour être utilisés et maîtrisés par toute personne travaillant dans l'informatique, même par des personnes ayant peu ou pas de connaissances techniques. On peut penser à des profils métiers ou à des testeurs qui ne connaissent pas le code mais qui sont très compétents dans leur capacité à concevoir des tests. Les outils basés sur cet objectif ont généralement fait un gros travail sur l'ergonomie, l'affichage des tests mais aussi la sélection des identifiants avec des outils de capture qui sont souvent visuels et cachent la partie technique.Être en mesure d'automatiser toutes les technologies avec le même outilC'est-à-dire disposer d'un seul outil (et donc de la maitriser un seul outil) pour automatiser un grand nombre de logiciels ou de parties de logiciels tels que les API, les interfaces graphiques web, les applications de bureau ou mobiles, etc. Les outils basés sur cet objectif ont bénéficié de beaucoup de travail sur l'architecture de leur logiciel, qui offre une surcouche à la technique, surcouche qui peut ensuite être adaptée aux différentes technologies.   Marc Hage Chahine         ---- Vous souhaitez en savoir plus ? Jetez un oeil à l'article complet publié dans le magazine QUALITY MATTERS (voir le lien ci-dessous)   Une fois sur le site web, vous pourrez créer un compte gratuit pour accéder à l'édition actuelle et aux anciennes éditions de QUALITY MATTERS.

10 mesures essentielles pour renforcer vos défenses informatiques   Dans un monde où les horizons numériques ne cessent de s'élargir, la sécurité n'est pas seulement une caractéristique agréable à avoir, c'est une nécessité absolue. Les cyberattaques étant omniprésentes, la protection de votre infrastructure informatique nécessite des protocoles de sécurité stricts. Alors, attachez vos ceintures, nous vous emmenons en balade et explorons 10 procédures et tâches de sécurité informatique vitales que vous devriez adopter. Parmi les différents cadres de sécurité disponibles, nous nous concentrerons sur les fonctions essentielles du cadre du National Institute of Standards and Technology (NIST) : Identifier, Protéger, Détecter, Répondre et Récupérer. Plongeons dans le vif du sujet et découvrons 10 mesures essentielles pour renforcer vos défenses informatiques.   1. Identifier : Gestion des actifs   Avant de sécuriser votre infrastructure, vous devez comprendre ce que vous protégez. Dressez un inventaire précis de tous les actifs matériels et logiciels. Cela vous aidera à identifier les vulnérabilités et les menaces potentielles associées à chaque composant. Imaginez que vous disposiez d'un système complet qui vous permette d'identifier et de suivre sans effort tous vos actifs numériques. Grâce à la gestion des actifs, vous pouvez garder un œil sur chaque technologie, logiciel ou donnée qui contribue au succès de votre entreprise. C'est comme si vous disposiez d'un superpouvoir qui vous permet d'exercer un contrôle et une visibilité inégalés sur votre royaume numérique. L'époque de l'incertitude et de la confusion est révolue lorsqu'il s'agit de gérer vos actifs. Grâce à des processus de sécurité informatique innovants tels que la gestion des actifs, vous pouvez désormais naviguer facilement et en toute confiance dans le vaste paysage des ressources numériques. Préparez-vous à embarquer pour un voyage impressionnant en découvrant comment ce processus peut révolutionner votre approche de la sécurité informatique.   2. Identifier : L'évaluation des risques   Dans ce monde de vulnérabilités, de nouvelles apparaissent constamment. C'est un peu comme jouer à la mouche du coche : de nouveaux défis surgissent chaque jour, ce qui donne l'impression d'un jeu sans fin ! Pour résoudre ce problème permanent, vous pouvez utiliser des outils tels que Tenable et Rapid7. Ces outils sont vos fidèles acolytes en matière de gestion des vulnérabilités. Ils analysent et classent en permanence les faiblesses de votre réseau. Ils mettent en évidence les vulnérabilités les plus urgentes, ce qui vous permet d'y remédier avant qu'elles ne deviennent un casse-tête plus important que le retrait de votre café du matin. Que ces vulnérabilités soient exposées à l'Internet sauvage ou qu'elles se cachent dans votre intranet confortable, il est essentiel d'en être conscient pour pouvoir les corriger. Profitez des avantages de l'analyse, de la création de rapports et de l'application de correctifs comme des pros pour garder une longueur d'avance sur ces défis.   3. Protéger : Gestion des correctifs   La gestion des logiciels obsolètes ressemble à une bataille sans fin, où l'on tente de rattraper les attaquants persistants. Mais n'ayez crainte, vous disposez d'une arme puissante dans votre arsenal : La gestion des correctifs ! En en faisant une routine et en automatisant le processus, tout comme votre café du matin, vous pouvez vous assurer que tous vos logiciels et systèmes reçoivent les derniers correctifs. En restant à l'affût de ces mises à jour, vous fermerez non seulement les portes aux attaquants opportunistes, mais vous améliorerez également les performances de votre système. Retroussez vos manches, restez vigilant avec les correctifs et éloignez les exploiteurs sournois !   4. Protéger : Durcissement du système   Rationalisez vos systèmes en supprimant les logiciels, les noms d'utilisateur et les identifiants inutiles. Cela revient à désencombrer votre espace numérique et à vous débarrasser de vieilles reliques poussiéreuses. Désactivez également tous les services non essentiels. Pensez-y comme si vous éteigniez le signe "ouvert pour le travail" sur les choses dont vous n'avez pas réellement besoin. Pour une sécurité accrue, suivez un guide de renforcement du système adapté spécifiquement à votre système d'exploitation et à vos applications. Cette approche revient à équiper votre système d'un costume sur mesure, réduisant ainsi sa surface d'attaque potentielle. Faisons le ménage, renforçons les mesures de sécurité et assurons-nous que seul l'essentiel est sous contrôle !   5. Protéger : Mettre en œuvre des politiques robustes en matière de mots de passe   Fortifiez vos défenses en utilisant des mots de passe forts et complexes pour protéger vos informations sensibles. C'est comme si vous construisiez une forteresse inviolable pour votre royaume numérique. Mais se souvenir de ces mots de passe peut être un véritable défi, n'est-ce pas ? C'est là qu'un gestionnaire de mots de passe fiable comme Bitwarden vient à la rescousse ! Considérez-le comme votre gardien de mots de passe personnel, qui stocke et gère en toute sécurité tous vos mots de passe en un seul endroit. De plus, il peut générer des mots de passe uniques, complexes et difficiles à déchiffrer pour chacun de vos comptes en ligne, laissant les cyber-vilains se gratter la tête de frustration.   6. Protéger : Authentification multifactorielle (2FA)   Renforcez votre sécurité en mettant en place l'authentification à deux facteurs (2FA). Cela revient à ajouter un verrou supplémentaire à votre forteresse numérique. Ce processus astucieux exige des utilisateurs qu'ils prouvent leur identité en utilisant non pas une, mais deux méthodes différentes avant d'obtenir un accès, comme une poignée de main secrète suivie d'un balayage rétinien - créant ainsi un double problème pour les intrus non autorisés ! Grâce à cette couche supplémentaire de vérification, le 2FA complique considérablement la tâche des malfaiteurs qui veulent se faufiler dans le système.   7. Détecter : Logiciel antivirus   Protégez votre univers numérique en utilisant un logiciel antivirus robuste. Il agit comme une équipe de cyber-gardes, analysant et éliminant en permanence les menaces qui se cachent pour que votre système reste sûr et propre. Mais ce n'est pas tout ! Pour garder une longueur d'avance sur les menaces en constante évolution, veillez à mettre régulièrement à jour les définitions de votre antivirus, afin de fournir à vos cyber-gardes du corps les informations et les outils les plus récents pour s'attaquer à de nouveaux ennemis. Planifiez également des analyses de routine pour garder un œil vigilant sur la sécurité de votre système, à l'instar des visites médicales régulières qui permettent de détecter les intrus potentiels avant qu'ils ne causent des dommages.   8. Détecter : Surveillance continue   Gardez une longueur d'avance sur les menaces numériques grâce à une surveillance continue. C'est comme si un chien de garde vigilant surveillait votre système en permanence. En utilisant des outils de surveillance du réseau, vous pouvez facilement suivre le flux de données, les journaux système et les comportements des utilisateurs en temps réel. C'est comme si vous aviez un détective sur l'affaire, qui détecte toute anomalie ou activité suspecte avant qu'elle ne puisse causer des dommages. Exploitez la puissance de ces outils de surveillance, en gardant un œil attentif sur chaque aspect numérique et en gérant rapidement toute surprise indésirable qui pourrait survenir.   9. Répondre : Plan d'intervention en cas d'incident   Préparez-vous à l'inattendu avec un plan d'intervention en cas d'incident, votre guide fiable en cas de faille de sécurité. C'est comme avoir une stratégie de combat prête à être déployée lorsque l'ennemi frappe. Votre plan doit comporter des mesures concrètes, à commencer par l'isolement des systèmes touchés afin de contenir la brèche. Ensuite, il faut mener une enquête approfondie pour comprendre le qui, le quoi et le comment de l'incident. Enfin, assurez une communication claire en informant rapidement les personnes concernées, car la transparence est cruciale. Toutefois, n'oubliez pas que l'efficacité d'un plan réside dans son exécution. Il convient donc de le tester et de le mettre à jour régulièrement pour l'adapter aux nouvelles menaces, tout comme on peaufine une stratégie de combat. Avec un plan d'intervention en cas d'incident bien conçu, vous pouvez faire face aux failles de sécurité en toute confiance, minimiser les dommages et rétablir l'ordre comme le héros numérique que vous êtes !   10. Récupérer : Sauvegardes régulières   Protégez vos données critiques des failles de sécurité en effectuant des sauvegardes régulières. Cela revient à créer des copies numériques de vos fichiers précieux et à les stocker en toute sécurité dans un coffre-fort hors site. Vous disposerez ainsi d'une bouée de sauvetage pour récupérer et restaurer vos informations si le pire se produit. De cette manière, vous vous assurez que même si le pire se produit, vous disposez d'une bouée de sauvetage pour récupérer et restaurer vos informations précieuses. En outre, testez régulièrement ces sauvegardes pour vous assurer de leur fiabilité, tout comme vous faites un exercice d'incendie pour tester votre plan d'évacuation. En vérifiant leur fonctionnalité, vous pouvez être tranquille, sachant qu'elles sont prêtes à venir à la rescousse en cas de besoin. Adoptez une approche proactive, sauvegardez vos données, gardez-les saines et sauves et soyez prêts à sortir indemnes des griffes d'une faille de sécurité !   Derniers mots   En conclusion, la sécurisation de l'environnement informatique nécessite un engagement constant et l'utilisation d'outils et de procédures appropriés. Il est essentiel de procéder régulièrement à des tests de pénétration, à des évaluations des risques et à des examens des processus afin d'identifier toute nouvelle vulnérabilité susceptible d'apparaître. Gardez à l'esprit que la cybersécurité n'est pas une entreprise ponctuelle, mais un engagement permanent à protéger vos actifs numériques contre des menaces en constante évolution. En suivant un cadre de sécurité, en comprenant vos risques et en mettant en œuvre des processus tels que ceux mentionnés ci-dessus, vous serez bien préparé pour protéger efficacement votre infrastructure informatique. Restez vigilant, restez proactif et assurez la sécurité de votre domaine numérique !

La vie est imprévisible et parfois notre parcours professionnel l'est aussi. Nous le constatons avec nos propres employés chez QESTIT - certains ont commencé leur carrière dans un domaine complètement différent et sont devenus d'excellents experts en tests de logiciels. Nous croyons fermement qu'il n'est jamais trop tard pour commencer quelque chose de nouveau, et nous avons de nombreux exemples de ce genre !     Voici Karolina !   L'un de ces exemples est notre collègue Karolina Wasalska - une mère célibataire de deux enfants, originaire de Pologne, qui a fait ses armes dans de nombreux domaines : soins infirmiers, gastronomie et couture. Cette jeune femme de bientôt 40 ans est également maquilleuse diplômée. Cependant, elle a toujours été intéressée par les sujets techniques ainsi que par la numérisation, et en 2021, Karolina a rejoint le programme organisé par zam (Fondation autrichienne dédiée aux femmes pour le tremplin vers l'emploi) en Styrie. Fondée en 2006 et financée par l'AMS et le Land Steiermark, zam aide les entreprises à trouver des employés tout en mettant l'accent sur l'égalité des chances pour les femmes.   Après les cours initiaux, Karolina a vu que le programme de développement de logiciels avec certification académique commencerait bientôt. "J'ai tout de suite su que je voulais y participer. J'ai posé ma candidature et, après deux évaluations, j'ai obtenu un stage", a déclaré Karolina.   Dans le cadre de ses études, où elle se concentre sur de nombreux domaines, elle doit effectuer un stage dans l'une des entreprises participant au programme, ce qui a conduit Karolina à QESTIT. Tatjana Soos, responsable des ressources humaines et des opérations commerciales de QESTIT Autriche, qui est à l'origine de cette coopération, a trouvé le concept extrêmement intéressant : "Nous avons un bon nombre de femmes parmi nos consultants chez QESTIT AT, en particulier à Graz, mais mon objectif est de continuer à l'augmenter."     Les semaines d'essai   Après la présentation initiale de l'entreprise, QESTIT a reçu sept candidatures et a décidé d'organiser un essai de deux semaines pour tous les candidats au bureau de Graz, afin de mieux connaître les candidats potentiels et de voir comment leurs intérêts et leurs compétences peuvent s'adapter à notre monde de test de logiciels et d'assurance qualité. Karolina se souvient : "Nous avions des tâches intéressantes à accomplir chaque jour et il y avait toujours quelqu'un de l'équipe qui s'occupait de nous". À la fin des semaines d'essai, la décision finale devait être prise. Comment Karolina a-t-elle été choisie ? "Elle nous a choisis", affirme Tatyana, "Son incroyable énergie positive nous a émerveillés et nous lui avons trouvé une possibilité de travailler sur un projet afin d'acquérir de l'expérience en matière de tests de logiciels. Elle a même séduit notre client !"   Perspective de Karolina dans l'entreprise   Actuellement, Karolina partage son temps entre son travail et ses cours à l'université et, si nécessaire, peut prendre des heures de formation sur son lieu de travail. La solidarité, l'honnêteté, le respect et une bonne communication sont les éléments les plus importants pour elleet tout cela peut être trouvé ici", a-t-elle déclaré.    "Si tout se passe comme prévu, nous aimerions employer Karolina à plein temps après qu'elle aura terminé sa formation au zam", a expliqué Tatjana. Elle a ajouté : "Nous avons eu une expérience tellement positive avec zam que nous prévoyons de travailler à nouveau avec eux cette année. Nous sommes impatients de rencontrer de nouveaux candidats et espérons avoir l'occasion d'accueillir quelqu'un en stage chez nous !   Quels sont donc les principaux éléments à garder à l'esprit lorsque l'on postule à ce programme de formation ? Il est possible de travailler dans la plupart des domaines des technologies de l'information, même sans formation universitaire. Cependant, il y a une chose qui ressort le plus : La motivation ! "Les réactions des entreprises sont claires : la motivation est le facteur le plus important ! a déclaré zam.   Karolina partage le même avis en ce qui concerne la coopération et a quelques conseils à donner aux nouveaux candidats : "Le chemin sera semé d'embûches, mais avec un travail constant, c'est possible. Si vous réussissez le premier semestre, vous réussirez tout ! Alors, faites-le et prenez soin de vous - n'oubliez pas de vous détendre. 😊.”   En conclusion, Karolina confie: "Je suis extrêmement heureuse de pouvoir travailler dans cette entreprise et je pense que j'ai beaucoup de chance à cet égard". Chère Karolina, nous sommes ici les plus chanceux 😊   L'histoire de Karolina vous motive ? En savoir plus sur le programme zam ou consultez notre site web actuel postes à pourvoir !

Il est de plus en plus courant d'utiliser des solutions SaaS (software as a service), principalement parce qu'elles sont rentables, faciles à utiliser, l'exploitation et la maintenance étant assurées par le fournisseur, et qu'elles offrent une grande sécurité, car les choses peuvent mal tourner si l'on n'est pas prudent et si l'on ne s'assure pas de la sécurité avant l'achat. Trop de gens achètent une solution SaaS avec la même attitude que lorsqu'ils achètent une voiture, ils s'attendent à ce que la personne qui a construit la voiture se soit assurée qu'elle est sûre et solide.   3 éléments importants à prendre en compte avant d'acheter une solution SaaS   1. Répartition des responsabilités Commencez par déterminer qui est responsable et pour quoi afin d'avoir une bonne vue d'ensemble de la solution. L'informatique sur le cloud comporte de nombreux modèles différents : l'informatique en nuage privée, dans laquelle vous mettez en place votre propre environnement, exécutez et gérez vos propres machines. L'infrastructure en tant que service, où le client est responsable de certaines parties et le fournisseur de certaines parties. Ensuite, il y a la plateforme en tant que service, où le fournisseur s'occupe de la plupart des aspects, et le logiciel en tant que service, dont nous parlons dans cet article.   Il est de votre responsabilité de vous assurer que vous achetez un produit capable de gérer la classification de sécurité des données que la solution traitera. Comme pour l'achat d'une voiture, Volvo est responsable de s'assurer que vous pouvez conduire la voiture en toute sécurité et qu'elle n'a pas d'accident, mais si vous avez un accident et que vous vous blessez, c'est votre problème.   2. Exigences Lors de l'évaluation des fournisseurs et de l'achat, il est important que les exigences en matière de sécurité soient claires afin que vous puissiez vous assurer que vos données sont totalement sécurisées avec le fournisseur que vous choisissez.   Le contenu d'un cahier des charges est propre à chacun, mais il faut toujours partir du type de données que vous avez dans la solution lorsque vous définissez votre cahier des charges. Par exemple, si vous avez des informations de carte de crédit, la solution doit être capable de gérer PCI DSS, et si vous avez des données personnelles, la solution doit suivre la loi RGPD.   Même si les exigences sont différentes, la grande majorité d'entre elles garantissent généralement la réalisation de tests de pénétration. C'est généralement le fournisseur qui s'en charge. Un conseil : veillez à ce que le fournisseur fasse appel à un testeur indépendant. Pour plus de sécurité, vous devriez également être tenu d'utiliser vos propres testeurs indépendants lorsque vous achetez une solution, ce qui est presque toujours le cas. À la fin de cet article, vous trouverez une liste des éléments généraux les plus importants à inclure dans une déclaration de sécurité.   Les fournisseurs sont généralement très favorables à l'idée de faire appel à une partie externe et de payer les tests de sécurité, mais je pense que vous devriez vous assurer que le fournisseur couvre ce coût. Après tout, c'est vous qui êtes le client et qui allez payer pour le produit. C'est comme si vous achetiez une voiture et que vous l'ameniez ensuite chez un garagiste pour vérifier si elle est sûre, vous ne le faites pas.   En fonction de la solution SaaS, vous pouvez effectuer des configurations et des intégrations personnalisées. Dans ce cas, vous effectuez les tests à vos propres frais.   La plupart du temps, il est bon de s'assurer de ses besoins auprès du fournisseur lors de l'évaluation/avant l'achat, mais malheureusement, beaucoup s'en rendent compte trop tard. Vous vous retrouvez alors dans une situation où les exigences en matière de données ne sont pas personnalisées, ce qui rend l'ensemble plus complexe. La première chose à faire est d'examiner la solution, d'évaluer à quel point elle est critique pour vos informations et de voir s'il y a quelque chose que vous devez/pouvez changer. La deuxième étape consiste à déterminer si le fournisseur est disposé à effectuer ces changements, ce qui est généralement le cas. À partir de là, vous développez un ensemble d'exigences que vous examinez ensemble, en regardant ce qui existe aujourd'hui et ce qui doit être corrigé   Les fournisseurs de SaaS sont presque toujours favorables au changement, mais vous devez comprendre que cela ne se fera pas du jour au lendemain, mais que cela prendra du temps. Si vous recevez un refus, il vous suffit de décider s'il est possible de vivre avec le risque ou de commencer à chercher une nouvelle plateforme.   3. Les processus du fournisseur en matière de sécurité et de tests Avant de procéder à un achat, il est également important de savoir à quoi ressemble le processus de test du fournisseur et comment il travaille avec la sécurité. Vous ne voulez pas d'un propriétaire de produit qui donne la priorité à d'autres choses qu'à la sécurité et à ses mesures.   Vérifiez s'ils effectuent des tests de sécurité et, le cas échéant, quels sont ces tests. Renseignez-vous sur la manière dont les tests sont effectués, sur les personnes qui les réalisent, sur leur fréquence et sur le processus de résolution des failles en cas d'apparition de celles-ci. N'hésitez pas à demander des preuves afin d'examiner à quoi ressemblent les rapports et comment l'entreprise a résolu les vulnérabilités antérieures (le cas éché Il doit y avoir une continuité dans leur travail de sécurité, les tests ne doivent pas être effectués uniquement lorsque quelqu'un le demande ou tous les trois ans.   Pour résumé Alors que de plus en plus d'entreprises s'orientent vers différentes solutions SaaS, le nombre de fournisseurs a complètement explosé. Que vous choisissiez d'exploiter votre propre système ou d'utiliser des solutions SaaS, il est extrêmement important de veiller à ce que l'application, l'infrastructure et les données soient protégées de manière adéquate. Le problème est que nous nous attendons souvent à ce que la sécurité soit en place sans vérifier ou poser des exigences lors de l'achat, ce qui peut avoir des conséquences fatales en cas d'attaque.   C'est pourquoi nous avons établi une liste de contrôle des éléments à inclure dans vos exigences lors de la phase d'achat d'une solution SaaS. Vous trouverez la liste ici.

Dans cet article, nous répondons à certaines des questions les plus courantes que nous recevons sur la sécurité informatique. Qu'il s'agisse de comprendre l'importance d'intégrer des mesures de sécurité lors de la gestion des exigences ou de se tenir au courant des dernières tendances en matière de sécurité. Nous explorerons également le rôle critique que joue la sécurité dans le processus de développement et nous donnerons un aperçu de la sécurisation des anciens systèmes et de la mise en œuvre de contrôles internes continus.   Que pouvons nous faire pendant la gestion des exigences pour contribuer à la sécurisation des applications ?   Le top 10 de l'OWASP est très intéressant à suivre. Il s'agit d'une liste des vulnérabilités les plus courantes dans les applications web. L'OWASP (Open Web Application Security) est une organisation qui s'occupe de la sécurité des applications logicielles.    Il y a quelques années, l'OWASP ASVS (Application Security Verification Standard) a été publié. Il s'agit d'un excellent recueil à consulter pour identifier les problèmes de sécurité dans le cadre de la gestion des exigences. Il peut être utilisé comme une déclaration d'exigences pour les applications. L'ASVS est une sorte de liste de contrôle à trois niveaux différents. Commencez par le niveau 1 et comparez avec ce que vous avez en place et ce qui doit être appliqué, puis passez au niveau suivant. Toutes les applications doivent passer le premier niveau. Si vous souhaitez ajouter la sécurité à vos exigences, je commencerais par cela. De nombreuses entreprises commettent l'erreur d'appliquer trop de choses à la fois que l'organisation ne peut finalement pas gérer.    Comment rester à jour en matière de sécurité informatique ?   Nous suivons de nombreux spécialistes de la sécurité sur Twitter, où nous recevons de bonnes mises à jour si quelque chose s'est produit ou si un nouvel outil a été publié. Nous suivons également des blogs sur la sécurité, par exemple Daniel Miessler, Podcast, darknet diaries. Par ailleurs, nous recherchons des outils, des extraits de code ou des scripts que les gens ont publiés ou sont en train de publier, et nous cherchons à savoir ce qu'ils essaient de faire.    En ce qui concerne les vulnérabilités, nous ne nous asseyons pas tous les jours pour vérifier si une nouvelle vulnérabilité a été publiée pour un produit spécifique. C'est lorsque nous avons des missions qui comprennent une application avec une certaine forme de pile d'application que nous examinons les vulnérabilités existantes. Sinon, Linkedin est une bonne source pour se tenir au courant des nouvelles vulnérabilités publiées.    Avant Covid, de grands événements liés à la sécurité étaient organisés chaque été à Vegas : Black Hat, Def Con et BSides. C'est l'endroit idéal pour nouer des contacts et assister à des sessions intéressantes.     Qu'est-ce que la sécurité dans le processus de développement ?   Du point de vue des tests d'intrusion et sur la base de nos missions, nous avons remarqué que la phase de sécurité entre dans les projets de développement extrêmement tard. Souvent, aussi tard que lorsque le produit est sur le point d'être mis en production, parce que l'entreprise se rend compte qu'elle doit effectuer un test de sécurité. Et dans le pire des cas, nous trouvons de nombreuses vulnérabilités qui doivent être corrigées. Ce qui entraîne un retard dans le projet et une augmentation des coûts.    Nous aimerions voir les entreprises travailler sur la sécurité plus tôt dans la phase de développement. En matière de sécurité, vous parlez généralement de Shift-Left Testing, c'est-à-dire que nous n'appliquons pas la sécurité comme une fonction supplémentaire à la fin, mais que nous l'incluons dès le début. La sécurité doit être incluse dans les exigences.    Comment gérer la sécurité au niveau de l'infrastructure et de l'application lorsque les systèmes sont plusanciens ?   En construisant la sécurité autour du système, par exemple en compensant les contrôles tout autour avec des pare-feu de niveau sept, une inspection approfondie des paquets et en examinant la couche d'application. Réfléchissez également à l'opportunité de vous doter d'un système de détection d'intrusion (IDS) et/ou d'un système de prévention d'intrusion (IPS). Ce sont là quelques options pour sécuriser vos systèmes un peu plus anciens.    Existent-ils des bonnes pratiques pour mettre en place un processus solide de contrôles internes continus ?   Travaillez avec les 20 contrôles CIS. Quels sont les contrôles en place dans l'entreprise aujourd'hui ?     Lorsque nous parlons de contrôles, il s'agit de tout :      - Disposez vous d'un système antivirus ?    - Gardez vous une trace de vos ressources dans l'entreprise ?    - Avez-vous une vue d'ensemble de vos applications dans l'entreprise ?    - Effectuez vous régulièrement des tests d'intrusion ?    - Avez-vous des connaissances sur les privilèges administratifs ?    - Utilisez vous un système de courrier électronique sécurisé ?   C'est assez vaste, mais c'est une très bonne chose à suivre si vous voulez commencer à avoir un contrôle, une structure et un suivi à examiner. Comme pour toute autre chose, ne vous attaquez pas à tout en même temps, commencez modestement et prenez votre temps. La sécurité ne se fait pas en un mois, c'est un long processus. Les grandes entreprises travaillent et luttent continuellement avec les contrôles CIS, c'est une chose importante à mettre en œuvre si vous voulez vous conformer à l'ensemble des 20.    Comment développer des applications sécurisées dans l'informatique dématérialisée ?   Si l'on sépare l'infrastructure et l'application et que l'on commence par l'application, on ne voit pas de grande différence dans l'approche et dans ce qu'elle devrait pouvoir gérer. L'infrastructure, en revanche, comme la gestion des clés et des secrets, est différente de celle qui est mise en place sur site dans un centre de données. Vous avez beaucoup de sécurité dans le nuage directement, des choses que vous n'avez peut-être pas dans votre propre centre de données, comme la traçabilité des accès. Mais pour qu'il fonctionne comme prévu, il est nécessaire de le configurer et de le configurer correctement. Le nuage n'est pas sécurisé par défaut, et c'est l'utilisateur qui doit configurer et activer ces fonctionnalités avant qu'il ne soit en ligne sur l'internet.    Existe-t-il une bonne liste de contrôle que vous pourriez recommander pour mettre en évidence les problèmes de sécurité dans la gestion des exigences ?   Oui, OWASP ASVS    Existe-t-il un moyen de vérifier que le produit est sûr ?   Oui, la méthodologie Shift Left. La sécurité doit être prise en compte dès le début du développement et le produit doit être testé très tôt. Les tests d'intrusion l'analyse SAST (analyse statique) et l'analyse dynamique sous la forme d'une analyse des applications web sont d'autres moyens de vérifier que vous disposez d'un produit sûr. Ces méthodes vous permettent de suivre votre application sur le long terme.    Vous pouvez également utiliser la modélisation de la menace. Prenez votre application, vos développeurs, mettez vous devant un tableau blanc et dessinez l'application. Vous pouvez la décomposer en composants plus petits ou la dessiner de manière plus basique. Examinez les flux de données, comment et où ils entrent et sortent, quelles sont les fonctions disponibles et commencez à dresser la liste des différents modes d'attaque possibles et des vulnérabilités éventuelles. Essayez ensuite de construire et de mettre en œuvre la sécurité.    Qu'est ce que le Privacy by Design ?   Le terme "privacy by design" est un terme plus élégant qui signifie que vous devriez penser à la sécurité dès le début, en ayant déjà des exigences en matière de sécurité.    La modélisation des menaces, telle que décrite ci-dessus, au début du développement est un très bon début. Le RGPD s'applique aux données personnelles et le PCI DSS est un document juridique bien développé sur la manière de traiter les données des cartes de crédit. Lorsqu'il s'agit d'informations confidentielles, vous pouvez vérifier quels sont les cadres juridiques à prendre en compte. Ensuite, il est important d'intégrer les processus de sécurité, tels que les exigences de sécurité, la modélisation des menaces, l'examen du code, les outils DAST, les tests d'intrusion et les tests d'infrastructure en termes d'outils d'automatisation.     Un test automatisé pourrait-il être une option dans la mesure où les compétences humaines sont rares ? Pouvez-vous nous recommander des tests ?   Notre recommandation est d'automatiser davantage là où c'est possible. Nous pensons que vous pouvez effectuer toutes les vérifications qui peuvent être automatisées, par exemple, dans le cadre de l'ASVS ou d'un processus CICD. Utilisez des outils automatisés, des outils DAST, des outils d'examen du code ou autres.    Notre expertise est nécessaire pour les questions plus complexes et lorsque des tests plus complexes doivent être effectués. Souvent, lorsque nous sommes sur le point d'effectuer des tests de pénétration, les entreprises n'ont pas effectué d'examen du code ni exécuté d'outils DAST. Cela signifie que nous devons identifier tous les types de vulnérabilités, ce qui n'est pas une mince affaire. Les meilleurs cas sont ceux où nous recevons un rapport d'un outil d'analyse des vulnérabilités et où nous examinons l'infrastructure et où il s'avère que la revue du code et les outils DAST ont été exécutés. Notre travail peut se concentrer sur toutes les autres choses que les outils ne peuvent pas faire lorsqu'il s'agit de logique pure. Comme la gestion de la logique dans une application, la logique commerciale pure, etc. Les outils automatisés ne sont pas particulièrement efficaces pour identifier ces éléments, car ils n'ont aucune idée de la manière dont l'application elle-même devrait fonctionner. Automatisons autant que possible et utilisons notre expertise pour les choses que les outils ne peuvent pas gérer.    Les tests que nous recommandons :    L'OWASP ASVS, niveau 1, est rédigé de manière à ce que vous puissiez l'automatiser complètement. L'OWASP Testing Guide est également un très bon guide sur les types de problèmes et la manière d'identifier les vulnérabilités.    En matière d'outils, tout dépend de l'entreprise. Aucun outil ne convient à tout le monde. 

Nous avons parlé dans un article paru il y a quelques semaines, des challenges humains auxquels le testeur doit faire face..   Le métier du test n’étant pas uniquement humain il existe également de nombreux défis liés à la technicité du test.   Cet article vous propose quelques-uns de ces défis techniques que nous observons le plus fréquemment.   Les tests API   Les challenges   Les logiciels ne sont pas isolés dans leur environnement. Afin d’échanger avec les autres logiciels ils communiquent au moyen d’API. Afin d’avoir un produit fonctionnel il est essentiel de s’assurer que ce dernier puisse interagir avec certains logiciels environnants. Ces interactions entre logiciel se doivent donc d’être testées.   Ces tests peuvent s’avérer déstabilisants pour des testeurs car les APIs ne proposent pas d’interfaces graphiques (les logiciels n’en ont pas besoin pour communiquer entre eux) et nécessitent des outils spécifiques.   De plus, même s’il est aisé de maitriser les APIs de son logiciel, ce n’est pas forcément le cas pour les APIs des logiciels avec lequel notre produit interagit.   Enfin ces interactions, très codifiées, peuvent générer des architectures plus ou moins faciles à appréhender.   Mes conseils   Il ne faut pas être effrayé par les tests d’APIs et les APIs en général lorsque l’on est testeur et ce même quand on est un testeur fonctionnel avec peu de compétences « techniques » et ce pour plusieurs raisons :   Il existe de nombreux outils de test d’APIs accessibles et relativement simples à prendre en main comme Postman, Les tests d’APIs ne sont généralement pas particulièrement complexes fonctionnellement car ce sont des messages normés dans lesquels ont fait passer des variables. Personnellement, j’aime voir les tests APIs comme des tests de formulaires dans lesquels on vérifie différentes valeurs que peuvent prendre les champs, Il est simple de multiplier les tests d’APIs très rapidement. En effet, dès le moment où l’on a un message, on peut faire de nombreux tests (avec des tests pilotés par les données) basés sur ce même message de base.   Les tests d’APIs sont un bon premier pas dans le monde des tests « techniques » car ils restent assez simples à appréhender dès lors où l’on a commencé à mettre les mains dans le cambouis. De même il est de plus en plus important, dans un contexte Agile, pour les testeurs de pouvoir intervenir sur différents aspects du test et les tests d’API sont une compétence de plus en plus recherchée.   Automatisation des tests   Les challenges   Ce challenge n’est pas nouveau ! J’entends parler d’automatisation des tests depuis que j’ai commencé à travailler en 2011. D’ailleurs, je ne doute pas que les testeurs entendent parler d’automatisation depuis bien plus longtemps. Il parait donc assez surprenant, au premier abord, de se dire que l’automatisation n’est pas totalement généralisée. D’ailleurs la part de test automatisés tant à se stabiliser plutôt qu’à se développer au cours des dernières années.   La raison est au final assez simple : il n’est pas simple d’automatiser l’exécution de ses tests. Les outils son nombreux, les besoins et contextes le sont encore plus !   De nombreux projets d’automatisation échouent car l’outil d’automatisation n’est pas adapté, les tests automatisés sont trop chronophage au niveau maintenance, les objectifs et la stratégie d’automatisation ne sont pas clairement définis ou adaptés ou encore les tests automatisés ne sont pas suffisamment fiables.   Afin de bien réussir son automatisation il faut donc bien sélectionner son outil, bien former les personnes qui interviendront sur cette automatisation, bien identifier le périmètre d’automatisation et adapter son périmètre et ses tests en fonction du contexte.   Mes conseils   Si l’on est un testeur fonctionnel l’automatisation des tests peut vite devenir incompréhensible. En effet, le testeur non technique se doit de monter en compétence en scripting (pour comprendre et écrire des tests automatisés) mais aussi en mise en place et suivi de tests automatisés. Dans ce cas, je conseille de faire les choses pas à pas en commençant par une automatisation « simple ». Cela peut se faire avec du test API ou en utilisant un framework KDT (Keyword Driven Testing) déjà développé comme on peut le voir avec des outils comme RobotFramework ou encore en utilisant des outils d’automatisation pensés pour des testeurs fonctionnels et qui permettent de se familiariser avec l’automatisation et ses contraintes. Je pense ici à des outils comme Agilitest.   Si l’on n’a pas de difficulté majeure avec la technique alors il n’y a « que » le challenge de mise en place et de réalisation qui est à relever. Il faut alors :   Bien sélectionner l’outil de test à utiliser afin que celui-ci permette de gérer les différents besoins des tests, Proposer des tests maintenables en utilisant les bonnes pratiques de code, Assurer une maintenance régulière des tests automatisés, Assurer un suivi régulier de ces tests, faire vivre la campagne de test.   L’intégration des bons tests non fonctionnels   Les challenges   On entend, enfin, de plus en plus parler de tests non fonctionnels. Les plus courants sont les tests de sécurité (popularisés par la RGPD), les tests de performances, les tests d’adaptabilité (notamment pour les mobiles) et les tests d’accessibilité (popularisés par la RGAA en France et WCAG dans le reste du monde). La liste de types de tests non fonctionnels va d’ailleurs continuer à s’agrandir avec les usages et les normes à venir comme la RGESN pour l’éco-conception. Comme vous le savez il est impossible de faire tous ces tests en profondeur et un testeur se devra de savoir identifier quels tests non fonctionnels doivent être faits et jusqu’à quelle profondeur ils doivent être poussés.   Mes conseils   Mon principal conseil est ici de s’appuyer sur des exigences et « d’exiger » d’avoir des exigences non fonctionnelles testables… ou tout simplement d’exiger que sur les points non abordés il n’y ait pas d’exigence et donc pas de besoin de test !   Je suis conscient que la première partie est utopique dans de nombreux contexte. Si l’existence de ces exigences n’est pas envisageable il peut être intéressant d’aborder le sujet des tests non fonctionnels directement dans la stratégie de test de l’entreprise avec les manières de sélectionner les tests non fonctionnels à implémenter. Puis de décliner cette stratégie dans les plans de test (stratégie au niveau du projet/produit). Dans le cas d’absence d’exigences chiffrées il faudra s’inspirer des différentes normes (RGPD, RGAA…) ou encore de ce que l’on observe sur le marché ou en production si le produit est déjà en production.   La conception des tests   Les challenges   On pourrait m’argumenter que la conception de test n’est pas technique. Il est vrai qu’il n’est pas nécessaire de savoir manipuler ou lire du code pour concevoir de bons tests. La conception de tests de qualité est cependant un aspect hautement technique du travail de testeur. Il existe plusieurs méthodes de conception de tests (les plus connues des testeurs sont basées sur les spécifications) qui permettent d’identifier, en fonction des conditions de test, quels sont les tests à faire et avec quelles valeurs. De même, un testeur doit savoir prioriser et identifier, quels sont les éléments à tester et jusqu’à quel point en fonction des risques et des moyens dont il dispose.   Mes conseils   Il faut tout d’abord bien connaitre ses techniques de conception, connaitre leurs points forts et points faibles et la manière de les implémenter. Ces connaissances techniques ne sont pas suffisantes. Il est essentiel de bien appréhender le contexte et le produit à tester. Cela permet alors de s’adapter au contexte et de proposer un mixte de techniques qui permettent d’avoir un ensemble de test aussi efficient que possible. Il est également primordial de faire un travail approfondi sur les données de test (certaines techniques de conception orientent fortement sur les valeurs à choisir pour certains cas) afin de choisir des données qui permettront de trouver au mieux les différentes failles potentielles du produit.   La gestion des données et environnements de test   Les challenges   C’est une problématique majeure pour de nombreux testeurs ! Les environnements de test ne sont pas stables ou difficilement accessibles ou pas assez proches de la production. Les données de sont pas représentatives ou pas assez nombreuses ou non accessible ou non anonymisées… Le problème est ici que pour être capables de tester correctement un produit il est essentiel de se rapprocher d’usages proche de la production pour simuler aussi fidèlement que possible le comportement qu’auront les utilisateurs. Malheureusement il est quasiment impossible d’avoir un environnement aussi important que celui de production d’un point de vue volume mais aussi interaction avec les partenaires. De même, tout miser sur du test en production avec du shift right n’est pas la solution.   Mes conseils   Les problématiques de données et d’environnements sont généralement assez complexes. Heureusement il existe actuellement de nombreux outils pour nous aider avec ces problématiques. Je pense notamment à la virtualisation des environnements qui permet de créer des environnements à la volée ce qui évite les problématiques d’environnements partagés par plusieurs équipes ou des environnements avec des données « déjà utilisées ». Pour les données il existe des outils (éditeurs ou « maison ») qui permettent d’anonymiser et prendre des sous-ensembles de données en production pour avoir des échantillonnages représentatifs.   Pour la partie partenaire, une solution parfois obligatoire, est la mise en place de bouchons car les partenaires n’ont pas forcément d’environnement de test partagés avec notre produit ou que ce dernier est trop souvent « down ».   Bref, ici pas de solution miracle mais plutôt une recherche de solutions pragmatiques (souvent outillées) liées à chaque contexte. Le plus important étant d’identifier les points les plus problématiques afin d’essayer d’y répondre.   Enfin, il arrive également que les problèmes d’environnements et de données puissent se régler avec de l’humain dans des contextes où les environnements et les données de test ne sont pas sous le contrôle des équipes utilisant des environnements et données.

La plupart des produits que vous achetez sont destinés à la sécurité des réseaux et des points d'accès. Ils ne seront pas très efficaces contre les vulnérabilités des applications web. Dans cet article, nous mettons donc en lumière les problèmes les plus courants que nous rencontrons dans notre travail, de la faiblesse du réseau à l'énumération des utilisateurs. Comprendre ces défis est essentiel non seulement pour les professionnels de l'informatique, mais aussi pour les individus et les organisations qui s'efforcent d'améliorer leur sécurité dans un monde de plus en plus interconnecté.   Les mauvais mots de passe   Lorsque vous utilisez une application, l'une des premières choses que vous rencontrez est une sorte d'authentification. Il s'agit généralement d'une combinaison de nom d'utilisateur et de mot de passe. Bien entendu, les exigences varient considérablement d'un site à l'autre. Il est assez courant de voir des exigences concernant les lettres majuscules et minuscules, ainsi que des chiffres et des caractères spéciaux. La longueur est également un facteur important. Une bonne ligne de conduite à suivre est de le garder suffisamment long pour éviter le forçage brutal et suffisamment complexe pour qu'il n'apparaisse pas dans un dictionnaire. Une bonne longueur recommandée est un minimum d'AU MOINS 10 caractères. De préférence beaucoup plus.    Nous avons rencontré de nombreuses applications dans lesquelles la seule exigence était une longueur de six caractères. Ainsi, un mot de passe tel que "111111" serait parfaitement acceptable. Il faudrait peu de temps, même à un ordinateur bas de gamme, pour déchiffrer un hachage de ce mot de passe. De plus, ce mot de passe figure probablement dans un dictionnaire, de sorte qu'il serait tout à fait possible de le forcer brutalement. Pour en savoir plus sur la manière dont les mots de passe sont déchiffrés, cliquez ici.   L'absence de mise en œuvre solide du protocole SSL    Un outil astucieux pour évaluer l'état actuel de l'implémentation de SSL, SSL Labs est rapide, facile à utiliser et complet. Il existe également l'outil SSL Checker, une version plus simplifiée et plus facile à comprendre pour un non-technicien. Il offre également la possibilité de vérifier les en-têtes de sécurité SSL. Nous n'allons pas entrer dans tous les détails concernant l'implémentation de SSL/TLS, cela nécessiterait au moins plusieurs pages supplémentaires à ce billet. Nous devrons donc revenir avec un article séparé à ce sujet. Si vous voulez vraiment en savoir plus tout de suite, il existe un autre outil astucieux. Ils l'appellent Google ; nous pensons qu'il commence à faire son chemin ! Ou contactez-nous et nous ferons en sorte que vous obteniez des informations correctes.    L'énumération des utilisateurs    Les applications vous permettent d'énumérer les utilisateurs valides de plusieurs manières. L'une des plus courantes et des plus faciles à réaliser est la fonction de connexion. Un exemple : Vous vous connectez à une application. Si vous tapez le bon nom, mais que vous vous trompez dans le mot de passe et que la réponse indique "le mot de passe est incorrect", il s'agit d'un indice que l'utilisateur n'est pas valide. C'est un indice que l'utilisateur est un utilisateur valide. Si vous essayez un autre nom d'utilisateur (qui n'est pas valide) et que la réponse indique "Pas un utilisateur valide", vous pouvez facilement déterminer que le premier utilisateur était en fait un utilisateur valide.    Pour un hacker, ce serait une bonne occasion d'essayer de forcer les utilisateurs de l'application. L'application répondra et vous informera si l'utilisateur est valide ou non.    Injection XSS/HTML/SQL    La question numéro un de 2017 et 2018 a été celle des injections de toutes sortes. Qu'est-ce qui peut être injecté ? Des requêtes SQL, des commandes OS, du contenu HTML, des pages entières de contenu et des scripts. Où quelqu'un pourrait-il injecter cela ? Partout où une entrée utilisateur est requise, ou où les utilisateurs peuvent modifier des données, c'est-à-dire une zone de texte, un champ de nom d'utilisateur/mot de passe, des fonctions de recherche, des champs de commentaires et de rétroaction, des URL, etc.    Téléchargement de fichiers sans restrictions   Les fichiers téléchargés peuvent avoir de graves répercussions sur l'application et le système de fichiers. On constate souvent qu'il n'y a pas de filtre sur les types d'extensions de fichiers qui peuvent être téléchargés. Si seuls un ou deux types de fichiers sont nécessaires, tous les autres devraient figurer sur la liste des indésirables.    Imaginez une application écrite en PHP, dans laquelle l'utilisateur peut télécharger une photo de profil. On pourrait supposer que cette fonction n'autorise que le téléchargement de fichiers images (JPG et PNG). Mais d'autres formats de fichiers peuvent également être téléchargés. Dans ce cas, puisque nous avons affaire à PHP (et que PHP peut interagir directement avec le système d'exploitation), nous téléchargeons un code PHP amusant qui nous permettra de communiquer directement avec le système de fichiers du serveur lui-même. Cela peut conduire à des choses problématiques telles que la compromission d'informations et l'accès potentiel à des parties plus profondes du réseau.    Contrôles d'accès défaillants (sécurité par l'obscurité)    Cela se produit lorsque des vérifications appropriées ne sont pas effectuées pour l'ensemble du plan du site. Cela permet à un utilisateur d'accéder à des informations que ses permissions ne devraient pas autoriser (ou de manière totalement non authentifiée). Imaginez que vous naviguez dans votre application de relevé d'heures avec votre compte à faible privilège, la seule chose qui vous empêche d'approuver votre propre relevé d'heures est essentiellement d'ordre cosmétique. Le bouton d'approbation n'est pas visible par votre compte, mais uniquement par les administrateurs de l'application. En réalité, si vous connaissiez les données de la demande, vous pourriez approuver le rapport d'activité vous-même.    Dans cette application, vous et votre entreprise avez stocké des documents internes contenant ce que l'on peut appeler des informations sensibles. Vous accédez à l'un des fichiers PDF et le téléchargez, après vous être authentifié. Si vous vous déconnectez de l'application et que vous accédez ensuite à la même URL pour ce document, et que le fichier est accessible, cela prouverait une fois de plus que les contrôles d'accès ont été rompus.   Faible segmentation des utilisateurs/groupes (pratique du moindre privilège)    Permissions uniformes pour les utilisateurs et les groupes. Il serait agréable de vivre dans un monde où tous seraient égaux. Dans le domaine de l'informatique, c'est un non-sens absolu, mais c'est encore très courant. Tous les comptes d'une application ou d'un réseau ont les mêmes privilèges, ce qui entraîne le chaos, surtout si ces informations d'identification sont compromises par un pirate. Cela revient plus ou moins à donner à l'attaquant les clés du royaume et c'est ce que l'on appelle plus communément "une mauvaise idée". Ce qu'il faut se demander ici, c'est si Janice, de la comptabilité, a réellement besoin d'accéder aux documents top secrets destinés à Leann et Kurt. Les rôles des utilisateurs doivent être attribués selon la pratique du moindre privilège : ce que vous n'avez pas besoin de savoir, vous ne devez tout simplement pas le savoir ou y avoir accès.     Mauvaise gestion des correctifs / de la fin de vie    L'épidémie WannaCry/EternalBlue du 12 mai 2017 est un excellent exemple de ce problème. Des infrastructures du monde entier ont été touchées par cette vulnérabilité, des entreprises de différentes tailles ont vu leurs serveurs et ordinateurs infectés par un cryptolocker. Les dommages totaux signalés s'élèvent à plus de 8 milliards de dollars dans 150 pays, rien que pour l'incident WannaCry, selon IBM X-Force. Je pense que cela se passe de commentaires : si vous gérez vos propres données et serveurs, vous pouvez contrôler quand et ce qu'il faut corriger. Avec un fournisseur tiers, vous n'avez pas la moindre idée de ce qu'il fait. C'est pourquoi c'est une bonne question à poser à tout fournisseur tiers que vous envisagez d'utiliser.     Faible segmentation du réseau/de la base de données    Il est arrivé que l'on nous dise que le réseau ou la base de données était correctement segmenté, du moins d'après les personnes à qui nous avons parlé. Lorsque nous les recontactons quelque temps plus tard, nous avons la preuve que ce n'est pas le cas. Applications où la version de pré-production et la version de production sont stockées sur le même serveur que la base de données "correctement segmentée". La segmentation réelle de la base de données n'était en fait que deux branches distinctes dans la même base de données. Cela signifie que l'injection SQL trouvée dans l'application de pré-production a également conduit à une compromission totale de la base de données de production. Cette situation a également été observée dans le cas de systèmes multi-locataires dans lesquels les données de plusieurs entreprises sont toutes stockées dans la même base de données.    

Avec le temps, certains logiciels perdent en qualité en raison du manque de mises à jour, du manque de support et des changements des besoins des utilisateurs. Pour mieux comprendre ce phénomène, nous vous proposons 3 petits articles sur le sujet.     Comment savoir si notre logiciel perd de sa qualité ?   Plusieurs indicateurs peuvent aider à déterminer que notre logiciel perd en qualité.En premier, au niveau fonctionnel, nous avons les anomalies en production, la maintenance et les livraisons qui deviennent difficiles, le manque de traçabilité et la perte de connaissance liée à la fabrication passée du logiciel.En second, au niveau non fonctionnel, nous avons l'apparition de failles de sécurité, la récurrence des phénomènes de ralentissement, une utilisabilité et une ergonomie vieillissante, la non-conformité et enfin et surtout, l'indicateur le plus important de tous : la perte d'utilisateurs.   Peut-on décider d’arrêter la mise en service d’une application si elle n’est plus de qualité ?   Oui, une des raisons de l'arrêt d'une application peut être sa qualité insuffisante. Il faut cependant faire attention. En effet ce n'est pas un audit qui va définir l'arrêt d'une application. L'audit va donner des préconisations et les chiffrer plus ou moins précisément. Le choix d'arrêter l'application se fait à un niveau plus stratégique dès lors ou la non qualité de l'application coûte trop cher. C'est à dire que sa remise à niveau est hors budget et que l'impact de son fonctionnement est plus négatif que celui de son arrêt.De nombreuses applications se sont arrêter pour des raisons de qualité, il y a notamment l'exemple pris à la JFTL: périscope, qui a été arrêté notamment à cause de coûts de maintenance trop élevés.   Peut-on considérer que la qualité est irrécupérable et qu’il est nécessaire de tout reprendre au début ?   La qualité est généralement toujours récupérable, mais peut dans bien des cas, demander un gros investissement en temps et en coûts pour sa restauration. Selon le contexte, le client pourra décider selon le budget et les délais dont il dispose, de mener à bien les actions d'amélioration ou de repartir du début. Suite à un audit, des recommandations sont faites pour aiguiller le client qui reste décisionnaire au final.    

Ces dernières années, dans le domaine du développement, la capacité à livrer rapidement a augmenté, ce qui amène une plus grande attention à l'automatisation des tests. Il n'a jamais été aussi important d'étudier de manière approfondie le produit, car cela permet de déterminer ce qui pourrait ne pas fonctionner dès le début et de trouver des solutions pour résoudre les problèmes qui pourraient survenir.  Bien que l'automatisation des tests soit devenue une pratique recommandée, il n'en reste pas moins que les tests manuels sont, dans de nombreux cas, préférés aux tests automatisés. Dans cet article de blog, nous allons examiner de plus près certains des plus grands avantages de l'automatisation des tests.  AMELIORATION DE LA QUALITE ET DU CONTRÔLE   Aujourd'hui, l'accent est mis sur la recherche d'erreurs à un stade précoce de la chaîne de développement, ce qui signifie que la ou les personnes responsables de l'assurance qualité doivent avoir un contrôle total sur la manière dont elles doivent envisager les tests.   Le fait de disposer de tests à tous les niveaux simplifie le processus de recherche d'une erreur dans un système, ce qui facilite le dépannage et nous permet de trouver le problème plus rapidement. Des processus plus rapides et moins d'erreurs - l'automatisation est tout simplement un moyen intelligent de travailler plus efficacement. En fournissant un retour d'information rapide sur les changements de fonctionnalité ou même sur les modifications du système, on peut rationaliser la mise en place de nouvelles fonctionnalités, avec l'assurance que les flux critiques pour l'entreprise fonctionnent toujours.     LIVRAISONS PLUS RAPIDES   Aujourd'hui, le développement suit un rythme dynamique où de nouvelles versions sont construites, voire livrées, plusieurs fois par jour, et l'on s'attend donc à ce que les tests suivent le même rythme. Cela peut mettre à mal le travail d'un testeur, les tests exploratoires étant le seul espoir.     L'automatisation nous donne la possibilité d'obtenir rapidement un retour d'information sur l'état d'un système et de savoir si quelque chose est cassé ou non. Les machines effectuent des opérations plus rapidement et peuvent faire des choses que nous, les humains, ne pouvons pas faire du tout, comme simuler des milliers d'utilisateurs simultanés dans un système de test contrôlé.     Un retour d'information plus rapide permet de simplifier le processus, ce qui se traduit en fin de compte par une livraison de produits meilleurs et plus rapides.     ACTIONS EFFICACES   Un autre avantage majeur de l'automatisation des tests est de rendre les ressources plus disponibles pour consacrer du temps à d'autres travaux de qualité. La réduction du nombre d'heures supplémentaires permet de se consacrer à des tâches créatrices de valeur. Au lieu d'effectuer des tests de régression longs, fastidieux et souvent monotones, nous pouvons approfondir nos connaissances dans de nouveaux domaines ainsi que dans des domaines problématiques connus. Dans cette optique, vous aurez également plus de temps pour les tests exploratoires. Plus nous avons le temps d'explorer le système, plus nous pouvons apprendre et plus il est facile de prendre des décisions en connaissance de cause. Les employés trouvent ainsi le travail moins stressant, plus intéressant, et le lieu de travail plus attrayant.      Si l'automatisation des tests est une bonne chose à bien des égards, il ne faut jamais oublier les tests humains. Il est tout aussi important et, par conséquent, une utilisation combinée des deux est toujours la meilleure pratique.   Conclusion   Lorsque les utilisateurs exigent que les nouvelles fonctionnalités et les corrections de bogues soient livrées de plus en plus rapidement  la nécessité d'automatiser les tests augmente encore plus rapidement. Aujourd'hui, l'automatisation des tests est une aide précieuse qui peut compléter les tests manuels, et un outil important à utiliser dans notre kit de test lorsqu'il s'agit de la recherche constante d'une meilleure qualité. Nous avons beaucoup à gagner en automatisant au moins une partie de nos tests - des livraisons plus rapides, une meilleure qualité et des employés plus heureux en font partie.  

Cet article est la suite de l'article du même nom paru dans le numéro 15 de la revue Quality Matters.Depuis 2020, les principaux éditeurs de tests logiciels ont pris le virage du no-scripting en utilisant la puissance de l'IA. Nous pouvons considérer les outils de ces éditeurs (au moins pour Eggplant et UFT One) comme la "2e génération" d'outils d'automatisation sans script, car ils poussent encore plus loin le concept de "pouvoir automatiser toutes les technologies avec le même outil" en proposant un test unique capable de fonctionner sur différents environnements tels qu'un ordinateur (différents navigateurs) et un téléphone (Apple ou Android).Ce changement explique pourquoi nous voyons actuellement apparaître des outils tels que Tosca (Tricentis) ou UFT One (Micro Focus). Marc Hage Chahine     ---- Vous souhaitez en savoir plus ? Jetez un oeil à l'article complet publié dans le magazine QUALITY MATTERS (voir le lien ci-dessous)   Une fois sur le site web, vous pourrez créer un compte gratuit pour accéder à l'édition actuelle et aux anciennes éditions de QUALITY MATTERS.

Les tests "low code" et "no code" sont des méthodes permettant d'automatiser les tests avec un minimum de codage ou sans codage du tout. Il s'agit d'un changement radical par rapport à la pratique antérieure qui consistait à travailler en étroite collaboration avec le code, en utilisant des uns et des zéros, pour utiliser aujourd'hui un langage plus naturel et des interfaces graphiques afin d'effectuer des tâches automatisées. Cette méthodologie vise à simplifier et à accélérer le processus de test en le rendant accessible à des personnes ayant différents niveaux de connaissances techniques, y compris celles qui n'ont pas de compétences approfondies en programmation.   Deux choses qui distinguent Low Code / No Code :   Une base d'utilisateurs plus large : Les tests Low Code / No Code permettent aux personnes n'ayant pas de compétences en programmation de créer des tests automatisés. En utilisant des outils visuels et des interfaces plus simples, les utilisateurs peuvent créer et maintenir des tests automatisés sans avoir à se plonger dans les détails du code. Cela permet aux organisations de rationaliser leurs processus de test et de permettre une participation plus large aux tests, ce qui, en fin de compte, peut conduire à une livraison plus rapide et plus agile des logiciels.    Facilité d'utilisation : L'idée générale des outils de Low Code / No Code est qu'ils doivent être faciles à comprendre et à utiliser, ce qui raccourcit le temps d'apprentissage. Ces outils sont beaucoup plus visuels que les méthodes traditionnelles, ce qui facilite le travail. Des exemples d'outils Low Code/No Code sont Postman flows, Jmeter, Katalon Studios et Leapworks.    Low Code / No Code ou pas ?   L'un des avantages de commencer avec Low Code / No Code est qu'on peut espérer que cela incitera beaucoup plus de gens à se lancer et à créer. Cela peut être avantageux en termes de coûts et de temps, et un démarrage rapide peut permettre d'aller beaucoup plus loin, même si cela ne permet pas toujours d'atteindre l'objectif final. Il y a toujours un risque de rencontrer des problèmes plus tard dans le développement qui nécessitent des solutions plus techniques, qui peuvent être coûteuses à résoudre.    Avec Low Code / No Code, les utilisateurs ne peuvent pas être aussi détaillés ou résoudre des problèmes très spécifiques parce que les outils sont conçus pour être généralement utiles et faciles à utiliser. Cela fonctionne très bien pour les entreprises qui ont des solutions plus simples, mais pour des solutions plus techniques et plus avancées, des outils et des connaissances plus poussés sont nécessaires.    Aujourd'hui, ce n'est pas une solution de commencer un projet avec un code faible ou nul, puis de faire appel à des personnes ayant des compétences techniques avancées à mi-parcours. Il est donc essentiel de comprendre le produit dès le départ et d'identifier ce dont il a besoin pour le construire correctement.    Avantages pour les entreprises d'utiliser Low Code / No Code   Démarrage rapide et automatisation: L'avantage est qu'il est plus facile de démarrer et de créer quelque chose qui est au moins semi-automatique. En utilisant de tels outils, les développeurs peuvent rapidement créer des systèmes de base qui fonctionnent et répondent aux besoins des utilisateurs finaux. Pour les cas d'utilisation courants et généraux, tels que la création d'une page de connexion, l'utilisation de Low Code / No Code est parfaite.    Simplicité dans les tests : Les outils peuvent aider à générer et à exécuter de nombreux cas de test rapidement et de manière générale. Dans les contextes de test, comme dans le cas d'une page de connexion, ces outils peuvent traiter des exemples de test standardisés, réduisant ainsi le besoin de tests détaillés et spécialisés. Ils permettent de réfléchir à différents scénarios et de les tester sans qu'il soit nécessaire de les détailler techniquement.    Amélioration de la collaboration entre les équipes commerciales et techniques: Les plateformes Low-Code / No-Code permettent une collaboration plus étroite entre les membres de l'équipe technique et non technique. Les utilisateurs professionnels et les décideurs peuvent jouer un rôle plus actif dans le processus de développement, ce qui améliore la compréhension et la collaboration entre les différents départements.    Agilité accrue et adaptation plus rapide aux changements : Comme les méthodes Low-Code / No-Code permettent un développement plus rapide et des changements plus simples, les entreprises peuvent être plus flexibles et s'adapter à l'évolution des exigences et des conditions du marché.    Évolution du rôle des développeurs et des testeurs   Dans la tendance générale du développement au cours des dix dernières années, la nécessité de comprendre et d'utiliser différents outils s'est accrue, et l'utilisation de Low Code / No Code introduit encore un autre outil que les développeurs et les testeurs doivent comprendre et utiliser. Cela signifie que pour réussir, les développeurs et les testeurs doivent aujourd'hui disposer d'une base plus large de compétences et d'outils.    Pour les développeurs, l'introduction de Low Code / No Code signifie qu'ils se concentrent davantage sur l'architecture et la conception, et qu'ils collaborent plus étroitement avec les utilisateurs finaux. Cela signifie qu'ils peuvent consacrer plus de temps à des tâches complexes et architecturales, créer des composants réutilisables et maintenir des parties techniquement avancées.    Pour les testeurs, le changement réside dans le fait qu'ils peuvent utiliser des outils Low Code / No Code pour des tests plus rapides, des scénarios de test complexes et des tests automatisés.    Pour les deux rôles, la collaboration et la communication deviennent cruciales. Les changements n'impliquent pas seulement de nouvelles tâches, mais aussi des opportunités d'améliorer et d'optimiser les flux de travail pour répondre aux demandes de développement de logiciels plus rapides et de meilleure qualité.    Étapes à suivre avant de commencer   Avant de commencer, il y a quelques points importants à prendre en compte :    Temps d'apprentissage : Même si l'objectif de ces outils est de rendre les choses plus faciles et plus rapides que de passer par de longues formations, il y a toujours une certaine courbe d'apprentissage. L'utilisation de ressources telles que YouTube et d'autres tutoriels peut s'avérer très utile pour démarrer rapidement.    Se tenir au courant de l'actualité mondiale : Pour profiter des outils les plus récents et les plus utiles, il est important de rester informé de ce qui se passe dans le monde. Suivre les tendances et découvrir de nouveaux outils qui peuvent faciliter le travail est un élément clé.    Comprendre le problème : Il est important de bien comprendre le problème spécifique avant de choisir un outil. L'utilisation d'un outil inadapté à une tâche donnée peut être source d'inefficacité et de frustration. Une analyse approfondie du problème est nécessaire pour le faire correspondre à l'outil adéquat.    Outils d'achat : Le choix et l'achat des bons outils constituent une partie essentielle du processus. Il peut s'agir de convaincre les décideurs et les responsables du budget de la valeur des outils et d'investir dans ceux-ci. Il est important de tenir compte du rapport coût-efficacité et de la manière dont l'outil s'inscrit dans la stratégie globale de l'organisation.    Pour résumé   Les outils Low Code / No Code sont très utiles car ils permettent des démarrages rapides et réduisent la nécessité d'une expertise technique avancée. Ils permettent aux utilisateurs de créer et de gérer l'automatisation à des fins générales, ce qui est bénéfique pour les entreprises qui s'efforcent de développer des produits plus rapidement et de manière plus rentable.    En même temps, il est important de souligner l'importance de choisir les outils qui conviennent le mieux au projet et à l'objectif spécifiques. Malgré les avantages d'un développement rapide et rentable, il est important de se rappeler que les outils Low Code / No Code ne peuvent pas résoudre des problèmes plus complexes et détaillés, car ils sont conçus pour être utilisés de manière générale. Il est donc important d'être conscient de leurs limites et d'envisager d'autres solutions plus techniques lorsque cela est nécessaire pour gérer la complexité et les détails du projet.

Dans le contexte actuel de développement, les entreprises font face à des impératifs d'efficacité, de célérité et de qualité élevée pour demeurer compétitives. La conception logicielle s'effectue fréquemment de manière incrémentielle, rendant ainsi insoutenable, le test manuel de chaque itération avant le déploiement en production. L'automatisation des tests est devenue essentielle pour relever ces défis. Si vous souhaitez vous lancer dans la mise en place de l'automatisation des tests mais ne savez pas par où commencer, cet article est conçu pour vous. Nous nous pencherons sur les caractéristiques de l'automatisation des tests avec un aperçu des outils susceptibles de rationaliser le processus.     Qu'est-ce que l'automatisation des tests ?   L'automatisation des tests implique l'utilisation de frameworks et d'outils pour créer des tests qui peuvent s'exécuter indépendamment et s'intégrer à un objet de test. L'automatisation des tests peut être classée en fonction de sa pertinence, avec deux approches principales : l'automatisation basée sur l'intégration (via API) et l'automatisation basée sur l'interface graphique . Il existe plusieurs méthodes pour définir un niveau d'automatisation :   Couverture des processus métier  Couverture de code  Temps d'exécution   Considérations clés pour démarrer l'automatisation   Lors de la mise en place de l'automatisation des tests, plusieurs facteurs cruciaux doivent être pris en compte. Il n'est pas nécessaire que tout soit parfait dès le départ ; il vaut mieux commencer par de petites parties et progresser graduellement que de ne pas commencer du tout. Voici quelques exemples :    Toujours donner la priorité au ROI  Impliquer l'organisation  Commencer et évoluer progressivement  Permettre à l'automatisation de différents niveaux de s'accorder    Les outils d'automatisation   Lorsqu'il s'agit d'outils, de nombreux facteurs doivent être pris en compte avant de prendre une décision. Contrairement au passé, où un seul outil était souvent utilisé pour toute l'automatisation des tests, les systèmes complexes d'aujourd'hui nécessitent différents outils pour différentes parties. Les outils tout-en-un manquent souvent d'expertise. L'approche actuelle consiste à trouver des outils spécifiques pour différentes situations et différents besoins, ce qui permet de créer une boîte à outils personnalisée pour les besoins individuels.    Avant de prendre une décision, il convient d'examiner les points suivants :   Piloté par le code ou basé sur l'interface graphique : Choisissez en fonction de ce que vous devez tester. Les outils basés sur l'interface graphique, comme Selenium ou WebDriver, conviennent pour tester l'interface graphique via un navigateur web. Si vous automatisez par rapport à des API et que vous avez de solides compétences en matière de développement, RestAssured ou Postman pourrait être une option.    Compétence : Évaluez les compétences organisationnelles existantes avant de choisir un outil, en tenant compte des facteurs culturels tels que les plateformes et les outils de développement.    Compatibilité : Le choix d'un outil compatible avec la technologie existante dans l'organisation est crucial.    L'automatisation des tests est indéniablement un élément stratégique dans le paysage moderne du développement. Dans cet article, nous encourageons une approche de mise en œuvre progressive, en mettant l'accent sur la valeur ajoutée, l'engagement organisationnel et la collaboration à différents niveaux. Lors de la sélection des outils d'automatisation, établissez des priorités en fonction des besoins spécifiques de votre projet en matière de tests. En adoptant ces principes, vous pourrez relever les défis de manière transparente et améliorer de manière significative l'efficacité, la rapidité et la qualité de vos processus de développement logiciel. Vous bénéficiez ainsi d'un avantage concurrentiel qui vous permet de répondre aux demandes de mise sur le marché dans des délais courts. 

Lorsqu’on écrit des tests automatisés, on veut ajouter le maximum de valeur avec le moins de coût ou de temps possible. Le nombre total de cas de test pour vérifier qu'un grand système moderne complexe ne comporte pas d'erreurs est presque infini. « Tout » ne peut pas être automatisé. Dans cet article, nous examinons de plus près ce qui ne peut/doit pas être automatisé et pourquoi.    On doit penser stratégiquement pour sélectionner un nombre limité de tests à automatiser. Ces tests doivent couvrir la plus grande partie possible du système, être simples à mettre en œuvre, stables et fiables, et peu coûteux à modifier et à maintenir.    L'automatisation des tests consiste à rationaliser certaines parties du travail de test, du moins les parties les plus appropriées. Par conséquent, il existe certaines catégories de tests que nous ne devrions pas automatiser.    Tests faisant appel à l'intelligence et à l'émotion   Un ordinateur est totalement dépourvu d'intelligence, de goût et de sentiment. Il n'est donc pas possible de créer de bons tests automatisés pour évaluer des éléments tels que les suivants :   La mise en page est-elle intuitive ?  L'expérience de l'utilisateur est-elle agréable ?  L'utilisation de l'application est-elle ergonomique ?  Est-il facile de comprendre comment utiliser le système ?  L'interface utilisateur est-elle visuellement attrayante ?    Ne perdez pas de temps et d'énergie à essayer de vérifier ne serait-ce qu'une partie de ces aspects. Un ordinateur n'a pas la capacité d'évaluer ces aspects. Les tests deviennent complexes et peu fiables et ne peuvent, même en théorie, vérifier qu'une fraction négligeable de ce que nous souhaitons.    Applications qui ne sont pas encore stables (trop tôt dans le cycle de vie)   Les tests qui interagissent avec l'application via l'interface utilisateur graphique (GUI) sont très sensibles aux changements. Des modifications apparemment minimes de l'interface utilisateur de l'application entraînent l'arrêt des tests. Par conséquent, ce n'est pas une bonne idée d'automatiser des tests avec une application qui n'est pas encore stable. Le fait qu'elle ne soit pas stable signifie qu'elle sera changée, modifiée ou corrigée, ce qui entraînera l'arrêt des tests.    Les tests qui interagissent avec l'application via l'interface utilisateur graphique sont, par rapport à d'autres types de tests automatisés, complexes, volumineux, longs et difficiles à modifier. Par conséquent, il est préférable d'attendre que le système ait commencé à se stabiliser et qu'aucun changement perturbateur ne soit prévu avant de mettre en œuvre ces types de tests.    Applications que l'outil a du mal à prendre en charge (API, GUI)   Nous rencontrons parfois des composants ou des parties d'un système pour lesquels il est très difficile de mettre en œuvre des tests automatisés. Cela peut être dû à plusieurs raisons. Un exemple est la sécurité où le but est d'éviter les bots ou les manipulations automatisées non désirées. Un autre exemple est celui des composants propriétaires dont les détails d'implémentation sont inconnus ou secrets.    La mise en œuvre de solutions créatives (souvent complexes) pour contourner le problème est généralement une mauvaise idée à long terme. Les tests deviennent erratiques et complexes. Ne passez donc pas un temps disproportionné à vous débattre avec des tests dans des situations presque impossibles où les résultats seront médiocres.    Consacrez plutôt votre temps et votre énergie dans la mise en œuvre de tests automatisés dans les domaines où cela est à la fois faisable et susceptible de porter ses fruits. Ce qui est utile et précieux, ce sont les tests qui s'exécutent rapidement, qui sont fiables, robustes, faciles à modifier et à entretenir.    Cas de test qui ne se sont pas bien déroulés manuellement   Si les tests manuels n'ont pas été concluants, cela suggère que l'application n'est pas encore totalement stable. Même de légères modifications de l'interface utilisateur entraînent des défaillances dans les tests. Ainsi, il est déconseillé d'opter pour des tests automatiques via l'interface utilisateur graphique (GUI) pour une application dont les tests manuels ne se sont pas révélés satisfaisants.    D'un autre côté, cela ne s'applique pas aux tests automatisés via une API (par exemple, des services Web tels que REST ou SOAP). En effet, les tests automatisés via une API sont, comparativement aux tests automatisés via une interface graphique, triviaux, courts et rapides à mettre en œuvre et faciles à modifier.    Si nous pouvons tester le système via l'API au début du cycle de développement, c'est une bonne idée de commencer à mettre en œuvre des tests exhaustifs à ce niveau. Lorsque le système a commencé à se stabiliser et qu'il ne faut plus s'attendre à des changements révolutionnaires, il est très efficace de compléter par un plus petit nombre de tests automatisés via l'interface utilisateur graphique de l'application.    Il manque des informations sur le fonctionnement du système et un soutien à l'ingénieur chargé de l'automatisation des tests.   La méthode la plus efficace consiste à mettre en œuvre les tests automatisés parallèlement à la mise en œuvre du système. Les tests automatisés doivent se situer à un niveau d'automatisation aussi bas que possible (niveau du dispositif, niveau de l'API, niveau de l'interface graphique) afin de détecter les défauts le plus près possible de la source (là où ils se produisent).    L'automatisation des tests au niveau de l'interface graphique intervient relativement tard dans la chaîne de développement. On souhaite que le développement du système se soit stabilisé et qu'aucun changement ou remaniement radical ne soit attendu. Ceci, comme mentionné ci-dessus, est dû à la complexité et à la taille de ces tests, ainsi qu'au coût et au temps des modifications et de la maintenance.    Il est essentiel que les personnes en charge des tests automatisés aient une connaissance approfondie du fonctionnement du système. En l'absence de ces connaissances, et si l'équipe, l'organisation, ou toute autre personne ne peut pas transmettre ces informations, la création de tests automatisés significatifs devient extrêmement complexe.

Dans le monde numérique d'aujourd'hui, il est de plus en plus important de veiller à ce que les informations agrégées de votre entreprise ne puissent pas être trouvées et prises par d'autres. C'est pourquoi vous devez travailler en permanence à l'amélioration de la sécurité en effectuant des tests pour déterminer s'il existe des vulnérabilités. Nous savons que la sécurité de l'information peut être délicate. C'est pourquoi, dans cet article, j'expliquerai la différence entre l'analyse de la vulnérabilité et les tests d'intrusion. J'espère qu'il vous permettra de mieux comprendre ces tests et leur importance pour votre entreprise.   Analyses de vulnérabilité   L'analyse des vulnérabilités est entièrement automatisée, il vous suffit d'ajouter les actifs à analyser. Vous indiquez au système ce qu'il doit rechercher et tout se passe automatiquement. En effectuant régulièrement des analyses de vulnérabilité, vous avez une bonne vue d'ensemble de votre niveau de maturité, par exemple à chaque publication. Si vous publiez des versions toutes les semaines, il peut être judicieux d'investir dans un outil d'analyse des vulnérabilités dynamique ou statique.   Dans l'analyse des vulnérabilités, le système recherche activement des défauts de configuration ou des vulnérabilités sur la base de déficiences ou d'erreurs réelles dans le logiciel, le serveur, le client, le commutateur, le routeur, etc. Il s'agit souvent d'un problème fondamental dans le code, soit que vous ayez fait quelque chose sans le savoir, soit que vous ayez omis quelque chose, par exemple dans la configuration.   Le plus grand avantage d'une analyse automatisée est qu'elle permet de repérer un grand nombre de problèmes mineurs, tels qu'une authentification défaillante, des scripts inter-sites (XSS) ou d'autres types d'injections. C'est un bon début.   Des exemples des vulnérabilités les plus courantes dans les applications web peuvent être trouvés, entre autres, sur le site suivant : OWASP (Open Web Application Security Project) top 10 list ou sur le site Sans Top 25.   Test d'intrusion   Le test d'intrusion, également appelé "pen testing", est un travail manuel. Il s'agit d'aller plus loin que la simple vérification des vulnérabilités existantes. Avec un test d'intrusion, vous allez plus loin dans le système pour voir les connexions et acquérir une compréhension plus profonde de la logique d'entreprise. Lorsque vous comprenez l'état d'esprit du développement et des ensembles de solutions, vous trouverez probablement d'autres failles, car le facteur humain ne peut jamais être ignoré. Nous savons que les gens font des erreurs lorsqu'il s'agit d'installer, de développer et de gérer des systèmes. Cette information ne pourrait jamais être récupérée par un outil d'analyse automatisé, car il ne dispose pas de la pensée rationnelle que nous avons en tant qu'êtres humains.   Le contrôle d'accès en est un exemple. Un outil d'analyse automatisée des applications web ne peut pas déterminer si les données auxquelles il peut accéder sont considérées comme une violation de la sécurité ou non. Si un "utilisateur standard" peut accéder à des informations auxquelles seul un administrateur devrait pouvoir accéder, les contrôles d'accès sont insuffisants. Un humain peut le déterminer en analysant les données et ce qui se passe.   Exemple d'un cas réel :   "Dans le cadre d'une de nos missions précédentes, nous avons effectué des tests sur une application web accessible sur Internet et nous avons trouvé un certain nombre de vulnérabilités, notamment une injection SQL non authentifiée. Cette vulnérabilité permettait de lire les données de la base de données, telles que les utilisateurs et les hachages. Après une analyse plus approfondie, il s'est avéré que les hachages avaient été altérés et, une fois que nous avons compris comment, nous avons pu craquer les mots de passe, nous connecter à l'application web, télécharger des fichiers et exécuter du code sur leur serveur web.   À partir du serveur web, nous avons obtenu un accès complet à l'ensemble du réseau de production, ce qui a permis l'accès aux contrôleurs de domaine. L'un d'entre eux présentait plusieurs vulnérabilités et, bien qu'il ait été remplacé par un nouveau contrôleur de domaine et un nouveau domaine, il était toujours utilisé pour l'ancien domaine. L'ancien et le nouveau domaine bénéficiaient d'une confiance réciproque, ce qui signifie que même si vous disposez d'un compte dans un domaine, vous avez accès aux ressources de l'autre domaine. En raison d'une combinaison de mauvaises configurations, d'erreurs logicielles, d'un manque de séparation logique entre les systèmes internes et externes, ainsi que du fait que le client n'a pas complètement mis hors service l'ancien domaine, nous avons pu pénétrer aussi loin dans le réseau et les systèmes de l'entreprise."   Si vous n'aviez procédé qu'à une analyse des vulnérabilités de l'application et non à des tests de pénétration, vous auriez au mieux découvert une injection SQL, mais pas les autres failles.   Les problèmes récurrents constatés au sein des entreprises   Un problème courant au sein des entreprises est qu'elles ne considèrent ces tests que comme faisant partie d'un processus basé sur des exigences telles que PCI-DSS ou GDPR. Une fois que l'entreprise a surmonté ses marques rouges (haut risque) et violettes (critique) dans son rapport, elle considère que le travail est terminé. L'utilisation des résultats n'est pas considérée comme importante, l'accent étant mis sur la vérification des exigences.   Il est dangereux de se contenter d'effectuer une analyse des vulnérabilités ou des tests d'intrusion avec une sorte d'"approche par cases à cocher". Le fait est que, dans de nombreux cas, les environnements sont généralement les mêmes l'année suivante et que les mêmes vulnérabilités et erreurs de configuration existent toujours. Les mêmes tests sont effectués et révèlent les mêmes vulnérabilités, ce qui signifie que le niveau de maturité augmente de 0 %. Comme dans l'exemple de l'application web ci-dessus, si l'entreprise s'était contentée d'effectuer les tests sans agir sur les résultats, cela aurait pu mal se terminer.   Une meilleure communication et une meilleure compréhension des tests et des résultats pourraient résoudre ce problème. La sécurité n'est pas facile à comprendre, c'est pourquoi il est d'autant plus important de s'assurer que les rapports sont correctement examinés et de se faire aider pour en clarifier le contenu. Si vous ne comprenez pas la signification des résultats, il est difficile de prendre des mesures.   Le risque de ne pas effectuer d'analyse de vulnérabilité ou de test d'intrusion   Si vous n'avez pas une vision claire de la sécurité dans vos différents systèmes, vous ne savez pas non plus quelles sont les vulnérabilités existantes et jusqu'où une personne extérieure peut pénétrer dans les systèmes. Tant que cette image n'est pas claire, vous risquez toujours d'être exposé à des infractions. Cela peut entraîner des pertes extrêmement coûteuses pour votre entreprise. Non seulement en termes d'argent, mais aussi en termes de réputation et de travail pour réparer les dégâts. Oserez-vous vraiment prendre ce risque ?   Pour résumer   Pour simplifier, on peut considérer l'analyse de la vulnérabilité comme le premier niveau et les tests de pénétration comme le suivant. L'analyse est le précurseur des tests d'intrusion, sans l'aspect humain. Il sert de base et met en évidence les vulnérabilités connues existantes. Après le travail de base, il faut aller plus loin pour comprendre comment les développeurs et l'administration configurent les systèmes, voient les connexions et s'assurent qu'il n'y a pas de portes cachées.   Si votre travail de sécurité est aujourd'hui déficient et que vous ne contrôlez pas ce que vous exposez à l'internet, vous courez un risque plus élevé que des personnes ayant l'intention de prendre le contrôle de votre infrastructure ou de s'emparer de vos données obtiennent un accès non autorisé. Il est donc important d'effectuer des tests en permanence et d'agir en fonction des résultats de ces tests. Ne considérez plus cela comme une exigence à mettre en œuvre, mais comme un effort à long terme en vue d'un système et d'un environnement plus sûrs.   Comme nous l'avons dit, nous savons qu'il peut être difficile de tout maîtriser en matière de sécurité informatique. C'est pourquoi nous avons mis en place un webinar focusing on application security where we will delve into key areas such as how to bring security into the development process, what the most common attacks are and when to choose open source. Inscrivez vous en cliquant sur l'image ci-dessous.

Dans le monde complexe des tests de logiciels, où l'objectif ultime est d'assurer la qualité et la fiabilité d'une application, deux éléments essentiels se démarquent : les cas de test et les scénarios de test.   Ils jouent un rôle fondamental dans le processus de test, permettant aux testeurs de vérifier de manière méthodique si le logiciel répond aux normes requises et fonctionne conformément aux attentes.   Pourtant, malgré leur importance capitale, ces deux piliers de la documentation de test sont souvent sujets à confusion. Dans cet article, nous allons examiner de près les nuances entre les cas de test et les scénarios de test, en explorant leurs définitions, leurs objectifs et leurs distinctions.     Qu'est-ce qu'un scénario de test ?   Un scénario de test offre une vue d'ensemble de haut niveau d'une situation de test spécifique. Il décrit le contexte dans lequel les tests seront effectués, en détaillant les objectifs, les prérequis et les résultats attendus de l'effort de test. En d'autres termes, il précise ce qui doit être testé, en délimitant les étapes complètes qu'un testeur suivrait pour s'assurer du bon fonctionnement d'une application.   Les scénarios de test sont conçus pour simuler les expériences réelles des utilisateurs. Par exemple, lorsque l'on teste le processus d'achat d'un billet d'avion, un scénario de test englobe toutes les étapes, depuis la sélection du vol jusqu'à la fin de la transaction de paiement.   L'objectif principal des scénarios de test est de garantir une couverture complète des fonctionnalités du logiciel, permettant ainsi aux testeurs de vérifier l'intégration et l'interaction harmonieuse des différentes fonctionnalités et composants.     Qu'est-ce qu'un cas de test ?   Contrairement aux scénarios de test, les cas de test agissent comme des instructions détaillées visant à examiner les fonctionnalités spécifiques du logiciel dans divers scénarios. Grâce à ces cas, les testeurs peuvent évaluer la conformité de l'application à ses spécifications. Ils permettent de déterminer ce qui doit être testé et comment le faire. Reprenons notre exemple du processus d'achat d'un billet d'avion : les cas de test pour cette fonctionnalité couvriraient des actions telles que naviguer jusqu'à la page de réservation, saisir les détails du voyage, sélectionner un vol, fournir les informations de paiement et finaliser la réservation.   Autre exemple, celui de l'inscription d'un nouvel utilisateur sur un site web : les cas de test consisteraient à naviguer jusqu'à la page d'inscription, à entrer les coordonnées de l'utilisateur, à vérifier la réception du courrier électronique de confirmation, et enfin à se connecter en utilisant les informations d'identification nouvellement créées.   Parmi les éléments clés d'un cas de test, on retrouve :   L'ID du cas de test, La description, Les données de test, Les étapes à suivre pour les tests, La priorité / sévérité du test, Les résultats attendus, Les résultats réellement observés.     Les cas de test visent principalement à aider les testeurs à repérer les défauts ou les bugs dans des aspects spécifiques d'une application et à garantir la précision des fonctionnalités individuelles. Ils constituent une composante essentielle des tests logiciel, offrant une couverture exhaustive du système. Cette approche permet aux clients de comprendre le comportement du produit et de localiser les éventuels défauts, ce qui guide efficacement leur attention et leurs efforts.     Quelles sont les principales différences ?   Pour mieux saisir la distinction entre les cas de test et les scénarios de test, prenons une analogie dans le domaine du cinéma. Un scénario de film équivaut à l'ensemble de l'intrigue et au thème global d'un film, détaillant la séquence des événements, les motivations des personnages et les moments-clés de l'histoire. De manière similaire, un scénario de test offre une vue d'ensemble des objectifs, des conditions préalables et des résultats escomptés du test, posant ainsi les fondations pour l'ensemble du processus de test.   En revanche, un script de film se concentre sur l'exécution détaillée du scénario, en fournissant des instructions spécifiques pour chaque scène, dialogue et séquence d'action. De la même manière, un cas de test décompose le scénario de test en étapes précises, en spécifiant les actions à effectuer, les données à utiliser et les résultats attendus à valider.   Parmi les différences, on peut citer :   Champ d'application : Les cas de test ciblent des fonctionnalités, des entrées ou des conditions spécifiques, tandis que les scénarios de test ont un champ d'application plus large couvrant plusieurs fonctionnalités ou cas d'utilisation.   Focus : Les cas de test définissent généralement ce qu'il faut tester et comment le faire, en fournissant des procédures de vérification étape par étape. Les scénarios de test identifient principalement ce qu'il faut tester, en mettant en évidence des aspects spécifiques du logiciel à évaluer.   Sources : Les cas de test découlent des scénarios de test, tandis que ces derniers sont élaborés à partir de diverses sources documentaires telles que les user stories et les exigences. Ainsi, les scénarios de test sont conçus en premier dans le processus, servant de fondement à l'élaboration des cas de test.   Ambiguïté : Les scénarios de test sont souvent résumés en une ligne. cette concision peut parfois laisser place à des ambiguïtés et à des interprétations variées, ce qui peut rendre les cas de test vagues. À l'inverse, des cas de test détaillés réduisent au minimum cette ambiguïté et assurent aux testeurs des directives claires pour exécuter efficacement les tâches de test.   Réutilisation : Si les scénarios de test peuvent être réutilisés dans des contextes similaires ou pour des tests de régression, ils peuvent nécessiter des ajustements pour être appliqués à des situations différentes. En revanche, les scénarios de test sont plus aisément adaptables à différents projets.   Collaboration : La collaboration sur les cas de test implique une étroite coopération entre les testeurs et les développeurs pour peaufiner et valider des fonctionnalités spécifiques. Cependant, cette collaboration ne fait pas toujours intervenir toutes les parties prenantes. En revanche, les scénarios de test encouragent la contribution de divers départements et disciplines, favorisant ainsi les discussions sur les cas d'utilisation, les exigences métiers, et bien d'autres aspects.   En conclusion, bien que les cas de test et les scénarios de test représentent des approches distinctes des tests de logiciels, ils sont étroitement liés au sein du processus de test. Cette relation d'interconnexion souligne l'importance des cas et des scénarios de test pour garantir la qualité et la fiabilité des logiciels.

Le travail de testeur est un travail technique demandant des compétences particulières. Il semble donc évident que le testeur se trouve face à des challenges liés à la technicité du test ou de certaines activités.   Néanmoins, le métier de testeur, comme tout métier, ne se limite pas à de la technique pure ! C’est d’autant plus vrai dans le test où il est amené à communiquer sur les notions de qualité, de gestion des risques et de confiance avec de nombreuses personnes aux profils différents.   Dans cet article nous vous proposons des défis humains que les testeurs rencontrent fréquemment.   Intégrer une équipe Agile   Les challenges Les équipes agiles sont des équipes pluridisciplinaires en nombre réduit. Elles doivent avoir en leur sein l’ensemble des compétences pour créer le produit sur lequel elles travaillent. Cela inclut l’ensemble des compétences de test (analyse, conception, communication, automatisation…) alors que dans un grand nombre d’équipes il n’y a qu’un seul testeur… qui doit donc, sur le papier, avoir toutes ces compétences… ce qui est rarement le cas.   De même, une équipe Agile est comme son nom l’indique une « équipe ». Elle forme un groupe humain et l’intégration à tout groupe ne se fait pas forcément facilement.   Enfin, l’équipe Agile travaille sur un produit qu’elle connait généralement très bien. Arriver en cours de route nécessite une montée en compétence.   L’alliance de ces 3 points engendre de vrais défis pour un testeur qui doit se faire accepter par l’équipe d’un point de vue humain mais aussi d’un point de vue opérationnel, en étant le référent qualité et test… sur le produit spécifiquement développé.   La conjugaison de ces montées en compétence engendre parfois un rejet de l’équipe Agile qui peut considérer, au bout d’un certain temps, que le testeur n’apporte pas autant que ce qui était attendu.   Mes conseils   Il est très rare d’avoir l’ensemble des compétences nécessaires à une équipe Agile en tant que testeur. Si l’on ajoute la capacité à bien comprendre, connaitre le produit et avoir des affinités avec l’ensemble des membres de l’équipe, on arrive alors dans le domaine du totalement improbable.   Il ne faut pas oublier qu’en tant que testeur Agile on est dans une équipe. Et dans une équipe, que cela soit en Agile, dans le domaine du sport ou tout autre, on s’entraide. En tant que testeur il ne faut pas hésiter à travailler avec les autres membres (développeur, métier, ops…) et à être accompagné sur certaines tâches non maitrisées.   De même, afin de monter en compétence sur des aspects du test il est toujours intéressant d’échanger avec ses pairs à travers des communautés ou des événements dédiés au test.   Enfin, il est également important de ne pas vouloir tout révolutionner avant d’avoir bien compris le contexte de l’équipe, ses besoins, ses problèmes, ses points forts et surtout son produit. Vouloir tout changer sans avoir acquis de légitimité au sein de l’équipe est souvent synonyme de rejet mais aussi de préconisations non adaptées.   Réussir à convaincre ses interlocuteurs   Les challenges   Trouver des anomalies c’est bien. Corriger celles qui doivent l’être c’est mieux. Il en est de même pour les actions d’amélioration. Identifier celles-ci c’est bien, les mettre en place c’est mieux.   Vous avez sûrement reconnu certaines situations. Le travail de testeur ne se limite pas à identifier des défauts, évaluer un niveau de qualité ou identifier des actions d’améliorations. Il est nécessaire que ce travail permette d’avancer et s’améliorer. Malheureusement, être convaincu du bien-fondé de ses actions (ou avoir raison) ne suffit pas à convaincre ses interlocuteurs.   Mes conseils   Le test dépend du contexte, la communication envers ses différents interlocuteurs également ! Il est important de bien connaitre les personnes avec lesquelles on travaille ainsi que le produit que l’on teste afin d’être capable de trouver les bons arguments pour corriger une anomalie, initier des actions d’améliorations ou alerter sur un niveau de qualité insuffisant.   De même, la communication envers des personnes techniques (ex : développeurs de l’équipe) ou fonctionnelles (ex : PO, chef de projet…) se doit d’être différente car les attentes et les objectifs ne sont pas les mêmes.   Attention, il est aussi important de savoir identifier quand une bataille est « perdue d’avance » afin de ne pas s’épuiser. Implémenter une stratégie de test peut avoir de la valeur… Mais si l’on n’arrive pas à convaincre les membres de son équipe cela peut être lié au fait que l’équipe n’en ressent pas encore le besoin ou qu’il y a d’autres sujets plus prioritaires.   Constamment se remettre en question   Les challenges   Il est aisé de vouloir remettre en place des techniques et stratégies ou approches de test qui ont fonctionné dans nos contextes précédents. De vouloir utiliser des outils que l’on maitrise bien et qui nous sont familiers.   Malheureusement cette approche connait vite ses limites car les tests dépendent du contexte et que ce contexte dépend des logiciels sur lesquels ont travail mais aussi du temps alloué. Ainsi, même si l’on continue à travailler dans une même équipe et sur un même produit, les approches de test, au même titre que les tests s’usent (paradoxe du pesticide).   Afin d’éviter une détérioration de la qualité il est alors essentiel de se challenger régulièrement et de se remettre en question afin d’évoluer avec le contexte.   Mes conseils   Il est important de bien connaitre la production, de faire évoluer ses campagnes, d’échanger avec les membres de son équipe et ses pairs afin d’identifier de potentielles faiblesses ou des axes d’améliorations.   En fait, il faut rester curieux et avoir une envie constante d’avancer. Rien n’est jamais acquis… et c’est d’ailleurs cela qui rend le métier de testeur passionnant… et non automatisable !   Communiquer sur un niveau de qualité   Les challenges   Définir un niveau de qualité est quelque chose de complexe. Pour cela il faut réussir à bien définir son approche de test. Malheureusement être capable de définir ce niveau est insuffisant ! Il est important pour le testeur d’être capable de faire appréhender à ses interlocuteurs ce niveau de qualité.   Pour cela les indicateurs sont un bon appui mais au final ils ne sont pas suffisants. Un testeur doit être capable de faire comprendre très rapidement les tenants et les aboutissants d’un déploiement en production. Quels sont les risques ? Quels sont les défauts connus et non corrigés ? Quel est leur impact ?   Vous pourrez constater que c’est le travail d’un livrable bien connu : le bilan ! Dans les faits il est nécessaire de bien travailler sur ce bilan mais aussi de s’entrainer à présenter succinctement et clairement les faits à l’oral pour s’assurer de cette bonne compréhension.   Mes conseils   Il est important de bien définir ses indicateurs et qu’ils soient transparents. Pour cela il faut une bonne gestion de la traçabilité. La communication doit également être adaptée à ses interlocuteurs… ce qui nous ramène au challenge « convaincre ses interlocuteurs. “   Faire accepter l'investissement dans le Test   Les challenges   Le test est généralement vu comme un centre de coûts. Même si cette vision persiste les faits montrent le contraire. Si ce n’était pas le cas les entreprises ne testeraient pas  !   Néanmoins il demeure important de faire des investissements dans le test afin de le rendre plus efficient et ceci n’est pas toujours facile. En effet le budget de construction des produits logiciels est limité et l’investissement dans le test se fait « au détriment » de potentielles fonctionnalités supplémentaires.   Mes conseils   Il est important de faire reconnaitre la « valeur du test », rappeler les apports du test qu’ils soient d’un point de vue financier ou non.   Pour le point de vue financier, il y a des indicateurs fréquents comme le coût de détection des bugs en production et en test. Ce calcul permet de calculer l’économie apportée par le test grâce à la détection des bugs. Il est également possible d’avoir des indicateurs sur le gain de temps notamment avec le % de temps passé à corriger des bugs en production.   D’un point de vue non financier, le test apporte de l’information sur la qualité pour la prise de décisions. L’information est un élément vital et même si cela ne rapporte pas directement de l’argent cela apporte de la confiance. De même le test permet d’assurer un niveau de qualité qui bénéficie à l’image de marque de l’entreprise et/ou du logiciel. Cette qualité fidélise et attire de nouveaux utilisateurs !   Pour en savoir plus sur les défis auxquels sont confrontés les testeurs, restez connectés. Je partagerai bientôt avec vous les défis techniques et quelques conseils associés.

Lorsque nous parlons de sécurité, l'une des choses qui est souvent négligée ou qui n'est pas entièrement calculée est le risque réel. Quel est le risque réel que vous courez en tant qu'entreprise ? Qu'est-ce qui a de la valeur pour vous ? Qu'est-ce que vous ne voulez pas voir divulgué, exposé ou volé ? Dans la plupart des cas, il s'agit d'informations. L'information est le bien le plus précieux que nous possédons. Et comme elle a de la valeur, elle comporte toujours un certain degré de risque.     Pour calculer le risque, vous devez d'abord savoir ce que vous possédez et ce que vous considérez comme précieux pour votre entreprise, et quelle est la valeur réelle de cet élément d'information. Il peut s'agir du coût initial que vous avez payé pour quelque chose, du temps qu'il a fallu pour le développer, de la valeur marchande future et même de ce qu'il en coûterait pour le remplacer. Un disque dur est un objet relativement bon marché, mais les informations qu'il contient peuvent potentiellement valoir des milliards, pour vous ou même pour quelqu'un d'autre.   LA MENACE COMME FACTEUR DE RISQUE   La menace est également un facteur de calcul du risque. Quelles sont les plus grandes menaces auxquelles vous êtes confronté ? Elles vont des catastrophes naturelles à l'espionnage d'entreprise, en passant par les espions, les employés mécontents... En gros, si vous exercez une activité qui consiste à fournir quelque chose que quelqu'un veut, il y a de fortes chances que quelqu'un d'autre veuille savoir ce que vous savez ou posséder ce que vous possédez. Les menaces sont les éléments qui causeront des dommages à votre organisation.   Les vulnérabilités sont le point d'entrée dans l'organisation ou permettent d'accéder à des informations de valeur. En ce qui concerne la sécurité informatique, les vulnérabilités peuvent être l'exposition sur l'internet, l'accès facile au réseau de l'entreprise, ou des machines clientes et des serveurs compromis. Mais les vulnérabilités comprennent également le fait de ne pas contrôler toutes les personnes entrant dans le bâtiment, les entrées latérales non verrouillées ou non surveillées, la perte ou l'abandon d'informations, ou même une soirée en ville avec les cadres. Ne négligez jamais l'erreur humaine et l'ego. Les personnes ivres aiment parler et ne sont pas toujours conscientes de leur environnement. Vous ne savez jamais quand quelqu'un peut écouter vos conversations ou fouiller dans les poches du manteau que vous avez enregistré au vestiaire.   Exemple inventé :   L'entreprise X est une grande entreprise mondiale. Elle possède des bureaux et des usines répartis dans le monde entier. Elle s'est développée très rapidement et n'a pas mis à jour sa sécurité (vilain vilain...). Elle possède bien sûr des informations que quelqu'un d'autre pourrait vouloir obtenir, mais elle est aussi une cible comme toute autre entreprise, simplement parce qu'elle existe. Que se passerait-il si une petite partie de leur activité tombait en panne ? Disons une région où elle fabrique le produit Z. Combien de personnes seraient touchées ? Quels seraient les coûts ? Peut-on chiffrer cette attaque ? Oui, nous le pouvons.   Cette attaque hypothétique a frappé la région avec un bon vieux casier cryptographique qui a été introduit par une campagne de phishing ciblée et qui s'est appuyé sur des systèmes obsolètes auxquels il manque des correctifs de sécurité indispensables. Le premier coût que nous examinons est la perte de production de tout ce qui est fabriqué. Supposons que leur production journalière s'élève à 1 000 000 € et qu'ils sont restés inactifs pendant deux semaines ! Cela représente une perte de 10 à 14 millions d'euros (en fonction des week-ends de congé). Et comme ils ont pris du retard, ils devront peut-être augmenter leur production pour rattraper ce retard lorsqu'ils redémarreront. Mais ce n'est pas le seul coût. Il y aura sans aucun doute des personnes qui travailleront jour et nuit pour arrêter l'attaque, essayer de la réparer et comprendre ce qui a mal tourné. Disons qu'une centaine de personnes ont travaillé d'arrache-pied pendant un mois pour contenir et réparer l'attaque afin que la production puisse reprendre. 100 personnes avec un coût moyen (estimons-le) de 50 €/heure pour l'entreprise, à raison de 10 heures par jour. Cela représente un coût supplémentaire de 1 500 000 euros ! Rien que pour les personnes qui tentent de contenir l'incident. D'autres coûts pourraient inclure le remplacement de l'équipement qui aurait pu être endommagé.   COÛTS CACHÉS   Il existe également quelques coûts cachés auxquels on ne pense pas immédiatement. Avant que les attaquants ne lâchent le crypto-monayeur, ont-ils également volé des données ? Il est possible qu'ils aient également volé des informations précieuses. S'agit-il d'un concurrent qui connaît désormais vos secrets ? Ou de quelqu'un qui les vend à vos concurrents ? Cela pourrait vous faire perdre des marchés lorsque quelqu'un propose votre produit à un prix légèrement réduit.   L'autre coût caché est la dégradation de la marque. Si l'incident fait la une des journaux, les clients risquent de se désintéresser de l'entreprise et de ne plus acheter ce qu'elle essaie de vendre. Il pourrait s'agir de la situation la plus difficile à surmonter.   Compte tenu de ce scénario terrifiant, qu'aurait-on pu faire pour contrer ce phénomène et combien cela aurait-il coûté ? Pour faire vite, il aurait fallu mettre à jour et corriger les systèmes, filtrer les courriels et former les utilisateurs à la sécurité. Supposons que cela leur coûterait 2 000 000 d'euros supplémentaires par an en ressources, logiciels et équipements pour limiter l'attaque à un niveau raisonnable. Cela ne représente que 166 666 euros par mois. Si l'on considère que leurs pertes ont dépassé les 15 000 000 d'euros en un mois, c'est un petit prix à payer pour la prévention.   Pour plus de ressources sur ce sujet, veuillez lire le livre d'Ira Winkler "Des espions parmi les États-Unis". L'équation d'Ira donne une valeur monétaire au risque, ce qui en fait un bon facteur de motivation. Ou encore le livre de Tony UcedaVelez "Risk Centric Threat Modeling“. En résumé, les entreprises devraient se concentrer davantage sur leur risque réel et lui attribuer une valeur monétaire. Il est beaucoup trop fréquent que des incidents tels que l'exemple ci-dessus se produisent. Les coûts peuvent être et ont été considérables. Mais avec un peu de planification de la prévention, beaucoup de ces incidents peuvent être réduits de manière drastique. Certaines choses se produiront toujours, et il est impossible de prévenir toutes les attaques, mais il existe de nombreux moyens de les détecter à temps et de les arrêter avant qu'elles ne deviennent trop graves.   Les seules personnes qui prétendent pouvoir vous assurer une sécurité totale sont des imbéciles ou des menteurs". Ira Winkler - Les espions parmi nous   Si vous souhaitez en savoir plus sur la sécurité des applications, rejoignez-nous pour un webinaire au cours duquel nous aborderons des domaines clés tels que la manière d'intégrer la sécurité dans le processus de développement, les attaques les plus courantes et le choix de l'open source. Inscrivez-vous ci-dessous en cliquant sur l'image

Trouver l'outil d'automatisation des tests parfait pour votre logiciel n'est pas une tâche facile. Nous devons tout d'abord accepter que chaque logiciel est unique et qu'il a sa propre façon d'être livré. Le type d'outils d'automatisation nécessaires pour s'adapter au cycle de vie des tests de logiciels dépend fortement des ressources, de l'équipe et de la stratégie. Il n'existe donc pas de meilleur outil d'automatisation des tests. Il existe cependant une série d'outils populaires qui sont actuellement à la mode et qui sont conçus pour s'adapter facilement à votre projet. Selenium, Appium, Katalon Studio, Cypress et Playwright sont quelques exemples d'outils d'automatisation populaires utilisés à la fois dans des systèmes simples et complexes, afin de fournir une qualité de test fiable et précise.      Aujourd'hui, nous allons mettre en lumière un outil de plus en plus populaire qui s'avère également être un des plus récents : Playwright.    Comme tout testeur, j'ai été confronté à certains défis dans mes projets précédents qui ont ralenti le processus d'automatisation du frontend. L'écriture d'un code de base excessif pour configurer les navigateurs, des exécutions de tests lentes, des temps d'attente peu fiables, des difficultés à trouver les sélecteurs et des tests bancals, pour n'en citer que quelques-uns. Ce n'est que lorsqu'un de mes collègues m'a présenté Playwright que le monde de l'automatisation s'est éclairci pour moi.      Qu'est-ce que Playwright ?   Playwright est un framework d'automatisation des tests de bout en bout à code source ouvert, issu de Puppeteer, qui est basé sur node.js et maintenu par Microsoft.       Dans l'architecture traditionnelle de Selenium, chaque requête HTTP est envoyée séparément et reçoit une réponse JSON, ce qui entraîne une communication en va-et-vient qui ralentit l'ensemble du processus. Playwright, en revanche, utilise une API unique.    It uses a single WebSocket to communicate with all drivers.  This is why Playwright is revealing its identity as being one of the fastest and easiest automation frameworks in the software testing world. Fast and easy = Playwright. So how accurate is it?  After reading this article, you will get a feel of whether this framework may be reliable enough to use for the software you are working on.       Pourquoi utiliser Playwright ?   Honnêtement, pour moi, c'était le framework le plus facile à mettre en place. Une commande One liner met en place votre environnement d'automatisation, et vous pouvez commencer à automatiser.      L'une des raisons pour lesquelles les équipes logicielles ont changé leur cadre d'automatisation pour Playwright est qu'il prend en charge de nombreux langages tels que JavaScript, Java, Python et .NET C#. De plus, une gamme variée d'outils d'exécution de tests est prise en charge : Mocha, Jest, Jasmine, Cucumber. L'aspect le plus intéressant de l'exécution des tests Playwright est qu'il s'agit de navigateurs sans tête avec une architecture pilotée par les événements.      Comment l'installer ?   Playwright est compatible avec tous les systèmes d'exploitation modernes (Windows, Mac et Linux) :    Node JS  Visual Studio Code      Créez un dossier dans votre système d'exploitation, par exemple LEARN-PLAYWRIGHT, et ouvrez le dossier dans VS Code. Exécutez le répertoire racine du projet à l'aide de la commande suivante,    npm init playwright@latest      Voici à quoi ressemble la structure des dossiers d'un projet playwright typique. Un exemple de structure de projet de test vous est fourni avec un simple qui comprend toutes les conditions préalables à la création d'une spécification de test. Dans l'exemple suivant, j'ai choisi le langage Typescript, c'est pourquoi les noms de fichiers sont en ts.         Le fichier playwright.config.ts contient la section intitulée projects, qui spécifie le processus que nous allons tester. C'est ici que vous pouvez configurer le navigateur, le contexte et les fixtures de page. Vous pouvez spécifier des options globalement ou localement, et activer l'enregistrement ou la capture de tests.   Voici les navigateurs qui seront utilisés par défaut. Les tests seront exécutés sous Chromium, Firefox et WebKit (Safari).   // playwright.config.tsimport { defineConfig, devices } from '@playwright/test';export default defineConfig({ projects: [   {     name: 'chromium',     use: { ...devices['Desktop Chrome'] },   },   {     name: 'firefox',     use: { ...devices['Desktop Firefox'] },   },   {     name: 'webkit',     use: { ...devices['Desktop Safari'] },   }, ],}); Les exemples de tests qui seront exécutés se trouvent dans le fichier appelé example.spec.ts.   Playwright vous fournit le fichier JSON qui utilise "test" comme script pour l'exécution des tests.   Voici à quoi ressemble un fichier JSON standard.   { "name": "LEARN-PLAYWRIGHT", "version": "1.0.0", "description": "", "main": "index.js", "scripts": {   "test": "echo \"Error: no test specified\" && exit 1" }, "keywords": [], "author": "", "license": "ISC", "devDependencies": {   "@playwright/test": "^1.16.3" }} Une caractéristique importante de Playwright est qu'il exécute, par défaut, tous les tests sans tête. Pour modifier ce comportement, utilisez headless : false comme option de lancement dans le fichier de configuration.     import { defineConfig } from '@playwright/test';export default defineConfig({ use: {   headless: false,   viewport: { width: 1280, height: 720 },   ignoreHTTPSErrors: true,   video: 'on-first-retry', },}); Exécution de votre exemple de test et compatibilité des navigateurs   Playwright est compatible avec tous les navigateurs modernes, notamment Microsoft Edge (Chromium), Apple Safari (avec Webkit), Mozilla Firefox et Chrome. Il permet d'exécuter plusieurs tests en parallèle, ce qui est le paramètre par défaut. Un autre facteur qui accélère le temps d'exécution.   Exécutez votre premier exemple de test à l'aide de la commande ci-dessous.   npx playwright test La commande d'exécution des tests est la suivante   npx playwright test --headed Si vous souhaitez lancer un navigateur à tête avec npm user :   npm run test -- --headed.  Si vous voulez exécuter un seul projet, disons chromium, vous pouvez commander   npx playwright test --project=chromium   Et il ne fonctionnera que sous chrome.   Lors de l'exécution, les tests ont attente automatique d'avoir les contrôles disponibles, de sorte qu'il n'est pas nécessaire d'ajouter un temps d'attente/sommeil supplémentaire pour une action.    Comme nous testons trois navigateurs différents, Playwright divise automatiquement le test en trois tâches distinctes. Une fois le test terminé, il génère les résultats dans un dossier appelé playwright report.   Conseils pour l'écriture des tests   Comme je l'ai mentionné précédemment, il faut peu de temps pour commencer à écrire des scripts de test dans Playwright, étant donné que le fichier de test d'exemple vous donne déjà un format propre et structuré. Vous pouvez simplement remplacer vos scripts personnels pour commencer. Plus tard, vous pourrez améliorer la structure de votre code pour le rendre plus propre et plus orienté objet.   test.describe('navigate to website', () => { test('navigate to website', async ({ page }) => {   // Navigate to base url   await page.goto('https://qestit.com/');   }) }); Une manière rapide de localiser les sélecteurs et les iframes   Utilisez la méthode "page.waitForSelector()" pour attendre l'apparition d'un élément sur la page. Cette méthode prend un sélecteur en argument et renvoie une promesse qui se résout lorsque l'élément est trouvé. Une fois que vous avez identifié le sélecteur de l'élément avec lequel vous souhaitez interagir, vous pouvez utiliser la méthode "page.click()" pour interagir avec l'élément.   Lors de l'exécution dans le navigateur principal, appeler page.pause() de votre script. L'utilisation d'une méthode page.pause() est un moyen simple d'interrompre l'exécution du script Playwright et d'inspecter la page dans les outils du développeur. Elle ouvrira également l'inspecteur Playwright pour faciliter le débogage.   Playwright est également bien connu pour sa gestion de la navigation entre différentes pages, par exemple les iframes et les différents onglets. Il s'agit d'un moyen fiable de vérifier que le contenu correct est affiché à l'emplacement actuel, en évitant les faux positifs/négatifs.      Débogage facile   Il s'agit de tout décomposer. Le dépannage est rendu plus convivial en décomposant visuellement les lignes avec le débogueur de Playwright. Ajoutez des points d'arrêt, exécutez le test en mode débogage et le test en cours d'exécution s'arrêtera au point d'arrêt et vous montrera la situation. Playwright dispose d'un mode strict - ainsi, s'il y a des sélecteurs similaires, le test est interrompu et il échoue quelques étapes avant l'échec réel.    Extension Codegen : Rédiger un test à partir de zéro sans écrire de code.   Codegen pour les testeurs est comme le copilote GitHub pour les développeurs. Il génère vos interactions utilisateur en code. Codegen est un générateur de code qui vous permet de créer immédiatement vos scripts de test avec précision pendant que vous effectuez les actions dans votre navigateur.    Par exemple, si vous souhaitez automatiser un cas de test dans une page, exécutez la commande suivante :   npx playwright codegen qestit.com   Il permet de réduire le temps de codage consacré à l'écriture de scripts à un simple clic. Une fois que votre code est prêt, vous le copiez et le collez dans votre classe de test. Cela accélère la mise en œuvre et l'exécution !      Extensions qui accélèrent l'identification des sélecteurs et le débogage :   Avec l'extension Playwright Test for VS Code, vous n'avez même pas besoin de taper des commandes. Cette extension simplifie l'identification des sélecteurs en survolant simplement l'élément et en laissant le localisateur s'écrire pour vous. Il vous suffit de cliquer, d'entrer, de copier et de coller.   Installer l'extension :     2. Allez au cas de test dans votre explorateur de test, 3. Cliquez sur "pick locator" 4. Cochez "afficher le navigateur"     5. Survolez l'élément que vous avez du mal à localiser, cliquez dessus et le localisateur apparaîtra sur votre éditeur.     Rapports avec fichiers traces interactifs   Playwright, par défaut, est livré avec de nombreux reporters de qualité tels que les reporters List, Dot, Line, JSON, JUnit et HTML.   La commande permettant d'obtenir les rapports de test est npx playwright show-report. Elle affiche un rapport propre dans un navigateur où vous pouvez développer ou minimiser chaque étape pour voir où l'erreur s'est produite si un test échoue.      Playwright crée également des fichiers de trace. Il s'agit de fichiers zip qui vous montrent la chronologie et les actions effectuées pour le test. Il s'agit simplement d'un instantané du DOM (avec lequel vous pouvez interagir). Maintenant, lorsque vous exécutez la commande show report, vous obtiendrez votre rapport interactif.   Les traces sont exécutées normalement dans un environnement CI, mais vous pouvez également exécuter une trace localement à l'aide de la commande suivante :   npx playwright test --trace on Pour ouvrir le rapport, exécutez :  npx playwright show-report   Facile à intégrer   Les méthodes d'intégration continue étant de plus en plus répandues, Playwright peut facilement être intégré aux pipelines CI/CD dans les outils CI. Playwright peut également s'intégrer à l'environnement Docker et à Selenium Grid.    Inconvénients   La communauté de Playwright est encore assez restreinte. Il n'est pas aussi complexe que les autres frameworks d'automatisation des tests, ce qui signifie qu'il peut y avoir des problèmes inconnus qui n'ont pas encore été rencontrés. Avec le temps, cependant, la documentation des solutions et des mesures d'atténuation évoluera.   Un autre inconvénient est qu'il ne prend pas en charge les appareils réels pour les tests de navigateur mobile, contrairement à Cypress par exemple, mais qu'il prend en charge uniquement les émulateurs.   Playwright dispose d'une capacité de test des composants qui n'est pas encore totalement stable. Il s'agit d'un travail en cours. Le cadre dispose toutefois d'une communauté active et énergique qui s'efforce d'apporter les meilleures améliorations possibles.    Conclusion   Plusieurs professionnels de l'informatique dans le monde ont exprimé le fait que l'automatisation des tests est en train de devenir une "documentation vivante" lisible à la fois par les testeurs et les principales parties prenantes techniques. Elle a la capacité de présenter les coulisses interactives d'un système aux coéquipiers, actuels et nouveaux. En d'autres termes, les scripts et la structure des tests sont conçus pour être faciles à comprendre et ne pas dépendre d'une personne. Des aspects tels que la maintenabilité et la simplicité peuvent constituer un défi lorsqu'il s'agit de la quantité de tests automatisés.    Playwright joue un rôle important en facilitant la visualisation de ce qui se passe pendant l'exécution des tests, ce qui les rend interactifs et intéressants pour les testeurs et même les développeurs. Playwright peut être un excellent outil d'automatisation qui mérite d'être utilisé pour vos projets, car il offre une présentation claire des scripts de test et, grâce à certaines des extensions utiles mentionnées ci-dessus, il peut vous faire gagner des minutes, voire des heures, sur votre temps de test.    Essayez-le : https://playwright.dev/docs/intro

Avec la numérisation, il devient de plus en plus important que vos informations soient conservées dans un environnement sécurisé et contrôlé afin qu'aucune personne non autorisée ne puisse y avoir accès. Cela signifie probablement que vous devez vous familiariser avec le domaine de la sécurité et les mesures que vous devez prendre pour éviter les intrusions. Ce faisant, vous vous familiariserez certainement avec un grand nombre de nouveaux mots et d'abréviations qui ne sont pas toujours faciles à comprendre. C'est pourquoi nous avons élaboré un glossaire des mots et abréviations les plus courants et peut-être les plus compliqués.   Nous espérons qu'il vous aidera à comprendre les concepts et leur signification.   ARP Spoofing   Cette attaque permet aux pirates d'usurper l'identité de votre ordinateur et de s'emparer de tout votre trafic. L'attaquant manipule la position entre les adresses MAC et les adresses IP, ce qui signifie qu'il a accès à tout le trafic destiné à l'utilisateur rée   Backdoor/Backdoor   Désigne une méthode par laquelle les utilisateurs autorisés et non autorisés peuvent contourner les mesures de sécurité normales et accéder à un système informatique, un réseau ou une application.   Brute force   Méthode utilisée pour, par exemple, énumérer des mots de passe, soit en utilisant une liste prédéfinie de mots de passe, soit en générant des mots de passe de manière aléatoire.   Buffer overflow   Un débordement de mémoire tampon est une vulnérabilité dans une application qui permet à un attaquant de manipuler et d'écraser une mémoire tampon avec du texte ou des instructions vers des emplacements proches dans la mémoire afin de modifier le flux d'exécution de l'application. Cela peut entraîner l'exécution d'un code malveillant par l'application.   CVSS   Le système commun de notation des vulnérabilités permet d'utiliser les principales caractéristiques d'une vulnérabilité pour produire une note numérique qui reflète la gravité de la vulnérabilité. Le résultat de la notation peut ensuite être traduit en une représentation qualitative (faible, moyen, élevé ou critique) afin d'aider les organisations à évaluer et à hiérarchiser leur processus de gestion des vulnérabilités.   Data Exfiltration   Utilisé dans des contextes où les données d'un individu ou d'une entreprise sont illégalement copiées, transférées ou déplacées d'un système.   DC Sync   Il s'agit d'une attaque tardive au cours de laquelle un pirate simule le comportement d'un contrôleur de domaine pour, par exemple, synchroniser les mots de passe par le biais d'une réplication de domaine. Une fois que l'attaquant a accès à un compte privilégié avec des droits de réplication de domaine, les attaquants peuvent exploiter ces protocoles pour se faire passer pour un contrôleur de domaine.   DDoS – Distributed Denial of Service   Le DDoS est une attaque par saturation contre des systèmes ou des réseaux informatiques. L'attaque consiste pour l'attaquant à envoyer de grandes quantités de trafic vers le réseau, de sorte que le site web ou le réseau est mis hors service. De plus en plus de personnes sont touchées par ce type d'attaque.   Enumeration   Définit le processus par lequel on trouve systématiquement, par exemple via une connexion active à un système, des informations précieuses concernant des vecteurs d'attaque potentiels, des informations sur l'ordinateur ou le serveur, des comptes d'utilisateurs, des services, des applications, etc.   Fuzzing   Il s'agit d'une technique de test de logiciel qui consiste à trouver des erreurs d'implémentation en utilisant une injection automatique de données.   GPG – GNU Privacy Guard   Ce qui distingue GnuPG et PGP, c'est en grande partie le fait que PGP est une solution détenue par Symantec et que GPG est fondamentalement un projet Open-Source. D'un point de vue fonctionnel, ils sont identiques l'un à l'autre.   IoT – Internet of Things   Terme générique désignant les systèmes qui sont en relation et communiquent entre eux par le biais, par exemple, de protocoles de réseau. Il s'agit par exemple de montres de fitness, de capteurs, de machines, de serrures, etc.   JWT   Abréviation de JSON Web Tokens. Il s'agit d'une norme ouverte pour le transfert sécurisé d'informations entre deux parties sous la forme d'un objet JavaScript Objection Notation (JSON). Le JWT est utilisé pour l'authentification et l'autorisation en générant une chaîne JSON contenant des informations, qui est ensuite signée et finalement utilisée pour vérifier et garantir l'authentification et l'autorisation.   LLMNR / Net BIOS Name Resolution (NBT-NS)   LLMNR (Link-Local Multicast Name Resolution) est un protocole basé sur le format de paquet DNS (Domain Name System) qui permet aux machines d'un réseau d'effectuer des recherches de noms sur les machines du même réseau local. NBT-NS est similaire en ce sens qu'il est utilisé pour identifier les systèmes sur le réseau local en utilisant leurs noms NetBIOS.   LSASS – Local Security Authority Subsystem Service   Processus de Microsoft Windows chargé d'appliquer la politique de sécurité sur le système. Il vérifie les utilisateurs qui se connectent au système, gère les changements de mot de passe et crée des jetons. Il s'agit généralement d'un processus qu'un attaquant exploite en vidant sa mémoire de processus, puis en lisant et en extrayant l'utilisateur et son mot de passe en clair.   MAC spoofing   Il s'agit d'un processus par lequel vous modifiez activement votre adresse MAC pour une ou plusieurs cartes réseau, par exemple pour vous fondre plus facilement dans l'équipement habituel du réseau.   MitM – Man-in-the-middle attack   Il s'agit d'une attaque dans laquelle le pirate se place entre deux ordinateurs, intercepte le trafic et relaie les messages entre les deux parties afin d'obtenir secrètement des informations. Les deux parties croient qu'elles communiquent directement l'une avec l'autre.   OWASP Top 10   L'Open Web Application Security Project est une organisation mondiale à but non lucratif dont l'objectif est d'améliorer la sécurité des logiciels. Sa liste des 10 principales failles est un recueil des failles les plus courantes dans les applications web. Cette liste est devenue une norme industrielle à suivre en matière de sécurité et de sensibilisation à la sécurité des applications web.   Pass-The-Hash   Technique permettant à un attaquant de s'authentifier auprès d'un serveur ou d'un service distant en exploitant le hachage NTLM ou LanMan sous-jacent du mot de passe d'un utilisateur, au lieu d'utiliser le mot de passe en clair normalement utilisé pour se connecter.   Pass-The-Ticket   Équivalent à pass-the-hash mais repose sur des TGT (ticket-granting-tickets) pour les utilisateurs au lieu de leurs hashs.   PCI-DSS – Payment Card Industry Data Security Standard   Il s'agit d'une norme de sécurité de l'information pour les organisations qui traitent les cartes de crédit connues des principaux systèmes de cartes (par exemple, American Express, Visa, Mastercard, etc.). La norme PCI est imposée par les marques de cartes et administrée par le Payment Card Industry Security Standard Council (Conseil des normes de sécurité de l'industrie des cartes de paiement).   PGP - Pretty good privacy   PGP est devenu un pilier de la sécurité et de la protection de la vie privée. Il s'agit d'un programme utilisé principalement pour crypter et décrypter les courriers électroniques, mais vous pouvez également crypter des fichiers, des textes et votre disque dur avec ce programme. Grâce au cryptage PGP, il n'est pas nécessaire de partager le code à l'avance lorsque vous souhaitez envoyer un message crypté à quelqu'un.   Phishing   Une technique utilisée par les attaquants pour obtenir des informations précieuses telles que votre mot de passe et votre compte bancaire. Il arrive souvent que vous receviez un courriel qui, à première vue, semble provenir d'une source légitime, mais ne vous laissez pas abuser. Le pirate essaiera de vous faire répondre par des informations précieuses, vous demandera de cliquer sur un lien ou d'exécuter une pièce jointe.   Pivoting   Is a process of accessing networks that an attacker would not be able to reach under normal conditions, by using compromised computers or servers as gateways. By using this method, an attacker can exploit compromised computers or servers in networks that have rights to access other parts of the network by forwarding their traffic through them in order to access servers, computers or equipment in other isolated parts of the network.   Port scanning Méthode qui consiste à énumérer les ports/services ouverts sur les serveurs, les ordinateurs ou d'autres équipements d'un réseau.   Ransomware   Le pirate utilise le logiciel pour crypter les fichiers du système, puis extorque une rançon à la victime pour obtenir l'accès à la clé nécessaire au décryptage des fichiers.   RCE - Remote Code Execution   Une vulnérabilité qui permet à un attaquant d'envoyer des commandes qui sont interprétées et exécutées par le système d'exploitation sous-jacent en contournant la couche d'application et les mécanismes de sécurité. Cette vulnérabilité a généralement d'énormes conséquences.   Red Teaming   Il s'agit de tests approfondis d'un système ou d'un environnement d'un point de vue externe, généralement sans réserves ni limitations. Les tests effectués comprennent toutes les tactiques concevables et inhabituelles pour identifier et exploiter les failles.   Root access   L'accès à la racine est spécifique à Unix, Linux ou Android qui est de type Linux. Lorsqu'un attaquant parvient à accéder à un système de ce type, le compte le plus privilégié qu'il peut atteindre est, le plus souvent, le compte racine. Disposer d'un "accès racine" signifie que l'on est parvenu à obtenir ce privilège pour un système. Ce compte est également appelé superutilisateur par de nombreuses personnes.   Social Engineering   Il s'agit d'un terme qui englobe les activités intrusives qui se produisent par le biais d'interactions humaines. L'attaquant incite l'utilisateur qui a accès à des systèmes importants à donner des informations importantes ou à commettre une infraction à la sécurité par le biais d'une manipulation psychologique. Le processus se déroule généralement en plusieurs étapes : d'abord, l'attaquant examine la victime en termes d'informations générales et de protocoles de sécurité faibles, puis il cherche à gagner la confiance de la victime pour finalement accéder à des informations sensibles.   SQL Injection attack   Cette attaque repose sur une validation défectueuse des données contrôlables par l'utilisateur, combinée à des requêtes SQL mal écrites qui permettent à l'attaquant de modifier la requête ou d'ajouter d'autres requêtes qui lui permettent d'exfiltrer des données à partir d'autres bases de données, tables ou colonnes potentielles.   Threat Modeling   La modélisation des menaces est un processus qui permet d'identifier, d'énumérer et de hiérarchiser les vulnérabilités potentielles, telles que les vulnérabilités structurelles, du point de vue d'un attaquant hypothétique.   War driving   Ce terme désigne une personne qui se déplace et localise les réseaux sans fil dans une zone. Pour ce faire, un ordinateur portable et une carte de réseau sans fil sont utilisés, via un téléphone portable par exemple.   White/Grey/Black Box   Ces concepts décrivent les différents niveaux de connaissance ou d'accès à l'information auxquels un testeur a accès au cours d'un test. Ils définissent également l'approche qui doit être adoptée au cours d'un test de pénétration. L'approche "boîte blanche" est celle dans laquelle le testeur a accès au plus grand nombre d'informations avant le test. L'approche de la boîte noire est la façon dont aucune information n'est disponible avant le test autre que les objectifs directs qui sous-tendent le test. L'approche de la boîte grise se situe à mi-chemin entre les deux approches mentionnées.   Le temps et l'argent étant des facteurs importants, l'approche de la boîte blanche est la plus efficace car le testeur ne doit pas passer la majeure partie de son temps à acquérir des informations qui seraient potentiellement manquantes dans une approche de la boîte grise ou de la boîte noire.   XSS - Cross-site scripting   Une faille courante dans les applications web. Un attaquant exploite des formulaires ou des paramètres dans l'application web pour introduire du code JavaScript qui est potentiellement rendu et exécuté par l'application. XSS peut être utilisé pour voler les cookies et les données d'autres utilisateurs, ou pour mener d'autres attaques malveillantes contre les utilisateurs de l'application. —

Il existe différents types de méthodologies et de normes utilisées dans le monde des technologies de l'information pour créer une base de référence pour des pratiques d'exploitation sécurisées. Cela concerne non seulement l'infrastructure et les logiciels informatiques, mais aussi les personnes impliquées.   Dans notre travail quotidien, nous tombons sur des tests où nos clients manquent de routines sûres en matière de gestion des correctifs, de codage, de tests et ne comprennent tout simplement pas les risques potentiels. Il est de notre devoir de les aider. De les éduquer là où ils en ont besoin et quand ils en ont besoin. En tant que professionnels de la sécurité, nous devons nous préoccuper nous-mêmes de la sécurité, afin qu'ils sachent à leur tour que nous nous préoccupons de la leur.   Avec le passage à l'utilisation des machines d'autres personnes (AKA, "The Cloud") pour soutenir l'infrastructure, les plates-formes et les services sur site, de nouvelles politiques et procédures doivent être prises en compte. Ces "nouveaux" environnements sont souvent présentés comme totalement sûrs. Bien qu'ils puissent l'être en eux-mêmes, ce que vous avez construit au-dessus de la fondation est une toute autre histoire. Vous pouvez construire les fondations les plus solides, mais si la structure qui les recouvre s'effondre... à quoi bon ?   Vos données sont-elles sécurisées ?   Cela nous amène à parler des fournisseurs de services tiers externes. La plupart des entreprises ont besoin de solutions multiples pour leurs activités quotidiennes. Tous ces besoins ne peuvent pas être satisfaits à l'aide de ressources internes ou d'applications sur mesure. Les raisons peuvent varier, mais le coût est généralement un facteur important dans cette décision. Soit la solution actuelle fait perdre trop de temps à l'entreprise, soit la conception d'une application interne serait trop coûteuse en termes de construction, de développement et de maintenance. Si vous pouvez penser à un problème, il y a généralement d'autres personnes qui ont le même problème. Et souvent, il existe une solution à ce problème quelque part sur l'un des différents sites Internet.   Le principal argument de vente est qu'il s'agit d'un service prêt à l'emploi, dont la maintenance est assurée par quelqu'un d'autre. Tout ce que vous avez à faire, c'est de l'utiliser. Bien entendu, cela entraîne des problèmes potentiels. Vous n'avez pas le contrôle total de ce qui se passe. Et pourquoi le feriez-vous ? Vous avez payé quelqu'un d'autre pour s'en occuper !   Lorsque vous confiez vos données à quelqu'un d'autre, vous voulez vous assurer qu'elles sont traitées correctement et en toute sécurité. Lorsque vous vous adressez à une entreprise au sujet de son produit, vous devez tenir compte de plusieurs éléments :   Transparence Flexibilité Cryptage Sécurité   Transparence   L'utilisation de nombreuses plateformes de médias sociaux est "gratuite" et vous devez simplement accepter leurs conditions d'utilisation. Si vous achetez un produit, vous devriez avoir certains droits concernant ce que vous achetez, ainsi qu'une excuse légitime pour vous plaindre si quelque chose ne correspond pas à ce qui est annoncé.   L'une des premières questions à poser au fournisseur devrait être : "Quelle est votre politique de sécurité ? Quelles sont vos procédures de sécurité ? Des tests de pénétration sont-ils effectués régulièrement, voire jamais ? Et pouvons-nous consulter ces rapports ? Oui, c'est plus d'une question. Ce n'est pas toujours aussi simple.   Nous pensons que s'ils ne sont pas préparés à ces réponses, c'est qu'ils ne font pas de la sécurité une priorité. S'ils ne sont pas prêts à partager leur politique et leurs procédures, il se peut qu'ils ne considèrent pas la sécurité comme une priorité. S'ils ne veulent pas partager les résultats de tests de pénétration antérieurs, il se peut qu'ils essaient de cacher quelque chose.   Flexibilité   Même si vous achetez un produit prêt à l'emploi, il peut être nécessaire de l'adapter aux besoins spécifiques de votre entreprise. Ce ne sont pas les besoins et les exigences qui sont déterminants. Il s'agit plutôt de savoir s'ils sont réceptifs à vos besoins. S'intéressent-ils à vos questions ? Semble-t-il disposé à vous aider à trouver une solution ? Est-il possible de faire des compromis ?   Certains services ne peuvent tout simplement pas être flexibles dans leur mise en œuvre. Mais cela peut être l'occasion de voir comment l'entreprise traite ses clients.   Cryptage   L'utilisation du cryptage pour protéger la transmission de données sur l'internet est désormais une pratique courante. Fin 2018, le pourcentage de trafic utilisant le protocole HTTPS est supérieur à 72 %. et l'escalade. Il s'agit d'une augmentation considérable par rapport aux années précédentes ! Et bien que ce soit une excellente chose, cela ne garantit en aucun cas que le système est correctement mis en œuvre. Le protocole SSL/TLS est-il correctement mis en œuvre ? Les normes les plus récentes sont-elles appliquées ? Devez-vous "payer pour jouer" afin d'obtenir le meilleur service et le meilleur cryptage ? Votre environnement "sûr" se trouve-t-il sur la même machine que les autres clients qui ne veulent pas payer pour les options de sécurité haut de gamme ? ... Cela vous met un peu mal à l'aise, n'est-ce pas ? On a oublié de vous le dire ? Oups ! Je suppose que votre cryptage sophistiqué n'a plus vraiment d'importance maintenant...   Sécurité   Enfin, nous en arrivons à la raison principale pour laquelle nous sommes ici et pourquoi nous faisons ce que nous faisons. Nous nous soucions de la sécurité. Non seulement pour nos clients, mais aussi pour nous-mêmes, car en réalité, tout est lié d'une manière ou d'une autre.   Nous voyons beaucoup de problèmes dans notre travail quotidien. Le Top 10 de l'OWASP n'est pas une liste arbitraire, ces problèmes sont très répandus. Les raisons pour lesquelles nous continuons à voir ces problèmes sont infinies et nous pourrions les énumérer toute la journée. Mais on en revient toujours à la même chose. L'élément humain est souvent considéré comme le maillon le plus faible de la chaîne. Peu importe les produits et services de sécurité sophistiqués que vous achetez, ils sont tous inutiles s'ils ne sont pas configurés correctement, s'ils ne sont pas allumés/branchés, s'ils ne font pas l'objet de correctifs réguliers ou s'ils sont trop difficiles à gérer.   Derniers mots De la même manière que vous vérifiez correctement les antécédents d'un nouvel employé potentiel, des références valables, une compréhension technique du rôle pour lequel vous recrutez, le même processus et la même méthodologie doivent être appliqués lors de l'examen d'une candidature potentielle d'un tiers. Si vous avez plus d'un candidat plausible, ne tombez pas dans le piège des coûts. N'excluez pas cette option avant d'avoir posé ces questions plus approfondies concernant la sécurité.   Pour vous aider, nous avons élaboré une liste de contrôle qui pourrait et devrait être utilisée comme questionnaire lors de l'examen des services tiers que vous pourriez envisager d'utiliser. Nous avons ajouté ce que nous pensons être quelques bonnes questions pour commencer à évaluer la maturité de la sécurité de l'application d'un fournisseur de services.   Pour téléchargez la liste, cliquez ici.  

Ça vous est déjà arrivé d'arriver au travail en pensant que ce serait une bonne journée et que vous seriez très productif ? Ou au contraire, vous avez su que c'était une mauvaise journée sur tous les fronts ?   Dans ce cas, votre travail a peut-être été affecté par ces émotions.    Pour que vos collègues le sachent, le calendrier "Niko Niko", un indicateur lié à la satisfaction de l’équipe très bien adapté aux méthodes agiles, a été progressivement introduit.    D'où vient-il ?   Venu tout droit du Japon, "Niko Niko" signifie "sourire" en japonais.C'est un calendrier pour exprimer son humeur du jour. Les personnes utilisent un tableau ou un outil dédié pour noter leur humeur quotidienne, symbolisée par des smileys comme ceux-là : 😊 😐 🙁   Cela permet de dresser un tableau de l'état émotionnel de l'ensemble de l'équipe. Cette méthode encourage l'honnêteté, la communication ouverte et fournit des informations utiles pour gérer l'humeur de l'équipe de manière positive. En somme, l'introduction du calendrier "Niko Niko" dans la gestion de projet représente une démarche agile visant l'adaptabilité, la transparence, et la collaboration au sein de l'équipe.   Le Niko Niko, un indicateur très Agile   Ce système permet une évaluation continue des humeurs de l'équipe, favorisant ainsi la flexibilité nécessaire pour répondre aux changements rapides. En encourageant la transparence émotionnelle, le Niko Niko crée un climat de confiance, renforçant la collaboration et facilitant la résolution de problèmes collectifs. En établissant un lien entre la satisfaction de l'équipe et la performance globale, il souligne l'importance du bien-être des membres, en accord avec les principes agiles.   À quoi cela sert-il ?   Chaque membre de l'équipe est encouragé à partager ses sentiments, créant ainsi un climat de confiance propice à la communication. L'objectif principal est d'obtenir une transparence émotionnelle collective. En suivant l'évolution de l'humeur de l'équipe au fil du temps, Niko Niko nous permet de mieux comprendre les schémas émotionnels. Cette ouverture permet d'identifier les hauts et les bas, ce qui facilite la détection précoce des changements importants. Il devient un moyen utile de mesurer le bien-être quotidien. L'objectif est de favoriser une atmosphère d'équipe positive et transparente par le biais d'une communication ouverte et d'une visualisation permanentes.   Conclusion   L'utilisation de Niko Niko dans la gestion de projet joue un rôle essentiel dans le suivi du moral des équipes. Cette analyse permet de comprendre les moments d'enthousiasme et les périodes plus délicates. De plus, ce tableau facilite la détection précoce des variations significatives, ce qui permet de résoudre les problèmes potentiels avant qu'ils ne prennent de l'ampleur.   En bref, l'intégration du Niko Niko dans la gestion de projet va au-delà du simple suivi des humeurs quotidiennes. Le lien entre la satisfaction de l'équipe et la performance globale est mis en évidence, ce qui déclenche des mesures proactives pour améliorer le bien-être.De cette manière il devient un outil dynamique pour influencer positivement la dynamique d'équipe, renforcer la collaboration et contribuer à la réussite du projet.

Le choix du bon outil pour réaliser ses tests de performance est primordial pour plusieurs raisons :   Tout d'abord, l'outil doit permettre de réaliser les tests de performance sur le parc applicatif que l’on souhaite tester, et donc proposer une couverture protocolaire adéquate. Tous les outils ne permettent pas de tester du Citrix, du SAP ou de l’Oracle Forms par exemple. Il doit aussi correspondre à l’organisation du client, et à sa façon de fonctionner. Ensuite, le prix ou l’abonnement, est également un critère des plus importants Enfin, sa simplicité d’utilisation, la qualité de son support, et sa stratégie d’évolution des versions vers les nouveautés du marché sont des critères de choix.   Nous proposons dans cet article un comparatif synthétique de 3 outils.   JMeter   JMeter est un outil de tests de charge open source largement utilisé actuellement, par tous types de client : domaine public, grands comptes, sociétés diverses.Son interface graphique est simple et efficace. Il permet de réaliser des tests sur toutes les applications Web, Webservices (REST, SOAP), Web 2.0, services de messagerie, etc…JMeter est livré avec des fonctions (au sens macro) natives permettant l’injection de données dynamiques ou/et de la manipulation de données à la volée durant le tir de charge.   C’est un outil développé en JAVA, qui propose un grand nombre de plug-in vers diverses technologies pour la partie monitoring.   Il peut être utilisé pour les tests réalisés tôt dans le cycle de développement – Shift Left - donc les tests d’API, de Web services et de Microservices - et également pour les tests de bout en bout. Son interface de recording est efficace. JMeter dispose d’éléments Récepteurs permettant la visualisation des résultats sous forme de graphiques ou de statistiques basiques, et ainsi d’interpréter ses résultats.C’est un outil complet qui, accompagné d’un outillage de reporting type Grafana, et complété par un outillage de capture de métriques type Prometheus permet de réaliser les tests de charge dans un grand nombre de contexte.   Neoload   Neoload est un outil de test de charge proposé par l’éditeur Tricentis (depuis le rachat de Neotys).Neoload supporte des protocoles que Jmeter ne propose pas, par exemple Citrix, Oracle Forms, SAP, ...   Il propose également des fonctions intégrées pour aider à la variabilisation des scripts et à la gestion des variables dynamiques.Dans ses versions récentes, NeoLoad propose un pas important vers l’approche Shift Left, qui permet aux équipes de tester plus tôt dans le cycle de développement logiciel, au niveau API, grâce à de nouvelles fonctionnalités, telles que les tests de performance en code et l’import de fichiers Swagger. Il propose également en plus de l’outillage de capture de scénario pour la réalisation des scripts et du module de contrôle de l’injection de charge, un module de reporting intégré puissant ainsiqu’un module de monitoring qui permet d’avoir un outil très complet. De plus il est interfacé avec des outil d’APM, notamment Dynatrace, qui rendent la corrélation des temps de réponse avec les métriques techniques plus aisé à interpeter, et donc apportent une grande plue value pour les préconisations d’amélioration et de tuning des composants techniques.   L’outil est payant, et son modèle de licensing a changé récemment pour le rendre notablement plus cher.   Gatling   Gatling est un outil de tests de performance open source à la base, de plus en plus souvent utilisé, particulièrement dans un contexte ou la société utilisatrice décide de mettre en place les tests de performance très tôt dans le cycle de livraison des release (mode agile principalement) et ou les développeurs sont plus impliqués dans les engagement de performance de leur code. Gatling permet alors de réaliser aisément les tests d’API et de Webservice. Gatling est « un outil de développeur » dans le sens ou son interface utilisateurs, son organisation, font que les développeurs s’y retrouvent tout de suite, alors que les testeurs traditionnels (utilisateurs de JMeter ou Neoload par exemple) ont du mal à s’y retrouver (j’ai testé …). On peut dire que c’est un outil de tests de performance sous forme de code. Attention Gatling est développé en Scala et nécessite l’apprentissage ou la compétence des bases de ce langage développement. Pour le reste, les fonctionnalités sont là, proches de celles d’un JMeter et les 2 outils sont comparables dans leurs avantages et leurs limites par rapport à un outil de type Editeur comme Neoload.   A noter que Gatling propose une version payante qui permet par exemple d’avoir accès au support et qui est nécessaire pour pouvoir réaliser des tests en mode distribué (controller + load generators multiples).

Il y a plusieurs raisons d'écrire des tests automatisés et leur écriture peut sembler relativement simple. Cependant, l'écriture de "bons" tests automatisés, est nettement plus difficile et nécessite une grande expérience et une formation.     Dans cet article, j'ai recensé quelques objectifs (de haut niveau) qui doivent être vérifiés pour que les tests automatisés deviennent "bons". Lorsqu'ils sont atteints, on peut qualifier les tests automatisés définis comme "bons."    Voici quelques objectifs de haut niveau qui pourraient s'appliquer :   Les tests doivent nous aider à améliorer la qualité.  Les tests doivent nous aider à comprendre le système.  Les tests doivent réduire (et non augmenter) le risque.  Les tests doivent être faciles à exécuter. Les tests doivent être faciles à écrire et à maintenir. Les tests doivent nécessiter une maintenance minimale au fur et à mesure que le système évolue autour d'eux.    Les tests devraient nous aider à améliorer la qualité  1. Test selon les spécifications   Si vous utilisez l'approche TDD (développement piloté par les tests) ou BDD (développement piloté par le comportement), les tests vous permettront de comprendre comment le système réagira. Le fait de réfléchir à différents scénarios pour les transformer en tests nous aide à identifier les zones où les exigences sont ambiguës ou contradictoires. Une telle analyse clarifie l'objectif de la spécification, ce qui conduit à une conception plus précise, améliorant ainsi la qualité du logiciel.    2. Prévenir les anomalies   Les tests automatisés permettent de trouver les bugs, mais ce n'est pas l'objectif principal de l'automatisation des tests. Les tests automatisés visent à prévenir l'introduction de bugs. Pensez aux tests automatisés comme un rejet des défauts, ce qui empêche les bugs de revenir dans notre logiciel après nous être assurés qu'il en est exempté. Si nous disposons de tests de régression complets et de qualité, il n'y aura pas de bugs, car les tests signaleront les défauts avant même que nous ne vérifions notre code.    3. Désignation des défauts   Si les tests automatisés sont assez petits (c'est-à-dire que nous ne testons qu'un seul comportement dans chacun d'eux), nous serons en mesure d'identifier rapidement l'erreur, en fonction du test qui échoue. Mais pour y parvenir, nous devons écrire des tests pour tous les scénarios possibles afin de couvrir chaque unité du logiciel. Les tests ne doivent jamais contenir d'ambiguïtés. Il est donc crucial que les tests soient aussi petits et triviaux que possible (faible complexité, format cohérent et un seul comportement vérifié par test).    Les tests doivent nous aider à comprendre le système    4. Les tests comme documentation   Les tests automatisés permettent de mettre en lumière la manière dont le code doit fonctionner. Ils montrent ce que devrait être le résultat (ils indiquent le résultat attendu d'un ou plusieurs scénarios).   Si nous voulons savoir comment le système se comporte, nous pouvons lancer le débogueur, exécuter un test et avancer étapes par étapes, à travers le code, pour voir comment il fonctionne. Les tests unitaires font figure de documentation pour le système.    Les tests doivent réduire (et non augmenter) le risque    5. Les tests comme filet de sécurité   La modification d'un code plus ancien est risquée car généralement, nous ne savons ce qui peut être cassé, et il est également difficile d'identifier si quelque chose a été cassé. Nous devons travailler rigoureusement et effectuer beaucoup d'analyses manuelles avant d'apporter des modifications.    Cependant, lorsque l'on travaille avec du code qui a une suite de tests automatisés, on peut travailler beaucoup plus rapidement. Les tests détecteront les effets de bords et nous indiqueront si nous avons cassé quelque chose. De cette façon, les tests automatisés agissent comme un filet de sécurité qui nous incite à oser prendre des risques.   6. Anticiper les risques    Nous devons veiller à ne pas introduire de nouvelles problématiques dans le système suite à l'automatisation des tests. Gardez le script des tests séparés du code en production pour éviter de créer des dépendances spécifiques au test dans le système (particulièrement important pour le code des tests unitaires). Tout le code et toutes les bibliothèques spécifiques au test doivent être liés par le test et uniquement dans la version test et dans l'environnement de test. Les dépendances de test et le code de test ne doivent jamais se trouver dans le code final avant sa mise en production.    Les tests doivent être faciles à exécuter   Il existe quatre caractéristiques spécifiques qui rendent les tests automatisés faciles à exécuter. Grâce à ces quatre caractéristiques, il vous suffit de cliquer sur un bouton (ou mieux encore, de le déclencher automatiquement) pour obtenir le précieux retour d'information que les tests fournissent :     Les tests doivent être entièrement automatisés afin d'être exécutés sans effort.  Les tests doivent être auto-évaluatifs afin de pouvoir détecter et signaler les erreurs sans inspection manuelle.  Les tests doivent être reproductibles afin d'être exécutés plusieurs fois avec les mêmes résultats.  Chaque test doit être indépendant afin qu'il puisse s'exécuter seul.     7. Des tests entièrement automatisés   Un test qui peut être exécuté sans aucune intervention manuelle est un test entièrement automatisé. La satisfaction de cette caractéristique est une condition préalable à la satisfaction des autres.   8. Auto-évaluation   Un test avec auto-évaluation permet de mettre en place les assertions qui vont vérifier que le résultat attendu est correct.  Le test nous avertit uniquement lorsque le résultat n'a pas été approuvé ; par conséquent, un test propre ne nécessite aucun effort manuel.     9. Tests répétables   Un test reproductible peut être exécuté à l'infini et générer les mêmes résultats, sans intervention humaine ni analyse entre les exécutions.     Les tests doivent être faciles à écrire et à maintenir    Lorsque nous changeons le comportement d'une partie d'un système, nous devons nous attendre à ce qu'un petit nombre de tests soit affecté par nos modifications. L'un des avantages de l'automatisation des tests est de rendre les changements simples. Nous devrions donc toujours nous efforcer d'assurer que nos tests ne font pas le contraire (rendre les changements plus difficiles). Les tests doivent nécessiter un minimum de maintenance au fur et à mesure que le système évolue autour d'eux.    10. Tests simples   Concentrez-vous sur les tests plutôt que sur la façon de les coder. Cela signifie que les tests doivent être simples/triviaux (faciles à lire, faciles à écrire et faciles à maintenir). Nous devons nous efforcer de vérifier une condition par test en créant une méthode de test distincte pour chaque combinaison unique de conditions. Chaque méthode de test doit tester le système par un seul chemin dans le système.  11. Tests d'expression   Une bibliothèque de méthodes auxiliaires aidant à la mise en place d'un langage pour un domaine de test spécifique permet, à la personne qui rédige le script de test automatisé, d'exprimer son idée du test sans avoir à traduire sa pensée dans un code trop détaillé et complexe.    12. Divisez les problèmes   Gardez le code des tests séparé du code en production (gardez la structure et la logique du code en production mais dans une structure parallèle). Chaque test doit se concentrer sur un seul problème pour éviter les tests compliqués et peu clairs.    Pour résumé    Il y a une différence entre un test et un bon test, mais il est souvent difficile de savoir comment définir un "bon" test. Dans cette liste de contrôle, j'ai partagé 12 caractéristiques pour de bonnes pratiques d'automatisation des tests, qui à leur tour se traduisent par des tests faciles à écrire et une maintenance adéquate - deux facteurs qui sont très importants pour un système.

L'automatisation des tests permet de gagner du temps, non seulement pour la première exécution, mais surtout pour les suivantes.   Bien que la technicité soit un atout dans ce domaine, ce n'est certainement pas l'atout majeur puisqu'au delà des langages et des technologies, les notions de conception, de couverture, de lisibilité et de maintenabilité distinguerons les bons scripts des inutiles.   Au fil de mes expériences je peux noter en automatisations ces points qu'il me semble nécessaire de vérifier :   La réutilisabilité des scripts.   Les tests autos ne doivent pas être des "one shot" mais ils doivent rester un maximum fonctionnel sur des environnements différents et être réutilisables plusieurs fois notamment pour de la non régression.   La conception   Et oui être technique ne suffit pas! Il peut être nécessaire d'utiliser des techniques de conceptions et d'identifier aussi bien des cas valides que des cas invalides. Rédiger des cas de tests c'est un art et solliciter le regard des autres n'est pas de trop!   La couverture   Il faut donc couvrir un maximum d'aspect mais toujours avec un minium de cas de test. Penser au temps d'exécution et s'essayer de construire un patrimoine pertinent et sans redondance.   Lisibilité   Un script clair et lisible c'est la base, ne négligez pas la structure et les commentaires pertinents. Le "turn over" ça arrive dans toutes les entreprises et il faut penser au personnes qui pourraient repasser derrière vous et tenter de vous relire.   Maintenabilité   Le dernier point est crucial, que ce soit à l'aide de langages ou d'outils low-code / no-code, il est primordial de comprendre la notion "d'objet" si chère à certains langages de programmation. Un objet / module s'il est le même dans plusieurs script doit être modifiable en un seul point tout comme les actions / fonctions / méthodes qui se répètent. Afin d'éviter lors d'un changement de refaire la même modification sur plusieurs script.   En automatisation web, on appel ce principe le Page Object Model, autrement connu sous le nom de POM.   Et vous? Quelles sont vos recommandations?

Découvrez lors de ce webinar, comment l'IA peut devenir un allié essentiel pour les testeurs. Bénéfices, limites et outils.

Découvrez les avantages de l'automatisation des tests dans les projets Salesforce pour garantir la stabilité et l'efficacité des processus métiers.