Capítulo 30 — Laboratório de verificação I | Engenharia Inteligência de ameaças e OSINT

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 30 publicada. Mapa, exemplo, EX088.

flowchart TD
  N0["30.1 Verificação versus validação"]
  N1["30.2 Procedimentos"]
  N2["30.3 Cobertura"]
  N3["30.4 Desvios"]
  N4["30.5 Evidências"]
  N5["Suíte de regressão"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX088"]

Desenho lógico

flowchart LR
  N0["30.1 Verificação versus validação"]
  N1["30.2 Procedimentos"]
  N2["30.3 Cobertura"]
  N3["30.4 Desvios"]
  N4["30.5 Evidências"]
  N5["Suíte de regressão"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX088"]

[30.1 Verificação versus validação]
    |
    v
[30.2 Procedimentos]
    |
    v
[30.3 Cobertura]
    |
    v
[30.4 Desvios]
    |
    v
[30.5 Evidências]
    |
    v
[Suíte de regressão]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX088]

Objetivos de aprendizagem

Você vai (1) escrever procedimentos de verificação rastreáveis até os requisitos; (2) executá-los com dados sintéticos; (3) registrar resultados de aprovação, falha e desvio; (4) distinguir verificação ("construído certo") de validação ("a coisa certa").

30.1 Verificação versus validação

A verificação confere se o Lantern atende aos requisitos escritos. A validação, no Capítulo 38, confere se ele atende às necessidades reais das partes interessadas. Uma plataforma pode passar na verificação e ainda falhar na validação se os requisitos estiverem errados. Kofi mantém as duas atividades em planos separados, com responsáveis separados. A verificação é conduzida pela equipe de engenharia contra o documento de requisitos. A validação envolve as pessoas que usam o Lantern e pergunta se ele ajuda no trabalho delas. Um requisito que passa na verificação, mas falha na validação, é evidência de que o próprio requisito precisa mudar.

30.2 Procedimentos

Cada procedimento indica o requisito, as pré-condições, os passos, o resultado esperado e os critérios de aprovação. "Carregar o pacote S-07 com 1.000 indicadores, dos quais 12 sem valid_from válido; esperar 988 armazenados e 12 rejeitados com motivo; aprovar se as contagens baterem exatamente." O exemplo mostra o nível de detalhe necessário: um pacote nomeado, contagens exatas e uma regra de aprovação clara. Duas pessoas que o sigam devem obter o mesmo resultado. Kofi escreve o procedimento antes de executá-lo, para que o resultado esperado não possa ser moldado pelo que o sistema por acaso produzir no dia.

30.3 Cobertura

A matriz de rastreabilidade mostra quais requisitos têm procedimentos. Requisitos descobertos são listados explicitamente; um requisito não testado é um risco aberto, não uma aprovação silenciosa. O relatório de cobertura de Kofi lista cada requisito com seus procedimentos e seu último resultado. Na primeira execução, vários requisitos não tinham procedimento, a maioria não funcionais, como a retenção. Cada lacuna foi preenchida com um procedimento ou registrada como risco aceito, com responsável e data de revisão. Ninguém podia marcar como atendido um requisito não testado.

30.4 Desvios

Quando um resultado difere, registre um desvio com severidade e responsável. Não edite o resultado esperado para casar com a saída sem uma mudança de requisito. Cada desvio registra o procedimento, o que era esperado, o que aconteceu e a evidência. A severidade segue o efeito sobre os usuários: uma falha na barreira de TLP é alta porque poderia vazar dados restritos; uma métrica ausente é menor. Kofi revisa semanalmente com a equipe os desvios abertos e só fecha cada um depois que o procedimento foi executado de novo e aprovado.

30.5 Evidências

Registros, instantâneos de métricas e hashes das saídas são armazenados com a execução do procedimento. Um revisor pode executar o mesmo procedimento com os mesmos dados sintéticos e comparar os hashes. Os hashes tornam a comparação rápida: se o arquivo de saída tem o mesmo hash da execução armazenada, o resultado é idêntico. Kofi guarda os dados sintéticos, a versão do código e a configuração com cada execução, para que um revisor meses depois possa reproduzi-la exatamente. Evidências que não podem ser reproduzidas pesam muito menos em uma auditoria.

Suíte de regressão

Procedimentos aprovados viram testes de regressão automatizados executados a cada mudança. A suíte cresce com cada defeito corrigido, de modo que o mesmo erro não pode voltar em silêncio. Kofi marca cada teste com o ID de seu requisito, o que mantém a matriz de rastreabilidade atualizada sem esforço manual e mostra num relance quais requisitos perderam cobertura quando um teste foi removido.

Exemplo resolvido

Kofi executa 42 procedimentos. 38 passam, 3 falham (a barreira de TLP permitiu um rótulo com espaço no final; faltou o motivo de rejeição para um tipo de erro; a métrica do ponto de controle não foi exportada) e 1 fica bloqueado pela falta de um dado de teste. Cada falha vira um defeito com responsável; o bloqueado é agendado.

Caso sintético. As contagens e os defeitos são inventados.

Erros e limites

Uma execução de testes toda verde com dados sintéticos não prova robustez diante de todos os formatos de parceiros; amplie os dados de teste à medida que surgem formatos. Não conte procedimentos bloqueados como aprovados.

Exercícios

EX088 — V e V. Em uma frase cada, defina verificação e validação.
Mostrar critérios de avaliação
Rubrica: 3 = construído conforme os requisitos; atende às necessidades reais; 2 = uma; 1 = trocadas; 0 = nenhuma.
EX089 — Espaço no final. Por que uma barreira de TLP que aceita "TLP:AMBER " (com um espaço) é um defeito?
Mostrar critérios de avaliação
Rubrica: 3 = tratamento inconsistente do rótulo; deveria normalizar ou falhar fechado conforme o requisito; 2 = parcial; 1 = inofensivo; 0 = nenhuma.
EX090 — Contagem do bloqueado. Como o procedimento bloqueado deve ser relatado?
Mostrar critérios de avaliação
Rubrica: 3 = à parte, como bloqueado/não executado, com plano; não é aprovação; 2 = não aprovado; 1 = aprovado; 0 = nenhuma.

Síntese

Verifique contra os requisitos escritos com procedimentos rastreáveis, registre os desvios com honestidade e mantenha as evidências reexecutáveis.

Continue estudando — capítulo 30 de 50

← Capítulo 29 (rascunho) · Índice de capítulos do curso · Capítulo 31 (rascunho) →