E quando não há um processo de teste definido, o que fazer? Parte 2

** DEFININDO UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE **

Dando continuidade ao assunto abordado no post anterior, em termos de processo de desenvolvimento e que contemple a etapa de testes, eu sugiro algo baseado no ciclo PDCA, que considero dinâmico e incremental.

Etapas do Processo de Desenvolvimento em um Ciclo PDCA

Vamos alinhar alguns conceitos utilizados neste ciclo:

•  Release – termo utilizado para designar uma demanda a ser desenvolvida pelo time. Nesta demanda poderá ter uma ou mais funcionalidade. Uma release poderá ter uma ou mais iterações.
• Iteração – termo utilizado para classificar um ciclo de desenvolvimento. Uma iteração poderá contemplar uma ou mais funcionalidades para ser(em) desenvolvida(s).
• Backlog – termo utilizado para designar o estoque de funcionalidades de um projeto.

1. PLAN

1.1. Planejamento da Release
– O analista de negócio revisa a visão do produto, estratégia e objetivos.
– O analista de negócio revisa as datas chave e milestones.
– O analista de negócio apresenta o backlog de produto priorizada.
– O time faz perguntas para entender os requisitos.
– O time estima os requisitos em um alto nível (story points, dias ideais, function points).
– O time estima sua velocidade inicial e/ou capacidade por iteração.
– O time formaliza os objetivos da entrega em um plano de release.
– O facilitador da reunião registra decisões chave, premissas, riscos e/ou questões.
– Consenso de stakeholders é alcançado e o consentimento de prosseguir é dado.

=> O Analista de Teste/Testador participa através…
– Questionamentos para entender as regras de negócio das funcionalidades a serem desenvolvidas pelo time.
– Identificação os critérios de aceitação de cada requisito.
– Estruturação da estratégia de teste da release.
– Realização do planejamento dos testes, onde já é possível identificar os principais cenários de teste para validar as funcionalidades.

1.2. Planejamento da Iteração
– O analista de negócio revisa a visão do produto, estratégia e objetivos.
– O analista de negócio revisa as datas chave e milestones.
– O analista de negócio apresenta parte do backlog de produto priorizada.
– O time faz perguntas para entender os requisitos.
– O time estima os requisitos em um alto nível (story points, dias ideais, function points).
– O time estima sua velocidade inicial e/ou capacidade por iteração.
– O time formaliza os objetivos da entrega em um plano de release.
– O facilitador da reunião registra decisões chave, premissas, riscos e/ou questões.
– Consenso de stakeholders é alcançado e o consentimento de prosseguir é dado.

=> O Analista de Teste participa através…
– Caso tenha surgido alguma dúvida sobre os requisitos durante o planejamentos dos testes, este é o momento de esclarecer!
– Complementa os cenários de teste, se for o caso.
– Realiza a estimativa de teste.
– Identifica a necessidade de massa de dados para teste, ambiente específico, etc.
– Verifica a viabilidade da automação dos testes funcionais e/ou a atualização dos scripts já existentes.

2. DO

2.1. Execução
– Ferramenta de qualidade de software configurada para monitorar a qualidade do código gerado.
– Automatizar sempre que for viável! Tanto testes funcionais quanto unitários.
– Documentação deve ser gerada a medida que o software é criado/alterado.

=> O Analista de Teste participa através…
– Enquanto o desenvolvedor codifica, o analista de testes/testador cria os artefatos de que se façam necessários.
– A medida que as demandas são liberadas pelo desenvolvedor, o analista de testes/testador realiza os testes funcionais, tanto manuais quanto automatizados.
– Reporta os problemas encontrados para o desenvolvedor.
– Refaz os testes para verificar a correção dos problemas reportados.
– Cria/atualiza scripts de testes automatizados, de acordo com o planejamento e estratégia dos testes.

2.2. Acompanhamento Diário
– O time reúne-se durante 15 minutos para compartilhar as atividades realizadas, impedimentos, angústias, onde respondem as seguintes perguntas:
a) O que você fez desde nosso último encontro?
b) O que você está planejando fazer até que nos encontremos de novo?
c) Quanto tempo falta para você concluir a atividade atual?
d) O que, se for o caso, você está encontrando de obstáculos que estão impedindo você de fazer progresso?

3. CHECK

3.1. Revisão da Iteração
– O time verifica as funcionalidades concluídas com o analista de negócio.
– O time identifica qualquer histórias incompletas.
– O analista de negócio move e/ou divide histórias incompletas ou itens de backlog para próxima iteração ou as retorna para product backlog, se não for uma prioridade.
– O analista de negócio fecha a iteração e aceita funcionalidades adequadas.
– O time demonstra o software funcional para as partes interessadas.
– Quaisquer questões em aberto/obstáculos e itens de ação são verificadas e atribuídas.

=> O Analista de Teste participa através…
– Acompanhamento da validação da versão pelo analista de negócio/cliente.

4. ACT

4.1. Retrospectiva
– O time revisa o plano de ação da última reunião de retrospectiva.
– O time revisa o que foi bem durante a última iteração.
– O time revisa o que não foi tão bom ou como planejado durante a última iteração e por que.
– O time analisa os números do projeto.
– O time analisa a causa-raiz da ocorrência de não conformidades e propõe ações de melhoria e/ou preventivas.
– O time identifica as questões mais importantes para focar na próxima iteração.
– O time verifica qualquer impedimento que os impeça de adotar as melhorias no processo.

=> O Analista de Teste participa através…
– Leva para a reunião de retrospectiva os pontos positivos e negativos ocorridos durante a iteração.
– Se prontifica a atuar em algum foco do plano de ação.

Portanto, um processo organizacional, seja do desenvolvimento de software como um todo, seja da etapa de teste, deve ser simples e facilmente repetido. As pessoas precisam ver o valor deste processo e passar a adotá-lo naturalmente. Destaco também a relevância do papel do analista de teste/testador como um facilitador dentro do time, ou seja, terá um papel vital para que a comunicação flua dentro do time. Em times de Scrum, poderá exercer o papel de Scrum Master dentro do sprint.

Não se esqueça: faça babies steps! 😉

E quando não há um processo de teste definido, o que fazer? Parte 1

Logo após a minha palestra na Trilha de Testes do TDC 2012 em Florianópolis, eu recebi um e-mail de uma testadora que havia lido os slides da palestra. Ela queria uma ajuda em como conduzir o desafio que foi dado a ela: estruturar o fluxo de testes da equipe de desenvolvimento. Quem aqui que está na área de Teste de Software já não se deparou com um desafio desses?! Pois então, para quem está começando a trabalhar na área tem uma certa dificuldade de dar o primeiro passo. Em uma sequência de 2 posts, irei explanar sobre como iniciar a estruturação do fluxo de testes e também sobre o processo de desenvolvimento como um todo.

** ESTRUTURANDO O FLUXO DE TESTES **

Vou elencar os pontos que eu acredito que sejam primordiais para iniciar este trabalho. Vejamos:

1. Mapear as atividades realizadas pelo time – quando me refiro ao time, quero dizer desenvolvedor + testador/analista de teste. É muito importante observar a forma de como as atividades são executadas, caso elas existam. Isso nada mais é do que mapear a situação atual, mesmo que ela seja informal.

2. Identificar o tempo do ciclo de desenvolvimento – saber quanto tempo o time leva para analisar, desenvolver e testar a demanda solicitada.

3. Verificar o retrabalho do time durante o ciclo de desenvolvimento – a partir dos registros dos bugs encontrados em uma ferramenta de bug tracking, é possível identificar o índice de retrabalho. Aqui destaco outro ponto importante: classificar o retrabalho! Por exemplo:

a) o time teve um retrabalho por causa de uma análise de requisito que não estava contemplando algumas regras de negócio relevantes.

b) o testador identificou um bug por problemas na codificação.

c) outro bug encontrado por causa de configuração de ambiente.

Como disse, esses são apenas alguns exemplos. O ideal é identificar no contexto de seu projeto o que seja mais relevante classificar!

4. Coletar o índice de não conformidade no ambiente de produção – após a publicação da versão no ambiente produtivo, seria interessante monitorar as ocorrências de não conformidade principalmente se forem oriundas das implementações realizadas na versão publicada.

A partir dessas informações, é possível ter um retrato atual do time e identificar pontos de melhoria serem propostos. Crie um plano de ação para registrar a sugestões! Se uma das sugestões é elaborar um processo de desenvolvimento, comece por algo simples e intuitivo! Não pense em modelos de processos, se sua empresa possui projetos de curto e médio prazos. As pessoas têm que enxergar valor no processo, para que ele consiga ser institucionalizado. Ter um processo muito burocrático não é uma boa ideia, pelo menos não neste início de trabalho.

Outro ponto é a questão das ferramentas para a parte dos testes. A primeira ferramenta a ser definida é de bug tracking para registrar o retrabalho e não conformidades em produção. Depois temos a questão da gestão do artefatos de teste. Estes poderão ser elaborados, inicialmente, em formato de planilhas e/ou arquivos.doc. Caso depois optar por utilizar uma ferramenta, seria interessante que estes artefatos pudessem ser importados. No mercado temos diversas ferramentas open source e pagas. Veja a que melhor se adapta à sua realidade.

Gerar métricas é outro ponto importante! É necessário medir para saber como o time está e no que pode melhorar para visar a melhoria contínua. São exemplos de métricas:

• número e/ou índice de não conformidades no ambiente de produção;
• número e/ou índice de retrabalho durante a iteração;
• número de requisitos entregues por iteração.

Sobre a automação de testes funcionais, vale destacar que nem sempre haverão funcionalidades passíveis de automação. Considero importante a priorização das funcionalidades e classificá-las a partir da análise de impacto dentro do nicho de negócio. O que isso significa? Criar testes automatizados dos pontos mais críticos do sistema! E se o projeto é novo? Pode-se considerar a automação de testes de funcionalidades mais estáveis.