Regole di Business - Testing & QA

Questo documento elenca le regole di business fondamentali del dominio Testing & QA, identificate con codice univoco BR-NNN. Ogni regola è technology-independent e descrive un vincolo invariante sul processo di verifica della qualità del software.

---

BR-001 - Ogni TestCase ha un oracolo verificabile

Codice: BR-001 Nome: Un TestCase definisce un esito atteso non ambiguo Descrizione: Ogni caso di test ha un oracolo di test esplicito (l'esito atteso) e asserzioni che lo verificano, tipicamente in struttura Arrange-Act-Assert. Un test senza asserzioni significative o senza esito atteso non verifica nulla. Motivazione: Garantire che un test fallisca quando il comportamento è errato e passi quando è corretto. Priorità: ALTA Attori: QA Engineer, Test Automation Engineer Tracciabilità: glossary "Oracolo di Test", "Asserzione", "Arrange-Act-Assert (AAA)"; BC-01.

---

BR-002 - La suite rispetta la piramide dei test

Codice: BR-002 Nome: La distribuzione dei test segue la piramide (molti unit, pochi E2E) Descrizione: Una TestSuite privilegia un'ampia base di test unitari veloci, un livello intermedio di test di integrazione e una punta ridotta di test end-to-end. L'inversione della piramide (molti E2E lenti) è un anti-pattern da evitare. Motivazione: Massimizzare velocità e affidabilità del feedback minimizzando i test fragili. Priorità: ALTA Attori: QA Engineer, Test Automation Engineer Tracciabilità: glossary "Piramide dei Test", "Test Unitario", "Test End-to-End (E2E)".

---

BR-003 - I test instabili sono corretti o isolati

Codice: BR-003 Nome: Un Test Instabile (Flaky) non resta nella suite di gate Descrizione: Un test che passa e fallisce in modo non deterministico erode la fiducia nella suite. Va corretto (rimuovendo la fonte di non determinismo) o temporaneamente isolato e tracciato, mai ignorato silenziosamente. Motivazione: Preservare la fiducia nei risultati e la capacità del gate di bloccare regressioni reali. Priorità: ALTA Attori: Test Automation Engineer, QA Engineer Violazione: una suite con flaky non isolati non è affidabile come release gate. Tracciabilità: glossary "Test Instabile (Flaky)"; events/domain-events.md evento RegressioneRilevata.

---

BR-004 - Ogni difetto è registrato come BugReport tracciabile

Codice: BR-004 Nome: Un Difetto (Bug) rilevato genera un BugReport riproducibile Descrizione: Ogni difetto è registrato con passi di riproduzione, comportamento atteso e osservato, severità e ambiente. Un bug non riproducibile è triagiato per ottenere informazioni, non chiuso silenziosamente. Motivazione: Rendere ogni difetto gestibile, prioritizzabile e verificabile alla chiusura. Priorità: ALTA Attori: QA Engineer, Developer Tracciabilità: glossary "Difetto (Bug)"; state-machines/bug-report-lifecycle.md; BR-007.

---

BR-005 - Il codice modificato è coperto da test di regressione

Codice: BR-005 Nome: Una correzione include un test di regressione che cattura il difetto Descrizione: Quando un BugReport è risolto, un RegressioneTest che fallisce prima del fix e passa dopo è aggiunto alla suite. Questo impedisce il ritorno dello stesso difetto. Motivazione: Prevenire la regressione dei difetti già corretti. Priorità: ALTA Attori: Developer, Test Automation Engineer Tracciabilità: glossary "Test di Regressione"; state-machines/bug-report-lifecycle.md stato verified; BR-004.

---

BR-006 - La copertura è significativa, non solo numerica

Codice: BR-006 Nome: Il CoverageReport misura comportamento testato, non solo righe eseguite Descrizione: La copertura è uno strumento, non un obiettivo: una soglia funge da guardrail ma una copertura alta con asserzioni deboli non protegge. Si privilegiano casi limite, partizioni di equivalenza e scenari negativi. Motivazione: Evitare la falsa sicurezza di una copertura elevata ma vuota. Priorità: MEDIA Attori: QA Engineer, Developer Tracciabilità: glossary "Code Coverage", "Analisi dei Valori Limite", "Partizionamento di Equivalenza", "Test Negativo".

---

BR-007 - Una release passa solo con il gate di qualità verde

Codice: BR-007 Nome: Una release richiede una TestSuite verde e nessun bug bloccante aperto Descrizione: Il ReleaseGate è superato solo quando la suite è green, la copertura rispetta la soglia e non esistono BugReport di severità bloccante aperti. Un gate fallito blocca il rilascio. Motivazione: Garantire che solo software verificato raggiunga la produzione. Priorità: ALTA Attori: Release Manager, QA Engineer Violazione: rilascio bloccato finché il gate non è verde. Tracciabilità: glossary "Smoke Test", "Quality Assurance (QA)"; events/domain-events.md evento ReleaseGatePassato.

---

BR-008 - I test sono indipendenti e ripetibili

Codice: BR-008 Nome: Ogni TestCase è isolato e non dipende dall'ordine di esecuzione Descrizione: I test non condividono stato mutabile né dipendono dall'esito di altri test. Ognuno predispone (Fixture) e ripulisce il proprio contesto, così da essere eseguibile in isolamento e in parallelo con esito deterministico. Motivazione: Garantire risultati ripetibili e parallelizzabili, prevenire flakiness da accoppiamento. Priorità: ALTA Attori: Test Automation Engineer, QA Engineer Tracciabilità: glossary "Fixture", "Test Fixture", "System Under Test (SUT)"; BR-003.