Il faut laisser la responsabilité des tests logiciels aux développeurs. Vraiment ?
Les développeurs sont-ils les mieux placés pour tester les développements ?
C’est la grande question qui s’est posée dans le monde de la micro-informatique de gestion, durant les années 90 et le début des années 2000 ! Avant que la fonction QA n’apparaisse c’est, dans beaucoup de projets, les développeurs qui étaient en charge de tester les livrables avec les résultats que l’on connaît : 70% des projets qui n’aboutissait pas, bien entendu pas uniquement à cause de la qualité.
Rôle du développeur dans une stratégie de test
Avec l’évolution des technologies et la complexification des projets et par conséquent des développements, il est vite devenu évident qu’il était impossible de laisser la responsabilité des tests aux seuls développeurs. Ce n’est pas leur métier et ils n’ont pas le recul nécessaire pour avoir une vision d’ensemble de l’application. Il n’y a que des équipes dédiées à l’établissement et à l’exécution d’un plan de tests qui vont permettre d’améliorer sensiblement la qualité des livrables. Mais ce n’est pas pour autant que les développeurs ne sont pas impliqués dans la qualité.La règle d’or d’un développeur devrait être « On ne part pas en développement si on ne sait pas comment on va tester »
Les développeurs sont en charge de l’exécution des tests unitaires. Dès l’instant où ils ont développé une fonction, ils se doivent de vérifier que celle-ci est bien conforme à ce qui est exprimé comme besoin et qu’elle donne le résultat attendu.
Dans un autre contexte on appelle ça : “relire son travail”. Mais cela ne peut présager de la bonne exécution de cette fonction dans un environnement global. Si l’on veut étendre la couverture des tests, il faut insérer des jeux de données et valider la fonction dans le reste de l’application.
Mais leur responsabilité ne s’arrête pas là. Un livrable aussi complexe qu’il soit est toujours composé d’un assemblage de fonctionnalités plus petites que lui. Il est indispensable que chacune réponde au cahier des charges. Un développeur doit également s’assurer du bon “emboîtement” de certaines d’entre elles. Et c’est là qu’interviennent les tests d’intégration. Ces derniers ont une importance capitale !
Prérequis : lorsque nous parlons d’intégration nous ne faisons pas référence aux compétences d’un intégrateur dont la responsabilité est de produire un rendu fidèle au design grâce à du CSS, par exemple. L’intégration, dans le monde du test, c’est l’assemblage de différentes fonctionnalités qui font appels les unes aux autres.
Et, dans une certaine mesure, il en va de la responsabilité des développeurs de vérifier que leurs intégrations fonctionnent avant de soumettre leurs développements aux équipes de tests. Si l’intégration ne fonctionne déjà pas sans jeux de données « clefs », il n’y a aucun intérêt à l’intégrer dans un test logiciel automatisé.
Toute la difficulté réside dans la limite du périmètre d’action du développeur. Et c’est là où le responsable qualité est indispensable : définir les rôles et responsabilités de chacun.
« Le Responsable Qualité définit et met en oeuvre la politique qualité de l’entreprise en y associant des indicateurs et des processus de contrôle Il est responsable de la conformité des produits ou services de l’entreprise aux exigences internes et externes (conformité aux normes, exigences légales, attentes des clients…). Il coordonne les activités de pilotage et de surveillance de la performance des procédures et méthodologies qualité de l’entreprise. »
Source Referentiels metiers opiiec
UX Functional testing
UX Functional testing
UX Functional testing