Guide de tests fonctionnels. En utilisant ces principes, mes équipes ont réduit de 90% les défauts détectés en tests d’acceptation (UAT) et permis la livraison de trois projets avec zéro défaut.
Guide de tests fonctionnels. En utilisant ces principes, mes équipes ont réduit de 90% les défauts détectés en tests d’acceptation (UAT) et permis la livraison de trois projets avec zéro défaut.
Aujourd’hui, les tests sont devenu un élément crucial au cycle de développement logiciel, des sociétés ont investi dans la création d’un service interne de tests, rien ne peut être mis en production sans être validé par ce service.
Pour cela, cette présentation va mettre en évidence les fondamentaux de test logiciel à savoir: définitions, types, processus, méthodes, outils, principes, stratégies, jeux de test, etc.
Cette présentation présente les concepts basiques de la qualité logicielle, elle explique le principes de la mesure et l’évaluation de la qualité, l'importance des métriques dans un projet informatique, le rôle des modèles de qualité comme la norme ISO9126, ainsi que les métriques de code, à savoir: les métriques de McCabe, de Chidamber et Kemerer, etc.
Introduction à la qualité logicielle (1/5)Sylvain Leroy
Présentation / Sensibilisation à la qualité logicielle, à l'assurance qualité et au contrôle du code des applications.
Cette présentation est le premier chapitre introductif du thème. Elle rappelle les principaux écueils que rencontre tout projet de développement informatique.
Formation généraliste rédigée en Juin 2009
Qualité logiciel
Plan Qualité
Gestion Processus de développement
Gestion des exigences
Gestion de configuration
Gestion des tests
Gestion des anomalies
Gestion de la documentation
Aujourd’hui, les tests sont devenu un élément crucial au cycle de développement logiciel, des sociétés ont investi dans la création d’un service interne de tests, rien ne peut être mis en production sans être validé par ce service.
Pour cela, cette présentation va mettre en évidence les fondamentaux de test logiciel à savoir: définitions, types, processus, méthodes, outils, principes, stratégies, jeux de test, etc.
Cette présentation présente les concepts basiques de la qualité logicielle, elle explique le principes de la mesure et l’évaluation de la qualité, l'importance des métriques dans un projet informatique, le rôle des modèles de qualité comme la norme ISO9126, ainsi que les métriques de code, à savoir: les métriques de McCabe, de Chidamber et Kemerer, etc.
Introduction à la qualité logicielle (1/5)Sylvain Leroy
Présentation / Sensibilisation à la qualité logicielle, à l'assurance qualité et au contrôle du code des applications.
Cette présentation est le premier chapitre introductif du thème. Elle rappelle les principaux écueils que rencontre tout projet de développement informatique.
Formation généraliste rédigée en Juin 2009
Qualité logiciel
Plan Qualité
Gestion Processus de développement
Gestion des exigences
Gestion de configuration
Gestion des tests
Gestion des anomalies
Gestion de la documentation
L'Approche SMV améliore la qualité en général dans le cycle de vie du développement d'un application grâce à l'interconnexion entre la gestion des exigences, la modélisation, la simulation et le test automatique
La mise en place d'un projet d'amélioration continue ne garantie pas un succès dans cent pout cent
des cas. L'expérience permet aujourd'hui de pouvoir identifier, anticiper et réduire ces risques pour
maximiser les chances de succès. Je propose de décrire quelques unes de ces bonnes pratiques afin
de justifier et d'illustrer le plan proposé.
La qualité au service de vos projets digitaux ! Retour sur le PDJ co-organisé...Julie DULOT
En collaboration avec la société StarDust, nous avons organisé ce 1er Juin 2017, un petit-déjeuner sur le thème de la qualité au services de vos projets digitaux.
Cédric Milton (StarDust) & Jérôme Calais (Netvigie) sont intervenus afin d'expliquer comment un site fonctionnel et performant booste votre business.
Un grand merci à Guillaume Goureau, Responsable Développement Web chez Norauto pour son retour d'expérience quant à l'utilisation de nos outils.
Tirer profit d'un outillage de gestion des exigencesEchoesLabs
Souvent le parent pauvre du cycle de vie des développements logiciels, la gestion des exigences est pourtant une étape incontournable pour réussir les projets. Notre livre blanc vous dévoile les bonnes pratiques, un comparatif des produits existants et nos recommandations pour implémenter une solution efficiente dans votre activité.
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...Horgix
This is the slide deck of a talk by Alexis "Horgix" Chotard and Laurentiu Capatina presented at the MongoDB Paris User Group in June 2024 about the feedback on how PayFit move away from a monolithic hell of a self-hosted MongoDB cluster to managed alternatives. Pitch below.
March 15, 2023, 6:59 AM: a MongoDB cluster collapses. Tough luck, this cluster contains 95% of user data and is absolutely vital for even minimal operation of our application. To worsen matters, this cluster is 7 years behind on versions, is not scalable, and barely observable. Furthermore, even the data model would quickly raise eyebrows: applications communicating with each other by reading/writing in the same MongoDB documents, documents reaching the maximum limit of 16MiB with hundreds of levels of nesting, and so forth. The incident will last several days and result in the loss of many users. We've seen better scenarios.
Let's explore how PayFit found itself in this hellish situation and, more importantly, how we managed to overcome it!
On the agenda: technical stabilization, untangling data models, breaking apart a Single Point of Failure (SPOF) into several elements with a more restricted blast radius, transitioning to managed services, improving internal accesses, regaining control over risky operations, and ultimately, approaching a technical migration when it impacts all development teams.
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Laurent Speyser
(Conférence dessinée)
Vous êtes certainement à l’origine, ou impliqué, dans un changement au sein de votre organisation. Et peut être que cela ne se passe pas aussi bien qu’attendu…
Depuis plusieurs années, je fais régulièrement le constat de l’échec de l’adoption de l’Agilité, et plus globalement de grands changements, dans les organisations. Je vais tenter de vous expliquer pourquoi ils suscitent peu d'adhésion, peu d’engagement, et ils ne tiennent pas dans le temps.
Heureusement, il existe un autre chemin. Pour l'emprunter il s'agira de cultiver l'invitation, l'intelligence collective , la mécanique des jeux, les rites de passages, .... afin que l'agilité prenne racine.
Vous repartirez de cette conférence en ayant pris du recul sur le changement tel qu‘il est généralement opéré aujourd’hui, et en ayant découvert (ou redécouvert) le seul guide valable à suivre, à mon sens, pour un changement authentique, durable, et respectueux des individus! Et en bonus, 2 ou 3 trucs pratiques!
L'IA connaît une croissance rapide et son intégration dans le domaine éducatif soulève de nombreuses questions. Aujourd'hui, nous explorerons comment les étudiants utilisent l'IA, les perceptions des enseignants à ce sujet, et les mesures possibles pour encadrer ces usages.
Constat Actuel
L'IA est de plus en plus présente dans notre quotidien, y compris dans l'éducation. Certaines universités, comme Science Po en janvier 2023, ont interdit l'utilisation de l'IA, tandis que d'autres, comme l'Université de Prague, la considèrent comme du plagiat. Cette diversité de positions souligne la nécessité urgente d'une réponse institutionnelle pour encadrer ces usages et prévenir les risques de triche et de plagiat.
Enquête Nationale
Pour mieux comprendre ces dynamiques, une enquête nationale intitulée "L'IA dans l'enseignement" a été réalisée. Les auteurs de cette enquête sont Le Sphynx (sondage) et Compilatio (fraude académique). Elle a été diffusée dans les universités de Lyon et d'Aix-Marseille entre le 21 juin et le 15 août 2023, touchant 1242 enseignants et 4443 étudiants. Les questionnaires, conçus pour étudier les usages de l'IA et les représentations de ces usages, abordaient des thèmes comme les craintes, les opportunités et l'acceptabilité.
Résultats de l'Enquête
Les résultats montrent que 55 % des étudiants utilisent l'IA de manière occasionnelle ou fréquente, contre 34 % des enseignants. Cependant, 88 % des enseignants pensent que leurs étudiants utilisent l'IA, ce qui pourrait indiquer une surestimation des usages. Les usages identifiés incluent la recherche d'informations et la rédaction de textes, bien que ces réponses ne puissent pas être cumulées dans les choix proposés.
Analyse Critique
Une analyse plus approfondie révèle que les enseignants peinent à percevoir les bénéfices de l'IA pour l'apprentissage, contrairement aux étudiants. La question de savoir si l'IA améliore les notes sans développer les compétences reste débattue. Est-ce un dopage académique ou une opportunité pour un apprentissage plus efficace ?
Acceptabilité et Éthique
L'enquête révèle que beaucoup d'étudiants jugent acceptable d'utiliser l'IA pour rédiger leurs devoirs, et même un quart des enseignants partagent cet avis. Cela pose des questions éthiques cruciales : copier-coller est-il tricher ? Utiliser l'IA sous supervision ou pour des traductions est-il acceptable ? La réponse n'est pas simple et nécessite un débat ouvert.
Propositions et Solutions
Pour encadrer ces usages, plusieurs solutions sont proposées. Plutôt que d'interdire l'IA, il est suggéré de fixer des règles pour une utilisation responsable. Des innovations pédagogiques peuvent également être explorées, comme la création de situations de concurrence professionnelle ou l'utilisation de détecteurs d'IA.
Conclusion
En conclusion, bien que l'étude présente des limites, elle souligne un besoin urgent de régulation. Une charte institutionnelle pourrait fournir un cadre pour une utilisation éthique.
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...OCTO Technology
Par Nicolas Bordier (Consultant numérique responsable @OCTO Technology) et Alaric Rougnon-Glasson (Sustainable Tech Consultant @OCTO Technology)
Sur un exemple très concret d’audit d’éco-conception de l’outil de bilan carbone C’Bilan développé par ICDC (Caisse des dépôts et consignations) nous allons expliquer en quoi l’ACV (analyse de cycle de vie) a été déterminante pour identifier les pistes d’actions pour réduire jusqu'à 82% de l’empreinte environnementale du service.
Vidéo Youtube : https://www.youtube.com/watch?v=7R8oL2P_DkU
Compte-rendu :
1. WHITE PAPER
Radiographier une application
pour « Tester Juste ».
Un nouveau regard pour la validation
Copyright Kalistick 2010
Tous droits réservés.
2. WHITE PAPER
Afin de satisfaire les besoins de l’entreprise, tout système d’information
doit s’aligner sans cesse avec des exigences de plus en plus fluctuantes et à
un rythme toujours plus rapide. Cela influe sur les processus de
développement mais exige également une gestion plus efficiente des phases
de qualification et de recette, soumises à des fortes pressions et à des
risques croissants.
Adopter une approche basée sur la connaissance d’informations précises sur
la version à valider permet de franchir une nouvelle étape dans
l’amélioration économique des activités de qualification et de recette, avec
comme bénéfices potentiels une amélioration de 32% de l’efficacité de la
validation et une réduction de 45% de sa durée1
Cette approche « boite grise » passe par une « radiographie » des
applications à valider pour obtenir une nouvelle visibilité sur les risques à
couvrir et ainsi :
Anticiper les problèmes.
Augmenter l’efficacité des tests.
Assurer la stabilité de la qualité de version en version.
Maitriser les risques de déploiement d’un correctif.
Agir sur la qualité en amont.
1
Capers Jones, Software Quality in 2010: “A Survey of the state of the art”, basée sur
13500 projets, 675 sociétés (150 Fortune 500) + 35 acteurs publics dans 24 pays, et
confirmés par 15 conflits juridiques.
2
3. WHITE PAPER
CONTEXTE
Avant de rendre un système opérationnel, il faut toujours s’assurer de sa
conformité à un niveau de qualité qui dépend des risques à prévenir
(dysfonctionnements, mauvaises performances, failles de sécurité, …). Différentes
méthodes sont disponibles à cet effet, toutes basées sur des activités formelles de
revues ou sur le déroulement de campagnes de test. Force est de constater
qu’aucune ne permet de répondre de manière satisfaisante à tous les enjeux aussi
bien du monde de l’IT que de celui des métiers, comme le démontrent les
problèmes soulevés par les acteurs impliqués :
L’IT se plaint des délais de qualification trop courts, des équipes sous-
dimensionnées, des budgets prévisionnels insuffisants, …
Les métiers constatent que la recette dure trop longtemps, que les tests
mobilisent trop de ressources non-informatiques, que des
dysfonctionnements restent et coûtent chers, …
Une première tentative de solution est venue de la standardisation des processus
(modèle V&V, méthodologie TMap, …). Cette standardisation a ensuite permis
d’automatiser certaines activités. Dernièrement, une amélioration importante est
venue de l’apport du pilotage des tests par les risques (RBT – Risk-Based
Testing), qui constate qu’une couverture à 100% des exigences fonctionnelles et
non-fonctionnelles relève de la théorie, et recommande de mieux cibler ses efforts.
Cependant l’accélération des fréquences d’évolution, la complexité des systèmes,
leurs interconnexions via les architectures SOA, mais aussi l’adoption des
méthodologies agiles nécessitent des stratégies complémentaires. Il est
primordial de rendre les activités de tests non seulement plus efficaces
(découverte des défauts les plus critiques) mais également plus efficientes
(couverture optimale avec le moins de cas de test). En effet, ces activités
représentent encore 30% à 50% des budgets et malgré cela, des défauts « latents »
génèrent des anomalies qui coûtent très cher.
UNE NOUVELLE VISIBILITE SUR L’APPLICATION A VALIDER
Les phases de qualification et recette impliquent différents acteurs et structures
organisationnelles de l’entreprise avec des rôles et responsabilités
complémentaires.
Le diagramme suivant représente une organisation articulée autour de trois
entités : les études et projets (département qui a en charge la partie amont d’un
projet de développement ainsi que la relation avec les entités métiers y compris
3
4. WHITE PAPER
l’accompagnement à la recette), le développement (département interne ou
externe qui effectue les développements), et la production (exploitation de
l’infrastructure technologique et services y afférant).
F IGURE 1 : O RGANISATION « V IRTUELLE » POUR LA VALIDATION
Au centre, nous avons représenté une organisation « virtuelle » chargée de la
qualification et de la recette. Certains l’incluront dans le département études et
projets, d’autres pourront considérer cette entité comme un prestataire de TRA
(Tierce Recette Applicative).
L’objectif principal de cette organisation est d’optimiser en temps et ressources
toutes les activités d’assurance qualité liées à une livraison planifiée2 de version
d’un système d’information, quel que soit le type d’évolution.
Pour atteindre cet objectif, son rôle est double : l’un est d’accompagner le pilotage
de la qualité globale du projet depuis les spécifications jusqu’à la mise en
production, l’autre est de certifier à tout moment la conformité d’une livraison
afin de garantir la fiabilité opérationnelle requise.
A chaque livraison, les responsables de qualification ou de recette doivent
s’appuyer sur des stratégies qui leur permettent d’évaluer, piloter et gérer leurs
activités de test efficacement tout en s’inscrivant dans un cadre de gestion des
risques opérationnels.
2
Mais aussi dans le cas d’un correctif à déployer rapidement (rarement planifié).
4
5. WHITE PAPER
QUELS SONT LES PROBLEMES ?
Commençons par regrouper quelques situations rencontrées couramment :
1) A la fin des tests, seule 50% de la couverture fonctionnelle est testée et les
mêmes tests sont sans cesse répétés (inefficience des tests).
2) Malgré des campagnes de test menées jusqu’au bout, la fiabilité du
système s’avère insuffisante au vu des incidents rencontrés en production
(inefficacité des tests).
3) Après des évolutions mineures exigées par les entités métiers et testées
normalement, le système s’est dégradé (non pertinence des tests).
Tout comme une énumération de symptômes ne suffit pas, il nous faut analyser
les causes des problèmes rencontrés lors des phases de qualification et de recette
pour identifier des solutions. Des études empiriques3 publiées après des
recherches scientifiques listent des causes originelles parmi lesquelles :
La qualité structurelle du code n’est pas au niveau requis. Dans ce cas, la
phase de validation se confronte à des problèmes qui auraient dû être
éliminés en amont car liés à un déficit dans les pratiques de développement
qui engendrent des défauts fonctionnels.
La maintenabilité et l’évolutivité du code ne sont pas suffisantes. Chaque
modification exige plus d’effort et a des impacts plus larges sur
l’application ; cela augmente d’autant le risque de régressions. En
conséquence, l’effort de test sera très important à chaque version, même
mineure.
Les impacts des modifications réalisées ne sont pas correctement perçus, ou
alors de manière trop tardive, et les campagnes de test ne s’appuient pas sur
les risques réels de régressions selon les fonctionnalités impactées par le code
modifié. Il est par exemple fréquent que des bugs soient créés lors des
dernières corrections livrées en fin de validation pour lesquelles il est
impossible de rejouer l’ensemble des tests.
Le manque de visibilité sur le contenu du livrable reçu rend difficile la mise
en place d’une stratégie de tests basée sur une collaboration efficace entre
tous les acteurs. Les testeurs ne peuvent pas optimiser leurs efforts, les
entités métiers ne reçoivent pas les informations nécessaires à l’évaluation
des risques métiers, et l’exploitation n’a pas de visibilité précise sur les
versions.
3
Empirical Studies from Software Quality Group of ATI (at.es).
“Empirical Studies of a Prediction Model for Regression Test Selection”, Harrold,
Rosenblum, Rothermel, Weyuker, IEEE.
5
6. WHITE PAPER
La conséquence fréquente de ces différents points : un nombre de livraisons trop
important pour une même phase de validation. Chaque livraison supplémentaire
augmente les coûts et la durée des tests, les risques de régressions non détectées,
et retarde la mise en production.
L’EXAMEN RADIOGRAPHIQUE
Evaluer ces risques en amont de la réception de chaque livraison, en disposant
d’une vision précise de la qualité du produit, de ses risques structurels, des
modifications et de leurs impacts renforce les processus de « validation qualité »,
« validation produit » et « validation version » avec des indicateurs clairs pour :
Evaluer l’effort de test nécessaire à la validation4 de cette version,
Orienter les efforts de test sur les bons composants et fonctionnalités au
moment opportun,
Réduire le nombre d’itérations nécessaires à la validation d’une version5.
La clé réside dans une radiographie des livraisons qui apporte à chacun une
information objective :
Evaluer la densité potentielle de défauts en effectuant une « validation
qualité » basée sur des techniques d’analyse du code source.
Restituer les risques projets et métier au travers d’une « validation
produit » avec une vision rapide sur les impacts directs et indirects
(régressions) des évolutions réalisées.
Donner aux entités de production une vision instantanée sur les
changements à déployer et les éventuels problèmes d’intégration grâce à
une « validation version ».
Pour satisfaire à ces trois validations et donner une visibilité complète sur
l’application (360°), la radiographie doit analyser des domaines complémentaires
et agréger les résultats pour fournir une synthèse pertinente et exploitable. En
couvrant les 8 domaines présentés ci-après, une plateforme de radiographie
devient une source d’informations riche pour planifier, piloter et gérer les
activités de validation. En disposer à chaque livraison évite de se lancer à
« l’aveugle » dans une phase de qualification ou de recette.
4
Validation s’entend au sens du modèle V&V, à savoir toutes les activités de test en
qualification et recette
5
Chaque itération correspond à une livraison et apporte de nouveaux risques de
régressions. Le nombre de bugs introduits lors de modifications pendant la
validation est estimé à 8%.
6
7. WHITE PAPER
F IGURE 2 : P ERIMETRE D ’ UNE RADIOGRAPHIE 360°
L’agrégation et la restitution des informations doivent se faire en utilisant un
prisme adapté aux besoins de chaque acteur. Ainsi, une restitution basée sur
l’architecture fonctionnelle, comme illustrée sur la figure ci-dessous, montre plus
clairement les zones de risques à couvrir lors des tests.
F IGURE 3 : R ESTITUTION DES RISQUES FONCTIONNELS ET REGRESSIONS
(risques : vert -> rouge, zones modifiées & risques régressions)
COMMENT PRODUIRE CETTE RADIOGRAPHIE
Pour réaliser cette radiographie, la plateforme Kalistick conjugue plusieurs
techniques d’analyse de l’application6 afin d’obtenir des informations pertinentes
et complémentaires, et les restitue de manière adaptée aux besoins des différents
acteurs de la validation.
F IGURE 4 : P ROCESSUS DE RADIOGRA PHIE
6
Ces techniques sont issues des recherches menées en collaboration avec les
laboratoires de l’Insa de Lyon et du CETIC, et ont été primées par le Ministère de la
Recherche en 2008.
7
8. WHITE PAPER
Les techniques appliquées sont :
Analyse statique du code, il s’agit d’une technique qui se rapproche de la
boite blanche pour détecter les potentiels problèmes techniques et
structurels.
Analyse des architectures technique et fonctionnelle pour recomposer son
organisation interne, pouvoir en vérifier la cohérence et restituer les
informations sur un angle fonctionnel.
Analyse des variations entre chaque livraison avec la version en production,
pour retrouver les modifications réalisées, évaluer les risques associés et
ainsi pouvoir affecter les bonnes priorités aux tests à réaliser.
Analyse des tests réalisés par les équipes de développement avant la
livraison, de leur couverture des modifications réalisées, pour détecter les
points insuffisamment testés ou éviter de focaliser tous les efforts de tests
sur les mêmes éléments.
La combinaison de ces différents axes d’analyse et la visibilité qu’elle donne des
applications forme une approche que nous qualifions de « boite grise » pour sa
capacité à restituer sur le plan fonctionnel une analyse interne de l’application, de
ses variations et de ses risques.
CARACTERISTIQUES SUPPLEMENTAIRES DE LA PLATEFORME DE
RADIOGRAPHIE
Pour maximiser l’efficacité de la démarche, cette radiographie doit se faire à
chaque livraison et s’intégrer de manière fluide dans les processus existants.
Pour cela, il est important qu’elle soit automatisée, que ses résultats soient
disponibles en quelques heures et accessibles facilement à l’ensemble des acteurs
internes ou externes pour disposer d’un référentiel commun Pour les projets
offshore, il est important d’avoir une plateforme multilingue accessible par
Internet de manière sécurisée pour partager la visibilité acquise sur l’application.
En outre, permettre un accès à l’équipe de développement est primordial car
l’expérience montre qu’il est également souhaitable de disposer d’une
radiographie anticipée, en amont de la livraison officielle (quelques semaines) afin
de disposer de plus de temps pour adapter sa stratégie de validation aux risques
détectés.
En complément, il faut bien sûr que la solution ne soit pas structurante et qu’elle
ne génère pas une charge d’exploitation qui la rendrait trop coûteuse notamment
durant les phases de maintenance corrective de l’application à radiographier.
Enfin, si elle s’appuie sur une base de connaissance pour d’étudier la corrélation
réelle entre les résultats de la radiographie et les taux de panne réellement
observés en production, cela permet l’amélioration continue de la radiographie et
donc des validations.
8
9. WHITE PAPER
La plateforme Kalistick offre ces caractéristiques notamment grâce au mode SaaS
(Software as a Service), c'est-à-dire accessible par Internet par tous les acteurs du
projet, dans différentes langues, et intégrées avec les plateformes de
développement et de test (ALM - Application Life-Cycle Management).
LES BENEFICES DE CETTE VISIBILITE POUR LA VALIDATION
Apporter au chef de projet et aux responsables d’entités concernées par la
validation les moyens d’anticiper sur les risques potentiels, d’en évaluer les
impacts techniques et métier en utilisant une perspective technique ou
fonctionnelle selon leur rôle est une vraie innovation et apporte des bénéfices très
concrets :
ANTICIPER LES PROBLEMES
Ce premier bénéfice est très tangible : l’anticipation sur la validation. Car
l’analyse des résultats des radiographies réalisées montre que trop souvent on
s’attaque à la validation d’une version instable pas réellement testée en
développement. Cette situation apparait généralement bien tard lorsque l’on a
reçu de multiples livraisons pour une même version avec à chaque livraison de
nouvelles régressions provoquées par des remaniements du code inattendus.
Avoir une vision de la version à recevoir quelques semaines avant sa réception
effective et s’appuyer sur des indicateurs factuels pour estimer l’effort de tests à
réaliser et les risques potentiels apporte une capacité d’anticipation forte à la DSI.
Comme le montre des études, telles celles de Capers Jones7, le coût et la durée de
validation augmentent de 50% lorsque l’on est face à une application
« pathologique8 ». Avoir cette information est donc capital.
AUGMENTER L’EFFICACITE DES TESTS
Disposer à chaque livraison d’une vision précise des modifications réalisées, telles
des « releases notes », accompagnée par une analyse d’impact de ces changements
sur les plans techniques ou fonctionnels, augmente significativement la
pertinence des efforts de tests. Cela évite également l’apparition de nouveaux
bugs introduits avec les dernières corrections réalisées peu avant la mise en
production.
ASSURER LA STABILITE DE LA QUALITE
Lors du déploiement d’une nouvelle version, on cherche toujours à s’assurer que
la qualité est à minima équivalente à la version précédente en identifiant les
nouveaux problèmes ; car soit les anciens sont connus et considérés comme non
7
Cf. note 1 : Capers Jones, Software Quality in 2010.
8
Dans un état de faible qualité.
9
10. WHITE PAPER
prioritaires, soit pas encore découverts et donc « potentiellement moins graves »
car ils ne « gênent » pas le fonctionnement actuel en production. Avoir la
visibilité sur ce différentiel est donc essentiel pour éviter la dégradation de
l’application au fur et à mesure de ses évolutions et l’apparition de nouveaux
risques.
CONTROLER LES RISQUES DE DEPLOIEMENT D’UN CORRECTIF
Lors de la réception d’un correctif à déployer rapidement, la capacité de test est
limitée et la décision de déploiement repose sur une analyse des risques pour
éviter des dysfonctionnements en chaîne. Là encore, disposer d’une radiographie
immédiate est synonyme d’une analyse des risques maîtrisée. D’autant plus si on
ajoute la possibilité pour la production d’identifier précisément le différentiel par
rapport à la version déjà déployée, par exemple sur la configuration ou les
librairies tierces.
AGIR SUR LA QUALITE EN AMONT
Notons que les validations effectuées permettent non seulement d’estimer les
probabilités de risques métiers ainsi que les impacts potentiels, mais également et
surtout, la valeur du code déjà fourni et testé. Basée sur un référentiel qualité
établi, les résultats font fréquemment ressortir des opportunités d’optimisation
ou d’adaptation des processus d’ingénierie logicielle en amont.
CONCLUSION
Disposer de cette nouvelle visibilité pour une application est un moyen efficace
pour « Tester Juste » et ainsi améliorer quatre dimensions de sa validation :
S’assurer avant le lancement des tests que le produit est au niveau de
qualité exigé.
Augmenter l’efficacité des activités de tests.
Maitriser les risques de mise en production.
Faciliter la gestion des risques projets.
L’étude des radiographies de plusieurs centaines d’applications représentant plus
de 100 millions de lignes de code montrent l’effet de levier que représente cette
visibilité pour la validation. Car lorsque cette approche « boite grise » laisse
entrevoir des difficultés, une approche traditionnelle de la validation de type
« boite noire » se traduit des risques non-maitrisés avec des retards
imprévisibles et des instabilités en production.
Copyright Kalistick 2010.Tous droits réservés.
www.kalistick.fr - contact@kalistick.fr
10