È corretto riferirsi a una funzionalità che non è stata ancora codificata come "bug"?
Ad esempio, sto lavorando a un progetto che comprende tre caratteristiche distinte. Se avvio solo uno di questi, è corretto riferirsi agli altri due come bug? Oppure i bug si applicano solo alle funzionalità che sono state codificate e testate?
Sembra inutile fare riferimento alle funzionalità mancanti come bug mentre sei ancora in fase di sviluppo.
Se dovessi rilasciare il prodotto senza queste funzionalità, potrebbe essere considerato un bug mancante, in quanto il software non esegue ciò che è stato progettato per fare.
Questo è il motivo per cui odio l'idea di suddividere le cose in bug e funzionalità. Porta a argomentazioni come questa che sono distrazioni dal realizzare effettivamente un lavoro utile.
Chiama tutto Attività o Elementi di lavoro e vai avanti con la vita.
Dovresti evitare di parlare di bug e funzionalità, poiché ciò implica una differenza qualitativa per l'utente, mentre non esiste una cosa del genere. Dal punto di vista dell'utente, se qualcosa è un bug o un miglioramento è irrilevante, perché in entrambi i casi l'utente non è in grado di utilizzare il prodotto. Se aiuta, puoi pensare ai bug come sviluppi di feature non terminati.
Ci sono solo problemi , come in "gli utenti hanno problemi con il tuo software in esecuzione". Metti tutti i tuoi problemi in una lista con una serie di priorità. In questo modo i bug non si presenteranno di fronte a miglioramenti con priorità più alta, e i miglioramenti non verranno di fronte a bug con priorità più alta.
Direi che una caratteristica mancante è un bug nel caso in cui la mancanza di quella funzione interrompa il tuo programma.
In questo caso, tuttavia, sarebbe difficile chiamarli bug, dal momento che il progetto non è ancora in uno stato funzionante. Oppure, se funziona, e la mancanza delle funzionalità non sta rompendo nulla, quindi sono solo funzionalità non implementate.
Troverò caratteristiche e bug in modo diverso. Hai ancora una coda di lavoro che devi superare, ma un bug si verifica quando il sistema non funziona correttamente. Se nella tua implementazione della prima feature hai fatto un errore, quello è un bug. Il fatto che gli altri due non siano ancora implementati non ha importanza. Sono funzioni su cui si sta ancora lavorando.
La definizione di "bug" è piuttosto fluida e lo è stata da quando Grace Hopper ha trovato l'insetto morto all'interno del computer Mark I. ( sì, questo potrebbe essere un account appochryphal )
Dal punto di vista dell'utente, una funzione non implementata potrebbe essere considerata un bug , specialmente se è proprio la funzione che vogliono usare adesso .
Devi davvero avere una buona comunicazione con il tuo utente finale / cliente / stakeholder sullo stato attuale del tuo software. Perché dire in sviluppo quando si dice molto più facilmente che si tratta di una versione alfa o beta (o la mia preferita personale - una versione beta di una versione alpha molto precoce ...)
IMHO non è appropriato, ma la gente lo farà ancora. Otterrai questo anche per determinate decisioni (in particolare nell'interfaccia utente) che non sono bug.
La ragione principale è che la maggior parte delle persone percepisce come un bug qualsiasi cosa si aspetta che si verifichi in un certo modo e quale no. Indipendentemente dal fatto che non sia implementato correttamente o perché non è implementato affatto, non importa.
Questo è aggravato se i tuoi utenti o i rapporti di errore sono anche ingegneri, nel qual caso assumono che qualsiasi funzione che desiderano possa essere stata implementata da loro in 5 righe di codice, indipendentemente dalla realtà.
Dio, questo genere di cose mi fa impazzire. Voglio attraversare lo schermo e pugnalare il tuo manager, che presumo ti stia spingendo a fare questa domanda.
Ecco le mie definizioni:
Se una persona prodotto non ha chiesto qualcosa? Questo non è un bug. Se hanno chiesto la cosa sbagliata? Inoltre, non un bug. Il venditore rilascia una nuova piattaforma che dobbiamo fare qualcosa per supportare? Non un bug Se un utente capisce qualcosa che sarebbe un bel miglioramento? Sicuramente non è un bug.
Il motivo per cui è così importante per me è che i team dovrebbero sparare per zero bug . È un bug se la squadra punta e manca l'obiettivo. Non è un bug se l'obiettivo non è ancora in vista.
Secondo me, l'utilizzo originale è quello che ti aspetti:
Tuttavia, ci sono ovvie somiglianze in quanto entrambe sono cose che devi fare, e qualche volta c'è un dubbio legittimo, e molte persone fanno battute che una è una specie dell'altra ("non è un bug, è una caratteristica, ecc. . ")
In particolare, ci sono due modi comuni, diffusi e ragionevoli per usare "bug" per includere "funzionalità":
Quando l'utente ha aspettative (molto ragionevoli o irragionevoli) nei confronti del programmatore. L'utente pensa "aspetta, dovrei riuscire a trascinare ma non posso, è un bug". Il programmatore pensa "Non ho ancora implementato il trascinamento e non c'è un'interfaccia utente che suggerisca di essere in grado di". (Se si tratta di una caratteristica sufficientemente importante, è importante quanto un bug (non pericoloso), nel senso che "senza funzione X, le persone non possono usare il software".
Le persone comunemente (e per molte ragioni ragionevoli) utilizzano database di bug per tracciare qualsiasi tipo di modifica al sistema che hai deciso di fare.
Se si gestiscono elenchi separati, è importante poter migrare gli elementi tra di loro, in modo da poter indirizzare gli articoli nel posto giusto dovunque entrino. Se li si combina, distinguere tra ciò che si deve risolvere e ciò che sarebbe essere davvero utile, ma il codice funzionerà ancora se lo rimandi alla prossima versione.
Quando decidi cosa fare dopo, è sensato distinguere generalmente (ad esempio, correggi tutti i bug in sospeso che avresti mai risolto prima, poi nuove funzionalità o altro). Ma non sempre.
Se qualcuno descrive le funzionalità non finite come bug nel senso che "qualcosa non va", allora si sbagliano. Se li descrivono come bug nel senso che "sono qualcosa che stai andando a rilanciare nel codice", hanno ragione.
Alcuni proverebbero a passare un bug come una funzionalità ancora da implementare.
But HOW you categorize this is dependent on who raised the request/complaint If its the client who raised it expecting a feature already sold to him This would be a bug.
Ma dichiari che il progetto è in fase di sviluppo. Se hai appena iniziato lo sviluppo su questi, allora impossibile essere chiamato bug.
Ma se sei molto tardi nel progetto e hai appena gestito una sola funzione, probabilmente tutte le tre funzionalità potrebbero essere state completate. La gestione potrebbe essere in grado di visualizzare le funzionalità mancanti come bug.
Una funzionalità non ancora implementata è un miglioramento non un bug.
Is it fair to refer to a feature that has not yet been coded as a "bug"?
No, non penso sia giusto.
Se qualcuno mi avesse detto del mio codice, avrei immediatamente rivisto la mia stima della loro intelligenza ... verso il basso. Quindi direi "Whatever" e spostare l'argomento della conversazione su qualcosa di più importante.
Detto questo, potrebbe essere che le tue funzionalità non implementate vengano visualizzate come test falliti sulle tue build notturne. In questo caso, verifica se è possibile disabilitare i test specifici fino a quando il codice è pronto per essere testato.
Le chiamiamo richieste di funzionalità e le assegniamo priorità in modo appropriato. I bug di Pri 1 sono must-fix, p2 sono belli da sistemare e così via.
Sarei titubante nel classificare una funzionalità pianificata e promessa mancante e intenzionalmente non implementata come errore.
C'è sicuramente un problema, ma chiamando le funzionalità mancanti un bug non rende giustizia o comunica la potenziale gravità o urgenza; soprattutto se lo sforzo complessivo o una particolare fase / iterazione è sotto contratto; o le caratteristiche mancanti sono parte di una campagna di marketing. Se questo è il tuo scenario, vorrei strongmente spingere verso la data di rilascio per un periodo successivo, al fine di fornire ciò che è stato promesso, anche se le funzionalità mancanti sono un po 'meno elegantemente implementate.
Se fa parte di uno sprint di breve durata e i rilasci sono regolari e frequenti, il tuo team potrebbe essere ok semplicemente riportandolo al prossimo sprint e dimostrando una pianificazione e una consegna più coerenti in futuro.
Per semplificare eccessivamente:
così per il cliente ogni cosa è un bug e per un produttore tutto è una funzionalità.
Quando si arriva a tracciare queste cose, è necessario un luogo in cui registrare i difetti e le nuove funzionalità mancanti o mancanti.
Il posto migliore è UN SOLO POSTO per registrare tutto con un sistema appropriato di categorizzazione.
Quindi potresti dire che un rapporto è "richiesta di funzionalità", "arresto anomalo", "difetto di stop-getting-work-done", ..., "errore testuale" come mezzo per metterli in gruppi ordinabili e prioritabili .
Se si dispone di un sistema, è facile allocare funzionalità e correzioni di errori a una build. Se lo fai in un altro modo è difficile mantenere l'oscilloscopio in un posto che è ricercabile e può mostrare progresso.
Le funzionalità potrebbero essere quelle desiderate e pianificate per una versione futura. Potrebbero anche essere funzionalità necessarie per un rilascio e non ancora eseguite. Potresti persino scegliere di spedire con alcune funzionalità incomplete o mancanti.
In questo senso, il LACK di una caratteristica in realtà comprende un difetto: la funzione che dovrebbe essere presente (per requisito esplicito o per qualche desiderio implicito) non è presente.
PUOI se scegli di fare un passo avanti e durante lo sviluppo iniziale colloca tutti i requisiti o le caratteristiche principali [i grumi della tua storia ... tutto dipende dal processo che usi e dalla terminologia che ti piace] nel sistema di tracciamento dei difetti anche.
L'ho fatto e rende davvero soddisfacente l'elaborazione dei set di funzionalità verso il completamento.
Infastidisce il diavolo dei tester che dicono "come posso tracciare i difetti quando è iniziato con un sacco ... e che è caduto quando hai finito i pacchetti di lavoro". La risposta è: difficile ... ottimizza i tuoi rapporti!
Leggi altre domande sui tag testing