Classificazione bug software: guida alle priorità per uno SLA efficace | Tiknil [ ![Logo Tiknil](https://www.tiknil.com/images/logo.svg) ![Logo Tiknil](https://www.tiknil.com/images/logo-white.svg) ](https://www.tiknil.com "Homepage") [ Connective app ](https://www.tiknil.com/connective-app) [ Il nostro metodo ](https://www.tiknil.com/creazione-app-mobile-metodo) [ Chi siamo ](https://www.tiknil.com/chi-siamo) [ Case History ](https://www.tiknil.com/case-history) [ Blog ](https://www.tiknil.com/blog) [ Contatti ](https://www.tiknil.com/contatti) [ ](https://www.linkedin.com/company/tiknil) [ ](https://www.facebook.com/tiknil/) [ ![Logo Tiknil](https://www.tiknil.com/images/logo.svg) ](https://www.tiknil.com) [ Connective app ](https://www.tiknil.com/connective-app) [ Il nostro metodo ](https://www.tiknil.com/creazione-app-mobile-metodo) [ Chi siamo ](https://www.tiknil.com/chi-siamo) [ Case History ](https://www.tiknil.com/case-history) [ Blog ](https://www.tiknil.com/blog) [ Contatti ](https://www.tiknil.com/contatti) [ ](https://www.linkedin.com/company/tiknil) [ ](https://www.facebook.com/tiknil/) MENU X Classificazione bug software: come funzionano le priorità (e perché centrano con lo SLA) ========================================================================================== Flavio Suardi | 12 minuti di lettura ![Schema di classificazione bug software con livelli di priorità per la gestione dello SLA](https://ddqgxd8alqge7.cloudfront.net/blog/classificazione-bug-software-2c407.webp) ![Foto di Flavio Suardi](https://www.tiknil.com/images/team/Flavio.jpg) Scritto da **Flavio Suardi** App Engineer quando la reale mansione del **citazionista** gli lascia un po' di spazio; in ufficio si diletta ad inserire nei dialoghi frasi più o meno celebri della cultura pop de noialtri, non ci stupiremmo se prima o poi le trovassimo anche nei commenti del codice delle App. Hai appena lanciato la tua app. Funziona, gli utenti la usano, tutto sembra filare liscio. Poi arriva la prima segnalazione. E poi un'altra. E un'altra ancora. Alcune parlano di un testo leggermente fuori posto, altre di un crash che blocca l'intera applicazione. Come fai a decidere cosa sistemare prima? E, soprattutto, come fai a garantire al cliente che i problemi più gravi verranno presi in carico in tempi certi e prevedibili? La risposta sta in un sistema che il mondo dello sviluppo software usa da decenni: la **classificazione dei bug per priorità**. Blocker, critical, major, minor, trivial: cinque parole che definiscono un metodo, una promessa e — nei fatti — il cuore pulsante di qualsiasi **Service Level Agreement** (SLA) ben costruito. Un framework che, come illustrato anche dalle linee guida [IEEE sulla classificazione dei difetti software](https://ieeexplore.ieee.org/document/511092), serve a stabilire un linguaggio comune tra team di sviluppo e cliente. Perché classificare i bug è indispensabile ------------------------------------------- Quando gestisci un software in produzione — che sia un'app mobile, una web app o una Connective App che dialoga con oggetti fisici — il caos è sempre dietro l'angolo. Senza un criterio oggettivo per stabilire l'urgenza di ogni segnalazione, si finisce per navigare a vista: il cliente che urla di più ottiene attenzione immediata, i problemi piccoli ma visibili rubano tempo a quelli gravi ma silenziosi, e il team di sviluppo perde il controllo delle priorità. La **classificazione bug software** risolve questo problema alla radice. Non è una questione di gusti o di simpatia: ogni segnalazione viene valutata in base a criteri oggettivi — impatto sul business, numero di utenti coinvolti, esistenza di un workaround — e incasellata in una categoria di priorità. A ciascuna categoria corrispondono tempi di risposta e risoluzione predefiniti, scritti nero su bianco nel contratto di manutenzione. Questo approccio ha un effetto collaterale niente male: allinea le aspettative tra chi sviluppa e chi paga. Il cliente sa esattamente entro quanto tempo riceverà un primo riscontro e quando potrà vedere il problema risolto. Il team di sviluppo, dal canto suo, può organizzare il lavoro senza farsi travolgere dall'urgenza percepita ma non reale. La scala di priorità: la classificazione bug software dal blocco totale al dettaglio estetico ---------------------------------------------------------------------------------------------- Vediamo nel concreto cosa significa ciascun livello di priorità, con esempi tratti dall'esperienza quotidiana di chi sviluppa e mantiene app mobile. ### Blocker — il mondo si è fermato Un bug **blocker (bloccante)** blocca completamente una funzionalità core del prodotto. L'app non si avvia, il login è impossibile, la connessione con il dispositivo fisico (nel caso delle Connective App) è interrotta per tutti gli utenti. Non esiste workaround: il software è inutilizzabile. Esempi tipici: l'app crasha all'avvio su tutti i dispositivi Android dopo un aggiornamento; il pagamento in-app non funziona per nessun utente; un bug lato server rende impossibile la sincronizzazione dei dati. In uno SLA, i blocker hanno priorità assoluta: nei nostri SLA indichiamo massimo 48 ore lavorative ma in realtà li prendiamo in carico al più presto. Sono il motivo per cui esiste un team di reperibilità. ### Critical — grave, ma con una via d'uscita Un bug **critical (critico)** compromette una funzionalità importante ma non blocca l'intero sistema, oppure esiste un workaround che permette di andare avanti. L'impatto sul business è comunque serio. Esempi: la funzione di ricerca non restituisce risultati, ma l'utente può navigare manualmente; la connessione Bluetooth con il dispositivo IoT funziona solo dopo tre tentativi; le notifiche push non arrivano a una fetta significativa di utenti. Per i critical, come per i blocker, il nostro SLA prevede tempi di risposta entro le 48h ore lavorative e risoluzione entro massimo 5 giorni, ma in verità diamo il massimo affinché si possa risolvere problemi del genere al più presto. La differenza con i blocker è sottile ma fondamentale: c'è un margine di respiro, anche se piccolo. ### Major — importante, non urgente Un bug **major** (maggiore) riguarda una funzionalità che non funziona come dovrebbe, ma senza impedire l'uso complessivo dell'app. L'esperienza utente ne risente, il flusso è rallentato, ma il prodotto resta utilizzabile. Questo è il livello più comune delle segnalazioni. Esempi: un filtro di ricerca non si applica correttamente; la grafica di una schermata è deformata su un modello specifico di smartphone; un'animazione di caricamento va in loop ma la schermata sottostante è raggiungibile. I major vengono gestiti nei normali cicli di sviluppo: risposta entro 2 giorni lavorativi, risoluzione pianificata entro 5 giorni, come per blocker e critical. ### Minor — fastidioso ma sopportabile Un bug **minor** è un difetto che non pregiudica la funzionalità ma crea un piccolo attrito nell'esperienza. È il classico problema che gli utenti notano ma con cui convivono senza troppi drammi. Esempi: un'etichetta leggermente disallineata, un colore fuori palette in una schermata secondaria, un messaggio di errore poco chiaro ma che non impedisce di proseguire. Per i minor, lo SLA prevede risposta entro 3 giorni lavorativi e risoluzione entro 10. Nessuna corsa contro il tempo, ma nemmeno l'oblio. ### Trivial — il pelo nell'uovo Un bug **trivial** è un'imperfezione estetica o funzionale di impatto trascurabile. Lo nota chi ha un occhio allenato, ma l'utente medio probabilmente non si accorge nemmeno che qualcosa non va. Esempi: una spaziatura leggermente irregolare tra due elementi, un'icona con un dettaglio fuori standard, un testo con una virgola di troppo in una schermata poco frequentata. I trivial vengono raccolti in un backlog e risolti quando c'è finestra — spesso in blocco, durante le attività di manutenzione evolutiva o nei momenti di pausa tra un ciclo e l'altro. Come questa scala si traduce in uno SLA ---------------------------------------- Lo SLA non è un pezzo di carta, è un contratto operativo. Definisce due grandezze fondamentali per ogni livello di priorità: il **tempo di risposta** (quanto passa tra la segnalazione e la presa in carico) e il **tempo di risoluzione** (quanto passa tra la presa in carico e il fix rilasciato in produzione). Come spiega anche [Wikipedia](https://it.wikipedia.org/wiki/Service_level_agreement), un buon SLA non è solo un elenco di penalità ma un accordo che allinea fornitore e cliente sugli stessi obiettivi operativi. Nella nostra esperienza con le Connective App — app che connettono smartphone a oggetti fisici come e-bike, termostati smart e dispositivi medicali — una matrice SLA tipica può essere riassunta così: Blocker, Critical, Major => Tempi di risposta: entro 2gg, risoluzione: entro 5gg Minor, Trivial => Tempi di risposta: entro 3gg, risoluzione entro 10gg (Sempre intesi come giorni lavorativi) Attenzione: questa matrice va sempre calibrata sul progetto specifico. Un'app medicale avrà SLA più stringenti di un'app per il vending. Un'app per un servizio di emergenza avrà tempi di risposta inferiori a quelli di un'app per la gestione interna di un'azienda. Non esiste uno SLA universale, ma esiste un metodo universale per costruirlo: partire dalla **classificazione bug software** e definire, livello per livello, cosa è accettabile per il business del cliente. ![Dashboard di monitoraggio priorità e SLA per la classificazione bug software](https://ddqgxd8alqge7.cloudfront.net/blog/classificazione-bug-software-b1a7f.webp) *Foto di* [*Luke Chesser*](https://unsplash.com/@lukechesser) *su* [*Unsplash*](https://unsplash.com)*\** Cosa succede se manca la classificazione ---------------------------------------- Proviamo a immaginare un scenario senza priorità definite. Un utente segnala un typo in una schermata secondaria. Il project manager, senza un criterio oggettivo, lo mette in cima alla lista perché «è una cosa veloce». Nel frattempo, un bug che impedisce la sincronizzazione dei dati aspetta in coda. Risultato: il typo è risolto, ma gli utenti stanno perdendo dati. Sembra un paradosso, ma succede molto più spesso di quanto si pensi. La classificazione non è una burocrazia fine a sé stessa: è lo strumento che impedisce al rumore di seppellire i segnali davvero critici. Un altro rischio riguarda le aspettative del cliente. Senza uno SLA esplicito, il cliente tenderà a considerare **ogni** segnalazione come urgente. «L'app ha un problema» diventa, nella sua testa, «l'app non funziona». Con una classificazione chiara e condivisa, invece, il cliente impara a distinguere e — cosa ancora più importante — impara a fidarsi, perché sa che quando dice «è un blocker» il team risponde con la massima priorità, e quando dice «è un minor» può permettersi di aspettare. Lato sviluppo: come si stabilisce la priorità giusta ----------------------------------------------------- Determinare la priorità di un bug non è un'operazione meccanica. Richiede di incrociare due dimensioni: la **severità** (quanto è grave il difetto in sé) e la **priorità di business** (quanto è urgente sistemarlo per il cliente). Un bug tecnicamente banale — un testo sbagliato nella home page — può avere priorità major se compare nella schermata più visitata dell'app. Al contrario, un bug tecnicamente complesso in una funzionalità usata da dieci persone potrebbe essere catalogato come minor. Questo è il motivo per cui la classificazione non può essere fatta da un algoritmo: serve una persona che conosca il progetto, il cliente, il contesto di business. In Tiknil, la valutazione della priorità è parte integrante del processo di presa in carico di ogni segnalazione. Strumenti come bug tracker e piattaforme di issue management (Jira, Linear, GitHub Issues ma anche semplicemente con Trello) permettono di registrare la priorità assegnata e di tracciare i tempi di risposta e risoluzione rispetto a quanto promesso nello SLA. La trasparenza è totale, e lo stato di fatto nelle kanban board delle suddette piattaforme mostrano al cliente esattamente come il team sta performando rispetto agli impegni presi. Atlassian, nel suo [manuale sulle priorità dei bug](https://www.atlassian.com/incident-management/kpis/severity-levels), offre un'ottima panoramica su come le aziende tech strutturano questo processo su larga scala. ![Strumenti di prioritizzazione per la classificazione bug software su post-it](https://ddqgxd8alqge7.cloudfront.net/blog/classificazione-bug-software-e4965.webp) *Foto di* [*Daria Nepriakhina*](https://unsplash.com/@epicantus) *su* [*Unsplash*](https://unsplash.com)*\** Classificazione bug e manutenzione: due facce della stessa medaglia ------------------------------------------------------------------- La classificazione delle priorità non vive nel vuoto: è strettamente intrecciata con la strategia di manutenzione dell'app. Come abbiamo raccontato nell'articolo sulla [manutenzione app](/blog/44/manutenzione-app), esistono diverse tipologie di intervento: correttivo, adattivo, evolutivo. La classificazione per bug si applica prevalentemente alla **manutenzione correttiva** — quella che risolve i problemi emersi dopo il lancio. Ma il sistema di priorità aiuta anche a organizzare la manutenzione adattiva ed evolutiva. Quando si pianificano aggiornamenti legati a nuove versioni dei sistemi operativi o all'introduzione di nuove funzionalità, il backlog di bug minor e trivial può essere smaltito a corollario del lavoro principale, senza costi aggiuntivi per il cliente. In un'offerta economica, tutto questo si traduce in una voce di costo chiara e prevedible: il cliente paga un canone periodico (o un pacchetto di ore) che copre la manutenzione, con livelli di servizio differenziati per priorità. Sapere che un blocker verrà risolto in poche ore mentre un trivial verrà gestito con calma permette di dimensionare l'investimento in modo proporzionato al rischio reale, senza sprechi. Non solo bug: priorità e assistenza continuativa ------------------------------------------------- La **classificazione bug software** non riguarda solo i bug in senso stretto. In un contratto di [assistenza app](/blog/45/assistenza-app), la stessa scala di priorità si applica a qualsiasi richiesta: malfunzionamenti, dubbi tecnici, richieste di modifica. Ogni ticket che arriva al team di supporto viene classificato e instradato secondo la matrice SLA. Questo significa che lo SLA diventa il linguaggio comune tra tutti gli attori del progetto: cliente, project manager, sviluppatori, supporto tecnico. È un vocabolario condiviso che elimina ambiguità e permette a tutti di lavorare con aspettative allineate. E, a proposito di aspettative allineate, se stai per affrontare lo sviluppo di una nuova app, ti suggeriamo di leggere anche il nostro articolo su [cosa deve includere un preventivo app](/blog/18/preventivo-app): lo SLA e la classificazione delle priorità fanno parte degli aspetti che devi trovarti in ogni proposta professionale. Un investimento in fiducia --------------------------- Alla fine, la classificazione delle priorità e lo SLA non sono strumenti tecnici — o meglio, non solo. Sono strumenti di relazione. Dichiarare in modo trasparente e vincolante quali sono i tempi di intervento per ogni livello di gravità significa dire al cliente: «Ci prendiamo la responsabilità di ciò che costruiamo, e ti diamo la certezza di un intervento proporzionato al problema». Non è una promessa da poco. Ma è esattamente il tipo di promessa che distingue un partner tecnologico affidabile da un semplice fornitore di codice. Nel mondo delle Connective App, dove un bug può significare un macchinario fermo, un dispositivo medico irraggiungibile o una flotta di veicoli inutilizzabile, questa differenza si misura in euro, in reputazione e — a volte — in sicurezza. Ecco perché la prossima volta che riceverai un'offerta per lo sviluppo o la manutenzione di un'app, ti consigliamo di cercare questa frase: «Service Level Agreement». Se è accompagnata da una **classificazione bug software** chiara e da tempi di intervento definiti, puoi essere certo di avere davanti un'azienda che sa cosa significa prendersi cura del software nel tempo. [ ORA PARLIAMO DELL'APP PER LA TUA AZIENDA](/contatti) **Che differenza c'è tra blocker e critical?** Un blocker rende l'app completamente inutilizzabile per tutti gli utenti e non ha workaround (es. crash all'avvio). Un critical compromette una funzionalità importante ma lascia una via alternativa o colpisce solo una parte degli utenti. La differenza pratica si riflette nei tempi di SLA: i blocker vengono gestiti in 1-4 ore anche fuori orario lavorativo, i critical in 4-24 ore. **La classificazione bug software è uno standard internazionale?** Esiste uno standard de facto, non de iure. L'IEEE definisce una classificazione di severità dei difetti software, ma nella pratica l'industria ha adottato la scala a cinque livelli (blocker, critical, major, minor, trivial) come riferimento comune. Ogni azienda può adattarla alle proprie esigenze, purché i criteri siano dichiarati nello SLA. **Chi decide la priorità di un bug?** La priorità viene assegnata dal team di sviluppo o dal project manager in accordo con il cliente, incrociando severità tecnica e urgenza di business. Non è una decisione unilaterale: un canale di comunicazione chiaro tra cliente e team è essenziale per classificare correttamente ogni segnalazione. **Cosa succede se il team non rispetta i tempi dello SLA?** Un buono SLA prevede meccanismi di compensazione (crediti, penali, estensioni di garanzia) per i casi di mancato rispetto dei tempi concordati. L'obiettivo, comunque, non è punire ma prevenire: un monitoraggio continuo e report periodici permettono di intervenire prima che lo SLA venga violato. **La classificazione si applica anche alle Connective App?** Assolutamente sì, anzi: nelle Connective App, dove l'app dialoga con oggetti fisici (dispositivi IoT, macchinari, veicoli), la classificazione è ancora più critica. Un bug che interrompe la connessione con un macchinario industriale è un blocker di fatto, e lo SLA deve riflettere questa urgenza con tempi di risposta adeguati. LEGGI ALTRI ARTICOLI DEL NOSTRO BLOG --------------------------------------- [ Horeca e diagnostica preventiva: come un'app può salvare la tua cucina Nel settore horeca, un forno che si spegne durante il servizio o un frigorifero che cede nella notte possono tradursi in perdite economiche devastanti. La diagnostica preventiva, resa accessibile tramite app connesse alle attrezzature, sta cambiando le regole del gioco: sensori IoT, algoritmi predittivi e notifiche in tempo reale permettono a ristoratori e albergatori di anticipare i guasti prima che diventino emergenze. ](https://www.tiknil.com/blog/69/horeca-diagnostica-preventiva-app) [ App HVAC: come il controllo remoto della climatizzazione sta trasformando l'industria Le app HVAC stanno rivoluzionando il mondo della climatizzazione industriale. Dal monitoraggio in tempo reale dei chiller alla manutenzione predittiva, le applicazioni mobile per il settore HVAC permettono a installatori e facility manager di gestire gli impianti ovunque si trovino. Scopri come le Connective App di Tiknil rendono intelligenti i sistemi di climatizzazione, migliorando efficienza e comfort. ](https://www.tiknil.com/blog/68/app-hvac) [ Oltre l'effetto wow: scopri i veri trend app 2026 per un'esperienza utente senza attriti Nel 2026 lo sviluppo di applicazioni mobile abbandona l'effetto wow fine a se stesso per concentrarsi sull'utilità reale e l'azzeramento dei tempi morti. Questo articolo esplora i sei trend tecnologici e di design che stanno ridefinendo il settore: dagli agenti AI autonomi all'Edge AI, fino alle UX multimodali e alle interfacce liquide. Scopri come l'ecosistema digitale si sta trasformando per creare connessioni sempre più umane, intelligenti e orientate al valore concreto, superando i vecchi limiti dei classici chatbot e delle interfacce statiche. ](https://www.tiknil.com/blog/67/trend-app-2026) [Scopri altri articoli](https://www.tiknil.com/blog) IL NOSTRO KNOW-HOW ------------------ ![iPhone outline](https://www.tiknil.com/images/home/iphone-blu.png) ![iPhone outline](https://www.tiknil.com/images/home/iphone-blu-portrait.png) CONNECTIVE APP: IL FUTURO NEL TUO SMARTPHONE -------------------------------------------- Mettere a disposizione dei tuoi clienti un'**app che accompagna i tuoi prodotti** permette di renderne più fruibili le informazioni, migliora l'esperienza d'uso e la percezione del digitale dei prodotti stessi, permettendoti di essere presente in **nuovi segmenti di mercato e superare i tuoi competitor** Affidati a noi, siamo specializzati nel realizzare **app per aziende** come la tua! [Scopri come](https://www.tiknil.com/connective-app) METODO O INCANTESIMI? --------------------- Le **app e le connessioni** sembra che funzionino per magia. In realtà dietro c'è un **metodo di lavoro** e un **processo ingegneristico** chiaro e ben definito. [IL NOSTRO METODO](https://www.tiknil.com/creazione-app-mobile-metodo) Iscriviti ad APProfondiamo -------------------------- *la nostra newsletter* Rimani aggiornato sulle novità del mondo delle Connective App e di Tiknil, ti garantiamo: - **Solamente 1 email al mese** 📧, non vogliamo appesantire ulteriormente la tua casella email - Contenuti **creati da noi** con il supporto di un po' di 🤖 Intelligenza Artificiale (q.b.! 😉) - **Valore**, esperienza e un pizzico di magia 🧙 Permettici di aver cura dei tuoi dati ( qui trovi 👉🏻 [l'informativa privacy](https://www.tiknil.com/privacy-policy)) Iscriviti Contattaci ----------- Compila il form sottostante per entrare in contatto con noi! Ciao, mi chiamo di e vorrei fare due chiacchiere con voi riguardo a argomenti vari > una nuova app un preventivo un incontro conoscitivo informazioni aggiuntive La mia mail è Vi lascio qualche informazione in più: Iscriviti ad APProfondiamo, la nostra newsletter (1 mail al mese ✍🏻, contenuti di qualità 💫 scritti da noi 🧑🏻‍💻!) Concedici il permesso ai dati che hai appena inserito, ne avremo cura (👉🏻 qui trovi [l'informativa privacy](https://www.tiknil.com/privacy-policy)) Invia ![Logo Tiknil](https://www.tiknil.com/images/logo-white.svg) **Passate a trovarci, siamo in** [Viale Fratelli Kennedy, 21 - 24066 Pedrengo (BG) | Italia](https://goo.gl/maps/VgXXYgvS5SK2) C.F. e P.IVA: 02422020228 REA: BG 452741 Codice Destinatario SDI: M5UXCR1 **oppure chiamateci** [+39 342 3259883](tel:+393423259883) - [Connective App](https://www.tiknil.com/connective-app) - [Il nostro metodo ](https://www.tiknil.com/creazione-app-mobile-metodo) - [Chi siamo ](https://www.tiknil.com/chi-siamo) - [Case History ](https://www.tiknil.com/case-history) - [Blog ](https://www.tiknil.com/blog) - [Faq ](https://www.tiknil.com/faq) - [Glossario](https://www.tiknil.com/glossary) - [Contatti](https://www.tiknil.com/contatti) - [Codice etico](https://www.tiknil.com/codice-etico) - [Privacy policy](https://www.tiknil.com/privacy-policy) - [Preferenze cookie](#) - [Cookie Policy](https://www.iubenda.com/privacy-policy/7823821/cookie-policy "Cookie Policy ")