Risco e proporcionalidade
Nesta aula
Escolher o rigor pelo efeito da falha
Risco descreve a possibilidade de uma falha e suas consequências no contexto. Probabilidade e impacto orientam a avaliação; capacidade de detectar o problema e possibilidade de desfazer seus efeitos ajudam a escolher a resposta. Não é necessário multiplicar notas arbitrárias para produzir um número aparentemente preciso. É necessário explicar qual falha preocupa, quem sofre seu efeito e qual evidência reduz a incerteza.
A Oficina Caracol usa dados fictícios e não registra informações pessoais. Isso reduz certos impactos, mas não elimina riscos de software: um inativo pode ser entregue, uma falha pode parecer lista vazia ou uma repetição de reserva pode produzir dois efeitos. O tratamento deve corresponder ao problema real. Acrescentar uma senha inexistente ou uma política corporativa copiada não resolveria esses casos.
Proporcionalidade significa escolher controle suficiente para o custo de falhar. O perfil Essencial preserva escopo, entrada clara, inventário, verificações de fluxo, gate e recuperação demonstrável dentro do ambiente de estudo. Estruturado amplia coordenação, automação, ambientes, observação e continuidade quando equipe e dados o exigem. Crítico envolve impacto elevado e controles especializados, inclusive revisão independente e recuperação testada no contexto apropriado. O kit didático não constitui uma certificação para esse terceiro perfil.
Ampliar diagrama Registro de riscos preenchido
A tabela apresenta estimativas qualitativas para discussão do projeto, não taxas medidas. Uma ocorrência pode alterar a estimativa. O responsável de cada linha é o mantenedor da Oficina, enquanto não houver divisão real de papéis; isso deve ser atualizado se outras pessoas assumirem o trabalho.
| Risco | Impacto e detecção | Tratamento e evidência |
|---|---|---|
| R-CAT-01 Inativo exposto | Quebra de REQ-002; captura visual pode não detectar entrega pela API | Selecionar e projetar campos públicos; teste do módulo e HTTP |
| R-CAT-02 Repetição cria reserva duplicada | Quebra da simulação de REQ-005; contador revela o efeito | Conservar a chave da intenção entre tentativas; provar um único efeito e conflito de reutilização |
| R-CAT-03 Falha tratada como vazio | Usuário recebe interpretação incorreta; pode passar despercebido | Distinguir vazio e erro na interface; verificar ambos |
| R-CAT-04 Recuperação altera o arquivo fonte | Perda do dado de referência; efeito evitável no exercício | Restringir snapshot e restore a sandbox/recuperacao; conferir isolamento |
A resposta de R-CAT-02 não é repetir mais vezes. É preservar a identidade da operação e demonstrar seu efeito único no escopo da simulação. A resposta de R-CAT-04 não é um lembrete genérico para ter cuidado: o comando deve limitar seu alcance tecnicamente. O registro informa a decisão; os testes e a inspeção confirmam se a limitação realmente existe.
Procedimento de avaliação
- Descreva uma falha concreta com causa plausível e consequência, evitando rótulos vagos como sistema inseguro.
- Identifique a exposição e os critérios atingidos; registre o que ainda é desconhecido.
- Escolha prevenir, detectar, limitar, recuperar ou aceitar o risco, com motivo e responsável.
- Defina a evidência que confirma o controle e a condição que torna o risco impeditivo.
- Reavalie após mudança de dados, uso, equipe ou impacto. Um perfil não deve permanecer fixo quando seu contexto desaparece.
Erros e reparos
| Erro | Reparo correspondente |
|---|---|
| Tratar dado fictício como ausência de risco | Examinar integridade, fluxo, efeitos e recuperação, além de privacidade |
| Copiar controle sem relação com a falha | Vincular cada controle a uma consequência e uma prova |
| Aceitar risco sem autoridade ou limite | Identificar responsável, justificativa, alcance e revisão |
| Usar a mesma checklist para qualquer impacto | Ajustar o perfil e buscar competência especializada quando o contexto exigir |
Exercício e solução
Dados: o projeto de estudo será reaproveitado como serviço de reservas real, com nome e telefone, persistência e confirmação a clientes. O responsável quer manter a avaliação anterior porque o código da tela parece igual. Que decisão deve preceder o reaproveitamento?
Ver solução comentada
Solução: abrir nova análise de escopo e risco. Surgem dados pessoais, persistência, autorização, confiabilidade de operação e recuperação fora do sandbox. O perfil e as competências necessárias precisam ser revistos. A simulação em memória não é reserva real nem demonstra esses controles. Não basta aumentar uma nota: é necessário definir requisitos, arquitetura, responsabilidades e provas antes de autorizar o novo uso.
- Rubrica: identificar ao menos três mudanças de consequência ou controle; recusar a equivalência entre mesma tela e mesmo risco; explicar por que o kit não autoriza o uso real.
- Gate: riscos relevantes têm tratamento, responsável e evidência aceitável; falhas impeditivas não são convertidas em ressalvas apenas para manter uma data.
Leitura relacionada
S16, gestão de riscos no planejamento de testes, e S03, práticas PO.1 e PO.4, apoiam a relação entre requisitos, critérios e verificação. Esses referenciais não tornam a estimativa didática uma medição estatística.
Fontes relacionadas
Consulte os limites e as seções de apoio de cada referência.
S16 S03Tente o exercício antes de consultar a solução. Marque a aula para organizar sua leitura.
A conclusão desta leitura não equivale a certificação ou aceite de um projeto real. Teste os exemplos no escopo indicado e registre as limitações.