È un comportamento indesiderato, mentre il lavoro è in corso, dichiarabile come "bug"?

0

Questa potrebbe essere solo una domanda di definizione, ma forse c'è un consenso?

Data la situazione, il software Foobar Plus è in costruzione, non stiamo lavorando ad un aggiornamento, ma alla sua prima versione.

Ora, una caratteristica specifica (A) è stata implementata;

    La funzione
  • (A) ha causato un comportamento indesiderato nella funzione (B).
  • Non ha alcuna influenza sulla funzione (A), ma è causata da essa.
  • La funzione (B) non è ancora implementata, il comportamento è stato notato a causa dell'interpretazione dei log di debug.

La domanda ora è; questo comportamento inaspettato è chiamato bug, o solo un cambiamento nell'ambiente della funzione (B)?

Modifica: Non si tratta di incolpare nessuno, ma di trovare la definizione appropriata per questo caso.

    
posta Sempie 30.07.2015 - 14:08
fonte

5 risposte

3

Dipende

Il significato della parola "bug" è a volte informale, a volte formale, a volte controverso, anche, a volte, definito dal contratto. Ho lavorato su progetti in cui sono stati addebitati i costi per ogni bug trovato dopo una certa data; in una situazione del genere, la definizione è chiaramente indicata nel contratto.

Evita l'argomento intero

Se la tua situazione non è così rigorosa, ma le persone sono ancora controverse, ti consiglio di evitare completamente il "bug" e di utilizzare questi termini alternativi:

Un difetto di implementazione è presente quando il comportamento previsto non corrisponde al comportamento effettivo. Il comportamento può essere "previsto" solo in presenza di un requisito - no "Semplicemente non mi piace!" tipo di problemi sono ammessi. I difetti di implementazione sono causati e risolti dagli sviluppatori.

Un difetto di progettazione è presente quando il comportamento corrisponde al design, ma il design non soddisfa i requisiti. In altre parole, si è verificata un'errata mappatura durante la conversione dei requisiti di sistema in requisiti software derivati . Questi sono causati e risolti da architetti o analisti tecnici del business.

Un difetto dei requisiti è presente quando il comportamento corrisponde ai requisiti ma i requisiti non corrispondono alla dichiarazione di missione dell'applicazione; in altre parole, c'è un errore nella mappatura di tracciabilità tra requisiti aziendali e requisiti di sistema. Questi sono causati e risolti dalle parti interessate o dagli analisti aziendali. (Nota: quando questi si presentano, è importante aggiornare la documentazione e informare il QA in modo che possano aggiornare i loro casi di test).

Un divario di requisiti è presente quando un comportamento non è incoerente con i requisiti dichiarati, ma sembra sbagliato ed è probabilmente qualcosa a cui nessuno pensava.

Nel tuo caso, la funzione B non è ancora stata implementata, quindi non hai un difetto di implementazione. È probabilmente un difetto di progettazione o un gap di requisiti.

    
risposta data 28.01.2017 - 02:58
fonte
2

Se capisco bene, la caratteristica B funziona invariata, ma poiché la caratteristica A esiste, il comportamento corrente di B non è più un buon comportamento. Quindi potrebbe essere il caso che le specifiche della caratteristica B debbano cambiare.

In un posto in cui lavoravo non avevano bug, ma "Richieste di modifica". Proprio per questo motivo.

    
risposta data 30.07.2015 - 14:45
fonte
2

Comportamento indesiderato o imprevisto quasi sempre inizia la vita come un bug .

Se il codice in questione è richiesto per la funzione A, allora sarebbe necessaria una richiesta di modifica per la compatibilità con la funzione B. Quindi si trasforma in una richiesta di funzionalità.

Se il codice in questione non è corretto, implementato male o ha effetti collaterali non testati, si tratta di un bug nella funzionalità A. Quindi rimane un bug. Certo, potrebbe non avere la caratteristica A originale o notevolmente rotta A - ad es. memory scribblers ecc., ma è un bug.

Registra il problema, triage, riclassifica se necessario, assegnalo, risolvilo, testalo .

    
risposta data 30.07.2015 - 14:46
fonte
1

Può essere entrambi.

Se la caratteristica (A) ha causato alcuni effetti collaterali indesiderati dall'implementazione, la chiamerei un bug

Se la caratteristica (A) ha causato alcuni effetti collaterali indesiderati di progettazione, la chiamerei una modifica delle caratteristiche

    
risposta data 30.07.2015 - 14:14
fonte
0

La mia definizione di bug è un comportamento inaspettato / non conforme scoperto DOPO che una funzionalità è stata consegnata. Qualsiasi altra cosa significa che la funzione fallisce la definizione di fatto. A meno che non sia determinato che la funzionalità verrà passata perché ha soddisfatto le specifiche e che verrà ridefinita in uno sprint / consegna futuri.

Per la maggior parte se l'implementazione di una funzione interrompe un'altra funzionalità nel sistema, direi che la funzione non è stata eseguita. Se l'interruzione viene scoperta dopo la consegna della funzione, direi che si tratta di un bug.

    
risposta data 28.01.2017 - 03:21
fonte

Leggi altre domande sui tag