Analizzatore di Bug Report
L'Analizzatore di Bug Report prende un bug report grezzo, un log di errore o una segnalazione utente e produce un'analisi strutturata: cause radice probabili ordinate per probabilità, passi di riproduzione chiari, classificazione della gravità e un piano di debug mirato. Trasforma segnalazioni vaghe come "l'app non funziona" in percorsi di indagine concreti.
Sviluppatori, QA engineer e team di supporto usano questo template durante il triage dei bug report in arrivo, soprattutto quando la segnalazione manca di dettagli critici o il bug è difficile da riprodurre. È particolarmente utile durante incidenti in produzione ad alta pressione, dove un pensiero strutturato e rapido conta più che mai.
Il prompt funziona applicando una metodologia di debug sistematica alle informazioni disponibili. Distingue tra ciò che è noto (fatti dal report), ciò che è probabile (inferenze dai sintomi) e ciò che è sconosciuto (lacune che richiedono indagine). Questo approccio strutturato previene la trappola comune di lanciarsi su una correzione prima di aver capito il problema: un errore che spesso fa sprecare ore sull'ipotesi sbagliata.
Questo prompt e' solo il punto di partenza
Analizzalo con l'AI, ottimizzalo con un click, tieni traccia delle versioni e costruisci la tua libreria.
Il Prompt
Analizza il seguente bug report e aiutami a diagnosticare il problema: **Origine del Bug Report**: [Segnalazione utente / alert automatico / ticket QA / log di errore] **Applicazione**: [NOME APP e breve descrizione di cosa fa] **Tech Stack**: [es. Next.js, PostgreSQL, Redis, deploy su AWS] **Descrizione del Bug**: [INCOLLA QUI IL BUG REPORT, IL MESSAGGIO DI ERRORE O LA SEGNALAZIONE DELL'UTENTE. Includi quante più informazioni grezze possibile: messaggi di errore, stack trace, descrizione di screenshot, passi dell'utente, timestamp.] **Cosa So Già**: - Quando ha iniziato a verificarsi? [DATA/ORA o "sconosciuto"] - Quanti utenti sono coinvolti? [TUTTI / ALCUNI / UNO / SCONOSCIUTO] - È cambiato qualcosa di recente? [DEPLOY RECENTI, MODIFICHE DI CONFIGURAZIONE, O "nulla di evidente"] - Si riesce a riprodurre in modo consistente? [SÌ / A VOLTE / NO / NON TESTATO] Fornisci la tua analisi in questo formato: 1. **Sommario**: In 2-3 frasi, riformula il bug in linguaggio tecnico preciso. Traduci le segnalazioni vaghe degli utenti in asserzioni specifiche e verificabili. 2. **Valutazione della Gravità**: Valuta questo bug su due scale: - **Impatto**: Critico (perdita di dati, violazione di sicurezza, disservizio totale) / Alto (funzionalità principale rotta per molti utenti) / Medio (funzionalità degradata, esiste un workaround) / Basso (cosmetico, edge case) - **Urgenza**: Immediata (risolvere ora) / Alta (risolvere oggi) / Normale (risolvere in questo sprint) / Bassa (backlog) - Giustifica la tua valutazione in una frase. 3. **Ipotesi sulle Cause Radice**: Elenca 3-5 possibili cause ordinate per probabilità. Per ciascuna: - Formula l'ipotesi in una frase - Spiega quali evidenze dal bug report la supportano - Descrivi un controllo rapido per confermarla o escluderla 4. **Passi di Riproduzione**: Scrivi un piano di riproduzione passo dopo passo basato sulle informazioni disponibili. Segna con "[VERIFICARE]" i passi che sono supposizioni, così lo sviluppatore sa di doverli confermare. 5. **Lacune Informative**: Elenca domande specifiche le cui risposte restringerebbero significativamente le cause possibili. Per ogni domanda, spiega cosa rivelerebbe (es. "Succede solo su Safari? Se sì, è probabilmente un problema di compatibilità CSS/JS, non un problema backend."). 6. **Piano di Debug**: Fornisci una lista prioritizzata di 3-5 azioni di debug concrete, partendo dalla più veloce da eseguire. Per ogni azione: - Cosa controllare (file specifico, log, endpoint o query al database) - Cosa cercare - Cosa significherebbe il risultato 7. **Mitigazione Immediata** (se la gravità è Alta o Critica): Suggerisci un workaround temporaneo o una mitigazione che possa ridurre l'impatto sugli utenti mentre si indaga sulla causa radice.
Consigli d'uso
- Incolla i messaggi di errore e gli stack trace grezzi: Non parafrasare o riassumere l'output degli errori. Le parole esatte, i codici di errore e i numeri di riga sono spesso il percorso più rapido verso una diagnosi.
- Includi le modifiche recenti: La maggior parte dei bug è causata da qualcosa che è cambiato. Se hai fatto un deploy, aggiornato una dipendenza o modificato una configurazione nelle ultime 48 ore, menzionalo anche se sembra non correlato.
- Usalo per il triage, non solo per la diagnosi: Passa ogni bug report in arrivo attraverso questo template per assegnare rapidamente la gravità, stimare lo sforzo e decidere se correggere subito o mettere in backlog. Questo porta coerenza al processo di triage.
- Riporta i risultati al template: Una volta trovata la causa radice effettiva, rivedi l'analisi per vedere quale ipotesi era corretta. Col tempo, questo costruisce la tua intuizione per i pattern di debug.
Ottieni di piu' da questo prompt
Salvalo, analizzalo con l'AI, ottimizzalo e tieni traccia di ogni versione. Gratis per iniziare.