L'AQ doit-elle faire partie du département de développement?

Je travaille pour une petite entreprise qui a un département de développement de produits depuis un bon moment. Ce que nous n'avons pas eu, cependant, c'est un groupe AQ ​​/ test.

Nous cherchons à ajouter un groupe de test, mais nous nous efforçons de déterminer où les placer au mieux dans la structure organisationnelle de l'entreprise. Plus précisément, nous allons embaucher un poste de «testeur principal». Doivent-ils être intégrés au département de développement de produits ou doivent-ils être un nouveau département? Devraient-ils être ailleurs?

Notre entreprise est structurée comme suit:

• PDG
  • CTO
    • Directeur développement produit
    • Directeur du service à la clientèle
      • Développeurs
    • VP Opérations
      • Ingénieurs réseau
  • Ingénieurs commerciaux / commerciaux
  • Président
    • Manette

Oui et non :)

Les développeurs et les personnes chargées de l'assurance qualité devraient avoir le même objectif (et leurs performances mesurées par rapport à cela): fournir un produit de qualité dans les délais et le budget. Vous pouvez définir un "produit de qualité", mais il doit être le même pour les deux groupes. Pourquoi? Parce que si ce n'est pas la même chose, vous obtiendrez deux groupes avec des agendas différents et qui peuvent rapidement se dégrader dans une situation qui se fait au détriment du produit / de l'entreprise.

L'AQ doit travailler (très) étroitement avec les développeurs et vice versa, mais les deux doivent être totalement indépendants l'un de l'autre dans leur prise de décision. Ils sont, après tout, responsables de différents aspects du développement de produits

La façon dont nous l'avons mis en place est que le "Développement Produit" est un département "virtuel" réalisé par deux départements concrets: QA et Développement. Tous deux relèvent du même membre de l'équipe de direction: le CTO. Cela garantit qu'il y a une seule personne responsable du produit (notre CTO) et que l'AQ et le développement sont indépendants l'un de l'autre.

Cela dépend vraiment de la gravité de votre entreprise en matière d'AQ. Par exemple, ferez-vous du développement piloté par les tests?

Vous mentionnez un "groupe de test", cela suggérerait plusieurs personnes. S'il s'agit en fait d'un groupe de plusieurs personnes, il devrait probablement s'agir d'un département distinct. Ce qui me laisse perplexe cependant, est-ce que vous avez actuellement au moins une personne dédiée à l'AQ et aux tests? Sinon, prévoyez-vous de constituer rapidement un tout nouveau groupe? Si tel est le cas, il s'agira d'une transformation organisationnelle substantielle et peut entraîner des frictions importantes avec vos développeurs actuels qui doivent également changer leur façon de travailler.

Si ce que vous envisagez est d'embaucher une seule personne AQ maintenant et peut-être de développer lentement la fonction AQ, il serait probablement préférable que cette personne relève directement du directeur du développement de produits. La partie la plus difficile de son travail, et la plus importante, sera de transformer votre culture organisationnelle pour intégrer l'AQ à toutes les étapes du processus plutôt que quelque chose qui se fait après coup.

Ce que nous n'avons pas eu, cependant, c'est un AQ ...

J'y suis allé - mes sincères condoléances. Bien donné ci-dessus, je dirais que l'obtention de testeurs sera beaucoup mieux que ce que vous avez maintenant, quel que soit le département dans lequel ils atterriront.

A part cela, je me sens en sécurité en recommandant un département séparé pour l'AQ.

J'ai participé à deux versions qui étaient interdites du point de vue de l'assurance qualité - une fois en tant que testeur, une autre en tant que développeur. Dans les deux cas, je pense que le fait d'avoir un service d'assurance qualité distinct m'a été très utile.

Autant que je sache, lorsque les testeurs sont dans un département séparé, il devient plus difficile de cacher les problèmes de qualité des produits derrière un faux "alignement d'équipe" . Cela a aidé tout le monde à comprendre clairement ce que nous publions et pourquoi. Cela a à son tour aidé à gérer les attentes des clients et à planifier leur développement.

Dans presque tous les cas, l'assurance qualité doit être distincte du développement. Bien que l'objectif entre les deux départements soit le même (publier des produits / solutions de qualité), l'AQ doit avoir le sentiment d'avoir l'autorisation de corriger et de faire des suggestions sur les produits en développement, et d'être sur un pied d'égalité. Si le chef de l'AQ relève directement du chef du développement, cela peut amener l'AQ à prendre du recul et à être à la merci du développement (et par conséquent le code / les produits les plus bâclés sont poussés à la production).

Cela dépend de la méthodologie de développement que vous utilisez: si vous faites du Agile / Lean, alors Agile Testing pourrait être la voie à suivre et, en tant que tel, devrait être proche des développeurs.

D'après ce que vous dites, vous avez une assez petite entreprise. Il est logique pour moi de profiter de cette taille et de cette capacité à communiquer pendant que vous le pouvez, avant de devenir plus gros. Cela implique de les maintenir dans le développement.

Dans une grande entreprise, lorsque vous avez des équipes de développement et d'assurance qualité de taille décente, il peut être judicieux de les diviser ensuite et de les faire maintenir leurs propres objectifs d'équipe séparés, etc.

Maintenant, je serais également sûr que les premières positions QA soient des positions SDET ... ie. testeurs avec des côtelettes de codage. Obtenez votre automatisation opérationnelle, stable et stable dès le départ.