Modèle de maturité des tests
Le modèle de maturité des tests basé sur la référence capability maturity model integration (CMMI), est composé de deux éléments :
- une échelle à cinq niveaux qui détermine la capacité à tester;
- un modèle d’évaluation.
Nous allons préciser ces 5 niveaux et considérer ce qui est caractéristique de chacun d’entre eux.
Le premier niveau — “Débutant”
Au premier niveau, les tests sont non structurés et chaotiques. Il n’existe pas d’environnement stable pour prendre en charge les processus de test. L’équipe ne fait pas attention au planning et aux normes.
L’objectif principal est de livrer le produit à temps sans problèmes critiques, donc les tests sont utilisés ici uniquement pour montrer que l’application fonctionne sans défaillances majeures. Souvent, le succès de tels projets dépend uniquement de l’héroïsme et des compétences des individus, et non de processus établis.
En résumé :
- le logiciel doit fonctionner correctement;
- les types de processus ne sont pas définis à ce niveau;
- le but des tests est de s’assurer que le logiciel fonctionne correctement;
- ce niveau manque de ressources, d’outils et de personnel formé;
- aucun contrôle qualité avant la livraison du logiciel.
Par conséquent :
- pas de documentation de test;
- le produit est instable;
- échec de processus lors de situations problématiques;
- le testing n’est rien de plus qu’une aide au débogage.
Deuxième niveau — “Répétable”
Au deuxième niveau, les tests deviennent un processus géré. La discipline et la progression permettent d’assurer le maintien de ces pratiques en période de stress. Les tests sont toujours considérés comme l’activité qui suit le développement. Des plans de test sont élaborés et mis en œuvre, à l’aide desquels il est clairement défini quels tests doivent être effectués, quand et par qui.
L’objectif principal est de s’assurer que le produit répond aux exigences spécifiées.
En résumé :
- développement d’objectifs et de politiques de test et de débogage;
- ce niveau distingue les tests du débogage, et ils sont considérés comme des activités différentes;
- la phase de test vient après le codage;
- le but principal des tests est de montrer que le logiciel est conforme à la spécification;
- méthodes et techniques de base des tests;
Par conséquent:
- il existe de grands types et types de tests (intégration, modulaire, régression, acceptation);
- les plans de test sont mis en œuvre;
- les activités de test sont surveillées et contrôlées;
- le processus est documenté et peut être répété.
Le troisième niveau — “Défini”
Au troisième niveau, les tests ne sont plus considérés comme une activité consécutive à la programmation. Les tests sont entièrement intégrés au projet. La planification des tests est effectuée à des stades antérieurs et consolidée dans le plan directeur. Des tests non fonctionnels sont introduits (par exemple, l’utilisabilité).
En résumé :
- intégration des tests dans le cycle de vie du logiciel;
- les tests sont intégrés à l’ensemble du cycle de vie;
- sur la base des exigences, les objectifs des tests sont déterminés.
- le cadre de test existe;
- tester est une activité professionnelle à part entière.
Par conséquent :
- les tests commencent par la phase des exigences;
- des activités sont ajoutées qui vous permettent de travailler plus efficacement (formations internes, révisions supplémentaires);
- mise en place de tests non fonctionnels.
Quatrième niveau — “Mesurable”
Au quatrième niveau, le test est un processus bien défini, bien établi et mesurable. Les tests sont perçus comme une évaluation et comprennent toutes les activités du cycle de vie du développement logiciel. La pratique consistant à mesurer la qualité des tests est en cours d’introduction. Ces mesures sont utilisées pour prédire les performances et le coût des tests.
En résumé :
- création d’un programme de mesures d’essais;
- le test est un processus mesuré et quantitatif;
- la vérification à toutes les étapes du développement est reconnue comme un test;
- pour les tests de réutilisation et de régression, il existe un cas de test et ils sont enregistrés dans la base de données de test;
- les défauts sont enregistrés et des niveaux de gravité donnés.
Par conséquent:
- le test en tant que processus est mesuré;
- les mesures sont utilisées pour les prévisions;
- l’équipe cherche des moyens de rendre le processus de test plus efficace.
Cinquième niveau — “Innovant”
Au cinquième niveau, toutes les approches et tous les processus sont bien établis. L’équipe ne s’arrête pas à ce stade, mais continue d’améliorer systématiquement les processus, en essayant constamment de réduire le temps de cycle de test et le temps de mise sur le marché sans réduire la qualité du projet. Les tests sont axés sur la prévention. L’automatisation est ajoutée pour une utilisation plus efficace des ressources.
En résumé :
- les tests sont gérés et définis;
- l’efficacité et le coût des tests peuvent être suivis;
- les tests peuvent être constamment modifiés et améliorés;
- pratique de contrôle de la qualité et de prévention des défauts;
- pratique le processus de réutilisation;
- les métriques liées aux tests ont également des outils de support;
- les outils fournissent un support pour le développement de cas de test et la collecte des défauts.
Par conséquent:
- il y a amélioration continue des processus;
- on privilégie la prévention et l’optimisation.
💡 On peut utiliser ce modèle de manière rigide pour déterminer le niveau de maturité des tests, en prenant le niveau de maturité le moins disant par rapport à l’évaluation réalisée. Cela peut aussi être utilisé comme un cadre dynamique permettant de cibler les axes d’amélioration à mettre en œuvre de manière itérative.
Version anglaise : Test Maturity Model
sources :
- https://fr.wikipedia.org/wiki/Capability_Maturity_Model_Integration
- https://www.brighthubpm.com/certification/69744-cmmi-vs-cmm-which-is-better/
- https://github.com/VladislavEremeev/QA_bible (en russe)
- https://www.istqb.org/downloads/send/12-expert-level-documents/75-expert-level-syllabus-improving-the-testing-process-2011.html (en anglais)
