Les développeurs doivent-ils être responsables des tests autres que les tests unitaires, si oui, lesquels sont les plus courants?

Je travaille actuellement sur un projet assez volumineux et j’ai utilisé JUnit et EasyMock pour effectuer des tests unitaires assez nombreux. Je suis maintenant intéressé par quels autres types de tests je devrais m'inquiéter. En tant que développeur, dois-je m'inquiéter de choses telles que les tests fonctionnels ou de régression? Existe-t-il un bon moyen de les intégrer de manière utilisable dans des outils tels que Maven / Ant / Gradle? Sont-ils mieux adaptés pour un testeur ou un BA? Existe-t-il d'autres types de tests utiles qui me manquent?

Il est de votre responsabilité de vous efforcer de fournir un code sans défaut. Vous devez écrire, aider à rédiger ou vous assurer que les tests sont écrits ou effectués de manière à vous faire confiance dans le code que vous livrez.

Remarque: je ne dis pas que vous devez fournir un code sans défaut. Vous devriez plutôt essayer d’écrire le meilleur code possible pour les besoins qui vous ont été donnés. Une partie de cette capacité signifie que le code doit être testé.

Que cela signifie que vous soyez personnellement responsable des tests fonctionnels et des tests de régression dépend principalement de l'organisation de votre entreprise. Tous les programmeurs les plus qualifiés que je connaisse ne se demandent pas "est-ce ma responsabilité d'écrire des tests de type X?". Au lieu de cela, ils se demandent "que dois-je faire pour m'assurer que mon code est correctement testé?". La réponse pourrait être d'écrire des tests unitaires ou d'ajouter des tests à la régression, ou bien de parler à un professionnel de l'assurance qualité et de l'aider à comprendre quels tests doivent être écrits. Dans tous les cas, cependant, cela signifie qu'ils se soucient suffisamment du code qu'ils écrivent pour s'assurer qu'il est correctement testé.

En bout de ligne: vous devez être responsable de la livraison d'un code de haute qualité. Si cela signifie que vous devez écrire des tests fonctionnels ou de régression, faites-le.

Cela pourrait vous aider:

Q1 sont écrits par les développeurs.

Les questions Q2 sont automatisées par les développeurs et écrites en collaboration avec l'entreprise et / ou les testeurs.

Existe-t-il d'autres types de tests utiles qui me manquent?

Il existe des tests d'acceptation pour lesquels je recommanderais les frameworks de style BDD utilisant le langage Gherkin : JBehave (Java), Cucumber (Ruby), Behat (PHP), etc. Ce type de test présente certains avantages par rapport aux tests unitaires:

• Les tests sont facilement lisibles par les non-développeurs, vous pouvez donc les montrer aux clients.
• Les tests décrivent clairement les processus métier sans entrer dans les détails de l'implémentation (je ne veux pas dire que l'implémentation n'est pas importante, bien sûr, mais c'est mieux lorsque vous séparez les exigences métier du code lui-même).
• Les tests font ce que les utilisateurs vont faire avec votre application
• Ils sont plus faciles à écrire (à mon humble avis, peuvent dépendre de la langue et du framework): pas de moqueries, moins de détails techniques

Les tests fonctionnels peuvent être automatisés, tout comme les tests unitaires. Ils sont très utiles pour tester la manière dont les différents composants de votre projet fonctionnent ensemble et comment votre système reflète les règles de gestion.

Ce test automatisé sert également de suite de tests de régression et d'acceptation pour toute modification majeure (ou mineure) du logiciel (correction de bogue, refactor, modification de l'entreprise, nouvelle fonctionnalité, etc.). Cela donne aux développeurs beaucoup plus de confiance pour le faire.

Il existe plusieurs frameworks pour ce type de test, nous utilisons la fitnesse avec de très bons résultats. Possède une très bonne bibliothèque pour tester les pages Web (nous l’utilisons pour tester notre application Web et nos services Web) et s’intègre très bien avec Maven et Jenkins .

Nous avions aussi l'habitude de faire des "tests fonctionnels croisés", entre développeurs, mais ce type de test n'est pas "répétable", son utilité est donc limitée ...

En tant que développeur, je me considère comme responsable du test unitaire de tout mon code et je garantis au mieux de mes possibilités qu'il ne présente aucun défaut. C'est pourquoi nous avons tant d'outils à notre disposition, comme se moquer. Le but de la création d'objets moqueurs dans vos tests est précisément d'essayer d'isoler votre code du monde "extérieur" et de garantir qu'il fonctionne correctement et qu'en cas d'échec, "ce n'est pas votre faute".

Cela étant dit, même si ce n'est pas votre faute et que votre code fonctionne comme il se doit, cela ne signifie pas que vous ne pouvez pas aider pour le reste des tests. Je crois qu'il est également de votre responsabilité d'aider et d'intégrer votre travail sur le travail des autres. Les équipes de développement informatique doivent travailler à chaque fois comme une machine bien huilée, en collaboration avec d’autres départements (comme le contrôle de la qualité) en tant que plus grande équipe pour fournir un logiciel fiable.

Mais c’est le travail d’une équipe, pas seulement le vôtre.

Évidemment des tests d'intégration ; ils sont plus importants et plus difficiles à écrire que les tests unitaires. C'est comme construire une maison. avec les tests unitaires, vous vous assurez uniquement que les briques sont solides et résistent à la pression, à la température, à l'humidité et à d'autres conditions. Mais vous ne savez pas à quoi la maison ressemble et se comporte avec les briques assemblées.

Le problème avec les grands projets, en particulier les projets Java résidant dans un conteneur, est que les tests d'intégration sont difficiles. Ainsi, pour faciliter les tests d’intégration de systèmes dans les grands projets, il est nécessaire de disposer d’un framework de tests, spécialement conçu pour le projet, qui doit être codé par le développeur. Récemment, d'importantes améliorations ont été apportées dans ce domaine et des plates-formes comme Arquillian simplifient grandement la rédaction d'un cadre de test (ou même le remplace).

Dans le monde réel, vous n’êtes responsable que dans la mesure où votre équipe / votre patron vous tient pour responsable. Si vous êtes payé ou engagé à travailler sans relâche pour trouver tous les coins et recoins et sauter à la fantaisie de l'interprétation de votre patron (ou pire marketing) des bogues de la logique d'entreprise, alors, par tous les moyens, vous êtes responsable de tout.

Donc, en d'autres termes, faites ce qui est requis par la portée qui vous est donnée. C’est un bon plus que de faire preuve de bon sens ou de voir d’autres utiliser le produit que vous êtes en train de construire pour avoir une idée des cas d’utilisation et des problèmes éventuels à résoudre mais adressez-le à votre équipe ou à votre patron avant de le "réparer". Cela inclut les outils de votre choix. Tous vos efforts devraient être une chose à laquelle tout le monde participe.

Si votre question concerne le suivi des bogues, j'aime bugzilla, google docs, zendesk ou basecamp en termes de systèmes de communication.

Je ne pense pas que cela ait déjà été couvert - désolé si je l’ai raté.

Un problème est l'utilisation efficace du temps des développeurs.

Les développeurs n'ont souvent pas les compétences nécessaires pour être performant dans certains types de tests. C'est en partie naturel. C'est la même raison pour laquelle les auteurs ont des éditeurs. Il est très difficile de voir les lacunes de quelque chose si vous en êtes trop près. Mais il s'agit également de différents ensembles de compétences et de différentes spécialités.

Cela étant dit, les tests de temps passé par un développeur sont peu coûteux en termes de coûts: avantages. Ce développeur serait plus productif en faisant autre chose, et un testeur spécialiste serait plus productif en testant.

Bien sûr, cela implique diverses hypothèses qui ne sont pas nécessairement valables. Dans une petite entreprise, par exemple, il n’est peut-être pas judicieux d’embaucher des personnes spécialisées dans les tests. Il serait peut-être plus judicieux d'employer du personnel de soutien supplémentaire et de le faire tester, ou du moins de demander à des personnes de tester du code qu'elles n'ont pas écrit elles-mêmes.

Je crois qu'il est de notre responsabilité (en tant que développeur) d’englober tous les scénarios de test possibles avant sa publication pour l’assurance qualité. Le contrôle qualité a pour but de valider le logiciel. De plus, si vous corrigez les erreurs avec votre propre code, vous aurez toujours l’air beau au bon moment.

Qui mieux qu'un développeur pour savoir quels scénarios de test sont les plus pertinents. Le développeur doit être responsable de tous les tests unitaires. Dans la mesure du possible, il doit aider à écrire et à exécuter les scripts de test. Dans la mesure où cela est rarement possible dans les projets de grande envergure, le développeur doit disposer de suffisamment de temps pour examiner tous les cas de test. En outre, le développeur doit avoir des connaissances et utiliser le large éventail d’outils de test automatisés disponibles.

Dans ma carrière de développement, je constate que les projets aboutissent à de meilleurs résultats s’il ya une intégration étroite entre les équipes de développement et les équipes de test.

au moins un membre de chaque équipe doit également participer aux réunions de planification et de mise en œuvre.