Testar sem documentação é possível?

A nona Mesa Redonda DFTestes teve como tema “Testar sem documentação é possível?”, contando com 24 respostas e 16 participantes, sendo eles: eu, Shmuel Gershon, Juliana Kryszczun, Ueslei Aquino, Ana Rosa, Sarah Pimentel, Fernanda Coelho, Ismael Munchen, Daniel Goettenauer, Felipe Silva, Cristiana Yukie, Rodrigo Almeida, Rodrigo Souza, Andrea Cruz, Marcelo Andrade e Jorge Diz.

Abaixo segue o “resumo” de mais uma excelente Mesa Redonda DFTestes, e como sempre, não deixem de acompanhar a mesma, e se você se interessa pelo assunto, é altamente recomendável a leitura da discussão na íntegra.🙂

Testar sem documentação é possível?

Segundo o Shmuel Gershon:

A documentação é uma das ferramentas usadas durante os testes, dentre outras. Como tal, ela nos ajuda a aprender sobre o comportamento e contexto do aplicativo.

Mas essa ajuda não é um pré-requisito para os testes. É possível testar sem documentação, pois durante os testes um Tester pode (deve?) abstrair e inferir sobre o aplicativo e ir aprendendo quais são as perguntas necessárias.

Muitos Testers, inclusive os que acreditam precisar da documentação, passam por esse processo consciente ou inconscientemente.

Afinal, nem sempre a documentação é correta, e se é possível testar desconfiando da documentação, é possível testar sem ela.

Finalizando, uma “prova matemática”: É possível testar a documentação, e a documentação por si não tem documentação (às vezes sim). Logo, é possível testar sem documentação🙂.

A utilização da documentação como base para a elaboração dos testes, costuma fazer parte de qualquer processo de Teste de Software, porém dependendo da documentação existente, outros caminhos podem ser seguidos para a elaboração dos testes, como foi comentado pela Juliana Kryszczun:

Muitas vezes a documentação que chega para a equipe de teste está toda distorcida. O sistema seguiu outro rumo, a documentação não foi atualizada e uma boa conversa com o analista de requisito (ou responsável) resolve bem mais do que ficar horas lendo a documentação desatualizada.

Esse não é o caminho feliz dentro do processo, mas às vezes, não dando a devida importância para a documentação pode salvar os prazos de entrega.

O Ueslei Aquino lembrou que em empresas onde não há um processo bem definido de Desenvolvimento e Teste de Software, ou onde o mesmo costuma sofrer resistência por parte das pessoas, a melhor fonte de informação acaba sendo as próprias pessoas:

Em empresas que não se tem a prática de documentação, o conhecimento tácito (o que está na cabeça de alguém) é o que predomina. Há momentos em que vale muito mais a pena descobrir quem é a “cabeça” do conhecimento, conversar sobre o sistema e extrair todas as informações necessárias que ficar preso a uma documentação desatualizada.

O Ueslei Aquino ainda complementa dizendo que:

A documentação é importante sim, desde que seja um facilitador para o teste, caso contrário mão a obra e vamos ao sistema sem documentação.

O Felipe Silva acredita que é possível sim testar sem documentação e complementa dizendo:

Pensando nos testes beta, por exemplo, muitos usuários que instalam aplicativos beta em seus PCs acabam testando. Porém, nem tudo é tão simples quanto um teste beta. Existem testes e testes, fato. Você testaria um sistema de controle de pouso de uma aeronave sem documentação? Eu não… se sim, você faria o primeiro vôo estando você nesta aeronave? Percebam que eu não disse que não é possível nem neste exemplo, eu não testaria sem documentação porque não tenho a mínima idéia de como um sistema desses deve funcionar para ter um resultado satisfatório, mas e se no contexto ao invéz de uma pessoa sem conhecimento fosse alguém que tem uma vasta experiência no assunto o suficiente para produzir a dita documentação, garanto que esta pessoa poderia testar sem documentação porque ela é a própria documentação.

Testar sem documentação é possível, depende de QUEM irá fazê-lo.

A Cristiana Yukie compartilhou uma experiência vivida com a documentação do Teste de Software:

Aqui tínhamos muitos problemas quando havia problemas em produção, porque não documentávamos o que foi testado, quais testes foram feitos na versão atualizada, quais regras foram cobertas… entre outros.  Quando começamos a ter documentos dos testes que deveriam ser feitos antes e após a atualização começamos a ter mais garantia da versão atualizada em produção.

Então, eu diria: é possível testar sem documentação Sim, porém se tivermos uma documentação (claro, sempre atualizada) ganhamos mais em qualidade! Esta documentação atualizada é bem vinda principalmente a longo prazo.

O Rodrigo Almeida lembrou que precisamos buscar produzir uma documentação eficiente:

Testar algum software sem documentação é possível sim, mas não acho que seja eficaz/eficiente.

O custo de não ter documentação alguma pode ser muito alto.

Criar e manter uma extensa documentação também não é viável, dado o custo.

Precisa ter um mínimo de documentação. Um caso de teste, o registro das alterações feitas no sistema para que seja feito o teste e um relatório sobre o teste. Acho que este seria o mínimo necessário.

A Andrea Cruz lembrou bem, que testar sem documentação irá trazer certos riscos e você precisará assumir-los:

Testar sem documentação é possível porém podem existir em determinados sistemas requisitos implícitos importantes que podem não serem cobertos pelo teste.

Eu trabalho com projetos que um testador leigo pode deixar de testar determinados requisitos.

Um bom testador é capaz de levantar os dados de um sistema a partir das conexões com Banco de Dados, Testes Funcionais e Testes de Performance apenas informando o tempo que foi levado para retornar determinadas consultas sem ter o critério e o limite esperado do tempo pelo cliente e escrever isso no Relatório de Testes.
Cabe ao Analista ter o critério para dizer o que passou e o que não é aceitável.

Exemplo simples: Um shortcut pode “matar” um software se não for acionado. Sem documentação como saber? Teste Monkey??? rsrsrsrsrs

Para o Daniel Goettenauer a documentação precisa ser gerada de acordo com o tamanho do projeto:

A empresa que trabalho até algum tempo não tinha a Fábrica de Testes e quando foi implantada para apagar incêndio a documentação de testes era ignorada, e o nível de produtividade era muito auto. A medida que o processo foi amadurecendo e se chegou a conclusão que a documentação era necessária para se ter robustez as coisas passaram a ficar lentas e engessadas.

O benfício da documentação só é percebido atualmente em grandes projetos, onde os testes de regressão são constantes e existe muitas mudanças.

Meu pensamento é que 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.

A Sarah Pimentel lembrou que a resposta para essa pergunta, poderá variar dependendo da escola de Teste, que você “segue”:

A favor de que é possível testar sem especificação:
Context-Driven School
-Faça o possível para ser útil (Acho que até agora a maioria aqui concordou que da pra gente seguir em frente)

-Faça perguntas se necessário (Comentei do oráculo, uma pessoa especialista a quem podemos recorrer)

Vasculhe documentações “escondidas” (Schmuel: “Uma documentação desatualizada serve para muitas coisas! :)”)

Agile School

– Conversas são mais importantes que documentações

Ps.: Note que nenhuma das duas disse que a melhor prática é testar sem documentação, apenas disseram que é possível se não tiver uma disponível.
Contra a possibilidade de testar sem especificação:
Analytical School
-Impossível (mas também imagina testar um sistema puramente matemático daqueles que tem não sei quantos computadores pra conseguir fazer um cálculo?)
Standard School
– Alguma documentação é necessária (planejando e seguindo um processo, deve ter alguma coisa que possa ser útil para o teste. e supondo que o planejamento ocorra de acordo com o ideal, que é o planejamento de testes iniciando no começo do projeto, já teriam sinalizado que tá faltando alguma coisa)
Quality School
– Force developers to follow the process (realmente, se tivessem seguindo um processo estruturado desde o começo, haveria alguma documentação, mas também chegar na fase de teste e fazer todo mundo documentar o que não foi documentado até o momento é suicídio do projeto)

O Marcelo Andrade lembrou que a informação é mais importante que a documentação, e disse:

Primeiro, só para deixar bem claro meu ponto de vista, a informação é mais importante que a documentação.

Isto é, se a documentação não é mantida, não é compreendida, não é atualizada, e é gerada apenas para cumprir-se com formalismo do processo, ela não é necessária.  Relembrando que documentação necessária é aquela que 1) o cliente solicita ou 2) é usada para apoiar o desenvolvimento.

Claro que não dá pra se 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.

Por fim, se sua equipe tem dificuldades com relação a documentação (encontrar, mantê-la atualizada, etc), tem-se que pode ser mais fácil incluir um artefato do qual se sinta real necessidade do que retirá-lo do que o processo prescreve.  O processo deve se adaptar às equipes e nunca o contrário.

Uma reflexão que me ocorreu dia desses: muitos de nós acabamos por usar documentos e mais documentos como “muletas”, como uma espécie de escora no que podemos nos apoiar (ou culpar) para saber o que devemos fazer.  Entretanto, se você tem uma equipe minimamente capacitada, as pessoas sabem o que fazer, o que é necessário para fazer, o que testar e como testar.  Talvez elas não tenham experiência em fazer ou temam errar.  Mas não há nada de errado em errar🙂 e aprender.  Mas aí já são divagações…

O Jorge Diz também acredita que não deve-se colocar todas as fichas na documentação:

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.

Durante a discussão a Sarah Pimentel levantou duas questões bem relevantes ao tema da mesma.

Pra quem acha que dá pra testar sem documentação, então por que a gente documenta? E porque tantas vezes brigamos por documentação?

Para Shmuel:

A documentação é uma ferramenta útil nos testes, por isso documentamos, ou brigamos por documentação correta. Às vezes o esforço da certo, às vezes não. É igual testabilidade. Uma ótima ferramenta, e brigamos por isso. Nem sempre dá certo, ou nem sempre acaba da melhor maneira.

O Felipe Silva disse que:

Para que pessoas sem conhecimento anterior do sistema consigam trabalhar, e em alguns casos serve para que o cliente assine dizendo que é isso que ele quer que seja feito.

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 logo não existe um registro de 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.

Se a documentação não é confiável, por que é gasto tempo produzindo-a?

O Shmuel acredita que:

Bom ela foi confiável no momento da produção.

Mas nem por isso ela é completamente inútil: Uma documentação desatualizada serve para muitas coisas!🙂

Ela nos ajuda a entender a história do projeto, as expectativas iniciais, as primeiras idéias. A comparação entre o que foi documentado e o que saiu no fim nos ajuda a entender as suposições do cliente e dos arquitetos, os limites e obstáculos encontrados. Não jogue a documentação desatualizada fora!🙂

O Felipe Silva pensa que:

Documentação é confiável quando atualizada e se possível assinada. Se não está atualizada e nem assinada siga o conselho do Shmuel: “Uma documentação desatualizada serve para muitas coisas! :) Ela nos ajuda a entender a história do projeto, as expectativas iniciais, as primeiras idéias. A comparação entre o que foi documentado e o que saiu no fim nos ajuda a entender as suposições do cliente e dos arquitetos, os limites e obstáculos encontrados. Não jogue a documentação desatualizada fora! :)”

Conclusão

Algumas conclusões extraídas da discussão:

  • A documentação NÃO É um pré-requisito para a área de Teste de Software;
  • No entanto, a existência de uma documentação completa e atualizada poderá ajudar MUITO a elaboração dos testes, e assim aumentar a eficácia dos mesmos;
  • Não jogue a documentação desatualizada fora, ela poderá ser útil para quem for pegar o bonde andando, para poder ter uma noção melhor do projeto, afinal das contas, se ela está desatualizada, que dizer que as informações contidas nela, um dia foram as atuais;
  • “Falta de documentação é um risco. A documentação que está faltando e o contexto do teu projeto é que vão determinar se é um risco aceitável ou não.” (Sarah Pimentel)

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Fique por dentro das novidades, assine o feed do QualidadeBR.

9 comentários sobre “Testar sem documentação é possível?

  1. Muito boa essa discussão. Os tópicos levantados são de conhecimento da grande maioria de analistas de testes e testers, e eu também me identifiquei.
    Concordo quando dizem que a informação é o mais importante, e que devemos buscar o “oráculo” pra suprir as dúvidas ao invés de ler documentação desatualizada.
    Mas devemos nos lembrar que as vezes, o dono da informação não está acessível (férias, reuniões, as vezes nem trabalha mais na empresa), e dai, voltamos a lamentar a falta da documentação atualizada.
    Eu acredito que os testes pelo menos, devem ser documentados, pra depois de colocarem na produção, e algo “der errado”, se ter como provar o que foi coberto pelo testes.
    Já aconteceu comigo de exigirem que fosse testado X, e quando estava na produção, viu se a necessidade de Y. Porém, o “oráculo” não havia solicitado o Y, e pude comprovar pela minha documentação gerada.
    Eu sou contra a burocratização, papelada e tudo que possa atravancar o caminho, mas se resguardar, não faz mal a ninguém!!!

    Responder
  2. @Felipe e Goettenauer

    Que bom que acharam a discussão produtiva e esclarecedora, o pessoal mandou muito bem mesmo (mais uma vez).🙂

    @Fernanda

    A rotativade é um dos maiores riscos em qualquer projeto, e sem dúvida uma das maneiras de mitigar esse risco é passar o conhecimento para o papel, ou seja, gerar documentação.🙂

    Testar um sistema com a documentação desatualizada e sem um oráculo, é uma missão para super heróis, sorte que temos os testes exploratórios para nos ajudar nesses momentos.

    Abraços!

    Responder
  3. Parabéns pelas colocações pessoal!
    Gostaria de acrescentar que uma documentação atualizada não só gera testes mais eficazes (objetivos e com a devida cobertura) como também auxilia a produtividade dos analistas de testes ou testadores, ou seja, as atividades se tornam mais eficientes (em tempo menor) – do contrário, uma documentação desatualizada ou consultas ao “oráculo”, pode elevar o tempo da criação de cenários ou execução dos testes.

    Responder
  4. “Não jogue a documentação desatualizada fora, ela poderá ser útil para quem for pegar o bonde andando, para poder ter uma noção melhor do projeto, afinal das contas, se ela está desatualizada, que dizer que as informações contidas nela, um dia foram as atuais;”

    Donde concluímos isso? Por acaso alguém, num projeto com prazos
    apertados, chama novos programadores e diz pra ler a documentação?
    Pelo menos, por onde passei, a primeira orientação quase sempre é
    “Senta lá com Fulano que já conhece bem essa parte pra ele te
    explicar”.

    Exemplo clássico: o documento de caso de uso menciona que é
    necessário informar um dado, mas a tela que está pronta não há
    nenhum campo solicitando tal dado. Continuo lendo este
    documento? Ele está sendo importante para o projeto? Ele será
    útil para quem for “pegar o bonde andando”?

    Responder
  5. Olá Marcelo!

    Entendi o seu ponto, mas como eu disse “ela poderá ser útil”, não é que ela será útil sempre, e isso depende de uma série de fatores, por exemplo: quem vai pegar essa documentação? qual documento que é? etc.

    Um escopo desatualizado pode ser útil para o novo Gerente de Projeto, para que ele possa entender melhor o que foi solicitado, mas o mesmo, provavelmente, não será útil para um Analista de Teste, e esse terá que buscar as informações diretamente da fonte (cliente e time).

    E no exemplo seu, um caso de uso, eu acho que ele só poderá ser útil para a pessoa que for atualizar ele.

    Abraços e obrigado pelo comentário!🙂

    Responder
  6. olá Pessoal!

    Fiquei feliz ao encontrar esta discussão em mesa. A minha empresa está a utlizar a metodologia Scrum e uma das questões que muito se coloca é se vale a pena usarmos ou não documentos de especificação, todas as opiniões dádas aqui na verdade caminham para o não descartamento da documentação, penso que continua a ser importante ter-se o mínimo de documentaçaõ para melhor orientação em muitas situações já descritas.

    Aguardo novas discussões!

    Responder
  7. Olá pessoal

    Também fiquei feliz com a riqueza das discussões e pude perceber que há diversas formas de se contornar falta de documentação de insumos para teste.

    Adicionalmente percebi (talvez me equivoque) que a maioria dos participantes da discussão levou em conta um cenário de trabalho em que gerente de projeto, desenvolvedores e testadores compartilham espaços físicos de trabalho e/ou estão vinculados a uma mesma hierarquia.

    Vou citar um cenário de trabalho onde, por exemplo, uma empresa contrata do desenvolvimento de uma fábrica de software terceirizada e contrata os testes de uma fábrica de teste também terceirizada, sendo que cada equipe da empresa, fábrica de software e fábrica de teste trabalha em ambiente físico específico e sob contrato específico. Nesses casos, avalio que a documentação de insumo para teste é vital ou então seria necessário “quebrar” o modelo de trabalho, juntando as pessoas das diferentes empresas num local físico unificado.

    As negociações gerenciais necessárias e as dificuldades de disponibilidade de pessoas que possam trocar conhecimentos entre empresas (pessoas estas que tem suas diversas atividades de cronogramas para cumprir) certamente gerarão custo superior àquele que seria utilizado para gerar a documentação de insumo.

    Mas, no final das contas vale considerar uma das observações pescadas na discussão acima: “parar uma equipe para documentar o que deixou de ser documentado em fases anteriores do projeto pode ser um suicídio do próprio projeto”. Nesses casos, algum gerente de projeto precisa bancar os custos operacionais e os riscos decorrentes para se testar sem documentação.

    Responder

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s