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.

Anúncios