Como usar Confluence e JIRA para rastrear testes de projetos grandes

Em caso de ter chegado aqui esperando encontrar uma postagem sobre ADT ou ATC, peço desculpas por usar uma tag enganosa. O que gostaria de compartilhar neste post do blog são informações sobre testes, não se trata de nenhuma ferramenta ou tecnologia fornecida pela SAP. Em vez disso, é um exemplo de como usar Confluence e JIRA para construir uma ferramenta para rastrear os testes de projetos grandes, como a grande atualização para NW 7.50 com EHP8 e HANA-DB que fizemos recentemente.

Preparando o cenário

Há vários anos, realizamos um grande projeto de conversão para Unicode em um ambiente MDMP com diversos aspectos "interessantes": dezenas de idiomas, incluindo caracteres de dois bytes para chinês e japonês, conversões de páginas de códigos, muitos textos em tabelas em que o idioma do conteúdo nem sempre correspondia à chave do idioma (se existisse). Com a ajuda de algumas ferramentas e muito esforço manual, construímos nosso próprio vocabulário para preparar o sistema da melhor forma possível para a conversão em grande escala de 5 (!) sistemas de produção durante um fim de semana prolongado.

Fonte: XKCD - https://imgs.xkcd.com/comics/unicode.png

Naturalmente, muitas tabelas e, portanto, processos foram afetados e precisavam ser testados, não apenas em um local, mas em mais de 50 países ao redor do mundo. Não tínhamos nenhuma ferramenta para ajudar com isso, apenas um grande número de documentos do Word individuais descrevendo um caso de teste cada um. Isso poderia ser tão simples quanto "imprimir qualquer tipo de documento SD e garantir que o resultado seja legível em seu idioma" até casos de teste mais complexos, que exigiam uma série de atividades, como "executar um processo SD desde a entrada do pedido, passando pela impressão do documento de entrega, até a faturação e finalmente a contabilização em FI". Cada documento continha informações sobre o resultado esperado do teste, bem como caixas para marcar "teste bem-sucedido" ou "problemas encontrados".

Esses documentos foram colocados em um grande arquivo zip e enviados por e-mail para as filiais com instruções para executar os cenários descritos em um sistema de teste e relatar os resultados. Tenho certeza de que você pode imaginar o quão bem isso funcionou e como foi o feedback que recebemos! Em muitos casos, recebíamos de volta apenas um arquivo zip com documentos do Word atualizados, mas sem um resumo indicando o que funcionou e o que não funcionou. Se tivéssemos sorte, alguém teria preenchido uma planilha do Excel anexada, mas na maioria das vezes não. Basicamente, não havia nenhuma maneira de avaliar realmente como os testes estavam sendo realizados e tínhamos que confiar no lema de TI "sem notícias, boas notícias" - se algo tivesse dado muito errado, com certeza teríamos sabido!

Buscando alternativas

Pouco depois do projeto Unicode ter sido concluído com sucesso, tivemos que começar a planejar uma grande atualização do sistema que envolvia a mudança para outro banco de dados e a migração para outro data center. Ficou decidido desde o início que precisávamos de uma maneira muito melhor de organizar os testes, pois não queríamos enviar novamente documentos do Word compactados com quase nenhuma possibilidade de acompanhar adequadamente os resultados. Não tínhamos ferramentas disponíveis como SolMan, que - se não me engano - tem algo para apoiar os testes. Eventualmente, essa busca chegou à minha mesa.

Justo naquele momento, eu havia configurado alguns testes para uma das minhas atividades de lazer relacionadas às mudanças climáticas, onde havia usado formulários do Google para coletar feedback sobre a funcionalidade do novo site/melhorado. O interessante dos formulários do Google é que os resultados são automaticamente inseridos em uma planilha que permite uma filtragem adequada para encontrar problemas relatados e também gera alguns painéis de controle com gráficos circulares e outros gráficos. Usar formulários do Google internamente não era uma opção, mas me deu uma ideia do que poderia construir usando Confluence e JIRA.

Criação de documentos de teste e listas de arquivos

Com base nos documentos do Word que já tínhamos com as descrições dos casos de teste, criei um modelo simplificado que continha apenas campos para um ID de caso de teste, um título, o módulo, a descrição do que deve ser testado e o resultado esperado do teste. As descrições deveriam ser, na maioria dos casos, bastante genéricas, em um nível alto e com a expectativa de que os usuários-chave que conhecem suas tarefas e transações habituais realizariam a maior parte dos testes. A recomendação, por exemplo, era simplesmente indicar: "gerar uma fatura para um pedido padrão", mas sem mencionar números de cliente ou material específicos, pois esses seriam diferentes dependendo de onde o teste fosse realizado, tanto no sistema em que o teste ocorreu quanto no país/organização de vendas para o qual foi realizado. Além de "o que deve ser testado", também era necessário descrever...