RELATÓRIO DE EXEMPLO
Cinco riscos. Um plano para a equipa.
Leia um exemplo de Auditoria de Risco Frontend do Magnificent Invoices: o que falha, porque importa e o que a equipa deve fazer a seguir.
PRODUTO FICTÍCIO · CONCLUSÕES ILUSTRATIVAS
Magnificent Invoices, um produto de faturação B2B.
Uma aplicação em React e Next.js com TypeScript. Os clientes abrem ligações para documentos partilhados; a equipa cria, pré-visualiza e guarda faturas. As alterações ao editor tornaram-se difíceis de rever.
O produto, o código e os exemplos abaixo são fictícios. Demonstram o formato e o raciocínio do relatório; não são conclusões sobre clientes nem resultados medidos. Qualquer semelhança com empresas, produtos ou pessoas reais é mera coincidência.
AS CINCO CONCLUSÕES
Corrigir os resultados. Tornar as alterações mais seguras.
Começar pelo acesso aos documentos e pelos totais das faturas (01, 04). Seguir com a validação de dados e o carregamento (05, 02), depois separar o editor com testes já implementados (03).
ACESSO A DOCUMENTOS · CORRIGIR PRIMEIRO
Uma ligação válida mostra uma lista de documentos vazia.
Evidência do exemplo
A ligação usa o nome do cliente como chave de pesquisa. Duas representações Unicode de José parecem iguais, mas não coincidem. Um pedido devolve documentos; o outro devolve HTTP 200 com uma lista vazia.
Jos\u00E9 → documentos encontrados
Jose\u0301 → HTTP 200 · []Porque importa
Os clientes podem confundir uma falha na pesquisa com a ausência de documentos. O ecrã não permite distinguir as duas situações.
Ação recomendada
Usar nas novas ligações o identificador estável do cliente fornecido pela API. Acordar com o responsável pela API o suporte às ligações existentes baseadas no nome e distinguir erros de pesquisa de uma lista realmente vazia.
Como verificar
As duas representações abrem os mesmos documentos. As ligações existentes continuam a funcionar; um cliente desconhecido origina um erro claro.
CARREGAMENTO · SEMANA 2
Abrir a lista também carrega o editor e a exportação.
Evidência do exemplo
No grafo de dependências do exemplo, o módulo da lista de faturas importa o editor e o módulo de exportação PDF. Ambos entram no carregamento inicial, embora a consulta da lista não os utilize.
InvoiceList
→ InvoiceEditor
→ Exportação PDFPorque importa
Cada visita descarrega e processa código para ações que o utilizador pode nunca executar. Isto acrescenta trabalho evitável antes de a lista estar pronta.
Ação recomendada
Carregar o editor quando a edição começar e a biblioteca de PDF existente quando for pedida uma exportação. Mostrar o estado de carregamento, tratar falhas e permitir uma nova tentativa.
Como verificar
Uma nova visita à lista não faz pedidos do editor nem da exportação. Ambas as ações continuam a funcionar. Comparar o JavaScript transferido e o tempo até a lista estar pronta com as mesmas condições de dispositivo, rede e cache.
RISCO DE ALTERAÇÃO · SEMANA 3
O editor interliga cálculos, gravação e estado do ecrã.
Evidência do exemplo
O mesmo componente controla a edição de linhas, as regras de desconto, a gravação e o estado da pré-visualização. Alterar o arredondamento afeta a apresentação e a preparação da gravação; testes isolados exigem montar o editor completo.
InvoiceEditor
linhas + totais + gravação
+ pré-visualizaçãoPorque importa
Uma pequena alteração atravessa vários comportamentos. A revisão tem de abranger uma área maior e as falhas tornam-se mais difíceis de isolar.
Ação recomendada
Antes de reestruturar, escrever testes de comportamento com base nas regras de produto acordadas. Reutilizar o cálculo comum de 04 e separar a gravação. Acrescentar testes unitários dos cálculos e testes de integração da edição, gravação e falhas. Limitar esta fase à separação dos cálculos e da gravação.
Como verificar
Os testes falham perante os defeitos conhecidos e passam após a correção. Um teste de ponta a ponta cobre criar → editar → guardar → reabrir. A reestruturação interna preserva estes testes, porque verificam o comportamento e não os detalhes do componente.
EXATIDÃO DAS FATURAS · CORRIGIR PRIMEIRO
O editor e a pré-visualização mostram totais diferentes.
Evidência do exemplo
Para três linhas de 19,95 € com desconto de 10%, o editor arredonda cada linha; a pré-visualização arredonda depois de as somar. Arredondando as metades para cima, a mesma fatura mostra 53,88 € e 53,87 € antes de impostos.
Editor 53,88 €
Pré-visualização 53,87 €Porque importa
A equipa não pode confiar no total apresentado ao conferir uma fatura. Um cêntimo revela uma divergência nas regras de cálculo.
Ação recomendada
Acordar a regra de arredondamento com os responsáveis pelo produto e pela API. Implementar um cálculo comum ao editor e à pré-visualização, com tratamento explícito dos decimais, e compará-lo com o resultado do servidor.
Como verificar
Os testes cobrem descontos, quantidades e limites de arredondamento. O editor, a pré-visualização e o servidor coincidem nos exemplos aprovados.
VALIDAÇÃO DE DADOS · SEMANA 2
O TypeScript passa. Uma resposta da API faz o ecrã falhar.
Evidência do exemplo
A resposta da API é tratada como Invoice sem validar a sua estrutura. Quando customerName é null, a chamada a trim() lança um erro. Uma asserção de tipo altera o que o compilador assume; não valida a resposta.
const invoice =
(await response.json()) as Invoice;
invoice.customerName.trim();
// API: { customerName: null }Porque importa
Uma compilação bem-sucedida deixa esta falha por detetar. Um único campo inesperado pode impedir a apresentação da fatura.
Ação recomendada
Validar os dados desconhecidos à entrada da aplicação. Representar corretamente os campos que podem ser null, substituir any no percurso afetado e mostrar um erro recuperável quando a resposta é inválida.
Como verificar
Os testes de validação rejeitam dados inválidos e aceitam faturas válidas. Um teste de integração confirma que uma resposta malformada mostra um erro e permite tentar novamente, sem fazer a página falhar.
PLANO ILUSTRATIVO DE 30 DIAS
Uma ordem de trabalho, com verificação em cada etapa.
Este período de planeamento decorre em paralelo com o trabalho habitual da equipa. A equipa deve estimar o esforço e confirmar a disponibilidade antes de assumir datas; a implementação é separada da auditoria.
Semana 1
Garantir ligações e totais fiáveis
CONCLUSÕES 01 + 04
Trabalho
Acrescentar testes de regressão para as ligações e os totais que falham. Corrigir a pesquisa do cliente e acordar uma regra de arredondamento comum ao editor, à pré-visualização e à API.
Concluído quando
As ligações existentes abrem os documentos esperados. Os três percursos de cálculo coincidem nos casos aprovados.
Responsável sugerido: Frontend, com Produto e o responsável pela API
Semana 2
Validar os dados e reduzir o carregamento
CONCLUSÕES 05 + 02
Trabalho
Validar as respostas de faturas e testar a recuperação de erros. Adiar os módulos de edição e exportação; comparar o carregamento antes e depois nas mesmas condições.
Concluído quando
Os dados inválidos têm uma forma clara de recuperação. A lista carrega menos JavaScript e a edição e a exportação continuam a funcionar.
Responsável sugerido: Frontend, com QA
Semana 3
Separar o editor com testes já implementados
CONCLUSÃO 03 · DEPENDE DE 04
Trabalho
Antes de reestruturar, escrever testes com base nas regras acordadas. Separar os cálculos e a gravação. Acrescentar testes unitários e de integração, além da cobertura de criar → editar → guardar → reabrir.
Concluído quando
Os testes detetam os defeitos conhecidos e passam após a correção. Verificam o comportamento esperado sem depender da estrutura interna do editor.
Responsável sugerido: Frontend, com Produto e QA
Semana 4
Verificar as alterações e registar o que falta
CONCLUSÕES 01–05
Trabalho
Repetir os cenários do relatório, rever a comparação do carregamento e verificar o tratamento de erros. Atualizar cada risco com evidências e trabalho ainda por fazer.
Concluído quando
Cada risco fica resolvido, reduzido ou em aberto, com uma justificação, evidências de suporte e um responsável pela próxima ação.
Responsável sugerido: Frontend e QA, com revisão de Produto
Corrigir primeiro o acesso aos documentos e os totais das faturas. Criar testes antes de alterar a estrutura do editor. O trabalho adicional no editor depende do que esta separação limitada revelar.
O que a sua equipa deve conseguir decidir.
Que riscos merecem atenção, porque têm prioridade e como verificar o resultado. Num relatório real, estas decisões dependem do seu produto, das evidências e das restrições acordadas.
Veja o que está incluído na auditoria →Quer esta clareza para o seu produto?
Conte-nos o que preocupa a equipa. Começamos por confirmar se a auditoria se adequa ao caso.
Pedir disponibilidade