Test automation 2021: Selenium, Cypress, Playwright per PMI

Quanto tempo impiega oggi il tuo team a validare manualmente una release? Tre ore? Una giornata intera? Per molte PMI software italiane il QA manuale resta ancora la norma — fino al momento in cui il backlog di feature cresce, il numero di sviluppatori supera i 5-6 e il tempo di regression testing si moltiplica con ogni nuovo modulo. A quel punto il test automation non è più una scelta tecnologica ma una questione di sopravvivenza sul mercato.

Il 2021 è stato un anno spartiacque per l’ecosistema del testing. Il 13 ottobre 2021 è uscito Selenium 4.0, primo rilascio major dopo cinque anni di sviluppo, allineato finalmente allo standard W3C WebDriver. Cypress, lanciato nel 2017, ha raggiunto la versione 9.0 a luglio 2021 con supporto stabile a Firefox e session API. Ma il vero scossone arriva da Redmond: Playwright, rilasciato da Microsoft nel 2020 e cresciuto rapidamente, ha pubblicato la 1.16 a novembre 2021 con auto-wait nativo, multi-browser cross-platform e supporto a JavaScript, TypeScript, Python, Java e .NET.

In questa guida operativa analizziamo i framework dominanti, i loro casi d’uso ideali, gli strumenti complementari (visual regression, API testing, performance) e come strutturare un piano di adozione in 60 giorni per una PMI italiana. Vediamo prima i fondamentali concettuali, poi entriamo nei tool e infine in un caso concreto di migrazione.

Test pyramid di Mike Cohn: la base teorica

Prima di scegliere un framework occorre capire quale livello di test stiamo automatizzando. Il modello di riferimento resta la Test Pyramid introdotta da Mike Cohn nel suo libro “Succeeding with Agile” del 2009 e poi resa popolare da Martin Fowler. La piramide divide i test in tre strati:

• Unit test (base, ~70%): testano singole funzioni o classi in isolamento. Veloci (millisecondi), economici da scrivere e mantenere. Tool: Jest, Mocha + Chai per JavaScript, PyTest per Python, JUnit + Mockito per Java, PHPUnit per PHP.
• Integration test (~20%): verificano l’interazione tra moduli, chiamate API, query database. Più lenti (centinaia di ms), ma coprono comportamenti che gli unit test non vedono.
• End-to-End (E2E, ~10%): simulano l’utente reale che usa l’applicazione tramite browser. Lenti (secondi-minuti), costosi da mantenere, ma sono gli unici a validare il flusso completo.

Il problema più comune che vediamo nelle PMI italiane è la “piramide invertita”: pochi unit test, molti test E2E. Risultato: suite che impiegano un’ora a girare, flakiness alta, ogni piccolo refactoring rompe decine di scenari. La regola pratica: se hai 100 test totali, almeno 70 devono essere unit, 20 integration, 10 E2E. Selenium, Cypress e Playwright lavorano principalmente sull’apice della piramide, ma la qualità della tua suite dipende soprattutto da quanto è solida la base.

Cos’è il test automation E2E e perché serve davvero

Un test E2E (End-to-End) è uno script che simula un utente reale: apre il browser, clicca link, compila form, attende risposte AJAX, verifica che i dati salvati appaiano correttamente nella UI. È l’unico tipo di test che convalida il sistema “as a whole”: frontend + backend + database + servizi esterni.

Per una PMI software i benefici concreti sono tre. Primo: riduzione del regression testing da giorni a minuti. Secondo: confidenza nel deploy continuo (CI/CD) — senza E2E automatizzati il “deploy del venerdì” resta un terno al lotto. Terzo: documentazione vivente. Uno script Cypress ben scritto descrive il comportamento atteso meglio di qualsiasi pagina Confluence.

Lo svantaggio principale dei test E2E è la fragilità: dipendono dal DOM, dalla rete, dai tempi di rendering. Un test che funziona in locale può fallire sporadicamente in CI (“flaky test”) creando rumore e perdita di fiducia. La scelta del framework giusto incide direttamente su questo aspetto.

Selenium WebDriver: il veterano (e Selenium 4)

Nato nel 2004 da un progetto interno di ThoughtWorks come “JavaScriptTestRunner”, Selenium è il framework di test automation più longevo e diffuso al mondo. La versione WebDriver, sviluppata da Simon Stewart a partire dal 2007, è oggi il de-facto standard per pilotare browser via codice.

Il 13 ottobre 2021 è uscito Selenium 4.0, primo major release dopo 5 anni di lavoro. Le novità chiave:

• W3C WebDriver Recommendation: protocollo standardizzato dal W3C nel 2018 e ora pienamente adottato. Niente più JSON Wire Protocol legacy.
• Selenium Grid 4: architettura rifatta con Docker support nativo, observability (tracing OpenTelemetry), e UI più moderna.
• Relative Locators: API tipo above(), below(), near() per selezionare elementi in base alla posizione visuale.
• Chrome DevTools Protocol (CDP): accesso a network throttling, geolocation, console log.

I punti di forza di Selenium WebDriver restano la maturità (community immensa, decine di migliaia di articoli, libri, corsi), il multi-language (Java, Python, C#, Ruby, JavaScript, Kotlin), e l’integrazione con tutti i browser farm cloud (BrowserStack, Sauce Labs, LambdaTest). Selenium è la scelta giusta quando hai sviluppatori back-end Java/.NET, devi testare browser legacy (IE 11 ancora richiesto da clienti enterprise) o hai vincoli di compliance.

Lato negativo: architettura WebDriver “out-of-process” (comandi inviati via HTTP REST al driver) introduce latenza, no auto-wait nativo (servono WebDriverWait + ExpectedConditions espliciti), e debugging meno comodo rispetto ai framework moderni.

Cypress: la dev experience friendly

Lanciato nel 2017 dalla startup californiana Cypress.io, Cypress ha cambiato le regole del gioco con un’architettura radicalmente diversa: invece di pilotare il browser dall’esterno via protocollo HTTP, Cypress gira dentro il browser con il test e l’applicazione nello stesso event loop. Questo elimina molti problemi di sincronizzazione tipici di Selenium.

Caratteristiche distintive:

• Time Travel Debugger: ogni comando crea uno snapshot del DOM. Puoi tornare indietro nel tempo e ispezionare lo stato esatto del test in qualsiasi step.
• Auto-wait nativo: Cypress attende automaticamente che gli elementi siano visibili, abilitati, attached al DOM prima di interagire.
• Network stubbing nativo: intercetti chiamate XHR/fetch con cy.intercept() senza tool esterni.
• Dashboard cloud (a pagamento da ~75$/mese): video recording, parallel execution, analytics.

La versione Cypress 9.0 di luglio 2021 ha portato supporto stabile a Firefox (precedentemente beta) e session API (cy.session()) per cache di login tra test. La community è in forte crescita: secondo lo State of JS 2021, Cypress è il framework di testing E2E più utilizzato dagli sviluppatori JavaScript con il 38% di adoption, superando Selenium tra chi lavora su frontend SPA.

Limiti: solo JavaScript/TypeScript (niente Python, Java), supporto multi-tab limitato, niente Safari (al 2021), no controllo browser nativo come click su dialog del sistema operativo, esecuzione sequenziale su singolo browser per default.

Playwright: la sfida di Microsoft

Annunciato a gennaio 2020 da Microsoft (autori in gran parte ex-team Puppeteer di Google migrati a Redmond), Playwright ha avuto un’evoluzione fulminea. La versione 1.16 rilasciata a novembre 2021 lo posiziona come alternativa moderna a Selenium con un’esperienza developer simile a Cypress ma senza i suoi limiti.

Punti di forza chiave:

• Multi-browser: Chromium, Firefox e WebKit (motore Safari) tutti gestiti con un’unica API. Cross-browser reale, anche su Linux/CI.
• Multi-language: bindings ufficiali per JavaScript/TypeScript, Python, Java, .NET. Non solo Node.js come Cypress.
• Auto-wait built-in: ogni azione (click, fill, selectOption) attende automaticamente che l’elemento sia “actionable”.
• Parallel execution nativa: la 1.10 (marzo 2021) ha introdotto il test runner ufficiale con parallel workers out-of-the-box.
• Trace Viewer: GUI che mostra timeline, network, console, screenshot per ogni step. Game-changer per debug.
• Multi-context: gestisce più tab, popup, iframe e contesti di sessione paralleli (utile per testare chat, multi-user).

Lo svantaggio è una community ancora più piccola di Selenium e meno integrazione con tool legacy. Ma per nuovi progetti, soprattutto su stack moderno (React, Vue, Angular, Next.js), Playwright è oggi la scelta tecnicamente più solida.

Selenium vs Cypress vs Playwright: tabella comparativa

TestCafe: l’alternativa open source di DevExpress

Tra le alternative meno note ma valide segnaliamo TestCafe, sviluppato da DevExpress e reso open source nel 2016. È un framework Node.js che non richiede driver esterni: inietta uno script nelle pagine, intercetta richieste via proxy e supporta tutti i browser moderni inclusi i dispositivi mobile remoti.

Punti di forza: zero configuration (installi via npm e parti), supporto a TypeScript nativo, ottimo per team JavaScript che non vogliono la lock-in del dashboard Cypress. Per il 2021 resta una nicchia ma è una scelta solida per progetti che cercano un’alternativa a costo zero al cloud di Cypress.

Mobile testing: Appium e Detox

Per applicazioni mobile native o ibride (React Native, Flutter, Cordova) i framework E2E browser-based non bastano. I due tool dominanti nel 2021 sono:

• Appium: framework open source nato nel 2012, basato su WebDriver protocol. Nel 2021 la versione mainstream è 1.x; la 2.0 alpha è in sviluppo. Funziona con iOS, Android, anche app desktop (Windows, Mac). Linguaggi: tutti quelli supportati da Selenium. Lo svantaggio è la curva di apprendimento e i tempi di esecuzione.
• Detox: sviluppato da Wix, specifico per React Native. Architettura “grey-box”: il framework ha visibilità interna sull’app e può sincronizzarsi con il render loop. Risultato: test molto più veloci e affidabili di Appium per progetti React Native, ma vincolato a quello stack.

Visual regression testing: Percy, Chromatic, Applitools, BackstopJS

I test E2E classici verificano che il bottone esista e sia cliccabile, ma non che sia bello. Un cambio di CSS può rompere il layout senza far fallire alcun test. Per questo serve il visual regression testing:

• Percy: piattaforma SaaS lanciata nel 2015, acquisita da BrowserStack nel 2020. Integrazione nativa con Cypress, Playwright, Selenium. Pricing parte da ~149$/mese per team.
• Chromatic: dal team di Storybook. Ideale se hai una component library: ogni story diventa un test visivo. Pricing da 149$/mese.
• Applitools: pioniere del visual testing con AI-based comparison (riduce falsi positivi su antialiasing). Enterprise-oriented, pricing su quote.
• BackstopJS: open source, gratis, basato su Puppeteer. Più “fai-da-te” ma valido per PMI con budget zero.

API testing: Postman, REST Assured, Karate DSL, SuperTest

Prima di testare la UI conviene testare le API. Strumenti di riferimento 2021:

• Postman: il più diffuso, con tab Collections e Newman per esecuzione CI. Versione free generosa, team plan da 12$/utente/mese.
• REST Assured: libreria Java fluida (“given/when/then”). Standard de facto per progetti enterprise Java/Spring.
• Karate DSL: framework BDD-style, scrivi test in Gherkin-like syntax senza Java. Ottimo per team misti dev + QA non programmatori.
• SuperTest: libreria Node.js per testare API Express/Koa/Fastify. Si integra con Jest e Mocha.

Performance e load testing: k6, JMeter, Artillery, Gatling

Quando l’app è in produzione il numero di utenti concorrenti determina se l’architettura regge. Tool 2021:

• k6: open source, scritto in Go, script in JavaScript. Acquisito da Grafana Labs a ottobre 2021. DX moderna, integrazione nativa con Grafana per dashboard.
• JMeter: il veterano (Apache, 1998). GUI Swing, supporta load test complessi. Standard per chi viene da background enterprise Java.
• Artillery: Node.js, script YAML semplici. Ottimo per test rapidi su API REST/WebSocket.
• Gatling: Scala-based, report HTML dettagliati. Forte adoption in ambito JVM.

CI/CD: integrare l’automation nella pipeline

Un test che non gira in CI non esiste. Le piattaforme di riferimento nel 2021:

• GitHub Actions: lanciato GA novembre 2019, marketplace con migliaia di action. Free tier generoso per progetti pubblici.
• GitLab CI: incluso nativamente in GitLab, runners self-hosted o shared. Ottima per chi già usa GitLab.
• Jenkins: il veterano OSS, pipeline-as-code con Jenkinsfile. Ancora molto presente in enterprise.
• CircleCI: SaaS storico, caching avanzato, parallelizzazione automatica.

Per il cross-browser testing in cloud i tre dominanti sono BrowserStack (Automate da 29$/mese), Sauce Labs (open API, plan enterprise), LambdaTest (alternativa più economica, da 15$/mese). Tutti supportano Selenium e Playwright; Cypress richiede plugin specifici.

Code coverage: Istanbul, JaCoCo, Coverage.py

La metrica per misurare quanta parte del codice è coperta dai test. Standard 2021:

• Istanbul (nyc): standard JS/TS, integrato in Jest, supporta line/branch/function coverage.
• JaCoCo: standard Java, plugin Maven/Gradle, report HTML/XML per SonarQube.
• Coverage.py: standard Python, integrato con PyTest via pytest-cov.

Obiettivo realistico per PMI: 70-80% coverage su modulo business core, 50-60% complessivo. Coverage al 100% è generalmente uno spreco di risorse.

Errori comuni nelle PMI italiane

• Piramide invertita: troppi E2E, pochi unit. Risultato: suite lente e flaky.
• Flaky test tollerati: “ogni tanto fallisce, ma se rilancio passa”. Sintomo di problemi reali (race condition, dipendenze esterne, dati condivisi).
• No maintenance time: scrivere test è il 30% del lavoro, manutenerli il 70%. Senza tempo dedicato la suite si degrada in 6 mesi.
• Test accoppiati ai selettori CSS: ogni refactor di markup rompe tutto. Soluzione: data-attributes dedicati (data-testid).
• No isolamento dei test: test A modifica DB, test B legge dati alterati. Soluzione: fixture per scenario, transaction rollback, cleanup hooks.
• Tutto E2E: anche logiche pure (calcolo IVA, formattazione data) testate via browser. Lentissimo. Vanno coperte da unit test.

Caso reale: PMI SaaS B2B migra da Selenium a Playwright

Software house italiana, 12 sviluppatori, prodotto SaaS B2B per gestione documentale (40k utenti). Stato pre-migrazione (gennaio 2021):

• Suite Selenium WebDriver Java + JUnit, 320 test E2E.
• Execution time CI: 18 minuti in sequenziale.
• Flakiness: 14% (circa 45 test su 320 falliscono sporadicamente).
• Tempo medio settimanale per analizzare e re-run flaky test: 9 ore-uomo.
• Sviluppatori demotivati: “i test E2E sono peggio del bug che dovrebbero scovare”.

Decisione: migrazione progressiva a Playwright TypeScript in 4 mesi. Step:

1. Mese 1: POC Playwright su 20 test critici. Confronto execution time e stabilità.
2. Mese 2: ri-architettura Page Object Model, introduzione data-testid in tutti i componenti React.
3. Mese 3: porting graduale dei restanti 300 test, doppia run (Selenium + Playwright) per validazione.
4. Mese 4: dismissione Selenium, parallelizzazione su 4 worker GitHub Actions.

Risultati post-migrazione (maggio 2021):

• Execution time CI: 4 minuti (riduzione del 78%).
• Flakiness: 2.5% (riduzione dell’82%).
• Tempo settimanale su flaky: 1.5 ore-uomo (risparmio 7.5 ore/settimana).
• Deploy in produzione passati da 2 volte/settimana a 1.7 volte/giorno.
• Bug critici sfuggiti in produzione: -64% nei 3 mesi successivi.

Il ROI della migrazione si è realizzato in 11 settimane contando il risparmio di tempo ingegneri. Il caso conferma che la scelta del framework giusto non è un tecnicismo ma un fattore di velocità competitiva.

Roadmap di adozione test automation in 60 giorni

Piano operativo per una PMI software che parte da zero o ha pochi test sporadici. Cinque step concreti per arrivare a una suite funzionante in due mesi.

FAQ — Domande frequenti su test automation