Qui écrit les tests de l'interface utilisateur automatisés? Les développeurs ou testeurs?

Question

Nous sommes dans les premières étapes d'un grand projet, et nous avons décidé qu'une certaine forme de tests d'interface automatisée va probablement être utile pour nous, mais n'a pas encore réglé exactement comment cela va fonctionner ...

Le principal objectif est d'automatiser une installation de base et la gestion par le biais de l'application, donc si un développeur provoque une rupture majeure (par exemple: l'application ne sera pas installé, le réseau ne se connecte pas, fenêtre ne affichage, etc.) les testeurs ne pas perdre leur temps (et se fâcher par) installation et la configuration d'une construction cassée

Un objectif secondaire est d'aider les testeurs lorsqu'ils traitent avec des tâches répétitives.

Ma question est: Qui devrait créer ce genre de tests? L'hypothèse implicite dans notre équipe a été que les testeurs vont le faire, mais tout ce que j'ai lu sur le net semble toujours impliquer que les développeurs les créer, comme une sorte de « test unitaire étendue ».

Quelques réflexions:

• Les développeurs semblent être dans une bien meilleure position pour ce faire, étant donné qu'ils savent le contrôle de, des cours ID, etc, et ont une bien meilleure image de la façon dont l'application fonctionne

• Les testeurs ont l'avantage de ne pas savoir comment l'application fonctionne, et peut donc produire des tests qui peuvent être beaucoup plus utile

• J'ai écrit quelques scripts initiaux en utilisant IronRuby et blanc. Cela a fonctionné très bien, et il est assez puissant pour faire quoi que ce soit littéralement, mais vous devez être en mesure d'écrire du code pour écrire les tests de l'interface utilisateur

• Tous les outils de test de l'interface utilisateur automatisés que nous avons essayé (TestComplete, etc) semblent être incroyablement complexe et fragile, et alors que les testeurs peuvent les utiliser, il leur faut environ 100 fois plus et ils sont constamment en cours d'exécution dans la "complexité accidentelle" provoquée par les outils de test de l'interface utilisateur.

• Nos testeurs code ne peut pas, et pendant qu'ils sont beaucoup intelligents, tout ce que je suis arrivé était un drôle d'air quand je suggère que les testeurs pourraient écrire des scripts simples rubis (même si les scripts sont dit au sujet 100x plus facile à lire et à écrire que le désordre mutilée des boutons et datagrids qui semble être la norme pour les outils de test de l'interface utilisateur automatique).

J'apprécierais vraiment tous les commentaires des autres qui ont essayé l'automatisation de l'interface utilisateur dans une équipe de développeurs et testeurs. Qui a fait quoi, et at-il bien? Merci d'avance!

Modifier L'application en question est une application C # WPF "client riche" qui se connecte à un serveur en utilisant WCF

Answer 1

Idéalement, il devrait vraiment être QA qui finissent par écrire les tests. Le problème avec l'aide d'une solution de programmation est la courbe d'apprentissage à obtenir les gens d'assurance qualité à la vitesse avec l'aide de l'outil. Les développeurs peuvent certainement aider à cette courbe d'apprentissage et d'aider le processus par le mentorat, mais il faut encore du temps et est un frein sur le développement.

L'alternative est d'utiliser un simple outil graphique qui soutient une langue (et les scripts de données) et permet QA de créer des scripts visuellement, se plonger dans les détails les plus fins de la langue que si vraiment nécessaire - le développement peut aussi s'impliquer ici aussi.

Les tentatives les plus réussies que je l'ai vu ont certainement été avec ce dernier, mais cette mise en place est la partie difficile. Sélénium a bien fonctionné pour de simples applications Web et les fils simples grâce à l'application. JMeter aussi (pour les conversations web scriptées pour les services Web) a bien fonctionné ... Une autre option qui est celle dans le faisceau de test intégré maison - un outil simple sur le dessus d'un langage de script (Groovy, Python, Ruby) qui permet d'AQ de mettre les données de test dans l'application soit via une interface graphique ou via des fichiers de données. Les fichiers de données peuvent être des fichiers de propriétés simples, ou dans des cas plus complexes structurés (quelque chose comme YAML ou même Excel) des fichiers de données. De cette façon, ils peuvent construire les tests de fumée de base pour commencer, et ensuite étendre ce dans divers tests axés sur le scénario.

Enfin ... Je pense que riches applications clientes sont beaucoup plus difficiles à tester de cette façon, mais cela dépend de la nature de la langue et les outils disponibles pour vous ...

Answer 2

Dans mon expérience, les testeurs qui peuvent code changer d'emploi pour une augmentation de salaire en tant que développeurs.

Je suis d'accord avec vous sur les outils de tests automatisés de l'interface utilisateur. Chaque endroit que j'ai travaillé qui était assez riche pour se permettre WinRunner ou LoadRunner ne pouvait pas se permettre le personnel à utiliser réellement. Les prix ont changé, mais à l'époque, ceux-ci étaient dans le 5 chiffres élevé pour les étiquettes à bas prix à 6 chiffres (penser au prix d'une maison de démarrage). Les produits étaient difficiles à utiliser, et étaient généralement maintenus désinstallés dans une armoire fermée à clé car tout le monde avait peur d'avoir des problèmes pour les briser.

Answer 3

J'ai travaillé plus de 7 ans en tant que développeur d'application avant de finalement passé à l'essai et l'automatisation des tests. Le test est beaucoup plus difficile que le codage, et tout développeur d'automatisation qui veut réussir doit maîtriser les compétences de test.

Il y a quelque temps que je mets mes pensées sur des matrices de compétences dans deux messages de blog.

Si vous êtes intéressé à discuter:

http://automation-beyond.com/ 2009/05/28 / qa-automatisation de compétences matrices /

Merci.

Answer 4

Je pense avoir les développeurs écrivent les tests seront des plus utilisation. De cette façon, vous pouvez obtenir « vérifier la casse » tout au long de votre cycle de dev, et pas seulement à la fin. Si vous ne nuit automatisé construit, vous pouvez attraper et corriger les bugs quand ils sont petits, avant qu'ils ne se transforment en énormes moyens, les insectes mangeurs d'hommes.

Answer 5

Et les testeurs proposant les tests et les développeurs qui écrivent réellement?

Answer 6

Je crois tout d'abord cela dépend en grande partie des outils que vous utilisez.

Notre entreprise utilise actuellement Sélénium (Nous sommes un magasin de Java).

L'IDE Sélénium (qui enregistre les actions dans Firefox) fonctionne bien, mais les développeurs ont besoin de corriger les erreurs manuellement fait contre nos webapps, il est donc pas vraiment approprié pour l'AQ pour écrire des tests avec.

Une chose que j'ai essayé dans le passé (avec un certain succès), était d'écrire des fonctions bibliothèque encapsulent les fonctions Selenium. Ils lisent comme anglais simple:

selenium.clickButton("Button Text")

... mais dans les coulisses pour vérifier la mise en page correcte et les balises sur le bouton, a un identifiant etc.

Malheureusement, cela a exigé beaucoup de mis en place pour permettre l'écriture facile des tests.

J'ai récemment pris conscience d'un outil appelé Twist (de Thoughtworks, construit sur le moteur Eclipse), qui est un wrapper pour sélénium, ce qui permet des tests de style anglais simple à écrire. J'espère être en mesure de fournir ce aux testeurs, qui peuvent écrire des affirmations simples en anglais simple!

Il crée automatiquement des talons de nouvelles affirmations aussi, de sorte que les testeurs puissent passer les tests, et de les transmettre aux développeurs s'ils ont besoin nouveau code.

Answer 7

Je l'ai trouvé l'option la plus raisonnable est d'avoir suffisamment de spécifications telles que les gens d'assurance qualité peuvent bouchonner le test, comprendre essentiellement ce qu'ils veulent tester à chaque « écran » ou sur chaque composant, et le talon ceux sur. Les talons doivent être nommés de telle sorte qu'ils sont très descriptif à ce qu'ils testent. Cela offre également un moyen de besoins fonctionnels cristallisent. En fait, faire les exigences de cette façon sont particulièrement faciles, et aider les gens non techniques travaillent vraiment dans les eaux boueuses de leur propre processus quoique.

Les talons peut être rempli via une combinaison de personnes QA / dev. Cela vous permet de former CHER personnes QA quant à la façon d'écrire des tests, et ils slurp généralement vers le haut comme il favorise leur sécurité d'emploi.

Answer 8

Je pense que cela dépend surtout du niveau de compétence de votre équipe de test, les outils et la culture de l'équipe en ce qui concerne la façon dont les développeurs et les testeurs interagissent les uns avec les autres. Ma situation actuelle est que nous avons une équipe de test relativement technique. Tous les testeurs sont censés avoir des compétences en développement. Dans notre cas, les testeurs écrivent UI Automation. Si votre équipe de test n'a pas les compétences dont ils ne seront pas mis en place pour le succès. Dans ce cas, il peut être préférable pour les développeurs de vous écrire UI Automation.

D'autres facteurs à considérer:

Quels sont les autres tâches de test sont sur la plaque signalétique des testeurs? Qui sont vos clients et quelles sont leurs attentes en matière de qualité? Quel est le niveau de compétence de l'équipe de développement et quelle est leur volonté de prendre sur le test travail d'automatisation?

-Ron