Aujourd’hui, quel niveau d’implication doit avoir un développeur sur les phases de tests ?

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é.

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

Pour conclure

Mais, en tout état de cause, un développeur teste le fruit de son travail avec comme limite constante : l’autoévaluation. Il faudrait aborder le concept psychologique du processus et il est évident que l’on est rarement objectif lorsque l’on doit s’évaluer. Ce manque d’objectivité ne peut avoir sa place dans un projet informatique, d’où les fonctions clés de testeurs et plus encore d’automaticien ! (voir notre article sur le sujet).

Publié par

2 réponses sur « Aujourd’hui, quel niveau d’implication doit avoir un développeur sur les phases de tests ? »

  1. J’ai vraiment beaucoup de mal avec cette affirmation concernant les 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. » Pas besoin d’en dire plus pour désengager immédiatement de nombreux développeurs par rapport aux tests, et par la même occasion conforter dans leur opinion ceux qui estiment encore que tester leur code ne fait pas partie du job.

    Aimé par 1 personne

  2. C’est dommage que cet article n’envisage qu’une seule pratique des tests par les développeurs. La meilleure façon de mettre à profit les tests automatisés pour un développeur n’est pas de « relire son travail » dans un esprit d’auto-évaluation après codage. C’est bien plutôt de spécifier le comportement du logiciel avant développement (https://gearsoftesting.org/tempo-of-testing.html). Et pour le coup, cette approche de la conception logicielle n’a pas les biais d’objectivité connus du Test-Last Development en matière de test.

    Aimé par 1 personne

Répondre

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s