Os desenvolvedores devem estar envolvidos nas fases de teste?

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)

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

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.

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.

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.

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 ++:

• Uma introdução rápida à estrutura de testes do Google C ++
• Ferramentas de teste de unidade C / C ++ de código aberto, Parte 1: Conheça a estrutura de teste de unidade Boost
• Ferramentas de teste de unidade C / C ++ de código aberto, Parte 3: Conheça o CppTest

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

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.

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.

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.