• Un bug è il risultato di un errore di codifica

• Un difetto è una deviazione dai requisiti

Cioè: un difetto non significa necessariamente che ci sia un bug nel codice , potrebbe essere una funzione che non è stata implementata ma definita nei requisiti del software.

Dalla pagina di Wikipedia su test del software :

Not all software defects are caused by coding errors. One common source of expensive defects is caused by requirement gaps, e.g., unrecognized requirements, that result in errors of omission by the program designer.[14] A common source of requirements gaps is non-functional requirements such as testability, scalability, maintainability, usability, performance, and security.

Citando Ilene Burnstein dal libro Test di software pratico (consigliato) che parte dalla definizione contenuta nella "Raccolta degli standard IEEE per l'ingegneria del software" (1994) e "Glossario standard IEEE sulla terminologia dell'ingegneria del software" (standard 610.12, 1990):

Errore

An error is a mistake, misconception, or misunderstanding on the part of a software developer

In the category of developer we include software engineers, programmers, analysts, and testers. For example, a developer may misunderstand a de- sign notation, or a programmer might type a variable name incorrectly.

Guasti (Difetti)

A fault (defect) is introduced into the software as the result of an error. It is an anomaly in the software that may cause it to behave incorrectly, and not according to its specification.

Faults or defects are sometimes called “bugs.” Use of the latter term triv- ializes the impact faults have on software quality. Use of the term “defect” is also associated with software artifacts such as requirements and design documents. Defects occurring in these artifacts are also caused by errors and are usually detected in the review process.

Fallimenti

A failure is the inability of a software system or component to perform its required functions within specified performance requirements.

During execution of a software component or system, a tester, developer, or user observes that it does not produce the expected results. In some cases a particular type of misbehavior indicates a certain type of fault is present. We can say that the type of misbehavior is a symptom of the fault. An experienced developer/tester will have a knowledge base of fault/symptoms/failure cases (fault models as described in Chapter 3) stored in memory. Incorrect behavior can include producing incorrect values for output variables, an incorrect response on the part of a device, or an incorrect image on a screen. During development failures are usually observed by testers, and faults are located and repaired by developers.

Puoi leggere l'intero capitolo in Google Libri, qui

Esistono termini diversi relativi ai bug del software. Estratto da un corso che ho seguito:

• Errore : azione o omissione umana che provoca un errore.

• Fault : Fault è un difetto del software (passaggio errato, processo o definizione dei dati) che causa un errore.

• Bug : identico a Fault.

• Errore : l'incapacità di un software di eseguire le sue funzioni richieste entro i requisiti prestazionali specificati.

In base a ciò, non c'è differenza tra un difetto e un bug. Tuttavia, alcune persone sostengono che il bug sia un errore che si trova prima di rilasciare il software, mentre il difetto è quello riscontrato dal cliente.

Non ho potuto resistere alla pubblicazione del famoso "primo vero caso di bug trovato".

Dal Glossario standard IEEE della terminologia dell'ingegneria del software, che è citato nel KA di Engineering Engineering Body of Knowledge per i test del software e la qualità del software:

bug. See: error; fault.

error. (1) The difference between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition. For example, a difference of 30 meters between a computed result and the correct result. (2) An incorrect step, process, or data definition. For example, an incorrect instruction in a computer program. (3) An incorrect result. For example, a computed result of 12 when the correct result is 10. (4) A human action that produces an incorrect result. For example, an incorrect action on the part of a programmer or operator. Note: While all four definitions are commonly used, one distinction assigns definition 1 to the word “error,” definition 2 to the word “fault,” definition 3 to the word “failure,” and definition 4 to the word “mistake.” See a2so: dynamic error; fatal error; indigenous error; semantic error; syntactic error; static error; transient error.

failure. The inability of a system or component to perform its required functions within specified performance requirements. Note: The fault tolerance discipline distinguishes between a human action (a mistake), its manifestation (a hardware or software fault), the result of the fault (a failure), and the amount by which the result is incorrect (the error). See also: crash; dependent failure; exception; failure mode; failure rate; hard failure; incipient failure; independent failure; random failure; soft failure; stuck failure.

fault. (1) A defect in a hardware device or component; for example, a short circuit or broken wire. (2) An incorrect step, process, or data definition in a computer program. Note: This definition is used primarily by the fault tolerance discipline. In common usage, the terms “error” and “bug” are used to express this meaning. See also: data-sensitive fault; program sensitive fault; equivalent faults; fault masking; intermittent fault.

Penso che la definizione di fallimento sia la più rilevante. Tutto inizia con un errore, sia che si tratti dei requisiti, della progettazione, dell'implementazione o del caso / procedura di test. Se questo errore si manifesta nel software, diventa un errore. Un errore è causato dall'esistenza di uno o più errori nel software.

Tuttavia, non mi interessa la definizione formale di errore. Preferisco molto la definizione fornita da dukeofgaming nella sua risposta , tuttavia, quello in questa risposta è la definizione standard di errore IEEE.

Oh caro.

Ai vecchi tempi - il funzionamento difettoso di un computer era causato da ogni sorta di cose - inclusi i ratti che masticavano i cablaggi e i veri bug (critters) che entravano nel lavoro.

Il termine BUG è rimasto come un termine che indica che qualcosa non funziona come previsto.

L'ERUG dovrebbe essere considerato come un termine in gergo che indica un difetto.

Un difetto è un termine tecnicamente corretto che significa che la cosa non fa come dovrebbe.

Ove possibile, usare DEFECT al posto di BUG porta con sé una connotazione che riconosciamo i nostri fallimenti (i nostri difetti, la nostra mancanza di comprensione dei requisiti degli utenti o le cose trascurate nell'implementazione) invece di vestirli come il più banale suona "bug".

Usa DEFECT.

Cerca di non usare il termine BUG. È sciocco, irrilevante, storico e banalizzante.

La risposta di Dan McGrath l'ha inchiodata bene.

• Un bug è il risultato di un errore di codifica
• Un difetto è una deviazione dai requisiti

Forse un esempio renderebbe più chiaro.

Esempio: il cliente desiderava che il modulo web fosse in grado di salvare e chiudere la finestra.

Scenario n. 1: modulo Web con un pulsante di salvataggio e un altro pulsante di chiusura. Risultato: difetto, perché il cliente desiderava il pulsante 1 per salvare e chiudere la finestra. Sviluppatore frainteso e creato separatamente. Poiché entrambi i pulsanti hanno soddisfatto i loro requisiti, non si tratta di un bug, ma di un difetto perché non soddisfa i requisiti del cliente.

Scenario 2: il modulo Web ha un salvataggio & pulsante di chiusura, ma salva solo ma non chiude. Risultato: Bug. Perché il pulsante non funziona come richiesto / previsto. Lo sviluppatore sa che è necessario produrre quel risultato ma alla fine non lo ha fatto. (forse errore di codifica)

Non sono sicuro se questo lo rende più chiaro.

p / s: dal punto di vista dello sviluppatore (ero una volta), sia i difetti che i bug sono altrettanto importanti. Lo sistemeremo ancora.

Abbiamo persino riscontrato strane anomalie, che abbiamo classificato sotto bug e cerchiamo continuamente di capire quale sia la causa e come risolverla. Definirlo bug non lo rende banale rispetto ai difetti.

La differenza è che il termine "bug" sembra magico. Come se un programma potesse avere in modo casuale dei bug dopo aver finito di programmare. Se ha errori casuali, significa che non sei conforme alle specifiche e il tuo programma è in errore.

Un difetto indica un errore in cui il programma non è conforme alle specifiche. Questo è più grave e in pratica dice: qualsiasi errore è un enorme problema con il programma e questo significa che il programma non è adatto per essere rilasciato.

La differenza sta nell'atteggiamento dei programmatori che usano i termini. Ci sono milioni di programmi che vengono rilasciati con bug e le persone vanno bene perché accettano per qualche motivo che un bug è magico e casuale e che ogni programma contiene almeno un bug. Tuttavia, un programmatore che usa il termine "difetto" può diventare scomodo nel rilasciare un programma con un difetto perché il termine implica una gravità maggiore.

Le implicazioni di preferire un termine sull'altro influiscono quotidianamente.

Secondo Affidabilità: concetti e terminologia di base :

A system failure occurs when the delivered service deviates from fulfilling the system function, the latter being what the system is intended for. An error is that part of the system state which is liable to lead to subsequent failure: an error affecting the service is an indication that a failure occurs or has occurred. The adjudged or hypothesized cause of an error is a fault.

Comprendo difetto come solo un altro nome per errore.

Bug è confuso e può rappresentare un errore o un errore a seconda del contesto.

Nota che non si fa menzione delle specifiche: anche una specifica può essere difettosa.

Ecco uno che ho fatto prima per il mio datore di lavoro Q-LEAP basato sul vocabolario ISTQB e ho anche controllato il vocabolario IEEE. Godere.

Bug e difetti? Lo stesso anche se si può avere una discussione senza fine su questo. Abbiamo davvero altre cose di cui preoccuparsi, la vita è già abbastanza complicata, ecc.

Unesempiodicomeilterminevieneutilizzatoinnatura,da "Come funziona Google Test Software" p. 113. Apri un articolo di "IEEE Software" e viene utilizzato allo stesso modo. In effetti, raramente si incontra la parola "difetto" nella vita reale.

Life of a Bug

Bugs and bug reports are the one artifact every tester understands. Finding bugs, triaging bugs, fixing bugs, and regressing bugs are the heartbeat and workflow for software quality. This is the part of testing that is the most conventional at Google, but there are still a few interesting deviations from the norm. For this section, we ignore the bugs that are filed to track work items and use the term to identify actual broken code. As such, bugs often represent the hour-to-hour and day-to-day workflow for engineering teams.

A bug is born. Bugs are found and filed by everyone at Google. Product Managers file bugs when they catch issues in the early builds that differ form their specifications/thoughts. Developers file bugs when they realize they accidentally checked in an issue, or find an issue somewhere else in the codebase, or while dogfooding Google products. Bugs also come in from the field, from crowd-sourced testers, external vendor testing, and are filed by Community Managers monitoring the product-specific Google Groups. Many internal versions of apps also have quick one-click ways to file bugs, like Google maps. And, sometimes, software programs create bugs via an API.