Os desenvolvedores devem estar envolvidos nas fases de teste?

10

estamos usando um processo de desenvolvimento clássico em forma de V. Temos então requisitos, arquitetura, design, implementação, testes de integração, testes de sistema e aceitação.
Os testadores estão preparando casos de teste durante as primeiras fases do projeto. O problema é que, devido a problemas de recursos (*), as fases de teste são muito longas e geralmente são encurtadas devido a restrições de tempo (você conhece os gerentes de projeto ...;)). Os desenvolvedores estão fazendo seus testes de unidade como deveriam.

Portanto, minha pergunta é simples: os desenvolvedores devem se envolver nas fases de testes e isso não é muito "perigoso". Receio que isso dê aos gerentes de projeto uma falsa sensação de melhor qualidade à medida que o trabalho foi realizado, mas os dias de trabalho agregados teriam algum valor? Não tenho muita confiança dos desenvolvedores fazendo testes (sem ofensa aqui, mas todos sabemos que é muito difícil interromper em alguns cliques o que você fez em vários dias).

Obrigado por compartilhar seus pensamentos.

(*) Por motivos obscuros, aumentar o número de testadores não é uma opção atualmente.

(Logo no início, não é uma duplicata de Os programadores devem ajudar os testadores a projetar testes? Que fala sobre preparação e não execução de testes, onde evitamos a implicação de desenvolvedores)

LudoMC
fonte
Editado para precisar que nossos desenvolvedores estão fazendo seus testes de unidade. Estou preocupado com as fases após os testes de unidade, quando o pessoal de controle de qualidade entra no circuito.
LudoMC
Hmmm, não será fácil escolher entre o "SIM absoluto e inequívoco" e o "absolutamente não". Vai pensar um pouco mais, esperando que outras respostas ou comentários sobre as respostas tenham uma visão mais clara.
LudoMC
Ok, aceitei uma resposta, mas também votei com vantagem em algumas das outras que forneceram bons argumentos para o problema. Obrigado a todos.
LudoMC

Respostas:

13

Olhando para a sua pergunta muito literalmente ("envolvido em") Minha única resposta é absolutamente inequívoca

SIM

Os desenvolvedores nunca devem ter a palavra final em seu próprio código.

Porém, os Devs devem estar envolvidos no teste do trabalho de outros desenvolvedores. Faz duas coisas:

  1. Traz a visão de um desenvolvedor para o teste. Isso é tanto do caso geral de apenas saber quais APIs provavelmente estão sendo usadas em um determinado momento, quais as exceções que podem surgir dessas APIs e como elas devem ser tratadas. Também ajuda em um projeto específico, porque os desenvolvedores ficam muito mais expostos às várias discussões sobre por que algo está sendo feito do que o controle de qualidade normalmente faz, o que significa que eles podem identificar casos extremos que o controle de qualidade não faria. Os erros detectados por um desenvolvedor também provavelmente serão mais baratos de corrigir, porque um desenvolvedor geralmente fornecerá mais informações e muito mais informações sobre como corrigi-lo imediatamente.
  2. Ele fornece ao desenvolvedor a exposição a partes do aplicativo às quais eles não podem ser expostos. Isso os tornará melhores desenvolvedores para esse aplicativo a longo prazo. Quando eu sei como minha API é consumida, sou muito melhor em antecipar a próxima coisa que devo fazer do que se estivesse apenas dirigindo uma especificação. Mais importante, posso saber quando as especificações estão erradas antes de começar a codificar se conheço o aplicativo e seu uso.

Finalmente, por que você não usaria o máximo de olhos possível? Você raramente pode se dar ao luxo de passar pelo processo de contratação e integração para trazer pessoas adicionais de controle de qualidade a bordo para um momento de crise. Então, onde você encontra os olhos extras que precisa? Ou você tenta passar o tempo de crise com o mesmo número de controle de qualidade que teve o tempo todo? Mesmo que os desenvolvedores passem 20% do tempo testando e 80% consertando os bugs que aparecerem, ainda há mais olhos no aplicativo do que antes. O teste automatizado fornece apenas um certo nível de garantia e nunca será 100%.

http://haacked.com/archive/2010/12/20/not-really-interested-in-lean.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+haacked+%28you%27ve+been+HAACKED%29

MIA
fonte
+1, uma vez que os desenvolvedores devem estar envolvidos na análise do código de outros
Gary Rowe
Aceito este por causa de 1 - o link fornecido (muito interessante e intimamente ligado à nossa situação) 2 - os bons argumentos em sua resposta: o fato de que os desenvolvedores não devem testar seu próprio código, que lhes dá uma boa visão de outras partes do aplicativo ou sistema.
LudoMC
11

Para qualquer coisa, exceto teste de unidade, absolutamente não. Os desenvolvedores sabem muito sobre o aplicativo e como "deve" funcionar para ser testadores objetivos.

kirk.burleson
fonte
2
Na maior parte, concordo totalmente com isso. No entanto, o post dizia que a equipe de controle de qualidade é responsável por apresentar os casos de teste. Supondo que os testes tenham uma cobertura completa, não vejo uma razão convincente para que os desenvolvedores não possam executar os casos de teste antes de liberar o software para o controle de qualidade. Isso pode ajudar a detectar erros mais cedo e reduzir a sobrecarga resultante de várias versões de correção de erros.
pemdas
2
Não concordo com esse ponto de vista porque ter o olho de um desenvolvedor pode ser extremamente benéfico durante o teste funcional. Um desenvolvedor é um recurso valioso para que não deveria estar passando por cenários de teste rote, mas eles podem aconselhá-testers onde ir para quebrar a aplicação mais eficiente (tornando a vida testadores mais divertido ...)
Gary Rowe
GR ... geralmente concordo com sua afirmação de que os desenvolvedores têm um recurso valioso, mas a questão aqui é realmente sobre reorganizar o recurso que eles já têm para garantir uma cobertura de teste adequada. Se isso significa que os desenvolvedores precisam se envolver em alguns testes do Qaish, que assim seja.
Pemdas
8

A diferença fundamental em testar filosofias entre desenvolvedores e Qs é a seguinte: o programador normalmente testa seu programa para provar que seu código funciona (teste "positivo"). O controle de qualidade pode e faz isso, mas também tem um foco adicional em descobrir o que não funciona tentando interromper o software (usando testes "negativos").

Na medida em que a equipe de controle de qualidade possa ser potencialmente corrompida pelos testes dos programadores que "comprovam" que o software funciona, deve haver isolamento entre o teste do desenvolvedor e o teste de controle de qualidade. O desenvolvedor certamente pode ajudar no teste de controle de qualidade, demonstrando o que funciona, mas cabe ao controle de qualidade verificar independentemente se o software não quebra.

A melhor coisa que o programador pode fazer para ajudar no esforço de teste é fornecer um conjunto de testes de unidade verificável, abrangente e de alta qualidade, contendo testes que se alinham aos requisitos individuais no documento de requisitos.

Robert Harvey
fonte
2

Bem, em termos de teste, existem 3 tipos.

Caixa preta, cinza e branca.

Caixa preta refere-se a usuários testando o produto, sem conhecimento de como o produto funciona internamente.

A caixa cinza refere-se a usuários avançados que possuem conhecimento em programação de computadores, mas não fazem parte da equipe de desenvolvimento. Essas pessoas testam se o produto possui vazamentos de memória, problemas de requisitos do sistema e assim por diante.

Aqui está a parte principal: Caixa branca refere-se a desenvolvedores testando o produto no nível do código. Isso significa dizer que eles fazem testes de unidade, depuração, ... etc.

Portanto, é bom que os usuários e a equipe de desenvolvimento estejam todos envolvidos na fase de teste, mas cada um deles exige um nível de comprometimento apropriado dos usuários e da equipe de desenvolvimento, dependendo do que é testado.

Mauris
fonte
2

O teste de unidade é obrigatório para todos os desenvolvedores

Para obter informações sobre como isso pode ser usado para seu benefício, leia os links a seguir, se você estiver no desenvolvimento de C ++:

NÃO HÁ MANEIRA DE UMA PESSOA DE QA PODER FAZER ESTES TESTES. DE JEITO NENHUM.

Fanatic23
fonte
Eu concordo, mas estava fazendo a pergunta de outra maneira. Os desenvolvedores devem se envolver em testes (excluindo testes de unidade), onde geralmente apenas pessoas de controle de qualidade estão envolvidas.
LudoMC
1

Assumindo que o projeto tenha um número significativo de desenvolvedores, tenha todos os meios para trabalhar nos testes. Uma ressalva seria que os desenvolvedores não trabalham no teste (isso não inclui o teste de unidade) para seu próprio código.

John Percival Hackworth
fonte
+1 para os desenvolvedores não testar seu próprio código (ou pelo menos não sozinho)
LudoMC
0

Prefiro ver a equipe administrativa (ou usuários em potencial reais) fazer o teste de controle de qualidade do que os desenvolvedores. Alguém que não sabe como o produto foi projetado para funcionar, precisa tentar usá-lo. Os desenvolvedores tendem a ser muito limitados na maneira como abordam os testes e, francamente, são muito caros por hora para usar também nos testes de controle de qualidade.

HLGEM
fonte
0

Você escreve:

O problema é que, devido a problemas de recursos (*), as fases de teste são muito longas e geralmente são encurtadas devido a restrições de tempo. Isso ocorre porque os desenvolvedores não as estão realizando. Uma das maiores empresas de Internet que oferece os melhores produtos mais estáveis não usa testadores. Eles usam apenas testes automáticos, todos feitos pelos próprios desenvolvedores. Os resultados são dez produtos melhores do que quando o desenvolvedor deixa o teste para "testadores".

É como ter trabalhadores da construção civil construindo sua casa, mas ter uma equipe diferente, certificar-se de que o prédio realmente esteja de pé, as portas se abrirem e fecharem, o ar condicionado estiver funcionando etc. sendo não confiável.

Cara
fonte