- 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 (como será 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. As evidências de teste 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)
-
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.
Exemplo 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 documento é 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 é bem 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.
-
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.
___________________________________________________________________________________________________________________
Gostou? Fique ligado no nosso blog que logo logo tem mais!
Não esqueça de deixar seu comentário 😉
Muito bom o artigo, realmente devemos analisar o que realmente será utilizando e não documentação excessiva onde ninguém irá ler, revisar e etc…, a documentação de teste ou de qualquer outra parte do projeto deva ser eficiente, deve ter uma pessoal que será direcionada, onde essa documentação faça sentido para essa pessoa, e não uma documentação onde não sabe nem para quem vai, acho que um dos primeiros passos é identificar para quem será a documentação, porque se não tem responsável para que serve aquela documentação? Temos que filtrar ao máximo pois até mesmo aquela documentação onde a pessoa diz “É fundamental para mim”, no final na verdade ela coloca em uma gaveta e nunca mais ler aquela documentação, o que gera disperdicio de tempo, é um assunto que tem muita discussão e cada equipe deve tomar essa decisão.
Muito bom, parabéns!