Évolution du rôle et des compétences de l’assurance qualité

Il fut une époque où l’assurance qualité était ni plus ni moins que le dernier filet de sécurité avant la livraison d’un produit logiciel. Les développeurs poussaient du code, et l’assurance qualité trouvait les anomalies et le processus se répétait. La valeur de l’assurance qualité se mesurait alors en nombre d’anomalies détectées. Et celle du développeur était déterminée inversement par le nombre d’anomalies détectées par ligne de code produite.

Vous pouvez imaginer les discussions sans fin entre les équipes d’assurance qualité et de développement. On se battait du côté QA pour affirmer qu’il s’agissait un bogue, tandis que les développeurs (dont je faisais partie à l’époque) clamaient que c’était une « conception intentionnelle » pour ainsi ne pas perdre de points. Cela vous fait peut-être sourire, mais c’était comme ça.

Bien sûr, au fil du temps, cette atmosphère de rivalité a fait place à une plus grande compréhension mutuelle. Mais pas encore au point d’appeler ça de la coopération.

Revenons à notre réalité actuelle. Les bonnes pratiques du développement exigent la mise en place d’un processus de qualité en mode continu. Cela implique qu’il faut exécuter à chaque itération des tests de non-régression. Ainsi, avec une liste de tests qui croît continuellement au fur et à mesure du développement du produit, ces sessions de détection des régressions consument de plus en plus de temps. Il arrive finalement le moment où l’équipe d’assurance qualité passe plus de temps à exécuter des tests de non-régression qu’à exécuter les tests d’intégration. Ou pire, l’équipe n’ajoute plus de tests à la liste de régression afin de sécuriser du temps pour la validation des fonctionnalités ajoutées.

De plus, parallèlement à cette exigence de qualité continue, la communauté du développement logiciel s’accorde sur le fait que la grande majorité des anomalies (plus de 80 %) sont introduites lors de la création et de l’édition de modules logiciels. Avec un modèle où trop de temps est dépensé pour l’exécution des tests de non-régression, les anomalies sont malheureusement détectées lors des tests d’intégration, et ce, tard dans le cycle de réalisation (en fait trop tard).

Il faut prendre en compte le coût de la correction d’une anomalie qui peut être jusqu’à 30 fois supérieur si l’anomalie n’est détectée qu’à la fin des tests d’intégration et jusqu’à 80 fois si la détection se produit en production.

Il faut appliquer le principe du « décalage à gauche » (« Shift left testing ») parce qu’il est crucial de détecter les anomalies au plus près du moment où elles sont créées, c.-à-d. pendant l’écriture du code. Il faut rapprocher les deux « pics » et combler l’espace entre eux dans la figure ci-dessus (inspirée de la présentation « Pas d’agilité sans qualité » donnée par François Boretto d’Askida, à l’Agile Tour Montréal 2018).

C’est ici qu’entre en jeu l’évolution du rôle de l’assurance qualité : comment réaliser ce « Shift-left » ?

En premier lieu, les analystes en assurance qualité doivent participer en amont à l’élaboration des scénarios. Ceux-ci doivent être ouverts à la connaissance de plusieurs technologies, et doivent être impliqués et intégrés dans l’équipe de réalisation. Cette approche doit être soutenue et supportée par la direction et les gestionnaires. Il faut ensuite libérer les membres de l’assurance qualité des sessions de tests de non-régression, rendues accablantes.

Ainsi, nous avons besoin d’une équipe initiée à la stratégie DevOps qui maîtrise le concept du développement et de l’intégration continue. Nous ne parlons plus de testeurs, mais d’analystes en assurance qualité qui ont les compétences de nécessaires pour dresser une liste de tests fonctionnels critiques et d’automatiser ces tests. Les scripts peuvent être exécutés au développement et ensuite à chaque itération à titre de non-régression. Il ne reste qu’un seul temps à considérer, celui du développement des tests fonctionnels. Les tests de non-régression s’exécutent ensuite automatiquement à la fréquence désirée. Il va aussi de soi que les analystes doivent avoir les compétences nécessaires pour gérer et maintenir eux-mêmes un environnement de test.

Ces compétences requises en assurance qualité sont donc de plus en plus similaires à celles requises pour les développeurs. En fait, il faut être capable de tester, bien sûr, mais aussi de coder. Il y a fort à parier que les tests fonctionnels exécutés manuellement lors de la soumission de code sont appelés à disparaître pour la plupart. Il demeurera cependant toujours (un peu) de place pour les testeurs manuels, car tout ne peut pas et ne doit pas être automatisé. Mais les testeurs qui n’acquerront pas les compétences liées à l’automatisation des tests n’auront plus autant de valeur dans le cycle de développement qu’auparavant.

Ce que je retiens des articles que j’ai parcourus (exemple), c’est qu’il devient prioritaire que les équipes d’assurance qualité s’enrichissent par le développement d’une expertise en automatisation des tests et l’acquisition des connaissances relatives à la rédaction de scripts. En faisant évoluer le rôle de l’assurance qualité dans cette direction, il s’avère que les tests de fonctionnalité sont disponibles tôt au début du cycle de réalisation sans compromettre la régularité de l’exécution des tests de non-régression.

Jean Godard, Ing.