Testing nelle Startup: Quanto Testing Basta per Andare Veloci senza Rompere Tutto
Ho visto due tipi di startup che falliscono nel testing. Ed entrambi falliscono per lo stesso motivo: il dogma.
La prima è la startup che non testa nulla. "Siamo una startup, ci serve velocità. I test ci rallentano. Li scriveremo quando avremo il product-market fit." Fanno deploy di ogni commit direttamente in produzione, il venerdì pomeriggio, e il lunedì si ritrovano con tre clienti enterprise con ticket critici che nessuno riesce a riprodurre.
La seconda è la startup che testa tutto. Copertura al 95%. Ogni componente UI ha test snapshot. Ogni endpoint ha test per edge case che riguardano lo 0,01% degli utenti. Il team impiega il doppio del tempo a consegnare ogni feature perché ogni modifica rompe 40 test che nessuno capisce. E quando arriva un'opportunità di mercato, non riescono a pivotare perché spostare una funzione significa riscrivere 200 test.
Nessuno dei due estremi funziona. La risposta sta nel mezzo, ed è più semplice di quanto sembri.
La domanda giusta non è "quanto", ma "cosa"
Smetti di pensare in percentuale di copertura. La copertura del codice è una vanity metric quando viene usata come obiettivo. Puoi avere il 90% di copertura e nessuno dei tuoi test copre la logica dei pagamenti che conta davvero.
La domanda giusta è: quali parti del mio sistema mi permettono di dormire tranquillo se non hanno test, e quali no?
Se il tuo sistema di elaborazione pagamenti fallisce e addebiti due volte un cliente, hai un problema esistenziale. Se un bottone ha 2px di margine extra su Safari, non muore nessuno.
Il testing pragmatico inizia identificando cosa può causare danni reali e concentrando lì le risorse limitate del tuo team.
La piramide del testing per le startup
La piramide classica del testing (molti unit test, meno integration, pochi E2E) resta valida, ma per le startup la proporzione cambia:
Unit test: la base, ma solo per la logica di business. Non testare ogni funzione helper, ogni utility di formattazione date, ogni mapper banale. Testa la logica che calcola i prezzi, che determina i permessi, che elabora dati di business. Se una funzione contiene un if che incide sul denaro o sui dati dell'utente, merita un test.
Integration test: il tuo miglior alleato. Per le startup, gli integration test sono quelli che offrono più valore per ora investita. Un test che verifica che la tua API di creazione ordini funziona end-to-end — validazione, elaborazione, persistenza, risposta — ti copre più terreno di 20 unit test individuali di ogni singolo passaggio.
E2E test: pochi, ma critici. Un test E2E che verifica l'happy path completo del tuo flusso principale utente (registrazione, azione core, pagamento) è sufficiente per iniziare. Non servono 50 test E2E che coprono ogni variante. Ne servono 3-5 che coprano i flussi che generano revenue.
La proporzione per una startup in fase iniziale dovrebbe essere circa così:
- 60% integration test per i flussi di business critici
- 30% unit test per la logica di business complessa
- 10% E2E test per gli happy path principali
Cosa devi SEMPRE testare
Ci sono componenti che non ammettono discussione. Se non li testi, stai giocando alla roulette:
Pagamenti e billing. Tutto. Creazione di addebiti, rinnovi, cancellazioni, rimborsi, upgrade, downgrade. Ogni edge case. Se addebiti troppo a un cliente, perdi la sua fiducia per sempre. Se addebiti meno, perdi soldi. Testa i calcoli dei prezzi con dati reali. Testa l'integrazione con il tuo processore di pagamenti in modalità sandbox.
Autenticazione e autorizzazione. Login, logout, refresh dei token, scadenza delle sessioni, controllo di accesso basato su ruoli. Se un utente può accedere ai dati di un altro utente per un bug di autorizzazione, hai un incidente di sicurezza che può affondare la tua azienda. Testa che un utente con ruolo X non possa compiere azioni del ruolo Y.
Mutazioni di dati critiche. Qualsiasi operazione che modifica dati non facilmente recuperabili. Creazione di account, eliminazione di risorse, cambi di stato irreversibili. Testa che i dati si trovino nello stato corretto dopo ogni operazione, inclusi gli edge case di concorrenza se applicabili.
Logica di business core. L'algoritmo che rende il tuo prodotto il tuo prodotto. Se è un sistema di matching, testa il matching. Se è un motore di raccomandazione, testa le raccomandazioni. Se è una pipeline di elaborazione, testa ogni trasformazione. Questa è la parte per cui i tuoi utenti pagano.
Cosa puoi saltare (per ora)
Non tutto merita un test in una startup pre-scala. Questi sono candidati ragionevoli da rimandare:
Test di UI pixel-perfect. I test snapshot per i componenti UI generano rumore costante. Ogni modifica di design rompe 30 snapshot e il team finisce per fare --update automaticamente senza controllare. Il valore reale è prossimo allo zero.
Edge case estremi. Se hai 200 utenti, non hai bisogno di testare cosa succede quando 10.000 utenti concorrenti eseguono la stessa operazione. Quel test ha valore, ma non oggi. Ne avrai bisogno prima di scalare, non prima di avere il product-market fit.
Test di integrazione con servizi esterni per flussi non critici. Se usi un'API di geolocalizzazione per mostrare l'ora locale, non serve un test E2E che verifichi quell'integrazione. Un mock è sufficiente.
Codice che cambierà radicalmente. Se stai prototipando un flusso che sai che riscriverai tra 2 mesi, investire in test esaustivi è bruciare denaro. Uno smoke test basico basta per quel codice temporaneo.
Quando aggiungere più test
Il livello di testing non è fisso. Dovrebbe crescere con il tuo prodotto e il tuo team:
Prima del tuo primo cliente enterprise. I clienti enterprise chiedono di testing, QA e pratiche di sviluppo. Inoltre, i loro dati sono più sensibili e le loro aspettative di uptime sono più alte. Questo è il momento di alzare l'asticella.
Quando inizi ad avere bug ricorrenti in produzione. Se lo stesso tipo di bug compare due volte, è un segnale chiaro che quell'area ha bisogno di test. La regola è semplice: ogni bug in produzione diventa un test prima del fix. Così non si ripresenta mai più.
Prima di ogni milestone di scala. Prima di passare da 100 a 1.000 utenti, rivedi quali flussi sono esposti. Prima di passare da 1.000 a 10.000, lo stesso. Ogni ordine di grandezza rivela debolezze che a scala minore restavano nascoste.
Quando il team cresce. Con 2 persone, tutti conoscono tutto il codice. Con 8, nessuno conosce tutto. I test diventano documentazione viva che permette ai nuovi membri di capire cosa fa il sistema e di modificarlo con fiducia.
Strumenti: mantienilo semplice
Non servono 10 strumenti di testing. Ne servono pochi, ben configurati:
- Jest per unit e integration test in JavaScript/TypeScript. È lo standard de facto e funziona bene per il 90% dei casi.
- Playwright per E2E test. È più stabile e più veloce di Selenium, con una developer experience migliore. Se usi già Cypress, non migrare solo per migrare — entrambi funzionano.
- Testing Library per test sui componenti. Testa il comportamento, non l'implementazione.
- GitHub Actions o GitLab CI per eseguire i test su ogni PR. Se i test non girano automaticamente, non esistono.
La chiave è che i test girino nella tua pipeline CI/CD su ogni pull request. Un test che gira solo in locale è un test che non esiste, perché nessuno lo eseguirà in modo costante.
Configura la tua CI per bloccare i merge se i test falliscono. Senza eccezioni. Il giorno in cui qualcuno dice "è urgente, mergio senza test" è il giorno in cui la cultura del testing muore.
Il vero costo di non testare
Non testare non è gratis. È debito che paghi con gli interessi:
I bug in produzione costano di più. Un bug individuato da un test costa 15 minuti di fix. Lo stesso bug individuato da un cliente costa ore di investigazione, un hotfix sotto pressione, comunicazione con il cliente coinvolto e danno reputazionale che non si misura in ore.
La paura di fare deploy. Senza test, ogni deploy è un atto di fede. Il team inizia a fare deploy meno frequentemente. Le modifiche si accumulano. I deploy diventano più grandi e più rischiosi. È un circolo vizioso.
Refactoring impossibile. Senza test, nessuno osa toccare codice esistente. Il codice si degrada progressivamente perché l'alternativa (refactoring e preghiera) è troppo rischiosa. Ti ritrovi con un codebase che nessuno vuole mantenere.
Il testing è criterio ingegneristico
E qui sta la verità scomoda: sapere cosa testare è più difficile che sapere come testare. Qualsiasi sviluppatore può imparare Jest in un pomeriggio. Ma decidere cosa merita un test, che livello di testing necessita ogni componente e quando è il momento di investire di più in qualità — questo richiede esperienza.
Un ingegnere junior testa tutto o non testa nulla. Un ingegnere senior testa esattamente ciò che conta, e sa difendere quella decisione davanti al team e al business.
In Conectia, quando valutiamo gli ingegneri, valutiamo esattamente questo: il criterio. Non cerchiamo persone che sappiano scrivere test — cerchiamo persone che sappiano decidere quali test scrivere e perché. È uno dei segnali più chiari di seniority reale rispetto ad anni di esperienza su un CV.
Gli ingegneri senior dal LATAM che mettiamo in contatto con startup europee portano quel criterio. Hanno lavorato su prodotti in produzione con utenti reali, hanno vissuto le conseguenze di non testare ciò che conta e hanno imparato dove sta l'equilibrio tra velocità e fiducia.
Non ti serve un team QA di 5 persone. Ti servono 2-3 ingegneri senior che sappiano esattamente dove mettere ogni test.
Il tuo team ha bisogno di ingegneri senior che sappiano bilanciare velocità e qualità dal primo giorno? Parla con un CTO — ti presentiamo ingegneri pre-validati che portano criterio, non solo codice.
