1. Minimize a sua documentação

Não crie documentos só porque é uma prática da empresa, se você não sabe realmente onde ele será empregado (utilizado, quem irá ler o documento etc).

Criar documentação “só por criar” gera um custo muito alto, visto que temos sempre “pouco” tempo para uma entrega. Logo, devemos criar somente entregáveis utilizáveis. Se o documento que você está criando não é utilizável interna ou externamente, ele pode ser removido.

Se há documentos que você precisa criar por conta de alguma legislação, obviamente, crie! Mas não se esqueça que este deve ser estimado e priorizado (sim, ele vira uma tarefa) e precisa fazer parte da sua Definição de Pronto (DoR).

Exemplo prático referente a teste de software – Evidência de teste

Muitas instituições financeiras necessitam documentar as evidências de teste, que são prints de telas, de partes estratégicas da aplicação, que são colocadas com uma descrição. É muito comum criarmos evidências de teste quando encontramos bugs para reportar a uma pessoa/equipe quando este não pode ser corrigido imediatamente, mas também é uma prática documentar os cenários de sucesso por conta de legislações vigentes em instituições financeiras (Sox).

2. Mantenha a documentação sempre simples

Criar gráficos, tabelas, diagramas coloridos e qualquer outro apelo visual que só servirá para “deixar o documento mais bonito” e sem informação efetiva, ou com muita informação, só faz você perder tempo. Seja simples e direto no documento. Ninguém gosta de perder tempo (horas) lendo algo que poderia ser absorvido em minutos.

Exemocumplo prático referente a teste de software – Plano de teste

Antigamente (não muito tempo atrás) e até hoje muitos testadores mesmo em times ágeis continuam criando documento de Plano de Teste em um padrão/template conhecido da IEEE 829 (referente a documentação de teste). O dento é muito extenso, possui vários tópicos e não é nada direto, ou seja, uma perda de tempo precioso para o time.

Agora pense comigo: o testador (ou o papel deste) não planeja os critérios de aceite com vocês (time)? Já não está saindo o planejamento ai? Precisa de documenta para isso? Há alguns casos, obviamente, onde iremos fazer um planejamento prévio como por exemplo a aplicação de testes de Performance, Carga e Stress. Mas no dia a dia, o documento é pouco utilizado e, mesmo que você crie, foque em pontos-chave e não o deixe extenso.

Sugiro a leitura da sessão Test Planning, do Livro Agile Testing.

3. Documente somente quando necessário

Focar na criação de diversos documentos que você necessita ao longo do tempo não é uma boa ação (big-requirement-upfront). A documentação de teste deve ser criada por demanda e, se tiver necessidade, por partes. O tamanho da documentação também importa. A documentação tem que ser objetiva, mas não pode habilitar o contexto da comunicação como em uma User Story: o documento de testes deve ser entendido por todos os membros do time e agentes externos (stakeholders) para que todos tenham um exemplo real de como a funcionalidade/requisito/regra deve funcionar.

Exemplo prático referente a teste de software – Critérios de aceite descrito como especificação por exemplos

Uma documentação obrigatória para habilitar o entendimento dos requisitos, guia do desenvolvimento e validação pelo usuário final é o Critério de Aceite. Ela é criada geralmente em conjunto com o time e o cliente.

Este pode ser escrito de diversas formas. A mais recomendada para o entendimento por todo time é através da Especificação por Exemplos.

Através dela podemos, de uma só vez, informar como será o detalhe do requisito em termos de utilização mais o exemplo de dados que utilizaremos.

Uma forma comum é adotar a escrita dos critérios de aceite através do Ghekin (Given, When, Then). Abaixo um exemplo:

• Dado que eu estou na página inicial da Adaptworks;
• Quando eu pesquisar pelo treinamento “Agile Testing”;
• Então o treinamento “Agile Testing” é apresentado;
•  E o treinamento “Agile Testing Automation” é apresentado.

Exemplo prático referente a teste de software – Plano para testes de performance

O plano para a execução dos testes de performance é um exemplo de uma documentação de teste evolutiva ao longo do projeto. Vamos pegar o exemplo onde precisamos executar testes de performance antes da entrega da release. A cada iteração iremos planejar quais serão os fluxos criados para o script de teste, coletar a massa de dados necessária, conversar com o pessoal de infraestrutura para ter um ambiente suportado ou mesmo o ambiente de produção, aplicação de monitores em diversas partes da arquitetura etc…

Isso é muito difícil de fazer em apenas uma iteração, onde dividimos todas as tarefas referente a esta ação em diversas partes.