Metodologia: do Mapa de Processos aos Cenários de Teste
Este documento explica como chegamos aos quinze cenários de teste e por que cada um deles é uma cadeia de atividades, nunca um teste isolado. É a justificativa, ponta a ponta, de tudo que está reunido no Mapa de Processos e na Tabela de Cenários.
1 Do mapa aos cenários, partindo do geral
O ponto de partida deste plano não foi uma lista de testes, foi o Mapa de Processos. Primeiro desenhamos a cadeia de valor macro da migração, os onze elos que vão do cadastro ao fechamento contábil. Só depois de validar esse desenho é que cada elo foi desdobrado em etapas, totalizando trinta e três ao todo, incluindo as etapas fiscais aprofundadas de entrada e de saída de nota.
Foi só com essa árvore completa de processos em mãos, sempre partindo do macro para só então chegar ao micro, que os cenários de teste puderam ser desenhados. Essa ordem importa porque garante que nenhuma parte real da operação da loja fica de fora simplesmente porque ninguém se lembrou de testar aquilo. Cada cenário nasce de uma pergunta simples: que comportamento de sistema precisa ser validado nesta etapa do mapa?
2 Por que cenários encadeados, não testes isolados
Testar isoladamente se a nota fiscal foi emitida não garante que o valor chegue certo no financeiro, que a comissão seja recalculada quando há devolução, ou que o balancete feche depois. Um teste pontual prova apenas que uma peça funciona sozinha; não prova que a jornada de negócio inteira funciona.
Por isso, cada um dos quinze cenários de teste percorre a cadeia real de um evento de negócio, tocando todas as áreas que aquele evento realmente afeta, exatamente como vai acontecer na loja de verdade. O cenário "Fluxo padrão ponta a ponta" é o exemplo mais direto disso: uma única venda comum atravessa oito das onze áreas do mapa, passando por cadastro, compra, recebimento, fiscal de entrada, estoque, venda, fiscal de saída e fechamento, numa validação só, porque é exatamente isso que uma venda de verdade faz.
Na primeira versão deste plano, boa parte dos "cenários" testava apenas um ponto da cadeia de cada vez. Revisamos e reagrupamos tudo: vinte e cinco dos trinta e oito itens daquela versão tocavam uma única área, e foram fundidos em cadeias reais ou viraram pré-requisito de checklist, deixando de figurar como cenário de teste.
3 Como cada cenário nasceu do mapa
Cada um dos quinze cenários foi derivado de uma ou mais etapas do Mapa de Processos, nunca inventado do zero. Dois exemplos concretos ajudam a mostrar essa lógica na prática.
Cenário 6: Primeira operação numa UF nova
Este cenário nasceu de quatro etapas espalhadas em quatro elos diferentes do mapa: cadastro da tributação da UF, entrada de nota fiscal, precificação e emissão fiscal de saída. Abrir uma UF nova é, na prática, um evento que atravessa essas quatro frentes ao mesmo tempo, e testar apenas uma delas não provaria que a loja pode realmente abrir.
Cenário 9: Operação completa de caixa
Este nasceu de cinco etapas: cadastro de perfil de acesso, identificação do operador, abertura de caixa, fechamento do cupom e fechamento de caixa com Redução Z. Elas foram reunidas num só cenário porque o mesmo controle de acesso precisa valer em toda ação sensível do caixa, não apenas na abertura.
Onde o mapa revelou uma lacuna real, sem etapa correspondente na versão anterior do plano, como um cupom com produtos de natureza fiscal diferente numa mesma venda, um cenário novo foi desenhado do zero, mantendo a mesma disciplina de encadeamento (Cenário 5). E onde o mapa revelou o oposto, um cenário redundante com o "Fluxo padrão" ou apoiado numa premissa que não existe no negócio real da Bel, já que a empresa não importa produtos diretamente, o cenário foi cortado em vez de mantido só para preencher espaço.