Le test unitaire est-il en cours de développement ou de test?

J'ai eu une discussion avec un responsable des tests sur le rôle des tests unitaires et d'intégration. Elle a demandé aux développeurs de signaler ce qu'ils ont testé et comment l'unité a été testée. Mon point de vue est que les tests unitaires et d'intégration font partie du processus de développement, pas du processus de test. Au-delà de la sémantique, je veux dire que les tests unitaires et d'intégration ne devraient pas être inclus dans les rapports de test et que les testeurs de systèmes ne devraient pas s'en préoccuper. Mon raisonnement repose sur deux choses.

1. Les tests unitaires et d'intégration sont planifiés et réalisés contre une interface et un contrat, toujours. Que vous utilisiez ou non des contrats formalisés, vous testez toujours ce que, par exemple, une méthode est censée faire, c'est-à-dire un contrat.

   Lors des tests d'intégration, vous testez l'interface entre deux modules distincts. L'interface et le contrat déterminent quand le test réussit. Mais vous testez toujours une partie limitée de l'ensemble du système. En revanche, les tests des systèmes sont planifiés et exécutés en fonction des spécifications du système. La spécification détermine quand le test réussit.

2. Je ne vois aucune valeur à communiquer l'ampleur et la profondeur des tests unitaires et d'intégration au testeur (systèmes). Supposons que j'écrive un rapport qui répertorie les types de tests unitaires qui sont effectués sur une classe de couche métier particulière. Que doit-il retirer de cela?

   Juger de ce qui devrait et ne devrait pas être testé à partir de cela est une fausse conclusion car le système peut toujours ne pas fonctionner comme l'exigent les spécifications, même si tous les tests unitaires et d'intégration réussissent.

Cela peut sembler une discussion académique inutile, mais si vous travaillez dans un environnement strictement formel comme moi, c'est en fait important pour déterminer comment nous faisons les choses. Quoi qu'il en soit, je me trompe totalement?

La rédaction de tests automatisés est le travail d'un développeur; les tests font partie de la base de code et doivent être traités comme tels - ils doivent être soumis aux mêmes révisions de code, normes de codage, discipline de contrôle des sources, etc., que le reste du projet.

L'exécution desdits tests se fait pour deux raisons: Premièrement, comme outil pour guider les développeurs. Vous exécutez des tests pour vérifier que le code que vous venez d'écrire fait ce qu'il est censé faire, vous les utilisez comme documentation supplémentaire et pour vérifier que les modifications ne rompent aucune fonctionnalité existante. Si vous faites du vrai TDD, les tests sont également une source de spécifications techniques faisant autorité. La deuxième raison d'utiliser les tests est lors de l'AQ et du déploiement. L'exécution de tous les tests automatisés devrait être l'une des premières étapes de chaque cycle de tests; exécuter des tests automatisés est bon marché (pratiquement aucune main-d'œuvre requise) et il n'est pas très logique de passer à des tests manuels si les tests automatisés échouent.

Cela signifie que les responsabilités devraient être les suivantes:

• Les développeurs écrivent des tests automatisés
• Les développeurs exécutent des tests automatisés individuels selon les besoins, dans le cadre de leur flux de travail de développement
• L'AQ exécute tous les tests automatisés comme l'une des premières étapes des tests

Si vous avez un serveur de build, la tâche de QA (concernant les tests automatisés) se résume à "ouvrir le rapport du serveur de build et vérifier que tout est vert".

Je pense que le plus important pour vous serait de clarifier pourquoi elle a besoin de ce rapport.

Il peut y avoir différentes explications (comme le suggèrent plusieurs réponses), qui nécessitent des stratégies très différentes.

• si elle est une personne raisonnable, souhaitant simplement obtenir des informations pour aider le travail de son équipe de test, il est logique de parvenir à une compréhension commune et de trouver une solution qui conviendrait à vous deux. Vous pouvez discuter avec elle de la nature des tests unitaires et de la différence fondamentale entre les tests unitaires vs fonctionnels / système / d'acceptation. J'espère que vous pourrez lui faire comprendre que ces travaux se déroulent à des niveaux très différents et qu'aucun ne peut remplacer l'autre.
• si elle est une folle de contrôle ou une bureaucrate, exigeant un rapport juste pour le plaisir, vous pouvez générer quelque chose pour satisfaire ses caprices avec le moins d'effort (par exemple, ce que @Doc a suggéré :-).
• si elle est dans un jeu de pouvoir, vous pouvez vous demander si elle a le droit d'exiger des rapports des développeurs. D'après mon expérience, les développeurs ne sont généralement pas censés faire rapport au département QA.

Je pense que le rôle de l'AQ et du développement, ainsi que l'interaction, peuvent varier considérablement d'une organisation à l'autre. Mais en général, dans mon équipe, je dis aux membres qui se joignent de faire comme s'il n'y avait pas d'équipe QA, dans le sens où ils sont responsables des changements qu'ils mettent en production. À son tour, notre équipe d'assurance qualité n'assume pas grand-chose aux tests des développeurs et effectue une bonne partie des tests du système dans son ensemble.

Pour cette raison, notre équipe d'assurance qualité ne se soucie pas vraiment de ce qui est et n'est pas testé unitaire avant de commencer le test.

Je pense qu'il est utile pour l'équipe d'AQ de comprendre ce que les tests unitaires font et ne couvrent pas, à un niveau élevé, afin que nous puissions travailler collectivement pour identifier les lacunes et les domaines qui pourraient avoir besoin de plus de rigueur. Donc, peut-être que votre collègue recherche un résumé de haut niveau, par opposition aux détails sanglants.

Elle a insisté pour que les développeurs signalent ce qu'ils ont testé et comment l'unité.

Essaie-t-elle vraiment de se demander si ce type de test relève réellement du domaine du «développement», ou essaie-t-elle simplement de déterminer dans quelle mesure votre code est couvert par des tests unitaires? En regardant les informations que vous avez fournies, il semble qu'elle veuille simplement savoir quelles parties du code sont couvertes et où elle devrait concentrer les efforts de son équipe.

J'ai travaillé sur une équipe de test dès la sortie de l'école avant de me lancer dans un rôle de développement, et je peux voir comment cela pourrait être utile pour elle et son équipe.

Je ne vois pas que cela compte trop.

Si vous ne les fournissez pas à QA / Testing, et qu'ils ne font pas les tests appropriés, et que cela échoue en production, c'est leur faute de le laisser passer par QA en production sans vérifier qu'il fonctionne comme spécifié.

Si vous les fournissez à QA / Testing, et qu'ils ne font pas de tests appropriés ... même résultat que si vous ne les aviez pas fournis.

Cependant, si vous les fournissez, ils pourraient également les comparer à la spécification et / ou suggérer quels tests pourraient être défectueux, ou doivent être modifiés car ils ont trouvé un bogue.

Vraiment, je ne vois pas beaucoup d'inconvénients à les fournir. C'est toujours sur QA / testing pour valider par rapport à la spécification. S'ils prennent la voie paresseuse et se contentent de croire que vos tests sont assez bons parce qu'ils ont tous réussi, ce sont eux qui ont échoué dans leur travail. Tant qu'ils ont toujours les spécifications, les résultats des tests unitaires / d'intégration ne sont que des peluches et ne devraient pas vous blesser d'une manière ou d'une autre. C'est la raison pour laquelle nous avons dev et QA. Plusieurs vérifications que l'application effectue comme spécifié.

Les développeurs font des erreurs, l'AQ fait des erreurs, idéalement, ils ne font pas tous les deux une erreur sur le même élément ... et s'ils le font ... c'est potentiellement un analyste qui a laissé tomber la balle en écrivant une spécification peu claire.

Les tests unitaires sont la responsabilité des développeurs que les tests peuvent être utiles pour comprendre comment les morceaux de code fonctionnent par eux-mêmes. Certains peuvent voir cela comme une forme de documentation et ont donc une certaine valeur bien qu'il puisse y avoir des frais généraux si les tests unitaires sont modifiés régulièrement.

L'autre valeur de la réussite des tests est que cela peut éviter de doubler les tests qui peuvent être redondants en termes de garantie des fonctionnalités de base.

Il existe également des tests d'acceptation par l'utilisateur qui sont distincts de tout cela, car l'utilisateur final peut avoir sa propre compréhension du fonctionnement d'un système.

Si votre entreprise a une méthodologie définie pour garantir la qualité de ses produits (s'ils sont conformes SOX, ou essaient d'améliorer leur niveau CMMI, ils le font probablement), alors les produits doivent pouvoir résister à l'audit pour montrer que le processus était suivi.

Souvent, le processus défini comprend des tests unitaires (ce qui est une bonne chose). Malheureusement, cela signifie également que vous devez documenter vos tests unitaires et prouver qu'ils ont été exécutés afin de résister à l'audit. Cela signifie donc que vous avez besoin d'un moyen de rendre compte de vos tests unitaires.

Examinez un outil comme Sonar pour vous aider - il indiquera le niveau de couverture du code et les résultats de vos tests unitaires.

Cela dépend vraiment de l'entreprise, mais d'après mon expérience ayant travaillé à la fois en tant que testeur de système dans une approche traditionnelle mais également en tant que testeur travaillant dans une équipe agile dans un modèle de CD, savoir ce qui a été testé à l'unité et à l'intégration est extrêmement utile.

La qualité est la responsabilité de l'équipe - les développeurs, les testeurs et la gestion des produits et travailler ensemble est le meilleur moyen de garantir cela.

Le gestionnaire de test veut donc savoir ce qui a été testé à l'unité et l'intégration et c'est un peu plus de travail supplémentaire pour les développeurs, mais cela économise le travail global pour le projet! En donnant les informations au responsable du test, il peut concentrer les efforts de son équipe de test sur ce qui est critique et important. Comme mentionné précédemment, si un domaine de code n'est pas testé unitaire, l'équipe peut y concentrer ses efforts par rapport à un domaine qui est fortement testé - pourquoi dupliquer l'effort? Vous travaillez tous vers le même objectif ultime: des logiciels de meilleure qualité publiés à temps.

Je pense qu'il serait avantageux de fournir ce genre de chose. La couverture des tests unitaires doit être connue par le développement et les tests afin qu'ils puissent en tenir compte.

De toute évidence, vous devez tester les éléments essentiels à l'entreprise, quoi qu'il arrive. Vous devez tester durement la fonctionnalité couramment utilisée, qu'elle ait ou non une grande couverture de test unitaire. Cela ne pouvait pas faire de mal de leur faire savoir quels autres endroits sont couverts par les tests unitaires. Le code vérifie-t-il déjà les cas marginaux dans ce petit contrôle? Ce genre de choses est utile à connaître de tous les côtés de l'entreprise.

Il convient de mentionner l'approche discutée dans le livre "Comment Google teste les logiciels": les tests et le contrôle de la qualité sont la responsabilité de tous, et les normes sont rigoureuses.

Le véritable rôle de ce que l'on appelle traditionnellement le département "Testing" est en fait la productivité des développeurs; c'est-à-dire l'automatisation pour permettre à l'organisation d'atteindre le niveau de rigueur économique requis.