Bem, o título realmente diz tudo, mas para elaborar um pouco, você pode pegar um departamento de controle de qualidade aleatório e geralmente eficaz e aprender a trabalhar em um ambiente XP (com uma curva de aprendizado para acompanhar o fluxo de trabalho do XP) ou eles precisariam de mais habilidades de programação para serem eficazes? Se sim, o que eles precisariam saber?
Respostas:
Controle de qualidade da equipe de conversão para XP?
Essa pergunta é uma da qual muitos testadores tradicionais dependem para a sobrevivência na carreira.
Resposta curta é talvez. Você está certo em identificar o fluxo de trabalho como um problema, mas o fluxo de trabalho é simples em comparação com o treinamento para programação e desenvolvimento. Transformar testadores em programadores pode ser uma ponte longe demais. Existem muitas outras habilidades que têm maior afinidade com o conjunto de habilidades atual dos testadores.
Eu acho que há um papel para os Engenheiros de Teste de Software, mas duas novas criaturas estão em cena, o Desenvolvedor Orientado a Testes e o Engenheiro de Desenvolvimento de Software em Teste, que assumirão grande parte do território que costumava pertencer ao STE.
Fluxo de trabalho XP
Sob um fluxo de trabalho XP, o teste de unidade é de responsabilidade do desenvolvedor. Normalmente, o fluxo de trabalho envolve a criação do cartão de história, a elaboração de um diagrama de casos de uso e alguns casos de uso e a transformá-los em casos de teste. Os casos de teste direcionariam o desenvolvimento em uma metodologia chamada Test Driven Development (TDD). A cada minuto que o programa existe, há um caso de teste a ser implementado primeiro, seguido por algum código que inicialmente falhará e, após trabalho adicional, passe no teste. Quando todos os testes identificados nos cartões de história passam, o produto está pronto. Ou pelo menos o último incremento é feito. Os testes de unidade são criados de maneira dependente do idioma e fazem parte do código. Existem muitas referências, mas, para uma introdução rápida, verifique a Wikipedia e, em seguida, a seguinte página de Scott Ambler.
http://www.agiledata.org/essays/tdd.html#WhatIsTDD
Também há sobreposição significativa com o teste de aceitação do sistema, porque os casos de teste são provenientes de fichas e casos de uso. ATDD (Acceptance TDD) faz uma distinção, mas acho que pode ser meio arbitrário.
Nem todo mundo faz testes com a mesma seriedade. Os gerentes podem pressionar os desenvolvedores a não testar. Eles podem pressionar para que os testadores não testem também. Fui enganado um ano quando os desenvolvedores da minha equipe estavam com o orçamento apertado, mas os testadores do projeto testaram correções de bugs e novos recursos várias horas por semana, embora o plano do projeto os fizesse funcionar apenas duas semanas no final. Parecia a coisa certa a fazer, e o projeto ainda era lucrativo e os clientes tinham um produto melhor por causa disso.
Os desenvolvedores devem testar. É um desperdício quando não o fazem, porque os testadores precisam executar, relatar e repetir. A qualidade do software não é menos responsabilidade dos desenvolvedores do que os testadores. Esse compartilhamento deve tornar a vida do testador menos frustrante, mas também amplia a demanda por muito conhecimento e habilidade para todos.
Se os desenvolvedores falharem em levar a sério os testes, as demandas dos testadores poderão aumentar, pois você terá compilações diárias. Por um tempo, as pessoas podem ser ouvidas dizer: "Por que parece que damos um passo à frente e dois passos para trás"? A resposta será que agora você está usando um sistema em que a equipe tem visibilidade como nunca teve antes e era apenas na marca de 90% que essas pessoas sabiam sobre o desastre iminente.
A mudança de teste para desenvolvedores
Minha experiência é que, para acelerar o desenvolvimento, isso pode ajudar a transferir os trabalhos realizados pelos testadores para o desenvolvimento. Isso se aplica a tudo, desde o teste da interface do usuário de uma tela sensível ao toque, até o teste do Windows Hardware Quality Lab de itens muito complexos, como um driver do Windows para WiFi.
Considere os dias anteriores ao PC, quando os engenheiros ditavam memorandos e informações técnicas a uma secretária para serem digitados, duplicados e distribuídos. Compare isso com um desenvolvedor que usa email, um wiki da intranet, comentários no rastreamento de bugs, controle de fonte ou ferramentas de revisão de código, mensagens instantâneas, etc. assustador que muitos de nossos testes sejam automatizados para implementação direta por desenvolvedores sem delegação para testar.
Agrega valor aos testadores
Eu trabalhei com alguns testadores que poderiam ser engenheiros de sistema e outros com boas habilidades de comunicação (quase como leitura / telepatia). Meu trabalho mais eficaz com eles foi quando eles fizeram um bom trabalho explicando o comportamento inesperado que viram no sistema, geralmente escrevendo no rastreador de erros, embora muitas vezes uma demonstração fosse extremamente útil.
Outro critério importante é que o esforço de uma transferência de código foi o menor possível. Por um tempo, os desenvolvedores sentiram algum alívio quando os testadores puderam criar suas próprias versões. Agora, usamos servidores de integração constantes para que os desenvolvedores precisem apenas confirmar a fonte e, desde que usemos o TDD corretamente, existem muitos testes que são executados por eles mesmos e relatam de volta.
A concorrência global está aumentando os tempos de ciclo e o retrabalho está sendo retrabalhado para fora do sistema. Se amanhã eu ouvir de um testador um defeito que eu adicionei hoje, como vou competir com o cara que não cometeu hoje (ou o encontrou)? Ainda não estamos lá, mas acho que os dias dos programadores do tipo cut-and-try estão contados. Vi demonstrações de desenvolvedores do Google que podem ter ensaiado muito, mas eles parecem capazes de digitar um programa do começo ao fim durante uma palestra de 90 minutos, explicando enquanto digitam com poucos ou nenhum problema no ciclo de alteração e execução . Os testadores agregam valor diminuindo o tempo entre o trabalho e o retrabalho, para que os relatórios concisos antecipados sobre a compilação de hoje sejam uma grande vantagem.
Novas funções de teste
Muitas organizações estão desempenhando funções no SDET - Software Developer Engineer in Test. Esses caras script, código e revisão de código. O link a seguir é um blog para um SDET na Microsoft.
http://aliabdin.wordpress.com/2007/03/31/what-does-an-sdet-do/
Ele também descreve os engenheiros de teste de software (STE) que alimentam os bugs encontrados no SDET. Outra coisa que me impressionou sobre o papel do SDET é que, diferentemente dos desenvolvedores de software tradicionais, quando eles têm sistemas de buggy, precisam conhecer o código de todo o sistema, porque quase qualquer parte pode ser a fonte do problema, portanto, o extenso mapa mental os ajuda localize-o.
Formando uma visão que leva a uma transição bem-sucedida
Eu encontrei um problema semelhante de um gerente de projeto sem saber como encaixar essa função no scrum. Ser mestre de scrum era seu destino de transição. É um papel bem definido e há treinamento para ele. Continue procurando e você pode encontrar algo semelhante para o teste.
Há mais informações sobre o teste Agile aqui:
http://www.ambysoft.com/essays/agileTesting.html#AgileTestingStrategies
e sobre a equipe de teste independente aqui:
http://www.ambysoft.com/essays/agileTesting.html#IndependentTestTeam
As observações de Scott Ambler sobre a proporção de desenvolvedores e testadores nas abordagens Agile vs. tradicional não farão o seu dia (15: 1 vs. 3: 1). Sugiro entender e criar uma visão para sua equipe de teste com base nas habilidades e conhecimentos das ferramentas:
Boa sorte na transição para o XP e na preparação de sua equipe para fazer o mesmo.
Para um desenvolvimento típico orientado a testes, provavelmente não é necessário que o seu controle de qualidade conheça nenhuma programação.
Mas se você estiver desenvolvendo um comportamento orientado para o comportamento, seria benéfico para o seu controle de qualidade conhecer uma linguagem como o pepino . Especialmente, se seus analistas de negócios estiverem escrevendo requisitos de história no estilo "Quando Quando".
No entanto, isso realmente depende do seu 'pessoal' e das ferramentas com as quais você está trabalhando. Eu diria que é possível que eles sejam eficazes com zero conhecimento de programação, mas certamente não faria mal e os tornaria mais eficazes.