Quando documentar não é preciso?

O tema da última Mesa Redonda DFTestes de 2009 foi “Quando documentar não é preciso?”, e teve 18 respostas e 7 participantes: eu, Felipe Silva, Milton Vopato, Sarah Pimentel, Rodrigo Almeida de Oliveira, Marcelo Andrade e o Eduardo Gomes.

A discussão foi bem produtiva, e ao longo dela novas dúvidas e assuntos foram abordados sobre documentação em geral. No próximo parágrafo começa o resumo da sétima mesa redonda, e mais uma vez, fica o convite para ler toda a discussão, caso o tema seja de seu interesse. 😉

Quando documentar não é preciso?

O Felipe Silva iniciou uma lista dos momentos que é preciso documentar, e depois eu adicionei dois itens a mesma:

• Necessitar arquivar evidências;
• Arquivar banco de conhecimentos (todos aqueles que servem como consulta para quaisquer tarefas);
• O contrato obrigar;
• Alta rotatividade na equipe;
• Disseminar o conhecimento (nesse caso há outras alternativas também (como reuniões, trabalhar em par), mas a documentação é a forma menos volátil).

Uma segunda lista foi iniciada pelo Felipe Silva, com todos os documento que são necessários em qualquer projeto de testes e aqueles que podem vir a ser úteis em casos separados, e depois adicionei alguns itens:

• Documentos necessários em qualquer projeto:
  • Casos de Testes;
  • Registro de bugs;
  • Relatórios.
• Necessários? Vocês usam? Independente se usam, acham bom ter?
  • Cenários de Testes;
  • Plano de Testes;
  • Estratégia de Testes;
  • Especificação de Projeto de Teste;
  • Especificação de Procedimento de Teste;;
  • Relatório de Sumário de Teste;
  • Relatório de Incidente de Teste;
  • Log de Teste.
• Outros:
  • Plano de automação de testes;
  • Estratégia de automação;
  • Relatório de Encaminhamento de Item de Teste.

Eu entendo que documentar serve para os seguintes fins (pensando em documentação de Teste de Software):

• Ajuda o entendimento do sistema, quando você cria a documentação de Teste de Software, você entende melhor o sistema, e ainda abstrai as informações para o mundo de Teste de Software;
• Compartilhamento de conhecimento com a equipe, se fizer todos os meus testes de forma exploratória como que uma outra pessoa poderá realizar os mesmos testes?
• Transmitir informações para os stakeholders do projeto;
• Gerar uma base histórica, que poderá auxiliar em futuros projetos.

E tudo depende da sua realidade, por exemplo: se o cliente não exige documentação de Teste de Software, você tem conhecimento do sistema sob teste e o prazo é curto. Você pode testar só de forma exploratória, sem documentar os seus testes, e poderá até mesmo passar os defeitos diretamente para os desenvolvedores (informalmente).

Lógico que o exemplo citado acima, não é muito correto e bem extremo. Só que nessas situações você precisa fazer escolhas, e entre garantir a qualidade do sistema sob teste ou garantir que todas as atividades do Teste de Software sejam cumpridas, eu fico com garantir a qualidade do sistema sob teste.

Eu não vejo nenhum problema em documentar, com tanto que essa documentação tenha alguma finalidade, documentar por documentar, é perda de tempo, e por consequência, perda de dinheiro.

Para o Milton Vopato:

A documentação dos testes é fundamental, para melhoria continua e além disso, pensando no dia a dia, para segurança da própria equipe de teste, pois é uma evidência de cobertura dos scenarios propostos.

A Sarah Pimentel compartilhou um pouco da sua experiência com documentação:

Já estive em um projeto de consultoria de testes, onde o nosso papel era analisar requisitos e casos de uso e gerar documentação para realização de testes por uma outra equipe.

Documentos gerados:

• Casos de teste (obvio :))
• Roteiro de testes (em que ordem devem ser executados os testes gerados)
• Massa de dados (listagem de dados necessários para a execução dos testes)
• Matriz de rastreabilidade de testes (o caso de teste gerado refere-se a que/quais caso de uso entregues pelo cliente)
• Registro de desvios (gaps encontrados na documentação enviada)

Em um outro projeto o trabalho foi configurar uma ferramenta (no caso, Quality Center), gerar casos de teste para a aplicação, treinar a equipe de testadores (inclusive para fazer atualizações posteriores no teste).

E já trabalhei em projetos com um MONTE de documentação também. Isso pra dizer que “tudo é relativo” 🙂 O que importa é gerar o que vai ser útil e o que você consegue manter. Não adianta produzir toda a documentação do RUP se você não consegue mantê-la alinhada entre si e se o próprio time não a consulta.

O Rodrigo Almeida expôs a sua opinião dizendo:

Na minha opinião, documentar só por documentar não se justifica. Toda atividade num processo precisa gerar valor. Se não é só pedágio!

Existe um mínimo que é obrigatório no nosso processo hoje: O caso de teste e/ou uma evidência de teste e um relatório de painel de bordo das homologações.

Quando fazemos um projeto aí temos também o Plano de Testes.

Para o Marcelo Andrade, não é necessário documentar quando o documento:

1. Não seja de fato útil, mas precise ser feito apenas por que o processo assim determina;
2. Não é mantido atualizado (de certa forma, uma consequência do item 1);
3. Não é compreendido pelas pessoas para quem ele foi escrito (outra consequência do item 1).

O Marcelo ainda comentou sobre documentos difíceis de serem compreendidos e compartilhou o link para um bom artigo sobre documentação:

Se sua equipe de desenvolvimento gera documentos difíceis de entender, que não atendam ao seu propósito, que estejam sempre muito defasados e não sejam efetivamente utilizados, isso não é valorizar a documentação. Longe disso. Valorizar a documentação é dar real importância aos documentos gerados, fazendo com que eles agreguem valor ao cliente e sejam usados de fato para apoiar o trabalho da equipe.

Volto a indicar este esclarecedor artigo do InfoQ sobre o assunto:

http://www.infoq.com/br/news/2009/08/agile-documentation

Outro link bem legal sobre documentação ágil, é esse abaixo, de um vídeo que o Vinícius Teles fez sobre documentação ágil:

http://blog.improveit.com.br/articles/2008/08/01/documenta%C3%A7%C3%A3o-%C3%81gil

O Eduardo Gomes compartilhou a sua opinião dizendo:

A necessidade de documentação é sempre motivo de debate e gera argumentações apaixonadas, tanto a favor como contra. Quando falamos da documentação dos testes, essa discussão fica ainda mais acalorada, pois muita gente entende que a documentação do sistema já é um “trabalho jogado fora”, quanto mais documentar os testes. É uma visão característica dos desenvolvedores, que estão preocupados em construir as soluções e veem na documentação um entrave ao seu trabalho. E em muitos casos isso é realmente o que acontece.

Mas se observarmos os modelos de maturidade de software, percebemos que a documentação é peça chave no esforço pela melhoria de processos e para a qualidade dos produtos. Sem uma documentação, automatizada ou não, dificilmente conseguimos atingir níveis satisfatórios de maturidade nos processos. Prefiro enxergar a documentação como um investimento e não como um trabalho jogado fora.

Quanto à documentação de testes, utilizamos atualmente, 04 artefatos básicos:

• Plano de Testes (Escopo, riscos, estratégia, ambiente, intervenientes, aprovações, etc);
• Roteiros de Testes (Casos de teste, massa de teste relacionada, especificidades do teste etc);
• Relatórios de Testes (Resultados da execução dos testes, evidências, gestão dos defeitos etc);
• Relatório Final (Resumo dos testes, pareceres, validações etc).

Esse conjunto completo de artefatos é aplicado somente sobre projetos, que possuem um escopo maior de teste e também outros artefatos relacionados ao desenvolvimento, que servem de insumo para a construção da documentação de teste. Em intervenções menores, somente os relatórios de testes são exigidos, principalmente para evidenciar os testes realizados, na maioria dos casos pelos próprios desenvolvedores. Mas tudo isso faz parte de uma estratégia de melhoria dos nossos processos, que deve alcançar níveis mais elevados de maturidade em breve.

Como tornar a documentação do Teste de Software eficaz?

O Felipe Silva acredita que:

As documentações devem ser efetivas, e sou favor de casos de testes diretos e objetivos – sem steps desnecessários à validação, sei que muitos vão discordar de mim, mas assim que é legal (gerar discussões).

Devemos sempre gerar apenas documentações que serão lidas, digo isso porque já vi casos onde são gerados vários artefatos só pra ficar no repositório (o contrato obriga) e no pior dos casos o próprio processo de testes da organização que diz que tal artefato – que não serve pra nada – deve ser gerado só para mostrar para o cliente, e piora, pois o sistema muda por alguma solicitação de mudança ou versão de requerimento nova e o tal artefato fica do mesmo jeito, nem quem escreve se importa em atualizá-lo pois sabe que ninguém irá usá-lo como base pra nada.

Eu vejo que esse é um grande desafio. Acho que o primeiro passo a fazer é listar quais documentos que estão sendo gerados pela equipe, e responder as seguintes questões (deve ter outras):

• Qual o objetivo desse documento?
• O documento está otimizado? (tem apenas os tópicos adequados para o projeto)
• Alguma sugestão de melhoria para o documento?
• Há alguma dificuldade em manter o documento? (ex.: mudanças de requisitos constantes)
• Há alguma ferramenta que possa auxiliar a criação do documento?
• O tempo levado para a criação do documento é o esperado?
• O documento está armazenado em um local seguro e acessível?
• As pessoas estão seguindo algum padrão para a criação do documento?
• Quais são as pessoas que irão utilizar esse documento? A linguagem está adequada com esse público?

Um segundo passo é tornar a documentação “viva”, ou seja, automatização dos testes, sempre que possível e viável. 🙂

O Eduardo Gomes acredita que:

Qualquer documentação deve ser a mais simples possível, mas que permita o registro das informações que a organização considera imprescindíveis. E nessa análise cada organização deve definir sua documentação básica, mas deve também explicitar a seus colaboradores os objetivos a serem alcançados e as estratégias utilizadas, para que consiga da equipe o comprometimento e a motivação necessários. Sem isso, vai ser realmente “trabalho jogado fora”.

Durante a discussão a Sarah Pimentel colocou três novas questões para esquentar o debate.

Eu posso ao invés de criar test cases, basear meus testes nos requisitos ou user stories?

A própria Sarah respondeu dizendo que:

Essa é uma abordagem estranha pra mim. Me sinto mais confortável com a idéia da criação de uma documentação criada para o propósito de teste. Mas considerando que no caso de uso, requisito ou user story tem todos os fluxos (pode-se assegurar isso com revisões da equipe de teste), é uma documentação que poderia servir como base para testes…

Na minha opinião deixar de criar os casos de teste é um pouco perigoso nesses casos, e quando eu digo criar um caso de teste, pode ser tanto um manual (no Test Link), ou um automatizado (no JUnit, por exemplo).

Mas não vejo problemas em basear os testes nos requisitos, até porque eles são a fonte principal, quando escrevemos testes de aceitação, por exemplo. E as user stories dão uma visão geral da funcionalidade, mas só com ela como base, fica difícil explorar a árvore de possibilidades da funcionalidade, geralmente é preciso ter algum outro documento para apoiar ou conversar diretamente com o desenvolvedor.

E se ao invés de requisitos, documentarmos apenas os testes? Colocarmos as solicitações do cliente não como requisitos mas como cenários de teste? Perderíamos alguma coisa?

O pessoal que pratica BDD (Behavior Driven Development), costuma comentar que é possível utilizá-lo para detalhar os requisitos funcionais. Neste caso você já estaria documentando e escrevendo um teste (e a sintaxe do teste é bem fácil de entender, e há ferramentas, como o Cucumber, que até permitem escrever em português).

Acho que não iremos perder, mas corremos o risco de detalhar muito cedo as coisas. E nem sempre isso é possível, pois o cliente também poderá consultar os requisitos, futuramente, e se estiver em uma linguagem muito técnica, ele poderá ter dificuldade de entender.

Em uma abordagem TDD, como fica a criação de documentação de teste? Ela se torna dispensável em alguns pontos? Passa a ser apenas o Unit Test?

Eu vejo que a documentação passa a ser “viva”, pode ser executada a qualquer momento, e o desenvolvedor terá um rápido feedback se a funcionalidade que ele está desenvolvendo está ou não de acordo com a documentação criada (testes).

Em relação ao documentos gerados, normalmente, por uma equipe de Teste, acho que eles continuar existindo (até porque só estamos documentando os casos de testes de forma automatizada), principalmente, se houver uma equipe de Teste de Software no projeto. E ainda haverão os testes manuais, que necessitarão ser documentados, da forma tradicional. E a própria equipe de Teste de Software, pode deixar de criar um caso de teste no Test Link e automatizá-lo no Selenium, por exemplo, e mesmo assim, a equipe não está deixando de documentar.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Fique por dentro das novidades, assine o feed do QualidadeBR.