domingo, 12 de setembro de 2010

Como testar quando a documentação é precária?

A importância da documentação para a realização de testes é sempre tema de muita discussão.
Quando falamos de projetos de desenvolvimento de software onde seguimos uma esteira rápida de produção ou quando a complexidade da solução é considerada baixa, normalmente a documentação é bastante simplificada e em muitos casos até desprezada. O fato é que a produção de documentação nesses projetos é normalmente vista pela maioria dos envolvidos no processo de desenvolvimento como perda de tempo e burocracia inútil.  


Isso pode trazer muitos problemas para as equipes de testes, que têm seu trabalho dificultado pela falta de insumos. Entretanto, essa dificuldade não deve ser motivo para que os testes sejam deixados de lado ou para que seja dispensada a participação de equipes de testes independentes. Mesmo com pouca documentação, é possível que essas equipes realizem testes importantes em nível de sistema, complementando a visão dos desenvolvedores sobre a qualidade da solução.

Outro ponto importante, é que pouca documentação certamente é melhor que nenhuma! E em muitos casos, pode ser até melhor termos uma documentação simplificada, mas que agregue real valor ao produto, do que uma ampla documentação, que não possa ser mantida atualizada e que não seja confiável, ou ainda, que não seja mais utilizada após a sua produção, representando um custo desnecessário para o projeto. Mesmo quando temos apenas uma definição simplificada do escopo da solução a ser construída, podemos estruturar nossos testes funcionais de tal forma que seja garantida a rastreabilidade em relação aos requisitos definidos. Isso é importante tanto para a organização dos casos de teste, como também para a avaliação da cobertura obtida na execução dos testes, sejam estes previamente projetados ou realizados de forma exploratória.

Mas como executar os testes se não temos uma documentação suficiente para compreendermos o comportamento esperado do sistema?  Não existe milagre! Quanto menos documentação estiver disponível, maior deverá ser a interação entre os envolvidos no projeto. O problema é que os desenvolvedores também sofrem pressões por uma entrega rápida e não têm muito tempo e nem disposição para explicar o funcionamento do sistema aos testadores. Mas será que isso é mesmo um problema?



Ao tratarmos a importância dos testes de aceitação em nosso último post, ressaltamos que a aproximação entre a equipe de testes e o cliente pode ser muito útil para a construção de roteiros de aceitação e maior detalhamento dos requisitos. Esta certamente é uma estratégia muito útil também quando nos defrontamos com um cenário de documentação escassa nos projetos, pois o cliente pode fornecer à equipe de testes informações preciosas sobre o funcionamento do sistema, desonerando os desenvolvedores desta tarefa. Na verdade, isso pode representar um importante benefício para o projeto, pois não teremos a contaminação dos testes de sistema pela visão do desenvolvimento, além de podermos identificar inconsistências entre as necessidades apresentadas pelo cliente e os requisitos especificados e utilizados para a construção do software. Ao aproximar-se do cliente, a equipe de testes obtém informações que lhe auxiliarão tanto no entendimento de detalhes importantes do sistema como na especificação dos testes, mesmo sem a utilização de uma documentação formal.

Assim, acreditamos ser possível contornarmos uma eventual precariedade da documentação em um projeto de desenvolvimento de software, com uma comunicação mais efetiva entre as equipes de testes e o cliente, permitindo a realização de testes com um bom nível de detalhamento, sem prejuízo ao relacionamento entre testadores e desenvolvedores e à celeridade na entrega das soluções.