📋 Indice dei Contenuti
1. Cos'è la Definition of Done
Per garantire che tutti questi aspetti siano rispettati, il team stabilisce una Definition of Done condivisa. La DoD è un accordo tra tutti i membri del team su cosa significa "completato".
🎯 Scopo della Definition of Done
- Standard condivisi: Tutti sanno cosa significa "finito"
- Qualità garantita: Ogni rilascio rispetta gli stessi criteri
- Riduzione bug: Controlli sistematici prevengono problemi
- Trasparenza: Stakeholder vedono cosa include ogni delivery
💡 DoD vs Acceptance Criteria
Acceptance Criteria: Specifici per ogni User Story ("cosa deve fare")
Definition of Done: Standard generali per tutte le story ("come deve essere fatto")
2. Definition of Done Completa
Una DoD efficace copre 5 aree fondamentali. Ogni User Story deve soddisfaretutti questi criteri prima di essere considerata completata.
💻 Codice
- ✅ Sviluppato seguendo gli standard di coding condivisi
- ✅ Versionato in Git, incluso sulla branch con il nome della funzionalità
- ✅ Code review effettuata e approvata da almeno un membro del team
🧪 Test
- ✅ Test end-to-end (E2E) eseguiti (anche usando semplicemente strumenti come Postman)
- ✅ Unit test scritti, automatizzati e superati
- ✅ Test di integrazione eseguiti e superati
- ✅ Copertura test rispettata (soglia minima stabilita dal team)
📚 Documentazione
- ✅ API documentate (es. Swagger / Postman) e aggiornate
- ✅ Commenti essenziali presenti nel codice, dove utile
- ✅ Note di rilascio o changelog aggiornati
📊 Implementazione di Monitoraggio & Analytics
- ✅ Eventi di analytics implementati e verificati (es. "User Registered", "User Logged In", "User Failed Login")
- ✅ Logging strutturato e conforme agli standard di osservabilità
🔒 Verifica di Sicurezza e Qualità
- ✅ Checklist OWASP (validazioni input, gestione sessioni, rate limiting, ecc.)
- ✅ Nessuna vulnerabilità critica rilevata da scansioni statiche/dinamiche (SAST/DAST)
- ✅ Dependency audit senza falle gravi
3. QA e Testing Strategy
Il nostro approccio alla Quality Assurance e alla sicurezzasegue gli standard internazionali più rigorosi, inclusa la checklist OWASP.
🧪 Piramide dei Test
Unit Test (Base della Piramide)
Test automatizzati che verificano singole funzioni o componenti in isolamento.
Velocità: Millisecondi
Strumenti: Jest, PHPUnit, JUnit
Integration Test (Livello Intermedio)
Verificano che diversi componenti funzionino correttamente insieme.
Velocità: Secondi
Strumenti: Postman, Supertest, TestContainers
End-to-End Test (Vertice)
Simulano il comportamento dell'utente finale attraverso l'intera applicazione.
Velocità: Minuti
Strumenti: Cypress, Playwright, Selenium
📋 QA Checklist Operativa
🔍 Test Funzionali
- ☐ Tutti gli Acceptance Criteria sono verificati
- ☐ Happy path funziona correttamente
- ☐ Edge cases gestiti appropriatamente
- ☐ Error handling implementato e testato
- ☐ Validazioni input/output verificate
⚡ Test Performance
- ☐ Tempi di risposta sotto le soglie definite
- ☐ Load testing per scenari di picco
- ☐ Memory leaks verificati
- ☐ Database queries ottimizzate
- ☐ Caching implementato dove necessario
📱 Test Compatibility
- ☐ Cross-browser testing (Chrome, Firefox, Safari, Edge)
- ☐ Responsive design su dispositivi mobili
- ☐ Accessibilità (WCAG 2.1 AA)
- ☐ Backward compatibility verificata
- ☐ API versioning rispettato
4. Sicurezza OWASP
La sicurezza non è un'aggiunta finale, ma deve essere integrata in ogni fase dello sviluppo. Seguiamo la OWASP Top 10 e implementiamo controlli di sicurezza sistematici.
🛡️ OWASP Security Checklist
Injection
Validazione input, prepared statements, escaping output
• SQL injection prevention
• XSS protection
• Command injection blocking
Authentication
MFA, password policy, session management sicuro
• Multi-factor authentication
• Password strength policy
• Session timeout
Data Protection
Encryption at rest/in transit, GDPR compliance
• HTTPS enforcement
• Database encryption
• PII data handling
Logging
Audit trail completo, monitoring real-time
• Security events logging
• Real-time monitoring
• Incident response
Access Control
Autorizzazioni granulari, principio del minimo privilegio
• Role-based access control
• API authorization
• Resource permissions
Security Config
Configurazioni sicure, hardening server
• Security headers
• Server hardening
• Dependency scanning
🔍 Security Testing Tools
🔍 SAST (Static Analysis)
Analisi del codice sorgente per vulnerabilità
- SonarQube: Analisi completa codice e sicurezza
- ESLint Security: Plugin per JavaScript/TypeScript
- Bandit: Scanner sicurezza per Python
🎯 DAST (Dynamic Analysis)
Test dell'applicazione in esecuzione
- OWASP ZAP: Scanner vulnerabilità web
- Burp Suite: Testing penetrazione professionale
- Nikto: Scanner web server
📦 Dependency Scanning
Controllo vulnerabilità nelle dipendenze
- npm audit: Vulnerabilità Node.js packages
- Snyk: Monitoring continuo dipendenze
- OWASP Dependency Check: Scanner multi-linguaggio
5. Quality Gates
I Quality Gates sono controlli automatizzati che impediscono il rilascio di codice che non rispetta gli standard di qualità. Sono il nostro "firewall" contro i bug.
Gate 1: Code Quality
- ✅ Code coverage ≥ 80%
- ✅ Zero critical/high severity issues
- ✅ Code review approvata
- ✅ Coding standards rispettati
Gate 2: Testing
- ✅ Tutti i test automatizzati passano
- ✅ Performance test sotto soglia
- ✅ Security scan pulito
- ✅ Acceptance criteria verificati
Gate 3: Security
- ✅ OWASP checklist completata
- ✅ Dependency scan pulito
- ✅ Penetration test approvato
- ✅ Compliance verificata
Gate 4: Release
- ✅ Staging test completati
- ✅ Documentazione aggiornata
- ✅ Rollback plan preparato
- ✅ Stakeholder approval
💡 Automazione dei Quality Gates
I Quality Gates dovrebbero essere automatizzati il più possibile. Usa CI/CD pipeline (GitHub Actions, GitLab CI, Jenkins) per eseguire controlli automatici ad ogni commit e pull request.
6. Metriche di Successo DoD
📊 Metriche di Successo DoD
📈 KPI da Monitorare
🎯 Qualità
- Difetti sfuggiti in produzione
- Tempo medio risoluzione bug
- Customer satisfaction score
- Percentuale hotfix
⚡ Velocità
- Lead time (idea → produzione)
- Cycle time (sviluppo → rilascio)
- Deployment frequency
- Mean time to recovery
🔒 Sicurezza
- Vulnerabilità critiche aperte
- Tempo medio patch security
- Compliance score
- Security incidents
7. Domande Frequenti
👥 Chi definisce la Definition of Done?
La DoD deve essere definita collaborativamente da tutto il team di sviluppo, inclusi sviluppatori, QA, DevOps e Product Owner. Non è un'imposizione dall'alto.
📊 Quanto deve essere il code coverage?
Non esiste un numero magico, ma 80-90% è un buon target per la maggior parte dei progetti. L'importante è la qualità dei test, non solo la quantità.
Applicazioni critiche, fintech, healthcare
Applicazioni business standard
Prototipi, MVP, progetti interni
Rischio alto, non raccomandato
🔒 Cosa include un controllo OWASP minimo?
Un controllo OWASP minimo deve coprire le vulnerabilità più critichedella OWASP Top 10. Ecco una checklist essenziale:
🚨 Controlli Critici (Obbligatori)
- ✅ A01 - Broken Access Control: Autorizzazioni verificate
- ✅ A02 - Cryptographic Failures: Dati sensibili crittografati
- ✅ A03 - Injection: Input validation e prepared statements
- ✅ A05 - Security Misconfiguration: Configurazioni sicure
- ✅ A06 - Vulnerable Components: Dipendenze aggiornate
⚡ Controlli Raccomandati
- ✅ A04 - Insecure Design: Threat modeling
- ✅ A07 - Authentication Failures: MFA implementato
- ✅ A08 - Software Integrity: Code signing
- ✅ A09 - Logging Failures: Security monitoring
- ✅ A10 - Server-Side Request Forgery: SSRF protection
⏱️ Quanto tempo aggiunge la DoD allo sviluppo?
Inizialmente la DoD può sembrare rallentare lo sviluppo, ma accelera il delivery complessivoriducendo drasticamente bug, rework e hotfix.
🛡️ Hai bisogno di supporto per QA e Sicurezza?
Il nostro team può aiutarti a implementare una Definition of Done robusta e sistemi di QA e sicurezza OWASP nella tua organizzazione.