Idea, pianificato, sviluppo, test, completato non sono sinonimi
La board di EclipsMC usa stati differenti perché il tipo di incertezza cambia durante il lavoro. Un’idea può essere interessante ma non ancora compatibile con il resto del network. Un’attività pianificata ha un obiettivo, ma non una soluzione implementata. In sviluppo significa che il sistema sta cambiando. In testing significa che esiste una soluzione concreta che deve ancora dimostrare di reggere i casi reali. Solo “done” dovrebbe indicare che il percorso principale e i controlli di regressione sono passati.
Questa distinzione evita due errori: promettere troppo presto alla community e considerare concluso un lavoro appena scompare l’errore che lo ha fatto iniziare.
Scrivere il risultato atteso prima della soluzione
Quando una card dice soltanto “sistemare cage” o “aggiustare mobile”, il rischio è correggere il sintomo visibile senza definire il comportamento corretto. Preferiamo trasformare la richiesta in un risultato osservabile: “ogni spawn SkyWars mostra una cage completa che scompare al countdown e resta corretta dopo riavvio” oppure “la pagina comandi mantiene layout, filtri e azioni principali sotto una certa larghezza”.
Il vantaggio è pratico: il test finale può essere confrontato con una frase. Se il risultato non è verificabile, anche la conclusione sarà soggettiva.
Cambiare il minimo numero di sistemi necessario
Un problema può attraversare più plugin, ma non significa che vadano modificati tutti. Prima si individua la sorgente del dato o del comportamento. Se la scoreboard mostra il valore sbagliato, si verifica se il problema nasce dal placeholder o dalla configurazione; se un comando del bot è duplicato, si controlla la registrazione e non si rinomina tutto il progetto.
Modifiche piccole e tracciabili rendono più facile capire quale cambiamento ha introdotto una regressione. Quando invece si approfitta di un fix per rifare contemporaneamente stile, struttura, nomi e logica, ogni test fallito apre troppe ipotesi.
Provare il percorso completo, non soltanto il punto modificato
Se tocchiamo la pagina login, testiamo anche il redirect alla pagina richiesta, il menu account e l’accesso negato alle aree staff. Se tocchiamo il kanban, verifichiamo creazione, modifica, trascinamento, persistenza e comportamento da visitatore. Se tocchiamo un plugin di lobby, controlliamo ingresso, uso, uscita e ritorno.
Ogni funzione ha un “prima” e un “dopo”. Un fix locale che rompe il passaggio successivo non è un fix. Per questo le checklist devono essere costruite intorno ai flussi dell’utente, non ai file modificati.
Il riavvio è un test funzionale
Molti sistemi mantengono dati in memoria: spawn, cache, sessioni, stato del bot, configurazioni caricate, dati live. Una modifica che funziona immediatamente ma sparisce dopo un restart non è persistita nel punto corretto. Allo stesso modo, un processo avviato manualmente può sembrare stabile finché la VPS non si riavvia.
Per questo il ciclo di test include un riavvio controllato quando la modifica riguarda configurazioni, script di startup o dati persistenti. Dopo il riavvio non verifichiamo soltanto che il processo sia “up”, ma che la funzione continui a comportarsi come prima.
OP e staff possono nascondere bug di permessi
Testare sempre con privilegi elevati produce falsi positivi. Un amministratore può aprire menu, usare kit, spostare card o eseguire comandi che un giocatore normale non dovrebbe vedere. Per funzioni pubbliche proviamo quindi almeno un profilo senza privilegi; per funzioni staff controlliamo sia l’utente autorizzato sia quello autenticato ma senza ruolo sufficiente.
Il principio è “deny by default”: il frontend può nascondere un pulsante, ma l’API o il comando devono verificare nuovamente l’autorizzazione. L’interfaccia migliora l’esperienza; il backend protegge davvero l’azione.
Cercare ciò che non stavamo guardando
Le regressioni più fastidiose spesso compaiono in superfici vicine. Un nuovo header può rompere il menu mobile. Un cambio di alias può modificare un comando usato da NPC. Una nuova configurazione di scoreboard può far riapparire un nome tecnico. Un aggiornamento di un plugin può risolvere un problema e introdurne un altro nel formato dei file.
La checklist di regressione contiene quindi le aree adiacenti più fragili: responsive, permessi, messaggi, placeholder, persistenza, link, cache e compatibilità con i mondi esistenti. Non serve testare ogni funzione del network dopo ogni modifica; serve sapere quali dipendenze sono realistiche.
La nostra formula pratica
Se uno di questi punti è ancora incerto, la card può essere molto avanti ma non è automaticamente completata. Questa disciplina rallenta leggermente il momento in cui scriviamo “done”, ma riduce il numero di volte in cui dobbiamo riaprire lo stesso problema dopo un riavvio o una prova reale.