Início > Processo de Desenvolvimento > Reportando Falhas

Reportando Falhas

Alguma vez alguém já recebeu um e-mail avisando que “está dando pau no sistema” e mais nenhuma informação a respeito? Pois é, fico contente quando me informam pelo menos a tela em que “está dando pau“.

Para reportar um problema para a equipe de desenvolvimento deve-se encontrar uma maneira estruturada de descrevê-lo. Para isso não importa se no processo é utilizada uma ferramenta de issue tracking, como o Jira. Poderia ser até uma planilha – tomara que gestores não me leiam.

Pior que dar uma descrição incompleta do problema é indicar uma solução errada ou um caminho errado para a condução da análise. “Eu acho” ou até mesmo “eu tenho certeza” não existem. Registre apenas fatos e omita comentários pessoais que podem atrapalhar ao invés de ajudar. As únicas informações úteis para o desenvolvedor além dos fatos são as referências a casos de uso e demais requisitos que deveriam ser consultados. Nesse caso não se trata de indicar um caminho errado caso a pré-análise do problema tenha sido bem feita pela pessoa que o reporta.

Sugiro a seguinte estrutura de seções para reportar um problema:

  • Ação executada: funcionalidade que o usuário estava tentando acionar quando a falha ocorreu;
  • Passos realizados: seqüência ordenada de passos acompanhados dos dados utilizados para que se possa reproduzir o problema;
  • Comportamento observado: comportamento do sistema após realizar a ação;
  • Comportamento esperado: comportamento previsto dada a ação executada. Esse comportamento está descrito em algum documento do projeto, como use cases, user stories ou um documento de requisitos qualquer, estruturado ou não. Espera-se que nessa seção seja feita referência ao documento que deve ser consultado. Caso não exista tal documento ou este esteja desatualizado, o que costuma acontecer, deve ser feita a descrição detalhada do comportamento esperado.

Observação: se necessário, devem-se anexar outras informações que você julga relevantes para a reprodução do problema, como um print screen de uma tela.

Exemplo

Ação Executada

Cadastro de um novo pedido de compra de chapas de aço.

Passos Realizados

  1. Selecione o item Chapa de Aço Galvanizado 0,5 x 100 x 200
  2. Informe uma quantidade igual a 10 unidades
  3. Informe o nome do cliente igual a José da Silva
  4. Informe o endereço de entrega igual à Avenida Paulista 1000
  5. Confirme o pedido
  6. Faça uma busca a partir do número do pedido gerado
  7. Visualize os detalhes do pedido

Comportamento Observado

  • A quantidade de chapas de aço pedida é igual a 9

Comportamento Esperado

  • Segundo o caso de uso Cadastrar Pedido, o Vendedor informa a quantidade de chapas de aço e o Sistema armazena essa quantidade;
  • Segundo o caso de uso Consultar Pedidos, dado o código de um pedido o Sistema deve apresentar todos os dados do pedido tal como foi cadastrado.

Note que a proposta de descrição estruturada do problema é isenta de comentários e outras informações irrelevantes que possam confundir o desenvolvedor. São registrados apenas fatos. Note também que para descrever o Comportamento Esperado foi feito um trabalho de pré-análise e validação.

Se o desenvolvedor não tivesse em mãos o comportamento esperado, é muito provável que assumisse o óbvio: se gravar 10 tem que exibir 10. Pode ser que haja alguma regra de negócio que negue essa afirmação. Daí a necessidade de envolvimento do product owner ou pelo menos de analistas

Anúncios
  1. Nenhum comentário ainda.
  1. No trackbacks yet.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: