Um estudo de caso de especificações ativas de requisitos de software

Olá a todos!

Este post é apenas para compartilhar um trabalho de minha autoria sobre o uso de testes de aceitação automatizados utilizando as ferramentas Concordion e Selenium num cenário de um projeto real.  Este trabalho foi submetido a um congresso interno na empresa onde trabalho.

A propósito, eu apresento um case similar, de um exemplo em poucos minutos, em minha palestra sobre BDD e testes automatizados.  Interessou?  Basta entrar em contato.

Logo

Clique no logo para fazer o download do trabalho.

PS: Reproduções são permitidas desde que citada a fonte.

Se você não testa, você não é ágil!

O colega Robson Pelegrini reportou na lista [scrum-brasil] uma situação que é comum, principalmente em equipes que estão iniciando no desenvolvimento ágil de software e que (com a devida autorização) transcrevo abaixo:

Pessoal,

Gostaria de saber como vocês tratam a questão dos bugs que surgem dentro do SPRINT, por exemplo:

  • Criam um item no SPRINT BACKLOG, “correção de bugs”
  • Bugs é responsabilidade do time concertar, não podendo esse impactar na entrega do SPRINT

Acredito que a partir da 1ª entrega feito ao PO, temos o que podemos chamar de “legado”, e então começam a surgir bugs e mudanças de requisitos e funcionalidades que geralmente afetam o planejamento feito para o próximo SPRINT.

- Isso costuma ocorrer com vocês ? Como vocês lidam com essas situações ?

Necessário pontuar algumas coisas num cenário como este.  Vamos a elas.

O QUE VEM A SER UM “BUG” DE SOFTWARE?software-bug-03

Como seres humanos, todos estamos sujeitos a erros.  Assim, mais ainda quando estamos lidando com um produto em desenvolvimento, ou seja, que está sendo construindo.  Muitos projetos de software mantém dois ramos do produto –um estável e um em desenvolvimento– justamente para diferir a quantidade de bugs em potencial que podem estar contidos no produto.

Se por um lado tudo isso é verdade, por outro, quando tratamos de desenvolvimento ágil de software, deve-se partir da premissa de que a cada iteração no ciclo de desenvolvimento um item de valor deve ser entregue ao cliente.  São os releases curtos.

Isto posto, cabe nos perguntarmos: afinal o que é um “bug” de software?

Continue lendo