Segnalare un bug a voce: dalla chiamata con il QA al ticket in Cursor

2026-10-08

Una segnalazione di bug perde i dettagli tra la chiamata e il ticket. La tester elenca cinque passi, si annuisce, e un'ora dopo nel ticket c'è scritto «l'export non funziona in staging». Con Speak-Y per Mac il percorso è più corto: si registra la chiamata con il QA come riunione, si preme una scorciatoia dopo ogni passo di riproduzione e si chiede a Cursor, collegato a Speak-Y via MCP, di scrivere la bozza della segnalazione dalla trascrizione e dai segni, nella stessa sessione in cui legge il codice. Quando la chiamata non c'è, la segnalazione si detta direttamente nel tracker: si clicca nella descrizione, si tiene premuto Right ⌘, si parla, si rilascia.

Speak-Y non apre il ticket e non registra lo schermo; fornisce le parole, ciascuna con il suo orario accanto. Questa guida segue un solo esempio, una chiamata di venti minuti con Dana, del QA, su un export CSV che ignora il filtro per data, e usa le etichette dell'app per Mac all'8 ottobre 2026.

Che cosa serve a una segnalazione di bug che la chiamata contiene già?

Quasi tutti i modelli dei tracker chiedono le stesse quattro cose: passi per riprodurre, risultato atteso, risultato effettivo e ambiente. In chiamata chi fa il test le dice tutte e quattro ad alta voce, in ordine e con i valori esatti. Nel ticket arriva di solito un riassunto scritto a memoria, e la memoria conserva la conclusione e lascia cadere i passi.

Una trascrizione conserva i passi. I segni li rendono rintracciabili: un segno chiamato Passo di riproduzione su ciascun passo di Dana è già l'elenco numerato della segnalazione, e un segno chiamato Effettivo è la frase in cui ha letto dallo schermo il numero sbagliato.

Prima della chiamata: tre tipi di nota, una scorciatoia ciascuno

Speak-Y arriva con un solo tipo di nota, Segna il momento, su ⌥1. I tre che servono a una segnalazione di bug si aggiungono in Impostazioni → Note:

1. Si clicca Aggiungi tipo di nota, si digita «Passo di riproduzione» in Nome del tipo e si preme Salva. Il nuovo tipo riceve il primo colore libero.
2. Si clicca Imposta scorciatoia sulla sua riga, si preme ⌥2 e poi si preme la combinazione ancora una volta, perché Speak-Y confermi che raggiunge l'app oltre la finestra della chiamata. Si preme Fatto.
3. Si ripete per «Atteso» su ⌥3 ed «Effettivo» su ⌥4.

Attiva note delle riunioni, in cima alla pagina, deve essere attivo. È una configurazione che si fa una volta: i tipi restano per tutte le chiamate successive.

Durante la chiamata: un tasto dopo ogni passo

Quando la chiamata inizia, Speak-Y chiede Registrare come riunione? sopra il pulsante di registrazione; si clicca il segno di spunta. Speak-Y registra il microfono e l'audio che il Mac riproduce, quindi Zoom, Google Meet e Microsoft Teams funzionano allo stesso modo e nessun bot entra nella chiamata; conviene dire a Dana che si sta registrando.

Poi le si chiede di riprodurre il bug dicendo ad alta voce ogni clic e ogni valore. Il tasto si preme subito dopo la frase:

• «Apro Reports e imposto il filtro per data su settembre» — ⌥2, Passo di riproduzione.
• «Clicco Export CSV» — di nuovo ⌥2.
• «Il file dovrebbe avere le 212 righe che vedo sullo schermo» — ⌥3, Atteso.
• «Ne ha 3.480: tutte le righe da gennaio» — ⌥4, Effettivo.

Ogni pressione segna gli ultimi 15 secondi sotto quel tipo; il pulsante mostra per un attimo Ultimi 15 s segnati. Il segno copre ciò che è appena stato detto, per questo si preme dopo la frase, non prima. Speak-Y sente la chiamata e non la vede: un passo che Dana esegue in silenzio non è nella trascrizione, quindi lo si ripete da sé ad alta voce, «quindi hai scelto CSV, non XLSX», e si segna quello.

Dopo la chiamata: ripercorrere i passi

Si apre la registrazione da Riunioni. Si clicca Speaker 2 sopra la trascrizione e si digita «Dana», così la segnalazione dice chi ha visto che cosa. Poi, nella scheda Per parlanti, si usa la striscia di chip: Tutte le note con il totale e un chip per tipo, Passo di riproduzione · 5, Atteso · 1, Effettivo · 2. Si clicca Passo di riproduzione e restano solo gli interventi con un passo; le frecce accanto ai chip passano dall'uno al successivo.

Bastano due minuti, e rispondono a una sola domanda: i passi sono completi? Se ne manca uno, si fa clic destro sull'intervento in cui Dana lo ha detto, si sceglie Aggiungi nota e si indica il tipo. Infine si clicca Tag e si crea un tag come export-bug, così una chiamata successiva sullo stesso bug finisce accanto a questa.

La bozza: si chiede a Cursor via MCP

Il server MCP di Speak-Y è incluso in ogni piano e gira sul Mac. Cursor si collega una volta in Impostazioni → Integrazioni: si clicca Installa accanto a Cursor e lo si riavvia; i dettagli sono in Cursor e il contesto delle riunioni via MCP. Dal lato di Cursor, la pagina dei prezzi elenca «MCPs, skills, and hooks» nel piano Individual da 20 $ e non nel piano gratuito Hobby (verificato l'8 ottobre 2026). Poi si chiede nella chat dell'agente:

Usando la mia registrazione «Export bug — call with Dana», scrivi una segnalazione di bug: Riepilogo, Passi per riprodurre, Risultato atteso, Risultato effettivo, Ambiente. Costruisci i passi solo dai segni Passo di riproduzione, in ordine, ciascuno con la sua ora. Non aggiungere passi che non sono stati detti. Poi trova il codice che genera l'export CSV e dimmi dove potrebbe perdersi il filtro per data.

L'agente chiama search_recordings per trovare la registrazione e get_transcript per leggerla. Riceve la trascrizione in blocchi attribuiti ai parlanti con gli orari, il riepilogo e una sezione Note in cui ogni segno occupa una riga: la sua ora, il suo tipo, il parlante e le prime parole dell'intervento. Una riga ha questo aspetto: - 04:12 · Passo di riproduzione — [Dana — 04:05]: “I open Reports and set the date filter…”. I passi numerati nascono dalle pressioni di ⌥2, non dalla lettura che il modello fa di una conversazione di venti minuti; e poiché lo stesso agente può aprire il repository, la segnalazione e la prima ipotesi arrivano in un'unica risposta.

La lettura è locale, dalla libreria di Speak-Y sul Mac. Ciò che l'agente legge entra nella chat e va al modello, esattamente come il codice.

Nessuna chiamata? La segnalazione si detta nel tracker

Quando il bug lo si è trovato da sé, la riunione si salta. Si clicca nel campo della descrizione del nuovo ticket (Jira, Linear, GitHub Issues), si tiene premuto Right ⌘, si dice la segnalazione, si rilascia. Per tutto ciò che supera poche frasi si preme ⌥ Space una volta, si parla e lo si preme di nuovo. Speak-Y incolla il testo nel punto in cui si trova il cursore e non invia il modulo. La punteggiatura viene aggiunta automaticamente.

Se si pronuncia il modello ad alta voce, la struttura resta: «Passi per riprodurre. Uno, aprire Reports. Due, impostare il filtro per data su settembre. Tre, cliccare Export CSV. Atteso: 212 righe. Effettivo: 3.480 righe». Lo stesso tasto funziona nella casella della chat di Cursor, dove una descrizione detta a voce tende a includere ciò che una scritta tralascia: che cosa si è provato, che cosa si è escluso, perché si sospetta del filtro. Di questa abitudine parla programmare a voce con gli assistenti IA.

La dettatura in qualsiasi app funziona in ogni piano; Free include 2.000 parole a settimana, che sono parecchie segnalazioni di bug.

Chi apre il ticket?

Lo si apre da sé, oppure lo apre l'agente tramite il server del tracker stesso: non Speak-Y. Speak-Y non ha integrazioni con Jira, Linear o GitHub, quindi la via semplice è copiare la bozza da Cursor nel ticket.

L'altra via è un secondo server MCP nello stesso Cursor. Linear ne documenta uno con strumenti per trovare, creare e aggiornare le issue, e il Rovo MCP Server di Atlassian crea e aggiorna i ticket di Jira; entrambi indicano Cursor tra i client (verificato l'8 ottobre 2026). Con uno dei due collegato, «apri questo come bug nel progetto Reports» diventa una chiamata a uno strumento. Per impostazione predefinita l'agente di Cursor chiede l'approvazione prima di usare uno strumento MCP: il testo del ticket va letto in quella richiesta, perché è l'ultimo momento in cui è ancora una bozza.

Prima di aprire il ticket

• Ogni passo è stato ascoltato, non solo letto. Si clicca l'ora di un intervento per riprodurre la registrazione da quel momento. Un passo dedotto dal modello è quello che rende il bug «non riproducibile».
• I numeri si controllano a orecchio. 212 e 3.480 sono proprio il tipo di parole che un riconoscitore può sbagliare.
• Le citazioni non sono letterali. Speak-Y rimuove intercalari e ripetizioni dalle trascrizioni delle riunioni, quindi una frase citata è più pulita di ciò che è stato detto.
• L'ambiente è compilato. Numero di build, browser, account: se in chiamata nessuno li ha detti, nella trascrizione non ci sono, e l'agente dovrebbe lasciare la riga vuota anziché tirare a indovinare.
• Niente di privato viaggia con il ticket. Una chiamata con il QA divaga; nel ticket va il bug, non il resto della conversazione.

Su quali piani e piattaforme funziona?

All'8 ottobre 2026 (prezzi), la registrazione di una riunione si ferma al limite per riunione del piano: 30 minuti con Free, 60 con Pro, 240 con Pro+ e Max. Una chiamata di venti minuti su un bug rientra in Free, entro le sue 2 ore di riunioni al mese. Tipi di nota, segni, riepilogo e server MCP sono disponibili in ogni piano.

Questa guida descrive l'app per Mac (macOS 14.2 e successivi). L'app per Windows detta in qualsiasi campo e registra le riunioni con nomi dei parlanti e tag, ma non ha i segni. Se la correzione diventa una discussione di progettazione, gli stessi segni costruiscono un altro documento, come descritto in dalla discussione di una funzionalità alla bozza del PRD, e un canale del team tiene la chiamata accanto a tutte quelle successive sullo stesso bug.

FAQ

Come si scrive una segnalazione di bug a voce?

Si clicca nel campo della descrizione del ticket, si tiene premuto il tasto Right ⌘ (su Mac il tasto rapido predefinito di Speak-Y da tenere premuto per parlare), si dicono i passi, che cosa ci si aspettava e che cosa è successo, e si rilascia. Speak-Y incolla il testo nel punto in cui si trova il cursore e non invia nulla. Per una segnalazione lunga si preme ⌥ Space una volta, si parla e lo si preme di nuovo. Lo stesso tasto funziona in Jira, Linear, GitHub e nella casella della chat di Cursor.

Cursor può scrivere una segnalazione di bug da una chiamata con il QA?

Sì, se la chiamata è registrata in Speak-Y e Cursor è collegato al server MCP di Speak-Y. L'agente trova la registrazione e la legge con get_transcript: interventi attribuiti ai parlanti con gli orari, il riepilogo e una sezione Note che elenca ogni segno con la sua ora e il suo tipo. Gli si chiede di costruire i Passi per riprodurre solo dai segni di quel tipo, poi si controlla ogni passo sulla registrazione.

Come si segnano i passi di riproduzione durante una chiamata?

Si crea un tipo di nota chiamato Passo di riproduzione in Impostazioni → Note → Aggiungi tipo di nota e gli si assegna una scorciatoia, per esempio ⌥2. Mentre Speak-Y registra la chiamata come riunione, si preme il tasto subito dopo che chi fa il test ha finito di descrivere un passo: Speak-Y segna gli ultimi 15 secondi sotto quel tipo. Un passo perso si può segnare più tardi: clic destro sull'intervento, poi Aggiungi nota.

Speak-Y crea il ticket in Jira o Linear?

No. Speak-Y non ha integrazioni con i tracker: fornisce il testo, con la dettatura o attraverso la trascrizione che l'assistente legge. La segnalazione la si incolla da sé, oppure si lascia che l'agente la apra tramite il server MCP del tracker stesso, che va collegato e autorizzato a parte: Linear e Atlassian ne pubblicano uno ciascuno (verificato l'8 ottobre 2026).

Speak-Y registra lo schermo di chi fa il test?

No. Speak-Y registra solo l'audio: il microfono e ciò che il Mac riproduce, quindi la voce di chi fa il test da Zoom, Google Meet o Microsoft Teams. Ciò che accade sullo schermo condiviso non viene catturato. Conviene chiedere di dire ad alta voce ogni clic e ogni valore, e allegare al ticket uno screenshot o il video della piattaforma se il bug è visivo.