Comment travailler comme un « ingénieur QA » sur un projet par opposition à un membre d'une « équipe Test Driven Development »?

Question

excuses Sincères si je pose cette question au mauvais endroit. (Peut-être l'un des mini-pile déborde spécifique à des conseils de carrière et QA) J'ai passé beaucoup de temps à apprendre récemment au sujet de la mise en œuvre et l'unité des cadres pour tester nos projets.

Avant la mise en place d'un cadre de tests unitaires, notre méthode consiste à coder, tester manuellement, commit, espérons que les choses ne se décomposent pas ou en amont. Un système très réactif.

Maintenant, nous comprenons tous que les choses doivent être testées et que les tests automatisés est efficace et bon. Cependant, le rôle semble actuellement être « vous faites le test » et « écriture des tests automatisés »

Faire le test manuel est possible, mais se sent écrasante (comme il y a des bugs tout le temps) et beaucoup comme une sous-utilisation de mes compétences.

Je vais avoir des difficultés dans l'accomplissement de la deuxième partie de la demande. si le code n'a pas été conçu pour être testables l'écriture de tests automatisés est difficile.

J'ai la responsabilité de QA - mais - je ne peux que trouver des ressources sur Test Driven Development.

Quelles méthodes puis-je utiliser pour devenir plus efficace dans mon rôle d'AQ où les autres développeurs ne sont pas encore en train d'écrire avec inquiétude à la création d'un code testable?

Answer 1

Je pense que les développeurs obtenir jusqu'à la vitesse avec les tests unitaires serait votre principale préoccupation! De cette façon, tout le monde est gagnant.

Jusqu'à ce moment-là, que vous êtes en effet travailler avec le code existant, le livre de Michael Feather Travailler efficacement avec Legacy code contient apparemment beaucoup de conseils utiles sur les tests de ce code.

Vous le savez probablement déjà, mais il faut vérifier aussi le comportement Driven Development (BDD), qui comprend beaucoup de choses sur la création de tests d'intégration automatisés, ce qui je pense serait de vous intéresser.

Answer 2

Le problème avec les noms développement piloté par les tests et tests unitaires , est qu'ils impliquent qu'ils sont sur le logiciel de test. Ils sont pas . TDD et tests unitaires sont sur conception et ils sont essentiellement la responsabilité des développeurs.

Le rôle de QA Analyst est toujours d'une importance capitale dans une équipe pratique TDD et ce sera un long, long temps avant de vous retrouver sur le travail en tant que QA consciencieux!

Jetez un oeil à Test d'acceptation développement axé sur et envisager de faire participer plus au stade des exigences en écrivant des tests d'acceptation automatique, en utilisant peut-être un outil tel que FitNesse .

Manuel, tests exploratoires a toujours sa place, bien sûr. Mais vous devriez envisager de répéter les tests de régression comme une violation de vos droits fondamentaux de l'homme!

Answer 3

Je pense que les développeurs devraient au moins des tests unitaires d'écriture (éventuellement en utilisant TDD). Ceci est la norme minimale de garantir que le code qu'ils vérifient dans travaille potentiellement.

Je comprends le rôle de l'AQ comme une personne fournissant des tests de niveau plus élevé, pour vous assurer que le logiciel répond aux exigences des clients, donc vous tester pas vraiment des cours individuels, mais des modules ou toute l'application. Même si les développeurs ne fournissent pas des tests unitaires, vous devriez toujours être en mesure d'automatiser les tests de bout en bout (ce qui inclut l'automatisation généralement la mise en place de l'environnement de test, etc.) - votre travail sera plus frustrant:)

Answer 4

Dans mon expérience, les gens ne se retourne pas pendant la nuit à écrire tests-- les convaincre est un processus. Les programmeurs finiront par essayer à contrecœur, mais il est encore des semaines ou des mois avant qu'ils ne soient avocats et praticiens réguliers. Cela ne signifie pas que vous devez abandonner, reconnaître simplement que c'est une bataille difficile, et a besoin de soutien d'en haut, et quelques bons défenseurs de l'intérieur de l'équipe.

Vous pouvez plonger dans l'écriture de tests vous:

Étant donné que la moitié environ des bogues sont « régressions » de bugs précédents, dans votre situation, je me concentrerais sur l'écriture des tests de régression pour les bugs critiques et nouveaux. Cela vous aidera beaucoup dans votre Q.A. normale le travail, mais aussi un excellent filet de sécurité pour les bugs futurs.

Même si vous ne pouvez pas convaincre les développeurs de tests d'écriture immédiatement, vous aurez des tests de valeur qu'ils vont bientôt voir la valeur. Ce travail peut aider à la vente de l'idée des développeurs d'écriture des tests unitaires.

Answer 5

Je travaille dans un rôle similaire il y a plusieurs années, donc je peux comprendre vos problèmes. Pour obtenir les développeurs à la vitesse avec les tests unitaires, je vous suggère de mentorat et des séances de programmation de paire. La rédaction du premier test unitaire pour une classe mal conçue peut être une vraie douleur. Il est plus facile et plus amusant s'il y a deux d'entre vous -. Sans parler de réduire le risque de faire des erreurs stupides dans les refactorisations initiales

Le livre de plumes, comme déjà mentionné par @Grant, est une ressource inestimable pour cela. Soyez patient et persévérer dans les premiers mois, avant que les résultats (à la fois dans la couverture des tests et dans l'esprit d'équipe) commencent à se montrer lentement.

Vous devez disposer d'un fort soutien de la gestion aussi bien - sans cela, il n'y a pas de point d'essayer. La direction doit comprendre que la construction de tests unitaires est un investissement , qui utilise une partie importante de votre temps et de l'énergie maintenant , et il ne rembourser dans les années à venir. S'ils insistent sur le maintien de la même pression limite que jamais, vous échouera inévitablement. Les développeurs ne peuvent pas apprendre et pratiquer de nouvelles compétences et des façons de penser si elles sont fortement sollicités et / ou démotivés.

(De l'autre côté de la médaille est bien sûr qu'il faut penser ou non l'investissement apportera des bénéfices. Tests unitaires de construction pour le code existant ne vaut que si les PREVOIT de gestion que le produit sera maintenu et utilisé pour de nombreuses années à venir.)