Tribunes

Amélioration des processus de tests logiciels : une prise de conscience est nécessaire et urgente !

De nombreuses publications se sont penchées sur l'amélioration des processus de développement de logiciels. Souvent, les techniques présentées sont associées aux tests et permettent à l'entreprise de faire face aux défis futurs en termes de qualité du logiciel, telles que l'amélioration de la qualité du produit, du rendement et de l'efficacité des activités de tests, tout en réduisant la durée et le coût des activités de développement et de test.

Cet article offre au lecteur une référence en matière de modèles et méthodes d'amélioration de processus, tout en le rendant conscient des défis et des faiblesses propres à l'implémentation de chacun des modèles, selon le contexte.

PublicitéVers un modèle de rentabilisation pour l'amélioration de processus

L'objectif d'une amélioration de processus est d'optimiser le rendement du processus de production, tout en obtenant un produit final de meilleure qualité. Le domaine de qualité de logiciel peut tirer profit de l'expérience d'industries plus matures (automobile, aérospatiale, etc.) et des techniques implémentées dans ces industries (kanban, inspection du premier article, etc.).

Il est évidemment impossible de transposer directement une technique d'amélioration destinée à l'industrie manufacturière à l'industrie logicielle. Pour adapter efficacement des techniques du secteur manufacturier à l'industrie logicielle, il est important d'en comprendre le mode de fonctionnement, le contexte et les aspects contribuant à son succès. Il sera possible d'évaluer par la suite si la technique est transférable au secteur logiciel, et quelles modifications doivent être apportées pour ce nouveau contexte. Par conséquent, une évaluation du retour sur l'investissement s'impose pour sélectionner la meilleure technique dans le contexte.

Faut-il s'engager ou non dans des techniques d'amélioration de processus? La question mérite d'être posée, car beaucoup de développements logiciels sont des développements uniques, dans un contexte spécifique qui ne se reproduira probablement pas. Néanmoins, même si un contexte identique ne se reproduira pas, il est certain que les processus de conception, de réalisation, de test et de maintenance des logiciels sont similaires, et que les défauts dans les processus se reproduiront dans le futur. Toute amélioration de ces processus sera donc un investissement avec une visée à long terme.

Quelle technique ou méthode utiliser ? Quotidiennement de nouvelles techniques et méthodes arrivent sur le devant de la scène, proposées par tel ou tel consultant, société ou groupement. Chacune promet de faire mieux que ses concurrentes. Comment y voir clair

Il est toujours préférable d'être engagé dans des initiatives d'amélioration mais il ne s'agit pas de succomber à toutes les nouvelles tendances dans l'industrie. De même, il est nécessaire de reconnaître les processus déjà efficaces pour se pencher sur les processus qui vont bénéficier de ces initiatives d'amélioration. Cet exercice nous force à mesurer nos processus actuels, à les évaluer, afin de choisir des méthodes d'amélioration et de fixer des objectifs pour vérifier conséquemment l'atteinte de ces objectifs.

Que savons-nous vraiment ?

Nous savons tous que la surface d'un liquide est horizontale. Nous l'avons appris dès notre plus jeune âge et nous ne remettons pas en question cet apprentissage. Nous savons également que la terre est ronde et que la majeure partie de sa surface est recouverte par de l'eau. Donc puisque la terre n'est pas plate, les deux affirmations peuvent-elles être vraies en même temps ?

PublicitéEn l'observant à l'aide d'un microscope assez puissant, la surface d'un liquide apparaît alors comme une couche inégale de molécules d'eau, ou une collection de neutrons, de protons et d'électrons en orbite dans le vide. Alors, la surface de l'eau est-elle sphérique, plate, inégale?

Cet exemple illustre bien que notre connaissance est basée sur un certain nombre d'hypothèses, desquelles nous sommes à peine conscients. Le seul moyen pour valider nos hypothèses demeure l'usage de métriques. Notre choix de métriques doit demeurer indépendant de nos suppositions, croyances ou pensées. De même notre choix de métrique doit refléter un usage, une utilisation raisonnable, adaptée aux besoins de notre projet, de notre organisation. Nous ne sommes pas payés par notre employeur pour supposer, deviner ou croire. Dans nos fonctions, nous sommes rémunérés pour présenter des preuves claires, applicables à notre contexte, et permettant de prendre des décisions en temps utile.

Suppositions et rôles

Suppositions et rôles

Revoyons nos hypothèses au sujet de l'amélioration des processus. L'amélioration du processus est perçue par le testeur comme un moyen d'améliorer l'efficacité du procédé de détection d'anomalies, que ce soit par des revues (d'exigences, de spécifications, d'architecture, de code, etc.), des tests boite noire ou boite blanche, des activités de test manuelles ou automatisées, structurées et systématiques ou agiles et exploratoires, etc. Certains testeurs, supposent être responsables de la qualité du logiciel développé, alors que ce devrait être l'affaire de tous, depuis la définition initiale des exigences jusqu'à la fourniture de l'application en production.

D'un point de vue global, il serait plus efficace d'éviter l'introduction de défauts dans le produit plutôt que de les filtrer plus en aval dans le processus (test). Après tout, en évitant d'introduire des défauts dans le code, écrire le code pourrait prendre moins longtemps (temps d'entrée du code erroné plus court). Les efforts de test seraient plus efficaces. La responsabilité de la qualité reposerait alors sur l'équipe de développement, ou sur des processus d'assurance qualité à plus haut niveau.

D'un autre côté, le département d'assurance qualité pourrait bien être tenu responsable de la qualité. Cependant, son objectif se limite généralement à s'assurer que les standards et règlements soient appliqués correctement. Son rôle n'est - généralement - pas de nature technique, ce ne sont ni des concepteurs, ni des testeurs. Selon leur vision, se conformer au processus assurera la qualité.

Au bout du compte, si ce ne sont ni les développeurs, ni les testeurs, ni l'assurance qualité qui sont en charge d'améliorer la qualité des produits et l'efficacité des processus, on pourrait en déduire que la qualité n'est l'affaire de personne, ce qui expliquerait l'augmentation des défauts dans le logiciels.

Dans certains environnements de production, comme la production automobile, des équipes de travailleurs se regroupent pour améliorer la qualité du produit et du processus. Cette façon de procéder est une illustration concrète de la déclaration « la qualité est l'affaire de tous ». Le contexte de production se prête bien à ce concept vu la nature répétitive du processus de production. La qualité est facilement mesurable aux prochains lots de production. Pour appliquer ce concept à l'industrie du logiciel, nous devons l'adapter au contexte.

Compétences

Voici la liste des compétences requises pour les ressources qui sont en charge de la qualité dans l'industrie logicielle :

- des compétences techniques, une compréhension des méthodes de développement, leurs limites et avantages, y compris le type de défauts qui sont introduits à chaque phase du cycle développement ;

- des compétences de test pour être en mesure de définir les activités nécessaires pour éliminer les défauts ;

- une compétence « assurance qualité » pour s'assurer que les évidences démontrant que les processus sont respectés et bien mesurés sont disponibles ;

- des compétences de type gestion et finance sont nécessaires à la gestion des risques et un retour sur l'investissement;

- une vision usager du produit pour s'assurer que les améliorations apportées au processus ont un impact positif sur le produit final ;

- une vision à long terme, compréhension de la contribution de chaque individu à la qualité pour assurer le maintien long terme du processus et du produit.

Il apparaît clairement qu'une personne avec un tel éventail de compétences (conception, test, qa, gestion et vision usager) est difficile à trouver. Or toutes ces compétences sont requises, ou alors les hypothèses de départ sont erronées. Comment se passent les choses dans l'industrie manufacturière?

Premièrement, des avancées majeures ne sont pas de mise, seuls des petits changements mesurés mèneront vers des améliorations. Chaque individu comprend son poste et sa contribution particulière à l'objectif de qualité globale. Cette situation est assurée en gardant les employés et en un engagement moral entre la compagnie et les employés, pour assurer le bien de chacun. Sans cet engagement, les employés fonctionneront en mode « mercenaire » et quitteront la société dès qu'une rémunération est meilleure ailleurs, sans s'investir dans une vision d'amélioration de la qualité à long terme.

Deuxièmement, toute suggestion présentée devrait être analysée sans idée préconçue fondée sur une position hiérarchique. Si un tel rejet arrive, cela pourrait être bien la dernière contribution proposée par cette ressource. De façon à s'assurer que des suggestions continuent à être proposées, une certaine forme de reconnaissance, que ce soit l'estime de ses pairs ou une reconnaissance pécuniaire, devrait revenir à ceux dont les idées ont été retenues.

À ce point, vous vous demandez où trouver un tel oiseau rare. Vous vous demandez également comment retenir une personne de ce calibre une fois que vous l'aurez trouvée et comment vous assurer que les améliorations continuent à porter leurs fruits à long terme plutôt que d'avoir des effets limités au trimestre ou à la prochaine promotion.

L'amélioration des processus au niveau hiérarchique

L'amélioration des processus au niveau hiérarchique

L'amélioration des processus est obligatoire au niveau hiérarchique, mais ceci n'est pas toujours possible si les délais alloués sont trop courts. De même, cela ne sera pas efficace si les managers se sentent menacés ou s'ils sont promus trop rapidement pour s'assurer que les changements mis en oeuvre ont été correctement adoptés par tous et font partie du modèle opérationnel quotidien.

Nous devons vaincre le "principe de peter [1]", où les gestionnaires se voient promus au-delà de leurs compétences, et trouver un moyen pour que les leçons apprises - au coût fort pour l'entreprise - soient prises en compte. Ceci est difficile, car nous devons surmonter cette recherche effrénée de solutions « quick wins » si courante dans notre société. Ces recherches de compensations rapides - sans investir des efforts pour anticiper les risques potentiels et les effets négatifs à long terme - sont trop fréquentes et résultent en des solutions mal pensées, inefficaces et devant être modifiées dans le futur. Il est aussi nécessaire d'anticiper l'effet de gel qui veut qu'une fois une décision prise - même mauvaise - il est difficile de la modifier car cela impliquerait une remise en cause des dirigeants ayant pris ces décisions. Donc les principes qui sont à la base des processus doivent être maîtrisés de façon à ce que le processus puisse être adapté et mis à jour selon les besoins et avec une pleine compréhension des implications.

Cette réaction typique, peut être illustrée de façon imagée. Si une personne pointe un objet du doigt, certain vont regarder l'objet désigné alors que d'autres regardent le doigt, passant à côté de la compréhension de la situation.

Vision globale

En cours d'amélioration de processus, il est possible d'agir sur un organisme vivant (l'entreprise), les actions dans un secteur vont avoir un impact sur les autres secteurs. Les testeurs peuvent comparer l'entreprise au logiciel, et comprendre que tout changement entraîne des effets secondaires (à évaluer).

Introduire des changements mineurs peut avoir plus de chances d'aboutir que d'imposer des changements majeurs. La raison est que l'on doit exécuter les processus modifiés pendant un certain temps ou un nombre de fois pour en comprendre et les subtilités et les impacts.

Si les changements s'avèrent négatifs, un processus de retour en arrière est plus facilement implantable en cas de changements mineurs, l'effet de gel ayant un impact moindre. Cependant une telle opération de retour arrière ne peut être menée efficacement dans des secteurs où les taux de remplacement de personnel sont élevés ou là ou la rétention de personnel est faible. Ceci est typique des environnements où le développement est sous-traité en offshore ou à des tiers (p.ex. Ssii), ou lors d'utilisation de consultants pour des missions courtes où ils ont des responsabilités de conception ou de direction.

Comment pouvons-nous nous assurer de quels processus améliorer et quels processus ne pas toucher? Comment devrions-nous sélectionner le processus et les activités à améliorer? Beaucoup d'auteurs, dont tom gilb [swi1993] et john d. Musa [sre2004], ont suggéré des manières de faire. Des analyses de risques et la mesure du retour sur investissement sont nécessaires pour que la sélection du processus soit cohérente. Une seule métrique ne suffit pas, plusieurs métriques concordantes sont obligatoires.

Métriques

Les métriques sont des définitions de choses que nous pouvons mesurer, les mesures étant des points sur cette échelle. Des mesures sont nécessaires pour identifier le(s) secteur(s) défaillant(s). L'analogie est similaire à un médecin qui évalue l'état de la santé d'un patient par un bilan, lequel est une série de mesures (température, pression sanguine, rythme cardiaque, etc.), parfois à un niveau plus approfondi (rayons-x, analyses sanguines ou d'autres fluides, etc.) pour vérifier si les symptômes correspondent à une pathologie.

Quand un diagnostic est établi, le médecin sélectionne le type de médicaments à utiliser pour guérir le patient. Dans l'amélioration des processus, nous avons des activités sont identiques : une mesure initiale de la santé de l'entreprise (le processus livre un produit qui présente des défaillances) puis nous essayons d'améliorer certains processus spécifiques (sélectionnés pour leur impact). Sans établir une mesure initiale qui servira de référence, il ne sera pas possible de comparer les mesures subséquentes et de confirmer la pertinence de l'amélioration.

Il est très important de s'assurer que des métriques soient définies et qu'une série de mesures initiales soient prises avant que l'amélioration du processus ne commence.

L'obtention de mesures permettra de sélectionner le processus à améliorer, ainsi que l'ordre dans lequel entreprendre les démarches. À partie de cette vision globale nous pourrons sélectionner d'abord les processus qui rapporteront d'avantages tant à long terme qu'à court terme. Cette approche permettra de poursuivre simultanément des objectifs à long terme et des objectifs à court terme, plutôt que l'un au détriment de l'autre.

Méthodes

Méthodes

Nous avons vu que l'amélioration de processus commence par une mesure initiale, suivie par la sélection des processus à améliorer (sur base de diverses mesures). Bien sûr, comme avec toute mesure de performance, en faisant disparaître un goulot d'étranglement précis (un processus non optimisé), un autre sera rendu apparent. Cette observation est valable, non seulement pour la mesure de performance des logiciels, mais aussi pour la gestion des processus critiques dans les environnements de production, tel que mentionné par eliyahu goldratt dans plusieurs de ses ouvrages [2].

Par conséquent, nous faisons face à une tâche sans fin consistant à identifier des goulots d'étranglement et à les supprimer dans la mesure du possible. Comparons les industries manufacturières avec la conception de logiciel : la production d'articles identiques, que ce soit des équipements, des composants ou des produits complets, suppose des processus généralement répétitifs, où l'optimisation des processus est permet une image « avant » et une image « après » (généralement améliorée ou optimisée). Dans l'industrie logicielle, nous n'avons pas le luxe de recréer le même code de façon itérative. Nous produisons, nous vérifions si le niveau de qualité est atteint, puis nous livrons le logiciel. Comme nous travaillons avec un processus non répétitif, toute solution d'amélioration de processus résultant de cette itération, impactera le projet suivant et non le projet actuel (à moins que la durée du projet permette de bénéficier de l'amélioration).

Du moment que nous reconnaissons que les activités d'amélioration des processus sont des activités à long terme, où les bénéfices escomptés seront obtenus dans le futur, en se basant sur des mesures dans le passé, nous serons capables d'avancer et d'atteindre un certain niveau d'amélioration. Il est évident qu'il y a certaines techniques et suggestions qui peuvent rendre la démarche plus douce et plus efficace.

Techniques

Un certain nombre de techniques peuvent être utilisées pour sélectionner les processus et les soumettre à une phase d'amélioration de processus. Ces techniques peuvent être regroupées selon les critères suivants :

- celles qui comparent la maturité des processus de l'organisation par rapport à un processus optimisé ou idéalisé défini par ailleurs, de sorte à ce que l'organisation puisse être comparée à une organisation plus mature (modèle de référence de processus) ;

- celles qui évaluent les processus de l'organisation en se basant sur les objectifs spécifiques de l'organisation, ce qui fait que les solutions d'une organisation ne peuvent pas être comparées aux solutions d'une autre organisation vu les différences de contexte (modèle de référence de contenu);

- celles qui évaluent les processus de l'organisation en se basant sur les objectifs du processus et essayent d'assurer l'atteinte de ces objectifs par la suite;

- celles qui évaluent les processus de l'organisation sur base de la qualité des produits livrés ;

- celles qui sélectionnent les processus sur base d'autres critères.

En se basant sur ces catégories principales, voyons quelle(s) technique(s) s'adapte(nt) le mieux à votre organisation.

Il est à noter que certaines techniques se prêtent mieux aux activités à long terme alors que d'autres sont plus appropriées pour des activités à court terme. En tant que personne en charge de l'amélioration du processus vous devrez vous assurer que les activités d'amélioration des processus à court et à long terme soient implémentées.

Retour d'expérience (REX)

Le retour d'expérience, parfois appelé leçons apprises ou post mortem, est un processus où les membres d'une équipe de projet (développement et test) se regroupent pour essayer de tirer des leçons utiles de leurs expériences d'un projet terminé. C'est une méthodologie très facile à implémenter et à gérer. Elle vous permet de lister les points forts du projet ainsi que des points faibles (ou à améliorer).

Fréquemment, aucune métrique n'est utilisée et l'information collectée est remontée par les participants pendant la réunion. Collecter, stocker et disséminer l'information pour qu'elle bénéficie à toute l'organisation peut être un souci.

L'implémentation nécessite que tous les membres de l'équipe soient réunis après la livraison du projet. Ceci peut être un défi car les membres de l'équipe sont souvent promus à d'autres projets ou ont quitté l'équipe (cas de consultants externes). De même, la mémoire humaine est sélective et l'on se souvient plus facilement des bons coups que des mauvais.

En termes d'expérience acquise, cette méthode bénéficie principalement aux membres de l'équipe si les recommandations ne sont pas stockées quelque part. En termes de mesures et de métriques, cette méthode ne requiert pas de preuves. Elle est subjective et peut laisser place à de mauvaises interprétations. Vu ce manque de mesures, le choix des processus à améliorer est fait sur des base d'opinions subjectives.

Pourcentage de détection de défaut (DDP)

Pourcentage de détection de défaut (DDP)

Cette méthode est mentionnée dans bon nombre d'ouvrages portant sur les tests logiciels. Pour être correctement utilisée, cette méthode requiert que le produit soit déployé en production depuis un certain temps. Ceci parce que les mesures (le nombre de défauts) devraient comprendre tous les défauts, y compris ceux rapportés par les utilisateurs.

Cependant, à la livraison du produit en production, la responsabilité est transférée de l'équipe de test à celle de support technique et les métriques ne sont pas toujours identiques. En plus, l'impact du défaut identifié sur l'usager (sa criticité) n'est pas pris en compte dans le calcul du dpp. Tous les défauts sont regroupés ensemble et leur agrégat est considéré comme base pour l'évaluation du dpp de chaque niveau de test.

Même si cette métrique est valable, elle laisse place à des usages et des interprétations erronées. Le nombre de défauts trouvés à un niveau de test ne fournit pas d'information au sujet de l'efficacité (ou le manque d'efficacité) des processus en question. Comme la cause à l'origine des défauts (c.à.d. la cause racine) n'est pas analysée, le processus à améliorer ne peut être identifié. En termes de mesures, l'évaluation ne peut être obtenue qu'après la fin du projet, donc trop tard pour le projet actuel

Analyse des causes racines (RCA)

L'analyse des causes racines est l'évaluation des causes à l'origine des anomalies. Cette évaluation peut arriver dès qu'un défaut est identifié, indépendamment du processus en cours. La technique rca peut s'exécuter à la phase de spécification, de conception et/ou de codage ou durant chacune des phases de test. Dès que le processus défaillant, celui qui est à l'origine du défaut (c.à.d. la cause racine) est identifié, ce processus peut être amélioré.

Implémenter la technique d'analyse des causes racines n'est pas un processus trivial; cela prend un certain temps et ne peut pas être exécuté pour chacun des défauts. En fait, ce n'est que sur une faible portion d'entre eux que cette technique peut s'appliquer. Ceci a un impact sur la représentativité statistique des résultats, vu que le processus « p » peut très bien être sélectionné à partir d'un seul défaut, alors qu'un grand nombre d'autres défauts pointe vers les autres processus.

Généralement, quand l'on utilise l'analyse des causes racines, ce n'est pas un seul processus qui est identifié comme racine unique du défaut, c'est plus souvent une combinaison de plusieurs facteurs. Rca identifie et liste tous les processus à améliorer. Il revient ensuite à l'ingénieur ou au spécialiste en assurance qualité de fixer l'ordre dans lequel traiter les processus. Cependant, comme le nombre de défauts impactés par le processus sélectionné n'est pas considéré, l'amélioration globale est subjective.

Amélioration du processus de test (TPI)

Tpi (test process improvement) est un modèle de référence créé par martin pol et tim koomen en hollande [tpi1999]. Il est caractérisé par une représentation continue de 20 secteurs clés. Chaque secteur clé est associé avec divers niveaux de maturité et dépend des autres secteurs. La représentation de base de tpi est une table comportant 20 lignes [3] (une par secteur clé) avec 13 colonnes (un par niveau de maturité). Les interdépendances entre les processus forcent l'amélioration de certains processus avant d'autres de sorte à qu'un niveau global de maturité plus élevé soit atteint.

Le modèle de référence de processus est cohérent et valide pour la majorité des organisations, mais l'emphase est mise sur des domaines (et des processus) qui pourraient être non essentiels pour votre contexte particulier. Pour une entreprise faisant l'acquisition et l'intégration de systèmes sous-traités au sein d'un système-de-systèmes, le processus de test de bas niveau (p.ex. tests boite blanche) peut être totalement non applicable, mais il est obligatoire pour le niveau b de tpi [4].

Tpi procure un cadre de travail intéressant ayant fait ses preuves en amélioration de processus, mais qui est limité à certaines entreprises et à des contextes spécifiques. De plus, tpi ne se focalise pas sur la fourniture d'améliorations mesurées : elle se limite à atteindre un certain niveau de maturité des processus de test. Cette amélioration du niveau de maturité est supposée associée à une amélioration de la qualité du produit et à un effet positif sur les processus mais aucune mesure n'est prise pour le confirmer. La facilité d'implémentation de tpi est aussi son point faible : le principe étant de s'assurer que tout le monde respecte un ensemble de processus standard, même s'ils ne sont pas adaptés à vos besoins.

L'absence de mesures de représentativité statistique de l'impact des défauts est aussi problématique, comme l'est l'absence de mesure initiale qui prive l'organisation de la possibilité de mesurer les bénéfices obtenus par le biais de cette méthode.

Processus de tests critiques (CTP)

Processus de tests critiques (CTP)

Introduite par rex black dans son ouvrage "critical testing processes" [ctp2004], cette méthode est principalement un modèle de référence de contenu. C'est une approche qui est sensible au contexte et peut adapter le modèle pour satisfaire vos besoins et votre contexte spécifique.

En définissant un processus « critique » comme un processus qui est soit répété fréquemment, soit qui affecte la capacité des testeurs de travailler ensemble, ou qui implique des pairs ou des tiers, ou un processus dont la défaillance aurait des conséquences négatives sérieuses, rex black fournit les moyens d'identifier les processus critiques dans votre contexte. Généralement, les processus de test critiques sont les suivants :

1 - Un processus de test complet et cohérent

2 - La compréhension du contexte

3 - L'identification des risques, à la fois sur le produit et sur le projet

4 - L'estimation de l'effort

5 - La planification des tests

6 - Une équipe de test cohérente et compétente

7 - Un environnement de test représentatif

8 - L'obtention d'une version de test du logiciel à tester

9 - L'exécution des tests

10 - Le reporting des anomalies

11 - La remontée des résultats

12 - La gestion des changements et des évolutions.

Si nous analysons tous les processus présents dans notre organisation en utilisant les définitions proposées, nous pourrions obtenir plus de 12 processus. Il est donc nécessaire d'allouer plus de temps à évaluer la criticité de chaque processus. L'expérience a démontré que ces 12 processus sont réellement les plus importants dans le cadre des tests. Ils peuvent être évalués et représentés sur un graphique. Cette approche permet d'identifier les processus à améliorer en priorité sur base de la valeur ajoutée qu'ils apportent à l'organisation. Des métriques - spécifiques à votre contexte, donc adaptés à votre organisation - doivent être définies pour établir une référence initiale et permettre ensuite de mesurer les améliorations atteintes. La méthode ctp requiert que l'évaluateur (l'assesseur) ait de l'expérience ainsi qu'une bonne compréhension du projet, car des processus importants pourraient être négligés si l'assesseur a une vision incomplète du projet ou de son contexte.

Méthodes basées sur les modèles de maturité (CMMI, TMMI, TMM, CMM)

Les améliorations basées sur les modèles de maturité sont dérivées du modèle cmm conçu par le software engineering institute (sei) aux usa. Ce modèle d'évaluation de la maturité des processus était initialement destiné à mesurer l'efficacité des fournisseurs de l'administration américaine. Le principe de base définit cinq niveaux de maturité. Chacun incluant un certain nombre de processus. Si tous les processus d'un niveau sont en place et exécutés, le niveau de maturité désigné est atteint.

Cmmi est une évolution de cmm et comprend une représentation étagée et une représentation continue.

Pour atteindre un niveau de maturité particulier, un certain nombre d'objectifs et de sous-objectifs maturité prédéfinis doivent être atteints. Ces objectifs sont définis en termes d'activités, de tâches et responsabilités et sont évalués selon des vues (des rôles) spécifiques telles que gestionnaire (manager), développeur/testeur et client/utilisateur.

Les processus à améliorer sont sélectionnés subjectivement par des décideurs, et ne représentent pas toujours le choix le plus opportun de processus à améliorer car ils ne sont pas basés sur le coût ou le retour sur investissement attendu au sein de votre organisation (votre contexte). Cependant, comme les modèles de maturité sont connus et utilisés à travers le monde, des tels modèles peuvent devenir la base d'initiatives d'amélioration de processus.

L'absence de lien direct entre les modèles de maturité et la qualité du produit livré, l'absence d'information en termes de causes racine (le processus à améliorer impacte-t-il la qualité?), Ni en termes de représentativité statistique (combien de défauts ont-ils été causés par ce processus?), Pose des questions sur la pertinence de ces méthode dans le cadre d'un objectif d'amélioration de la qualité des produits ou des processus.

Processus de test et d'évaluation systématique (step)

Processus de test et d'évaluation systématique (step)

Step, comme ctp mais contrairement à tpi et aux autres méthodes basées sur la maturité, n'exige pas que les améliorations suivent un certain ordre, cependant la planification doit se conformer aux documents portent sur les tests de logiciel ieee 829:1998 [ieee829:1998].

Une analyse détaillée de la méthode step permet de déterminer que cette méthode est valide pour générer des tâches de test et d'évaluation d'un produit logiciel. Elle ne propose aucune manière d'améliorer le processus actuel. Dans leur ouvrage "systematic software testing" [sst2007], où ils décrivent la méthode step, les auteurs craig et jaskiel proposent les 8 étapes suivantes en vue d'améliorer les processus de test :

1 - Mesurer les pratiques courantes

2 - Définir une vision et des objectifs

3 - Formuler et prioriser les exigences

4 - Établir un projet

5 - Développer une planification cohérente

6 - Introduire les changements de façon incrémentale

7 - Mesurer les résultats obtenus de ces changements

8 - Retour à l'étape 1.

Même si ce processus est formel, il est clairement établi et prend en compte une certaine mesure d'itération, mais ces mesures n'arrivent qu'en avant dernière position, sans avoir défini un état initial de référence. L'étape1, « mesurerles processus actuels » ne requiert pas de mesure, ni d'évaluation de l'efficacité des processus déjà implémentés. Les changements implémentés graduellement l'un après l'autre de façon à identifier les améliorations résultantes, permettent un certain retour arrière si les résultats obtenus sont non concluants.

Le souci principal avec la méthode step est son lien fort avec des pratiques de documentation des activités de test, parfois sans rapport avec les besoins réels et des pratiques de développement utilisées (p.ex. Agile vs. cycle en v)

Cycles PDCA (planifier définir contrôler agir), improve et ideal

Le cycle pdca d'edward deming est d'un usage très répandu. Ce méta-modèle a servi de base à de nombreux autres modèles. La sélection des processus à améliorer devrait se baser sur certaines métriques et ceux-ci dépendront des objectifs initiaux de la direction ou de l'encadrement.

Le cycle improve a été introduit dans le syllabus istqb niveau avancé (v2007), et représente une évolution de la méthodologie pdca. Il s'applique à tout modèle de processus et s'énonce tel que suit:

1 - Initialisation : le modèle de processus qui servira de base pour les améliorations sera sélectionné et/ou défini, ainsi que les critères de succès. Ceci peut l'être par rapport à une référence connue (métriques) ou en termes d'atteinte d'objectifs ;

2 - Mesure : on sélectionne l'approche des mesures et les processus précis à améliorer ;

3 - Prioriser & planifier : les processus à améliorer sont priorisés, en se basant sur une analyse de risque ou tout autre moyen de sélection en utilisant les mesures prises précédemment (point 2) ;

4 - Définir & redéfinir : les raffinements d'amélioration des processus sont décrits et prêts à être implémentés ;

5 - Opérer : les processus améliorés sont implémentés et déployés ;

6 - Valider : de nouvelles mesures sont prises pour s'assurer de l'atteinte des objectifs ;

7 - Évoluer : une décision est prise d'aller - ou non - au niveau de maturité suivant (si le modèle du processus inclut des niveaux de maturité) ou d'entreprendre une nouvelle boucle d'améliorations, ou d'arrêter les activités d'amélioration si les objectifs sont atteints.

Le cycle idéal, proposé par l'ISTQB dans les syllabus ISTQB niveau expert et niveau avancé test manager (v2012), propose une évolution de PDCA moins détaillée que le modèle improve, avec les processus suivants :

1 - Initialisation du processus d'amélioration

2 - Diagnostiquer l'état de la situation actuelle

3 - Établir un plan d'amélioration des processus

4 - Agir pour mettre en oeuvre les améliorations

5 - Tirer les leçons du programme d'améliorations.

La sélection de la méthodologie, et critères de sélection des processus à améliorer est laissée au choix de l'organisation.

Ces méta-modèles, ainsi que d'autres similaires, présentent l'avantage de pouvoir être implémentés dans d'autres modèles de processus et possiblement sur des métriques valides. D'un autre côté, il est aussi possible d'implémenter ces méta-modèles en se limitant à des mesures et des processus ad-hoc.

La sélection des processus à améliorer peut être subjective, sans se baser sur le nombre de défauts et leur criticité, ou elle peut être objective. Une gestion des risques et une bonne gestion - basée sur des métriques plutôt que sur des sentiments - permettront de focaliser les améliorations sur certains processus plutôt que d'autres.

Ceci implique une bonne connaissance de votre propre contexte, avec un nombre suffisant de métriques adéquates, de façon à éviter que la sélection des processus soit biaisée.

Classification orthogonale des défauts (ODC)

Classification orthogonale des défauts (ODC)

La méthode odc, de classification orthogonale a été initialement développée au sein d'ibm et lie les défauts aux processus qui en sont la cause. Odc est basé sur la considération que, dans un modèle de développement comprenant des processus de conception et de vérification, les défauts sont introduits par certains processus et ôtés par d'autres (revues, tests). Le calcul du nombre de défauts générés par chaque processus permet aux manager de sélectionner le(s) processus à améliorer. L'application de gestion d'anomalies de l'entreprise est utilisée comme support à ce processus, et doit être adaptée en ajoutant quelques champs d'information à compléter par les testeurs (identification du défaut & impact) ou par les développeurs (localisation du défaut et quelques autres champs).

Le principe derrière la méthode odc repose sur deux constats. D'un côté, l'identification de la cause racine permet d'identifier le processus à améliorer (les processus à l'origine des défauts, et tout autre processus entre l'origine et la découverte). Cependant les analyse des causes racines sont coûteuses et ne sont effectuées que pour certains défauts (p.ex. les plus impactants) et pas pour d'autre. Il n'y a donc aucune garantie que les processus identifiés soient réellement les plus importants à corriger. Odc propose donc une analyse simplifiée des causes racines, en associant les typologies de défauts aux processus qui sont généralement à l'origine de ces défauts.

L'autre constat est qu'il est important d'identifier et de sélectionner les processus à améliorer en fonction des avantages que l'organisation peut tirer. Donc améliorer un processus qui a généré un seul défaut évalué à 100 unités de coût est peut-être moins rentable à améliorer qu'un autre processus qui a généré 75 défauts d'un coût de 20 unités. Baser la sélection des processus sur base du nombre de défauts garantit une représentativité statistique correcte et la sélection du/des processus à améliorer de façon prioritaire (le plus grand nombre de défauts, ou les coûts agrégés les plus élevés).

Un bénéfice supplémentaire de la méthode odc est que l'on peut évaluer la maturité des produits sur base de la typologie des anomalies identifiées dans les processus. Il est donc plus facile pour la hiérarchie de prendre des décisions de « go/no go » sur la base d'informations fiables et représentatives.

Pour correctement implémenter la méthode odc au sein d'une organisation, il est nécessaire de l'adapter aux processus actuellement en place. Il faut en effet établir une correspondance entre les descriptions de processus génériques d'odc et celles des processus de l'organisation. Après avoir établi cela, le travail sur les défauts peut commencer. L'implémentation d'odc, nécessite de rajouter huit champs dans l'outil de suivi des anomalies, et de les renseigner pour toutes les anomalies. Il est coûteux et inefficace de reprendre la liste des défauts passés, mais il peut être rentable d'implémenter cela pour les nouveaux défauts, ce qui donnera une vision sur les défauts futurs.

Avec la méthode odc, la cause racine est limitée à un seul type de cause (d'où l'orthogonalité), et par conséquent les processus identifiés pourraient ne pas être les bons. Établir une correspondance entre type de défaut et processus qui l'engendre prend du temps et nécessite des intervenants ayant une bonne compréhension à la fois des méthodes et des processus de développement et des techniques et processus de test. L'obtention de résultats pertinents n'est pas immédiate, et il est nécessaire de vérifier périodiquement si le processus sélectionné comme cause racine est effectivement à l'origine du défaut pour s'assurer que les statistiques sont pertinentes.

La méthode odc est généralement appropriée quand un nombre importants d'anomalies est présent, puisqu'il peut produire des statistiques et des graphiques qui se prêtent moins à l'interprétation subjective.

Processus de sélection

Processus de sélection

Dans les sections précédentes, nous avons passé en revue les diverses méthodes d'amélioration de processus présentes. Il est maintenant nécessaire de choisir l'une ou plusieurs d'entre elles pour améliorer nos processus de test. Le critère de sélection dépend à la fois du contexte et d'objectifs clairement établis.

Quand nous nous fixons des objectifs d'amélioration, nous ne souhaitons pas attendre trop longtemps pour que les changements portent des fruits. Nous voulons que les changements de processus aient un impact positif relativement rapidement. Évidemment, ces changements ne se font pas du jour au lendemain, mais il ne faudrait pas devoir attendre tout une année non plus pour en voir les résultats.

La sélection d'un schéma d'amélioration peut être utilisée pour des raisons marketing, comme en témoigne l'engouement que des schémas comme cmmi, iso9000 ou en9000 ont eu pour certaines organisations. Dans cet article, nous nous limiterons à considérer l'efficacité, la rentabilité et le retour sur investissement réel pour l'entreprise, sans prendre en compte les avantages commerciaux ou marketing que la conformité à un modèle apporte à l'organisation.

Tout processus basé sur un modèle de maturité peut impliquer la mise en oeuvre de tâches qui ne procureront aucune amélioration dans notre contexte, mais qui sont néanmoins requis par le modèle de maturité sélectionné. Si notre organisation correspond au modèle ayant servi de base au modèle de maturité, alors l'implémentation du modèle de maturité est relativement facile et des améliorations à long terme se manifesteront probablement si le modèle est correctement et complètement appliqué.

Les processus d'amélioration basés sur une mesure et une évaluation des processus de l'organisation et des risques existants seront plus facilement adaptables et génèrent plus rapidement des résultats utiles. Cependant, comme le contexte et l'organisation évoluent, les taux d'amélioration vont se réduire avec le temps, ce qui amènera à l'identification et à la sélection d'un nouvel ensemble de mesures d'amélioration de processus.

Les méthodes faciles à implanter telles que le retour sur l'expérience (rex) et les méthodes subjectives telles que pdca, ideal et improve produisent des résultats de moindre envergure à très court terme, mais les améliorations à long terme sont généralement faibles. Par contre, la mise en place d'une culture d'entreprise axée sur une amélioration continue (et donc impliquant des itérations de mesure et d'actions d'amélioration) génèrera des bénéfices substantiels à long terme, des changements dans l'entreprise qui ne sont pas à négliger.

Les méthodes d'amélioration basées sur un nombre réduit de facteur telle l'analyse des causes racines (rca), génèrent des améliorations, mais ne traitent pas un grand nombre de processus simultanément. Nous voyons parfois certains processus très développés alors que d'autres ne le sont pas. Une analyse complète du processus de développement s'impose pour s'assurer que les améliorations sont cohérentes à travers l'organisation, et n'oublient pas certains processus au dépend d'autres.

Les améliorations basées sur des normes ou des standards, tel que step, sont habituellement aussi efficaces que la norme elle-même. Si la norme est applicable et qu'elle l'est effectivement, les résultats sont impressionnants. Les résultats vont dépendre de la manière dont le standard est interprété et comment il est implémenté dans l'organisation.

La mise en oeuvre de modèles sur base de données statistiquement représentatives (p.ex. nombre de défauts trouvés au cours du temps) appliqués aux processus ayant causé ces défauts, représente une solution qui s'assure que les ressources limitées allouées à l'amélioration de processus ciblent correctement les améliorations les plus rentables. La validité d'une analyse odc se trouve renforcée avec le nombre de défauts trouvés, par conséquent, elle s'améliore avec le temps (plus de défauts trouvés). De la même manière, il est important de sélectionner une méthode qui soit pragmatique et se focalise sur les processus pour lesquels les améliorations fourniront la meilleure rentabilité et le retour sur investissement le plus rapide.

La sélection de la méthodologie d'amélioration des processus peut devoir aussi prendre en compte les besoins de gains à court terme, à long terme, ou à court et long terme. Rien n'interdit d'utiliser plusieurs méthodes d'amélioration de processus simultanément, pour autant que l'on identifie correctement toutes les interactions entre ces méthodes.

Processus d'implémentation

L'implémentation dépend de la méthode sélectionnée. Dans tous les cas, vous voudrez vous assurer que les améliorations sont mesurables. Ceci implique de définir un certain nombre de métriques et surveiller leur évolution dans le temps. Ainsi, les impacts de la méthode d'amélioration seront mesurés et la rentabilité, l'efficacité et le retour sur investissement des différentes méthodes pourra être évalué sans être subjectif.

L'implémentation de la méthode retour sur l'expérience (rex) est facile : une revue lors des jalons majeurs ou à la fin du projet est suffisante. Les leçons apprises devraient être sauvegardées dans une sorte de base de connaissances pour être disponibles au début de tout nouveau projet - d'un contexte similaire - là où c'est applicable. Si le nouveau projet n'applique pas les leçons apprises - alors qu'elles seraient applicables - l'effort d'amélioration aura été inutile.

L'implémentation de l'analyse de la cause racine est plus technique que rex et l'information acquise peut être appliquée directement dans le projet courant. Une implémentation rca est un processus qui prend du temps et qui ne reflète qu'un nombre limité de causes racines. Si les causes racines résident toutes dans le même processus, encore mieux, si les causes racines sont éparpillées à travers de multiples processus, il est plus difficile de choisir ceux à améliorer. Les mesures, métriques et statistiques recueillies devraient aider à sélectionner le processus. D'autres métriques vous permettront de vérifier si les mesures d'amélioration ont produit le résultat escompté en termes de qualité et réduction de coût.

Les processus basés sur les modèles de maturité sont très bien documentés dans des articles et des livres et l'adaptation au contexte est simple. Les améliorations ne sont pas garanties mais l'usage étendu de ce modèle semble indiquer qu'il est avantageux (à moins que nous ne soyons face à un effet de mode). Il est fortement recommandé de mesurer l'efficacité et la rentabilité des processus - établir une baseline - avant le début des activités d'amélioration des processus et de mesurer périodiquement après l'implémentation des améliorations de processus.

L'implémentation d'un modèle basé sur une norme (p.ex. Step) est aussi facile que pdca, ideal et improve, voire que l'implémentation d'un modèle de maturité à référentiel externe. Dès que la définition des métriques et la sélection des processus ont été effectuée, le reste se résume à de la simple gestion de projet. La sélection des processus étant associée à un contexte qui peut ne pas être le votre peut amener à une remise en question de la rentabilité.

L'implémentation d'odc est plus longue, mais amène généralement des résultats durables. La première étape consiste à identifier les processus de développement existants et à les mapper aux processus odc. Ceci implique une analyse des processus de l'entreprise et une bonne connaissance de la méthode odc. Ensuite nous adapterons l'outil de gestion des anomalies et demanderons aux développeurs et testeurs de remplir les champs ajoutés. En général, le remplissage des huit champs ne prend qu'une ou deux minutes par défaut au testeur et l'information sera disponible pour le développeur au moment de traiter le défaut. La troisième étape consiste à générer les statistiques adéquates à partir des données obtenues. Cette étape est directe et peut être effectuée à l'aide de feuilles de calcul et de graphiques (p.ex. Excel) ce qui permettra d'évaluer les bénéfices atteints et de prendre des décisions à partir de données fiables.

Contrôle de l'implémentation

Contrôle de l'implémentation

Contrôler l'implémentation des diverses activités liées à l'amélioration des processus transversalement dans l'organisation implique des mesures et une surveillance de ces processus. Pour cela, les métriques doivent être recueillies et surveillées, de sorte que tout écart soit identifié rapidement, étudié et remédié si besoin.

Le contrôle de l'implémentation devrait être fait périodiquement, avec des délais suffisamment courts pour intervenir rapidement en cas de déviation des résultats observés par rapport aux résultats attendus.

Amélioration et fiabilité du logiciel

À travers les actions entreprises dans le cadre d'un processus d'amélioration, il faut aussi que la fiabilité du produit final s'accroisse. Les métriques peuvent être utilisées pour mesurer la fiabilité du produit à travers le temps, la formule r(t)) selon [sre2004] : r(t) = 1 - f(t); où f(t) est la probabilité d'échec selon la période de temps.

La fiabilité dépend de l'usage du produit. Un produit non utilisé pendant un mois ne risque pas de mal fonctionner pendant ce temps. Il est donc nécessaire de considérer à la fois le temps d'exécution (temps d'utilisation réel) et le temps calendaire (temps de présence mais pas spécialement d'utilisation). Ceci est vrai aussi pour les processus : si les processus de revue sont améliorés mais qu'aucune revue n'est effectuée durant la période de référence, il sera impossible de noter l'amélioration.

Pour mesurer correctement l'implémentation de mesures d'amélioration de processus, il faut prendre comme référence une période de temps suffisamment longue pour être représentative.

Améliorations et métriques

De nombreux indicateurs permettent de mesurer l'amélioration des processus. La plupart sont mentionnés dans des standards comme la norme qualité iso 9126. Ces indicateurs peuvent être des métriques de qualité externes [iso91262] ou des métriques de qualité internes [iso91263]. Les méthodes de calcul de métriques sont expliquées en détail dans ces deux rapports techniques.

La comparaison des métriques sur une période donnée est également importante car elle permet de détecter des évolutions dans le temps, des tendances, et de vérifier la vitesse de mise en oeuvre des changements et l'évolution de rentabilité des processus.

Améliorations et ressources individuelles

Implémenter un schéma d'amélioration de processus dans une organisation signifie apporter des changements dans les activités des individus. Selon la culture de l'organisation et des individus présents, la facilité à implémenter de tels changements est aléatoire. Certains cultures d'entreprises sont fixés dans leur manière d'agir (« nous avons toujours fait les choses comme cela, pourquoi changer? »), Et obtenir une acceptation de ces changements est ardu. D'autres cultures ont une inertie importante envers les changements qui leurs sont imposés (« encore un changement provenant de la direction, attendons que cela passe pour retourner à notre façon de faire habituelle ») sans pour autant accepter le changement. D'autres encore - souvent plus rares -adoptent les changements avec moins de résistance.

Le facteur humain de l'équation est critique. S'il n'est pas pris en considération, les améliorations seront de courte durée. Selon l'expérience de l'auteur, si des mesures sont prises et montrées aux parties prenantes avant la mise en oeuvre des processus d'amélioration, il est souvent plus facile d'obtenir un engagement des participants dans les mesures d'améliorations proposées. La clé du succès réside à obtenir l'engagement des individus impliqués

La plupart des développeurs et des testeurs ont l'habitude de travailler avec des outils de suivi des anomalies, le temps d'entrée des données est faible (environ une minute), l'auteur juge la méthode odc relativement facile à utiliser. Son efficacité en fait une méthode d'amélioration intéressante.

Les modèles tpi, ceux basés sur un modèle de maturité, aussi bien que les modèles basés sur des normes step sont généralement imposés aux individus par la direction. Il est donc important de s'assurer que les employés adhèrent au modèle pour qu'il soit entièrement efficace. Cependant, comme ces modèles de maturité ne prennent en compte les spécificités de l'entreprise, leur rentabilité - sans mise en oeuvre d'une adaptation au contexte de l'entreprise - peut laisser à désirer.

Les méta-modèles peuvent être efficaces si les individus ont l'impression d'avoir contribué à l'amélioration du processus.

La méthode rex met en avant l'expérience de chaque individu, est elle est généralement perçue comme facile à implémenter parce qu'elle met l'emphase sur les individus et procure des récompenses personnelles (voir sa propre contribution reconnue à travers toute l'organisation). Pour que cette méthode soit efficace, il est nécessaire de faire des retours d'expérience relativement fréquemment pour s'assurer de bien garder en mémoire toutes les leçons apprises. De même l'amélioration des référentiels - via la base de connaissance - nécessite de relire périodiquement ces informations.

Comme la méthode des processus de test critiques (ctp) analyse le modèle organisationnel et les individus dans l'organisation, et s'appuie sur des métriques adaptés au contexte de l'organisation, ce modèle est un processus d'amélioration très utile, pragmatique et focalisé sur le calcul d'un retour sur investissement et d'une rentabilité réelle.

Conclusion

Conclusion

L'amélioration de nos processus de conception et de test n'est pas une obligation : nous pouvons continuer à perdre de l'argent et à faire du travail inutile. Cependant, dans toutes les autres industries, des améliorations mesurées, implémentées de façon itératives, ont démontré leur efficacité, leur rentabilité et ont permis à ceux qui les mettaient en oeuvre des améliorations qui leur ont donné des avantages économiques importants.

Les processus de test, permettent d'identifier des axes d'amélioration des processus de conception car ils identifient les défauts introduits par ces processus. L'istqb rappelle qu'au plus tôt les défauts sont identifiés au moins ils coûtent à l'organisation. Si nous sommes en mesure d'améliorer l'efficacité des processus de test - trouver plus de défauts dans le même temps - et aussi d'améliorer la rentabilité de ces processus de test - trouver les défauts avec moins d'effort - nous devrions permettre d'améliorer la rentabilité économique de nos entreprises. Si en outre nous sommes en mesure - avec des méthodes disponibles et prouvées - d'améliorer les processus de conception et de test, l'amélioration de la qualité des processus impliquera une amélioration de la qualité des produits, de la rentabilité des processus et cela avec un coût moindre.

Si vous souhaitez vous lancer dans l'évaluation et l'amélioration des processus d'une organisation, vous vous embarquez dans un projet à long terme qui aura un impact sur toute l'organisation. Il est évident qu'un support sans faille de la hiérarchie est important, mais il est nécessaire de sélectionner la méthode d'amélioration de processus adaptée à votre organisation et à vos objectifs. Il est donc nécessaire de sélectionner la méthode sur base de sa capacité d'adaptation au contexte de l'organisation, à sa capacité à procurer un retour sur investissement important tout en exigeant un degré d'investissement limité et des délais d'implémentation courts.

Le choix d'une méthode qui apportera des améliorations à court terme et qui simultanément minimisera les anomalies à long terme nous permet obtenir le meilleur des deux mondes : des changements adaptés au contexte, le retour sur l'investissement le plus élevé, des améliorations maintenables à long terme, basées sur des données statistiques valides. La personne sélectionnée pour diriger une telle initiative devra avoir une connaissance et une expérience pluridisciplinaire, couvrant à la fois les aspects de test - nous recommandons d'avoir acquis au moins les trois modules du niveau avancé de l'istqb - , mais aussi d'avoir des compétences en cycles de développement, et en gestion.

Décider de ne pas améliorer les processus de test - sauf si vous produisez déjà des produits « zéro défaut » de façon bon marché - doit être comparé à une faute lourde de gestion.

Article rédigé par

Bernard Homes, Président Du Comité Français Des Tests Logiciels (CFTL)
Bernard Homès (52 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).