Voir la source de Cessez d'attendre la fin du projet pour commencer la recette

[[Category: Portail Product Owner]]
[[Category: Tests]]
[[Category: Alberto Gutierrez]]
Auteur : Alberto Gutierrez<br/>
Source : [http://www.makinggoodsoftware.com/2010/05/02/stop-waiting-to-the-end-of-the-project-to-start-qa/ Stop waiting to the end of the project to start QA!!! (And other QA principles)]<br/>
Date : 02/05/2010<br/>
----
Traducteur : Fabrice Aimetti<br/>
Date : 03/05/2010<br/>
----
Traduction :<br/>
<br/>
Si vous souhaitez continuer votre lecture sur ce sujet, je vous conseille le billet de Hiren Doshi, [[A_quel_moment_engager_l%27équipe_de_recette_dans_une_itération_%3F|A quel moment engager l’équipe de recette dans une itération ?]]. Il est toujours intéressant d’avoir deux points de vue qui se rejoignent avec des différences "sensibles"...<br/>
Beaucoup de chefs de projet considèrent qu’il est improbable de détecter des bogues majeurs durant la recette –technique– (NdT : le terme anglais est QA (Quality Assurance). J’ai toujours du mal à le traduire, tantôt test d’intégration, recette technique ou même recette fonctionnelle suivant les organisations...), ce qui ressemble à aller à la guerre en espérant ne pas avoir de pertes humaines. L’une des conséquences d’un tel raisonnement naïf est qu’ils sont habitués à planifier la recette –technique– comme la dernière phase du processus de développement logiciel pour finalement découvrir que :<br/>
* Cela n’offre pas assez de temps pour réagir lors de l’apparition de bogues majeurs.
* Cela génère beaucoup de tension entre les équipes de recette –technique– et de développement. Il devient donc crucial pour les développeurs de passer avec succès la recette –technique– parce qu’ils savent qu’ils n’auront pas assez de temps pour corriger un bogue majeur.
* Cela n’est pas adapté pour mener des tests exploratoires. Les tests exploratoires permettent aux testeurs d’appliquer une approche boîte noire qui est excellente pour trouver les bogues les plus importants dans l’application.
* Cela exige des passages de relai et un paramétrage importants.
<br/>
Une leçon que j’ai apprise il y a longtemps, est que la recette –technique– peut opérer comme un processus distinct dans d’autres industries, par exemple le manufacturing, mais cela ne fonctionne pas dans le développement logiciel. Chaque fonctionnalité unitaire qui est implémentée dans une application devrait être passée immédiatement en recette –technique–. Vous trouverez ci-après mes principes concernant la recette –technique–.<br/>
<br/>
'''1. Il n’y a pas de transferts de responsabilités entre le développement et les tests'''<br/>
<br/>
Coder et tester ne sont pas deux processus distincts, ils sont réalisées en parallèle, et on ne peut pas terminer l’un sans terminer l’autre et vice versa (extrait de : [http://www.makinggoodsoftware.com/2009/11/29/continuous-integration-going-beyond-continuous-compilation/ Intégration continue, aller encore plus loin que la compilation continue].<br/>
<br/>
'''2. Développeurs et testeurs ont un objectif commun'''<br/>
<br/>
Ils ne réalisent pas des activités différentes, les développeurs ne sont pas seulement concentrés sur le développement et les testeurs sur les tests. Ils partagent un objectif commun, produire un logiciel de qualité de façon coordonnée à partir des attentes du propriétaire du produit (extrait de : [http://www.makinggoodsoftware.com/2009/11/29/continuous-integration-going-beyond-continuous-compilation/ Intégration continue, aller encore plus loin que la compilation continue]).<br/>
<br/>
'''3. Les équipes de recette –technique– et de développement doivent fournir leurs plannings au sein d’un planning unique'''<br/>
<br/>
Il n’y a pas un planning de développement et un autre pour la recette –technique–, parce qu’ils dépendent l’un de l’autre.<br/>
<br/>
'''4. Le rôle d’un recetteur –technique– ne devrait pas être moins valorisé, qualifié ou reconnu que le rôle d’un développeur'''<br/>
<br/>
J’ai travaillé sur de nombreux projets où les recetteurs –techniques– sont considérés comme des collaborateurs de deuxième classe qui effectuent des tâches plus faciles que les développeurs. En réalité, dans de nombreux projets, le type de rôle tenu est celui d’un testeur qui suit uniquement un script de test et prenant notes des résultats attendus et obtenus à chaque étape.<br/>
<br/>
À mon avis, les testeurs apportent beaucoup de valeur ajoutée au projet, ils devraient être responsables de l’écriture de tests automatisés, de la mise en place des environnements et de la coordination avec le Métier pour s’assurer de leurs attentes réelles.<br/>
<br/>
'''5. Le recetteur –technique– et le développeur n’ont pas besoin d’être deux personnes différentes, c’est seulement deux rôles différents'''<br/>
<br/>
Parce que la recette –technique– a coutume de se passer à la dernière étape du développement logiciel, et parce qu’elle était considérée comme une sorte de processus de certification, le management a décidé que la recette –technique– devrait être confiée à une équipe totalement indépendante, et cela a conduit à l’idée que le recetteur –technique– et le développeur devraient toujours être non seulement deux rôles différents, mais aussi deux personnes différentes.<br/>
<br/>
'''6. La recette –technique– devrait être planifiée de telle manière qu’elle puisse représenter jusqu’à 50% du temps de développement'''<br/>
<br/>
C’est juste une règle empirique, et bien sûr c’est à juger au cas par cas, mais il est important de comprendre que la recette –technique– est une tâche très importante qui, lorsqu’elle est correctement réalisée, pourrait représentée jusqu’à 50% du temps de développement.