Pourquoi le guide Scrum dit pas de testeurs?

J'ai lu le Scrum Guide de scrum.org et il dit:

Les équipes de développement ne contiennent pas de sous-équipes dédiées à des domaines particuliers tels que les tests ou l'analyse commerciale.

Dans sa traduction littérale, cela signifie qu'il n'y a pas de testeurs, ce qui prête à confusion. Comment peuvent-ils suggérer cela?

Cela signifie que:

1. Les testeurs sont intégrés dans l'équipe de développement - des outils de construction pour aider les développeurs à tester ainsi qu'à tester.

   ou:

2. L'équipe pratique le développement piloté par les tests - c'est-à-dire qu'elle écrit des tests automatisés qui font fonctionner le système.

Dans les deux cas, il n'est pas nécessaire de disposer d'une équipe de test distincte.

Dans sa traduction littérale, cela signifie qu'il n'y a pas de testeurs ce qui prête à confusion ... Comment peuvent-ils suggérer cela?

Oui, c'est exactement ce qu'ils suggèrent. En d'autres termes - les développeurs sont les testeurs et les testeurs sont les développeurs.

L'idée est de favoriser l'appropriation et la qualité du code .

Cela ne signifie pas que le code n'est pas testé, mais que les personnes impliquées dans sa rédaction sont celles impliquées dans le test - il n'y a pas de séparation des responsabilités.

Le problème que cette approche tente de résoudre est la séparation trop courante entre les développeurs et les testeurs, où les développeurs écrivent du code et le "jettent par-dessus le mur" à l'autre équipe, puis il va et vient, retardant le projet et produisant logiciel de qualité inférieure.

La partie fondamentale de ceci est que la responsabilité du codeur est de créer un code qui fonctionne et remplit l'exigence. Cela nécessite un état d'esprit particulier - "Le code que j'écris fait ce qu'il est censé faire."

Mélanger les responsabilités du codeur signifie que le codeur doit maintenant entrer dans d'autres états d'esprit pour d'autres activités, cependant, en tant que codeur, il est difficile, voire impossible, de se séparer complètement de cet état d'esprit.

La responsabilité du testeur est de trouver des bogues et des endroits où la fonctionnalité s'écarte de la fonctionnalité requise. Cela a nécessité la mentalité de "Le code est cassé et je vais voir comment."

De même, un analyste commercial essaie d'identifier les exigences que le client demande réellement. Cela nécessite un autre état d'esprit de "l'application ne fonctionne pas de cette façon, mais elle devrait."

Pour qu'un codeur fonctionne dans l'une de ces autres capacités, il y a une probabilité raisonnable que les mentalités entrent en conflit et le codeur exécute en dessous de la normale:

• Coder / QA - "Le code fonctionne parfaitement, et j'ai déjà codé pour gérer toutes les façons possibles, je pense que cela pourrait le casser."
• Coder / BA - "Le code devrait fonctionner comme je le souhaite et ce seraient des choses intéressantes à ajouter auxquelles le client n'aurait pas pensé.

Cela ne veut pas dire que chaque codeur est sensible à ces problèmes (j'ai rencontré certains types de codeurs / AQ très doués ... mais pas pour le code qu'ils ont écrit).

Cela s'étend également à l'équipe de développement. Mélanger les responsabilités et les mentalités associées de ces responsabilités pour une équipe de développement compromet le produit final (le code).

Il indique qu'il n'y a pas de sous- équipe dédiée aux tests. Cela ne signifie pas qu’il n’y ait aucun test. Cela signifie seulement que les membres de l'équipe feront leurs propres tests et testeront souvent le code / les fonctionnalités d'autres personnes. Je ne suis pas très familier avec la méthodologie Scrum, mais je vais dire un mot et dire que le client peut également être impliqué dans le test.

Je pense que cela signifie en partie que vous êtes censé écrire des tests pour votre propre code afin que vous sachiez qu'il fonctionne (sinon, vous ne l'avez pas vraiment terminé) et en partie que vous pourriez bien être censé être un testeur pour le code d'autres personnes parfois .

Plutôt que de permettre aux gens de décharger le travail de qualité logicielle sur quelqu'un d'autre et de l'ignorer, cela oblige tout le monde à penser tout le temps au code qu'ils écrivent dans une perspective de qualité, c'est donc une bonne idée.

Cette déclaration essaie essentiellement d'éviter le travail cloisonné. Une partie de la solution à ce problème est des pratiques telles que - le développement piloté par les tests - la programmation en binôme - les demandes d'extraction - l'automatisation des tests et autres qui font tous du test une partie intrinsèque du processus de développement plutôt que quelque chose qui est fait isolément sur le côté ou 'après'.

De plus, il y a très peu de discussions sur les rôles dans le Scrum Guide. En fait, ils parlent de l'équipe de développement. Ce que cela signifie, c'est que vous voulez une solide équipe interfonctionnelle. Cela signifie qu'en fonction de ce dont vos projets ont besoin, vous avez besoin d'une gamme de compétences, telles que UX, BA, QA / Tester, Ops, Coder, etc., mais que ce soit une ou plusieurs personnes les couvrant, n'a pas vraiment d'importance.

Les équipes avec lesquelles je travaille ont certainement le QA comme rôle, car nous avons des personnes DevOps. Mais ils sont tous aussi des développeurs, juste avec une spécialisation dans ces domaines. L'astuce est vraiment de ne pas tomber dans des silos et de travailler de manière isolée.

Cela ne signifie pas nécessairement qu'il n'y a pas de testeurs. Il se peut qu'une équipe Scrum ait des testeurs dédiés ou non.

Pour moi, ce que signifie cette déclaration sur Scrum, c'est que vous devriez penser à l'ensemble du pipeline de livraison en une seule équipe. Faire partie de la même équipe suggère plusieurs choses:

1. Il existe une seule estimation pour une histoire / un bug / une tâche. Il n'y a pas d'estimation de dev et d'estimation de test.
2. L'équipe n'évalue pas une histoire et s'y engage sans le testeur présent.
3. Si quelque chose ne va pas, ce n'est pas plus la faute du testeur que la faute du développeur. C'est la faute de l'équipe .
4. L'équipe n'a jamais besoin d'emprunter, de demander ou de demander des testeurs.
5. Les tests font partie de la définition du fait. Un travail non testé est un travail incomplet.
6. Les développeurs devraient considérer la testabilité lors de la conception de leur code.

S'ils travaillent ensemble une seule équipe, alors l'équipe réussit ensemble et échoue ensemble. J'ai fait partie d'une équipe Scrum très réussie qui avait plusieurs testeurs. Des testeurs étaient présents lors de tous les standups, séances de toilettage, planification, etc. S'il n'était pas clair comment tester une histoire, l'équipe ne s'y engagerait pas. Nous avons toujours parlé avec nos testeurs lors de l'estimation.

Signes potentiels que vous ne traitez pas vraiment les testeurs comme faisant partie de l'équipe de livraison, même si vous pensez que vous le faites:

1. Les testeurs ont un "standup QA" (ouais, je l'ai vu).
2. Les testeurs ont une structure de gestion distincte.
3. Vous avez un responsable QA.
4. Vous comptez beaucoup sur des tests de bout en bout.
5. Les tests sont écrits le sprint suivant.
6. La plupart des tests ont lieu le dernier jour du sprint.

Ce sont subjectifs et pas nécessairement faux. Ce sont des drapeaux rouges, à mon avis.

Cela dit, il est tout à fait possible d'avoir une équipe Scrum sans personne ayant un rôle désigné de testeur. Cela peut aussi bien fonctionner. Surtout si vous automatisez les tests. TDD aide aussi.