Les développeurs devraient-ils être impliqués dans les phases de test?

nous utilisons un processus de développement classique en forme de V. Nous avons ensuite les exigences, l'architecture, la conception, l'implémentation, les tests d'intégration, les tests système et l'acceptation.
Les testeurs préparent des cas de test pendant les premières phases du projet. Le problème est que, en raison de problèmes de ressources (*), les phases de test sont trop longues et sont souvent raccourcies en raison de contraintes de temps (vous connaissez les chefs de projet ...;)). Les développeurs font leurs tests unitaires comme ils le devraient.

Ma question est donc simple: les développeurs devraient-ils être impliqués dans les phases de tests et ce n'est pas trop «dangereux». Je crains que cela ne donne aux chefs de projet une fausse impression de meilleure qualité car le travail a été fait, mais les jours ouvrés supplémentaires auraient-ils une valeur? Je ne suis pas vraiment sûr que les développeurs fassent des tests (pas d'offense ici mais nous savons tous qu'il est assez difficile de casser en quelques clics ce que vous avez fait en plusieurs jours).

Merci d'avoir partagé vos avis.

(*) Pour des raisons obscures, l'augmentation du nombre de testeurs n'est pas une option à ce jour.

(Juste au départ, ce n'est pas un doublon de Les programmeurs devraient-ils aider les testeurs à concevoir des tests? Qui parle de préparation de test et non d'exécution de test, où nous évitons l'implication des développeurs)

En regardant votre question très littéralement ("impliqué dans") Ma seule réponse est un absolu sans équivoque

OUI

Les développeurs ne devraient jamais avoir le dernier mot sur leur propre code.

Mais, les développeurs devraient être impliqués dans le test du travail des autres développeurs. Cela fait deux choses:

1. Il apporte aux développeurs un aperçu des tests. Cela provient à la fois du cas général de savoir simplement quelles API sont probablement utilisées à un moment donné, quelles sont les exceptions qui peuvent provenir de ces API et comment elles doivent être traitées. Cela aide également sur un projet spécifique, car les développeurs sont beaucoup plus exposés aux diverses discussions sur la raison pour laquelle quelque chose est fait que l'AQ, ce qui signifie qu'ils peuvent repérer des cas de pointe que l'AQ ne ferait pas. Les bogues détectés par un développeur sont également susceptibles d'être moins chers à corriger car un développeur fournira généralement plus d'informations et beaucoup plus d'informations sur la façon de le corriger immédiatement.
2. Cela donne au développeur une exposition à des parties de l'application auxquelles il ne serait pas autrement exposé. Cela fera d'eux de meilleurs développeurs à long terme pour cette application. Quand je sais comment mon API est consommée, je suis beaucoup mieux à anticiper la prochaine chose que je devrais faire que si je ne fais que conduire une spécification. Plus important encore, je peux dire quand la spécification est erronée avant de commencer à coder si je connais l'application et son utilisation.

Enfin, pourquoi n'utiliseriez-vous pas autant d'yeux que possible? Vous pouvez rarement vous permettre de passer par le processus d'embauche et d'intégration pour amener des personnes AQ supplémentaires à bord pour le temps de crise. Alors, où trouvez-vous les yeux supplémentaires dont vous avez besoin? Ou essayez-vous de passer à travers le temps de crise avec le même nombre d'AQ que vous aviez tout au long? Même si les développeurs passent 20% de leur temps à tester et 80% à corriger les bugs qui se présentent, c'est toujours plus de regards sur l'application qu'auparavant. Les tests automatisés ne vous donnent qu'un certain niveau d'assurance et ils ne seront jamais à 100%.

http://haacked.com/archive/2010/12/20/not-really-interested-in-lean.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+haacked+%28you%27ve+been+HAACKED%29

Pour tout sauf les tests unitaires, absolument pas. Les développeurs en savent trop sur l'application et comment elle est "censée" fonctionner pour être des testeurs objectifs.

La différence fondamentale dans les tests de philosophies entre développeurs et Qs est la suivante: le programmeur teste généralement son programme pour prouver que son code fonctionne (test "positif"). L'assurance qualité peut le faire et le fait, mais a également pour objectif supplémentaire de découvrir ce qui ne fonctionne pas en essayant de casser le logiciel (en utilisant des tests "négatifs").

Dans la mesure où le personnel d'AQ pourrait être corrompu par les tests des programmeurs qui "prouvent" que le logiciel fonctionne, il devrait y avoir une isolation entre les tests du développeur et les tests d'AQ. Le développeur peut certainement aider les tests d'AQ en démontrant ce qui fonctionne, mais c'est à l'AQ de vérifier indépendamment que le logiciel ne casse pas .

La meilleure chose que le programmeur puisse faire pour aider à l'effort de test est de fournir une suite de tests unitaires complète, de haute qualité et vérifiable, contenant des tests qui s'alignent avec les exigences individuelles dans le document d'exigences.

Eh bien en termes de tests, il existe 3 types.

Boîte noire, boîte grise et boîte blanche.

La boîte noire fait référence aux utilisateurs testant le produit, sans savoir comment le produit fonctionne en interne.

La case grise fait référence aux utilisateurs expérimentés qui ont des connaissances en programmation informatique, mais ne font pas partie de l'équipe de développement. Ces personnes vérifieront si le produit présente des fuites de mémoire, un problème de configuration requise, etc.

Voici la partie principale: la boîte blanche fait référence aux développeurs testant le produit au niveau du code. Cela signifie qu'ils font des tests unitaires, du débogage, ... etc.

Par conséquent, il est bon que les utilisateurs et l'équipe de développement soient tous impliqués dans la phase de test, mais chacun des tests nécessite un niveau d'engagement approprié de la part des utilisateurs et de l'équipe de développement, en fonction de ce qui est testé.

UNIT TESTING est un must pour tous les développeurs

Pour plus d'informations sur la façon dont cela pourrait être utilisé à votre avantage, lisez les liens suivants si vous êtes dans le développement C ++:

• Une introduction rapide au framework de test Google C ++
• Outils de test unitaire C / C ++ open source, partie 1: Découvrez le cadre de test unitaire Boost
• Outils de test unitaire C / C ++ open source, Partie 3: Apprenez à connaître CppTest

IL N'Y A AUCUNE MANIÈRE QU'UNE PERSONNE QA PEUT FAIRE CES TESTS. EN AUCUNE FAÇON.

En supposant que le projet compte un nombre important de développeurs, alors, par tous les moyens, les développeurs travaillent sur les tests. Une mise en garde serait que les développeurs ne travaillent pas sur les tests (cela n'inclut pas les tests unitaires) pour leur propre code.

Je préfère voir le personnel administratif (ou les utilisateurs potentiels réels) faire les tests d'assurance qualité que les développeurs. Quelqu'un qui ne sait pas comment le produit a été conçu pour fonctionner doit essayer de l'utiliser. Les développeurs ont tendance à être très limités dans leur approche des tests et, franchement, ils sont trop chers à utiliser pour les tests d'AQ.

Vous écrivez:

Le problème est que, en raison de problèmes de ressources (*), les phases de test sont trop longues et sont souvent raccourcies en raison de contraintes de temps. C'est parce que les développeurs ne les font pas. L'une des plus grandes sociétés Internet fournissant les meilleurs produits les plus stables n'utilise pas du tout de testeurs. Ils n'utilisent que des tests automatiques, tous effectués par les développeurs eux-mêmes. Les résultats sont x10 meilleurs produits que lorsque le développeur laisse les tests aux "testeurs".

C'est comme avoir des travailleurs de la construction pour construire votre maison, mais avoir une équipe différente pour vous assurer que le bâtiment se tient réellement, les portes s'ouvrent et se ferment, la climatisation fonctionne, etc. Il faudra probablement x10 pour construire des bâtiments, et la plupart finiront étant peu fiable.