É possível realizar documentação de testes quando trabalhamos com metodologias ágeis? Digo, desde o plano de teste até o caso de teste, isso é possível?

Após um bom tempo sem fazer os resumos das excelentes mesas redondas virtuais, que ocorrem no grupo de discussão DFTestes. Nos próximo parágrafos, segue o resumo da 31ª Mesa Redonda DFTestes (sim, a minha intenção e fazer o resumo de todas que ocorreram no período em que parei de fazer os resumos).

Essa mesa redonda teve 7 respostas e 7 participantes, sendo eles: eu, Lidiane Santos, Shmuel Gershon, Felipe Silva, Fermiano de Queiroz, Sarah Pimentel e Ueslei Silva.

É possível realizar documentação de testes quando trabalhamos com metodologias ágeis? Digo, desde o plano de teste até o caso de teste, isso é possível?

A Lidiane deu a sua contribuição dizendo:

É possível sim, fazer documentação em um proceso ágil, mesmo porque você começa desenvolvendo em cima dos cenarios de testes que foram levantados.

E eu já trabalhei muito em empresas que não utilizam o processo agil, mas já testei muito software sem documentação, indo apenas pela intuição e conforme vou testando vou documentando os testes.

Acho que essa associação de Teste de Software = Documentação e Burocrácia é coisa do passado.

Para o Shmuel, você pode tanto documentar, como não documentar, quando está trabalhando com metodologias ágeis:

É possivel realizar documentacao de testes quando trabalhamos com metodologias ágeis.

E também, é possível não realizar documentação de testes quando trabalhamos sem metodologias ágeis. Surpresa!

O Fermiano contou um pouco da sua experiência atual:

Sei que existem testadores que usam deste argumento, mas também vejo testadores fazendo o contrário. Felizmente, aqui a maioria encara os desafios da função e assume os riscos, sedentos por um teste exploratório. Documentação também depende do processo utilizado, precisamos seguir os planos de testes para garantir o sucesso obtido em projetos anteriores. Em nosso processo temos uma variedade de testes, com base em planos de teste e, também, exploratórios, em várias etapas. Toda a documentação “necessária” para os testes é gerada durante essas etapas, de acordo com cada etapa do processo.

A Sarah tocou num ponto bem importante, o de que as metodologias ágeis muitas vezes não são utilizadas corretamente, e passam a ser apenas para mascarar que não está sendo utilizado nenhuma metodologia:

Pois é.. Uma questão é que muitas vezes quando alguém me diz “nesse projeto vamos usar metodologias ágeis” me dá um frio na espinha e eu já saio correndo pra mesa do SQA dizendo pra ele fazer alguma coisa, porque em muitos casos eu sei que ‘usar metodologia ágil’ é uma desculpa pra não usar metodologia alguma. A metodologia passa a ser: precisamos entregar para o cliente um monte de pedaços de sistemas e fazer várias entregas e rápidas.

Completamente deturpado. Não existe envolvimento próximo do cliente, não tem ninguém capacitado na equipe para conduzir o time nas práticas da metodologia escolhida, a equipe é formada por um grande numero de profissionais juniors, ou seja: tem tudo pra ser um desastre.

Não tô dizendo que NINGUÉM sabe fazer projeto ágil, por favor. Tô dizendo que HÁ CASOS, em que ‘metodologia ágil’ é desculpa para não usar metodologia alguma. Se não tiver um responsável fazendo às vezes de SQA (no sentido de orientar a equipe e até mesmo intervir na escolha da metodologia) o negócio desanda feio.

Então metodologia ágil pode ou não ter o teste documentado, dependendo da necessidade do projeto.

Se para testar é necessário ter uma vasta documentação, já discutimos isso antes. A minha opinião é: não.

O Ueslei compartilhou um pouco da sua experiência:

Depende!

Atualmente estou alocado em uma empresa que usa desenvolvimento ágil. Junto com o Desensolvimento, estão 3 pessoas encarregadas pelos testes.

As histórias de usuário criadas pelo desenvolvedor, são levantadas com base nas especificações que são realizadas por uma área específica.

A equipe de teste, utilizam tais especificações para realização da primeira bateria de testes.

Mas, isso não é tudo. Temos também uma outra equipe de testes, com perfil de homologação/aceitação, mas que explora os sistemas com maior granularidade do que os conhecidos testes de aceitação.

Esta equipe, é formada por 10 colaboradores. Esta equipe, também com base nas especificações, geram documentos de casos de teste e automação de teste.

Bom! no nosso ambiente, além de ágil, temos outros processos que suportam as necessidades e geram artefatos. Mas, mesmo que uma organização use ágil puro, ainda sim, seria interessante usar documentos, mesmo que simples. Por exemplo, mapas do que é interessante ser testado. Assim, o conhecimento não fica tácito nem corre-se o risco de algo importante cair no esquecimento.

Eu acredito que sim. Porém, pensando em uma equipe que é realmente ágil ou pelo menos busca respeitar os princípios ágeis, talvez não seja necessário realizar um plano de teste. Copiando e colando um exemplo que dei num comentário no blog As Especialistas, relacionado ao assunto:

De acordo com o contexto, podemos até não utilizar o Plano de Teste, mas isso não significa que estaremos pulando a fase de planejamento (que é essencial), mas sim que podemos utilizar outras formas de fazer o planejamento.

Para ilustrar o que quero dizer, vamos pensar numa equipe de Teste de Software com 3 pessoas, que testam um sistema que é desenvolvido em ciclos de 2 semanas. A cada ciclo de desenvolvimento novas funcionalidades são adicionadas e também bugs são resolvidos.

Para esta equipe, o planejamento do Teste de Software pode ser iniciado na própria reunião de planejamento do ciclo de desenvolvimento, da qual já podem sair, por exemplo, com as funcionalidades que serão testadas, o que não será testado, ambientes que serão usados e os prazos.

Depois os três podem fazer uma reunião entre eles para detalhar melhor o planejamento de teste. Deste detalhamento podem sair com vários post-its para serem colocados num quadro ou com um checklist num Google Docs, por exemplo.

O que ocorre é que “o Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara”, portanto toda documentação que você faria apenas com o objetivo de comunicar algo a alguém será provavelmente, descartada.

Por que raios, quando se fala em Teste de Software, as pessoas logo lembram de documentação, e não de testes em si? Por que os profissionais de Teste de Software ainda são tão dependentes de documentação?

Segundo o Shmuel:

Um dos motivos da ligação Teste de Software –> Documentação é esse mesmo, os testadores passarem o tempo tentando provar que da pra documentar, e tentando gerar documentação suficiente pra se proteger atrás dela. Quem nunca ouviu um testador falando: “Testei o que está nos requerimentos”, “esse bug eu perdi, porque não esta no plano de testes”, “Já terminamos os testes: 100% do plano de testes”… ? Acho que essa associação é culpa nossa, mais do que culpa deles.

O Felipe Silva comentou a resposta do Shmuel dizendo:

Que jogue a primeira pedra aquele que nunca se protegeu atrás de documentação.

Na minha opinião, a documentação acaba sendo uma forma da gente se defender. E além disso, muitos profissionais foram influenciados por processos que tem em sua saída a produção de artefatos. Então, acabamos utilizando a documentação até mesmo em ocasiões onde ela não é necessário (ex.: comunicação).

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

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.

Quando documentar não é preciso?

O tema da última Mesa Redonda DFTestes de 2009 foi “Quando documentar não é preciso?”, e teve 18 respostas e 7 participantes: eu, Felipe Silva, Milton Vopato, Sarah Pimentel, Rodrigo Almeida de Oliveira, Marcelo Andrade e o Eduardo Gomes.

A discussão foi bem produtiva, e ao longo dela novas dúvidas e assuntos foram abordados sobre documentação em geral. No próximo parágrafo começa o resumo da sétima mesa redonda, e mais uma vez, fica o convite para ler toda a discussão, caso o tema seja de seu interesse. 😉

Quando documentar não é preciso?

O Felipe Silva iniciou uma lista dos momentos que é preciso documentar, e depois eu adicionei dois itens a mesma:

• Necessitar arquivar evidências;
• Arquivar banco de conhecimentos (todos aqueles que servem como consulta para quaisquer tarefas);
• O contrato obrigar;
• Alta rotatividade na equipe;
• Disseminar o conhecimento (nesse caso há outras alternativas também (como reuniões, trabalhar em par), mas a documentação é a forma menos volátil).

Uma segunda lista foi iniciada pelo Felipe Silva, com todos os documento que são necessários em qualquer projeto de testes e aqueles que podem vir a ser úteis em casos separados, e depois adicionei alguns itens:

• Documentos necessários em qualquer projeto:
  • Casos de Testes;
  • Registro de bugs;
  • Relatórios.
• Necessários? Vocês usam? Independente se usam, acham bom ter?
  • Cenários de Testes;
  • Plano de Testes;
  • Estratégia de Testes;
  • Especificação de Projeto de Teste;
  • Especificação de Procedimento de Teste;;
  • Relatório de Sumário de Teste;
  • Relatório de Incidente de Teste;
  • Log de Teste.
• Outros:
  • Plano de automação de testes;
  • Estratégia de automação;
  • Relatório de Encaminhamento de Item de Teste.

Eu entendo que documentar serve para os seguintes fins (pensando em documentação de Teste de Software):

• Ajuda o entendimento do sistema, quando você cria a documentação de Teste de Software, você entende melhor o sistema, e ainda abstrai as informações para o mundo de Teste de Software;
• Compartilhamento de conhecimento com a equipe, se fizer todos os meus testes de forma exploratória como que uma outra pessoa poderá realizar os mesmos testes?
• Transmitir informações para os stakeholders do projeto;
• Gerar uma base histórica, que poderá auxiliar em futuros projetos.

E tudo depende da sua realidade, por exemplo: se o cliente não exige documentação de Teste de Software, você tem conhecimento do sistema sob teste e o prazo é curto. Você pode testar só de forma exploratória, sem documentar os seus testes, e poderá até mesmo passar os defeitos diretamente para os desenvolvedores (informalmente).

Lógico que o exemplo citado acima, não é muito correto e bem extremo. Só que nessas situações você precisa fazer escolhas, e entre garantir a qualidade do sistema sob teste ou garantir que todas as atividades do Teste de Software sejam cumpridas, eu fico com garantir a qualidade do sistema sob teste.

Eu não vejo nenhum problema em documentar, com tanto que essa documentação tenha alguma finalidade, documentar por documentar, é perda de tempo, e por consequência, perda de dinheiro.

Para o Milton Vopato:

A documentação dos testes é fundamental, para melhoria continua e além disso, pensando no dia a dia, para segurança da própria equipe de teste, pois é uma evidência de cobertura dos scenarios propostos.

A Sarah Pimentel compartilhou um pouco da sua experiência com documentação:

Já estive em um projeto de consultoria de testes, onde o nosso papel era analisar requisitos e casos de uso e gerar documentação para realização de testes por uma outra equipe.

Documentos gerados:

• Casos de teste (obvio :))
• Roteiro de testes (em que ordem devem ser executados os testes gerados)
• Massa de dados (listagem de dados necessários para a execução dos testes)
• Matriz de rastreabilidade de testes (o caso de teste gerado refere-se a que/quais caso de uso entregues pelo cliente)
• Registro de desvios (gaps encontrados na documentação enviada)

Em um outro projeto o trabalho foi configurar uma ferramenta (no caso, Quality Center), gerar casos de teste para a aplicação, treinar a equipe de testadores (inclusive para fazer atualizações posteriores no teste).

E já trabalhei em projetos com um MONTE de documentação também. Isso pra dizer que “tudo é relativo” 🙂 O que importa é gerar o que vai ser útil e o que você consegue manter. Não adianta produzir toda a documentação do RUP se você não consegue mantê-la alinhada entre si e se o próprio time não a consulta.

O Rodrigo Almeida expôs a sua opinião dizendo:

Na minha opinião, documentar só por documentar não se justifica. Toda atividade num processo precisa gerar valor. Se não é só pedágio!

Existe um mínimo que é obrigatório no nosso processo hoje: O caso de teste e/ou uma evidência de teste e um relatório de painel de bordo das homologações.

Quando fazemos um projeto aí temos também o Plano de Testes.

Para o Marcelo Andrade, não é necessário documentar quando o documento:

1. Não seja de fato útil, mas precise ser feito apenas por que o processo assim determina;
2. Não é mantido atualizado (de certa forma, uma consequência do item 1);
3. Não é compreendido pelas pessoas para quem ele foi escrito (outra consequência do item 1).

O Marcelo ainda comentou sobre documentos difíceis de serem compreendidos e compartilhou o link para um bom artigo sobre documentação:

Se sua equipe de desenvolvimento gera documentos difíceis de entender, que não atendam ao seu propósito, que estejam sempre muito defasados e não sejam efetivamente utilizados, isso não é valorizar a documentação. Longe disso. Valorizar a documentação é dar real importância aos documentos gerados, fazendo com que eles agreguem valor ao cliente e sejam usados de fato para apoiar o trabalho da equipe.

Volto a indicar este esclarecedor artigo do InfoQ sobre o assunto:

http://www.infoq.com/br/news/2009/08/agile-documentation

Outro link bem legal sobre documentação ágil, é esse abaixo, de um vídeo que o Vinícius Teles fez sobre documentação ágil:

http://blog.improveit.com.br/articles/2008/08/01/documenta%C3%A7%C3%A3o-%C3%81gil

O Eduardo Gomes compartilhou a sua opinião dizendo:

A necessidade de documentação é sempre motivo de debate e gera argumentações apaixonadas, tanto a favor como contra. Quando falamos da documentação dos testes, essa discussão fica ainda mais acalorada, pois muita gente entende que a documentação do sistema já é um “trabalho jogado fora”, quanto mais documentar os testes. É uma visão característica dos desenvolvedores, que estão preocupados em construir as soluções e veem na documentação um entrave ao seu trabalho. E em muitos casos isso é realmente o que acontece.

Mas se observarmos os modelos de maturidade de software, percebemos que a documentação é peça chave no esforço pela melhoria de processos e para a qualidade dos produtos. Sem uma documentação, automatizada ou não, dificilmente conseguimos atingir níveis satisfatórios de maturidade nos processos. Prefiro enxergar a documentação como um investimento e não como um trabalho jogado fora.

Quanto à documentação de testes, utilizamos atualmente, 04 artefatos básicos:

• Plano de Testes (Escopo, riscos, estratégia, ambiente, intervenientes, aprovações, etc);
• Roteiros de Testes (Casos de teste, massa de teste relacionada, especificidades do teste etc);
• Relatórios de Testes (Resultados da execução dos testes, evidências, gestão dos defeitos etc);
• Relatório Final (Resumo dos testes, pareceres, validações etc).

Esse conjunto completo de artefatos é aplicado somente sobre projetos, que possuem um escopo maior de teste e também outros artefatos relacionados ao desenvolvimento, que servem de insumo para a construção da documentação de teste. Em intervenções menores, somente os relatórios de testes são exigidos, principalmente para evidenciar os testes realizados, na maioria dos casos pelos próprios desenvolvedores. Mas tudo isso faz parte de uma estratégia de melhoria dos nossos processos, que deve alcançar níveis mais elevados de maturidade em breve.

Como tornar a documentação do Teste de Software eficaz?

O Felipe Silva acredita que:

As documentações devem ser efetivas, e sou favor de casos de testes diretos e objetivos – sem steps desnecessários à validação, sei que muitos vão discordar de mim, mas assim que é legal (gerar discussões).

Devemos sempre gerar apenas documentações que serão lidas, digo isso porque já vi casos onde são gerados vários artefatos só pra ficar no repositório (o contrato obriga) e no pior dos casos o próprio processo de testes da organização que diz que tal artefato – que não serve pra nada – deve ser gerado só para mostrar para o cliente, e piora, pois o sistema muda por alguma solicitação de mudança ou versão de requerimento nova e o tal artefato fica do mesmo jeito, nem quem escreve se importa em atualizá-lo pois sabe que ninguém irá usá-lo como base pra nada.

Eu vejo que esse é um grande desafio. Acho que o primeiro passo a fazer é listar quais documentos que estão sendo gerados pela equipe, e responder as seguintes questões (deve ter outras):

• Qual o objetivo desse documento?
• O documento está otimizado? (tem apenas os tópicos adequados para o projeto)
• Alguma sugestão de melhoria para o documento?
• Há alguma dificuldade em manter o documento? (ex.: mudanças de requisitos constantes)
• Há alguma ferramenta que possa auxiliar a criação do documento?
• O tempo levado para a criação do documento é o esperado?
• O documento está armazenado em um local seguro e acessível?
• As pessoas estão seguindo algum padrão para a criação do documento?
• Quais são as pessoas que irão utilizar esse documento? A linguagem está adequada com esse público?

Um segundo passo é tornar a documentação “viva”, ou seja, automatização dos testes, sempre que possível e viável. 🙂

O Eduardo Gomes acredita que:

Qualquer documentação deve ser a mais simples possível, mas que permita o registro das informações que a organização considera imprescindíveis. E nessa análise cada organização deve definir sua documentação básica, mas deve também explicitar a seus colaboradores os objetivos a serem alcançados e as estratégias utilizadas, para que consiga da equipe o comprometimento e a motivação necessários. Sem isso, vai ser realmente “trabalho jogado fora”.

Durante a discussão a Sarah Pimentel colocou três novas questões para esquentar o debate.

Eu posso ao invés de criar test cases, basear meus testes nos requisitos ou user stories?

A própria Sarah respondeu dizendo que:

Essa é uma abordagem estranha pra mim. Me sinto mais confortável com a idéia da criação de uma documentação criada para o propósito de teste. Mas considerando que no caso de uso, requisito ou user story tem todos os fluxos (pode-se assegurar isso com revisões da equipe de teste), é uma documentação que poderia servir como base para testes…

Na minha opinião deixar de criar os casos de teste é um pouco perigoso nesses casos, e quando eu digo criar um caso de teste, pode ser tanto um manual (no Test Link), ou um automatizado (no JUnit, por exemplo).

Mas não vejo problemas em basear os testes nos requisitos, até porque eles são a fonte principal, quando escrevemos testes de aceitação, por exemplo. E as user stories dão uma visão geral da funcionalidade, mas só com ela como base, fica difícil explorar a árvore de possibilidades da funcionalidade, geralmente é preciso ter algum outro documento para apoiar ou conversar diretamente com o desenvolvedor.

E se ao invés de requisitos, documentarmos apenas os testes? Colocarmos as solicitações do cliente não como requisitos mas como cenários de teste? Perderíamos alguma coisa?

O pessoal que pratica BDD (Behavior Driven Development), costuma comentar que é possível utilizá-lo para detalhar os requisitos funcionais. Neste caso você já estaria documentando e escrevendo um teste (e a sintaxe do teste é bem fácil de entender, e há ferramentas, como o Cucumber, que até permitem escrever em português).

Acho que não iremos perder, mas corremos o risco de detalhar muito cedo as coisas. E nem sempre isso é possível, pois o cliente também poderá consultar os requisitos, futuramente, e se estiver em uma linguagem muito técnica, ele poderá ter dificuldade de entender.

Em uma abordagem TDD, como fica a criação de documentação de teste? Ela se torna dispensável em alguns pontos? Passa a ser apenas o Unit Test?

Eu vejo que a documentação passa a ser “viva”, pode ser executada a qualquer momento, e o desenvolvedor terá um rápido feedback se a funcionalidade que ele está desenvolvendo está ou não de acordo com a documentação criada (testes).

Em relação ao documentos gerados, normalmente, por uma equipe de Teste, acho que eles continuar existindo (até porque só estamos documentando os casos de testes de forma automatizada), principalmente, se houver uma equipe de Teste de Software no projeto. E ainda haverão os testes manuais, que necessitarão ser documentados, da forma tradicional. E a própria equipe de Teste de Software, pode deixar de criar um caso de teste no Test Link e automatizá-lo no Selenium, por exemplo, e mesmo assim, a equipe não está deixando de documentar.

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.

3P – Piores Práticas de Projeto (parte 2)

Continuamos falando sobre as piores práticas de projeto, mais uma vez com o intuito de alertar e prevenir tais práticas:

Telefone sem fio – a comunicação é essencial não apenas para a sobrevivência do ser humano, mas como também para a dos projetos. Portanto, devemos estar sempre nos perguntando se a informação está sendo gerada, coletada, documentada e passada para a pessoa certa. Segundo o PMI há quatro processos de gerenciamento das comunicações:

• Planejamento das comunicações – determinação das necessidades  de informações e comunicações das partes interessadas no projeto.
• Distribuição das informações – colocação das informações necessárias à disposição das partes interessadas no projeto no momento adequado.
• Relatório de desempenho – coleta e distribuição das informações sobre o desempenho. Isso inclui o relatório de andamento, medição do progresso e previsão.
• Gerenciar  as partes interessadas – gerenciamento das  comunicações para satisfazer os  requisitos das partes  interessadas no projeto  e resolver problemas com elas.

Eu quero eu posso – Essa é uma prática muito natural, sempre achamos que basta querer para poder realizar ou obter algo. Em projetos devemos avaliar o quanto de esforço que ele demandará e se o time está preparado, caso contrário o projeto terá grandes chances de sofrer atrasos, aumento de custo ou até fracassar. Um exemplo dessa prática foi o Pan de 2007, o maior evento poliesportivo já realizado no país, onde devido a falta de preparo dos realizadores e a problemas políticos o orçamento final ficou 1.289% a mais do que estava previsto inicialmente.

Excesso de documentação – documentação é um dos fantasmas em projetos de TI, isso porque o bom senso muitas vezes não é usado. E quando a equipe do projeto tem grande preocupação em documentar ou a metodologia usada tem como base a geração de documentos para tudo, um risco que aparece é o excesso de documentação, onde podemos ainda estar realizando a análise de risco e o prazo do projeto já ter acabado. Uma das medidas para evitar tal prática é sempre averiguar a importância que a documentação terá para o projeto e o que será documentado e o que não será. Lembrando que mais importante do que documentação gerada é software funcionando.

‘Achômetro’ – por último umas das práticas mais utilizadas não somente em projetos de TI, mas como também na nossa vida. Afinal, o ‘achômetro’ tem como base o conselho que segundo o texto de Mary Schmich, que foi transformado em um discurso musicado por Pedro Bial com o nome Filtro Solar:

Conselho é uma forma de nostalgia. Compartilhar conselhos é um jeito de pescar o passado do lixo, esfregá-lo, repintar as partes feias e reciclar tudo por mais do que vale. (“Advice, like youth, probably just wasted on the young”- Mary Schmich)

Devemos usar o ‘achômetro’ somente em momentos que realmente não teríamos como obter um histórico de dados, como por exemplo, no primeiro projeto de uma recém criada empresa. Sempre que possível, precisamos justificar as nossas ações e estratégias com base em informações e não na opinião própria ou de outras pessoas.

Aqui chego ao fim das 3P, mas com certeza há ainda muitas piores práticas de projetos que não foram citadas. Por isso, caso alguém queira colocar alguma prática que vivenciou ou conhece, por favor sinta-se à vontade. O seu comentário será bem-vindo!

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

Fonte:

Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK); Terceira edição, 2004. Project Management Institute, Four Compus Boulevard, Newton Square, PA 19073-3299 EUA.

http://www1.folha.uol.com.br/folha/esporte/ult92u450247.shtml

3P – Piores Práticas de Projeto (parte 1)

Melhores Práticas de Projeto é um dos temas que mais vem ganhando espaço no mundo de TI, pois percebemos que um bom gerenciamento é fundamental para o sucesso do projeto. Mas se temos as melhores práticas, quais seriam as piores práticas?

Abaixo explico algumas das piores práticas de projeto (3P) que devemos tomar cuidado para não cometemos:

Não envolvimento dos stakeholders – Por mais absurdo que possa parecer, essa é uma das práticas que mais acontecem, na qual um ou mais stakeholders (envolvidos com o projeto) não participam ativamente do projeto, ou participam apenas no início, ocasionando vários problemas, como requisitos mal especificados. Este é uns dos problemas que afetam diretamente o prazo e custo do projeto e em determinados casos, pode até representar o fim de um projeto. Um exemplo de não envolvimento dos stakeholders aconteceu com o projeto do Rodoanel, onde grupos ambientais não foram colocados como stakeholders no início do projeto, e esses acabaram gerando impasses para o governo, resultando em grandes atrasos nas obras e aumento do custo.

Contratação de funcionários, quando o projeto está atrasado –  No desespero, muitos gerentes acabam contratando novos funcionários, quando o prazo do projeto já está com seu prazo vencendo, pois acreditam na teoria de quanto mais pessoas mais produtividade. Porém, na prática a história é outra, esse novo funcionário, por mais habilidoso e experiente que seja, terá que receber um treinamento a ser dado por um funcionário, portanto o projeto perderá um funcionário ao invés de ganhar um. Para entender melhor, seria como você contratar um novo jogador de futebol faltando cinco rodadas para o término do campeonato, por mais habilidoso que ele seja, ele terá o seu tempo de adaptação e se ele for colocado em campo, o desentrosamento pode prejudicar o time.

Falta de documentação – essa é umas práticas mais adotadas pelas empresas, por parecer a curto prazo uma boa prática, pois economizará tempo. Porém, a longo prazo ela pode fazer com que o projeto seja o caos. Imagine a seguinte situação: na empresa XPTO Zé é  programador sênior e responsável por um módulo crítico da aplicação, porém não costuma documentar nada que faz, nem ao menos comenta o código. Um certo dia, Zé consegue um emprego melhor e sai da XPTO. E agora como o projeto continuará sem o Zé? Ele era o único que tinha conhecimento sobre aquele módulo e sem esse módulo o projeto não poderá ser entregue.

É pessoal, vocês podem estarem achando que tal situação apresentada não acontece nas empresas, mas por mais incrível que pareça essa é uma das que mais acontece e que faz muitos dos gerentes “arrancarem os cabelos” (quando ainda tem). Por isso o projeto tem que ser documentado e bem documentado.

Documentar no final – Não sei o que é pior, não documentar ou documentar no final do projeto. Uma documentação feita no final do projeto, por mais esforço que se faça, será fraca e imprecisa e a razão para isso é simples, as pessoas acabam esquecendo o que elas fazem. Para exemplificar uma pergunta clássica: o que você comeu ontem no almoço?

Talvez, você até se lembre do que você comeu ontem, mas e antes de ontem, e na semana passada?

Se eu fosse pedir para você me fazer uma documentação do seu almoço por um mês, ela teria que ser feita antes do almoço, onde você colocaria qual o restaurante que você vai almoçar, qual será o pedido, etc; durante o almoço, situação em que você falaria sobre a qualidade da comida escolhida; e após o término do almoço, você iria descrever como foi o atendimento e quanto custou o almoço.

Logo percebemos que a documentação é uma tarefa que tem que ser feita, durante todo o projeto e não somente durante uma determinada etapa do projeto.

Bem pessoal, por hoje é só. Em breve trarei a segunda parte do 3P. Até a próxima!

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