Hai appena ricevuto il software custom che aspettavi da mesi. Il fornitore dice che funziona. Il tuo team inizia a usarlo. Dopo tre giorni arriva il primo bug serio: un'operazione che sembrava banale cancella dati nel modo sbagliato.
Questo non è uno scenario raro. È quasi la norma quando il testing viene trattato come un dettaglio dell'ultimo minuto, qualcosa che "si gestisce dopo il lancio".
Le PMI che commissionano software custom si trovano in una posizione scomoda: non hanno un team QA interno, non sempre sanno cosa chiedere al fornitore in termini di qualità, e spesso scoprono i problemi solo quando il software è già in produzione. Vediamo come uscire da questa trappola con un approccio che non richiede né un budget enorme né competenze specialistiche.
Prima di parlare di strumenti, serve chiarire una cosa: testare non significa cliccare su tutto e sperare che non si rompa niente.
Un test ha senso quando risponde a una domanda precisa. "Se inserisco un ordine con quantità zero, cosa succede?" è un test. "Ho girato l'applicazione per venti minuti e sembra ok" non lo è.
Esistono tre livelli di testing che una PMI dovrebbe conoscere:
I test unitari verificano singole funzioni del codice. Sono responsabilità del team di sviluppo e non richiedono coinvolgimento diretto del cliente. Se il tuo fornitore non li scrive, è un segnale da non ignorare.
I test di integrazione verificano che i pezzi del sistema funzionino insieme. Tipicamente: il modulo ordini comunica correttamente con il magazzino? I dati del CRM si sincronizzano con la piattaforma e-commerce?
I test end-to-end simulano il comportamento reale di un utente. Aprono il browser, navigano, compilano form, verificano i risultati. Sono i più lenti da eseguire ma anche i più vicini all'esperienza reale.
Per una PMI senza QA interno, il punto di partenza più utile sono i test end-to-end sui flussi critici. Non tutto, solo quello che, se si rompe, blocca il business.
Ogni applicazione ha un nucleo di operazioni che non possono fallire. Per un e-commerce è il checkout. Per un gestionale di produzione è la registrazione degli ordini di lavoro. Per un CRM custom è la qualificazione dei lead.
Mappa questi flussi prima ancora di parlare con il tuo fornitore di testing. Un metodo pratico: chiedi al tuo team operativo "cosa succederebbe se domani mattina questo non funzionasse?" Le risposte che generano panico immediato sono i tuoi flussi critici.
Tipicamente sono tre o quattro. Raramente di più.
Su questi flussi vale la pena investire in test automatici. Sul resto, un collaudo manuale strutturato prima di ogni release è spesso sufficiente.
Cypress è un framework di test end-to-end open source. Simula un utente reale nel browser: clicca, compila, naviga, verifica. Lo script che scrivi oggi verrà rieseguito identico ad ogni deploy, ogni volta che il codice cambia.
Perché Cypress e non altro? La documentazione è tra le migliori del settore. La sintassi è leggibile anche per chi non scrive codice tutti i giorni. E il feedback visivo (puoi vedere il browser che esegue i test in tempo reale) abbassa enormemente la curva di apprendimento.
Un test Cypress per verificare il flusso di login di un'applicazione custom somiglia a questo:
describe('Login aziendale', () => {
it('permette l\'accesso con credenziali valide', () => {
cy.visit('/login')
cy.get('[data-cy="email"]').type('utente@azienda.it')
cy.get('[data-cy="password"]').type('passwordTest123')
cy.get('[data-cy="submit"]').click()
cy.url().should('include', '/dashboard')
cy.contains('Benvenuto').should('be.visible')
})
})Non serve un team QA per leggere questo codice e capire cosa fa. Serve però che il tuo fornitore aggiunga gli attributi data-cy agli elementi dell'interfaccia: è una convenzione che rende i test stabili anche quando il CSS cambia. Chiedila esplicitamente nel capitolato.
Opinione netta: chi propone ancora Selenium come primo approccio per un'applicazione moderna sta risolvendo un problema del 2015. Cypress è più veloce da configurare, più stabile in esecuzione e più facile da mantenere. La scelta è semplice.
Avere i test è metà del lavoro. L'altra metà è sapere cosa fare quando qualcosa va storto.
Senza un sistema di bug tracking condiviso, i problemi vengono segnalati via WhatsApp, persi in thread di email, o peggio, risolti senza che nessuno sappia cosa è stato cambiato. Questo genera regressioni: bug già risolti che tornano perché la correzione non era documentata.
Non serve uno strumento sofisticato. GitHub Issues, Linear o anche una board Notion con un template standard funzionano benissimo per una PMI. Il template minimo per segnalare un bug:
Questa struttura, applicata in modo consistente, dimezza il tempo che il tuo fornitore impiega a capire e risolvere il problema.
Se non hai test automatici su tutto (ed è normale non averli), il collaudo manuale strutturato è la rete di sicurezza.
Un collaudo efficace non è "gira l'applicazione e vedi se funziona". È una checklist specifica, aggiornata ad ogni release, che copre:
Questa checklist va costruita insieme al tuo fornitore e aggiornata dopo ogni bug trovato in produzione. Ogni bug che sfugge al collaudo diventa un nuovo punto di controllo per la volta successiva.
Il collaudo manuale non scala all'infinito. Ogni nuova funzionalità aggiunge superficie da testare, e fare tutto a mano prima di ogni deploy diventa rapidamente insostenibile. Questo è il momento in cui investire in automazione smette di essere opzionale.
Se stai per commissionare un software custom, queste domande ti aiutano a capire come il fornitore tratta il testing:
Le risposte vaghe o evasive dicono molto. Un fornitore che non ha una risposta chiara sulla copertura dei test probabilmente non ha un processo strutturato di quality assurance.
Se stai valutando come impostare questo processo per un software già in produzione, raccontaci il tuo caso: possiamo aiutarti a capire da dove partire.
I test automatici verificano che il software faccia quello che gli hai detto di fare. Non verificano che quello che gli hai detto di fare sia la cosa giusta.
Questo è il confine tra quality assurance tecnica e validazione del prodotto. Un test Cypress può confermare che il form di inserimento ordine salva correttamente i dati. Non può dirti se quel form è usabile, se il flusso ha senso per i tuoi operatori, se i campi richiesti sono quelli giusti.
Per questo serve il feedback degli utenti reali, raccolto sistematicamente. Sessioni di test con gli utenti finali prima del rilascio, survey post-lancio, analisi delle segnalazioni dei primi mesi: sono strumenti diversi dai test automatici, ma complementari.
Una PMI che ha entrambi, anche in forma minimale, è in una posizione molto più solida di una che ha solo uno dei due.
Q: Quanto tempo richiede impostare un sistema di test automatici per un software custom?
A: Per un'applicazione aziendale di medie dimensioni, configurare un set minimo di test end-to-end con Cypress richiede qualche giorno di lavoro iniziale. L'investimento si recupera già alle prime release successive, quando i bug regressivi smettono di presentarsi in produzione.
Q: Cypress è adatto anche a PMI senza sviluppatori dedicati al QA?
A: Sì. La sintassi è leggibile, la documentazione è solida e i test possono essere eseguiti in autonomia anche da chi non è uno sviluppatore senior. Il vero ostacolo è trovare il tempo per scriverli, non la difficoltà tecnica.
Q: Qual è la differenza pratica tra test manuali e test automatici?
A: I test manuali richiedono che qualcuno esegua le funzioni dell'applicazione e verifichi il comportamento a mano. I test automatici fanno la stessa cosa via script, ogni volta che il codice cambia. Per software che evolve spesso, i test automatici diventano l'unico modo per non perdere il controllo sulla qualità.
Q: Come si gestisce il bug tracking senza un team QA dedicato?
A: Serve uno strumento condiviso tra chi sviluppa e chi usa il software: Linear, GitHub Issues o Notion vanno bene. La chiave è un formato standard per segnalare i bug (cosa è successo, cosa ci si aspettava, come riprodurlo) e una persona che decide le priorità.
Q: Il collaudo finale prima del rilascio è sufficiente senza test automatici?
A: Per una prima release, spesso sì. Per un software aggiornato ogni settimana, no. Il collaudo manuale non scala: ogni nuova funzionalità aggiunge superficie da testare, e farlo tutto a mano prima di ogni deploy diventa rapidamente insostenibile.
Se gestisci un software custom che viene aggiornato spesso e ti accorgi che ogni release porta con sé qualche sorpresa indesiderata, in Press Start possiamo aiutarti a impostare un processo di testing adatto alle tue risorse. Scrivici e vediamo insieme da dove conviene partire.
