AAA (Arrange-Act-Assert)
Una struttura a tre fasi per il corpo di un test: predisporre input e precondizioni, agire chiamando l'unità una sola volta e verificare l'esito. Mantenere le fasi distinte rende l'intento evidente ed espone i test che cercano di verificare troppo.
ATDD (Acceptance Test-Driven Development)
Una pratica collaborativa in cui il team concorda i test di accettazione di una funzionalità - di solito in forma Given/When/Then - prima di iniziare l'implementazione. I test concordati diventano la definizione eseguibile di "fatto", allineando sviluppatori, tester e stakeholder di business.
BDD (Behaviour-Driven Development)
Un approccio che esprime i requisiti come esempi concreti di comportamento in un linguaggio condiviso e quasi naturale (Gherkin), leggibile sia dagli stakeholder tecnici sia da quelli non tecnici. Strumenti come Cucumber legano quegli scenari a step definition che pilotano il sistema.
CI (Continuous Integration)
La pratica di integrare frequentemente il codice in un tronco condiviso, con ogni integrazione verificata da una build e da test automatici. Dipende da una suite di test veloce e affidabile per dare feedback rapido e mantenere il tronco rilasciabile.
CD (Continuous Delivery/Deployment)
La Continuous Delivery mantiene il software sempre rilasciabile tramite pipeline automatiche; il Continuous Deployment va oltre rilasciando automaticamente ogni cambiamento che passa i controlli. Entrambi si affidano a un gate di test automatico affidabile per rilasciare senza colli di bottiglia di QA manuale.
DAST (Dynamic Application Security Testing)
Una tecnica di test di sicurezza che sonda un'applicazione in esecuzione dall'esterno, inviando richieste costruite ad arte per trovare vulnerabilità come injection e autenticazione difettosa. Completa la SAST, che ispeziona il codice sorgente staticamente senza eseguirlo.
E2E (End-to-End)
Testing che pilota un sistema completo e integrato lungo un percorso utente reale, di solito tramite la UI. I test E2E danno la massima fiducia ma sono i più lenti e fragili, perciò appartengono al vertice stretto della piramide dei test.
SUT (System Under Test)
Il codice specifico che un test esercita, sia esso una singola classe, una fetta di servizi o l'intera applicazione. Nominare con precisione il SUT chiarisce l'ambito del test e quali collaboratori siano reali o sostituiti.
TDD (Test-Driven Development)
Un ciclo red-green-refactor: scrivere un test che fallisce, scrivere il codice minimo per farlo passare e poi refattorizzare sotto la protezione del test. Guida design piccoli e disaccoppiati e produce una suite di regressione come sottoprodotto.
DDT (Data-Driven Testing)
Una tecnica che esegue la stessa logica di test su molte righe di input/output atteso fornite da una tabella o da una fonte esterna, anziché duplicare il test per ogni caso. I framework la supportano tramite test parametrizzati, mantenendo i casi concisi e facili da estendere.
DoD (Definition of Done)
La checklist condivisa ed esplicita che un elemento di lavoro deve soddisfare per essere considerato completato - tipicamente include test scritti e passanti, codice revisionato e criteri di accettazione soddisfatti. Una DoD chiara impedisce di negoziare il "fatto" a posteriori.
SLA / SLO / SLI
Un Service Level Indicator è un segnale misurato (es. latenza p99); un Service Level Objective è il target per quell'indicatore (es. p99 < 300 ms nel 99,9% dei casi); un Service Level Agreement è l'impegno promesso esternamente, spesso contrattuale. I test di performance e affidabilità validano che il sistema possa rispettare le sue SLO.
SAST (Static Application Security Testing)
Analisi del codice sorgente, del bytecode o dei binari alla ricerca di difetti di sicurezza senza eseguire il programma, tipicamente integrata in CI per segnalare presto problemi come sink di injection e segreti hardcoded. Si abbina alla DAST, che testa l'applicazione in esecuzione.
QA (Quality Assurance)
La disciplina orientata al processo di costruire la qualità nel modo in cui il software viene prodotto - chiarezza dei requisiti, review, strategia di test e miglioramento continuo - distinta dal quality control, che ispeziona il prodotto finito.
QC (Quality Control)
L'attività orientata al prodotto di ispezionare e testare il software finito o in corso per rilevare difetti rispetto alle specifiche. Il QC è un sottoinsieme del più ampio sforzo di quality assurance.
MTTR (Mean Time To Recovery)
Il tempo medio impiegato per ripristinare il servizio dopo un guasto, una metrica chiave di affidabilità usata insieme al change failure rate nell'insieme DORA. Buona osservabilità e percorsi di rollback testati riducono l'MTTR.
MTBF (Mean Time Between Failures)
Il tempo operativo medio tra i guasti di un sistema, una misura di affidabilità per cui i soak e gli stress test forniscono evidenza. Un MTBF più alto indica un sistema più affidabile sotto uso prolungato.
POM (Page Object Model)
Un pattern di test di UI che incapsula ogni pagina o componente dietro un oggetto che espone metodi rivelatori di intenzione e nasconde i selettori. Localizza i cambiamenti di UI così che un locator modificato si corregga in un solo punto anziché in molti test.
RAGAS
Un framework open-source di valutazione per la retrieval-augmented generation che assegna punteggi alle risposte su metriche come faithfulness, answer relevancy e context recall/precision. È ampiamente usato per costruire gate di qualità automatici per sistemi LLM e RAG.
p95 / p99 (Latenza ai Percentili)
Il valore di latenza sotto il quale si completa il 95% (o il 99%) delle richieste. I percentili di coda espongono l'esperienza delle richieste lente che le medie nascondono, perciò i test di performance verificano p95/p99 anziché la media.
SLA Burn Rate
Il ritmo a cui un error budget (la quota di guasti consentita da una SLO) viene consumato. Un consumo rapido fa scattare gli allarmi; i test di affidabilità e gli esperimenti di caos aiutano a validare che il sistema resti entro il budget.
VRT (Visual Regression Testing)
Confronto automatico di screenshot renderizzati con baseline approvate per cogliere cambiamenti visivi non voluti (spostamenti di layout, colore, elementi mancanti). Protegge l'aspetto della UI che le asserzioni funzionali non coprono e richiede una revisione disciplinata delle baseline.
CDC (Consumer-Driven Contracts)
Uno stile di contract testing in cui i consumatori pubblicano le aspettative da cui dipendono e ogni fornitore verifica indipendentemente di poterle soddisfare. Coglie le rotture di integrazione tra servizi senza ambienti end-to-end completi.
SbE (Specification by Example)
Una tecnica collaborativa per i requisiti che usa esempi concreti per specificare il comportamento atteso, esempi che diventano poi test di accettazione automatici. Riduce l'ambiguità sostituendo affermazioni astratte con illustrazioni eseguibili.
HiL / SiL (Hardware/Software-in-the-Loop)
Configurazioni di test, comuni nei sistemi embedded e automotive, in cui hardware reale (HiL) o un modello software (SiL) di un componente gira in un ambiente simulato per validare il comportamento prima della piena integrazione. Consentono di testare la logica di controllo contro condizioni realistiche in sicurezza.
Metriche DORA
Le quattro metriche di performance di delivery del programma DevOps Research and Assessment: frequenza di deploy, lead time dei cambiamenti, change failure rate e tempo di ripristino del servizio. L'automazione dei test e i gate di qualità influenzano fortemente il change failure rate e il tempo di recupero.
Pact
Uno strumento e un formato di file molto usato per i contract test consumer-driven. Un consumatore genera un pact che descrive le interazioni che si aspetta, che il fornitore poi verifica, disaccoppiando la validazione dell'integrazione dagli ambienti condivisi.
A/B Test
Un esperimento online controllato che divide il traffico reale tra varianti per misurare l'effetto causale di un cambiamento su una metrica. È una tecnica di validazione in produzione distinta dal testing funzionale pre-rilascio, usata per confermare che un cambiamento produca l'impatto voluto.
Canary Release
Una strategia di deploy che instrada prima una piccola frazione di traffico verso una nuova versione, osservando tassi di errore e latenza prima di allargare il rollout. È una forma di testing in produzione che limita il raggio d'azione di un rilascio difettoso.
Chaos Testing
La pratica di iniettare deliberatamente guasti (terminare istanze, aggiungere latenza, perdere pacchetti) in un sistema per verificare che degradi con grazia e si riprenda. Valida le assunzioni di resilienza che i test ordinari danno per scontate anziché esercitare.