Accueil
Envoyer
Imprimer
Partager
Les applications deviennent de plus en plus complexes et les charges de développement s’accroissent en conséquence, entrainant l’accroissement des charges de test, des délais et des coûts de développement. S’il est vrai que certaines méthodes telles que le TDD (Test Driven Development, développement dirigé par les tests) sont recommandées par les méthodes agiles, le niveau d’indépendance des tests, de traçabilité vers les exigences et de profondeur des tests ne sont que rarement étudiés.
Comment pouvons-nous réduire les délais et les coûts, tout en augmentant la qualité des applications ? A première vue cela semble une équation insoluble, l’accroissement de la complexité engendrant mathématiquement un accroissement du développement et des tests. Pourtant, il peut en être autrement…
DES TESTS POUR LES DEVELOPPEURS ?
Depuis de nombreuses années, nous constatons un développement important des activités de test, et une tendance à séparer les activités de développement et de test. Cette tendance, soutenue par des organismes spécialisés dans les tests logiciels comme le CFTL et l’ISTQB, se fonde sur l’importance de disposer de plusieurs personnes s’assurant du niveau de qualité (par le biais de tests) avant la mise en production des logiciels développés.
Simultanément, nous remarquons que de nombreux organismes d’enseignement pour développeurs ne mettent l’accent ni sur les tests, ni sur l’analyse des causes de défaillances des logiciels, mais se focalisent sur d’autres aspects, comme les langages de programmation ou les nouvelles méthodologies telles que les développements agiles, Scrum etc.
Les applications deviennent de plus en plus complexes et les charges de développement s’accroissent en conséquence, entrainant l’accroissement des charges de test, des délais et des coûts de développement. S’il est vrai que certaines méthodes telles que le TDD (Test Driven Dévelopment, développement dirigé par les tests) sont recommandées par les méthodes agiles, le niveau d’indépendance des tests, de traçabilité vers les exigences et de profondeur des tests ne sont que rarement étudiés.
Comment pouvons-nous réduire les délais et les coûts, tout en augmentant la qualité des applications ? A première vue cela semble une équation insoluble, l’accroissement de la complexité engendrant mathématiquement un accroissement du développement et des tests. Pourtant, il peut en être autrement…
COMMENT LES DEFAUTS SONT-ILS INTRODUITS ?
L’introduction des défauts dans les logiciels s’effectue depuis le moment de la conception jusqu’à la fin du codage (y compris lors des corrections). Les humains étant imparfaits, ils font des erreurs. Ceci se traduit en défauts pouvant se trouver dans les exigences, les spécifications, l’architecture ou le code. Entre chaque phase de développement, un facteur multiplicateur doit être appliqué, reflétant l’accroissement du nombre de composants entre chaque phase : par exemple, une exigence tenant en une ligne se traduit en un plus grand nombre de spécifications, et un nombre encore plus grand de lignes de code. Si un défaut est introduit dans les spécifications, il est certain qu’il générera un nombre plus important de défauts dans les phases aval de développement.
Si nous étudions le graphique ci-dessous, nous voyons que la phase de capture des exigences commence avec 0 anomalie, en introduit 90, et que la revue de ces exigences permet d’en filtrer 65% (soit 59 anomalies) pour n’en laisser que 31. Le facteur multiplicatif de 1,5 implique, qu’en entrée du processus de conception générale, ces 31 anomalies d’exigences se transforment en 47 anomalies, auxquelles il faut ajouter les 120 anomalies introduites par le processus lui-même. On remarque que, malgré l’efficacité des processus de revue et de tests, il reste néanmoins une vingtaine d’anomalies en livraison.
Si nous n’avions pas effectué de revues dans les phases amont, le nombre d’anomalies aurait été nettement plus élevé (532 anomalies au lieu de 95 en début des tests de composants). Les phases de test auraient été plus coûteuses et plus longues pour atteindre le même objectif, ou auraient été de même durée, mais laissant plus de défauts dans le logiciel. Dans les deux cas, les clients et l’équipe de réalisation n’auraient pas été satisfaits.
Il est donc évident que la réduction du nombre de défauts introduits dans les phases amont du cycle de développement est la solution la plus rentable pour réduire le nombre total de défauts dans les logiciels. A charge pour les équipes de conception et de développement de réaliser des activités de tests, plus spécifiquement des revues et des tests unitaires.
REDUIRE EFFICACEMENT LES DEFAUTS ?
Souvent, les phases de tests unitaires et d’intégration sont réduites à leur plus simple expression, voire non exécutées, et les tests réels ne commencent qu’avec les tests système. Cependant, les développeurs sont toujours amenés à tester leur code lors des tests unitaires, et l’intégration des composants entre eux pendant les tests d’intégration. Une réduction efficace et rentable des défauts implique :
- que les défauts soient identifiés le plus tôt possible pour éviter qu’ils ne se propagent à des phases ultérieures de développement : la recherche des défauts dans les phases de conception doit être exécutée par les concepteurs, architectes, développeurs…
- que la charge de test soit la plus réduite possible : elle se doit d’être la plus précoce possible, par exemple, exécuter les tests dans des phases de tests unitaires (aussi appelés tests de composants) et dans les phases d’intégration (appelées tests d’intégration de composants).
Les développeurs, acteurs des phases des tests unitaires et d’intégration, devraient effectuer les tests pendant ces phases. S’il est vrai que cette problématique existe depuis plus de 30 ans et que diverses pratiques ont été proposées pour améliorer la qualité du développement, nous remarquons qu’elles ne sont pas suffisamment diffusées, ni appliquées. Il suffit de regarder le nombre de projets qui prennent plus de temps que prévu.
EST-CE RENTABLE ?
Il est évidemment coûteux de devoir revenir sur ce qui a été conçu pour le corriger, d’autant plus qu’il faut également prendre en compte les obligations de retest et de tests de non-régression nécessaires lors de la découverte et de la correction d’un défaut.
La rentabilité peut s’évaluer plus directement, en identifiant la différence de coût entre une anomalie identifiée tôt dans le cycle de production, et une anomalie découverte plus tard. Le gain entre une détection en phase de codage et en phase d’acceptation est de l’ordre d’un facteur 10 voire 100.
La rentabilité peut également s’estimer en termes de délais, et nous savons que les corrections d’anomalies retardent souvent les mises en production. Ceci implique du temps, non seulement pour effectuer ces corrections, mais aussi pour s’assurer que celles-ci n’ont pas engendré ou mis à jour d’autres anomalies (retest et tests de non-régression).
COMMENT FAIRE ?
L’implémentation d’une politique d’identification précoce des défauts est une décision du ressort de la direction informatique de l’entreprise, qui doit prendre en compte les coûts et les délais. Or, la plupart du temps, ces informations ne sont pas mesurées. Une politique de mesure des anomalies et d’utilisation des informations que ces anomalies contiennent est donc nécessaire, afin d’apporter les éléments factuels de rentabilité, spécifiques à chaque entreprise.
Une fois ces informations disponibles, il est nécessaire de mettre en place des processus de revue des livrables plus formels et plus efficaces. L’analyse du nombre d’anomalies permet du justifier des actions de formation aux tests et aux revues pour les développeurs. Elle permet également de formaliser les activités de développement, pour y inclure les activités de test unitaire et d’intégration.
En faisant ainsi, les équipes de tests peuvent se focaliser sur les tests système et d’acceptation, sans avoir à traiter un volume important de défauts, déjà identifié par les développeurs. A terme, cela génère :
- La réduction des temps de développement, en évitant d’introduire, puis de corriger des défauts
- La réduction des temps de tests, en se concentrant sur des défaillances plus complexes et des actions métier
- La réduction des coûts de maintenance, par une identification précoce des problèmes de maintenabilité
- L’augmentation de la qualité des livrables, par une réduction des défauts et une amélioration de l’efficacité des processus.
LE PRE-REQUIS DE LA DSI
Comme tout travail d’amélioration continue, pour être efficace et rentable, il est nécessaire qu’une décision de la hiérarchie soit prise pour mettre en œuvre de telles pratiques. Cela implique d’une part, une politique de mesures efficaces pour identifier de façon non ambigüe les coûts et facteurs de non qualité, présents à la fois dans les processus et dans les produits, et d’autre part, une volonté affichée et réelle d’améliorations mesurées, soutenue par la Direction des Systèmes d’Information et les équipes de gestion de projets.
Les techniques et méthodes permettant d’améliorer la qualité des tests unitaires et d’intégration sont connues, mais elles ne sont pas assez diffusées, ni implémentées. En l’absence des pré-requis mentionnés ci-dessus, il est illusoire de penser qu’une rentabilité accrue des développements et de leur qualité puisse avoir lieu et donner des résultats mesurables à long terme.
FAIRE SIMULTANEMENT MIEUX, MOINS CHER ET PLUS RAPIDEMENT, C’EST POSSIBLE
La rentabilité des développements peut s’envisager de deux manières : soit on fait mieux avec les ressources que l’on a, soit on cherche des ressources moins chères pour faire le même travail.
- Faire mieux avec les ressources que l’on a : cela consiste à rendre nos ressources plus efficaces pour éviter l’introduction de défauts. Cela passe par la mise en œuvre en amont de processus de revue avec des équipes de développeurs et de testeurs, à la mise en œuvre de tests unitaires et d’intégration, effectués par des développeurs et des testeurs certifiés de niveau supérieur (dont le niveau de connaissance a été certifié par un organisme indépendant comme le CFTL et l’ISTQB). Le tout doit, bien entendu, être compléter d’une boucle d’amélioration continue, visant à améliorer les processus en fonction des mesures obtenues précédemment.
- Chercher des ressources moins chères pour faire le même travail : il s’agit ici de mettre en place des solutions d’offshore. Mais l’expérience a montré que cette solution n’était pas – et de loin – la meilleure. En effet, elle entraine une perte de compétences internes, sans augmenter la qualité des logiciels produits, et nécessite de toute manière la mise en œuvre d’équipes de tests pour s’assurer de la qualité des produits conçus.
Faire simultanément mieux, moins cher et plus rapidement est tout à fait possible. Un certain nombre de sociétés le font déjà en s’appuyant sur les méthodes agiles, les processus de test normalisés ou Scrum. Cela implique simplement l’obligation pour les développeurs de connaître les techniques de test et les méthodes de revues. De plus il faut s’assurer que les processus de conception incluent des activités de vérification efficace de tous les livrables intermédiaires.
C’est un changement de vision, mais une solution efficace et rentable à plus long terme.
Bernard Homès Président du CFTL
Bernard Homès (53 ans) bénéficie d’une expérience de plus de 30 ans dans le domaine de la Qualité et des Tests de logiciels. Au cours de sa carrière, il a occupé différents postes clefs à dimension internationale, notamment en tant que Directeur de Centre de Tests rattaché à la direction générale de SMC International. Depuis 1999, il exerce en qualité de Consultant Senior « Environnement International Qualité et Tests de Logiciels » pour le compte d’entreprises renommées : Eurocopter, Alcatel Space, TESSCO ltd, Orange France ou encore CRIM.
Après des études en informatique à l’ISIB Bruxelles et un Master of Sciences in Computer Information Systems, obtenu en Angleterre, Bernard possède les certifications Certified Tester Advanced Level (Full), ISEB/ISTQB, iSQI et Certified REQB Professional – Ingénierie des Exigences, GASQ (Allemagne).
Il exerce également en tant qu‘intervenant en dernière année du Mastère, au sein de l’Ecole des Mines de Paris et de HEC, et a exercé aux Ecole des Mines de Douai, Nantes et Alès, et à l’ENST-B à Brest. Il dispense parallèlement de nombreuses conférences chaque année. Bernard Homès est impliqué au sein de différentes organisations professionnelles : membre du jury de l’Académie d’experts de France Télécom R&D, Président du groupe de travail et auteur du Syllabus Avancé de l’ITQSB, membre honoraire du bureau exécutif de l’IEEE France et membre fondateur de l’Association for Software Testing (USA), et du Global Association for Software Quality (GASQ).
Comment pouvons-nous réduire les délais et les coûts, tout en augmentant la qualité des applications ? A première vue cela semble une équation insoluble, l’accroissement de la complexité engendrant mathématiquement un accroissement du développement et des tests. Pourtant, il peut en être autrement…
DES TESTS POUR LES DEVELOPPEURS ?
Depuis de nombreuses années, nous constatons un développement important des activités de test, et une tendance à séparer les activités de développement et de test. Cette tendance, soutenue par des organismes spécialisés dans les tests logiciels comme le CFTL et l’ISTQB, se fonde sur l’importance de disposer de plusieurs personnes s’assurant du niveau de qualité (par le biais de tests) avant la mise en production des logiciels développés.
Simultanément, nous remarquons que de nombreux organismes d’enseignement pour développeurs ne mettent l’accent ni sur les tests, ni sur l’analyse des causes de défaillances des logiciels, mais se focalisent sur d’autres aspects, comme les langages de programmation ou les nouvelles méthodologies telles que les développements agiles, Scrum etc.
Les applications deviennent de plus en plus complexes et les charges de développement s’accroissent en conséquence, entrainant l’accroissement des charges de test, des délais et des coûts de développement. S’il est vrai que certaines méthodes telles que le TDD (Test Driven Dévelopment, développement dirigé par les tests) sont recommandées par les méthodes agiles, le niveau d’indépendance des tests, de traçabilité vers les exigences et de profondeur des tests ne sont que rarement étudiés.
Comment pouvons-nous réduire les délais et les coûts, tout en augmentant la qualité des applications ? A première vue cela semble une équation insoluble, l’accroissement de la complexité engendrant mathématiquement un accroissement du développement et des tests. Pourtant, il peut en être autrement…
COMMENT LES DEFAUTS SONT-ILS INTRODUITS ?
L’introduction des défauts dans les logiciels s’effectue depuis le moment de la conception jusqu’à la fin du codage (y compris lors des corrections). Les humains étant imparfaits, ils font des erreurs. Ceci se traduit en défauts pouvant se trouver dans les exigences, les spécifications, l’architecture ou le code. Entre chaque phase de développement, un facteur multiplicateur doit être appliqué, reflétant l’accroissement du nombre de composants entre chaque phase : par exemple, une exigence tenant en une ligne se traduit en un plus grand nombre de spécifications, et un nombre encore plus grand de lignes de code. Si un défaut est introduit dans les spécifications, il est certain qu’il générera un nombre plus important de défauts dans les phases aval de développement.
Si nous étudions le graphique ci-dessous, nous voyons que la phase de capture des exigences commence avec 0 anomalie, en introduit 90, et que la revue de ces exigences permet d’en filtrer 65% (soit 59 anomalies) pour n’en laisser que 31. Le facteur multiplicatif de 1,5 implique, qu’en entrée du processus de conception générale, ces 31 anomalies d’exigences se transforment en 47 anomalies, auxquelles il faut ajouter les 120 anomalies introduites par le processus lui-même. On remarque que, malgré l’efficacité des processus de revue et de tests, il reste néanmoins une vingtaine d’anomalies en livraison.
Si nous n’avions pas effectué de revues dans les phases amont, le nombre d’anomalies aurait été nettement plus élevé (532 anomalies au lieu de 95 en début des tests de composants). Les phases de test auraient été plus coûteuses et plus longues pour atteindre le même objectif, ou auraient été de même durée, mais laissant plus de défauts dans le logiciel. Dans les deux cas, les clients et l’équipe de réalisation n’auraient pas été satisfaits.
Il est donc évident que la réduction du nombre de défauts introduits dans les phases amont du cycle de développement est la solution la plus rentable pour réduire le nombre total de défauts dans les logiciels. A charge pour les équipes de conception et de développement de réaliser des activités de tests, plus spécifiquement des revues et des tests unitaires.
REDUIRE EFFICACEMENT LES DEFAUTS ?
Souvent, les phases de tests unitaires et d’intégration sont réduites à leur plus simple expression, voire non exécutées, et les tests réels ne commencent qu’avec les tests système. Cependant, les développeurs sont toujours amenés à tester leur code lors des tests unitaires, et l’intégration des composants entre eux pendant les tests d’intégration. Une réduction efficace et rentable des défauts implique :
- que les défauts soient identifiés le plus tôt possible pour éviter qu’ils ne se propagent à des phases ultérieures de développement : la recherche des défauts dans les phases de conception doit être exécutée par les concepteurs, architectes, développeurs…
- que la charge de test soit la plus réduite possible : elle se doit d’être la plus précoce possible, par exemple, exécuter les tests dans des phases de tests unitaires (aussi appelés tests de composants) et dans les phases d’intégration (appelées tests d’intégration de composants).
Les développeurs, acteurs des phases des tests unitaires et d’intégration, devraient effectuer les tests pendant ces phases. S’il est vrai que cette problématique existe depuis plus de 30 ans et que diverses pratiques ont été proposées pour améliorer la qualité du développement, nous remarquons qu’elles ne sont pas suffisamment diffusées, ni appliquées. Il suffit de regarder le nombre de projets qui prennent plus de temps que prévu.
EST-CE RENTABLE ?
Il est évidemment coûteux de devoir revenir sur ce qui a été conçu pour le corriger, d’autant plus qu’il faut également prendre en compte les obligations de retest et de tests de non-régression nécessaires lors de la découverte et de la correction d’un défaut.
La rentabilité peut s’évaluer plus directement, en identifiant la différence de coût entre une anomalie identifiée tôt dans le cycle de production, et une anomalie découverte plus tard. Le gain entre une détection en phase de codage et en phase d’acceptation est de l’ordre d’un facteur 10 voire 100.
La rentabilité peut également s’estimer en termes de délais, et nous savons que les corrections d’anomalies retardent souvent les mises en production. Ceci implique du temps, non seulement pour effectuer ces corrections, mais aussi pour s’assurer que celles-ci n’ont pas engendré ou mis à jour d’autres anomalies (retest et tests de non-régression).
COMMENT FAIRE ?
L’implémentation d’une politique d’identification précoce des défauts est une décision du ressort de la direction informatique de l’entreprise, qui doit prendre en compte les coûts et les délais. Or, la plupart du temps, ces informations ne sont pas mesurées. Une politique de mesure des anomalies et d’utilisation des informations que ces anomalies contiennent est donc nécessaire, afin d’apporter les éléments factuels de rentabilité, spécifiques à chaque entreprise.
Une fois ces informations disponibles, il est nécessaire de mettre en place des processus de revue des livrables plus formels et plus efficaces. L’analyse du nombre d’anomalies permet du justifier des actions de formation aux tests et aux revues pour les développeurs. Elle permet également de formaliser les activités de développement, pour y inclure les activités de test unitaire et d’intégration.
En faisant ainsi, les équipes de tests peuvent se focaliser sur les tests système et d’acceptation, sans avoir à traiter un volume important de défauts, déjà identifié par les développeurs. A terme, cela génère :
- La réduction des temps de développement, en évitant d’introduire, puis de corriger des défauts
- La réduction des temps de tests, en se concentrant sur des défaillances plus complexes et des actions métier
- La réduction des coûts de maintenance, par une identification précoce des problèmes de maintenabilité
- L’augmentation de la qualité des livrables, par une réduction des défauts et une amélioration de l’efficacité des processus.
LE PRE-REQUIS DE LA DSI
Comme tout travail d’amélioration continue, pour être efficace et rentable, il est nécessaire qu’une décision de la hiérarchie soit prise pour mettre en œuvre de telles pratiques. Cela implique d’une part, une politique de mesures efficaces pour identifier de façon non ambigüe les coûts et facteurs de non qualité, présents à la fois dans les processus et dans les produits, et d’autre part, une volonté affichée et réelle d’améliorations mesurées, soutenue par la Direction des Systèmes d’Information et les équipes de gestion de projets.
Les techniques et méthodes permettant d’améliorer la qualité des tests unitaires et d’intégration sont connues, mais elles ne sont pas assez diffusées, ni implémentées. En l’absence des pré-requis mentionnés ci-dessus, il est illusoire de penser qu’une rentabilité accrue des développements et de leur qualité puisse avoir lieu et donner des résultats mesurables à long terme.
FAIRE SIMULTANEMENT MIEUX, MOINS CHER ET PLUS RAPIDEMENT, C’EST POSSIBLE
La rentabilité des développements peut s’envisager de deux manières : soit on fait mieux avec les ressources que l’on a, soit on cherche des ressources moins chères pour faire le même travail.
- Faire mieux avec les ressources que l’on a : cela consiste à rendre nos ressources plus efficaces pour éviter l’introduction de défauts. Cela passe par la mise en œuvre en amont de processus de revue avec des équipes de développeurs et de testeurs, à la mise en œuvre de tests unitaires et d’intégration, effectués par des développeurs et des testeurs certifiés de niveau supérieur (dont le niveau de connaissance a été certifié par un organisme indépendant comme le CFTL et l’ISTQB). Le tout doit, bien entendu, être compléter d’une boucle d’amélioration continue, visant à améliorer les processus en fonction des mesures obtenues précédemment.
- Chercher des ressources moins chères pour faire le même travail : il s’agit ici de mettre en place des solutions d’offshore. Mais l’expérience a montré que cette solution n’était pas – et de loin – la meilleure. En effet, elle entraine une perte de compétences internes, sans augmenter la qualité des logiciels produits, et nécessite de toute manière la mise en œuvre d’équipes de tests pour s’assurer de la qualité des produits conçus.
Faire simultanément mieux, moins cher et plus rapidement est tout à fait possible. Un certain nombre de sociétés le font déjà en s’appuyant sur les méthodes agiles, les processus de test normalisés ou Scrum. Cela implique simplement l’obligation pour les développeurs de connaître les techniques de test et les méthodes de revues. De plus il faut s’assurer que les processus de conception incluent des activités de vérification efficace de tous les livrables intermédiaires.
C’est un changement de vision, mais une solution efficace et rentable à plus long terme.
Bernard Homès Président du CFTL
Bernard Homès (53 ans) bénéficie d’une expérience de plus de 30 ans dans le domaine de la Qualité et des Tests de logiciels. Au cours de sa carrière, il a occupé différents postes clefs à dimension internationale, notamment en tant que Directeur de Centre de Tests rattaché à la direction générale de SMC International. Depuis 1999, il exerce en qualité de Consultant Senior « Environnement International Qualité et Tests de Logiciels » pour le compte d’entreprises renommées : Eurocopter, Alcatel Space, TESSCO ltd, Orange France ou encore CRIM.
Après des études en informatique à l’ISIB Bruxelles et un Master of Sciences in Computer Information Systems, obtenu en Angleterre, Bernard possède les certifications Certified Tester Advanced Level (Full), ISEB/ISTQB, iSQI et Certified REQB Professional – Ingénierie des Exigences, GASQ (Allemagne).
Il exerce également en tant qu‘intervenant en dernière année du Mastère, au sein de l’Ecole des Mines de Paris et de HEC, et a exercé aux Ecole des Mines de Douai, Nantes et Alès, et à l’ENST-B à Brest. Il dispense parallèlement de nombreuses conférences chaque année. Bernard Homès est impliqué au sein de différentes organisations professionnelles : membre du jury de l’Académie d’experts de France Télécom R&D, Président du groupe de travail et auteur du Syllabus Avancé de l’ITQSB, membre honoraire du bureau exécutif de l’IEEE France et membre fondateur de l’Association for Software Testing (USA), et du Global Association for Software Quality (GASQ).
