Testar sem documentação é possível?

Essa é a minha contribuição para o livro do DFTestes.
Falei um pouco sobre a problemática da falta de documentação para a equipe de testes.

Confiram outros capítulos na página do livro.

1. Introdução

De acordo com o RUP, caso de teste "é a definição (geralmente formal) de um conjunto específico de inputs de teste, condições de execução e resultados esperados, identificados com a finalidade de avaliar um determinado aspecto de um item de Teste-alvo". Duas disciplinas da Engenharia de Software provêem informações para criação dos casos de teste. São elas: Engenharia de Requisitos e Projeto.

De acordo com o IEEE, a Engenharia de Requisitos é o processo de aquisição, refinamento e verificação das necessidades do cliente. Dentro das diversas metodologias de desenvolvimento há maneiras distintas de documentar requisitos. No RUP, o principal documento gerado, que é utilizado pela equipe de teste, são os Modelos de Caso de Uso; já nas metodologias ágeis, um documento mais comum é o conjunto de User Stories. Na prática, muitas equipes não têm nem os Casos de Uso e nem as User Stories, mas sim, descrições em alto nível dos requisitos, sejam elas por escrito ou não.

A disciplina de Projeto, por sua vez gera documentos complementares às especificações de Requisitos. Nessa etapa, a estrutura interna do software é descrita através de diagramas. A utilização da linguagem UML é bastante recomendada na geração desses diagramas. Exemplos de diagramas de projeto são Diagramas de Estados, Diagramas de Seqüência e Diagrama de Atividades, entre outros.

Essa documentação serve como apoio para a elaboração dos testes. Todas elas são de grande valia para o analista no seu projeto de casos de teste. Mas e se o analista não as tiver? É possível, mesmo assim, testar? Essa é a pergunta tema da Nona Mesa Redonda do DFTestes.

Esse tema nos fez refletir sobre a necessidade da documentação para o teste. Primeiramente não vamos confundir necessidade com importância. Denotativamente o termo necessidade significa uma obrigação imprescindível, enquanto que importância ou relevância significa valor.

As participações nessa mesa redonda são freqüentemente utilizadas no texto que segue para expressar a opinião da comunidade sobre o assunto.

2. Testes Exploratórios

É possível sim testar sem scripts e isso já não se pode chamar de novidade. O termo "testes exploratórios" foi citado pela primeira vez por Cem Kaner em seu livro Testing Computer Software (1999).

Segundo James Bach, testes exploratórios são simultaneamente um aprendizado, um projeto e uma execução de teste. Através da profunda exploração das habilidades de ouvir, ler, pensar e reportar eficazmente, os testes exploratórios podem trazer informações muito importantes de maneira tão ou mais produtiva que os testes baseados em casos de teste. A falta de um script a ser seguido tende a potencializar essas habilidades.

3. Escolas de Teste

Sobre a documentação em que iremos embasar a criação dos casos de teste, o Jorge Diz disse: "não coloquemos todas as nossas fichas na documentação do sistema. Com certeza, é possível testar sem documentação formal: pode ser mais ou menos eficaz, dependendo do contexto. E sempre devemos lembrar que o documento mais atualizado é sempre o próprio sistema sendo testado."

O contexto! Esse é o grande segredo dessa discussão. A eficácia do seu teste pode ou não ser impactada pela falta de documentação considerando diversos cenários. É papel do analista de testes sinalizar até que ponto ele consegue aferir a qualidade do sistema com as ferramentas (documentação, especialista, etc.) que lhe foram dadas.

Dentro das Escolas de Teste, veremos que de acordo com as características de cada escola (um contexto), o tema "testar sem documentação é possível?" é tratado de maneiras diferentes.

De acordo com Pettichord (2007), uma escola é definida por afinidades intelectuais, interação social e objetivos comuns. São compostas por uma hierarquia de valores, técnicas, padrões de crítica, instituições organizadas e vocabulário comum.

Existem cinco escolas de teste e suas visões são:

Escola Analítica: o teste deve ser rigoroso e técnico, com base na academia
Escola Padrão: o teste é uma maneira de medir o progresso com ênfase no custo e padrões repetíveis
Escola da Qualidade: enfatiza o processo e policia os desenvolvedores
Escola baseada em Contexto: enfatiza as pessoas, procuram bugs com os quais os clientes se importam mais
Escola Ágil: usa o teste para provar que o desenvolvimento está completo. Enfatiza o teste automatizado

Sobre os testes sem documentação, são a favor:

Escola baseada em Contexto: "Faça o que puder para ser útil. Faça perguntas se necessário. Desencave especificações escondidas."
Escola Ágil: "Conversas são mais importantes que documentação"

E são contra:

Escola Analítica: "É impossível"
Escola Padrão: "Algum tipo de documentação é necessária"
Escola da Qualidade: "Force os desenvolvedores a seguir o processo"

Como cada escola vive um contexto e analisa o teste de acordo com os seus cenários, cada uma expressa uma visão diferente da possibilidade de testar sem documentação. Na visão geral dos participantes da discussão, testar sem documentação não é impossível, mas essa abordagem também não foi defendida como a melhor prática. A comunidade do DFTestes parece ter uma tendência muito próxima a da Escola baseada em Contexto, entendendo que não devemos olhar as nossas dificuldades de documentação como muros intransponíveis, mas como empecilhos que devem ser vencidos.

4. Reflexões da Mesa Redonda

"À medida que os sistemas se tornam mais complexos, os riscos se tornam maiores, chegando ao ponto no qual ninguém conhece o que há no sistema. Isto é ruim não só para o teste, mas também para todas as fases anteriores do desenvolvimento.

Falando de casos de uso ou similares, um dos problemas comuns de quem não tem essa documentação é o de não saber o que testar. Recentemente fiz uma análise de cobertura de código em um programa de pedidos e concluí que ao incluir um pedido neste sistema com o máximo de opções que consegui informar, não cobri nem 20% do código. Se você não tem nada para consultar, como testar os outros 80% de forma eficiente? Agora imaginem se este programa estivesse 60% documentado com casos de uso e casos de teste. Já seria uma garantia bem maior.

Outro problema é o de não saber o que alterar. Recentemente em um projeto foi esquecido de alterar um programa, e só esse programa gerou mais estresse que todas as outras alterações juntas porque estava dando problema lá no cliente. Sem documentação, não há rastreabilidade." [Ismael Munchen]

Na colocação do Ismael conclui-se que:
1. Falta de documentação pode prejudicar a cobertura dos testes
2. Falta de documentação implica em falta de rastreabilidade e aumento dos riscos nas manutenções do sistema

A visão do Marcelo Andrade complementa o primeiro cenário do Ismael:
"Claro que não dá para testar tirando conclusões sobre regras de negócio da própria cabeça do testador. Neste caso, se a informação está disponível (com o cliente ou com quem quer que seja) é ela que deve ser buscada."

Então, na falta de uma documentação, caso haja alguma outra fonte de conhecimento sobre os requisitos, ela viabiliza os testes e também aumenta a sua cobertura. Essa opinião também foi expressa pela Andrea Cruz quando ela fala que "testar sem documentação é possível, porém podem existir em determinados sistemas requisitos implícitos importantes que podem não ser cobertos pelo teste."

Existe sem dúvida um risco na falta de documentação. Para ser bem sucedido, o Analista de Teste precisa contar com alguma outra fonte de informação, ou a sua cobertura poderá ser seriamente prejudicada.

Segundo Daniel Goettenauer, "o beneficio da documentação só é percebido atualmente em grandes projetos, onde os testes de regressão são constantes e existem muitas mudanças.
[...] dependendo do tamanho do projeto de teste a documentação poderia ser tratada de forma mais simples (documentos básicos) ou complexa (todos os documentos). Dessa forma não teríamos projetos desenvolvidos em 16 horas e testados em 72 horas por conta do volume de documentação."

Ter algum nível de documentação é mesmo importante, entretanto o que define sua necessidade? Uma documentação necessária é aquela que é consultada e mantida, que serve de apoio para o time ou, não se encaixando em nenhum desses objetivos, ela se torna necessária apenas se for uma requisição do cliente. Jeffries, 2001 expõe em seu blog esse mesmo ponto quando fala que "você pode precisar de um UML bem formatado para o seu projeto, ou você pode precisar imprimir o Javadoc quando distribuir o seu código para outros, ou você pode precisar documentar os requisitos para o gerenciamento ou como parte de um contrato. Se e quando você realmente precisar dessas documentações, você deve realmente tê-las." Se elas não forem realmente necessárias apenas demandam tempo da equipe e nem sempre são mantidas adequadamente.

Um sem número de documentos que são criados no início do projeto e não sofrem mais atualizações é uma realidade em muitos projetos. De acordo com o Shmuel, "uma documentação desatualizada é menos útil, mas ainda pode ser usada da mesma maneira. Mas essa ajuda não é um pré-requisito necessário, e podemos testar mesmo sem tê-la. Por meio de abstrações e inferências, é possível aprender sobre o programa de várias outras maneiras, durante os testes, durante conversas, durante as discussões sobre bugs etc.”

Essa opinião está alinhada com uma pesquisa do IEEE, 2003 em que entrevistas com engenheiros de software revelaram as seguintes opiniões sobre documentação:
"- Documento de arquitetura e outras documentações abstratas são freqüentemente válidos ou ao menos provêem um guia histórico que pode ser útil para manutenção.
- Documentações de todos os tipos freqüentemente estão desatualizadas
- Uma fração considerável da documentação não é confiável. "

O Felipe da Silva trouxe um ponto diferente sobre a necessidade e assinalou outro uso dado à documentação fora o projeto de testes que é o de contrato. É comum utilizarmos uma documentação e a aprovação do cliente como um contrato ou parte dele na definição de escopo e base para cronograma. Segundo Felipe, "na maioria dos casos além de brigarmos para querer ter um sistema testável por qualquer um, em determinados processos de engenharia de software também brigamos porque queremos ter um documento como "defesa" contra a insatisfação do cliente. É aquele problema que se você não documenta, o cliente não assina, se ele não assina, não existe um registro que ele havia dito que era aquilo que ele queria, correndo o risco do cliente reclamar e ter melhorias no sistema sem pagar por elas nem ajustar cronograma e etc."

5. Conclusão
As opiniões expostas na Mesa Redonda levaram a um entendimento de que a documentação pode não ser necessária, mas é importante. O tema é bastante abrangente e a cada participação na lista foi possível idealizar novos cenários para responder a mesma pergunta. E você? A que conclusão chegou após ler o que discutimos em mais uma edição da Mesa Redonda do DFTestes?


Participantes da Nona Mesa Redonda:
Fabrício, Shmuel Gershon, Juliana Kryszczun, Ueslei Aquino, Ana Rosa, Sarah Pimentel, Fernanda Coelho, Ismael Munchen, Daniel Goettenauer, Felipe da Silva, Cristiana Yukie, Rodrigo Almeida, Rodrigo Souza, Andrea Cruz, Marcelo Andrade e Jorge Diz.


Referências:
Much Ado About Nothing: Documentation
Ron Jeffries 2001

Schools of Software Testing
Bret Pettichord, 2007

How Software Engineers Use Documentation: The State of the Practice
Timothy C. Lethbridge, Janice Singer, Andrew Forward
IEEE Computer Society
2003

Exploratory Testing Explained
James Bach, 2003