A importancia da documentacao para a realizacao de testes e sempre tema de muita discussao.Quando falamos de projetos de desenvolvimento de software onde seguimos uma esteira rapida de producao ou quando a complexidade da solucao e considerada baixa, normalmente a documentacao e bastante simplificada e em muitos casos ate desprezada. O fato e que a producao de documentacao nesses projetos e normalmente vista pela maioria dos envolvidos no processo de desenvolvimento como perda de tempo e burocracia inutil. Isso pode trazer muitos problemas para as equipes de testes, que tem seu trabalho dificultado pela falta de insumos. Entretanto, essa dificuldade nao deve ser motivo para que os testes sejam deixados de lado ou para que seja dispensada a participacao de equipes de testes independentes. Mesmo com pouca documentacao, e possivel que essas equipes realizem testes importantes em nivel de sistema, complementando a visao dos desenvolvedores sobre a qualidade da solucao.Outro ponto importante, e que pouca documentacao certamente e melhor que nenhuma! E em muitos casos, pode ser ate melhor termos uma documentacao simplificada, mas que agregue real valor ao produto, do que uma ampla documentacao, que nao possa ser mantida atualizada e que nao seja confiavel, ou ainda, que nao seja mais utilizada apos a sua producao, representando um custo desnecessario para o projeto. Mesmo quando temos apenas uma definicao simplificada do escopo da solucao a ser construida, podemos estruturar nossos testes funcionais de tal forma que seja garantida a rastreabilidade em relacao aos requisitos definidos. Isso e importante tanto para a organizacao dos casos de teste, como tambem para a avaliacao da cobertura obtida na execucao dos testes, sejam estes previamente projetados ou realizados de forma exploratoria.Mas como executar os testes se nao temos uma documentacao suficiente para compreendermos o comportamento esperado do sistema? Nao existe milagre! Quanto menos documentacao estiver disponivel, maior devera ser a interacao entre os envolvidos no projeto. O problema e que os desenvolvedores tambem sofrem pressoes por uma entrega rapida e nao tem muito tempo e nem disposicao para explicar o funcionamento do sistema aos testadores. Mas sera que isso e mesmo um problema? Ao tratarmos a importancia dos testes de aceitacao em nosso ultimo post, ressaltamos que a aproximacao entre a equipe de testes e o cliente pode ser muito util para a construcao de roteiros de aceitacao e maior detalhamento dos requisitos. Esta certamente e uma estrategia muito util tambem quando nos defrontamos com um cenario de documentacao escassa nos projetos, pois o cliente pode fornecer a equipe de testes informacoes preciosas sobre o funcionamento do sistema, desonerando os desenvolvedores desta tarefa. Na verdade, isso pode representar um importante beneficio para o projeto, pois nao teremos a contaminacao dos testes de sistema pela visao do desenvolvimento, alem de podermos identificar inconsistencias entre as necessidades apresentadas pelo cliente e os requisitos especificados e utilizados para a construcao do software. Ao aproximar-se do cliente, a equipe de testes obtem informacoes que lhe auxiliarao tanto no entendimento de detalhes importantes do sistema como na especificacao dos testes, mesmo sem a utilizacao de uma documentacao formal.Assim, acreditamos ser