Microsoft AZ-400: Strategia di test e ingegneria della qualità — Guida allo studio

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

Fa parte della Microsoft DevOps Engineer Expert AZ-400 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La strategia di test e la Quality Engineering in Azure DevOps si concentrano sulla creazione di fiducia nel software attraverso un feedback rapido e deterministico lungo tutto il ciclo di vita della delivery, utilizzando al contempo le funzionalità native della piattaforma per imporre quality gate e tracciabilità. Le strategie efficaci combinano una piramide di test bilanciata, validazione anticipata e continua (TDD/BDD), automazione robusta nelle pipeline, una gestione disciplinata dei dati di test e tecniche avanzate come load testing, chaos engineering, controlli di accessibilità e deployment basati sulla code coverage. Azure Test Plans, Azure Pipelines, Azure Load Testing e Azure Chaos Studio forniscono gli strumenti per implementare queste pratiche su larga scala.

Fondamenti della Strategia di Test

Una piramide di test pragmatica riduce il rischio con test veloci e a basso costo alla base e un numero minore di test ad alta fedeltà al vertice:

I test unitari (unit test) validano la logica isolata e dovrebbero costituire la maggior parte della suite. Puntare a un’esecuzione rapida e a un alto determinismo. Per la maggior parte dei prodotti, impostare obiettivi di code coverage per i test unitari nell’intervallo del 70-90% per i servizi critici, riconoscendo che la coverage è una metrica proxy e non una garanzia di qualità.
I test di integrazione (integration test) verificano i contratti tra componenti (es. database, messaging, servizi esterni) utilizzando confini realistici e dipendenze effimere. Eseguirli in parallelo quando possibile, in ambienti containerizzati o sandbox, e puntare a coprire il 30-60% dei percorsi di codice critici esercitati tramite scenari a livello di integrazione.
I test end-to-end (E2E) validano i percorsi utente (user journey) attraverso l’intero stack. Mantenerli al minimo e concentrarli sui percorsi di maggior valore (tipicamente il 5-15% della suite) per evitare feedback lenti e fragili.

Le pratiche di shift-left testing riducono i difetti in una fase anticipata del processo:

Il Test-Driven Development (TDD) impone cicli red-green-refactor, guida la progettazione e aumenta la fiducia a livello unitario. Rendere il TDD pratico fornendo agli ingegneri test runner locali e veloci, e mantenendo i test ermetici e deterministici.
Il Behavior-Driven Development (BDD) cattura l’intento in un vocabolario condiviso utilizzando Gherkin. I team .NET possono usare SpecFlow; i team Java e JavaScript usano spesso Cucumber. Collegare gli scenari BDD ai criteri di accettazione in Azure Boards e pubblicare i loro risultati su Azure Test Plans per la tracciabilità.

La gestione dei dati di test (test data management) elimina il non-determinismo:

I dati sintetici forniscono dataset deterministici e sicuri per la privacy per i test unitari e di integrazione. Generarli con librerie “faker” specifiche del linguaggio e valori di seed che ne consentano la riproducibilità.
Il data masking consente di creare dataset di test realistici senza esporre informazioni personali o sensibili. Utilizzare strumenti di masking per database o data pipeline che applicano trasformazioni irreversibili. Per Azure SQL Database, esportare snapshot in una sottoscrizione di staging e applicare il masking prima dell’uso nei test.
La parità tra ambienti (environment parity) garantisce che i risultati dei test siano significativi. Eseguire il provisioning degli ambienti di test con Infrastructure as Code (ARM/Bicep/Terraform) in modo che i componenti di sistema, la configurazione e la topologia di rete corrispondano il più fedelmente possibile a quelli di produzione. Mantenere le migrazioni dello schema sincronizzate (in lockstep) tra i vari ambienti.

Rilevamento e gestione dei test instabili (flaky test) per proteggere i cicli di feedback:

Le cause includono race condition temporali, dipendenze esterne, accoppiamento nell’ordine dei test e contesa di risorse. Utilizzare il task Visual Studio Test di Azure Pipelines con l’opzione rerunFailedTests abilitata per ridurre il rumore transitorio durante l’indagine.
Mettere in quarantena i test non deterministici per mantenere le pipeline “verdi” (green), etichettandoli e isolandoli in una suite separata che viene eseguita e genera report, ma non causa il fallimento della build. Tracciare il debito di quarantena (quarantine debt) con i work item di Azure Boards.
La root cause analysis richiede strumentazione. Acquisire log, metriche di temporizzazione e dettagli dell’ambiente durante le esecuzioni; riprodurre localmente con lo stesso seed e le stesse dipendenze; rimuovere la dipendenza da system clock, rete e file system non “mockati”; e correggere il non-determinismo alla fonte.

Funzionalità di test di Azure DevOps e Azure

Azure Test Plans offre funzionalità di prim’ordine per test manuali ed esplorativi, oltre alla tracciabilità:

I casi di test (test case) definiscono passaggi, risultati attesi e parametri; i passaggi condivisi e i casi di test parametrizzati riducono la duplicazione. Le suite basate sui requisiti allineano i casi ai Product Backlog Item o alle user story, mentre le suite statiche e basate su query raggruppano i test per l’esecuzione.
Le esecuzioni dei test (test run) assegnano suite e configurazioni ai tester, registrano esiti e durate e acquisiscono dati diagnostici. La segnalazione dettagliata dei bug include screenshot, video, dati sull’ambiente e log delle azioni.
Il test esplorativo utilizza l’estensione del browser Test & Feedback per acquisire charter, note di sessione e artefatti durante l’esplorazione ad-hoc. Collega i risultati agli elementi di lavoro (work item) e analizza la copertura dei requisiti e delle sessioni di test.

I test automatizzati si integrano direttamente nelle pipeline:

Utilizza il task Visual Studio Test (VsTest) per eseguire test MSTest, NUnit e xUnit e pubblicare i risultati in formato TRX. Per .NET, è comune l’uso di dotnet test con il logger appropriato (trx, junit).
Per Java, esegui JUnit tramite Maven o Gradle e pubblica il file XML JUnit con il task Publish Test Results. Per JavaScript, configura i runner (Jest, Mocha) per generare un output in formato XML JUnit.
Il task Publish Test Results consolida gli esiti e i trend tra le varie esecuzioni. Standardizza i formati dei risultati (TRX o XML JUnit) per unificare il reporting e abilitare l’analisi dei test instabili (flaky test).
Collega le esecuzioni dei test automatizzati ad Azure Test Plans mappando i casi di test ai metodi di test automatizzati, garantendo una tracciabilità end-to-end dal requisito all’esecuzione fino al difetto.

La code coverage è un guardrail di qualità misurabile:

Raccogli i dati di coverage con Coverlet (per .NET), JaCoCo (Java) o Cobertura/lcov (JavaScript). Convertili in formati comprensibili da Azure DevOps e pubblicali tramite il task Publish Code Coverage Results per visualizzare trend e delta.
Imponi soglie minime in fase di build. Per .NET, usa gli switch di soglia di Coverlet per far fallire la build se la copertura di riga o di ramo scende al di sotto della policy. In alternativa, utilizza l’estensione Build Quality Checks per imporre policy basate sulla copertura e sui trend.
I rilasci controllati dalla coverage (coverage-gated deployment) impediscono l’avanzamento quando la qualità diminuisce. In YAML, fai fallire lo stage di qualità se la copertura è inferiore all’obiettivo; per le release classiche, usa i gate che invocano una Azure Function o un controllo REST per convalidare la copertura misurata prima della promozione.

Prestazioni, Chaos e Resilienza

I test di carico e di prestazione convalidano i requisiti non funzionali in modo precoce e continuo:

Azure Load Testing orchestra carichi di lavoro basati su JMeter su larga scala, correlando la telemetria di backend proveniente da Application Insights. Importa piani di test JMX, imposta criteri di superamento/fallimento (es. latenza p95, tasso di errore) e visualizza i risultati nelle pipeline. Utilizza il gate di Azure Monitor o i controlli di ambiente per bloccare l’avanzamento quando le baseline non sono rispettate.
Apache JMeter rimane una scelta versatile per i test di carico a livello di protocollo. Mantieni i gruppi di thread (thread group) e le asserzioni (assertion) parametrizzati per la CI. Archivia i dataset JMX e CSV insieme al codice, versionandoli con gli scenari.
k6 abilita test di carico come codice (as code) in modo intuitivo per gli sviluppatori. Esegui k6 in Azure Pipelines tramite un container o un runtime Node, acquisisci i risultati ed esportali in formato JUnit o JSON per la pubblicazione. Usa le espressioni di soglia (threshold) all’interno degli script k6 per far fallire le esecuzioni in modo deterministico.
La gestione delle baseline è fondamentale. Monitora i trend di latenza, throughput e utilizzo delle risorse per ogni ambiente. Stabilisci degli SLO e assicurati che i test vengano eseguiti con volumi di dati e configurazioni rappresentativi.

Il chaos engineering verifica la resilienza in condizioni di guasto:

Azure Chaos Studio inietta guasti nelle risorse Azure con un raggio d’impatto (blast radius) controllato e misure di sicurezza. I tipi di esperimento includono pressione su CPU/memoria delle VM, latenza di rete/blackhole, terminazione di processi e throttling del servizio.
Esegui gli esperimenti prima in pre-produzione e strumentali con Application Insights e Azure Monitor per catturare le modalità di guasto, gli error budget e il comportamento di ripristino automatico.
La convalida della resilienza abbina il chaos a sonde di integrità (health probe) e transazioni sintetiche per garantire che i percorsi critici per l’utente rimangano disponibili o subiscano un degrado controllato (degrade gracefully). Promuovi l’ambiente solo quando le ipotesi di resilienza sono confermate e gli allarmi si comportano come previsto.

Accessibilità, Conformità e Governance

Accessibilità e conformità sono fondamenti della qualità:

Conformarsi come minimo a WCAG 2.1 AA per le esperienze rivolte al pubblico. Tradurre i requisiti in criteri di accettazione in Azure Boards e Azure Test Plans con casi di test dedicati all’accessibilità.
Automatizzare i controlli con axe-core integrato in framework di test per l’interfaccia utente come Playwright, Cypress o Selenium. Interrompere le build quando vengono rilevate violazioni critiche e pubblicare i report di accessibilità come artefatti della pipeline.
Integrare l’automazione con audit manuali (navigazione da tastiera, supporto per screen reader, contrasto dei colori in contesti dinamici) e acquisire i risultati in sessioni esplorative utilizzando l’estensione Test & Feedback.
La governance della conformità e della qualità in Azure Pipelines utilizza controlli di ambiente e gate. Per le prestazioni e la disponibilità, interrogare Azure Monitor o Azure Load Testing per ottenere le baseline prima della distribuzione. Per il gatekeeping della copertura o dell’accessibilità, invocare una funzione o un controllo REST che analizza i report pubblicati e restituisce un esito positivo/negativo (pass/fail). Questo impone la qualità non funzionale come prerequisito per il rilascio, non come un’aggiunta successiva.

La pubblicazione e l’analisi dei risultati dei test chiudono il cerchio:

Standardizzare i formati dei risultati e i report di copertura per popolare Test Analytics, monitorare l’andamento delle percentuali di successo e far emergere automaticamente i test instabili (flaky).
Utilizzare policy di build e protezioni dei branch per richiedere test con esito positivo (green) e una copertura adeguata prima del merge. Mantenere un feedback rapido; parallelizzare le fasi di test, suddividere (shard) le suite di grandi dimensioni e memorizzare nella cache le dipendenze per ridurre il tempo di ciclo.

Scenario Pratico

Adobe sta modernizzando una piattaforma di elaborazione documenti trasformandola in microservizi su Azure. La leadership ingegneristica impone una cadenza di rilascio più rapida senza regressioni, baseline di prestazioni dimostrabili, resilienza ai guasti di rete regionali e conformità a WCAG 2.1 AA. Le pipeline attuali soffrono di test E2E instabili (flaky) e dati di test incoerenti.

Stabilire la piramide dei test e le pratiche di shift-left

Adottare il TDD per le librerie e i servizi principali per creare una base ampia e deterministica di unit test, utilizzando NUnit e xUnit per i componenti .NET e JUnit per Java. Il BDD con SpecFlow e Cucumber cattura i criteri di accettazione inter-team come specifiche eseguibili. Questo garantisce un feedback rapido e una comprensione condivisa.

Automatizzare i test e pubblicare i risultati in Azure Pipelines

Utilizzare VsTest per .NET e Maven/Gradle per Java per eseguire gli unit test e i test di integrazione. Pubblicare i risultati con Publish Test Results e la copertura con Publish Code Coverage Results per centralizzare il reporting e abilitare l’analisi dei test instabili (flaky). Le task integrate forniscono una stretta integrazione con Azure DevOps e riducono la necessità di strumenti personalizzati.

Imporre soglie di copertura del codice e usare gate per le distribuzioni

Configurare le soglie di Coverlet e JaCoCo per interrompere le build se la copertura scende al di sotto dell'80% per riga e del 60% per branch per i servizi critici. Aggiungere un controllo di rilascio che chiama una Azure Function per leggere l’ultimo artefatto di copertura e restituire un esito positivo/negativo (pass/fail), impedendo la distribuzione quando la copertura è inferiore alla policy. Questo formalizza i quality gate senza intervento umano.

Implementare la gestione dei dati di test per il determinismo

Generare set di dati sintetici per gli unit test e i test di integrazione utilizzando librerie di tipo “faker”. Per i test di sistema, clonare copie mascherate dei database Azure SQL tramite una pipeline automatizzata che utilizza Data Factory per applicare un mascheramento irreversibile. Effettuare il provisioning degli ambienti con Bicep per garantire la parità. Questo elimina i rischi per la privacy e l’instabilità (flakiness) legata ai dati.

Contenere ed eliminare i test instabili (flaky)

Abilitare rerunFailedTests in VsTest per mitigare i fallimenti transitori e contrassegnare le specifiche instabili con un marcatore di quarantena che le esclude dalla suite bloccante, pur continuando a eseguirle e a registrarne i risultati. Creare work item in Azure Boards per ogni test in quarantena. Individuare la causa principale (root-cause) raccogliendo log di temporizzazione e di rete e rimuovendo le attese non deterministiche. Questo mantiene le pipeline affidabili, promuovendo al contempo correzioni permanenti.

Validare le prestazioni con Azure Load Testing e k6

Modellare i percorsi utente chiave (key journeys) come piani JMeter ed eseguirli in Azure Load Testing dopo la distribuzione in staging, con criteri di successo/fallimento (pass/fail) basati sulla latenza p95 e sulle percentuali di errore. Per i test a livello di API eseguiti dagli sviluppatori, eseguire script k6 in CI con soglie integrate. Aggiungere un gate di Azure Monitor per bloccare la produzione se le baseline di staging non vengono rispettate. Questi strumenti forniscono un’applicazione scalabile e misurabile delle prestazioni, in linea con il concetto di gate del QA.

Dimostrare la resilienza con Azure Chaos Studio

Progettare esperimenti che iniettano latenza di rete e pressione sulla CPU su microservizi selezionati in staging, mentre Application Insights monitora gli error budget e il ripristino. Richiedere che tutti gli esperimenti di resilienza soddisfino gli SLO prima della promozione. I controlli di governance di Chaos Studio si allineano alla necessità di Adobe di avere un raggio d’impatto controllato (blast radius) ed esperimenti verificabili.

Garantire accessibilità e conformità

Integrare axe-core nei test dell’interfaccia utente con Playwright per rilevare automaticamente le violazioni di WCAG 2.1 AA nelle schermate principali. Pubblicare i report delle violazioni come artefatti di build e interrompere la build in caso di problemi critici. Pianificare sessioni esplorative di accessibilità con Azure Test Plans e l’estensione Test & Feedback per la verifica manuale. Questo combina la copertura automatizzata con controlli incentrati sull’utente.

Fornire tracciabilità e analisi

Collegare i test automatizzati ad Azure Test Plans dove appropriato, allineare le suite ai requisiti e utilizzare Test Analytics per monitorare l’andamento delle percentuali di successo, identificare i test instabili (flaky) e focalizzare gli interventi di correzione. Ciò consente alla leadership di visualizzare a colpo d’occhio l’andamento della qualità e lo stato di preparazione al rilascio (release readiness).

← Sicurezza · Tutti i domini · Monitoraggio →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →