Precisa de ajuda para escolher o seu
treinamento ou tem alguma dúvida?

Teste Antes, Valide Depois

Test Driven Development é uma das práticas do eXtreme Programming, uma das metodologias precursoras de métodos ágeis. O livro de eXtreme Programming é de 2000, um ano antes da criação do Agile Manifesto (e o termo Agile).

Times ágeis fazem TDD. Isso significa que os testes são escritos antes do código funcional. Ou seja o código está pronto quando a versão atualizada do produto (com a nova funcionalidade ou história do usuário) passa por todos os testes do produto.

Todos os testes do produto, nesse momento, são: (1) os testes que validam que o requisito em questão foi alcançado e (2) os testes de regressão, aqueles que confirmam que todas funcionalidades anteriores a essa continuam funcionando.

A grande maioria dos testes de regressão são testes automatizados. Isso gera uma confirmação, em pouco tempo (minutos geralmente) de que todo o produto está ok.

Mas, até hoje, eu nunca vi um local com 100% de automação, onde não exista uma pessoa, um ser humano, realizando algum tipo de validação mesmo após todos testes automatizados passarem. Geralmente, essas pessoas são chamadas de testadores.

Alguns times não possuem pessoas testadores, e tal validação é realizada pelas pessoas desenvolvedoras e/ou o PO. Mas, alguns times possuem pessoas testadores, que além de ajudar a analisar o trabalho, ajudar os desenvolvedores com os critérios de aceite, também fazem algumas tarefas de validação manual e exploratória para confirmar o estado atual desejado do produto.

Na Lean Inception, quando o facilitador pede “todas as tarefas que precisam ser realizadas para ter as funcionalidades em produção”, o squad considera o tempo de: preparação dos dados de teste, automação dos cenários de teste, scripts de integração e automação. Ou seja, muito da preparação e validação do trabalho já está comtemplado no ˜tempo de desenvolvimento˜

Puxe, Não Empurre

Times ágeis não empurram trabalho adiante. Ao invés, o trabalho é puxado da etapa mais próxima ao fim para a etapa anterior.

Por exemplo, pessoas desenvolvedoras em times ágeis evitam acumular trabalho para ser validado depois. Assim que um trabalho de desenvolvimento acaba, as pessoas desenvolvedores tentam colocá-lo para validação. Mas, caso já tenha muita coisa na fila para validação, ao invés de empilhar mais uma tarefa para validar, as pessoas desenvolvedoras se oferecem para ajudar com a etapa de validação. Dessa forma, o time (todos juntos) resolvem o gargalo de validação, mantendo um sistema puxado saudável.

Ao trabalhar desta forma – time multifuncional e com sistema puxado –, a etapa de validação puxa o próximo item ao invés das pessoas desenvolvedoras empurrarem e empilharem trabalho.

Gostou deste conteúdo?

Participe do Treinamento Lean Delivery com Métricas Ágeis
Participe do Treinamento Lean Inception

Paulo Caroli

Paulo Caroli é um apaixonado por inovação, empreendedorismo, produtos digitais, processo, pessoas e transformação. Como autor do best-seller “Lean Inception” e facilitador de workshops estratégicos, sua contribuição tem sido fundamental para o avanço de práticas ágeis em diversas organizações. Como autor, palestrante, consultor e facilitador, Caroli já ajudou muitas pessoas, times e organizações a desbloquear ideias e aprimorar a forma de trabalhar, inspirando muitos a buscar o sucesso em suas próprias trajetórias profissionais.

Nenhum resultado encontrado

A página que você solicitou não foi encontrada. Tente refinar sua pesquisa, ou use a navegação acima para localizar a postagem.

Pin It on Pinterest