Aujourd’hui nous nous attarderons sur les tests liés à l’avant dernière famille définissant la qualité au sens ISO – 25 010, les tests de « maintenabilité ». Nous verrons à quoi correspondent ces tests et à quelle problématique ils répondent.
Pour avoir plus d’informations sur la norme ISO – 25 010, je vous invite à lire ou relire mes autres articles sur le sujet.
Les tests de maintenabilité sont souvent des tests « ignorés » lors du développement initial d’un logiciel. La raison est simple la maintenabilité ne se ressent qu’à moyen, voire à long terme. Il est fréquent d’entendre dire « Cette application n’est pas maintenable car trop vieille », l’inverse (avec une application récente) ne l’est que très rarement.
Il est bon de noter que les problèmes de maintenabilité engendre souvent des décision radicales comme l’utilisation ou le développement d’un autre logiciel.
Comme vous l’aurez compris, ici le but n’est pas tant de savoir si l’application est sécurisée, qu’elle répond rapidement est ergonomique et fait ce que l’on demande mais plutôt de savoir si elle pourra répondre à ces contraintes à moyen ou long terme. Ces tests ne sont donc que très peu utile pour des application à durée de vie courte.
Comme vous pouvez le voir avec l’image ci-dessus, la famille des tests de maintenabilité contient, d’après la norme ISO – 25 010, 5 types de tests spécifiques, chacun ayant un rôle bien définit :
- Les tests de modularité
Les tests de modularité ont pour but de vérifier que le logiciel est bien divisé en « composants » (plus ou moins) indépendants les uns des autres. L’idée est de vérifier que l’on peut remplacer/faire évoluer une partie du logiciel sans nécessairement devoir retravailler et impacter tout le logiciel.
Lorsque l’on doit changer de réfrigérateur dans une cuisine, il est préférable que ce changement ne nous force pas à refaire le plan de travail est acheter un nouveau four! Pour le développement des applications c’est pareil. Il faut donc, en amont, bien prévoir l’architecture du logiciel.
Un moyen efficace d’effectuer ces tests est d’avoir et de suivre de bonnes pratique lors du développement. Il est également possible du juste modifier certains modules afin de voir les impacts.
- Les tests de réutilisabilité
Les tests de réutilisabilité ont quant à eux le but de vérifier que le code développé peut être réutilisé sur d’autres logiciels. Si c’est le cas il est beaucoup plus simple de mutualiser des coûts des modifications.
Si on reprend l’exemple de la cuisine et du réfrigérateur. Si je déménage je souhaite pouvoir garder mon réfrigérateur pour ma prochaine cuisine. La manière la plus simple de s’assurer cela est d’avoir un frigo avec des dimensions « standards ».
Pour le développement d’une application c’est pareil, il faut essayer de suivre les standards de développement et les pratiques utilisées sur les autres logiciels développés par l’entreprise.
La réutilisabilité est également très pratique pour les tests et particulièrement pour les tests automatisés. En effet, si notre « bout de test » peut être utilisé sur 50 tests, alors le coût de maintenance de ces 50 tests si cette partie évolue devient 50 fois inférieur.
- Les tests d’analysibilité
Les tests d’analysibilité ont un autre but. Leur vocation est de permetre de savoir quels sont les impacts d’un changement sur l’application, savoir quelles seront les actions à effectuer, quelles fonctionnalités seront touchées et dans quelle mesure.
L’analysibilité, au niveau du code, a un peu le rôle du test au niveau du produit, il donne de l’information. Il parait inconcevable de sortir une application alors que l’on ne connait pas du tout sa qualité, il est tout autant inconcevable de décider de faire un changement sur un logiciel si l’on n’est pas capable de savoir quel sera l’effort à effectuer pour mener à bien ce changement.
- Les tests de modifiabilité
Les tests de modifiabilité ont un autre rôle. Ils sont là pour savoir dans quelles mesures l’application peut évoluer sans y introduire de régressions majeures. Peut-on ajouter de nouvelles fonctionnalité? Est-il possible de changer des parties de l’application?
Les tests de modifiabilié sont là répondre à ces questions. Il est bon de noter que ces tests sont en partie liés aux tests de modularité. Si les composants sont indépendants, les chances de régressions sont plus faibles car « seul » le composant modifié est sujet à des régressions majeures.
- Les tests de testabilité
Ces tests sont très importants car ils permettent de savoir s’il est possible d’avoir une bonne visibilité sur la qualité de l’application à travers une campagne de test. Cela n’est malheureusement pas forcément évident. En effet, il est possible d’avoir une application dans un environnement très complexe et de ne pas réussir à avoir un environnement de test suffisamment fidèle pour la tester.
Or, comme dit tout à l’heure, personne ne souhaite mettre en service une application sans avoir la moindre idée de la qualité de l’application. La « résolution » de ce problème est généralement une non maintenance du logiciel.
Afin de bien comprendre l’intérêt des tests de maintenabilité, il faut garder à l’esprit que personne (humain ou non) n’aime s’engager sur un résultat totalement inconnu ou engager des frais disproportionné pour un résultat moyen. Les tests de maintenabilité sont là afin de s’assurer qu’à moyen/long terme le logiciel développé sera modifiable dans des conditions acceptables (coût, visibilité, impact qualité) avec la possibilité d’avoir une évaluation du coût de ces modifications.
Source ISO – 25 010
Syllabus ISTQB fondation 2018 Lien anglais car non disponible en français à la date d’écriture
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
Une réponse