Home
Bug Report Suite for WillBit Projects¶
Pagina Personale¶
Progetti¶
Ambienti Naxos¶
-
Ambiente DEV
Questo ambiente è destinato ai test di sviluppo, alla correzione dei bug e all'implementazione delle nuove funzionalità. -
Ambiente DEMO
In questo ambiente vengono testate esclusivamente versioni stabili di Naxos, sia dal punto di vista funzionale che per applicare eventuali ultime modifiche. La piattaforma DEMO rappresenta anche la vetrina per mostrare il prodotto e le sue funzionalità ai clienti. -
Ambiente PRODUZIONE
L'ambiente di produzione è costituito dalle singole installazioni presso i clienti, sulle quali vengono trasferiti esclusivamente codice stabile e testato.
Premesse¶
-
Completamento della Segnalazione
La segnalazione deve includere tutti i dati necessari per la comprensione, l'individuazione e la riproduzione del bug. Nello specifico, è essenziale che vengano forniti:- I passaggi necessari per riscontrare l’anomalia segnalata.
- L'ambiente in cui il bug si è verificato es. DEV, DEMO, PRODUZIONE. In caso di anomalia in ambiente di Produzione, specificare quale ambiente (es. Libertà, Avvenire, L'azione ecc) tramite l'apposito menù a tendina.
- Il ruolo che ha riscontrato l'anomalia (es. admin, giornalista, redattore, super admin).
- Eventuali azioni specifiche, come dove si è cliccato e quanti passaggi sono stati effettuati dal login fino alla pagina in cui si è manifestata l'anomalia.
- Ogni altra informazione utile per replicare il bug. In tal senso, è possibile allegare immagini di riferimento, link o file sulla piattaforma.
-
Comportamento Atteso
È fondamentale che nella segnalazione venga esplicitato il comportamento atteso durante l’esecuzione di una determinata procedura, in contrasto con quanto accaduto al momento del bug. -
Assegnazione alla Scheda Prodotto
È fondamentale che le segnalazioni vengano fatte nella scheda del prodotto corretta. In questo modo, gli sviluppatori avranno sempre un quadro chiaro della situazione e potranno intervenire in modo mirato sui progetti. -
Segnalazioni Singole e Agnostiche
Le segnalazioni devono essere formulate come singole e agnostiche.
Le segnalazioni multiple devono essere utilizzate solo quando non è possibile scindere la segnalazione in più argomenti o su precisa indicazione dello sviluppatore.
Workflow¶
Attualmente, la piattaforma Redmine prevede i seguenti stati per la gestione delle segnalazioni:
-
Nuovo
La segnalazione viene inserita come "Nuovo" e risulta aperta.
-
In Elaborazione
Lo sviluppatore si assegna la segnalazione e inizia a lavorarci.
-
Risolto su DEV o Risolto in Produzione o Risolto in Staging
Quando un bug viene corretto, il programmatore valuta l'entità della correzione e decide se segnalarlo come "Risolto su Dev" o "Risolto in Produzione" o "Risolto in Staging".- "Risolto su Dev": Se la correzione è stata effettuata nell'ambiente di sviluppo.
- "Risolto in Produzione": Se la correzione è stata confermata in ambiente di produzione.
- "Risolto in Staging": Se la correzione è stata confermata in ambiente di staging.
-
Chiuso
La segnalazione passa a "Chiuso" solo dopo che lo sviluppatore ha ricevuto un riscontro dal segnalatore, il quale conferma definitivamente la risoluzione del bug. Senza tale conferma, la segnalazione non può essere considerata conclusa.
-
Rifiutato
In alcuni casi, a discrezione del programmatore, la segnalazione può essere rifiutata.
-
In Attesa di Riscontro
La segnalazione passa su questo stato per evidenziare che è necessario un confronto con il segnalatore.
⚠️ Nota Importante: ⚠️¶
Indipendentemente da dove la segnalazione venga segnata come "Risolto" (su DEV o in Produzione), è fondamentale che lo sviluppatore riceva un riscontro dal segnalatore dopo i test. Questo riscontro confermerà che la correzione è stata effettivamente risolutiva e che il bug è stato risolto come previsto.
Il riscontro da parte del segnalatore è un passo imprescindibile per garantire la qualità e la corretta risoluzione del problema, nonché la possibilità di chiudere definitivamente la segnalazione.