Software Quality Evidence: The Gap That Costs

A evidência de qualidade de software não é a mesma coisa que um programa de testes, e a diferença é aquilo que a primeira revisão de supervisão a sério tende a expor. A maioria das instituições financeiras reguladas tem engenheiros de QA, suites de testes, pipelines de CI/CD e dashboards a verde. Bem menos têm evidência.

Um programa de testes diz se o software funciona. A evidência diz a um supervisor, a um auditor ou a uma autoridade nacional competente que os sistemas certos foram testados, da forma certa, no momento certo, com a supervisão certa, e que os resultados foram revistos por pessoas com autoridade para confirmar que eram adequados. O custo da conformidade em sectores regulados vive sobretudo nessa lacuna e não nos testes em si.

Abaixo explicamos o que é essa lacuna, o que custa, por que persiste e o que fechá-la exige realmente.

Classificação

Sem demora indevida, e dentro de 24h após tomar conhecimento

4 horas

Notificação inicial, contada a partir da classificação como grave

72 horas

Relatório intermédio com âmbito, contenção e progresso da causa raiz

1 mês

Relatório final com causa raiz completa e remediação

O que os supervisores pedem e uma suite de testes não responde

O DORA passou da preparação para a revisão ativa de supervisão durante 2026, o que tornou esta distinção visível de uma forma que antes não era. As autoridades nacionais competentes já não estão a verificar se as instituições têm um programa de testes. Estão a verificar se esse programa produz registos que aguentam exame.

Um pedido expõe a lacuna com mais clareza do que qualquer outro, e os supervisores fazem-no hoje em várias formulações: apresente a evidência de testes de resiliência dos seus três sistemas TIC mais críticos. Não os resultados dos testes. Um registo completo e rastreável do que foi testado, por que razão, quando, por quem, com que resultado e quem confirmou que o resultado era adequado. O Capítulo IV do Regulamento (UE) 2022/2554Artigos 24 a 27, é onde a obrigação assenta.

Nas instituições com infraestrutura de evidência madura, esse pedido resolve-se em minutos. Onde os testes são bem feitos mas a camada de evidência foi montada a partir de registos de CI/CD e folhas de cálculo, o mesmo pedido desencadeia dias de trabalho manual. Os resultados chegam incompletos e com formatação inconsistente, o que cria um segundo problema: um supervisor a ler um dossiê montado às pressas está agora a avaliar as práticas de gestão de evidência a par das práticas de teste.

O pedido não é "mostre-me os seus testes". É "mostre-me que os testes certos aconteceram e que alguém responsável concordou que eram suficientes".

Por que existe a lacuna na evidência de qualidade de software

A lacuna não é negligência. É o resultado previsível da forma como a infraestrutura de testes evoluiu antes de existirem requisitos regulatórios de evidência.

Feito para isto

A pergunta de engenharia

O software funciona? O Selenium, o JUnit, o Playwright e os pipelines de CI/CD respondem-lhe com eficiência, produzindo registos de execução, contagens de passa e falha, percentagens de cobertura e stack traces. São os resultados certos, e a maioria das organizações construiu bem esta camada.

Não feito para isto

A pergunta regulatória

Consegue demonstrar, a um nível que sobrevive a um exame, que os sistemas TIC críticos foram testados em linha com as suas obrigações, com supervisão adequada e com resultados revistos por indivíduos responsáveis? Uma percentagem de cobertura não responde a isso.

A segunda pergunta exige uma camada que ligue testes a requisitos, mantenha a cadeia de aprovação, guarde registos de forma imutável e os devolva quando pedidos. Na maioria das organizações essa camada nunca foi construída, foi construída de forma diferente por cada equipa, ou foi construída como rotina manual.

Por que as camadas manuais de evidência falham

Processos manuais que dependem da disciplina individual não sobrevivem a saídas de pessoas, reorganizações de equipa nem aos prazos comprimidos de um pedido de supervisão. Falham também em silêncio. Ninguém repara que a folha de aprovações deixou de ser atualizada em março até alguém pedir os registos de março em outubro. É esse intervalo entre a falha e a descoberta que torna a abordagem manual mais arriscada do que parece num organograma.

O que custa a lacuna na evidência de qualidade de software

O custo materializa-se de três formas, e nenhuma delas aparece numa rubrica orçamental chamada testes.

Preparação para supervisão. Cada revisão ou pedido implica reunir evidência de onde ela estiver, normalmente com QA, conformidade e o tempo do próprio CTO. Dias a semanas, consumidos por pessoas caras, a repetir-se em cada interação regulatória. Não diminui com o tempo enquanto a infraestrutura não mudar.

Resposta a incidentes. Classificar um incidente como grave exige saber qual é o sistema afetado, o que depende dele e o que os testes recentes mostraram. Uma instituição que não consegue recuperar isso depressa está a tomar a decisão de classificação, que arranca o relógio das 4 horas, com informação incompleta.

Risco de supervisão acumulado. Uma instituição que produz repetidamente registos incompletos ou inconsistentes constrói uma relação marcada por preocupação e não por confiança. Isso condiciona a intensidade da supervisão futura e o tipo de pedidos de seguimento. Difícil de quantificar, e acumula.

Há também uma data previsível que vale a pena ter no calendário. O Registo de Informação é submetido anualmente até 30 de abril, pelo que existe pelo menos um exercício de evidência por ano, com ou sem revisão agendada.

A evidência de testes da sua instituição está pronta para uma revisão de supervisão hoje, e não depois de duas semanas de recolha?

Fale com a nossa equipa

Os quatro requisitos da infraestrutura de evidência de qualidade de software

Fechar a lacuna é sobretudo uma decisão de arquitetura sobre onde vive a evidência, quem é o seu dono e como é produzida. Quatro requisitos fazem o trabalho.

Requisito 1

Rastreabilidade do requisito até ao teste

Cada caso de teste ligado ao requisito ou à função TIC que verifica, como relação estrutural e não como documento que alguém mantém. Altere um requisito e os testes afetados ficam imediatamente identificáveis. Quando um supervisor pergunta que testes cobrem um Artigo específico, a resposta não precisa de cruzamento manual.

Requisito 2

Fluxo de aprovação com governação

Um registo de execução por si só não é evidência. Precisa de aprovação por alguém com a autoridade e a responsabilidade para confirmar que o resultado é adequado ao seu fim regulatório. Controlo de acessos por papel aplicado à função de QA, com aprovações datadas, atribuídas e imutáveis.

Requisito 3

Armazenamento imutável com retenção

Registos guardados de forma que não possam ser alterados depois, com períodos de retenção alinhados com as obrigações da instituição. Um log de CI/CD rodado ao fim de 90 dias não é um registo de evidência, por muito bem que tenha documentado a execução na altura.

Requisito 4

Recuperação em formato para supervisão

Exportável como documento estruturado que apresenta o requisito, os casos de teste, os registos de execução, a cadeia de aprovação e a conclusão. Não um relatório escrito à mão quando pedem, mas o resultado natural de um sistema que estruturou a informação no momento da captura.

As instituições que já fazem testes de resiliência DORA. costumam ter o primeiro requisito parcialmente resolvido. A maioria dos programas quebra na cadeia de aprovação.

Um caminho de 90 dias para a evidência de qualidade de software

Ninguém reconstrói uma camada de evidência num trimestre. O que cabe num trimestre é estrutura suficiente para sobreviver ao próximo pedido, por isso a sequência abaixo está ordenada pelo que reduz exposição mais depressa e não pelo que é mais completo

Semanas 1 a 2: escolher três sistemas. Pegue nos sistemas com maior probabilidade de aparecer num pedido de supervisão, o que normalmente significa os que suportam funções críticas ou importantes. Limite o exercício a esses em vez de tentar todo o parque, porque uma cadeia completa para três sistemas vale mais do que uma cadeia parcial para trinta.

Semanas 3 a 5: fazer o teste de recuperação. Peça a evidência à sua própria equipa, sem aviso, e cronometre. Seja qual for a resposta, esse número é aquilo que um supervisor experimentaria. As equipas ficam frequentemente surpreendidas, e a surpresa é em si o argumento para o orçamento.

Semanas 5 a 8: resolver primeiro a cadeia de aprovação. A rastreabilidade costuma estar parcialmente presente, enquanto os registos de aprovação são habitualmente a peça que falta. Defina quem pode aprovar, registe com data e identidade, e deixe de aceitar aprovações por thread de email.

Semanas 8 a 12: retenção e um ensaio real

Resolver a retenção. Verifique o que a sua plataforma de CI/CD guarda de facto e durante quanto tempo, e depois mova tudo o que conta como evidência para armazenamento que não possa ser sobrescrito. É muitas vezes o item mais barato da lista e o mais adiado.

Produzir um dossiê a sério. Exporte a cadeia completa de um sistema como se tivesse chegado um pedido, e depois entregue-a a alguém de fora da equipa de QA e pergunte se responde à questão. Se não responder, encontrou a lacuna antes de um supervisor a encontrar.

Dois hábitos fazem a diferença depois. Ensaie a recuperação uma vez por trimestre, já que um processo não testado é uma suposição. E trate a submissão anual do Registo de Informação como o prazo recorrente que mantém a cadeia atual, porque uma camada mantida só quando alguém pergunta degrada-se entre pedidos.

Sob pressão: o que revela um incidente grave

Nada testa esta infraestrutura como uma falha. Um sistema TIC crítico cai, a equipa de resposta ativa-se, e a primeira decisão é a classificação, porque é aí que arranca o relógio das 4 horas.

Onde a evidência de testes entra na cronologia do incidente

Classificar

Clientes afetados, duração, dispersão geográfica, perdas de dados, criticidade, impacto económico

›

Notificar às 4 horas

Tipo, serviços afetados, impacto preliminar, ponto de contacto, ações tomadas

›

Reportar às 72 horas

Âmbito, contenção, progresso da causa raiz e o que os testes anteriores mostraram

Os critérios de classificação vêm do RTS 2024/1772. O histórico de testes alimenta as três fases, e é por isso que o tempo de recuperação conta mais do que o tempo de escrita do relatório.

Duas instituições com a mesma suite de testes comportam-se de forma diferente aqui. Uma tem num único lugar, em minutos, o registo do sistema afetado, a execução mais recente, a aprovação que o validou e os requisitos cobertos, pelo que a classificação é melhor informada e a notificação chega completa. Na outra, a mesma pergunta manda pessoas para registos de CI/CD, threads de email e folhas de cálculo enquanto o relógio corre. A notificação acaba por refletir o estado da infraestrutura de evidência e não o estado dos testes.

O que a evidência de qualidade de software não resolve

Vale a pena ser direto sobre os limites, porque a infraestrutura de evidência é às vezes vendida como resposta de conformidade em si mesma.

Uma suite de testes fraca continua fraca. Registos perfeitamente rastreáveis e guardados de forma imutável de testes inadequados documentam a inadequação com grande precisão, pelo que a camada de evidência melhora o relato do trabalho e não o trabalho. Decidir que sistemas suportam funções críticas ou importantes continua a ser um juízo interno, já que essa classificação pertence à avaliação de risco da própria instituição. Os testes de penetração orientados por ameaças mantêm requisitos e cadência próprios para as entidades em âmbito, e nenhuma plataforma de evidência os substitui. As pessoas responsáveis também continuam no circuito, porque a aprovação é a parte que não pode ser automatizada por desenho. O que desaparece é o trabalho de recolha, a inconsistência e a dependência de quem por acaso se lembra de onde estão as coisas.

Como o Qualigentic produz a cadeia de evidência de qualidade de software

Qualigentic O Qualigentic é uma plataforma de QA agêntica construída em torno da camada de evidência e não do volume de geração de testes. Cada caso de teste carrega a ligação ao requisito que o motivou. Os registos de execução são datados e imutáveis. A aprovação corre por fluxos com controlo de acessos por papel, pelo que valida quem tem autoridade para validar. A exportação produz documentos estruturados pensados para leitura de supervisão.

A distinção que conta: a evidência é produzida continuamente à medida que os testes correm, não montada quando alguém pergunta. A instalação é on-premise, pelo que os registos ficam dentro do perímetro da própria instituição, o que também elimina a questão da transferência de dados para terceiros. Um piloto com duração fechada cobre uma aplicação e um framework e produz evidência apresentável ao regulador em seis a oito semanas. As nossas notas sobre QA com IA em sectores regulados e sobre o custo da qualidade do software cobrem os argumentos em volta.

Perguntas frequentes

Evidência de qualidade de software e o DORA

Qual é a diferença entre um programa de testes e uma cadeia de evidência ao abrigo do DORA?

Um programa de testes é o conjunto de testes que uma instituição corre para verificar que os seus sistemas TIC funcionam. Uma cadeia de evidência é o registo estruturado e auditável que liga cada teste ao requisito que endereça, através do registo de execução, até à aprovação por um indivíduo responsável. Os supervisores avaliam a cadeia de evidência. Uma instituição pode ter testes rigorosos e ainda assim passar mal numa revisão se a camada de evidência não produzir registos no formato esperado.

Por que a maioria das instituições tem uma lacuna entre testes e evidência?

As ferramentas de teste foram concebidas para responder a perguntas de engenharia, por isso produzem registos, resultados de passa e falha e métricas de cobertura pensadas para operações de desenvolvimento. Os requisitos regulatórios de evidência chegaram depois de essas ferramentas estarem adotadas, e a camada de evidência foi normalmente acrescentada como rotina manual por cima. Rotinas manuais que dependem da disciplina individual não escalam nem sobrevivem a mudanças de pessoas.

Pedidos de supervisão e incidentes

Como é um pedido de supervisão de evidência de testes de resiliência?

Os supervisores pedem tipicamente um registo completo e rastreável dos testes de resiliência dos sistemas TIC designados como críticos, cobrindo que sistemas foram testados, contra que requisitos, quando, com que resultado e quem aprovou esse resultado. O registo tem de ser estruturado, atribuível e recuperável quando pedido. Montá-lo a partir de registos de CI/CD e folhas de cálculo depois de o pedido chegar é trabalho considerável, e reflete-se tanto na gestão de evidência da instituição como nos seus testes.

Como funciona o relógio das 4 horas do DORA?

A notificação inicial é devida em 4 horas a contar da classificação do incidente como grave e, em qualquer caso, não mais de 24 horas depois de a entidade ter tomado conhecimento. A classificação em si tem de acontecer sem demora indevida. Como a classificação depende de saber qual é o sistema afetado, as suas dependências e o seu histórico de testes recente, a recuperação da evidência situa-se antes do relógio das 4 horas e não dentro dele.

Ferramentas e instalação

Como é que o Qualigentic resolve a lacuna de infraestrutura de evidência?

O Qualigentic produz uma cadeia de evidência estruturada como parte do funcionamento normal da plataforma, ligando cada caso de teste ao requisito que está por trás, mantendo registos de execução datados e correndo a aprovação por fluxos com controlo de acessos por papel. A evidência é produzida continuamente em vez de montada a pedido, guardada de forma imutável com retenção configurável e exportável em formatos adequados a revisão de supervisão. A instalação on-premise mantém os registos dentro da infraestrutura da própria instituição.

As ferramentas de teste existentes conseguem produzir uma cadeia de evidência conforme?

Parcialmente, com trabalho. A rastreabilidade de requisitos pode ser mantida numa ferramenta de gestão de testes, e o armazenamento imutável pode ser construído com um arquivo de escrita única. O que costuma faltar é a cadeia de aprovação com governação e a exportação em formato de supervisão, e é por isso que muitas instituições acabam a ligar as pontas manualmente. Construir ou comprar essa camada é uma decisão legítima, e o teste honesto é se o resultado sobrevive à saída de pessoas.

Equipa Caixa Mágica

A Caixa Mágica Software é uma empresa portuguesa de software com mais de 20 anos de experiência a fornecer software à medida, soluções de IA e equipas de desenvolvimento *nearshore* para empresas europeias.

Qualigentic · Caixa Mágica Software

Evidência produzida à medida que os testes correm, não montada sob pressão

Cadeias assinadas do requisito ao registo de execução. Armazenamento imutável com retenção configurável. On-premise, para que nada saia do seu perímetro. Um piloto com duração fechada cobre uma aplicação e um framework em seis a oito semanas

Saiba mais sobre a Qualigentic Fale connosco