Os desenvolvedores devem ser responsáveis por testes que não sejam testes de unidade? Em caso afirmativo, quais são os mais comuns?

35

Atualmente, estou trabalhando em um projeto bastante grande e usei o JUnit e o EasyMock para uma funcionalidade de teste de unidade bastante abrangente. Agora estou interessado em com que outros tipos de testes devo 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 uma maneira utilizável em ferramentas como Maven / Ant / Gradle? São estes mais adequados para um testador ou BA? Existem outros tipos úteis de testes que estou perdendo?

    
por Jackie 17.12.2012 / 17:29
fonte

10 respostas

44

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

Observação: não estou dizendo que você precisa entregar um código sem defeitos. Em vez disso, você deve tentar escrever o melhor código possível para os requisitos que lhe foram dados. Parte de ser capaz de fazer isso significa que o código deve ser testado.

Se isso significa que você é pessoalmente responsável por 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 devidamente testado?". A resposta pode ser escrever testes de unidade, ou adicionar testes à regressão, ou pode significar conversar com um profissional de QA e ajudá-los 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 sejam devidamente testados.

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

    
por 17.12.2012 / 17:31
fonte
13

Isso pode ajudar você:

Q1 são escritos pelos desenvolvedores.

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

    
por 17.12.2012 / 18:03
fonte
3

Are there other useful types of testing that I am missing?

Há testes de aceitação para os quais eu recomendaria frameworks no estilo BDD que usam idioma Gherkin : JBehave ( Java), Pepino (Ruby), Behat (PHP), etc. Este tipo de teste tem algumas vantagens sobre os testes unitários:

  • 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 de 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)
  • 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 estrutura): sem detalhes de zombaria, menos técnicos
por 17.12.2012 / 18:07
fonte
3

O teste funcional pode ser automatizado da mesma forma que os testes de unidade, e é muito útil para testar como os diferentes componentes do seu projeto trabalham juntos e como seu sistema reflete as regras de negócios.

Além disso, esse teste automatizado serve como um conjunto de testes de regressão e aceitação para quaisquer alterações maiores (ou menores) que você tenha que fazer no software (correção de erros, refatoração, mudança comercial, nova funcionalidade, etc.). Isso dá aos desenvolvedores muito mais confiança para fazer isso.

Existem vários frameworks para esse tipo de teste, estamos usando fitnesse com resultados muito bons. Tem uma biblioteca muito boa para testar páginas web (nós a usamos para testar nosso aplicativo web e nossos serviços web) e ela se integra muito bem com Maven e Jenkins .

Nós também costumávamos fazer "cross functional testing", entre desenvolvedores, mas esse tipo de teste não é "repetível", então sua utilidade é limitada ...

    
por 19.12.2012 / 00:48
fonte
2

Como desenvolvedor, considero-me responsável pela unidade testando todo o meu código e garantindo, 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 zombeteiros em seus testes é exatamente tentar isolar seu código do mundo "externo" e garantir que ele está funcionando bem e, se houver algo que falhe, "não é sua culpa".

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

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

    
por 17.12.2012 / 18:03
fonte
1

Obviamente testes de integração ; são mais importantes e mais difíceis de escrever que os testes de unidade. É como construir uma casa; Com o teste de unidade você só garante o fato de que os tijolos são sólidos e resistem à pressão, temperatura, umidade e outras condições. Mas você não tem ideia 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. Assim, para facilitar os testes de integração de sistemas em grandes projetos, é necessário um framework de testes, feito especialmente para o projeto, que é o trabalho do desenvolvedor para codificá-lo. Recentemente grandes melhorias foram feitas nesta área e plataformas como o Arquillian simplificam muito a redação de um framework de testes (ou mesmo o substitui) ).

    
por 17.12.2012 / 22:29
fonte
1

No mundo real, você é tão responsável quanto sua equipe / chefe o considera responsável por ser. Se você é pago ou contratado para trabalhar incessantemente para encontrar todos os detalhes e saltar para o capricho da interpretação do seu chefe (ou marketing pior) dos bugs da lógica de negócios, então, de qualquer maneira, você é responsável por todos.

Em outras palavras, faça o que é exigido pelo escopo dado a você. É um bom extra lançar em algum senso comum ou ver outros usarem o produto que você está criando para ter uma noção dos casos de uso e possíveis problemas a serem consertados, mas trazer isso para sua equipe ou chefe antes de "consertar". Isso inclui as ferramentas de sua escolha. Todos os seus esforços devem ser algo que todos estejam envolvidos.

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

    
por 17.12.2012 / 22:52
fonte
1

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

Um problema é o uso eficiente do tempo dos desenvolvedores.

Os desenvolvedores muitas vezes não têm as habilidades para serem bons em determinados tipos de testes. Em parte, isso é apenas natural. É a mesma razão pela qual os autores têm editores. É muito difícil ver as deficiências em algo se você está muito perto disso. Mas também é sobre diferentes conjuntos de habilidades e diferentes especialidades.

Sendo esse o caso, um teste de tempo gasto pelo desenvolvedor é ruim em termos de custo: benefício. Esse desenvolvedor seria mais produtivo fazendo outras coisas, e um testador especialista seria mais produtivo fazendo o teste.

É claro que está fazendo várias suposições que não são necessariamente válidas. Em uma pequena empresa, por exemplo, pode não fazer sentido empregar pessoas especializadas em testes. Embora possa fazer mais sentido empregar uma equipe de suporte extra e fazer com que eles façam alguns testes, ou pelo menos fazer com que as pessoas testem códigos que não foram escritas por eles mesmos.

    
por 19.12.2012 / 06:23
fonte
0

Acredito que é nossa responsabilidade (também do desenvolvedor) abranger todos os possíveis cenários de teste antes que ele seja liberado para o controle de qualidade. O objetivo do controle de qualidade é validar o software. Além disso, martelar seu próprio código para erros sempre fará com que você pareça bom em termos de controle de qualidade.

    
por 17.12.2012 / 18:17
fonte
0

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

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

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

    
por 17.12.2012 / 20:27
fonte

Tags