Les testeurs devraient-ils approuver les versions ou simplement faire rapport sur les tests?

20

Est-il judicieux de donner le pouvoir d'approbation aux testeurs? Si une équipe de test

Il suffit de tester les fonctionnalités, les problèmes, etc., et de simplement rapporter sur une base de réussite / échec, laissant à d'autres le soin d'agir sur ces résultats, ou
Avez-vous le pouvoir de bloquer eux-mêmes les communiqués sur la base de ces résultats?

En d'autres termes, les testeurs devraient-ils être tenus de réellement approuver les versions? L'équipe de test avec laquelle je travaille pense que oui, et nous avons un problème avec cela en raison du «fluage de la portée des tests» - le refus d'approuver les versions est parfois basé sur des problèmes explicitement non traités par la version en question.

testing release-management process

— Ernest Friedman-Hill
source

2

Veuillez reformuler votre question afin qu'elle ne soit pas un sondage. Quel est le problème que vous essayez de résoudre?

— M. Dudley

5

«devrait» dépend en grande partie de la structure organisationnelle de l'entreprise. S'ils sont mesurés sur les bugs trouvés en production, pouvoir tenir une version buggy est un outil essentiel.

Excellent point, @MichaelT. Dans mon organisation, les tests sont un rôle plutôt qu'une description de poste, et l'évaluation est plus ponctuelle et pas du tout quantitative. Les déploiements réussis alimenteraient des critiques positives, mais les bogues en production ne seraient pas des points négatifs spécifiques, pas plus que pour n'importe qui d'autre dans l'équipe.

— Ernest Friedman-Hill

5

Si vous rencontrez des problèmes pour que les testeurs refusent d'approuver les versions sur la base de problèmes non prévus, alors vous avez un problème de communication (ils ne savent pas que les problèmes ne devraient pas être résolus) ou des problèmes de personnes (ils se rendent importants; que ce soit la libération est finalement une décision commerciale).

— Jan Hudec

27

Dans la plupart des endroits où j'ai travaillé, les gens de l'assurance qualité ont une sorte d'approbation, mais n'ont pas le pouvoir final de savoir si la libération se poursuit ou non. Leur approbation signifie qu'ils ont terminé les tests attendus par le plan de version, et non que la version est parfaite.

En fin de compte QA! = L'entreprise et l'entreprise doivent décider si elles sont d'accord avec le déploiement du code dans l'état actuel ou si l'avantage l'emporte sur l'inconvénient ou autre. Cela est souvent effectué par les clients ou les parties prenantes immédiatement avant le déploiement et est souvent appelé Acceptation des utilisateurs.

Si votre QA est également votre groupe d'acceptation des utilisateurs, il est possible qu'ils aient le pouvoir de définir votre version candidate comme inacceptable, mais si vous rencontrez ces problèmes hors de portée du correctif de bogue / itération / sprint / changement demandez / quoi que vous fassiez de votre temps, le gestionnaire de projet ou les intervenants du secteur d'activité doivent avoir une rencontre avec Jésus avec l'équipe d'AQ.

Il est bon de signaler les défauts préexistants ou les résultats inattendus de nouvelles exigences, mais s'il est hors de portée et non désastreux, il n'est généralement pas acceptable de l'étiqueter comme un problème de blocage. Il va dans l'arriéré pour que le propriétaire du produit établisse des priorités comme tout le reste.

— Facture
source

Qui décide si vous inviterez le client à effectuer un test d'acceptation sur le build 1234 ou s'il ne suffit pas pour les tests d'acceptation?

— Bart van Ingen Schenau

3

@BartvanIngenSchenau: Le propriétaire du produit / chef de projet doit avoir le dernier mot à ce sujet. Parce que même les tests d'acceptation vont souvent gonfler si besoin est (voulez-vous la fonctionnalité X maintenant même si nous ne pouvons pas faire fonctionner Y avec, ou voulez-vous attendre 2 mois de plus jusqu'à ce que nous la réparions?) Et le propriétaire du produit négocie cela.

— Jan Hudec

en plus de ce que Jan a dit, dans de nombreuses méthodologies, il y aurait un calendrier ou une cadence ici. certains déploient tous les candidats qui survivent au test de fumée initial sur l'UAT, certains déploient automatiquement tout ce qui est vérifié dans la branche candidate, certains tout ce qui est vérifié dans le principal. idéalement, vous avez montré les progrès des parties prenantes au fur et à mesure que vous avancez, donc il ne devrait pas y avoir beaucoup de surprise à la fin. dans certains de ces cas, vous finissez par montrer aux parties prenantes ce que les gens de l'AQ vous ont traîné à travers les charbons et ils disent simplement "qui s'en soucie" et c'est fini.

— Bill

Dans les SaaS modernes avec déploiement continu, le cycle de déploiement du code (service) peut être distinct du cycle de publication des fonctionnalités (métier). Ce cycle de libération des fonctionnalités peut être implémenté à l'aide d'indicateurs ou de basculements de fonctionnalités, par exemple de l'alpha (interne) à la bêta (opt-in) à la disponibilité générale. C'est une façon d'impliquer une approbation commerciale plus formelle distincte et indépendamment de la déployabilité d'un code ou de services particuliers. L'inverse, liant les versions des fonctionnalités aux déploiements de services, introduit le couplage et les risques dans le processus qui peuvent être évités avec la technique d'indicateur de fonctionnalité.

— Will

@Je ne suis pas en désaccord, mais quelqu'un continue de faire appel au jugement si ces fonctionnalités cachées sont suffisamment cachées pour ne pas être remarquées par des utilisateurs autres que l'équipe bêta lors du déploiement initial et, finalement, partout où j'ai utilisé cette approche, la séquence joue plus ou moins les mêmes, mais avec des étiquettes différentes sur les pièces mobiles et le risque a changé un peu. Je préfère la situation que vous décrivez, mais l'équipe QA trouvant quelque chose de préexistant ou le chef de produit décidant de continuer de toute façon est autant une chose dans ce modèle que n'importe quelle autre dans mes expériences.

— Bill

6

Quelqu'un a besoin de cette autorité . Que ce soit un testeur, l'équipe de testeurs, le chef de l'équipe de testeurs ou le chef de l'organisation de développement est quelque peu hors de propos. Ou peut-être plus précisément, cela dépend de l'organisation.

En fin de compte, le choix de publier un logiciel est une fonction commerciale. L'entreprise doit décider si la qualité est appropriée. On peut dire que le directeur de l'assurance qualité devrait prendre cette décision ou la transmettre à l'unité commerciale appropriée. Tout dépend de la taille de l'entreprise, de l'importance relative de la qualité, etc.

Cela étant dit, les informations utilisées pour prendre la décision commencent par le testeur . Qu'ils aient le pouvoir d'arrêter ou non une libération, ils devraient se sentir responsables d'informer les décideurs lorsqu'ils voient quelque chose qui, selon eux, devrait retarder la libération.

— Bryan Oakley
source

6

Donner une autorisation de signature (c'est-à-dire un droit de veto) pour les versions aux testeurs est tout aussi logique que d'accorder ce droit aux développeurs: aucun.

Les testeurs et les développeurs sont principalement des techniciens, ils sont donc susceptibles de prendre leurs décisions principalement pour des raisons techniques. Mais, les préoccupations qui doivent être pesées lors de la réalisation d'une version sont à la fois des préoccupations techniques et commerciales. De toute évidence, le client ne sera pas satisfait si vous livrez un produit contenant des bogues, mais le client sera tout aussi mécontent si vous continuez à reporter une version car il y a encore des problèmes ouverts sur le produit.

Quelqu'un doit trouver le bon équilibre entre un bon produit et le respect du calendrier promis au client. Pour ce faire, vous ne devez pas être impliqué dans le projet dans un rôle purement technique, mais plutôt dans un rôle plus orienté vers les affaires / la gestion comme le chef de projet ou le propriétaire du produit et prendre votre avis des testeurs et des développeurs.

— Bart van Ingen Schenau
source

1

J'ai voté contre parce que je suis fondamentalement en désaccord avec plusieurs points et hypothèses que vous faites. Je ne suis pas d'accord sur le fait que le contrôle qualité ne devrait pas avoir le droit de veto sur une version car de nombreux groupes d'assurance qualité opèrent également dans un rôle d'acceptation des utilisateurs. De plus, je ne suis pas d'accord avec l'hypothèse selon laquelle les testeurs sont des techniciens. Ce n'est pas toujours le cas, tous les groupes qui publient des logiciels ne peuvent pas se permettre une équipe d'AQ complète, de sorte que ce rôle peut incomber à des analystes commerciaux qui peuvent ne pas être techniques du tout.

— maple_shaft

1

en plus du point de maple_shaft, je vois souvent le dernier appel sur cette gauche à quiconque est dans le rôle de client, sauf si quelque chose de terrible est identifié. c'est en fin de compte leur produit livrable et ils sont les plus susceptibles d'avoir le bon point de vue sur le risque en supposant que vous leur fournissez des informations précises.

— Bill

5

La décision de «libérer» ou de «ne pas publier» est en fin de compte une décision commerciale, où une analyse rigoureuse risque / récompense doit être effectuée.

Il est insensé pour toute organisation de demander à l'équipe de test d'assumer cette responsabilité ou à l'équipe de test d'accepter cette responsabilité.

Le rôle de l'équipe de test est de fournir une analyse de la qualité du logiciel, de sa disponibilité à être publié et de tout risque identifié comme une entrée dans la décision commerciale de publier ou de ne pas publier.

Comme d'autres l'ont noté, _ quelqu'un _ (et je crois qu'il s'agit d'un individu) a besoin de l'autorité pour prendre la décision de "libérer" ou de "ne pas libérer". Cette même personne peut avoir délégué cette décision dans des conditions spécifiques (c'est-à-dire sans bug P1 ou P2)

— Jordan
source

3

J'ai travaillé avec la même situation de testeurs dépassant les limites et inventant des moyens toujours plus créatifs de casser un système qui, une fois le risque évalué, sont incroyablement peu susceptibles de se produire en production.

Bien que je comprenne et félicite l'équipe de test de ne pas vouloir envoyer de version imparfaite, cela nécessite une forte propriété du produit pour définir ce qu'est un «risque acceptable».

D'après mon expérience, l'équipe de test devrait avoir un droit de veto sur la sortie du logiciel, mais ce veto devrait pouvoir être annulé par le propriétaire du produit, mais uniquement après discussion avec les testeurs principaux.

Les logiciels ne seront jamais parfaits, si vous souffrez de fluage de test, vous ne recevrez jamais rien avant qu'il y ait un problème de production majeur (qui ne sera pas testé correctement) et précipité.

— Michael
source

1

C'est un vrai problème mais je ne sais pas si c'est nécessairement le problème du PO. Mon interprétation est qu'en quelque sorte les testeurs interprètent de nouvelles exigences qui n'étaient pas définies à l'origine.

— maple_shaft

2

mon expérience avec les équipes de test m'a conduit à tomber de l'autre côté. Pour moi, le QA ne devrait pas s'attendre à pouvoir bloquer un déploiement sans faire valoir ses arguments auprès du reste de l'équipe ou amener le propriétaire à remplacer l'équipe.

— Bill

1

C'est vrai - je n'étais probablement pas assez explicite, les mêmes problèmes se produisent lorsque les testeurs soulèvent des défauts, et je cite, "dans le vif du sujet", ce qui conduit aux mêmes problèmes - rien n'est jamais sorti.

— Michael

Dans mon cas, c'est plutôt l'interprétation de @maple_shaft; pas tant être sournois dans la recherche de moyens de casser le logiciel, que de signaler l'échec à gérer des cas explicitement non pris en charge.

— Ernest Friedman-Hill

1

@ ErnestFriedman-Hill Il semble que vous décriviez des exigences négatives et ce sont celles qui manquent dans vos documents d'exigences fonctionnelles. Une exigence négative est une déclaration explicite sur ce qu'un système ne fera PAS et peut être aussi acceptable que les exigences normales. Si ceux-ci sont déclarés, leurs cas de test par rapport aux exigences négatives ne sont pas valides.

— maple_shaft