Automação de Teste de Software – Parte 3 – Priorização do Backlog

Na série de dicas para automação de testes de software, baseados na postagem Automação de Testes de Software é só record and play #SQN, já falamos sobre:

1) Definição de ferramentas

2) Definição do Ambiente de teste

Dando sequência no que chamei de diretrizes para automação, o próximo passo abordado será:

3. Priorização do Backlog de Automação

Bom, para priorizar um backlog nós precisamos primeiro criá-lo, certo?

Você pode pensar no conceito de um board de scrum, listar funcionalidades que precisam ser desenvolvidas como “To Do” com objetivo que ao finalizar cada funcionalidade você tenha movido a mesma para “Done”, para controle do andamento do desenvolvimento.

 

scrum-process-board

Exemplo de Scrum Board[1]

Nessa etapa serão listadas as funcionalidades do sistema que para a criticidade do negócio seria interessante que existisse uma suíte de testes automáticos rodando em uma integração contínua.

Pode ser que sinta um certo desconforto ou dificuldade para fazer essa listagem. Para isso, poderia trocar uma ideia com o time e com alguém mais ligado a produto\negócio para levantar tais funcionalidades. A ideia é trazer mais a visão do que é importante para o negócio não somente focando no lado mais técnico.

Com a listagem definida, o próximo passo, também em conjunto com a equipe, seria priorizar a lista de backlog para ordenar por quais itens serão iniciados a automação do software que está trabalhando.

Agora é o momento de discutir e definir qual critério de priorização será adotado, algumas abordagens seriam:

  • Criticidade para negócio – Priorizar pelas funcionalidades que não mais críticas para o negócio, que não podem deixar de funcionar, manter testes de regressão dessas funcionalidades seria de extrema importância.
  • Nível de dificuldade – Priorizar pelas funcionalidades mais fáceis ou mais difíceis de automatizar.

Com relação a essa abordagem o que pode ser ressaltado em um cenário que, por exemplo, a equipe é nova, é o primeiro contato deles com a ferramenta ou com automação, estariam em um período de capacitação. Sendo assim, essa opção poderia ser uma boa alternativa para iniciar a suíte de testes por entregáveis mais fáceis e menores.

Dessa forma, a familiaridade da equipe com a ferramenta também vai aumentando, e a medida que o nível de dificuldade for crescendo também, diminuindo o impacto que poderiam sofrer. Quando se depararem com alguma funcionalidade mais difícil conseguiriam levar mais facilmente, ou seja, a priorização poderia ser do nível mais fácil para o mais difícil.

  • Funcionalidades mais utilizadas – Priorizar pelas funcionalidades mais utilizadas pelos clientes, ou seja, se são usadas a chance de ser identificado algum bug pelos clientes seria maior, ou até mesmo as funcionalidades que estão sempre aparecendo no ranking do atendimento. A ideia é minimizar isso, poderiam seguir essa abordagem também.

Você pode estar se perguntando nesse instante qual seria a importância dessas definições. Por que eu preciso de uma backlog e preciso priorizá-lo?

Por questões de organização e manter o foco no objetivo final que é a sua suíte de teste rodando na integração contínua com 100% das funcionalidades automatizadas essa é uma forma de mapear todo trabalho que terá pela frente e usar esses pontos a seu favor na etapa do planejamento.

É importante ressaltar que quando cito “100% das funcionalidades automatizadas” o nosso 100% são as funcionalidades listadas para o backlog de automação.

Sabemos que em ambientes corporativos encontramos cenários complexos, portanto, caberia uma analise mais detalhada sobre o contexto do projeto para identificar a melhor abordagem de priorização. Nosso objetivo aqui foi apenas sugerir pontos de partida.

E então, vamos priorizar?

Referências:

[1] http://www.slideshare.net/PowerPoint-Templates/scrum-process-powerpoint-ppt-slides

Links:

[1] http://www.matera.com/br/2015/07/10/automacao-de-testes-de-software-e-so-record-and-play-sqn/

[2] http://www.matera.com/br/2016/04/13/automacao-de-teste-de-software-parte-1-definicao-de-ferramentas/

[3] http://www.matera.com/br/2016/05/10/automacao-de-teste-de-software-parte-2-definicao-do-ambiente-de-teste/

Por ARIANE FERREIRA IZAC

Analista apaixonada por testes, dançarina, corredora e colecionadora de viagens! Filha de peixe (jornalista) peixinho (blogueira) é. Meu grupo no LinkedIn só poderia ser "Diário de uma paixão: Teste de Software"

Postado em: 29 de julho de 2016

Confira outros artigos do nosso blog

Matera participa da 9ª edição do meetup DevTests Campinas

03 de setembro de 2018

Ariane Ferreira Izac

Teste de mutação com PITest

24 de agosto de 2018

Julio Cesar Consolini

Introdução ao Dev-Test Pairing

13 de junho de 2018

Caio Rizolli

Falando sobre Teste de Intrusão (ou PenTest)

03 de abril de 2018

Jacqueline Costa

Deixe seu comentário