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.

6 comentários:

  1. Muito bom Eduardo!

    Você realmente captou a "regra básica" para lidar com pouca documentação, se há pouca documentação deve haver maior comunicação e interação entre a equipe.

    Afinal, o profissional de teste, por mais que seja experiente, precisa saber como o sistema funciona e o que o cliente espera com ele. Sem esses dados básicos, os testes se tornam uma verdadeira exploração, guiada pelo feeling do profissional, e aí a qualidade dos testes dependerá exclusivamente da capacidade do dele.

    Abraços!

    ResponderExcluir
  2. Olá Fabrício!

    Acredito que essa comunicação mais efetiva deveria ser um prática comum, mas que infelizmente não ocorre com frequência. Existe ainda muita resistência, na maioria das organizações, em permitir a aproximação das equipes de testes dos clientes.

    Felizmente, percebemos uma tendência de mudança nesse cenário, favorecendo entregas mais rápidas mesmo em situações onde existe pouca documentação disponível, mas sem perder de vista a qualidade das aplicações.

    Abraço.

    ResponderExcluir
  3. Olá, Eduardo!

    Belo artigo, bastante realista e contundente!

    Vivo essa realiadade na empresa que trabalho. Por não ser uma fábrica de software, a própria empresa decidiu montar a equipe e desenvolver a aplicação.

    Documentação aqui é zero! No entanto, a conversa com os desenvolvedores é muito constante e agregadora. Se tenho dúvida do que foi implementado faço o seguinte: converso com o desenvolvedor, se não resolver, vou ao gestor, se não resolver, vou ao usuário final.

    Dessa forma, absorvo a base de conhecimento necessária para testar a aplicação com o máximo de conhecimento possível.

    De qualquer maneira, ainda sinto falta de documentação, pois é uma segurança, uma garantia, que, feita de maneira consciente, não deixa dúvidas para interpretações.

    ResponderExcluir
  4. Olá galera,

    Como o Fabrício disse, realmente é muito difícil ainda as equipes de teste se aproximarem do cliente final.
    Mas esse regra deve ser quebrada com o tempo, pois assim a qualidade será muito maior e o cliente final ficará muito mais satisfeito.

    Quando a equipe de teste receber essa documentação incompleta deve começar a exigir o contato com o cliente para um melhor processo de qualidade.

    Abs,
    Danilo Rebouças

    ResponderExcluir
  5. Olá Eduardo. Muito bom o seu post. Mas uma dúvida me surgiu.

    A solução de aproximar a equipe de testes do cliente é perfeita para o caso onde o cliente contratou uma empresa para desenvolver um sistema para o que ele quer.

    E quando ocorre o inverso? A empresa está produzindo um software de prateleira que será disponibiizado para n clientes que utilizam aquele sistema para os mais variados objetivos e das mais variadas formas. Nesse caso a empresa não possui um cliente específico, e fazer uma avaliação junto aos clientes pode ser um tiro no pé, pois vc pode acabar seguindo uma visão de um cliente e prejudicando um outro que não utiliza seu sistema daquela forma.

    Um exemplo bem tosco: word é um software de prateleira, com fins de editor de texto, porém existem muitos usuários que utilizam a aplicação para criação de trabalhos gráficos como criação de cartões de visitas que deveriam ser feitas em um Corel Draw.

    Para essas empresas que criam software de prateleira, para clientes dos mais variados tipos e com diferentes metas de utilização. Qual seria a solução para ajudar a equipe de testes que tem como insumo documentação pracária ou nula?

    ResponderExcluir
  6. Oi Luciana,

    De fato, para testar softwares de prateleira essa aproximação entre a equipe de testes e os potenciais clientes não traria tantos benefícios. Mas nesses casos, normalmente existe uma documentação mais completa, até porque essa documentação vai ser fundamental para a manutenção da aplicação.

    Penso que no mínimo você deverá ter um bom detalhamento dos requisitos, para que possa definir seus critérios de validação e estabelecer a rastreabilidade entre os requisitos e seus casos de teste.

    Para refletirmos um pouco mais sobre o assunto: você compraria um software se soubesse que ele não possui uma documentação mínima? É bem provável que um software assim nunca seja um campeão de vendas, não acha?

    Abraço.

    ResponderExcluir