É 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.

About these ads

4 comentários sobre “É 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?

  1. Eu acho que é possível mas não imprescindível realizar documentação com metodologias ágeis. Na minha opinião, realizar testes exploratórios em partes do sistema é arriscado, porque no final das contas, o tester pode esquecer alguma parte. Errar É humano, certo?
    Minha experiência com ágil sempre me permitiu escrever casos de teste, ou no mínimo, um mapa mental, pra eu me assegurar que todos os cenários possíveis e imaginados foram contemplados. Eu particularmente, acho importante ter algum tipo de documento que certifique a equipe de qualidade de que o software foi testado, o que foi testado, quando, em que condições, em qual versão e que erros foram encontrados. Sinceramente, mesmo trabalhando com ágil agora, não me vejo longe dos meus mapas mentais, que me guiam na hora do teste de integração e exploratórios. Este modelo de documentação que uso é simples e me faz garantir de que o meu trabalho foi realizado, se lá na frente me cobrarem. E isso acontece, ah se acontece!!

    Responder
    • Excelente Fernanda!

      Concordo com você. Confiar apenas na nossa memória é muito arriscado, é sempre bom registrar em algum lugar o que testamos e o que tem que ser testado.

      Acho o uso de mapas mentais super válido, pois eles conseguem dá uma visão geral do que precisa ser testado, e você também consegue ter uma visão detalhada, navegando em direção do nó final.

      Outra forma legal de controlar o que está sendo testado é usando um quadro Kanban, pois aí a informação fica disponível de forma bem simples, para todos da equipe.

      Abraços! E obrigado pelo comentário Fernanda!

    • Oi Geralda,

      Você pode usar como base o próprio template do IEEE 829. O “segredo” é adaptar ele para as suas necessidades, seja usando metodologia ágil ou outra metodologia.

      E como comentei no post, você pode até não criar um plano de teste, ou melhor, o plano de teste não precisa ter a forma de um documento em .doc, por exemplo. Ele pode ser feito num quadro, usando post-its por exemplo. Lembre-se, o plano de teste é apenas um artefato de saída da etapa de planejamento, o mais importante é o planejamento em si.

      Abraços!

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