In una fase di test, posso sollevare un difetto verificatosi a causa di problemi di distribuzione?

Da un lato, gli sviluppatori vogliono bug corretti nel codice che devono essere corretti.

D'altra parte, in che modo QA dovrebbe sapere se si tratta di codice, dati, script o errore umano? QA sa che non funziona. Il QA segnala che non funziona. Cosa succede se sembra essere dovuto al fatto che il lavoro in ritardo non è stato riavviato, ma in realtà era un bug nell'inizializzatore del lavoro in ritardo? Il QA non è attrezzato per capirlo.

Non è compito di QA capire il problema o la soluzione. Il compito di QA è trovare il problema e trovare le condizioni che causano il problema, quindi comunicare i risultati. È compito del Product Manager assegnarlo alla persona appropriata per risolverlo, sia esso uno sviluppatore, un amministratore di sistema, un amministratore di sistema o un gopher.

Quindi sì, dovresti sollevare un bug. Non funziona, questo è tutto ciò che sai. Chiunque stia eseguendo la distribuzione dovrebbe creare uno script per riavviare automaticamente i lavori in ritardo durante la distribuzione. Il fatto che non lo facciano, o che non funzioni, è il bug qui. OTOH, se è un problema perché il lavoro è nel processo di riavvio, l'errore è che non fornisce un feedback ragionevole all'utente ("Attendere prego. .. ").

Naturalmente, se il tuo capo dice che non dovresti innalzare un bug, allora non farlo. Il tuo capo è l'autorità suprema, non alcuni estranei casuali su Internet.

Processi ripetibili dentro / intorno al tuo sistema sono altrettanto importanti del "codice". Le implementazioni devono essere ripetibili e richiedono uno sforzo manuale minimo. Ciò aiuta a garantire che anche le distribuzioni di produzione siano sicure. Se questo processo non funziona, questo è un bug tanto quanto qualsiasi errore di codifica.

Quando gli sviluppatori consegnano il sistema a QA, dovrebbe funzionare. Non è richiesta alcuna magia speciale. Non è così, l'installazione deve essere risolta. In quale altro modo crederai che le tue installazioni produttive siano sicure?

I team di sviluppo devono essere consapevoli del fatto che qualsiasi cosa al di fuori del sistema operativo che rende il software non funzionante è un bug. Se questo è il tuo software, i file di configurazione, gli script di avvio / arresto non contano davvero. Gli utenti non si preoccupano veramente di dove si trova il "bug" quando il sistema non funziona.

Quindi ti consiglio di presentare i bug fino a quando il team di sviluppo non è in grado di fornire un sistema operativo pulito al QA ripetutamente.

Penso che dipenda dal livello di qualità che tu o la tua azienda volete ottenere.

È buona prassi creare bug per qualcosa che è non correlato al codice. Penso che sia ancora meglio creare qualche altro bug " progetto " correlato a questo tipo in caso di problemi.

Con questo intendo che spesso usiamo bugtracker come Jira o Bugzilla solo per gestire bug relativi al codice. Quindi, forse è per questo che è strano creare un bug non correlato al codice.

Ma potremmo avere diversi tipi di problemi in altre aree dello sviluppo del software, ad es. Documentazione, requisiti, processo.

Quindi dovremmo sfruttare questi tracker per gestire questi altri tipi di problemi. È possibile creare divisioni o "progetti" in questi strumenti per gestire i bug in diversi aspetti del processo di sviluppo del software.

Quindi potresti creare un "progetto" nel tuo bug tracker relativo ai problemi di "restarted job restarting " che avevi. In questo modo, non mischi questo bug con i bug del codice nel bug tracker.

Di solito, dovresti aumentare un qualche tipo di biglietto. Potrebbe non essere un bug nel sistema di tracciamento dei bug, ma un ticket di servizio per il team operativo per intraprendere qualche azione (come riavviare quel lavoro).

Un altro pensiero, pure. Sembra che questo stesso problema si ripresenti più e più volte. Potresti voler aumentare un miglioramento per correggere la causa principale o inserire un monitor / riavvio automatico. (è meglio correggere la causa principale)