Posté par jc-QualityStreet le 12 février 2007
Actualiser ses connaissances, envisager d’autres points de vue, me paraît primordial. Aujourd’hui marquait le début de deux formations que je vais suivre : Stratégie des Tests (sur 3 jours) et Test & Validation du logiciel (l’UE du CNAM en cours du soir jusqu’au mois de juin).
Dans les deux cas, je n’échapperai pas à des choses connues, déjà vues et revues: ce fut le cas pour l’essentiel de cette première “grande” journée (11 heures de formation au total!); même s’il n’est pas toujours inintéressant de se voir présenter les choses sous un angle différent.
Toutefois la suite s’annonce meilleure… Pour le première formation, focus sur l’intégration du test dans le processus itératif avec études de cas (qui répondront peut être à certaines questions que je me pose) et retours d’expèrience sur les problématiques offshore. Pour la seconde, celle du CNAM, l’étude plus détaillée des techniques de test et des aspects propres au développement : tests unitaires, intégration, automatisation.
Bref, une belle complémentarité.
Posté par jc-QualityStreet le 1 février 2007
Développé, livré et testé dans une même itération : ce n’est pas forcément naturel ; c’est même souvent une vraie difficulté pour les projets utilisant les les méthodes Agile: Processus Unifié (UP), SCRUM ou XP.
Le TimeBoxing (fixer les dates d’iteration quitte à faire évoluer le contenu de celle-ci) et les livraisons intermediaires sont bien acceptés. Reste à s’entendre sur ce qu’on livre …
Vérifier continuellement la qualité de l’application est principe fondateur du Processus Unifié. Le processus Unifié (”Unified Process” en anglais ou plus simplement “UP”) met l’accent sur la qualité des processus, sur la qualité du produit : des points déterminants dans notre choix de la méthode.
Une discipline est même formalisée, des rôles (”worker”) identifiés.
Quand vous présentez ce principe aux hautes instances de votre organisation, cette dernière est enthousiaste …il en est de même pour les équipes de développement.
Puis c’est le moment de concrétiser tout cela avec vos nouveaux projets: “ce sera environ 25% (parfois plus) de charge pour la discipline Test sur l’ensemble du projet”. Mettre le focus sur la qualité, ça a un prix : “Ah bon, vous êtes sur ?”
Mais jusque là tout va bien.
Enfin c’est le moment de mettre en application notre principe sur une itération, et c’est là que se présentent les premiers dérapages :
- “tester, désolé on a plus le temps” …
- “au fait qui va tester ?” …
- “on a pas les ressources” …
- “vous avez pris du retard les testeurs ne sont plus dispo”
- “les cas de test ne sont pas prêts”
- “ah pour vos tests on a pas l’environnement”
- “attendez !! on a livré c’est déjà bien non ?”
Et bien non, ce n’est pas suffisant: ce qu’on livre on l’a testé. On ne peut se contenter de tester dans l’iteration suivante ce qu’on vient de produire dans notre itération. Une stratégie, non, plutôt un constat d’echec et surtout davantage de risques pour l’avenir.
Ce problème est donc récurrent; malheureusement il n’y a pas de recette miracle.
Encore une fois, une prise de conscience doit avoir lieu.
L’itération entière doit être tournée vers la recherche de la qualité. Les tests doivent être planifiés, anticipés, toute l’équipe doit se mobiliser et la QA team impliquée au plus tôt dans une approche collaborative (QA n’est pas mon ennemi !!) …
Bon, un vrai travail d’optimisation des ressources est à mener mais je pense de plus en plus à intégrer les SCRUM dans ma gestion de projet (scrum signifie mêlée), ou plus exactement intègrer le “scrum daily meeting”, (une courte réunion quotidienne, sauf que pour moi ce serait plutôt tous les 2/3 jours, d’environ 15 minutes, rassemblant les membres de l’équipe, où chacun décrit entre autres ce qu’il a fait la veille et va faire aujourd’hui).
Ces points intermédiaires seraient par exemple l’occasion pour les développeurs et les QA de faire un point sur leurs tests respectifs, et de rester en alerte sur cette question.
Et vous, comment faites-vous ?
Posté par jc-QualityStreet le 12 janvier 2007
Dans l’autre sens cette fois.
La recherche de la qualité du logiciel et de la qualité des processus est mon leitmotiv depuis quelques années et sera à l’honneur sur QualityStreet. Si vous êtes devant ce blog c’est que vous percevez déjà la nécessité de tester ce que vous produisez et que le chiffre de 30% de test dans la charge globale d’un projet ne vous fera pas bondir !!
Ce que j’apprécie beaucoup dans le Processus Unifié c’est qu’il met le focus sur cette discipline et permet d’introduire facilement les concepts de validation, de vérification. Il me permet même de faire le lien avec mon activité initiale d’ergonome, que ce soit au niveau de:
- la vérification (le produit est-il bien fait ?) : cela peut être par rapport à une charte d’ergonomie, de standards…
- ou de la validation (est ce le bon produit ?) par des utilisateurs (tests utilisateurs pour les ergos.; tests d’acceptation pour les ingenieurs qualité).
Vous me voyez venir…
oui, le test peut être un point d’entrée idéal vers une démarche ergonomique. Si en plus mon équipe développe en mode UP, dans une démarche itérative, et bien je peux même faire mes tests plus tôt et avoir accés à mes utilisateurs. Voilà la boucle est bouclée, avec un peu d’efforts je m’approche sans en avoir l’air de l’ISO 13407 (conception centrée utilisateur).
OK, ça fait beaucoup de raccourcis…mais je vous promets de déveloper tout cela par la suite.
