Melhorando a Confiabilidade do Sistema Durante a Sprint

Oi pessoal,


Vamos falar de como podemos adaptar testes de software junto com a execução da Sprint. Neste texto não vamos falar sobre TDD e sim sobre o processo clássico de testes de software com uma adequação ao desenvolvimento ágil.

No planejamento da Sprint quando a equipe se reunião com o Product Owner é realizado o processo de analise de sistemas, nesta atividade a equipe analise cada Cartão de Historia e faz ANOTAÇÕES sobre os itens relevantes desta conversa. Estas anotações são registradas como um Histórico, para que exista uma aderência as necessidades que devem ser desenvolvidas.

Nesta mesma etapa (Planejamento da Sprint) entra o Analista de Testes, onde para cada Cartão de Historia ele elabora cenários de testes que o sistema vai ser submetido. Com as informações levantadas na Conversa com o Product Owner e os cenários de testes que o sistema vai ser submetido a equipe de construção passa a desenvolver o sistema.

Mas devemos deixar os desenvolvedores aguardando a relação de testes que o Analista de Teste vai criar? A resposta é não, o desenvolvimento é iniciado, pois sempre é possível realizar varias atividades ao mesmo tempo na Sprint que vai ser executada.

Para cada Cartão de Historia desenvolvido ou funcionalidades do Cartão de Historia identificadas nas Conversas com o Product Owner é possível realizar liberações para um testador de software. Este testador também faz parte da Equipe e o seu trabalho é realizar os testes durante a Sprint.

Alguns testes vão ser manuais e outros automatizados, vai depender do nível de construção do software já realizado durante a Sprint.

A união dos integrantes da equipe trabalhando juntos permite um conhecimento cada vez maior do negocio e desta maneira aumenta o grau de confiabilidade do sistema e possibilita a visão cada vez mais critica da equipe de tudo que esta sendo feito.

Deixarmos o testador como uma equipe a parte faz com que tenhamos uma perda de tempo com a transferência do código desenvolvido para a equipe de testes, a busca por erros pela equipe de teste e o retorno dos erros para a correção pela equipe de desenvolvimento, o que acarreta um gasto de tempo na execução deste processo.

Ágil é também evitar o desperdício e podemos diminuir a perda do tempo com a inserção do testador dentro da Sprint, pois os erros são identificados e corrigidos durante o desenvolvimento. Evitamos uma perda de tempo com o processo de passagem de Bastão de uma equipe para a outra, simplesmente fazendo a equipe de desenvolvimento e de teste de software trabalharem juntas.

Estar junto é muito importante, gera o espírito de equipe e comprometimento entre as pessoas.

Faz com que os problemas passem a ser NOSSOS problemas e não problemas da outra equipe.

Mas os testes no processo clássico também ocorrem após a Sprint estar terminada. Também temos os testes antes do termino da Sprint, para que o Product Owner receba um produto sem erro na Sprint Review.

Também é realizado testes de maneira clássica nas entregas de Releases, onde os integrantes da equipe de teste realizam uma checagem geral nos Cartões de Historia que fazem parte do sistema a ser entregue.

O ultimo ponto não menos importante é que a equipe junta permite uma gestão de escopo e controle dos requisitos de maneira mais sincronizada, quando temos equipes separadas existe a necessidade de uma comunicação melhor para alertas de alteração de escopo ou acordos realizados sobre funcionalidades. Uma equipe junta, próxima, permite com que esta comunicação ocorra de maneira mais fácil.

Um exemplo de como funciona o cenário de execução é:

1) Planejamento da Sprint

2) Identificação dos Testes para os Cartões de Historia / Inicio do Desenvolvimento

3) Testes sobre os Cartões de Historia desenvolvidos (Casos de Testes criados pelo Analista de Testes, Testes identificados pelo Analista de Testes para cada Cartão de Historia, Testes identificados pela equipe de desenvolvimento, Testes identificados pelo próprio testador)

4) Testes sobre a Sprint Terminada (Execução Manual e Execução Automatizada)

5) Sprint Review

Dica: Nem sempre temos uma equipe de testes nos nossos projetos, mas quando temos, temos que potencializar a busca preventiva de falhas e sem perder tempo com troca de Bastão entre as equipes. União, essa a palavra.

Amplexos,

Abu