Microsoft AZ-400: Estratégia de Testes e Engenharia de Qualidade — Guia de estudos

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Faz parte do Microsoft DevOps Engineer Expert AZ-400 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

Estratégia de Testes e Engenharia de Qualidade no Azure DevOps trata de construir confiança no software por meio de feedback rápido e determinístico ao longo do ciclo de vida de entrega, utilizando as capacidades nativas da plataforma para impor portões de qualidade (quality gates) e rastreabilidade. Estratégias eficazes combinam uma pirâmide de testes balanceada, validação antecipada e contínua (TDD/BDD), automação robusta em pipelines, gerenciamento disciplinado de dados de teste e técnicas avançadas como testes de carga, engenharia de caos, verificações de acessibilidade e deployments com imposição de cobertura. O Azure Test Plans, Azure Pipelines, Azure Load Testing e Azure Chaos Studio fornecem as ferramentas para implementar essas práticas em escala.

Fundamentos da Estratégia de Testes

Uma pirâmide de testes pragmática reduz o risco com testes rápidos e de baixo custo na base e um número menor de testes de alta fidelidade no topo:

Testes de unidade validam a lógica isolada e devem dominar o conjunto de testes. Busque uma execução rápida e alto determinismo. Para a maioria dos produtos, defina metas de cobertura de testes de unidade na faixa de 70–90% para serviços críticos, reconhecendo que a cobertura é uma métrica proxy e não uma garantia de qualidade.
Testes de integração verificam contratos entre componentes (por exemplo, banco de dados, mensageria, serviços externos) usando limites realistas e dependências efêmeras. Execute-os em paralelo quando possível, em ambientes em contêineres ou sandbox, e tenha como alvo 30–60% dos caminhos de código críticos exercitados por meio de cenários de nível de integração.
Testes de ponta a ponta (E2E) validam as jornadas do usuário em todo o stack. Mantenha-os mínimos e focados nos caminhos de maior valor (normalmente 5–15% do conjunto) para evitar feedback frágil e lento.

Práticas de teste “shift-left” reduzem defeitos mais cedo no ciclo:

O Test-Driven Development (TDD) impõe ciclos red-green-refactor, informa o design e aumenta a confiança no nível de unidade. Torne o TDD prático fornecendo aos engenheiros executores de teste locais e rápidos, e mantendo os testes herméticos e determinísticos.
O Behavior-Driven Development (BDD) captura a intenção em um vocabulário compartilhado usando Gherkin. Times .NET podem usar o SpecFlow; times Java e JavaScript geralmente usam o Cucumber. Vincule os cenários BDD aos critérios de aceitação do Azure Boards e publique seus resultados no Azure Test Plans para rastreabilidade.

O gerenciamento de dados de teste elimina o não determinismo:

Dados sintéticos fornecem conjuntos de dados determinísticos e seguros para a privacidade para testes de unidade e integração. Gere-os com bibliotecas “faker” específicas da linguagem e valores de semente (seed) que permitam a reprodutibilidade.
O mascaramento de dados (data masking) permite conjuntos de dados de teste realistas sem expor informações pessoais ou sensíveis. Use ferramentas de mascaramento de banco de dados ou pipelines de dados que aplicam transformações irreversíveis. Para o Azure SQL Database, exporte snapshots para uma assinatura de preparação (staging) e aplique o mascaramento antes do uso nos testes.
A paridade de ambiente garante que os resultados dos testes sejam significativos. Provisione ambientes de teste com Infraestrutura como Código (ARM/Bicep/Terraform) para que os componentes do sistema, a configuração e a topologia de rede correspondam à produção da forma mais próxima possível. Mantenha as migrações de esquema em sincronia entre os ambientes.

A detecção e o gerenciamento de testes instáveis (flaky) protegem os ciclos de feedback:

As causas incluem condições de corrida (race conditions) de tempo, dependências externas, acoplamento de ordem de teste e contenção de recursos. Use a tarefa Visual Studio Test do Azure Pipelines com rerunFailedTests ativado para reduzir o ruído transitório enquanto você investiga.
Coloque em quarentena os testes que são não determinísticos para manter os pipelines verdes (green), etiquetando-os e isolando-os em um conjunto separado que executa e reporta, mas não falha o build. Rastreie a dívida de quarentena com work items do Azure Boards.
A análise de causa raiz requer instrumentação. Capture logs, métricas de tempo e detalhes do ambiente durante as execuções; reproduza localmente com a mesma semente (seed) e dependências; remova a dependência de relógios de sistema, rede e sistema de arquivos não mockados; e corrija o não determinismo na origem.

Azure DevOps e Capacidades de Teste do Azure

O Azure Test Plans oferece testes manuais e exploratórios de primeira linha, além de rastreabilidade:

Casos de teste (Test cases) definem passos, resultados esperados e parâmetros; passos compartilhados e casos de teste parametrizados reduzem a duplicação. Suítes baseadas em requisitos (Requirement-based suites) alinham os casos aos Product Backlog Items ou user stories, enquanto suítes estáticas e baseadas em consultas (query-based) agrupam testes para execução.
Execuções de teste (Test runs) atribuem suítes e configurações aos testadores, registram resultados e durações e capturam diagnósticos. O registro detalhado de bugs inclui capturas de tela, vídeo, dados do ambiente e logs de ações.
Testes exploratórios usam a extensão de navegador Test & Feedback para capturar charters, notas de sessão e artefatos durante a exploração ad-hoc. Vincule os achados a work items e analise a cobertura de requisitos e sessões de teste.

Testes automatizados se integram diretamente aos pipelines:

Use a task Visual Studio Test (VsTest) para executar testes MSTest, NUnit e xUnit e publicar os resultados em TRX. Para .NET, o uso de dotnet test com o logger apropriado (trx, junit) é comum.
Para Java, execute o JUnit via Maven ou Gradle e publique o JUnit XML com a task Publish Test Results. Para JavaScript, configure os runners (Jest, Mocha) para emitir JUnit XML.
A task Publish Test Results consolida resultados e tendências entre as execuções. Padronize os formatos de resultado (TRX ou JUnit XML) para unificar os relatórios e habilitar a análise de testes instáveis (flaky tests).
Vincule as execuções de testes automatizados ao Azure Test Plans mapeando os casos de teste para os métodos de teste automatizados, garantindo rastreabilidade de ponta a ponta, do requisito à execução e ao defeito.

A cobertura de código (code coverage) é um mecanismo de controle de qualidade mensurável:

Colete a cobertura com Coverlet (para .NET), JaCoCo (Java) ou Cobertura/lcov (JavaScript). Converta para formatos que o Azure DevOps entende e publique através da task Publish Code Coverage Results para exibir tendências e deltas.
Imponha limites mínimos em tempo de build. Para .NET, use os switches de threshold do Coverlet para falhar o build se a cobertura de linha ou de branch cair abaixo da política. Alternativamente, use a extensão Build Quality Checks para impor políticas de cobertura e baseadas em tendências.
Deployments com validação de cobertura (coverage-gated) impedem a progressão quando a qualidade cai. Em YAML, faça o estágio de qualidade falhar se a cobertura estiver abaixo da meta; para releases clássicos, use gates que invocam uma Azure Function ou uma verificação REST para validar a cobertura medida antes da promoção.

Desempenho, Caos e Resiliência

Testes de carga e desempenho validam requisitos não funcionais de forma antecipada e contínua:

O Azure Load Testing orquestra cargas baseadas no JMeter em escala enquanto correlaciona a telemetria de backend do Application Insights. Importe planos de teste JMX, defina critérios de aprovação/reprovação (ex: latência p95, taxa de erro) e exiba os resultados nos pipelines. Use o gate do Azure Monitor ou verificações de ambiente para bloquear a progressão quando os baselines não forem atendidos.
O Apache JMeter continua sendo uma escolha versátil para testes de carga em nível de protocolo. Mantenha os thread groups e as asserções parametrizados para CI. Armazene os datasets JMX e CSV com o código, versionados junto com os cenários.
O k6 permite testes de carga como código de forma amigável para desenvolvedores. Execute o k6 no Azure Pipelines por meio de um contêiner ou de um runtime Node, capture os resultados e exporte para JUnit ou JSON para publicação. Use expressões de threshold dentro dos scripts k6 para falhar as execuções de forma determinística.
O gerenciamento de baselines é fundamental. Acompanhe as tendências de latência, throughput e utilização de recursos por ambiente. Estabeleça SLOs e garanta que os testes sejam executados com volumes de dados e configurações representativos.

A engenharia do caos (chaos engineering) verifica a resiliência sob falhas:

O Azure Chaos Studio injeta falhas em recursos do Azure com raio de impacto (blast radius) controlado e proteções (safeguards). Os tipos de experimento incluem pressão de CPU/memória em VMs, latência/blackhole de rede, finalização de processos (process kill) e limitação de serviço (service throttling).
Execute experimentos primeiro em pré-produção e instrumente com o Application Insights e o Azure Monitor para capturar modos de falha, orçamentos de erro (error budgets) e comportamento de recuperação automática.
A validação da resiliência combina o caos com sondas de saúde (health probes) e transações sintéticas para garantir que os caminhos críticos para o usuário permaneçam disponíveis ou se degradem gradualmente. Promova somente quando as hipóteses de resiliência forem confirmadas e os alertas se comportarem conforme o projetado.

Acessibilidade, Conformidade e Governança

Acessibilidade e conformidade são fundamentos de qualidade:

Esteja em conformidade com o WCAG 2.1 AA, no mínimo, para experiências voltadas ao público. Traduza os requisitos em critérios de aceitação no Azure Boards e no Azure Test Plans com casos de teste de acessibilidade dedicados.
Automatize as verificações com o axe-core integrado a frameworks de teste de UI como Playwright, Cypress ou Selenium. Falhe os builds quando violações críticas forem detectadas e publique relatórios de acessibilidade como artefatos do pipeline.
Complemente a automação com auditorias manuais (navegação por teclado, suporte a leitores de tela, contraste de cores em contextos dinâmicos) e capture os resultados em sessões exploratórias usando a extensão Test & Feedback.
A governança de conformidade e qualidade no Azure Pipelines usa verificações e portões (gates) de ambiente. Para desempenho e disponibilidade, consulte o Azure Monitor ou o Azure Load Testing para obter baselines antes da implantação. Para o controle de cobertura ou acessibilidade, invoque uma função ou uma verificação REST que analise (parse) os relatórios publicados e retorne sucesso/falha (pass/fail). Isso impõe a qualidade não funcional como um pré-requisito para o lançamento, não como uma consideração tardia.

A publicação e a análise dos resultados de teste fecham o ciclo:

Padronize os formatos de resultado e os relatórios de cobertura para popular o Test Analytics, acompanhar as tendências das taxas de aprovação e expor testes instáveis (flaky tests) automaticamente.
Use políticas de build e proteções de branch para exigir testes aprovados (verdes) e cobertura adequada antes de fazer o merge. Mantenha o feedback rápido; paralelize os estágios de teste, fragmente (shard) suítes grandes e armazene as dependências em cache para reduzir o tempo de ciclo.

Cenário de Problema Prático

A Adobe está modernizando uma plataforma de processamento de documentos para microsserviços no Azure. A liderança de engenharia exige uma cadência de lançamento mais rápida sem regressões, baselines de desempenho comprováveis, resiliência a falhas de rede regionais e conformidade com o WCAG 2.1 AA. Os pipelines atuais sofrem com testes E2E instáveis (flaky) e dados de teste inconsistentes.

Estabelecer a pirâmide de testes e práticas de shift-left

Adote o TDD para bibliotecas e serviços principais para criar uma base grande e determinística de testes de unidade, usando NUnit e xUnit para componentes .NET e JUnit para Java. O BDD com SpecFlow e Cucumber captura critérios de aceitação entre equipes como especificações executáveis. Isso garante feedback rápido e um entendimento compartilhado.

Automatizar testes e publicar resultados no Azure Pipelines

Use o VsTest para .NET e Maven/Gradle para Java para executar testes de unidade e de integração. Publique os resultados com a tarefa Publish Test Results e a cobertura com a Publish Code Coverage Results para centralizar os relatórios e habilitar a análise de testes instáveis (flaky). As tarefas integradas fornecem uma integração forte com o Azure DevOps e reduzem a necessidade de ferramentas personalizadas.

Impor limites de cobertura de código e controlar (gate) as implantações

Configure os limites do Coverlet e do JaCoCo para falhar os builds se a cobertura cair abaixo de 80% por linha e 60% por branch para serviços críticos. Adicione uma verificação de lançamento que chame uma Azure Function para ler o artefato de cobertura mais recente e retornar sucesso/falha (pass/fail), impedindo a implantação quando a cobertura estiver abaixo da política. Isso formaliza os portões de qualidade (quality gates) sem intervenção humana.

Implementar o gerenciamento de dados de teste para determinismo

Gere conjuntos de dados sintéticos para testes de unidade e de integração usando bibliotecas faker. Para testes de sistema, clone cópias mascaradas de bancos de dados Azure SQL por meio de um pipeline automatizado usando o Data Factory para aplicar mascaramento irreversível. Provisione ambientes com o Bicep para garantir a paridade. Isso remove o risco de privacidade e a instabilidade (flakiness) relacionada aos dados.

Conter e eliminar testes instáveis (flaky)

Habilite rerunFailedTests no VsTest para mitigar falhas transitórias e marque as especificações instáveis com um marcador de quarentena que as exclui da suíte de bloqueio, mas ainda as executa e reporta. Crie itens de trabalho no Azure Boards para cada teste em quarentena. Analise a causa raiz coletando logs de tempo e de rede e removendo esperas não determinísticas. Isso mantém os pipelines confiáveis enquanto impulsiona correções permanentes.

Validar o desempenho com o Azure Load Testing e o k6

Modele as jornadas principais como planos do JMeter e execute-os no Azure Load Testing após a implantação em staging, com critérios de sucesso/falha (pass/fail) baseados na latência p95 e nas taxas de erro. Para testes de API no nível do desenvolvedor, execute scripts k6 em CI com limites integrados. Adicione um portão (gate) do Azure Monitor para bloquear a produção se os baselines de staging não forem atendidos. Essas ferramentas fornecem uma imposição de desempenho escalável e mensurável, alinhada com o conceito de portão de QA.

Provar a resiliência com o Azure Chaos Studio

Projete experimentos que injetem latência de rede e pressão de CPU em microsserviços selecionados em staging, enquanto o Application Insights monitora os orçamentos de erro (error budgets) e a recuperação. Exija que todos os experimentos de resiliência atendam aos SLOs antes da promoção. Os controles de governança do Chaos Studio se alinham à necessidade da Adobe de ter um raio de impacto (blast radius) controlado e experimentos auditáveis.

Garantir acessibilidade e conformidade

Integre o axe-core aos testes de UI do Playwright para detectar automaticamente violações do WCAG 2.1 AA nas telas principais. Publique relatórios de violação como artefatos de build e falhe em caso de problemas críticos. Agende sessões exploratórias de acessibilidade com o Azure Test Plans e a extensão Test & Feedback para verificação manual. Isso combina cobertura automatizada com verificações centradas no ser humano.

Fornecer rastreabilidade e análise (analytics)

Vincule testes automatizados ao Azure Test Plans quando apropriado, alinhe as suítes com os requisitos e use o Test Analytics para acompanhar tendências de taxas de aprovação, identificar testes instáveis (flaky) e focar na remediação. Isso permite que a liderança veja as tendências de qualidade e a prontidão para o lançamento de forma rápida.

Cada escolha enfatiza os serviços nativos do Azure DevOps e do Azure para uma integração de primeira classe, governança por meio de verificações e portões (gates) de ambiente, e uma estratégia de teste equilibrada que otimiza a velocidade do feedback, a confiabilidade e a conformidade.

← Segurança · Todos os domínios · Monitoramento →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →