Validação e testes
Estratégia de testes end-to-end: planeamento, UAT, automação e gestão de defeitos para garantir que cada release cumpre os requisitos definidos
Descarregar pack completoÂmbito e objectivos
Garantir que produtos e serviços novos ou alterados cumprem os requisitos definidos antes de serem disponibilizados em produção.
SDP (Service Design Package) aprovado, nova release disponível para testes, alteração significativa aprovada pelo Change enablement.
Estratégia de testes, planeamento, preparação de ambientes e dados, execução de testes, gestão de defeitos e aceitação formal pelo service owner.
Desenvolvimento e build do código, deployment em produção e resolução efectiva dos defeitos encontrados (responsabilidade do desenvolvimento).
Relatório de resultados de testes, lista de defeitos documentados por severidade e prioridade, declaração de aceitação formal e recomendação go/no-go para release.
Tipos de teste
| Tipo de teste | Objectivo | Executado por | Quando | Ferramentas comuns |
|---|---|---|---|---|
| Unit | Validar componentes individuais de código de forma isolada | Desenvolvimento | Durante o build | JUnit, pytest, Jest |
| Integration | Verificar a comunicação correcta entre módulos e serviços | QA / Desenvolvimento | Após unit tests | Postman, REST Assured |
| System | Validar o sistema completo face aos requisitos funcionais | QA/Testers | Antes de UAT | Selenium, Cypress |
| UAT | Confirmar que o sistema satisfaz as necessidades do negócio | Utilizadores / Service owner | Antes do go-live | TestRail, Zephyr |
| Regression | Assegurar que alterações não introduziram novos defeitos | QA/Testers | Após cada mudança | Selenium, Cypress |
| Performance / Load / Stress | Verificar comportamento sob carga normal, elevada e extrema | QA especializado | Antes de releases major | JMeter, k6, Gatling |
| Segurança | Identificar vulnerabilidades e riscos de segurança | Equipa de segurança / QA | Antes de releases major | OWASP ZAP, Burp Suite |
| Acessibilidade | Garantir conformidade com WCAG e requisitos legais | QA/Testers | Antes de releases de UI | axe, Lighthouse, WAVE |
Diagrama do processo
Diagrama BPMN simplificado do processo de validação e testes (3 swimlanes). Percorra horizontalmente em dispositivos móveis.
Actividades macro
| # | Actividade | Responsável | Input | Output |
|---|---|---|---|---|
| 1 | Estratégia de testes | Test manager | SDP, requisitos de negócio e técnicos | Documento de estratégia de testes (tipos, critérios, âmbito) |
| 2 | Planeamento | Test manager | Estratégia de testes, calendário de releases | Plano de testes (recursos, prazos, ambientes, ferramentas) |
| 3 | Preparação de ambiente e dados | QA/Testers | Plano de testes, requisitos de dados | Ambiente de testes configurado, dados de teste disponíveis |
| 4 | Execução de testes funcionais | QA/Testers | Casos de teste, build disponível | Resultados de testes funcionais, defeitos registados |
| 5 | Execução de testes não funcionais | QA/Testers | Plano de performance e segurança | Resultados de performance, segurança e acessibilidade |
| 6 | Gestão de defeitos | QA/Testers + Desenvolvimento | Defeitos registados, critérios de severidade | Defeitos classificados, atribuídos e corrigidos |
| 7 | Testes de aceitação (UAT) | Service owner / Utilizadores | Build aprovado em system tests, cenários de negócio | Aceitação formal ou lista de defeitos UAT |
| 8 | Reporting e métricas | Test manager | Resultados de todos os testes | Relatório de testes, dashboard de qualidade |
| 9 | Aceitação formal | Test manager + Service owner | Relatório final, critérios de aceitação | Declaração de aceitação, decisão go/no-go |
Descrição detalhada das actividades
O shift-left testing pressupõe antecipar as actividades de teste para as fases mais precoces do ciclo de desenvolvimento, reduzindo o custo de correcção de defeitos. Um defeito encontrado em desenvolvimento custa até 10 vezes menos do que um defeito encontrado em produção. TDD (Test-Driven Development) e BDD (Behaviour-Driven Development) são práticas que formalizam este princípio.
TDD - práticas chave
- Escrever o teste antes do código de produção (ciclo red-green-refactor)
- Manter os testes unitários rápidos e independentes entre si
- Integrar a execução de testes unitários no pipeline CI
BDD - práticas chave
- Escrever cenários em linguagem Gherkin (Given-When-Then) compreensível pelo negócio
- Envolver product owners e utilizadores na criação dos cenários
- Automatizar a execução dos cenários com Cucumber ou SpecFlow
A automação de testes aumenta a velocidade de feedback e reduz o esforço manual em testes de regressão. A pirâmide de testes recomenda automatizar massivamente os testes de baixo nível (unit) e ser selectivo nos testes de UI, que são mais frágeis e lentos a executar.
Ferramentas por camada
- Selenium: automação de browsers para testes E2E em aplicações web; adequado para equipas com experiência em programação
- Cypress: framework moderno para testes E2E com execução em tempo real, ideal para aplicações JavaScript/SPA
- JMeter: testes de carga e performance com suporte a HTTP, JDBC, SOAP e outros protocolos; adequado para cenários complexos
- k6: testes de performance baseados em código JavaScript, com integração nativa em pipelines CI/CD e dashboards Grafana
Boas práticas de automação
- Seguir o page object model para manter os scripts de UI organizados e reutilizáveis
- Versionar os scripts de teste no mesmo repositório que o código de produção
- Executar os testes de regressão automatizados em cada pull request
- Monitorizar a taxa de falhas flaky e remover ou estabilizar os testes problemáticos
A gestão de dados de teste é frequentemente negligenciada e constitui um risco de conformidade significativo. O uso de dados reais de clientes em ambientes de teste viola o RGPD e expõe a organização a coimas. A anonimização ou geração sintética de dados é obrigatória.
Abordagens de gestão de dados
- Anonimização: substituição de campos pessoais identificáveis (nome, NIF, IBAN, email) por valores fictícios mas realistas
- Pseudonimização: substituição por tokens reversíveis com chave guardada em cofre seguro
- Geração sintética: criação de dados fictícios que respeitam as regras de negócio (formatos, intervalos, dependências)
- Subsetting: uso de subconjuntos representativos da base de dados de produção após anonimização
Controlos RGPD em ambientes de teste
- Documentar no registo de actividades de tratamento o uso de dados em ambiente de teste
- Restringir o acesso ao ambiente de teste aos elementos com necessidade de negócio
- Purgar dados de teste após conclusão do ciclo de testes
Severidade e prioridade são conceitos distintos que frequentemente se confundem. A severidade mede o impacto técnico do defeito no sistema. A prioridade mede a urgência de correcção com base nas necessidades do negócio. Um defeito pode ter alta severidade mas baixa prioridade (afecta funcionalidade raramente usada) ou baixa severidade mas alta prioridade (erro ortográfico no ecrã de login).
Escala de severidade
- Critica (S1): sistema inutilizável, sem workaround possível; bloqueia o go-live
- Alta (S2): funcionalidade principal comprometida, workaround difícil; bloqueia UAT
- Media (S3): funcionalidade parcialmente afectada, workaround existe; pode libertar com nota de release
- Baixa (S4): problema cosmético ou de usabilidade menor; pode entrar no backlog normal
Critérios de aceitação para go-live
- Zero defeitos S1 em aberto
- Zero defeitos S2 sem plano de resolução aprovado
- Defeitos S3 e S4 aceites pelo service owner com data de resolução
Os testes de aceitação pelo utilizador (UAT) são a última linha de defesa antes do go-live. O objectivo não é encontrar defeitos técnicos (essa responsabilidade é do QA), mas confirmar que o sistema resolve os problemas de negócio para os quais foi construído. O service owner é o responsável por aprovar ou rejeitar formalmente a release.
Passos do ciclo UAT
- Seleccionar representantes do negócio com conhecimento dos processos afectados
- Preparar cenários UAT baseados em casos de uso reais, não em requisitos técnicos
- Realizar sessão de kick-off com explicação do ambiente e procedimentos de reporte
- Executar testes em ambiente dedicado, idêntico a produção
- Registar todos os defeitos e observações no sistema de tracking
- Realizar sessão de sign-off com o service owner após resolução dos bloqueadores
A cobertura de testes mede a percentagem do código ou dos requisitos que foi exercitada pelos testes. Métricas de cobertura elevadas não garantem qualidade por si só, mas a cobertura insuficiente é um sinal claro de risco. Importa combinar cobertura de código com cobertura de requisitos.
Tipos de cobertura de código
- Cobertura de linhas: percentagem de linhas de código executadas pelos testes
- Cobertura de ramos: percentagem de branches (if/else, switch) percorridos
- Cobertura de funções: percentagem de funções invocadas pelos testes
Targets recomendados
- Cobertura de linhas em testes unitários: minimo 80% para código critico
- Cobertura de requisitos: 100% dos requisitos must-have testados antes de UAT
- Taxa de automacao de regressao: minimo 70% dos casos de teste de regressao automatizados
Modelo RACI
| Actividade | Test manager (TM) |
QA/Testers (QA) |
Desenvolvimento (DEV) |
Service owner (SO) |
Release manager (RM) |
|---|---|---|---|---|---|
| Estratégia de testes | R | C | C | A | I |
| Planeamento | R | C | I | A | C |
| Preparação ambiente/dados | A | R | C | I | - |
| Execução testes funcionais | A | R | C | I | - |
| Execução testes nao funcionais | A | R | C | I | - |
| Gestão de defeitos | A | R | R | I | I |
| Testes de aceitação (UAT) | A | C | - | R | I |
| Reporting e métricas | A | R | I | I | I |
| Aceitação formal (go/no-go) | R | I | I | A | C |
Métricas e KPIs
| Métrica | Descrição | Target sugerido |
|---|---|---|
| Cobertura de testes | Percentagem de requisitos must-have cobertos por casos de teste executados | 100% must-have |
| Defeitos por severidade | Distribuição dos defeitos encontrados por nível de severidade (S1 a S4) | S1 = 0 no go-live |
| Defect escape rate | Percentagem de defeitos encontrados em produção em relação ao total encontrado em testes | < 5% |
| Taxa de aprovação UAT | Percentagem de cenários UAT aprovados sem defeitos na primeira execução | > 90% |
| Automação de testes | Percentagem de casos de teste de regressão automatizados em relação ao total | > 70% |
| Tempo de execução de testes | Duração total do ciclo de testes desde inicio até aceitação formal | Definido por release |
| Duração da regressão automatizada | Tempo de execução da suite de regressão automatizada no pipeline CI/CD | < 30 min |
Interfaces com outros processos
Design de servicos
O SDP com requisitos funcionais e nao funcionais define o âmbito e os critérios de aceitação dos testes.
Build / Desenvolvimento
O código construído e os artefactos de build são o objecto principal dos testes funcionais e não funcionais.
Release management
Os resultados de testes e a declaração de aceitação formal alimentam a decisão go/no-go do release manager.
Gestão de defeitos
Os defeitos encontrados durante os testes são registados e encaminhados para o desenvolvimento para resolução.
Change enablement
Mudancas aprovadas desencadeiam testes de regressão para assegurar que não introduzem novos defeitos.
Deployment management
A aprovação formal dos testes é o prerequisito para o deployment em producao ser autorizado.
Descarregar o pack completo
Inclui o processo documentado, plano de testes, matriz RACI em Excel, templates de relatório e checklist de UAT.