Le Q&A : nécessité ou abomination ?

by norman@dotnethub.be lun., mai 19 2014 23:59

Ceci est issu de mes différentes expériences sur le terrain et peut vous choquer.
Si vous continuez, à vos risques et périls !

Bon j'y vais : pour moi le Q&A est une abomination ! Dans sa forme la plus répandue.
En créant un service de Q&A, la société admet que ses équipes vont faire du mauvais boulot ! et que Les tests sont faits par quelqu'un d'autre, beh oui faut bien les faire et les devs n'ont pas le temps !

D'ailleurs, posez la question dans n'importe quelle société pourquoi ils ont un Q&A ? Vous obtiendrez que la qualité est telle qu'on ne saurait pas faire autrement.
Ha bon !

Si je prends les chiffres des endroits où je suis passé, cela va de 15% à 50% des personnes employées uniquement à faire du test. Ensuite vous creusez un peu les chiffres et essayez de comprendre à quoi ils passent leur temps.
On peut généralement constater à cette étape que la plupart de ces teseurs découvre des bugs dans la première demi-heure de test. Donc des tests basiques donnent directement lieu à un bug. WTF !
Qu'est-ce-qu'ils b...ent les développeurs ?

Beh oui, on en revient à la racind du problème ! Les devs livrent de la m.. car ils ne testent pas assez ou testent mal leur développement, ou n'ont pas compris ce qu'on leur demande, ou...

Voici quelques conseils pour limiter les bugs les plus débiles :

  • vos responsables produit/projet doivent bien maitriser leur sujet et créer de bonnes specs qui contiennents :
    • une définition claire du besoin incluant pourquoi on le fait et pas juste : "il faut un bouton qui fait ça !"
    • des critères d'acceptance claires et partagés à l'équipe, voir construit avec l'équipe (de test)
    • la description des besoins non-fonctionnels doit figurer dans la demande
  • des guidelines de dev
  • convention de nommage
  • SOLID
  • des tests unitaires
  • des tests de recettes/intégration automatisés
  • une intégration continue : déploiement de package/build automatisè


Quand vous aurez la plupart de ces points DONE, vous serez peut-être mieux préparés à l'agilité.

Donc en résumé, votre service Q&A est encore nécessaire dans sa forme actuelle : je fais deux clics et il y a un bug !

Un métrique à mettre en place pour savoir si ça va mieux c'est le nombre de temps entre le début des tests et le premiers bug.

 

Quelques liens pour aller plus loin :

http://fr.wikipedia.org/wiki/SOLID_%28informatique%29

http://www.mountaingoatsoftware.com/training/courses/effective-user-stories

http://www.scrumalliance.org/community/spotlight/mike-cohn/march-2014/agile-user-stories-epics-and-themes

http://fr.wikipedia.org/wiki/Extreme_programming

http://www.amazon.com/Extreme-Programming-Explained-Embrace-Edition/dp/0321278658

http://henrik-kniberg.developpez.com/livre/scrum-xp/

 

Tags: , , , , ,

Commentaires

Ajouter un commentaire




  Country flag

biuquote
  • Commentaire
  • Aperçu immédiat
Loading