Viabilité d'une équipe de développement sans rôle de testeur * dédié * [fermé]


9

J'ai beaucoup réfléchi récemment à la façon de créer une équipe de développement allégée. En fin de compte, j'aimerais ouvrir ma propre petite maison de logiciels avec un petit nombre de personnes partageant les mêmes idées. L'objectif n'est pas de devenir riche, mais plutôt d'avoir un environnement de travail sain.

Jusqu'à présent, je définis une équipe allégée comme suit:

  • Petit;
  • Auto-organisation;
  • Tous les membres doivent avoir l'AQ à l'esprit;
  • Les membres doivent être capables de jouer plusieurs rôles

Le dernier point est celui où je m'inquiète un peu car, comme le dit le mantra ...

Les développeurs font de mauvais testeurs.

Bien que je comprenne que, souvent, les développeurs sont «trop proches» de leur code ou du code de leurs collègues pour effectuer des évaluations de qualité de niveau supérieur, je ne suis pas convaincu qu'ils soient de mauvais testeurs de facto . Au contraire, je suis d'avis que les qualités d'un bon développeur se chevauchent grandement avec les qualités d'un bon testeur.

En supposant que cela soit correct, j'ai pensé à différentes façons de contourner le problème dev / tester et je pense avoir trouvé un modèle viable.

Mon modèle nécessite:

  • Une petite maison de logiciel avec 2+ projets
  • Une approche agile (itérative) du développement et de la livraison
  • 1 équipe par projet
  • Tous les membres de l'équipe seront des développeurs de logiciels
    • Leur description de travail indiquera clairement le développement , l'assurance qualité , les tests et la livraison comme responsabilités

Si toutes ces conditions préalables sont remplies, les projets peuvent être organisés de la manière suivante (cet exemple fera référence à deux projets, A et B ):

  • Chaque membre de l'équipe alternera entre le rôle de développeur et le rôle de testeur
  • Si un membre de l'équipe est développeur sur le projet A , il sera testeur sur le projet B
    • Les membres travailleront sur seulement 1 projet à la fois, et par conséquent devraient agir comme soit un Dev ou un testeur.
  • Un cycle de rôle se compose de 3 itérations en tant que développeur et 2 itérations en tant que testeur (encore une fois, sur deux projets différents)
  • Les équipes de projet auraient à tout moment 3 développeurs et 2 testeurs.
  • Les cycles de rôle des membres doivent être déphasés par 1 itération.
    • Cela minimise la brutalité des changements d'équipe. Pour chaque itération, 2 devs et 1 testeur resteront les mêmes que l'itération précédente.

Compte tenu de ce qui précède, je vois les avantages et les inconvénients suivants:

Avantages

  • Distribue la connaissance du projet dans toute l'entreprise.
  • Garantit que les membres de l'équipe ne testent pas le code qu'ils ont aidé à écrire.
  • Les cycles de rôle hors phase signifient qu'aucun projet n'a jamais un commutateur de membre à 100%.
  • L'alternance des rôles rompt la monotonie des projets ennuyeux.

Les inconvénients

  • Les itérations des deux projets sont étroitement liées. Si un projet devait annuler une itération à mi-parcours et recommencer, les deux projets seraient désynchronisés. Cela rendrait le cycle de rôles difficile à gérer.
  • Cela dépend de l'embauche de développeurs qui travaillent également en tant que testeurs.

J'ai reçu des critiques mitigées lorsque j'ai discuté de cette approche avec des amis et des collègues. Certains croient que peu de développeurs voudraient jamais alterner des rôles comme celui-ci, tandis que d'autres me disent qu'ils aimeraient personnellement l'essayer.

Ma question est donc la suivante: un tel modèle pourrait-il fonctionner dans la pratique? Sinon, pourrait-il être modifié en un modèle fonctionnel?

Remarque: Par souci de concision, je ne me suis concentré que sur les rôles de développeur et de testeur. Je développerai d'autres rôles si nécessaire.



Bien qu'il y ait un chevauchement quant à savoir si les développeurs peuvent ou doivent être des testeurs, je pense que le nœud de cette question concerne les rôles hors de la phase 2 sur le modèle de 2 projets.
MetaFight

2
FWIW mon opinion personnelle est que vous risquez beaucoup avec une telle approche. Je suis un ancien testeur (et pas le pire) et quand j'ai atterri dans un projet où je pouvais "entrelacer" 2 rôles, j'ai d'abord pensé wow, une chance de comprendre comment le faire correctement. Après environ six mois, j'ai changé d'avis et je ne veux plus jamais réessayer. Les deux rôles (dev et QA) nécessitent une concentration de 100% pour bien faire les choses, mais lorsque vous entrelacez, vous distrayez et perdez soit en qualité, soit en productivité, soit dans les deux. BTW obtenant un testeur dédié dans ce projet a produit le retour sur investissement le plus impressionnant que j'ai jamais vu
gnat

2
@gnat, mais vous n'avez pas expliqué pourquoi un développeur ne pouvait pas remplir le rôle de testeur. Certes, la personne en question devrait le prendre au sérieux en tant que rôle à temps plein, c'est pourquoi j'ai suggéré qu'elle alterne les projets et ne travaille que sur un seul projet à la fois. Je ne m'attends pas à ce qu'un développeur soit capable de faire cela ... juste ceux qui feraient de bons testeurs s'ils avaient choisi cette voie.
MetaFight le

2
En paraphrasant ce que vous voulez faire: "Je veux ouvrir une chirurgie médicale, plutôt que d'embaucher quelques anesthésistes, j'emploierai suffisamment de chirurgiens et je les ferai pivoter dans ce rôle". Votre proposition montre un manque (typique) de compréhension de ce qu'un testeur professionnel offre à une équipe. Vous pouvez le faire, beaucoup le font, certains le font fonctionner. Ce que vous ne saurez jamais, c'est ce que vous manquez et ce que vous pourriez faire mieux. Soit dit en passant - Les tests ne sont pas de l'AQ - juste une leçon qu'un testeur professionnel vous apprendra.
mattnz

Réponses:


8

Je ne suis pas d'accord avec

Les développeurs font de mauvais testeurs

La plupart des équipes sur lesquelles j'ai travaillé au cours de ma carrière n'ont bénéficié d'aucune assistance QA. Cela comprend quelques grandes sociétés mondiales impliquant des produits tels que leur système mondial de connexion et d'enregistrement. Dans un autre cas, j'avais 30% des revenus de l'entreprise passant par une boîte sur mon bureau. (Ces pratiques ne sont pas conseillées BTW;)) Ces sociétés comptaient sur les ingénieurs pour s'assurer que leur code fonctionnait correctement. Et nous, étant soucieux du détail, un peu compulsifs et fiers de notre travail, nous ferions tout notre possible pour nous assurer que notre logiciel fonctionnait correctement.

De plus, en tant que développeur, je fais beaucoup plus de tests que les testeurs. Je teste régulièrement mon code à 90% ou 100% si je ne travaille pas avec Java.

J'aime travailler avec les testeurs car ils abordent la question sous un angle différent et attrapent des choses auxquelles je ne pensais pas. Mais je ne compte vraiment pas sur eux pour fournir plus de 30 à 50% de couverture de test, alors que je me tiens responsable de 100%. (BTW Ce n'est pas un slam sur eux - ils sont généralement étalés entre les projets.)

Plutôt que de demander aux ingénieurs lors des entretiens s'ils veulent faire de l'AQ, demandez: si un bug apparaît en production, qui est responsable? Si j'introduis un bug et qu'un client en fait l'expérience, je me sens mal et j'assume la responsabilité. Je ne blâme pas les gars de l'AQ. À mon humble avis, c'est le genre d'ingénieur que vous souhaitez embaucher (et travailler avec)

Ma méthode pour assurer la qualité est a) des tests unitaires super agressifs (bien que je ne puisse pas tout à fait me résoudre à faire un développement entièrement piloté par les tests), b) un processus de révision de code fort aide vraiment, et c) intégrer une intolérance et une impatience avec défauts dans la culture d'équipe.

J'ai toujours été frappé par le fait que les gars les plus âgés étaient ceux qui étaient les plus diligents et attentifs aux problèmes même mineurs, car ils pouvaient signaler un problème plus important. Mais ce sont surtout eux qui sont les plus disposés à passer le temps de bien faire les choses.

Mais la plupart des équipes sur lesquelles j'ai travaillé, en particulier pour les petites entreprises, n'avaient pas de composante AQ formelle.


6

Je suis d'accord avec la réponse de @Rob Y et je voudrais ajouter quelques points:

  • En agile, les testeurs dédiés au sein d'une équipe sont un anti-modèle, car ils forcent les équipes à travailler en pipeline et sont intrinsèquement inefficaces. Vous vous retrouvez constamment avec des histoires qui sont "dev done" mais non testées. Les testeurs dédiés sont très bien s'ils travaillent en dehors de l'équipe (ou d'une équipe distincte).

  • Les développeurs font de mauvais testeurs ... et les testeurs font de mauvais testeurs. L'AQ est difficile. En fait, c'est très difficile. Votre problème n'est peut-être pas lié aux personnes et aux rôles. Votre problème pourrait être que votre logiciel est précipité. Encore une fois, en agile, il est de la responsabilité de votre équipe de tester avant la production (qu'elle ait ou non dédié un contrôle qualité).

  • L'AQ fait partie du développement, comme le refactoring, l'architecture, etc. Il est de la responsabilité d'une équipe de développement de produire des logiciels selon un certain standard, convenu et réaliste. Les QA n'amélioreront pas cette norme. De meilleurs développeurs le feront probablement.

  • Provocation: Qui a dit que les QA sont meilleurs que les développeurs de QA-ing? C'est quelque chose que les gens disent mais ... [citation nécessaire]. La mentalité de "hacker" nécessaire de QA est une mentalité de développeur. En fait, tous les hackers sont ou étaient des développeurs, pas QA ...

  • Provocation 2: 99% du travail d'AQ peut être (et, oserais-je dire, devrait être ) automatisé via des scripts. Une bonne équipe le fera, et pour le faire correctement, vous avez besoin de ... développeurs.


Commentaire sur Provocation 2: l'automatisation des tests peut être effectuée par les développeurs, mais pas nécessairement. Les testeurs qui savent coder (mais pas au niveau d'un développeur pro) peuvent écrire des scripts assez bons.
Mate Mrše

4

Lors d'un travail précédent, nous n'avions que des développeurs et pas de personnel QA. En conséquence, il n'y avait personne d'autre à blâmer si un problème arrivait à la production. Nous avons pris très au sérieux nos responsabilités en matière d'AQ et nous nous sommes largement appuyés sur des suites de tests automatisés. Étant donné que l'écriture de tests automatisés est toujours en cours de codage, ce n'était pas un gros problème pour que les développeurs le fassent.

L'essentiel est de l'intégrer à la culture de l'équipe et à chaque projet. Nous avons rédigé des plans de test (juste de brèves listes de tests que nous avions l'intention d'écrire pour un projet), et d'autres développeurs examineraient et suggéreraient des cas et des scénarios que nous avions manqués.

Si vous êtes rigoureux à ce sujet, cela peut très bien fonctionner. C'est ce que nous avons fait - nous avons eu une excellente disponibilité et de faibles défauts dans un service Web de commerce électronique toujours actif.


ce post est assez difficile à lire (mur de texte). Pourriez-vous le modifier sous une meilleure forme?
gnat

2
Désolé, brain-dump du matin. Je l'ai cassé maintenant.
Rory Hunter

2

D'abord une mise en garde - J'ai travaillé professionnellement en tant qu'ingénieur QA et ingénieur logiciel.

Un tel modèle pourrait-il fonctionner dans la pratique?

Tout est possible.

Bien que je comprenne que, souvent, les développeurs sont «trop proches» de leur code ou du code de leurs collègues pour effectuer des évaluations de qualité de niveau supérieur, je ne suis pas convaincu qu'ils soient de mauvais testeurs de facto. Au contraire, je suis d'avis que les qualités d'un bon développeur se chevauchent grandement avec les qualités d'un bon testeur.

Cela dépend du type de test dont vous avez besoin. Si vous avez besoin de tests manuels monotones et répétitifs pour vous assurer que chaque écran ou élément a vraiment été traduit en elbonien ... vous allez avoir des problèmes.

Et d'après mon expérience, chaque projet nécessite au moins un peu de ce genre de test (même si tous les projets n'ont pas fait ce genre de test). Le problème est que vous ne recevez pas ce type de test de la part de personnes peu familiarisées avec les meilleures pratiques en matière d'AQ. Enfer, vous ne l'obtenez même pas de gens qui connaissent les meilleures pratiques, mais "faites confiance" aux développeurs.

En tant que testeur, vous ne pouvez pas faire confiance aux développeurs. J'ai perdu le compte des bogues que j'ai trouvés "qui n'auraient pas pu être causés par ce changement" ou "qui fonctionnent parfaitement bien sur ma boîte de développement".

Même si vous pouvez trouver des développeurs qui peuvent tolérer de ne pas faire ce qu'ils aiment faire 2 semaines sur 5, vous rencontrerez également cette contradiction fondamentale. Pire encore, vous dépensez du temps et de l'énergie pour former les gens à être bons dans deux emplois plutôt qu'un. Les entreprises ont déjà du mal à trouver et à former des personnes compétentes pour un seul emploi, sans parler de deux.

Peut-être que vous êtes génial d'une manière que je n'ai pas encore rencontrée - mais j'en doute.


Peut-être que mon modèle a besoin d'un rôle Sr QA pour examiner les approches proposées par mes développeurs de test et pour recommander des approches de meilleures pratiques. Oh, et la plupart des gens ne me trouvent pas génial, mais ma maman le fait :) et c'est assez bon pour moi!
MetaFight

Je suis en train de transférer certains de nos rôles d'AQ vers des chefs de produit. Il semble que vous n'ayez pas l'acceptation par les propriétaires de produits des histoires d'utilisateurs ou des critiques de sprint. Ces deux problèmes entraîneront de nombreux problèmes que l'équipe de développement aurait pu manquer. Avant cela, cependant, si vous ne pouvez pas faire confiance aux développeurs pour produire de la qualité, vous devez trouver différents développeurs. C'est ma conclusion - d'après mon expérience - vous ne pouvez pas former une mauvaise qualité à partir d'un mauvais développeur. J'ai travaillé avec de nombreux développeurs «faites le travail», et c'est le résultat que vous obtenez d'eux. Une bonne équipe Scrum nécessite de bons développeurs.
David Anderson

0

Je pense que cela pourrait fonctionner, mais il y a deux ou trois choses que je voudrais m'assurer que vous fassiez.

  1. Soyez très direct sur le double rôle des candidats. Ce n'est pas pour tout le monde pour de nombreuses raisons. Si vous avez trop de gens qui ne l'aiment pas, vous aurez échec et roulement.
  2. Ayez un plan où vous pouvez évaluer la meilleure façon d'incorporer cela à l'équipe. Bien que j'aime me concentrer sur une tâche / un projet à la fois, je ne suis pas sûr de vouloir ne pas programmer pendant une très longue période. Peut-être que les tests sont de belles vacances loin de la programmation. Non pas que ce soit plus facile, il suffit d'utiliser des cellules cérébrales différentes pour changer. Soyez prêt à l'essayer de différentes manières avant de décider de ce qui est le mieux.

La synchronisation des projets ne semble pas être une solution pratique. Si quelqu'un est un testeur sur un projet, il peut être le meilleur candidat pour remplacer un programmeur et vice versa.

Ce plan ne permet pas aux équipes de s'auto-organiser suffisamment. Une stratégie ne conviendra probablement pas à toutes les équipes et à tous les projets.


Le rôle de testeur dans ce cas impliquerait probablement des tests manuels et automatisés. Je m'attendrais à ce que les développeurs écrivent des tests unitaires et d'intégration, mais les testeurs feraient de même. Il est à espérer que la division exacte de l'écriture test codée serait un équilibre naturel atteint après quelques itérations.
MetaFight le

Il ne devrait même pas être question de savoir si les candidats sont prêts à jouer un double rôle ou non. Si vous voulez diriger une entreprise prospère, vous devez mettre les gens là où ils excellent. Pourquoi mettre le gars à l'essai qui peut concevoir et coder 2 systèmes fiables par lui-même alors qu'il faut une équipe de 4 ou 5 pour faire un seul système en même temps? De même, le test a ses propres compétences pour bien le faire. Les plus grands progrès de la civilisation humaine ont eu lieu lorsque les humains ont commencé à se spécialiser. Pourquoi diriger une entreprise de logiciels serait-il différent de ce que Mère Nature a déjà prouvé le mieux?
Dunk
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.