Muitas discussões sobre QA tendem a envolver conceitos e temas grandiosos. Muitos termos técnicos, documentos técnicos e palestras TED. Pode tornar-se bastante abstrato muito rapidamente. E, convenhamos, muitas vezes não é particularmente relevante para os obstáculos práticos que as equipas de QA enfrentam diariamente.
Por isso, por vezes é útil abrandar o ritmo e concentrarmo-nos em alguns dos aspetos mais modestos da disciplina. Neste caso, a documentação de testes. Um tema aparentemente simples, mas, como acontece com tudo o que está relacionado com o desenvolvimento de software, há monstros à espreita por baixo das tábuas do soalho.
A questão de como e quanto escrever na documentação de testes envolve quase imediatamente a QA num dilema do Catch-22. Documentação insuficiente torna difícil saber qual é a sua posição relativamente ao esforço como um todo. E torna ainda mais difícil reatribuir tarefas de teste a diferentes recursos conforme as necessidades o exigem, preservando simultaneamente a consistência dos testes. Mas documentação a mais e — espera. Nunca há documentação de testes a mais, pois não?
Ou há?
Ao longo do tempo, vi muitas equipas de QA iniciarem conscienciosa e diligentemente a tarefa heroica de documentar completamente os seus testes. Para uma versão. E, depois, essa documentação tende a ser deixada de lado. A acumular pó digital algures numa rede. E não porque a equipa de QA tenha deixado de acreditar na sua importância. Simplesmente fica completamente exausta com o esforço necessário para a atualizar para a próxima versão principal.
Porque, no seu zelo, a equipa de QA escreveu descrições de testes incrivelmente detalhadas, decompondo tudo até um nível maníaco de microscopismo e hiperespecificidade. Criando documentação de testes separada para cada faceta ou atributo de uma única funcionalidade ou interação do utilizador. Gerando dezenas de descrições e tarefas de teste individuais para aquilo que é, basicamente, uma única tarefa de teste. É como aquela pessoa que fica à sua frente na fila do supermercado e insiste em pagar 80 $ de compras com moedas de baixo valor.
O resultado deste zelo atomizador é a geração de centenas, por vezes milhares, de descrições de testes para a versão em questão. A QA acabou, sem querer, por escrever um romance de Dickens. Uma História de Dez Mil Cidades. Já leu realmente um desses? Eu também não.
A consequência é que ninguém tem tempo ou paciência para atualizar estas milhares de descrições de testes individuais. Isto porque a prioridade será sempre testar a próxima iteração do software, uma vez que isso acaba por gerar receitas, enquanto a atualização da documentação de testes não gera.
Mas também porque as aplicações de documentação de testes não tornam nada fácil fazer atualizações em massa dos registos de documentação de testes. Fazer alterações globais a classes de testes pode ser árduo e pouco intuitivo na maioria das aplicações (isto também se aplica a muitas aplicações de acompanhamento de defeitos — ainda hoje). O que aumenta os custos em tempo e saúde mental associados a fazê-lo.
Como resultado, toda essa documentação de testes meticulosa acaba por ser abandonada. E todo o tempo despendido a criá-la é, em última análise, desperdiçado. Porque não é reutilizável. É um sucesso de uma só vez. É o “I Melt With You” dos testes de software. No entanto, a documentação de testes é uma necessidade absoluta para um esforço de testes repetível e sistemático. Daí o dilema do Catch-22.
Há uma saída para este dilema. E, por muito que me custe admiti-lo, devemos procurar a solução na engenharia. Ou, pelo menos, a sua inspiração. Os engenheiros enfrentaram um problema semelhante nos primeiros anos do desenvolvimento comercial de software. Devido às limitações das linguagens de programação da época, tinham de reescrever, para cada função, o código correspondente aos mesmos atributos básicos, ações e salvaguardas. Repetidamente. A gestão de memória/recolha de lixo era um bom (e perigoso) exemplo deste problema.
Como resultado, os engenheiros geraram enormes quantidades de código redundante e desperdiçaram enormes quantidades de tempo (não que os engenheiros se importem necessariamente com esta última parte. O Ebay ainda existe por alguma razão.). Depois, alguém inteligente teve a ideia da programação orientada a objetos, na qual podiam ser criados objetos de código que herdavam atributos predefinidos pela sua própria natureza. O mesmo código não tinha de ser escrito (ou copiado e colado) sempre que necessário. O que significava que a qualidade já não dependia da memória ou das capacidades de dactilografia de um engenheiro específico. Pelo que a QA estará eternamente grata.
Esta é uma visão muito útil para a QA enquanto lida com o beco sem saída da documentação de testes. O conceito de orientação a objetos, tal como existe na engenharia, não pode ser aplicado diretamente a este problema, mas, enquanto metáfora, tem muito para oferecer. A criatividade, por definição, adapta-se facilmente a novas situações.
Ao longo da minha carreira, deparei-me muitas vezes com o problema de como criar documentação de testes abrangente, mas concisa, acionável no momento, mas também facilmente reutilizável em versões futuras. E a solução a que finalmente cheguei consiste em aplicar a ideia de um “objeto” à própria documentação de testes.
Aqui estou a falar de muito mais do que um modelo de documentação de testes. Estes modelos são, evidentemente, muito úteis como ferramenta de normalização, mas são irrelevantes para o problema em questão. Desenvolvi a ideia de que os testes podiam ser documentados de uma forma que incluísse, numa única peça de documentação, todos os seus vários modos, pontos de inflexão, fluxos de trabalho e condições especiais. Quando esta lâmpada se acendeu na minha cabeça pouco iluminada, a resposta pareceu subitamente muito simples. E muito viável.
Vamos então abordar o assunto.
Tomar a pílula vermelha
A resposta consiste em encarar qualquer teste individual, e, por conseguinte, também o seu artefacto de documentação, não como a afirmação/descrição de testes relativamente a um único ponto de dados ou a uma condição isolada. Mas sim como uma descrição de toda a matriz (estão a ver o que fiz?) de condições em que a funcionalidade ou capacidade precisa de ser validada.
Isto envolve uma abordagem holística à definição de testes individuais. Uma tarefa de teste coerente e única não pode ser dividida de forma útil em dezenas de "testes" independentes sem, paradoxalmente, apagar a especificidade ao testar a funcionalidade como um todo. É uma situação de não conseguir ver a floresta por causa das árvores.
Aqui, é útil rever o conceito de contexto de teste. Porque, para implementar eficazmente a ideia de um objecto de teste, tem primeiro de ser capaz de separar o núcleo imutável de uma determinada funcionalidade dos seus contextos secundários de aplicação e operação. Esta é uma questão que o estilo atómico da documentação de testes evita, pelo que os testadores nunca aprendem a realizar esta análise de forma sistemática e consciente. Mais uma desvantagem do poder atómico.
Dito de forma simples, os contextos de teste de uma funcionalidade ou sistema são o conjunto de condições, ambientes, fluxos de trabalho ou estados que podem variar independentemente uns dos outros dentro dos limites da própria funcionalidade. Os sistemas operativos e as versões dos sistemas operativos são um exemplo claro disso. As línguas estrangeiras são outro. Os estados do sistema são mais um (ou seja, no caso de um servidor Web, a colocação em cache da memória estar activada ou desactivada). Depois de compreender esta distinção, pode facilmente pensar em muitos outros relevantes para os tipos de produtos que está a testar.
Depois de concluir esta análise (que, de qualquer modo, deveria ser a base de todo o planeamento profissional de testes), terá então a capacidade de criar formas compactas de documentação de testes que incorporam esta distinção. No sistema que estou a descrever, um único artefacto de documentação de testes será composto por:
- Uma descrição da funcionalidade ou capacidade principal que está a ser testada.
- Uma lista de todos os contextos nos quais a funcionalidade principal tem de ser validada.
- Qualquer outro elemento que normalmente teria incluído de qualquer forma (pré-condições para que o teste seja válido, recursos e privilégios do sistema necessários para executar o teste, uma ligação para os requisitos relevantes do produto, etc.). Nenhum destes elementos é substituído pelo que estou a propor.
Neste momento, poderá estar a pensar: "Isso pode significar muitos contextos!" Bem, sim. Mas veja as coisas desta forma. Fazer isto assim não lhe cria mais trabalho. Na verdade, reduz o trabalho. Elaborar planos de teste abrangentes torna-se mais fácil com a nossa lista seleccionada de ferramentas de teste de software para documentação. Isto porque este método irá reduzir *significativamente* o número de testes individuais que terá de dedicar tempo a criar e que terá de manter (ou não) no futuro. Já no sistema atómico, teria de criar um artefacto de documentação de testes individual para cada um deles. O que conduz ao dilema descrito no início deste artigo.
Este método de documentação de testes tem, de facto, determinadas consequências processuais que podem, à primeira vista, parecer inconvenientes. Ou até perturbadoras. E não apenas para a QA, mas também para outras partes interessadas no projecto. No entanto, se todos os envolvidos dedicarem tempo a compreendê-las, verão que são realmente melhorias. Para todos.
A principal é que, ao incluir a matriz de contextos da funcionalidade no próprio teste principal, isto significa, logicamente, que se esse único teste falhar em qualquer um desses contextos, então todo o teste falhou. Mesmo que seja apenas num. Consigo imaginar que isto provoque pânico entre as equipas de engenharia. Porque pode parecer que está a jogar contra elas, elevando a fasquia para um nível impossível para que um teste seja considerado "aprovado". Mas este receio é facilmente dissipado. Basta apontar-lhes duas coisas, e uma terceira a si próprio:
- Este método irá, na realidade, reduzir o número de erros gerados pelo teste do trabalho dessas equipas. Isto porque, com o método atómico, a falha de qualquer um desses contextos teria gerado o seu próprio erro separado. Aumentando assim o número total de erros associados a essa única funcionalidade. Isto deverá pôr um sorriso no rosto dos engenheiros. E dos gestores de projecto.
- Em segundo lugar, testar utilizando esta metodologia fornece automaticamente o contexto para o verdadeiro âmbito da falha funcional. Porque qual é a primeira pergunta que o engenheiro encarregado de corrigir o erro lhe fará sempre? "Hum, bem, isso acontece em todo o lado? Ou apenas no contexto X?" E, em vez de ter de voltar a correr apressadamente para a sua secretária e repetir o teste no contexto X (porque talvez se tenha esquecido de o fazer durante os testes originais?), já terá essa resposta, e o engenheiro ficará sem uma desculpa para evitar trabalhar no assunto (o que a QA dá em menos erros, retira mais tarde).
- Em terceiro lugar, a análise de contexto da documentação de testes garante que realmente pensou em todos os contextos relevantes ao documentar o teste inicialmente. Isto significa que terá menos probabilidades de passar por aqueles momentos de pânico — três dias antes ou, pior ainda, depois do lançamento — em que percebeu que se esqueceu de testar alguns contextos muito importantes. Um esforço de QA baseado no pânico não é muito eficaz. Nem é uma experiência particularmente agradável do ponto de vista psicológico.
Na máquina
Este método de documentação de testes inspirado em objectos reduzirá drasticamente a quantidade de artefactos de documentação que terá de produzir e, por conseguinte, tornará mais provável que consiga — e queira — actualizá-los continuamente para versões futuras.
A única dificuldade é que poucas aplicações de documentação de testes estão preparadas para documentar testes desta forma de origem. Tendem a assumir o modelo atómico de documentação, uma vez que, infelizmente, é a norma, e, por isso, não têm funcionalidades integradas que permitam acomodar facilmente o modelo de objectos que descrevi aqui.
É por isso que, muitas vezes, tenho recorrido a soluções de aplicação muito menos elaboradas — como o Excel — que são, na realidade, para este efeito, muito mais flexíveis e fáceis de personalizar, por serem de utilização geral. A desvantagem dessa estratégia é que a sua integração com o Jira, entre outros, se torna complicada. Mas talvez a integração seja sobrevalorizada.
De qualquer forma, continua a ser um problema o facto de muitas aplicações de testes e de documentação de defeitos tornarem extremamente difícil efetuar atualizações em lote de registos individuais. Independentemente dos protocolos que se escolham para os criar. Mas isso é verdade, seja qual for a forma escolhida para redigir a documentação dos testes. Um problema de cada vez, pessoal.
Peço desde já desculpa (ou, no seu caso, peço desculpa retrospetivamente) por não lhe fornecer um modelo de objeto de teste. A minha experiência diz-me que fornecer modelos é normalmente uma má ideia, porque as pessoas começam simplesmente a utilizar o seu modelo. A disponibilidade de modelos genéricos prontos a utilizar tende a antecipar e a limitar a criatividade da própria equipa na criação de um modelo que esteja de acordo com as suas necessidades, processos e ferramentas reais. Por isso, não leve a mal.
Estou sempre disponível para responder às suas perguntas e sugestões. Basta publicá-las ou enviar-mas por mensagem no LinkedIn.
E, como sempre, boa sorte.