Impara / Glossario
Glossario del testing del software
Definizioni chiare dei termini che QA engineer e SDET usano ogni giorno, ciascuna con un esempio e i link a lezioni, laboratori e domande di colloquio che la approfondiscono.
77 termini · Fondamenti del testing 26 · Progettazione dei test 5 · Automazione della UI 18 · Testing delle API 8 · CI/CD e DevOps 5 · Performance 5 · Sicurezza 4 · AI nel testing 6
Fondamenti del testing
- Black-box testing (test a scatola nera) Black-box testing Testare un sistema attraverso input e output rispetto ai requisiti, senza guardare il codice interno o il design e senza basarsi su di essi.
- Code coverage (copertura del codice) Code coverage La percentuale di codice sorgente (righe, istruzioni, rami o funzioni) eseguita durante i test. Mostra cosa non è testato, non cosa è testato bene.
- Criteri di accettazione Acceptance criteria Le condizioni specifiche e verificabili che una user story o una funzionalità deve soddisfare per essere accettata come completa dal product owner.
- Flaky test (test instabile) Flaky test Un test che passa e fallisce sullo stesso codice senza alcuna modifica, di solito per tempistiche, stato condiviso, ordine dei test o ambiente instabile.
- Matrice di tracciabilità dei requisiti (RTM) Requirements traceability matrix Tabella che collega ogni requisito ai test case che lo verificano e ai loro risultati, rendendo visibili le lacune di copertura e l'impatto delle modifiche.
- Mutation testing Tecnica che inserisce nel codice piccoli bug deliberati (mutanti) e riesegue i test per misurare se la suite rileva davvero i difetti.
- Oracolo di test (test oracle) Test oracle La fonte di verità con cui un test decide se un output è corretto, come una specifica, una versione precedente, un modello di riferimento o una regola.
- Piano di test (test plan) Test plan Documento che definisce ambito, approccio, risorse, calendario, ambienti, rischi e criteri di ingresso e di uscita per il testing di un rilascio o di un progetto.
- Piramide dei test Test pyramid Modello per bilanciare una suite automatizzata: molti unit test veloci alla base, meno test di integrazione al centro e pochi test end-to-end in cima.
- Priorità del bug Bug priority Quanto è urgente correggere un difetto rispetto al resto del lavoro, in base alle esigenze di business. Di solito la decide il product owner o il bug triage.
- Risk-based testing (test basato sul rischio) Risk-based testing Approccio che assegna le priorità ai test in base al rischio, cioè probabilità di guasto per impatto, così le aree più rischiose vengono testate prima e più a fondo.
- Sanity testing Verifica mirata e ristretta dopo una piccola modifica o un bug fix, per confermare che l'area interessata funzioni come previsto prima di proseguire con test più ampi.
- Scenario di test (test scenario) Test scenario Descrizione di alto livello di un obiettivo dell'utente o di una funzionalità da testare, come "verificare il checkout con una carta salvata", poi suddivisa in test case.
- Severità del bug Bug severity L'impatto di un difetto sul sistema o sugli utenti, da un crash totale o una perdita di dati fino a un problema estetico. Di solito la assegna il QA.
- Shift-left testing Anticipare test e attività di qualità nel ciclo di consegna del software, così i difetti vengono prevenuti o intercettati quando correggerli costa meno.
- Smoke testing Verifica rapida e superficiale delle funzioni più critiche di una nuova build per decidere se è abbastanza stabile da meritare test più approfonditi.
- Test case (caso di test) Test case Insieme specifico di precondizioni, dati di input, passi e risultati attesi che verifica un comportamento del sistema e produce un esito chiaro, superato o fallito.
- Test di integrazione Integration test Un test che verifica se due o più componenti, come un servizio e il suo database o due API, funzionano correttamente insieme attraverso le loro interfacce reali.
- Test di regressione Regression testing Rieseguire i test esistenti dopo una modifica per confermare che ciò che già funzionava funziona ancora e che la correzione o la nuova funzionalità non ha rotto altro.
- Test double Qualsiasi oggetto che sostituisce una dipendenza reale in un test, come dummy, stub, fake, spy o mock, così il codice sotto test gira in modo veloce e prevedibile.
- Test end-to-end (E2E) End-to-end test Un test che percorre un intero percorso utente sul sistema reale e completamente rilasciato, dalla UI o dall'API pubblica fino al database e ritorno.
- Test esplorativo (exploratory testing) Exploratory testing Un approccio in cui il tester progetta ed esegue i test nello stesso momento, usando ciò che ogni risultato rivela per decidere cosa provare dopo.
- Unit test (test unitario) Unit test Test automatico che verifica una piccola porzione di codice, come una funzione o una classe, in isolamento da database, rete e altri servizi.
- User acceptance testing (UAT) User acceptance testing La fase finale di test, in cui utenti reali o rappresentanti del business confermano che il sistema soddisfa le loro esigenze ed è pronto per essere accettato e rilasciato.
- Verifica e validazione Verification and validation La verifica chiede "stiamo costruendo il prodotto nel modo giusto?" rispetto alla specifica; la validazione "stiamo costruendo il prodotto giusto?"
- White-box testing (test a scatola bianca) White-box testing Test progettati a partire dalla conoscenza del codice interno, come branch, condizioni e percorsi, per assicurarsi che l'implementazione si comporti correttamente.
Progettazione dei test
- Analisi dei valori limite Boundary value analysis Una tecnica black-box di progettazione dei test che sceglie gli input sui bordi degli intervalli validi e subito attorno, dove si concentrano gli errori off-by-one.
- Pairwise testing Tecnica combinatoria che sceglie un piccolo insieme di test case in cui ogni coppia di valori dei parametri compare insieme almeno una volta.
- Partizionamento in classi di equivalenza Equivalence partitioning Una tecnica di progettazione dei test che divide gli input in gruppi che il sistema deve trattare allo stesso modo, e testa un valore rappresentativo per gruppo.
- Tabelle decisionali (decision table testing) Decision table testing Una tecnica di progettazione dei test che elenca le combinazioni di condizioni e l'azione che ciascuna deve attivare, così che ogni regola di business abbia un test.
- Test delle transizioni di stato State transition testing Tecnica di test design che modella un sistema come stati ed eventi che lo spostano dall'uno all'altro, per poi testare le transizioni valide e quelle non valide.
Automazione della UI
- Auto-waiting (attesa automatica) Auto-waiting Una funzione del framework che attende che un elemento sia pronto (visibile, stabile e abilitato) prima di agire, invece di affidarsi a pause fisse.
- Behavior-Driven Development (BDD) Behavior-Driven Development Una pratica collaborativa in cui business, sviluppo e testing concordano il comportamento tramite esempi concreti, spesso scritti in Gherkin e automatizzati.
- Browser headless Headless browser Un vero motore di browser che gira senza una finestra visibile, usato per eseguire test di UI su server di CI e altre macchine prive di display.
- Data-driven testing (test guidati dai dati) Data-driven testing Eseguire la stessa logica di test su molti insiemi di input e risultati attesi, tenuti in una tabella, un file o una sorgente dati invece che copiati in ogni test.
- Explicit wait (attesa esplicita) Explicit wait Un'attesa che verifica ripetutamente una condizione specifica, per esempio che un elemento diventi cliccabile, fino a un timeout. In Selenium si scrive con WebDriverWait.
- Gherkin La sintassi Given-When-Then in testo semplice con cui si scrivono gli scenari BDD nei file .feature, che strumenti come Cucumber eseguono come test automatizzati.
- Implicit wait (attesa implicita) Implicit wait Un'impostazione globale di Selenium per cui ogni chiamata a findElement continua a cercare l'elemento fino a un tempo massimo prima di lanciare NoSuchElementException.
- Isolamento dei test Test isolation Proprietà per cui ogni test prepara il proprio stato e può passare da solo, in qualsiasi ordine e in parallelo, senza dipendere da altri test né influenzarli.
- Locator La query con cui un test UI trova un elemento nella pagina, ad esempio ruolo e nome, un test id, un selettore CSS o un'espressione XPath.
- Page Object Model (POM) Page Object Model Design pattern che incapsula ogni pagina o componente della UI in una classe, così i test chiamano metodi che esprimono l'intento invece di ripetere i locator.
- Selenium Grid Server Selenium che instrada le sessioni WebDriver verso nodi browser remoti, così i test possono girare in parallelo su molti browser, versioni e macchine.
- Selettore CSS CSS selector Un pattern del linguaggio CSS che trova elementi per tag, id, classe, attributo o posizione, molto usato come locator veloce e leggibile nei test di UI.
- StaleElementReferenceException Errore di Selenium lanciato quando un test usa un WebElement il cui nodo DOM è stato rimosso o sostituito dopo essere stato trovato, di solito dopo un re-render.
- Test fixture La preparazione fissa di cui un test ha bisogno prima di partire, come una pagina del browser, un utente precaricato o un database, più il teardown che poi fa pulizia.
- Test sharding Suddividere una suite di test in porzioni, dette shard, eseguite contemporaneamente su macchine separate, così una suite lunga termina in una frazione del tempo.
- Visual regression testing Confrontare screenshot della UI con immagini di riferimento approvate per intercettare modifiche visive involontarie come layout spostati, stili mancanti o sovrapposizioni.
- Web-first assertion Asserzione di Playwright che riceve un locator e ritenta finché la condizione attesa non è soddisfatta o scade il timeout, invece di controllare un valore una sola volta.
- XPath Linguaggio di query per selezionare nodi in un documento XML o HTML, usato nell'automazione UI per localizzare elementi in base a struttura, attributi o testo.
Testing delle API
- API REST REST API API HTTP progettata attorno a risorse identificate da URL, manipolate con metodi standard come GET, POST, PUT, PATCH e DELETE, con richieste stateless.
- Contract testing Verificare che un provider di API e i suoi consumer concordino su richieste e risposte scambiate, senza doverli rilasciare insieme per un test end-to-end.
- Idempotenza Idempotency La proprietà per cui inviare la stessa richiesta una o più volte lascia il server nello stesso stato. GET, PUT e DELETE sono idempotenti, POST no.
- JSON Schema Un vocabolario JSON per descrivere la struttura attesa dei dati JSON, con tipi, campi obbligatori e formati, usato per validare le risposte delle API.
- JWT (JSON Web Token) JWT Un JSON Web Token è un token compatto e firmato nella forma header.payload.signature che trasporta claim come id utente, scadenza e audience.
- OAuth 2.0 Framework di autorizzazione che permette a un'applicazione di ottenere un access token limitato per chiamare un'API per conto di un utente o proprio, senza gestire password.
- Rate limiting Limitare quante richieste un client può fare a un'API in una finestra di tempo, rifiutando l'eccesso, di solito con 429 Too Many Requests e un header Retry-After.
- Status code HTTP (codice di stato) HTTP status code Il numero di tre cifre presente in ogni risposta HTTP che indica se la richiesta è riuscita, è stata reindirizzata o è fallita per colpa del client o del server.
CI/CD e DevOps
- Container Docker Docker container Un'istanza isolata e in esecuzione di un'immagine Docker che impacchetta un'app o un servizio con le sue dipendenze, così che funzioni allo stesso modo in locale e in CI.
- Continuous integration (integrazione continua) Continuous integration La pratica di unire spesso piccole modifiche in un branch condiviso, con build e test automatici a ogni push, così che gli errori emergano in pochi minuti.
- Feature flag Un interruttore a runtime che attiva o disattiva un percorso di codice senza deploy, per rilasciare lavoro nascosto, distribuirlo per gradi e annullarlo in fretta.
- Quality gate Controllo automatico pass/fail in una pipeline, come test superati o coverage sopra una soglia, che deve riuscire prima che il codice possa essere unito o rilasciato.
- Testcontainers Libreria che avvia dipendenze reali come database, broker o browser in container Docker usa e getta direttamente dal codice dei test, per poi rimuoverli.
Performance
- Latenza percentile Percentile latency Misura del tempo di risposta come p95 o p99 che indica entro quanto si è conclusa quella quota di richieste, rivelando la coda lenta che le medie nascondono.
- Load testing (test di carico) Load testing Test di performance che sottopone un sistema al traffico reale previsto per verificare tempi di risposta, tasso di errore e throughput rispetto a obiettivi concordati.
- Soak testing (test di durata) Soak testing Test di performance che mantiene un carico normale e realistico per molte ore per far emergere problemi che si accumulano nel tempo, come i memory leak.
- Stress testing Test di performance che spinge il carico oltre i livelli previsti per trovare il punto di rottura, vedere come cede il sistema e verificare che poi si riprenda.
- Throughput La quantità di lavoro che un sistema completa per unità di tempo, di solito richieste o transazioni al secondo, misurata insieme a latenza e tasso di errore.
Sicurezza
- Cross-site scripting (XSS) Cross-site scripting L'XSS è una vulnerabilità in cui un input non attendibile viene eseguito come script nel browser di un altro utente, permettendo a un attaccante di agire al suo posto.
- IDOR Insecure Direct Object Reference, una falla nel controllo degli accessi per cui cambiare un ID in una richiesta permette di leggere o modificare i dati di un altro utente.
- OWASP Top 10 L'elenco di sensibilizzazione di OWASP con le dieci categorie di rischio più critiche per la sicurezza delle applicazioni web, usato per definire security test e code review.
- SQL injection Vulnerabilità in cui l'input dell'utente viene concatenato in una query SQL, permettendo a un attaccante di cambiarne la logica per leggere, alterare o cancellare dati.
AI nel testing
- Golden dataset Un insieme curato e versionato di input con output attesi verificati, usato come benchmark fisso per i test di regressione di modelli, prompt o pipeline.
- LLM-as-judge (LLM come giudice) LLM-as-judge Usare un modello linguistico con una rubrica scritta per valutare gli output di un altro modello, un sostituto scalabile ma distorto della revisione umana.
- Model Context Protocol (MCP) Model Context Protocol MCP è un protocollo aperto per collegare assistenti e agenti AI a strumenti e dati esterni, come un browser, un repository o un sistema di test management.
- Prompt injection Attacco in cui un testo fornito a un LLM, digitato dall'utente o nascosto nei contenuti che legge, scavalca le istruzioni dello sviluppatore e ne cambia il comportamento.
- Self-healing locator Locator che, quando non trova più l'elemento, lascia allo strumento di test la scelta di un sostituto probabile in base ad attributi salvati o a un modello.
- Valutazione degli LLM (LLM evaluation) LLM evaluation Misurare in modo sistematico la qualità di una funzionalità basata su LLM su input e criteri fissi, perché gli output variano e le asserzioni esatte di rado bastano.