Compartilhando casos de teste de desenvolvimento (integração de unidade e desenvolvimento) com a equipe de QA (teste)?

A equipe de teste (a chamada equipe de controle de qualidade em algumas organizações) insiste em que a equipe de desenvolvimento compartilhe seus casos de teste (da equipe de desenvolvimento) com eles. Seus argumentos são que os casos de teste de desenvolvimento são o ponto de partida para o teste de controle de qualidade.

Como membro da equipe de desenvolvimento, não entendo a solicitação. Por mim, o testador deve testar a solução com base nos requisitos. Não sei se a equipe de teste deve ser compartilhada com o documento de design detalhado (design de baixo nível). No entanto, estamos compartilhando o design detalhado.

Li aqui algumas postagens que dizem que a equipe de controle de qualidade deve compartilhar seus casos de teste com a equipe de desenvolvimento para obter uma solução melhor e um melhor rendimento. Porém, nada da equipe de desenvolvimento compartilhando seus casos de teste com a equipe de controle de qualidade.

Parece que minha equipe de controle de qualidade ficará muito feliz se eu compartilhar meus casos de teste de unidade de desenvolvimento e integração e os resultados do teste.

Quando sua equipe de desenvolvimento e sua equipe de controle de qualidade não se comunicam, existe um certo risco de que alguns testes sejam desnecessariamente feitos duas vezes e outros sejam esquecidos. Um dos piores cenários é quando sua equipe de desenvolvimento implementou alguns bons testes de integração automática, que são executados em alguns minutos ou horas, e seu pessoal de QA testa as mesmas coisas manualmente, gastando dias ou semanas para essa tarefa. Outro cenário ruim é quando os dois grupos pensam que o outro grupo é responsável por algum tipo de teste e, portanto, esses testes são omitidos.

Portanto, supondo que ambos os grupos trabalhem em equipe e não um contra o outro, faz sentido informar-se detalhadamente quais testes são feitos por cada grupo e permitir que os dois grupos coordenem suas atividades.

A equipe de teste (a chamada equipe de controle de qualidade em alguma organização) insiste que a equipe de desenvolvimento compartilhe seus casos de teste (da equipe de desenvolvimento) com eles.

Certamente, o controle de qualidade deve ter uma compreensão geral do que é coberto pelos testes de unidade / integração e do que não é.

Seus argumentos são casos de teste de desenvolvimento, que são o ponto de partida para o teste de controle de qualidade.

... mesmo que seu raciocínio seja falho. O mantra número 1 de uma pessoa de controle de qualidade é não confiar nos desenvolvedores . "Não se preocupe! Eu verifiquei isso completamente!" é o primeiro passo para um problema de produção gigante.

Como Doc Brown diz, não é bom gastar muito tempo no controle de qualidade em algo que seja bem coberto por testes automatizados. Mas é tolice não gastar tempo com algo que é bem coberto por testes automatizados. E é um desperdício gastar muito tempo documentando detalhadamente seus testes de unidade quando o controle de qualidade não deveria realmente confiar neles (e porque esse nível de documentação leva seus desenvolvedores a fazer menos / maus testes de unidade).

Em uma arquitetura de software moderna, a intenção é que os testes não testem apenas o código, mas o façam de maneira a documentar sua funcionalidade.

Esta documentação sobre o que o código faz (além do que se destina nas especificações) é útil para os QA'ers entenderem melhor a intenção do código e também se ele atende aos requisitos. Também é uma informação útil quando os QA'ers estão escrevendo casos de teste e ajudará a dar uma idéia do que, em teoria, já está sendo testado. Algumas das áreas sob teste podem se beneficiar de casos adicionais e outras podem ser expostas como não tendo testes.

Os detalhes reais dessa exposição dependerão muito da composição organizacional e, em particular, da profundidade técnica dos testadores (por exemplo, leitura do código fonte).

Para ser um pouco contrário ... Eu geralmente gosto de ignorar os testes do desenvolvedor e criar meus próprios 'testes (sou membro de uma grande equipe de QE). Descobri que ignorar os testes do desenvolvedor ajuda a evitar a mentalidade de analisar o problema / questão / recurso apenas do ponto de vista dos desenvolvedores.

MEU lema QE é: QE deve agregar valor testando o produto. "mesclar e executar testes de unidade" por si só é QA insuficiente!

Minha primeira reação a essa pergunta é "depende".

Depende do que você quer dizer com "casos de teste da equipe de desenvolvimento".

• Se você tiver apenas testes de unidade ( teste de caixa branca ); A equipe de controle de qualidade (integração e teste do sistema) não pôde alavancar seus casos de teste. Os testes de unidade existem apenas para verificar sua unidade, que não satisfaz apenas um requisito (principalmente). O teste de caixa branca não deve ser o caminho para testes de integração ou sistema.

• Se você tiver testes comportamentais; A equipe de controle de qualidade pode usá-los para derivar alguns cenários de integração.

• Se você estiver usando TDD ; conforme definição, os testes são documentos executáveis ​​dos requisitos, arquitetura e design do aplicativo. A equipe de controle de qualidade definitivamente precisaria desses casos de teste.
• Alguns métodos de design de teste, como o teste de caixa cinza, exigem informações detalhadas do projeto para poder isolar ou zombar dos assuntos de teste, como componente ou subsistema (teste de integração). Portanto, também é necessário compartilhar o projeto detalhado com a equipe de controle de qualidade.
• Os caras do Teste do Sistema nunca se preocupam com o design detalhado. Eles se concentram nos cenários do usuário. Portanto, os testes de desenvolvimento (caixa branca) não serão úteis para eles.

Minha humilde recomendação para o seu caso é uma avaliação de abordagens ágeis, como ter testador (s) (QA) dentro da equipe do desenvolvedor e testes de design (recurso, integração, sistema) juntos antecipadamente.

Não há motivo para você não compartilhar o que testou com a equipe de controle de qualidade; no entanto, eles devem duplicar os seus testes que consideram importantes para verificar corretamente o aplicativo.

1) Eles são responsáveis ​​por testar o código / aplicativo / o que for. Duplicando seus testes, quando apropriado, eles verificam se o seu teste foi realizado corretamente.

2) Como desenvolvedor, você é responsável por testar seu código de unidade (geralmente, no entanto, algumas organizações também começaram a testar os códigos dos desenvolvedores). Essa é uma abordagem diferente e, geralmente, concentra-se mais na cobertura dos pontos de decisão em um método.

3) Como você mencionou, é importante que sua equipe de teste compartilhe os casos de teste com você para ajudá-lo a pensar nos casos que você talvez não tenha considerado originalmente.

4) Alguém mencionou que é responsabilidade das equipes de teste testar os requisitos e, embora isso seja verdade, o design detalhado também é bastante útil. Por ter o design, a equipe de teste não apenas pode garantir que você esteja cobrindo os requisitos, mas também os ajuda a entender algumas das decisões de design, além de ajudá-los a criar melhores casos de teste.