Il software testing è la verifica strutturata di un software per trovare difetti, dimostrare che i requisiti sono rispettati e ridurre il rischio di business prima e dopo il rilascio. Per CTO e responsabili tecnici, il test del software non è una checklist del reparto QA: è una capacità di delivery che protegge ricavi, reputazione, conformità e velocità di sviluppo del prodotto.
TL;DR: punti chiave
- Testate in base al rischio, non all'abitudine: date priorità ai percorsi utente, alle integrazioni, ai flussi di dati e agli obblighi normativi che danneggerebbero di più l'azienda se fallissero.
- Usate più tipi di test: unit test, test di integrazione, di sistema, di accettazione, di regressione, di prestazioni, di sicurezza ed esplorativi fanno emergere ciascuno guasti diversi.
- Automatizzate dove conta la ripetibilità: i test automatizzati rendono al meglio sui controlli stabili e frequenti nella pipeline CI/CD; i test manuali restano essenziali dove serve giudizio umano.
- Trattate la conformità come evidenza: GDPR, NIS2, Cyber Resilience Act ed EU AI Act chiedono sempre più spesso controlli dimostrabili, non rassicurazioni informali.
- Misurate i risultati: monitorate difetti sfuggiti, change failure rate, test instabili (flaky), tempo medio di ripristino e copertura dei flussi critici, non il semplice numero di test.
Cos'è il software testing e perché è importante?
Il software testing è il processo con cui si verificano prodotti, componenti e sistemi software rispetto al comportamento atteso, agli attributi di qualità e al rischio di business. È importante perché le aziende di oggi funzionano grazie al software: un difetto può causare fermi, falle di sicurezza, controlli delle autorità e perdita di clienti. Un testing efficace dà al management la fiducia, basata su evidenze, per rilasciare più spesso senza scommettere sulla qualità.
Secondo ISO (ISO/IEC/IEEE 29119-1:2022, pubblicata a gennaio 2022), lo standard internazionale definisce i concetti generali del software testing e li colloca all'interno della serie ISO/IEC/IEEE 29119. Questo conta perché inquadra il testing come una disciplina ingegneristica con processi, artefatti e governance, non come una caccia ai bug dell'ultimo minuto. (iso.org)
Anche il caso economico è chiaro. Secondo CISQ, The Cost of Poor Software Quality in the US: A 2022 Report (copyright 2022; stime 2022), la scarsa qualità del software è costata agli Stati Uniti almeno 2.410 miliardi di dollari, con un debito tecnico accumulato stimato in circa 1.520 miliardi di dollari. È una stima sull'economia statunitense, non un benchmark per le imprese europee, ma rende l'idea dello spreco generato quando difetti, vulnerabilità e debito tecnico arrivano in produzione. (it-cisq.org)
Per le medie imprese europee la domanda pratica raramente è «facciamo test?». La domanda è se i test sono allineati al rischio di delivery. Un team può avere centinaia di controlli di poco valore e lasciare comunque poco testati i flussi di pagamento, la logica IVA per le vendite transfrontaliere, la gestione delle identità o l'esportazione dei dati dei clienti.
Una strategia di software testing matura deve rispondere a cinque domande del management:
- Cosa potrebbe guastarsi in un modo che danneggia clienti o ricavi?
- Quali difetti hanno più probabilità di sfuggire, data la nostra architettura e il nostro modello di delivery?
- Quali controlli devono girare automaticamente a ogni modifica?
- Quali evidenze servono per auditor, clienti e autorità di controllo?
- Quanto rapidamente possiamo individuare, isolare e correggere un difetto in produzione?
Le organizzazioni che testano meglio collegano queste domande a product ownership, architettura e metriche DevOps. Secondo il 2024 Accelerate State of DevOps Report di DORA (ultima versione corretta v.2024.3; errata aggiornata l'8 ottobre 2024), i team dovrebbero affrontare il miglioramento continuo in modo sperimentale e misurare il proprio punto di partenza prima di cambiare le pratiche di delivery. Il testing deve quindi migliorare insieme flusso e affidabilità, non diventare un cancello separato che i team cercano di aggirare. (dora.dev)
Un modello operativo utile è la «piramide dei test basata sul rischio»: molti unit test veloci alla base, meno test di integrazione e delle API nel mezzo e pochi test end-to-end selezionati con cura in cima. Così il feedback resta rapido e si verificano comunque i percorsi utente che contano.
Quali tipi di test del software deve usare un team moderno?
Un team moderno deve combinare a più livelli test funzionali e non funzionali, manuali e automatizzati. Gli unit test controllano piccole porzioni di codice, i test di integrazione verificano le interazioni, i test di sistema valutano il comportamento complessivo e i test di accettazione confermano l'obiettivo di business. Test di sicurezza, prestazioni, usabilità e regressione coprono poi i rischi che i soli test funzionali non intercettano.
Secondo il Certified Tester Foundation Level Syllabus v4.0.1 di ISTQB (datato 15 settembre 2024), il livello Foundation si rivolge non solo ai tester ma anche a sviluppatori, project manager, quality manager, product owner, direttori IT e consulenti di management. Questa ampiezza riflette un fatto chiave: il testing è una responsabilità condivisa tra funzioni, non un singolo ruolo. (istqb.org)
Questa è la mappa sintetica che serve a chi decide, prima di scegliere gli strumenti o riorganizzare il QA.
| Tipo di test | Cosa dimostra | Responsabile tipico |
|---|---|---|
| Unit test | Una piccola funzione o classe si comporta correttamente | Sviluppatore |
| Test di integrazione | Servizi, moduli o API funzionano insieme | Sviluppatore / QA |
| Test di sistema | L'intera applicazione rispetta i requisiti | QA / team di prodotto |
| Test di accettazione | Il software supporta i risultati di business | Product owner / rappresentante degli utenti |
| Test di regressione | Il comportamento esistente funziona ancora dopo una modifica | QA / team di automazione |
| Test di prestazioni | Il sistema regge carico, latenza e scalabilità richiesti | QA / team di piattaforma |
| Test di sicurezza | Vulnerabilità e possibili abusi vengono individuati | Sicurezza / DevSecOps |
| Test di usabilità | Gli utenti completano i compiti in modo efficace | UX / team di prodotto |
| Test di compatibilità | Il software funziona negli ambienti di destinazione | QA / team di rilascio |
| Test esplorativi | Rischi non noti vengono indagati con il giudizio umano | Tester esperto |
Unit test, test di integrazione e test di sistema
Gli unit test (test unitari) danno un feedback rapido vicino al codice. Sono la scelta giusta per regole di business, calcoli, trasformazioni di dati e casi limite che si possono isolare senza un ambiente completo. In Java, JUnit resta la base più comune; secondo la JUnit 5 User Guide (versione 5.13.1), JUnit 5 unisce JUnit Platform, JUnit Jupiter e JUnit Vintage, e Jupiter fornisce il modello di programmazione ed estensione per i test moderni. (docs.junit.org)
I test di integrazione intercettano un'altra classe di difetti: contratti, schemi, formati dei messaggi, flussi di autenticazione e dipendenze tra servizi. Sono particolarmente importanti per microservizi, integrazioni con l'ERP, pagamenti, sistemi di magazzino e portali clienti, dove «il codice funziona» non significa «il processo funziona».
I test di sistema verificano poi l'applicazione come prodotto completo. Devono coprire dati realistici, configurazioni, ruoli, permessi e condizioni di errore. Per le piattaforme B2B questo comprende spesso gerarchie di account, fatturazione, contenuti multilingua, log di audit e il degrado di servizi di terze parti.
Test di accettazione, di regressione ed esplorativi
I test di accettazione traducono l'obiettivo di business in esempi verificabili. Il behaviour-driven development può aiutare, ma solo se gli scenari sono scritti in un linguaggio che prodotto, sviluppo e QA capiscono tutti. Un test di cui nessuno si fida diventa documentazione di facciata.
I test di regressione proteggono il valore che già esiste. Le suite di regressione migliori sono selettive, basate sul rischio e manutenute come codice di produzione. Quelle deboli crescono fino a diventare lente, instabili e politicamente impossibili da eliminare.
I test esplorativi restano essenziali perché non tutti i rischi si conoscono in anticipo. Tester esperti usano conoscenza del prodotto, euristiche e curiosità per trovare lacune che i test scritti a copione non vedono. Nei processi complessi, una sola sessione esplorativa può rivelare una gestione degli errori poco chiara, permessi incoerenti o ipotesi nascoste sulla qualità dei dati.
Test di prestazioni, di sicurezza e di usabilità
I test di prestazioni devono iniziare prima di un lancio importante, non durante la gestione dell'incidente. Secondo la documentazione di Apache JMeter (sito ufficiale consultato nel 2026), JMeter è un software open source pensato per i test di carico del comportamento funzionale e per misurare le prestazioni di applicazioni web, API, database e altri protocolli. (jmeter.apache.org)
I test di sicurezza devono includere il rischio delle dipendenze, autenticazione, autorizzazione, validazione degli input, gestione dei segreti e casi di abuso. Secondo la Web Security Testing Guide di OWASP (ultima edizione online consultata nel 2026), la guida comprende un framework di test, i test di sicurezza delle applicazioni web e risorse per il reporting. (owasp.github.io)
I test di usabilità colmano la distanza tra «funzionalmente corretto» e «usabile sotto pressione». In un sistema B2B la scarsa usabilità diventa costo operativo: ticket di assistenza, formazione, soluzioni di ripiego ed errori nei dati.
Quali strumenti di software testing sono indispensabili?
Gli strumenti indispensabili sono i framework di unit test, gli strumenti per testare le API, i framework di automazione del browser, gli strumenti per i test di prestazioni, le risorse per i test di sicurezza, i sistemi di gestione dei test e le piattaforme CI/CD. Il set giusto dipende dalla vostra architettura e dalla maturità del team. Non acquistate una piattaforma prima di aver chiarito chi possiede i test, gli ambienti, la strategia sui dati di test e la capacità di manutenzione.
La scelta degli strumenti deve partire dal livello di test, non dalla shortlist dei fornitori. Un front end React, un back end Java e un insieme di integrazioni a eventi richiedono una toolchain diversa da una piattaforma dati in Python o da un SaaS regolamentato con requisiti di audit stringenti.
| Categoria di strumenti | Opzioni comuni | Ideale per |
|---|---|---|
| Unit test | JUnit, pytest, NUnit, Jest | Feedback rapido a livello di codice |
| Test delle API | Postman, REST Assured, Pact | Contratti tra servizi e flussi |
| Automazione del browser | Selenium, Playwright, Cypress | Percorsi utente e regressione |
| Test di prestazioni | Apache JMeter, Gatling, k6 | Test di carico, stress e capacità |
| Test di sicurezza | OWASP ZAP, Snyk, Semgrep, scanner delle dipendenze | Individuare vulnerabilità |
| Esecuzione in CI/CD | GitHub Actions, GitLab CI, Jenkins, Azure DevOps | Quality gate automatici |
| Gestione dei test | Xray, Zephyr, TestRail | Tracciabilità e reporting |
Secondo la documentazione di pytest (versione stabile consultata nel 2026), pytest è pensato per rendere semplice scrivere test piccoli e, allo stesso tempo, scalare fino a test funzionali complessi per applicazioni e librerie. È quindi una scelta pratica per i team Python che vogliono test leggibili, fixture ed estensibilità tramite plugin. (docs.pytest.org)
Per l'automazione del browser, la scelta tra Selenium e Playwright dipende spesso dai sistemi esistenti, dalle competenze del team e dalle esigenze di affidabilità. Secondo la documentazione di Selenium (ultima modifica 16 settembre 2026), Selenium è un progetto ombrello di strumenti e librerie per l'automazione del browser e l'esecuzione cross-browser basata su WebDriver. Secondo la documentazione di Playwright di Microsoft (consultata nel 2026), Playwright automatizza Chromium, Firefox e WebKit, con attesa automatica, asserzioni, tracing ed esecuzione in parallelo. (selenium.dev)
I test delle API meritano un'attenzione particolare nei sistemi aziendali. Secondo la documentazione di Postman (consultata nel 2026), le collection di Postman possono funzionare come richieste salvate, flussi di lavoro o suite di test, ed essere eseguite per verificare il funzionamento delle API. È utile quando i team di prodotto hanno bisogno di una visione condivisa ed eseguibile del comportamento delle API nei diversi ambienti. (learning.postman.com)
La CI/CD trasforma questi strumenti in un sistema di delivery. Secondo GitHub Docs (consultato nel 2026), GitHub Actions permette di creare workflow di integrazione continua che compilano e testano automaticamente il codice per verificare se un commit introduce errori. Lo stesso principio vale per GitLab CI, Jenkins e Azure DevOps: i test devono girare dove gli sviluppatori già modificano il software. (docs.github.com)
Criteri di scelta per i CTO
Usate questi criteri prima di impegnarvi su licenze, framework o una «piattaforma di qualità»:
- Adattamento all'architettura: lo strumento supporta i vostri linguaggi, browser, API, code di messaggi e modello di deployment?
- Esperienza degli sviluppatori: gli sviluppatori possono eseguire i test in locale senza supporto specialistico?
- Affidabilità in CI: gestisce esecuzione in parallelo, isolamento e risultati deterministici?
- Manutenibilità: i test sono leggibili, versionati e di proprietà dei team di prodotto?
- Osservabilità: i fallimenti si possono collegare a log, trace, screenshot, chiamate di rete e commit?
- Evidenze di conformità: i risultati si possono conservare, esportare e associare ai controlli?
Spesso la decisione migliore sugli strumenti è togliere complessità. Molti team hanno bisogno di meno strumenti, di responsabilità più chiare e di dati di test più puliti prima di avere bisogno di un'altra dashboard.
Come applicare tecniche di testing efficaci?
Applicate le tecniche di test in base al rischio, alla velocità di feedback e al giudizio umano. Automatizzate i controlli deterministici, usate l'esplorazione manuale dove c'è ambiguità, applicate tecniche come i valori limite e le classi di equivalenza per ridurre il numero di test e integrate i risultati nella CI/CD. L'obiettivo non è testare di più, ma avere un feedback più precoce, più chiaro e più affidabile.
Test manuali e test automatizzati non sono rivali: rispondono a domande diverse. L'automazione chiede «questo comportamento noto funziona ancora?». Il test manuale chiede «cos'altro potrebbe essere sbagliato, poco chiaro, rischioso o scomodo?».
| Approccio | Uso migliore | Rischio se usato male |
|---|---|---|
| Test manuali | Esplorazione, usabilità, nuove funzionalità, processi ambigui | Ripetizione lenta e copertura incoerente |
| Test automatizzati | Regressione, verifiche delle API, unit test, smoke test, validazione dei dati | Suite instabili e falsa sicurezza |
| Analisi statica | Qualità del codice, pattern di sicurezza, manutenibilità | Rumore se le regole non sono gestite |
| Test dinamici | Comportamento a runtime, prestazioni, sicurezza, flussi end-to-end | Feedback tardivo se non automatizzati |
| Contract testing | Compatibilità delle API tra servizi | Poco valore se nessuno possiede i contratti |
Usare le tecniche di progettazione dei test per ridurre lo spreco
Classi di equivalenza, analisi dei valori limite, tabelle decisionali e test delle transizioni di stato aiutano i team a coprire più rischio con meno casi di test. Una regola di fatturazione, per esempio, potrebbe non richiedere 200 test se i valori si possono raggruppare in categorie valide, non valide e di confine.
Le tabelle decisionali sono particolarmente utili per i prodotti B2B con combinazioni complesse: tipo di cliente, regione, regime fiscale, livello di sconto, soglia di approvazione e metodo di pagamento. Il test delle transizioni di stato funziona bene per processi come onboarding, evasione degli ordini, gestione dei sinistri e ciclo di vita degli abbonamenti.
Integrare la qualità nella CI/CD
Una sequenza pratica di test nella CI/CD può essere questa:
- Pre-commit: linting, scansione dei segreti e unit test locali veloci.
- Pull request: unit test, contract test delle API, analisi statica e test di integrazione mirati.
- Merge: regressione più ampia, build dei container, controllo delle dipendenze e smoke test.
- Pre-release: test end-to-end, baseline di prestazioni e controlli di sicurezza.
- Produzione: monitoraggio, test sintetici, feature flag e cicli di feedback dagli incidenti.
Secondo il report DORA 2024 (pubblicato nel 2024; ultima versione corretta v.2024.3), i team che mettono al centro i bisogni degli utenti finali e lavorano con priorità organizzative stabili sono meglio posizionati per ottenere qualità del prodotto e successo dell'organizzazione. Per il testing questo è un punto diretto: i test devono proteggere il valore per l'utente, non soltanto soddisfare un processo QA interno. (dora.dev)
Gestire con decisione i test instabili
I test instabili (flaky) sono più di un fastidio: insegnano agli sviluppatori a non fidarsi della pipeline. Quando succede, il team rilancia i test invece di indagare, ignora i fallimenti e riporta silenziosamente il giudizio sulla qualità su canali informali.
Trattate l'instabilità come debito tecnico, con un responsabile, una gravità e uno SLA. Mettete in quarantena i test inaffidabili, misurate quanto spesso si ripresentano e correggete le cause profonde: ipotesi sui tempi, stato condiviso, ambienti instabili, selettori fragili e dipendenze da servizi esterni.
Collegare la strategia di test all'architettura
È l'architettura a determinare cosa si può testare. Se i servizi non hanno contratti chiari, la proprietà dei dati è confusa e gli ambienti non si creano in modo affidabile, testare diventa costoso. Al contrario, architettura modulare, osservabilità e confini di deployment puliti riducono il costo dei test.
Per questo i test automatizzati e i test di integrazione non sono temi secondari: sono capacità ingegneristiche centrali che incidono sulla frequenza dei rilasci, sul numero di incidenti e sulla fiducia dei clienti.
Come supporta il testing la conformità e la governance?
Il testing supporta la conformità producendo evidenze che i controlli del software funzionano come previsto. Per le organizzazioni europee significa mappare i test sugli obblighi di protezione dei dati, cybersecurity, resilienza operativa e IA. I test di conformità devono verificare controlli di accesso, log di audit, cifratura, conservazione dei dati, resilienza, gestione delle vulnerabilità e tracciabilità delle modifiche lungo tutto il ciclo di delivery.
La conformità non è più solo una funzione legale o di sicurezza: è sempre più integrata nella delivery del software. I CTO europei hanno bisogno di evidenze di test che reggano la due diligence dei clienti, gli audit ISO, i questionari di procurement e il controllo delle autorità.
Secondo il testo EUR-Lex dell'articolo 32 del GDPR (Regolamento (UE) 2016/679, adottato il 27 aprile 2016 e applicabile dal 25 maggio 2018), titolari e responsabili del trattamento devono adottare misure tecniche e organizzative adeguate, compresa, ove opportuno, una procedura per testare, verificare e valutare regolarmente l'efficacia delle misure di sicurezza. È un obbligo diretto di verificare i controlli di sicurezza, non solo di documentare una policy. (eur-lex.europa.eu)
La NIS2 porta la resilienza operativa al livello del consiglio di amministrazione. Secondo EUR-Lex per la Direttiva (UE) 2022/2555 (NIS2, adottata il 14 dicembre 2022), gli Stati membri dovevano recepire la direttiva entro il 17 ottobre 2024 e applicarne le misure dal 18 ottobre 2024; l'articolo 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate di gestione dei rischi di cybersecurity. Gli obblighi per le aziende dipendono dal recepimento di ciascuno Stato membro (in Italia il D.Lgs. 138/2024), quindi i piani di test vanno adattati al paese per i soggetti interessati. (eur-lex.europa.eu)
Il Cyber Resilience Act cambia le aspettative per i prodotti software immessi sul mercato UE. Secondo la sintesi del CRA della Commissione europea (Regolamento (UE) 2024/2847, adottato il 23 ottobre 2024; Gazzetta ufficiale del 20 novembre 2024), l'atto si applica ai «prodotti con elementi digitali» hardware e software messi a disposizione nel mercato dell'Unione, e i produttori devono considerare la cybersecurity in pianificazione, progettazione, sviluppo, produzione, consegna e manutenzione. (digital-strategy.ec.europa.eu)
Il CRA introduce anche obblighi di segnalazione. Secondo le indicazioni della Commissione europea sul reporting CRA (consultate nel 2026), dall'11 settembre 2026 i produttori devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi che riguardano prodotti con elementi digitali, mentre gli steward di software open source sono soggetti agli obblighi di segnalazione dell'articolo 24(3) dall'11 dicembre 2027. (digital-strategy.ec.europa.eu)
I sistemi di IA aggiungono un ulteriore livello. Secondo la sintesi dell'articolo 15 dell'AI Act Service Desk della Commissione europea (basata sul testo consolidato EUR-Lex dell'AI Act al 27 luglio 2026), i sistemi di IA ad alto rischio devono raggiungere un livello adeguato di accuratezza, robustezza e cybersecurity per tutto il loro ciclo di vita, con le metriche di accuratezza pertinenti dichiarate nelle istruzioni per l'uso. Testare l'IA significa quindi occuparsi di qualità dei dati, robustezza, comportamento avversariale, monitoraggio e supervisione umana, non solo di controlli funzionali. (ai-act-service-desk.ec.europa.eu)
| Normativa / framework | Implicazione per i test | Evidenze da conservare |
|---|---|---|
| GDPR, articolo 32 | Testare regolarmente i controlli di sicurezza sui dati personali | Risultati dei test di sicurezza, revisioni degli accessi, test di ripristino |
| NIS2, articolo 21 | Verificare le misure di gestione dei rischi di cybersecurity | Piani di test basati sul rischio, registri di correzione delle vulnerabilità |
| Cyber Resilience Act | Testare la cybersecurity del prodotto lungo tutto il ciclo di vita | Evidenze di sviluppo sicuro, registri di gestione delle vulnerabilità |
| EU AI Act, articolo 15 | Testare accuratezza, robustezza e cybersecurity dell'IA ad alto rischio | Report di valutazione, metriche, log di monitoraggio |
| NIST SSDF | Integrare pratiche di sviluppo sicuro nel ciclo di vita del software | Evidenze di codifica sicura, code review e test delle vulnerabilità |
| OpenSSF SLSA | Rafforzare l'integrità della supply chain del software | Provenance, integrità delle build ed evidenze sulle dipendenze |
Secondo NIST SP 800-218 (SSDF versione 1.1, pubblicata a febbraio 2022), il Secure Software Development Framework fornisce pratiche di alto livello per lo sviluppo sicuro del software, integrabili in qualsiasi implementazione del ciclo di vita del software. Secondo la descrizione del progetto SLSA di OpenSSF (consultata nel 2026), SLSA offre linee guida adottabili in modo incrementale per la sicurezza della supply chain del software e un vocabolario comune per chi produce e chi usa software. (csrc.nist.gov)
Per chi decide, l'approccio consolidato è costruire una matrice conformità-test: collegare ogni obbligo a scenari di test, responsabili, ambienti, conservazione delle evidenze e processo di correzione. Così la conformità smette di essere una corsa annuale e diventa un sistema di controllo ingegneristico.
Se la vostra suite di test è lenta, instabile o non copre i flussi che contano, il servizio di test automatizzati di WWG costruisce suite di unit test, test delle API ed end-to-end basate sul rischio dentro la vostra pipeline CI/CD. Se prima volete sapere dove sono le lacune, un audit del software mette a confronto la copertura dei test con l'architettura e il rischio di delivery.
Contatta il nostro team di ingegneria →
Fonti
- ISO — ISO/IEC/IEEE 29119-1:2022, Software and systems engineering — Software testing — Part 1: General concepts (pubblicata a gennaio 2022). (iso.org)
- ISTQB — Certified Tester Foundation Level Syllabus v4.0.1 (datato 15 settembre 2024). (istqb.org)
- CISQ — The Cost of Poor Software Quality in the US: A 2022 Report (copyright 2022; stime 2022). (it-cisq.org)
- DORA / Google Cloud — 2024 Accelerate State of DevOps Report ed errata 2024 (ultima versione corretta v.2024.3; errata aggiornata l'8 ottobre 2024). (dora.dev)
- JUnit — JUnit 5 User Guide, versione 5.13.1. (docs.junit.org)
- pytest — documentazione stabile, pytest: helps you write better programs. (docs.pytest.org)
- Selenium — documentazione ufficiale, The Selenium Browser Automation Project (ultima modifica 16 settembre 2026). (selenium.dev)
- Microsoft Playwright — documentazione ufficiale. (playwright.dev)
- Apache JMeter — documentazione ufficiale, Apache JMeter™. (jmeter.apache.org)
- OWASP — Web Security Testing Guide, ultima edizione online. (owasp.github.io)
- Postman — documentazione ufficiale, Test your API functionality. (learning.postman.com)
- GitHub Docs — Continuous integration. (docs.github.com)
- EUR-Lex — GDPR, Regolamento (UE) 2016/679, articolo 32. (eur-lex.europa.eu)
- EUR-Lex — Direttiva NIS2, Direttiva (UE) 2022/2555, articoli 21 e 41. (eur-lex.europa.eu)
- Commissione europea — Sintesi del Cyber Resilience Act e obblighi di segnalazione del Regolamento (UE) 2024/2847. (digital-strategy.ec.europa.eu)
- Commissione europea, AI Act Service Desk — EU AI Act, articolo 15: accuratezza, robustezza e cybersecurity. (ai-act-service-desk.ec.europa.eu)
- NIST — SP 800-218, Secure Software Development Framework Version 1.1 (pubblicata a febbraio 2022). (csrc.nist.gov)
- OpenSSF — SLSA, Supply-chain Levels for Software Artifacts. (openssf.org)
FAQ
Domande frequenti
Risposte pratiche per CTO e responsabili tecnici che vogliono una strategia di software testing più solida.
