Lorsque l’on vous parle d’équipe de test ou de QA, cela vous évoque-t-il des personnes essayant de faire planter le logiciel réalisé pour démontrer à l’équipe de développement qu’elle s’est trompée ?
Si c’est le cas vous êtes dans l’erreur et il serait bon que vous réfléchissiez encore à la situation.
Dans notre culture, le rôle du testeur est généralement dévalué par rapport à celui du développeur (parfois même au niveau du salaire), et pour certains développeurs, le développement de tests est considéré comme une tâche subalterne n’ayant aucun aspect « noble ».
Dans une approche Scrum, le testeur est considéré comme un membre à part entière de l’équipe, qui possède une spécialité reconnue, comme la vision du fonctionnement global du produit, qui ne sera pas pour autant uniquement cantonné aux tâches de tests, et qui apporte une plus value réelle à l’organisation.
Regardons la contribution du testeur en mode Scrum :
- Lors de la revue du Product Backlog, il aide l’équipe à mieux comprendre chaque item en contribuant à formaliser les critères de recette (« acceptance criteria »)
- Lors du Sprint Planning, il amène une vision produit dans son ensemble (il est souvent l’un des seuls à avoir cette vision globale) qui aide l’équipe à ne pas oublier certaine tâches de réalisation
- Lors du Stand Up quotidien, il acquière de la connaissance sur l’architecture de l’application qui lui permettra de poser les bonnes questions (celle qui font progresser l’équipe) et de développer le jeu de tests le plus pertinent pour valider l’application (je ne parle pas ici des tests unitaires qui sont généralement de la responsabilité des développeurs).
- Lors du Sprint, les jeux de tests qu’il a créé et automatisé contribuent à l’obtention du DONE, tel que défini au niveau de l’item du Backlog, du Sprint ou de la Release.
- Lors de la Review, il est bien souvent, vu du management, le garant que les choses sont réellement terminées et que les fonctionnalités sont potentiellement déployables. La nécessité de rassurer le management n’est pas une pratique agile à proprement parlé mais est absolument nécessaire dans les organisations actuelles … le temps pour elles de changer leurs mentalités.
- Lors de la Retrospective, il contribue au même titre que les autres membres et identifie ce qui a bien et mal marché et ce qui peut être amélioré.
L’approche Scrum permet à une entreprise de tirer le meilleur parti de la totalité des compétences des testeurs en les intégrant tout au long du cycle de développement du produit. Si vous pensez encore que le testeur n’est que celui qui sait rentrer les bugs dans l’outil de tracking … recommencez la lecture de cet article
… Merite une petite reponse ….
JE ne sais pas pourquoi, mais en ce moment je suis plus sensibilisé au sujet.
Je suis d’accord avec le postulat que les testeurs sont considérés comme des larbins 😀 Je ne doute aucunement du role d’un testeur. Une des difficulté cependant est la compétence du testeur. Sans juger de la valeur humaine, un bon testeur dans mon idée, et visiblement dans la tienne, doit avoir a la fois une vision produit pour imaginer les scenarios et valider le produit (souvent le produit n’aide pas bcp …), il doit voir une compétence technique à la fois haut niveau mais aussi système pour identifier/anticiper les problèmes possibles. Il doit être aussi capable d’avoir une vision globale de l’architecture pour identifier les points faibles, sans parler d’une compétence I18N/ sécurité/ performance / scalabilité / robustess.
En gros, l’ingénieur parfait, un mixte de DBA/ ingénieur de production / developpeur back End, avec un bout de webdev, un soupçon d’expert I18N/sécurité, une petite sauce d’architecte et le tout avec une vision produit.
En plus s’il avait une connaissance des outils de tests, qu’il connaissent les injecteurs et les mocks pour aider les développeur, et surtout qu’il soit capable de définir les bonnes priorités pour ses tests.
On aurait le testeur parfait.
Finalement …. ce sont eux qu’on devrait payer le plus ….
Wahou, comment dire ? Ca fait tellement du bien de voir qu’il existe des personnes ayant une vision différente et réaliste du rôle de testeur, merci Alex ! Je pense que Scrum aide l’équipe à avoir cette vision, en tout cas cela a été mon cas. Plus généralement, la méthode permet d’avoir une vision beaucoup plus concrète des différents « fonctions » de l’équipe (développeurs, architectes, production …) et mène à un plus grand respect entre eux.
Tout à fait d’accord avec le commentaire précédent sur la palette extrêmement large de compétences nécessaires pour être un bon testeur, sans être spécialiste dans chacun de ces domaines … Une compétence également essentielle : pouvoir supporter d’être vu comme celui qui doute de tout et remet toujours les choses en cause …
Très bonne analyse des ‘vilains petits canards’ du monde du web. Ayant été testeur je sais de quoi je parle dommage d’ailleurs que ce manque de dicernement échappe à tant de personne qui sont censés avoir un minimum de réflexion étant donné leur niveau…
C’est aussi ce manque de reconnaissance qui fait que bien des testeurs abandonnent leur poste pour finalement se retrouver en développement ou en administration système par exemple. Comme quoi les compétences sont là quoi qu’on en dise.
Le mode scrum est une bonne méthode pour faire avancer de manière cohérente et rapidement un projet, toutes les équipes gravitant autour du projet étant présentes et ayant leur mot à dire.
Encore bravo pour cet article.