** 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! 😉
Divã de uma Tester 