Zero documentação, o que testar?

Quando você é contratado ou alocado em um projeto, a maioria das pessoas esperam atuar em um algo novo, usando tecnologias e linguagens de programação novas. E quando isso não acontece bate um desespero, mas calma, vejam como eu passei por isso com algumas técnicas e ferramentas.

A documentação é importante, mas não é mandatória para você planejar e iniciar testes, nesses projetos em fase de manutenção ou legado. Não é viável parar as atividades e começar a escrever requisitos. Porque você pode deixar de entregar alguma demanda importante relacionado a aplicação.

Minha experiência….

Quando fui alocada para um projeto assim, tinha um documento de plano de negócio e plano de teste que foi escrito há alguns anos e hoje está desatualizado, além de páginas na wiki. Então eu e o time adotamos boas práticas como: iremos criar um requisito novo para um pedido de alteração no software ou uma solicitação de uma nova feature vinda do cliente.

Durante as eventuais demandas, como por exemplo um bug encontrado, o desenvolvedor registra a análise do bug em uma ferramenta compartilhada com o time e eu crio uma documentação em forma de caso de teste. Nesse momento é possível entender mais o funcionamento da aplicação.

Outra forma de documentação que usamos foi criar uma página de passo a passo dos fluxos mais importantes do sistema, como por exemplo:

• Caminhos críticos;
• Fluxos que o cliente usa com bastante frequência;
• Fluxos que constantemente ocorrem bugs etc.

Com isso temos documentações informais que agregam valor ao time.

Como testar sem documentação…

Muitas vezes eu vou até o desenvolvedor ou quem já trabalhou no projeto (ainda existem algumas pessoas) para levantar informações e entender o que é o requisito. Olhar o código também ajuda a compreender as regras de negócio. Essa conversa é muito benéfica para colher informações para o teste.

Podemos usar várias estratégias de testes quando não há documentação, como por exemplo:

• Heurísticas (campos obrigatórios, interrupção de ações, quebra de fluxos..);
• Testes baseados em riscos;
• Teste exploratório que é muito útil quando tem pouca ou nenhuma especificação.

Conclusão

É possível realizar testes sem documentação suficiente em um projeto. Diante dessa situação podemos colaborar com time evangelizando para fazer uma documentação útil. E não é só Product Owner, Analista de Requisitos ou Negócio que devem escrever documentação, a colaboração é do time, tanto desenvolvedor ou QA podem fazer uma documentação informal que agreguem valor e que seja útil para o time. Assim quando chegar alguém novo no projeto, você ajudará na curva de aprendizado dele(a). Lembrando que ter uma documentação completa e atualizada poderá ajudar muito no desenvolvimento e nas atividades relacionados ao QA, e assim aumentar a assertividade dos mesmos.

Referência:

https://medium.com/@juliodelimas — Julio de Lima

Heurísticas de testes de software: o que são e seus benefícios — Gabriel Santos

Testes Baseados em Riscos (Risk-Based Testing) — Gabriel Santos

Why Use Heuristics in Software Testing? — Conor Fitzgerald

Test Heuristics Cheat Sheet: Data Type Attacks & Web Tests — Elisabeth Hendrickson, James Lyndsay e Dale Emery

What is Exploratory testing in software testing? Examples, When/How to do, Agile