O teste de unidade é desenvolvimento ou teste?

Tive uma discussão com um gerente de testes sobre o papel dos testes de unidade e integração. Ela solicitou que os desenvolvedores relatassem o que eles testaram na unidade e na integração e como. Minha perspectiva é que os testes de unidade e integração fazem parte do processo de desenvolvimento, não do processo de teste. Além da semântica, o que quero dizer é que os testes de unidade e integração não devem ser incluídos nos relatórios de teste e os testadores de sistemas não devem se preocupar com eles. Meu raciocínio é baseado em duas coisas.

1. Testes de unidade e integração são planejados e executados sempre contra uma interface e um contrato. Independentemente de você usar contratos formalizados, você ainda testa o que, por exemplo, um método deve fazer, ou seja, um contrato.

   No teste de integração, você testa a interface entre dois módulos distintos. A interface e o contrato determinam quando o teste passa. Mas você sempre testa uma parte limitada de todo o sistema. O teste de sistemas, por outro lado, é planejado e executado de acordo com as especificações do sistema. A especificação determina quando o teste passa.

2. Não vejo nenhum valor em comunicar a amplitude e a profundidade dos testes de unidade e integração ao testador (sistemas). Suponha que eu escreva um relatório que liste que tipo de testes de unidade são executados em uma classe de camada de negócios específica. O que ele / ela deveria tirar disso?

   Julgar o que deve e o que não deve ser testado é uma conclusão falsa, porque o sistema ainda pode não funcionar da maneira que as especificações exigem, mesmo que todos os testes de unidade e integração sejam aprovados.

Pode parecer uma discussão acadêmica inútil, mas se você trabalha em um ambiente estritamente formal como eu, é realmente importante determinar como fazemos as coisas. Enfim, eu estou totalmente errado?

Escrever testes automatizados é um trabalho do desenvolvedor; os testes fazem parte da base de código e devem ser tratados como tal - devem estar sujeitos às mesmas revisões de código, padrões de codificação, disciplina de controle de origem, etc., como o restante do projeto.

A execução desses testes é realizada por dois motivos: primeiro, como uma ferramenta para orientar os desenvolvedores. Você executa testes para verificar se o código que você acabou de escrever faz o que deveria, usa-os como documentação adicional e para verificar se as alterações não quebram nenhuma funcionalidade existente. Se você faz TDD real, os testes também são uma fonte autorizada de especificações técnicas. O segundo motivo para usar os testes é durante o controle de qualidade e a implantação. A execução de todos os testes automatizados deve ser uma das primeiras etapas em cada rodada de teste; a execução de testes automatizados é barata (praticamente nenhuma mão de obra necessária) e não faz muito sentido entrar em testes manuais se os automatizados falharem.

Isso significa que as responsabilidades devem ser assim:

• Os desenvolvedores escrevem testes automatizados
• Os desenvolvedores executam testes automatizados individuais, conforme necessário, como parte de seu fluxo de trabalho de desenvolvimento
• O controle de qualidade executa todos os testes automatizados como um dos primeiros estágios do teste

Se você possui um servidor de construção, a tarefa do controle de qualidade (referente aos testes automatizados) se resume a "abrir o relatório do servidor de construção e verificar se tudo está verde".

Acho que o mais importante para você seria esclarecer por que ela precisa desse relatório.

Pode haver explicações diferentes (como sugerido por várias respostas), que exigem estratégias muito diferentes.

• se ela é uma pessoa razoável, simplesmente querendo obter informações para ajudar o trabalho de sua equipe de teste, faz sentido chegar a um entendimento comum e elaborar alguma solução que seja adequada para vocês dois. Você pode discutir com ela a natureza dos testes de unidade e a diferença fundamental entre os testes de unidade versus funcional / sistema / aceitação. Espero que você entenda que eles funcionam em níveis muito diferentes e que nenhum deles pode substituir o outro.
• se ela é uma maníaca ou burocrata de controle, exigindo um relatório apenas por isso, você pode gerar algo para satisfazer seus caprichos com o mínimo de esforço (por exemplo, o que o @Doc sugeriu :-).
• se ela estiver em algum jogo poderoso, você pode questionar se ela tem o direito de exigir relatórios dos desenvolvedores. Na minha experiência, os desenvolvedores geralmente não devem se reportar ao departamento de controle de qualidade.

Acho que o papel do controle de qualidade e desenvolvimento e a interação podem variar muito entre as organizações. Mas, em geral, na minha equipe, digo aos membros para fingir que não há uma equipe de controle de qualidade, no sentido de que eles são responsáveis ​​pelas mudanças que estão promovendo na produção. Por sua vez, nossa equipe de controle de qualidade não assume muito a respeito dos testes dos desenvolvedores e faz uma boa quantidade de testes no sistema como um todo funcional.

Por esse motivo, nossa equipe de controle de qualidade não se importa muito com o que é e o que não é testado em unidade antes de começar.

Eu acho que é útil para a equipe de controle de qualidade entender o que os testes de unidade fazem e não cobrem, em alto nível, para que possamos trabalhar coletivamente para identificar lacunas e áreas que possam precisar de mais rigor. Portanto, talvez seu colega esteja procurando um resumo de alto nível, em oposição aos detalhes sangrentos.

Ela insistiu que os desenvolvedores relatassem o que eles testaram na unidade e na integração e como.

Ela está realmente tentando discutir se esse tipo de teste está realmente no domínio do "desenvolvimento" ou está apenas tentando descobrir o quão bem seu código é coberto pelo teste de unidade? Apenas olhando as informações que você forneceu, parece que ela só quer saber quais partes do código são cobertas e onde ela deve concentrar o esforço de sua equipe.

Eu trabalhei em uma equipe de teste logo depois da escola antes de me mudar para uma função de desenvolvimento e posso ver como isso pode ser valioso para ela e sua equipe.

Não vejo que isso importe demais.

Se você não os fornecer ao controle de qualidade / teste, e eles não fizerem os testes adequados, e ele falhar na produção, é culpa deles deixar o controle de qualidade entrar em produção sem verificar se funciona como especificado.

Se você os fornecer ao controle de qualidade / teste, e eles não fizerem os testes adequados ... o mesmo resultado como se você não os tivesse fornecido.

No entanto, se você os fornecer, eles também poderão compará-los com as especificações e / ou sugerir quais testes podem ser falhos ou precisam ser alterados porque encontraram um bug.

Realmente, não vejo muita desvantagem em fornecê-los. Ainda está em controle de qualidade / teste para validar com as especificações. Se eles tomam o caminho preguiçoso e apenas confiam que seus testes são bons o suficiente porque todos passaram, foram eles que falharam em seu trabalho. Contanto que eles ainda possuam as especificações, os resultados dos testes de unidade / integração são apenas leves e não devem machucá-lo de uma maneira ou de outra. Esta é a razão pela qual temos dev e QA. Várias verificações de que o aplicativo executa conforme especificado.

Os desenvolvedores cometem erros, o controle de qualidade comete erros, o ideal é que eles não cometam erros no mesmo item ... e se o fizerem ... é potencialmente um analista que deixou cair a bola escrevendo uma especificação pouco clara.

O teste de unidade é de responsabilidade dos desenvolvedores, pois os testes podem ser úteis para entender como os trechos de código funcionam por conta própria. Alguns podem ver isso como uma forma de documentação e, portanto, têm algum valor, embora possa haver sobrecarga se os testes de unidade forem alterados regularmente.

O outro valor na passagem dos testes é que isso pode evitar duplicar os testes que podem ser redundantes em termos de garantia da funcionalidade básica.

Também há testes de aceitação do usuário que são separados de tudo isso, pois o usuário final pode ter seu próprio entendimento de como um sistema deve funcionar.

Se sua empresa possui uma metodologia definida para garantir a qualidade de seus produtos (se eles são compatíveis com SOX ou estão tentando melhorar seu nível de CMMI, provavelmente o fazem), os produtos devem ser capazes de resistir à auditoria para mostrar que o processo foi seguido.

Freqüentemente, o processo definido inclui testes de unidade (o que é uma coisa boa). Infelizmente, isso também significa que você deve documentar seus testes de unidade e provar que eles foram executados para resistir à auditoria. Isso significa que você precisa de uma maneira de relatar seus testes de unidade.

Olhe para uma ferramenta como o Sonar para ajudá-lo - ela relatará o nível de cobertura do código e os resultados dos testes de unidade.

Isso realmente depende da empresa, mas pela minha experiência em trabalhar como testador de sistema em uma abordagem tradicional, mas também como testador trabalhando em uma equipe ágil em um modelo de CD, saber o que foi testado por unidade e integração é extremamente útil.

A qualidade é responsabilidade da equipe - desenvolvedores, testadores e gerenciamento de produtos e trabalhar juntos é a melhor maneira de garantir isso.

Portanto, o gerente de teste deseja saber o que foi testado por unidade e integração e é um pouco mais de trabalho extra para os desenvolvedores, mas economiza o trabalho geral do projeto! Ao fornecer as informações ao gerente de teste, eles podem concentrar o esforço da equipe de teste no que é crítico e importante. Como mencionado anteriormente, se uma área do código não é testada em unidade, a equipe pode concentrar seu esforço lá em comparação com uma área que é fortemente testada - por que duplicar o esforço? Todos vocês estão trabalhando para o mesmo objetivo final de software de alta qualidade lançado no prazo.

Eu pensaria que seria benéfico fornecer esse tipo de coisa. A cobertura do teste de unidade deve ser algo conhecido pelo desenvolvimento e teste, para que eles possam explicar isso.

Obviamente, você precisa testar as coisas críticas dos negócios, não importa o quê. Você precisa testar a funcionalidade comumente usada com força, independentemente de ter uma excelente cobertura de teste de unidade. Não faria mal deixá-los saber que outros lugares são cobertos por testes de unidade. O código já verifica casos extremos neste pequeno controle? É útil saber esse tipo de coisa por todos os lados da empresa.

Vale mencionar a abordagem discutida no livro "Como o Google testa o software": teste e controle de qualidade é responsabilidade de todos, e os padrões são rigorosos.

O verdadeiro papel do que é tradicionalmente chamado de departamento "Testes" é na verdade a produtividade do desenvolvedor; isto é, automação para permitir que a organização alcance economicamente o nível exigido de rigor.