Amélioration des processus de tests logiciels : une prise de conscience est nécessaire
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é. Faut-il s’engager ou non dans des techniques d’amélioration de processus ?
Vers un modèle de rentabilisation pour l’amélioration de processus
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 ?
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.
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.
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 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 œuvre 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 globaleEn 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étriquesLes 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.
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.
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)
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)
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)
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 IDEAL, 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 œuvre 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)
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électionDans 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 œuvre 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 œuvre 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émentationContrô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 œuvre 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 œuvre 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 œuvre 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
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 œuvre 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.
---------------------------------Références
[IEEE829:1998] IEEE Standard for Software Test Documentation, © IEEE, 1998
[IEEE829:2008] IEEE Standard for Software and System Test Documentation, © IEEE, 2008
[SWI1993] Software Inspection, Tom Gilb & Dorothy Graham, © Addison-Wesley, 1993, ISBN: 878-0-201-63181-4
[SRE2004] Software Reliability Engineering, John D. Musa, © AuthorHouse, 2004, ISBN: 978-1-418-49387-5
[CTP2004] Critical Testing Processes, Rex Black, © Addison-Wesley, 2004, ISBN: 978-0-201-74868-0
[TPI1999] Test Process Improvement, Tim Koomen & Martin Pol, © Addison-Wesley, 1999, ISBN: 987-0-201-59624-3
[SST2007] Systematic Software Testing, Rick D. Craig & Stefan P. Jaskiel, © Artech House, 2007, ISBN: 978-1-580-53508-3
[ISO91262] ISO/CEI TR 9126-2:2003 Software engineering – Product quality Part 2: External metrics, © ISO/IEC 2003
[ISO91263] ISO/CEI TR 9126-3:2003 Software engineering – Product quality Part 3: Internal metrics, © ISO/IEC 2003
[1] Principe qui veut que les individus soient promus jusqu’à atteindre leur niveau d’incompétence, à partir de quoi ils ne sont plus promus. Cf. Le Principe de Peter, auteurs L.J. Peter, R. Hull, Le Livre de Poche, 1971, ISBN 978-2253005933.
[2] Eliyahu GOLDRATT, « Le But : un processus de progrès permanent », AFNOR, 2006, ISBN 978-2124656417
[3] La version plus récente, TPI-Next, a un nombre plus restreint de processus. Les recommandations s’appliquant à TPI s’appliquent aussi pour TPI-Next.
[4] L’absence du processus de tests de bas niveau dans TPI-Next peut lui aussi être problématique s’il est nécessaire dans votre contexte.