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.
