Objetivo

Este documento tem objetivo de reunir e disseminar as boas práticas de testes no desenvolvimento, para podermos elevar o nível de qualidade das nossas entregas, diminuindo índice de retrabalho, índice de reabertura, tornando assim nossas entregas mais assertivas. Devemos criar e incentivar o hábito de testar, sempre que concluirmos o desenvolvimento realizar uma bateria de testes, garantindo que o que foi alterado  ou implementado será processado dentro do esperado, diminuindo assim o risco liberações com erros.

Cobertura de Fonte

É recomendável que na bateria de testes seja executada a Cobertura de Código, que consiste em executar todas as linhas alteradas do código fonte pelo menos uma vez, passando por todas as decisões de Verdadeiro e Falso envolvidas, todos os laços envolvidos, testando a execução do laço uma vez, mais de uma vez, e a hipótese de não executar o laço, executando todas as validações ao menos uma vez, etc.

Nosso IDE oferece uma ferramenta que nos apoia com a cobertura de código. Basicamente ela destaca as linhas de códigos que foram processadas no Debug, mostrando de forma clara o trecho de fonte que foi processado. Com a cobertura de código conseguimos perceber se nosso teste realizado foi suficiente para abranger todas as linhas alteradas, caso não tenha sido suficiente, devemos então elaborar mais testes. Abaixo temos um exemplo hipotético:

Podemos identificar que as opções 2, 3 e 4 não foram processadas no teste realizado, o ideal neste caso seria realizar mais testes para executar também estas opções, garantindo que todas as opções irão funcionar.

Check list ao Concluir a Codificação

Ao concluir o processo de codificação, antes de enviar para conferência técnica, faça um check list para garantir que nada foi esquecido. Segue abaixo uma sugestão de pontos importantes a serem verificados:       

Alterações de Dicionários

Na versão 11 quando houver alteração de dicionário, faça sempre o teste da rotina antes da criação de campos, tabelas, índices etc, pois caso o fonte não esteja devidamente protegido, irá causar error log, ou então algum processamento incorreto. Com este teste garantimos que a rotina não vai para de funcionar ou ter algum efeito colateral, caso o cliente não tenha processado o compatibilizador.

Na versão 12 quando houver alteração de dicionário, realizar o teste processando UPDDISTR com diferencial baixado do ATUSX, para realmente certificar se as alterações foram feitas corretamente no ATUSX, e se o UPDDISTR fez corretamente as alterações de dicionário.

Quando precisar criar ou alterar arquivo .CH de descrições, não altere manualmente o .CH local, altere diretamente no ATUSX e teste com arquivo .CH baixado, assim o teste será realizado com o mesmo  .CH que o RoboPatch irá considerar, sem risco de esquecer de cadastrar alguma descrição no ATUSX.

Preenchimento de Cadastros

Sempre realize testes com informações mais próximas do real possível, como CFOP correto, CST de ICMS, IPI, PIS e COFINS regime de tributação, alíquotas etc. Tenha cadastros consistentes e não insira informações diretamente nas tabelas de notas, do livro, dos cadastros, nosso teste deve ser completo, desde o cadastro até a geração dos arquivos. 

Testes na criação e alteração nos cálculos de tributos

Sempre quando criarmos ou alterarmos cálculo de tributo na MATXFIS, devemos nos atentar aos seguintes pontos:

• Testar cálculo no documento de entrada;
• Testar cálculo no documento de saída;
• Testar estornos nas devoluções;
• Testar a visualização da nota e dos itens;
• Testar reprocessamento do livro;
• Testar alteração manual de base de cálculo, alíquota e valor, caso esteja disponível para o tributo;
• Sempre testar com vários itens;
• Testar deleção dos itens, para verificar se os totalizadores estão corretos;
• Se for previsto retenção do tributo, testar sempre nas duas visões, de beneficiário e do responsável do recolhimento;
• Testar com valores de desconto, despesas acessórias, seguros etc, para certificar que estes valores estão sendo considerados corretamente no cálculo do tributo;
• Procure testar sempre nas principais rotinas de escrituração, MATA103, MATA410, MATA461, MATA910 e MATA920, assegurando que não dará error log e que o cálculo será feito corretamente nestas rotinas (quando previsto também para MATA910 e MATA920);
• Certifique de que as informações foram persistidas corretamente no banco de dados, tanto nas tabelas de livro quando nas de documento fiscal;
• Para a versão 11, sempre realize primeiro o teste sem a criação dos campos, para assegurar de que não terá impacto nos clientes que ainda não receberam a atualização de dicionários;
• Verifique se os campos gravados no cabeçalho do livro e das notas foram acumulados corretamente.

Testes na criação e alteração em Arquivos Magnéticos

• Quando houver vários níveis de hierarquia dos registros, testar a geração dos registros em todos os níveis, gerando várias ocorrências de registros “pai” e registros “filhos”.
• Quando criar ou alterar registros com campos onde os valores precisam ser totalizados, testar com movimentações que forcem esta totalização, e verificar se está acumulando os campos corretamente;
• Quando existir campos com quantidade de casas decimais maior que duas, testar se estão gerando com quantidade correta, segundo o layout;
• Realize teste selecionando mais de uma filial, para testar totalizadores e quebras dos registros;
• Nas situações que temos acesso ao programa validador disponibilizado pelo Fisco, sempre importe e valide o arquivo, é fundamental esta validação;
• Nas alterações de layout condicionada a partir de uma data específica, sempre testar antes e após a data descrita no layout, garantindo que o arquivo continuará sendo gerado corretamente antes da data de alteração, isso se deve pelo motivo das gerações retroativas.
• Nas situações onde não temos acesso aos programas validadores, se julgar necessário, verifique a possibilidade de solicitar apoio do cliente para validação do arquivo, já que dependendo do validador, será exigido certificado digital, Número de Inscrição Estadual e senha do cliente, o apoio do cliente nestas situações é muito bem-vindo.

Testes nas alterações das Apurações

• Sempre que houver alteração de regra de cálculo, é recomendado que processe também a geração do arquivo magnético pertinente, principalmente os SPEDs e as Gias, já que os valores das apurações refletem nestas obrigações;
• Nas apurações que possuem possibilidade de inclusão de linha manual, é recomendável o teste incluindo, editando e excluindo linhas, verificando se os totalizados e possíveis saldos estão sendo calculados corretamente;
• Nas alterações que envolver geração de Guias e Títulos, sempre teste apuração com opções de gerar Guia e Título igual a “Sim”, certificando que o valor está sendo gravado no Financeiro corretamente.
• Nas apurações de ICMS, IPI, Iss, PIS e Cofins sempre fazer as alterações e testes em Mono-Thread e Multi-Thread, já que possuímos o código fonte duplicado para o tratamento das Threads.
• Quando houver alteração em tributos que dependem de baixas no Financeiro, sempre realize o teste com baixas integrais e baixas parciais.
• Nas operações de ICMS interestadual, leve em consideração nos testes os cenários onde o contribuinte é inscrito e não inscrito no Estado de destino
• Nas operações de PIS e COFINS, sempre considere nos testes as possibilidades dos regimes, Cumulativo e Não Cumulativo.

Testes na criação e alteração em Relatórios

• Na criação de nova coluna de valor, verificar se está sendo considerada corretamente nos totalizadores;
• Na criação de quebra de páginas, testar com movimentações que forcem esta quebra, para certificar de que a quebra está sendo efetuada corretamente;
• Testar com valores grandes e com centavos, para certificar de que as colunas não ficaram sobrepostas ou com valores truncados;
• Imprimir relatório selecionando mais de uma filial, para verificar se as quebras de páginas e totalizadores estão sendo realizadas corretamente.

Testes em alterações e criações de telas

• Na criação de campos em tela, sempre testar consulta padrão, picture, gatilhos, descrições de help, validação de campo e validações de gravações;
• Quando houver gravação de campo memo (SYP), teste sempre a gravação, edição e exclusão destas informações.
• No modo de edição, verificar se os campos chaves da entidade não estão disponíveis para edição
• Para os campos que possuem consulta padrão, sempre testar de duas maneiras, uma preenchendo campo através da consulta, e outra preenchendo o campo manualmente.