Réponse.

Avec le temps, les tests manuels se sont adaptés aux méthodologies agiles comme Scrum. À l'origine, les testeurs travaillaient « à la fin du sprint », testant le résultat final de tout le travail. Cela entraînait souvent des urgences et des tests insuffisants (histoire).

Le principal problème est le manque de temps pour tester, les changements fréquents des exigences et les tâches qui n'atteignent pas les testeurs pendant le sprint. Les testeurs se retrouvent sous pression, ce qui réduit la qualité (problème).

La solution consiste à intégrer les testeurs dans l'équipe dès le début du sprint : participer aux réunions, planifier les cas de test au fur et à mesure de l'apparition de nouvelles tâches, organiser ensemble des stand-ups quotidiens et des rétrospectives, et favoriser la transparence du statut des artefacts de test (solution).

Caractéristiques clés :

Engagement constant des QA à toutes les étapes du sprint
Mise à jour régulière et planification des cas de test ‘on-the-fly’
Collaboration avec les développeurs pour définir la readiness des tâches à tester

Questions pièges.

Peut-on commencer à tester seulement après avoir terminé toutes les tâches du sprint ?

Non, le testeur doit être impliqué dès les premiers jours du sprint et tester autant que possible la fonctionnalité pas encore complètement terminée.

Tous les bugs doivent-ils être corrigés dans le sprint en cours ?

Pas nécessairement, les bugs critiques oui, les non critiques peuvent être portés dans le backlog externe et corrigés dans le sprint suivant.

Les tests manuels sont-ils nécessaires en cas d'automatisation dans Scrum ?

Oui, les tests manuels sont cruciaux pour vérifier les nouvelles fonctionnalités et les exigences non formalisées, ainsi que pour les tests exploratoires.

Erreurs typiques et anti-patterns

Intégration tardive des tests
Absence de documentation pour les nouvelles fonctionnalités au début
Ignorer la communication et les réunions d'équipe

Exemple de la vie réelle

Cas négatif

Le testeur n'a pas participé à la planification et n'a pas eu accès aux nouvelles histoires de tâches avant la fin du sprint. Au final, les tests ont été écrits dans l'urgence, certaines erreurs ont été reportées aux sprints suivants.

Avantages :

Moins de réunions pour le testeur

Inconvénients :

Erreurs en production, mécontentement des clients, faible couverture

Cas positif

Le testeur a rejoint l'équipe dès les premiers jours du sprint, a participé aux réunions, a vu à l'avance les tâches émergentes et a planifié les tests en parallèle avec le développement.