O teste é uma parte necessária da metodologia Agile?


24

Já participei de várias equipes que tentam praticar metodologias ágeis e, muitas vezes, essas equipes são centradas nos testes. O teste é uma parte necessária da prática da metodologia Agile ou é apenas uma prática de XP que foi travada ao longo dos anos?


76
O teste é uma parte necessária de qualquer desenvolvimento de software de qualidade.
Telastyn 25/09/14

2
possível duplicata de Você pode ser ágil sem fazer TDD (desenvolvimento orientado a teste)? - se você não concordar deixe-me saber ...
Murph

11
Eu discordo da duplicata. O teste é mais amplo que o TDD e a pergunta mais ampla tem respostas diferentes.
Bart van Ingen Schenau

Eu concordo com @BartvanIngenSchenau. Não apenas testar uma atividade muito mais ampla do que apenas fazer TDD, mas TDD e testes de unidade não são os mesmos. Estou surpreso que muitas pessoas confundam os dois últimos.
Andres F.

Pode ter sido dobrado no conceito de "Definição de Concluído", que em Agile / Scrum significa que depende do contexto. Quando o Agile é aplicado ao marketing, vendas, etc., eles não têm conceitos semelhantes aos testes de software, mas ainda possuem uma "definição de concluído". Para o software, a "definição de concluído" deve considerar a qualidade (visível e interna, por exemplo, a qualidade do código) do resultado final, bem como o nível de teste realizado.
rwong

Respostas:


33

O teste é absolutamente essencial para o ágil, principalmente porque o ágil se baseia em melhorias incrementais: a dificuldade é que às vezes pode ser difícil ver como as mudanças atuais afetarão seu código antigo. A melhor maneira de ter certeza de que você não quebrou algo é testá-lo e saber COMO testá-lo. Dessa forma, você encontra o bug imediatamente, não no caminho quando se esquece exatamente o que fez quando estava escrevendo o código que quebrava algum recurso antigo.

A razão pela qual isso é diferente da programação do tipo de projeto de cima para baixo mais tradicional é que, nesse ambiente, é a) muito difícil de testar até que você tenha o produto final b) em teoria, você está considerando todos os critérios de design ao mesmo tempo, e portanto, é menos provável que você tome uma decisão de design que quebre as anteriores.


2
Também é importante que futuras alterações incrementais não quebrem a funcionalidade anterior, e os testes de unidade são uma maneira fácil de verificar isso.

11
Eu diria que o teste é absolutamente essencial para o desenvolvimento de software .
Andres F.

@Snowman Testing! = Teste de unidade. Além disso, teste de unidade! = TDD (apenas no caso ...).
Andres F.

@AndresF. verdade, normalmente penso que o teste de unidade é parte integrante do Agile pelos motivos descritos acima. Falha na leitura.

8

Você provavelmente está falando sobre testes automatizados, testes de unidade, testes de integração etc. Estes são mais importantes para o ágil que o manual (com testadores e outros) porque são muito lentos, portanto, não é possível testar todas as pequenas alterações que você faz. Como o agile trata de pequenas iterações rápidas, é muito útil ter testes que verifiquem a correção em segundos ou minutos, em vez de horas ou dias.


8

Se você não possui testes, como você sabe que seu código funciona?

Edit: a afirmação de que os testes não podem provar que o código funciona falha ao definir um termo crucial, ou seja, funciona . O que significa para um programa funcionar? Se você mantiver esse termo vago, não há como provar ou garantir que algum programa funcione. Sempre.

Por outro lado, você pode definir trabalhos como "se comporta de acordo com uma especificação". Agora você pode não apenas usar testes para mostrar que o código funciona, mas os próprios testes podem servir como uma especificação executável do comportamento do seu código. Em outras palavras, um conjunto de testes bem escrito define o que funciona significa.

Essa maneira de pensar também obriga a reexaminar o significado de um bug . Se o seu código passar em todos os testes, não haverá bugs no código. Se, apesar disso, o sistema não se comportar como deveria, então seu comportamento não será especificado corretamente. I. e. o bug está na especificação, definida por testes.

Essa abordagem ao desenvolvimento de software dissocia a especificação funcional de um sistema de sua implementação, o que, de acordo com todos os livros de engenharia de software do mundo, é uma coisa muito boa. Ao mesmo tempo, essa abordagem garante que sua implementação sempre corresponda à especificação funcional.


13
quando os clientes param de registrar relatórios de erros? :-)
gbjbaanb 25/09

3
Você pode provar que está correto. A Engenharia de software de sala limpa é muito semelhante ao TDD, na verdade, mas gerou automaticamente testes estatísticos gerados a partir de especificações e provas.
Jörg W Mittag

11
-1 - "O teste mostra a presença, não a ausência de bugs."
Telastyn 25/09

@Telastyn, Não ter testes mostra a presença de bugs com quase certeza. Por outro lado, um conjunto bem escrito de testes fornece uma especificação executável do que seu código faz.
Dima

Não discordo, mas nenhuma quantidade de testes prova que seu código funciona.
Telastyn 26/09/14

5

Não, não é necessário"

Os princípios do Agile não dizem nada diretamente sobre o teste.

Mas é altamente recomendável

Dado o compromisso da Agile com um processo sustentável, entrega contínua / incremental e qualidade de software, o teste automatizado é a melhor solução atualmente disponível para a maioria dos projetos.

Exceções (como observado por Jörg W Mittag) incluem ferramentas de desenvolvimento comprovadamente corretas, sistemas de metaprogramação que geram código, et al. Mas esses tipos de sistemas são raros.


4

O Agile e o XP tentam evitar o Big Design Up Front . Em BDUF, requisitos estão reunidos, uma especificação formal é criado, em seguida, a codificação é feito, em seguida, o teste é feito. Isso faz sentido para sistemas bem definidos, críticos para a missão e a vida, como equipamentos médicos, sondas espaciais, etc.

O Agile evita esse fluxo porque não funciona bem para problemas que não estão bem definidos, por exemplo "o que quer que as mudanças que o cliente solicite nesta semana". Ainda precisamos de uma especificação formal, para sabermos o que fazer e quando terminarmos, mas, em vez de algum tipo de documento escrito, usamos o código na forma de testes automatizados.

Testes de unidade automatizados são rápidos de escrever, rápidos de executar e muito modulares / desacoplados. Isso os torna uma maneira rápida de especificar e verificar formalmente os requisitos.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.