Os desenvolvedores devem ser responsáveis ​​por outros testes que não os testes de unidade; se sim, quais são os mais comuns?

Atualmente, estou trabalhando em um projeto bastante grande e usei o JUnit e o EasyMock para funcionalidade de teste de unidade bastante extensiva. Agora estou interessado em que outros tipos de teste eu deveria me preocupar. Como desenvolvedor, é minha responsabilidade me preocupar com coisas como testes funcionais ou de regressão? Existe uma boa maneira de integrá-los de maneira útil em ferramentas como Maven / Ant / Gradle? Eles são mais adequados para um testador ou BA? Existem outros tipos úteis de testes que estão faltando?

É sua responsabilidade se esforçar para fornecer código sem defeitos. Você deve escrever, ajudar a escrever ou garantir que os testes sejam escritos ou executados para dar confiança no código que você está entregando.

Nota: não estou dizendo que você é obrigado a fornecer código sem defeitos. Em vez disso, você deve tentar escrever o melhor código possível para os requisitos que foram fornecidos. Parte da capacidade de fazer isso significa que o código deve ser testado.

Se isso significa que você é pessoalmente responsável pelos testes funcionais e de regressão, é principalmente uma função de como sua empresa está organizada. Todos os programadores mais qualificados que conheço não se perguntam "é minha responsabilidade escrever testes do tipo X?". Em vez disso, eles se perguntam "o que devo fazer para garantir que meu código seja testado corretamente?". A resposta pode ser escrever testes de unidade ou adicionar testes à regressão, ou pode significar conversar com um profissional de controle de qualidade e ajudá-lo a entender quais testes precisam ser escritos. Em todos os casos, no entanto, isso significa que eles se importam o suficiente com o código que estão escrevendo para garantir que ele seja testado corretamente.

Conclusão: você deve ser responsável por fornecer código de alta qualidade. Se isso significa que você precisa escrever alguns testes funcionais ou de regressão, faça-o.

Isso pode ajudá-lo:

Q1 são escritos pelos desenvolvedores.

O Q2 é automatizado pelos desenvolvedores e escrito em colaboração com os negócios e / ou testadores.

Existem outros tipos úteis de testes que estão faltando?

Existem testes de aceitação para os quais eu recomendaria estruturas no estilo BDD que usam a linguagem Gherkin : JBehave (Java), Pepino (Ruby), Behat (PHP) etc. Este tipo de teste tem algumas vantagens sobre os testes de unidade:

• Os testes são facilmente legíveis por não desenvolvedores, para que você possa mostrá-los aos clientes
• Os testes descrevem claramente os processos de negócios sem entrar em detalhes da implementação (não quero dizer que a implementação não seja importante - com certeza é - mas é melhor quando você separa os requisitos de negócios do próprio código)
• Os testes fazem coisas que os usuários farão usando seu aplicativo
• Eles são mais fáceis de escrever (IMHO, pode depender da linguagem e da estrutura): sem zombaria, menos detalhes técnicos

O teste funcional pode ser automatizado como testes de unidade e é muito útil para testar como os diferentes componentes do seu projeto funcionam juntos e quão bem o seu sistema reflete as regras de negócios.

Além disso, esse teste automatizado serve como suíte de testes de regressão e aceitação para qualquer alteração principal (ou secundária) que você precise fazer no software (correção de bugs, refatoração, alteração comercial, nova funcionalidade etc.). Isso dá aos desenvolvedores muito mais confiança para fazer isso.

Existem várias estruturas para esse tipo de teste, estamos usando fitnesse com resultados muito bons. Possui uma biblioteca muito boa para testar páginas da Web (usamos para testar nosso aplicativo e serviços da Web) e se integra muito bem ao Maven e Jenkins .

Também costumávamos fazer "testes funcionais cruzados", entre desenvolvedores, mas esse tipo de teste não é "repetível", portanto, sua utilidade é limitada ...

Como desenvolvedor, considero-me responsável pelo teste de unidade de todo o meu código e garanto, da melhor forma possível, que ele não tem defeito. É por isso que temos tantas ferramentas à nossa disposição, como zombarias. O objetivo de criar objetos de simulação em seus testes é exatamente tentar isolar seu código do mundo "externo" e garantir que ele esteja funcionando bem e se houver alguma falha, "a culpa não é sua".

Dito isto, apesar do fato de que a culpa não é sua e que seu código está funcionando como deveria, isso não significa que você não pode ajudar no restante dos testes. Acredito que também é sua a responsabilidade de ajudar e integrar seu trabalho no trabalho de outras pessoas. As equipes de desenvolvimento de TI devem trabalhar sempre como uma máquina bem lubrificada, trabalhando em conjunto com outros departamentos (como o QA) como uma equipe maior para fornecer software confiável.

Mas esse é o trabalho de uma equipe, não apenas o seu.

Obviamente testes de integração ; eles são mais importantes e mais difíceis de escrever do que os testes de unidade. É como construir uma casa; Com o teste de unidade, você garante apenas que os tijolos são sólidos e resistem à pressão, temperatura, umidade e outras condições. Mas você não tem idéia de como a casa se parece e se comporta com os tijolos juntos.

O problema com grandes projetos, especialmente os Java que residem em um contêiner, é que o teste de integração é difícil. Portanto, para facilitar os testes de integração do sistema em grandes projetos, é necessária uma estrutura de teste, feita especialmente para o projeto, que é o trabalho do desenvolvedor para codificá-lo. Recentemente, grandes melhorias foram feitas nessa área e plataformas como o Arquillian simplificam muito a escrita de uma estrutura de teste (ou mesmo a substitui).

No mundo real, você é tão responsável quanto seu time / chefe o considera responsável. Se você é pago ou está empenhado em trabalhar incessantemente para encontrar todos os casos extremos e ir direto ao capricho da interpretação do seu chefe (ou pior, do marketing) dos bugs da lógica de negócios, então, de qualquer maneira, você é responsável por tudo.

Portanto, em outras palavras, faça o que for exigido pelo escopo fornecido a você. É um acréscimo legal para mostrar algum senso comum ou ver outras pessoas usarem o produto que você está construindo para ter uma noção dos casos de uso e possíveis problemas a serem corrigidos, mas leve isso à sua equipe ou chefe antes de "consertar". Isso inclui as ferramentas de sua escolha. Todos os seus esforços devem ser algo com que todos estejam envolvidos.

Se sua pergunta for útil sobre rastreamento de bugs, eu gosto do bugzilla, google docs, zendesk ou basecamp em termos de sistemas de comunicação.

Eu não acho que isso já foi coberto - desculpe se eu perdi.

Uma questão é o uso eficiente do tempo dos desenvolvedores.

Os desenvolvedores geralmente não têm as habilidades necessárias para serem bons em certos tipos de teste. Em parte, isso é natural. É a mesma razão pela qual os autores têm editores. É muito difícil ver as deficiências em algo se você estiver muito próximo disso. Mas também trata de diferentes conjuntos de habilidades e especialidades diferentes.

Sendo esse o caso, um desenvolvedor que gasta tempo testando é pobre em termos de custo: benefício. Esse desenvolvedor seria mais produtivo ao fazer outras coisas, e um testador especialista seria mais produtivo ao fazer o teste.

Claro que isso faz várias suposições que não são necessariamente válidas. Em uma empresa pequena, por exemplo, pode não fazer sentido empregar pessoas especializadas em testes. Embora possa fazer mais sentido contratar uma equipe de suporte extra e fazer com que eles façam alguns testes, ou pelo menos fazer com que as pessoas testem código que não escreveram por si mesmas.

Acredito que é nossa responsabilidade (também do desenvolvedor) abranger todos os cenários de teste possíveis antes de ser lançado para o controle de qualidade. O objetivo do controle de qualidade é validar o software. Além disso, martelar seu próprio código por erros sempre fará com que você pareça bem na hora do controle de qualidade.

Quem melhor que um desenvolvedor para saber quais casos de teste são os mais relevantes. O desenvolvedor deve ser responsável por fazer todos os testes de unidade, sempre que possível, o desenvolvedor deve ajudar a escrever e executar os scripts de teste. Como isso raramente é possível em grandes projetos, deve ser concedido tempo para o desenvolvedor revisar todos os casos de teste. Além disso, o desenvolvedor deve ter conhecimento e usar a grande variedade de ferramentas de teste automatizadas disponíveis.

Na minha carreira de desenvolvimento, acho que os projetos acabam com melhores resultados, onde há uma forte integração entre as equipes de desenvolvimento e as equipes de teste.

pelo menos um membro de cada equipe também deve participar das outras reuniões de planejamento e implementação.