Objetivo

Este documento tem objetivo de reunir e disseminar boas práticas de testes no desenvolvimento, para podermos elevar o nível de qualidade das nossas entregas, diminuindo índice de retrabalho na homologação e o índice de reabertura, tornando assim nossas entregas mais assertivas e sem transtornos para o cliente.

Cobertura de Fonte

Devemos criar 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, eliminando assim o risco liberações com erros. É recomendável que nessa bateria de testes seja executada a Cobertura de Código, que consiste em executar todas as linhas do código fonte alteradas 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.

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.

Check list ao Concluir a Codificação

Sempre que 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:

•         Criar e informar a URL do Documento Técnico na Issue
•         Criar e anexar Evidência de Testes na Issue
•         Verificar se Evidência de Testes e Documento Técnico estão com nomenclatura correta
•         Conferir se todas as alterações dos fontes envolvidos estão no TFS
•         Conferir se todas as dependências da rotina estão na Issue
•         Verificar se a CausaNC está devidamente preenchida no TFS
•         Verificar se as informações de Incidente e Solução estão corretamente preenchidas na Issue
•         Atualização do manual da rotina (caso exista)
•         Certificar que o processo de gestão de fontes foi devidamente seguido (para versão 12)
•         Revisar COM CALMA as alterações realizadas no fonte
•         Verificar as alterações de dicionário foram todas aprovadas pelo DBA

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. Sempre ter cadastro consistente e não insira informações diretamente nas tabelas de notas ou do livro, nosso teste deve ser completo, desde o cadastro até a geração dos arquivos.

Alterações de Dicionários

Na versão 11 quando houver alteração de dicionário, faça sempre o teste 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 arquivo .CH que o RoboPatch irá considerar, sem risco de esquecer de cadastrar alguma descrição no ATUSX.

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

Sempre quando criarmos cálculo de novo tributo, 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 alteração;
• 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ários 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.

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;

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 e IPI, 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.

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;
• Sempre acessem a rotina através do menu, pois nas rotinas que possuem variáveis Private não são inicializadas se chamadas através da consulta da rotina no menu;
• Quando houver gravação de 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.