Nous sommes dans les premières étapes d'un vaste projet et j'ai décidé que certaines formes de tests automatisés de l'interface utilisateur seront probablement utiles pour nous, mais n'ont pas encore trié exactement comment cela va travailler ...
L'objectif principal est d'automatiser une installation et une exécution de base de l'application, de sorte qu'un développeur provoque une rupture majeure (par exemple: l'application ne s'installera pas, le réseau ne se connecte pas, la fenêtre ne se connectera pas. Affichage, etc.) Les testeurs n'ont pas à perdre leur temps (et d'être ennuyés par) Installation et configuration d'une version cassée
Un objectif secondaire est d'aider les testeurs lors de la gestion des tâches répétitives.
Ma question est la suivante: qui devrait créer ce genre de tests? L'hypothèse implicite de notre équipe a été que les testeurs le feront, mais tout ce que j'ai lu sur le net semble toujours impliquer que les développeurs les créeront, comme une sorte de «test d'unité étendue».
Certaines pensées:
Les développeurs semblent être dans une bien meilleure position pour le faire, étant donné qu'ils connaissent les identifiants de contrôle, les classes, etc. et avoir une bien meilleure idée de la manière 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 utiles
J'ai écrit des scripts initiaux en utilisant ironRuby et blanc . Cela a vraiment bien fonctionné et est suffisamment puissant pour faire littéralement n'importe quoi, mais vous devez ensuite être capable d'écrire du code pour écrire les tests d'interface utilisateur
Tous les outils de test d'interface utilisateur automatisés que nous avons essayés (testcomplete, etc.) semblent être incroyablement complexes et fragiles, et pendant que les testeurs peuvent les utiliser, il les prend environ 100 fois plus longtemps et ils sont constamment Concentant une "complexité accidentelle" causée par les outils de test d'interface utilisateur.
Nos testeurs ne peuvent pas coder, et pendant qu'ils sont beaucoup intelligents, tout ce que j'ai eu était drôle des regards lorsque j'ai suggéré que les testeurs puissent potentiellement écrire des scripts de rubis simples (même si lesdits scripts sont environ 100 fois plus faciles à lire et écrire que le désordre mutilé des boutons et des datagrids qui semblent être la norme pour les outils de test d'interface utilisateur automatisés).
J'apprécierais vraiment les commentaires des autres qui ont essayé une automatisation de l'interface utilisateur dans une équipe de développeurs et de testeurs. Qui a fait quoi, et a-t-il bien fonctionné? Merci d'avance!
edit: L'application en question est une application C # WPF "Client Rich" qui se connecte à un serveur à l'aide de WCF
8 Réponses :
Dans mon expérience, les testeurs qui peuvent coder vont changer d'emploi pour une augmentation de salaire en tant que développeurs.
Je suis d'accord avec vous sur les outils de test automatisés de l'interface utilisateur. Chaque endroit où j'ai travaillé était assez riche pour vous permettre à WinRunner ou LoadRunner ne pouvait pas vous permettre de l'utiliser réellement. Les prix ont peut-être changé, mais à l'époque, ils se trouvaient à 5 chiffres à 5 chiffres à 5 chiffres à 6 chiffres (pensez au prix d'une maison de démarrage). Les produits étaient difficiles à utiliser et étaient généralement tenus non désinstallés dans une armoire verrouillée parce que tout le monde avait peur d'avoir des ennuis pour les briser.
LoadRunner est pour les tests de performance et est effectivement difficile à maîtriser. Le problème n'est pas avec C Il utilise mais avec des corrélations et analysant le trafic réseau. Quant aux tests automatisés GUI, QTP est beaucoup meilleur choix. Il permet de créer un test via un enregistrement et une lecture, mais également pour script le même test dans VBScript. Toujours le prix peut être question.
J'ai trouvé l'option la plus raisonnable consiste à avoir suffisamment de spécifications telles que les personnes QA peuvent éteindre le test, à déterminer essentiellement à déterminer ce qu'ils veulent tester à chaque «écran» ou sur chaque composant, et s'effondrent. Les talons doivent être nommés de telle sorte qu'ils soient très descriptifs quant à ce qu'ils testent. Cela offre également un moyen de cristaliser les exigences fonctionnelles. En fait, faire les exigences de cette manière sont particulièrement faciles et aider les personnes non techniques à travailler vraiment à travers les eaux boueuses de leur propre processus.
Les talons peuvent être remplis via une combinaison de QA / Dev personnes. Cela vous permet de faire appel à des personnes d'assurance qualité à moindre coût pour savoir comment écrire des tests, et ils ont généralement progressivement augmenté en favorisant leur sécurité d'emploi.
Comment le folk-folk a-t-il échappé au test? N'écriraient-ils un fichier de code réel plein de tests? ou vous remettez un document Word plein d'exigences? Je suppose que les développeurs rempliraient alors les talons avec le code d'assurance-emploi réel?
Le QA fonctionne réellement des talons de fonction, ou quoi que ce soit, peut-être. Les noms doivent servir de documentation agile. Vous devriez être capable d'analyser cela et d'exécuter une simple scission sur un boîtier de chameau pour obtenir des phrases approximatives de garnir chaque exigence.
Je pense que les développeurs écrivent les tests seront les plus utilisés. De cette façon, vous pouvez obtenir une "vérification des bris" tout au long de votre cycle de développement, pas seulement à la fin. Si vous faites des constructions automatisées nocturales, vous pouvez attraper et résoudre des bugs quand ils sont petits, avant de devenir des bugs énormes, méchants manuels.
Idéalement, il devrait vraiment être QA qui finissent par écrire les tests. Le problème avec l'utilisation d'une solution programmatique est la courbe d'apprentissage impliquée dans l'obtention des personnes QA à la hauteur de l'utilisation de l'outil. Les développeurs peuvent certainement aider à cette courbe d'apprentissage et aident le processus en mentorant, mais cela prend toujours du temps et est une traînée sur le développement.
L'alternative consiste à utiliser un outil d'interface graphique simple qui recule d'une langue (et de scripts de données) et permet à QA de construire des scripts visuellement, de s'introduire dans les détails plus fins de la langue uniquement lorsqu'il est vraiment nécessaire - le développement peut également être impliqué ici également.
Les tentatives les plus réussies que j'ai vues ont certainement été avec ce dernier, mais la configuration est la partie difficile. Le sélénium a bien fonctionné pour des applications Web simples et des fils simples à travers l'application. JMeter également (pour les conversations Web scriptées pour services Web) a bien fonctionné ... Une autre option qui est celle de Harness de test bâti à la maison - un outil simple sur le dessus d'une langue de script (Groovy, Python, Ruby) qui permet à QA de Mettez les données de test dans l'application 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 des fichiers de données YAML ou même Excel). De cette façon, ils peuvent créer les tests de fumée de base pour démarrer et développer ultérieurement que dans divers tests pilotés par scénario.
Enfin ... Je pense que les applications des clients riches sont bien plus difficiles à tester de cette manière, mais cela dépend de la nature de la langue et des outils à votre disposition ...
Nous avons décidé d'aller avec la possibilité d'obtenir le peuple QA d'écrire des scripts de base 'talon' (en utilisant ironRuby, qui est très facile à lire et à écrire), puis à faire la réalisation du code et à la mise en œuvre des pièces que le QA Les gens n'étaient pas capables de faire. J'espère que ça ira bien
Peut-être au lieu de sélénium comme des applications, vous devriez essayer des produits comme IBM Tester fonctionnel, HP QuickTestPro, Borland Silktest ou MSVS Test Edition. Quant aux applications Web, il existe également des bibliothèques dédiées telles que Webaii ou Watin qui aident à écrire des scripts. Quoi qu'il en soit, rendez votre QA Les gens apprennent et adoptent. À peu près au développeur - Besoin d'apprendre quelque chose de nouveau tous les jours.
Qu'en est-il des testeurs proposant les tests et les développeurs l'écrivent réellement?
En général, Devs est trop occupé à écrire le code que QA testera et n'aura pas de temps pour écrire les tests. Je ne connais pas votre entreprise, mais à tous ceux que j'ai travaillé, si un Dev a le temps de rédiger des tests, les gestionnaires (MIS) critiquent le Dev, car le développement aurait dû ajouter davantage de fonctionnalités.
L'application «Twist» de la pensée »semble modélisée le long de ce genre de chose
Je crois au début, cela dépend en premier lieu des outils que vous utilisez.
Notre société utilise actuellement selenium (nous 'Re un magasin Java).
L'IDE SELENIUM (qui enregistre des actions dans Firefox) fonctionne correctement, mais les développeurs doivent corriger manuellement les erreurs qu'il fait contre nos webapps, il n'est donc pas vraiment approprié pour la QA d'écrire des tests Avec.
Une chose que j'ai essayée dans le passé (avec un certain succès), était d'écrire des fonctions de bibliothèque comme des wrappers pour les fonctions de sélénium. Ils ont lu comme un simple anglais: ... Mais derrière les scènes, vérifiez la mise en page et les balises appropriées sur le bouton, a un identifiant, etc. Malheureusement, cela nécessitait beaucoup de configuration pour permettre une écriture facile des tests. J'ai récemment pris conscience d'un outil appelé Twist (de Pitchlessworks, construit sur le moteur Eclipse), qui est une enveloppe pour sélénium, permettant d'écrire des tests de style anglais clair. J'espère pouvoir fournir ceci aux testeurs, qui peut écrire des affirmations simples en anglais clair! Il crée automatiquement des talons pour de nouvelles assertions également, afin que les testeurs puissent écrire les tests et les transmettre à développeurs s'ils ont besoin de nouveau code.
C'est fondamentalement ce que j'ai fait avec mes scripts rubis (résumant sur le cadre blanc). J'ai un code comme "ok_button = window.find_button (" ok "); ok_button.click"
J'ai travaillé plus de 7 ans en tant que développeur d'applications avant de passer finalement à tester et à tester l'automatisation. Le test est beaucoup plus difficile que le codage, et tout développeur d'automatisation qui souhaite réussir devrait maîtriser les compétences de test.
Il y a quelque temps, je mets mes pensées sur des matrices de compétences dans quelques poteaux de blog.
Si vous êtes intéressé à discuter:
http://automation-beyond.com/ 2009/05/28 / QA-Automation-Skills-Matrices /
merci.
Oh, et pour l'installation d'installation et de gestion de base, sans tests fonctionnels réels, vous n'avez pas vraiment besoin de QTP ou de testComplete. Essayez autoit (c'est gratuit).
Je suis très sceptique à un salaire QA correspondant à un bon salaire de Développeur, alors il s'agit d'une QA de Dev semble être une chose étrange à faire, de carrière. Dire Test est beaucoup plus difficile que le codage est une opinion même. Je fais les deux et préférons coder plus
Je pense que cela dépend principalement du niveau de compétence de votre équipe de test, des outils disponibles et de la culture de l'équipe en ce qui concerne la manière 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 devraient avoir des compétences en développement. Dans notre cas, les testeurs écrivent une automatisation de l'UI. Si votre équipe de test n'a pas ces compétences, ils ne seront pas mis en place pour réussir. Dans ce cas, il peut être préférable que les développeurs vous écrivent de l'automatisation de l'interface utilisateur.
D'autres facteurs à considérer:
Quelles autres tâches de test sont sur la plaque des testeurs? Qui sont vos clients et quelles sont leurs attentes liées à la qualité? Quel est le niveau de compétence de l'équipe de développement et quelle est leur volonté de prendre des travaux d'automatisation des tests?
-ron