[Tradução] Lutando contra a má documentação de testes

Olá!

Esse post é uma tradução do post Fighting Bad Test Documentation do James Bach.

Com minha opinião no final (só para não falarem que eu só traduzi rs).

“Muitas pessoas que eu ensino parecem estar sob pressão para criar mais documentos para descrever os seus processos de teste. Mas documentar não é testar, é uma das principais distrações do teste.

Algumas pessoas vão dizer “James Bach odeia documentação!”. Não, eu não odeio. Eu odeio desperdício. Eu odeio trabalho tedioso de escritório, que sem necessidade interrompe um trabalho intelectual produtivo e interessante. E você devia odiar também.

Eu sou um escritor, “pelo amor de Deus” (não conheço tradução melhor para cryin’ out loud). Eu gosto de documentação, quando é a solução para um problema importante, e não apenas uma obsessão da gestão. Mas se você está indo rumo a uma documentação de testes concisa (esboços, matrizes, uma página de referência e outros formatos minimalistas) você pode precisar de ajuda para persuadir a gestão e seus colegas.

Eis algumas ideias:

  • Mostre para a gestão quantos testes vocês estão deixando de fazer devido ao tempo gasto com documentações.
  • Mostre para a gestão como alguns tipos de testes não são feitos por sempre difíceis de documentar (teste exploratório, cenários de testes complexos costumam cair nessa categoria). Esse inclusive é o maior efeito inibidor em excesso de documentação, especialmente na área de dispositivos médicos. Eu continuo vendo documentação de testes médicos que é simplista em toda sua obesidade , até o ponto da quase inutilidade.
  • Observe de perto o que os testers estão fazendo e perceba que eles não estão nem seguindo a documentação (Na minha experiência como consultor que acompanha processos de teste, eles não costumam seguir).
  • Demonstre o poder de testes exploratórios (com a  aproximação de uma documentação mais leve). Um dia de teste exploratório costuma ser o suficiente para achar o que demoraria para encontrar seguindo o processo de uma documentação detalhada.
  • Demonstre o valor da documentação concisa.
  • Considere documentar em level de atividades de teste ao invés de casos de teste.
  • Considere uma documentação automática (via log de arquivos produzidos durante os testes, ou via uma uma ferramenta de log externa, por exemplo “Spector”.
  • Faça a pergunta “O que exatamente estamos conseguindo com nossa documentação?” Não aceite respostas teóricas. Por exemplo, uma resposta típica é que a documentação protege a empresa dos efeitos nocivos da rotatividade de funcionários. Mas protege mesmo? Pela minha experiência, provavelmente não. Tem uma teoria baseada na ignorância, de como as pessoas aprendem na vida real, novos testers aprendem o que precisam saber utilizando o produto por si só, e conversando com as pessoas ao seu redor. Na minha experiência, testers alcançam uma boa velocidade em poucos dias no máximo. E na minha experiência, a documentação de testes costuma ter uma qualidade tão ruim que é melhor ignora-la do que segui-la. Você tem que seguir pela sua própria experiência, é claro. Estou apenas sugerindo que você questione e tenha suas próprias decisões.

Eis alguns livros sobre documentação de testes que podem te ajudar nesse caso:

Uma documentação pesada costuma ser consequência de gestores e testers que não estão pensando nas razões pelas quais estão fazendo isso. Eles ouviram que documentação é bom, mas não pararam para pensar no custo da documentação, ou observar como a documentação é realmente usada (ou mais normalmente, ignorada).”

Fim da Tradução.

Meus comentários sobre o tema:

Bem…eu já acredito na importância da documentação, como já mencionei anteriormente no post “Um plano infalível” temos alguns motivos para usa-la, mas o que eu entendo que o James reclama é sobre o excesso de detalhes na documentação e o desperdício de tempo em cria-las.

Mas afinal, usar ou não a documentação?

Como costumo dizer…. “Depende”, a documentação ajuda e muito um analista inexperiente (por exemplo eu) a não ficar perguntando a cada 5 segundos se aquilo que o sistema está fazendo era o esperado, mas ao mesmo tempo se eu for ter que pesquisar um detalhe em um documento de 170 páginas….bem vai ser bem mais rápido perguntar para alguém que tenha maior conhecimento do projeto, vai muito do bom senso do analista, e vale a pena lembrar a frase do Tio Sam,  “Time is Money!”, essa frase realmente faz sentido, o tempo utilizado por você seja pesquisando, perguntando ou criando a documentação é o tempo que será cobrado do cliente, o que encarece o projeto (e obviamente isso não é bom), então costuma ser melhor procurar a melhor opção que irá economizar mais tempo ao longo do projeto.

E seja lá o que for fazer, seja uma documentação, ou execução de teste….faça o melhor trabalho possível, vale mais a pena gastar um dia executando um serviço bem feito, do que concluir o mesmo serviço em 4 horas, mas o resultado ser incompleto, pois isso irá gerar dúvidas e re-trabalhos.

E qual a opinião de vocês quanto ao assunto? Gostariam de compartilhar conosco?

Anúncios

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