Pourquoi le guide Scrum dit pas de testeurs?


14

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?


4
Dans sa traduction littérale, cela signifie qu'il n'y a pas de programmeur non plus. Il n'y a pas d'analyste commercial. Une bonne analogie est que tout le monde est un survivant, dont le travail est de faire (et d'apprendre à faire) tout ce qui est nécessaire pour aider tout le monde à survivre.
rwong

3
Non, ce n'est pas du tout la traduction littérale. Il dit qu'il n'y a pas de sous-équipes dédiées, c'est tout. Vous pouvez diviser votre équipe en sous-équipes pour résoudre les problèmes, mais ces équipes devraient être capables de se mélanger et de s'associer en un rien de temps. Cela ne dit rien de ne pas avoir de testeurs.
zzzzBov

Réponses:


25

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.


TDD serait une meilleure approche pour les équipes de démarrage. Je suis fermement convaincu que lorsque les testeurs et les développeurs travaillent ensemble dans des équipes novices, les tests deviennent un problème. Que dis-tu?
Maxood

4
@Maxood: Je dirais que TDD ne rend certainement pas le test manuel superflu. Si quelque chose devient un problème, vous le résolvez; vous ne commencez pas à l'éviter.
Michael Borgwardt

@MichaelBorgwardt Très vrai! Mais que se passe-t-il si vous trouvez votre testeur occupé dans les tests unitaires, qui sont principalement le travail d'un développeur? Je pense que la première option ne devrait être utilisée que pour l'optimisation du code et l'évolutivité des applications, etc. Que dites-vous?
Maxood

7
@Maxood: Les testeurs devraient, à mon avis, ne pas toucher aux tests unitaires. Ils doivent travailler sur les tests d'acceptation, en coopération avec les développeurs, et sont responsables des tests manuels / GUI. Les tests unitaires sont à un niveau qui n'est intéressant que pour les développeurs. La pyramide de test ( blogs.agilefaqs.com/2011/02/01/inverting-the-testing-pyramid ) a également des capacités de réponse, Unit-testing = développeurs, acceptation testing = shared, GUI testing = testers.
martiert

12

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.


2
Je suis un ardent défenseur de ce que la personne A teste ce que la personne B a développé. Quels sont les conseils de Scrum pour éviter les pièges de la «cécité du code propre» (où si vous êtes à la fois développeur et testeur de la fonctionnalité X, vous n'exercez pas le code à tous égards parce que vous savez comment il est codé et supposez qu'il doit travailler ou éviter inconsciemment les points faibles)?
Marjan Venema

1
@MarjanVenema - Ce que la personne A a écrit peut être testé par la personne B, ou les tests automatisés peuvent être écrits avant qu'un code ne soit écrit.
Odé

5
Tous les développeurs ont une cécité QA qui ne disparaît jamais. Ce qui s'est passé dans l'industrie, c'est que les gens sont allés trop loin avec le «QA contre les développeurs» et ont créé ce système «jeter par-dessus le mur», puis il y a un contrecoup. Les développeurs et le contrôle qualité réussissent et échouent en une seule équipe, mais le contrôle qualité est un rôle et une compétence différents du codage. Les codeurs doivent effectuer des tests de développement et les tests unitaires font partie de la qualité, mais ce n'est pas la fonction entière de qualité. En outre, les rôles d'assurance qualité impliquent souvent la création de documentation dans des endroits qui ne sont pas devenus si "agiles" qu'ils ont cessé d'écrire de la documentation technique.
Warren P

6
D'après mon expérience, c'est exactement la séparation des rôles qui permet à un testeur de regarder le logiciel du point de vue d'un utilisateur final et de trouver beaucoup plus de bugs qu'un développeur. Le produit résultant n'est certainement pas "sous-standard".
Giorgio

2
L'AQ et le développement sont deux rôles distincts avec deux ensembles de compétences (et échelles de salaires) différents. Une excellente assurance qualité requiert un niveau de concentration et de spécialisation qui ne se produira tout simplement pas si quelqu'un remplit une double fonction de développeur et d'assurance qualité.
17 du 26

2

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).


1

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.


"Le client peut également être impliqué dans le test" - oui, tout à fait raison, sinon vous avez un projet en cascade où la définition de fait est "nous avons atteint la fin du projet". Ce n'est pas agile.
Robin Green

1

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.


1

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.


1

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.