Sitering av Ilene Burnstein fra boken Praktisk programvaretesting (anbefales) som deler fra definisjonen i» IEEE-standardene Collection for Software Engineering «(1994) og» IEEE Standard Glossary of Software Engineering Terminology «(standard 610.12, 1990):

Feil

En feil er en feil, misforståelse eller misforståelse fra en programvareutviklers side

I kategorien utviklere inkluderer vi programvareingeniører, programmerere, analytikere og testere. For eksempel kan en utvikler misforstå en designnotasjon, eller en programmerer kan skrive et variabelnavn feil.

Feil (Defekter)

En feil (defekt) blir introdusert i programvaren som et resultat av en feil. Det er en avvik i programvaren som kan føre til at den oppfører seg feil, og ikke i henhold til spesifikasjonene.

Feil eller mangler kalles noen ganger «bugs». Bruk av det sistnevnte begrepet bagatelliserer virkningen feilene har på programvarekvaliteten. Bruk av begrepet «defekt» er også assosiert med programvareartefakter som krav og designdokumenter. Feil som oppstår i disse gjenstandene er også forårsaket av feil og oppdages vanligvis i gjennomgangsprosessen.

Feil

En feil er manglende evne til et programvaresystem eller en komponent til å utføre de nødvendige funksjonene innenfor spesifiserte ytelseskrav.

Under kjøring av en programvarekomponent eller et system skal en tester, utvikler, eller brukeren observerer at den ikke gir de forventede resultatene. I noen tilfeller indikerer en bestemt type feil oppførsel at en bestemt type feil er til stede. Vi kan si at typen dårlig oppførsel er et symptom på feilen.En erfaren utvikler / tester vil ha en kunnskapsbase om feil / symptomer / feiltilfeller (feilmodeller som beskrevet i kapittel 3) lagret i minnet. Feil oppførsel kan omfatte å produsere feil verdier for utgangsvariabler, feil respons fra enheten, eller et feil bilde på skjermen. Under utviklingen observeres feil ofte av testere, og feil blir lokalisert og reparert av utviklere.

Du kan lese hele kapittelet i Google Bøker, her .

Det er noen forskjellige begreper relatert til programvarefeil. Utdrag fra et kurs jeg gikk:

• Feil : Menneskelig handling eller utelatelse som resulterer i en feil.

• Feil : Feil er en programvare feil (feil trinn, prosess eller datadefinisjon) som forårsaker en feil.

• Feil : Samme som feil.

• Feil : manglende evne til en programvare til å utføre de nødvendige funksjonene innenfor spesifiserte ytelseskrav.

I følge dette er det ingen forskjell mellom en feil og en feil. Noen mennesker hevder imidlertid at bug er en feil som blir funnet før programvaren ble utgitt, mens feilen er en av kunden.

Jeg kunne ikke motstå å legge ut det berømte, første faktiske tilfellet av feil som ble funnet. «.

Kommentarer

• Endelig noen som har lest: testingstandards.co.uk/bs_7925-1_online.htm
• At ‘ s ikke hvor jeg fikk den fra, men de kan ha en felles kilde (eller denne kan være kilden).
• Ja, for mange, mange år siden brukte jeg en stund på å fikse en feil. Jeg hadde en irriterende flimring i en celle på skjermen, og det ga ingen mening. Den fløy til slutt av. (Dette var i tiden med hvit tekst på en svart skjerm, det aktuelle punktet var langt nok til høyre for å alltid være svart mens Jeg redigerte, så jeg la merke til det bare da programmet la noe hvitt bak.)

Å kjære.

Tilbake i gamle dager – defekt drift av en datamaskin var forårsaket av alle slags ting – inkludert rotter som tygget ledningene og ekte bugs (critters) som kom i gang.

The begrep BUG har sittet fast som et begrep som betyr at noe ikke fungerer som forventet.

BUG bør betraktes som et sjargonguttrykk som betyr en mangel.

En mangel er en teknisk korrekt term som betyr at tingen ikke gjør som den skal.

Når det er mulig, bruker DEFECT i stedet for BUG faktisk en konnotasjon om at vi anerkjenner våre feil (våre mangler, vår manglende forståelse av brukerkrav eller ting vi overså i implementeringen) i stedet for å kle den ut som den mer trivielle klingende «bug».

Bruk DEFEKT.

Prøv å ikke bruke begrepet BUG. Det er dumt, irrelevant, historisk og bagatelliserende.

Kommentarer

• Hvorfor vil du fjerne et godt forstått teknisk begrep fra bruk? Jeg ‘ beklager … ja, BUG er historisk – men hvis du tror at programmerere betrakter feil (generelt sett i motsetning til spesifikk) som trivielle bare fordi de ‘ kalles bugs eller begrepet som irrelevant på grunn av sin opprinnelse, så jeg ‘ er redd for at jeg blir en gretten middelaldrende er helt berettiget. Å og som @Dan påpeker, er feil feil, men defekter er ikke ‘ t nødvendigvis feil, noe som videre antyder at begrepet har verdi.
• @Murph, a » bug » er en eufemisme for en programmeringsfeil. Ubevisst lokker dette til en slags gremlin som utvikleren ikke har kontroll over. Dette er ikke riktig – det er en feil og å erkjenne dette er et skritt mot mer profesjonell atferd. (Imho selvfølgelig :-))
• Erm, helt klart er jeg uenig (-: Jeg vet nøyaktig hvem som er ansvarlig for feilene – koding og logiske feil – som jeg har i koden min. (I ‘ Jeg kan også identifisere feil i andre mennesker ‘ s kode.) Alle programmererne jeg kjenner er klare på hva begrepet betyr – at de ( vel noen programmerer) og ikke noen form for gremlin gjorde en feil.
• Når du har å gjøre med kundene dine, kan du kalle disse tingene bugs, eller defekter. Bugs er sjargong. Defekter er en erkjennelse utenfor sjargongen det er ikke som det burde være. » Defekter » er et begrep som er og oppmuntrer til klar kommunikasjon – også utenfor programmeringsbrorskapet som inne.(Jeg er også uenig i at det er forskjell på en feil og en mangel.)
• Defekter er det rette begrepet. Hvor mange programmer blir utgitt med feil i dem, og vi godtar det alle? Men hvor mange programmer blir utgitt med mangler? Vi vil ikke ‘ t godta det fordi begrepet innebærer en større alvorlighetsgrad, og vi vet at det ‘ er vår egen feil for feilen, heller enn en feil der vi kan klandre været eller tidspunktet på dagen.

Fra IEEE-standarden Ordliste over Software Engineering Terminology, som siteres i Software Engineering Body of Knowledge KA for programvaretesting og programvarekvalitet:

bug. Se: feil; feil.

feil. (1) Forskjellen mellom en beregnet, observert eller målt verdi eller tilstand og den sanne, spesifiserte eller teoretisk korrekte verdien eller tilstanden. For eksempel en forskjell på 30 meter mellom et beregnet resultat og riktig resultat. (2) Et feil trinn, prosess eller datadefinisjon. For eksempel en feil instruksjon i et dataprogram. (3) Feil resultat. For eksempel et beregnet resultat på 12 når riktig resultat er 10. (4) En menneskelig handling som gir et feil resultat. For eksempel en feil handling fra en programmerers eller operatørs side. Merk: Selv om alle fire definisjonene ofte brukes, tilordner ett skille definisjon 1 til ordet «feil», definisjon 2 til ordet «feil», definisjon 3 til ordet «feil» og definisjon 4 til ordet «feil». Se a2so: dynamisk feil; fatal feil; urfolksfeil; semantisk feil; syntaktisk feil; statisk feil; forbigående feil.

feil. Manglende evne til et system eller en komponent til å utføre sine nødvendige funksjoner innenfor spesifiserte ytelseskrav. Merk: Feiltoleransedisiplinen skiller mellom en menneskelig handling (en feil), dens manifestasjon (en maskinvare- eller programvarefeil), resultatet av feilen (en feil) og mengden resultatet er feil (feilen). Se også: krasj; avhengig feil unntak; feil modus; strykprosent; hard feil; begynnende feil uavhengig svikt; tilfeldig svikt; myk svikt; fast feil.

feil. (1) En feil i en maskinvareenhet eller komponent; for eksempel kortslutning eller ødelagt ledning. (2) Feil trinn, prosess eller datadefinisjon i et dataprogram. Merk: Denne definisjonen brukes primært av feiltoleranse. I vanlig bruk brukes begrepene «feil» og «feil» for å uttrykke denne betydningen. Se også: datasensitiv feil; programfølsom feil; tilsvarende feil; feilmaskering; intermitterende feil.

Jeg tror definisjonen av feil er den mest relevante. Alt begynner med en feil, enten det er i kravene, designet, implementeringen eller testsaken / prosedyren. Hvis denne feilen manifesteres i programvare, blir det en feil. En feil skyldes eksistensen av en eller flere flere feil i programvaren.

Jeg er imidlertid ikke opptatt av den formelle definisjonen av feil. Jeg foretrekker veldig mye definisjonen gitt av dukeofgaming i hans svar , men den i dette svaret er IEEE-standarddefinisjonen av feil.

Dan McGraths svar spikret det riktig.

• En feil er resultatet av en kodefeil
• En feil er et avvik fra kravene

Kanskje et eksempel vil gjøre det tydeligere.

Eksempel: Kunden ønsket at webskjemaet skulle kunne lagre og lukke vinduet.

Scenario nr. 1: Webskjema har en lagringsknapp og en annen lukkeknapp. Resultat: Defekt, fordi klienten ønsket at 1-knappen skulle lagre og lukke vinduet. Utvikler misforstått og opprettet separat. Fordi begge knappene utførte sine krav, er det ikke en feil, men en feil fordi den ikke oppfyller klientens krav.

Scenario # 2: Webskjema har en lagring & lukkeknapp, men bare lagrer men lukkes ikke. Resultat: Feil. Fordi knappen ikke fungerer som ønsket / forventet. Utvikler vet at det er antatt å produsere det resultatet, men til slutt gjorde det ikke. (Kanskje kodingsfeil)

Ikke sikker på om dette gjør det tydeligere.

p / s: fra en utvikler standpunkt (jeg var en gang), både mangler og feil er like viktige. Vi vil fortsatt fikse det.

Vi opplevde til og med rare avvik, som vi kategoriserte under feil, og vi prøver kontinuerlig å finne ut hva er årsaken og hvordan du fikser det. Å kalle det feil gjør det ikke trivielt i forhold til mangler.

Kommentarer

• Hva kaller vi feilkrav?
• @ gnasher729 hvis du med feilkrav mente at programmererne misforsto kravene, så ville jeg tro at det ‘ er en feil. Men hvis du mente feil krav da brukeren som oppga feil krav som resulterer i det endelige arbeidet ikke løser det opprinnelige problemet, så er det utenfor feil og mangler, da dette er et problem med kravsamlingsøkten snarere enn med utviklingen.

Her er en jeg gjorde tidligere for min arbeidsgiver Q-LEAP basert på ISTQB-ordforrådet, og jeg sjekket også IEEE-vokabularet. Nyt.

Feil og feil? Det samme selv om man kan ha uendelig diskusjon om dette. Vi har virkelig andre ting å bekymre oss for, livet er allerede komplisert nok osv.

Et eksempel på hvordan begrepet brukes i naturen, fra «Hvordan Google tester programvare» s. 113. Åpne en artikkel av «IEEE Software» og den brukes på samme måte. Man møter faktisk sjelden ordet «defect» i det virkelige liv.

Life of a Bug

Bugs og bug-rapporter er den gjenstanden hver tester forstår. Å finne bugs, triaging bugs, fikse bugs og regressing bugs er hjerteslag og arbeidsflyt for programvarekvalitet. Dette er den delen av testingen som er den mest konvensjonelle hos Google, men det er fortsatt noen få interessante avvik fra normen. For denne delen ignorerer vi feilene som arkiveres for å spore arbeidselementer og bruker begrepet for å identifisere faktisk ødelagt kode. Som sådan representerer feil ofte den timevis og daglige arbeidsflyten for ingeniørteam.

En feil blir født. Feil blir funnet og arkivert av alle på Google. Produkt Ledere arkiverer feil når de får problemer i de tidlige versjonene som er forskjellige fra spesifikasjonene / tankene deres. Utviklere registrerer feil når de innser at de ved et uhell sjekket inn et problem, eller et problem et annet sted i kodebasen, eller mens du nærer Google-produkter. Feil kommer også fra feltet, fra testere fra folkemengder, testing av eksterne leverandører, og arkiveres av fellesskapsledere som overvåker de produktspesifikke Google-gruppene. Mange interne versjoner av apper har også raske ett-klikk-måter å arkivere feil på, for eksempel Google maps. Noen ganger oppretter programvarefeil via et API.

Forskjellen er at begrepet «bug» høres magisk ut. Som om et program tilfeldig kan ha feil i det etter at du er ferdig med å programmere. Hvis det har tilfeldige feil, betyr det at du ikke samsvarte med spesifikasjonene, og programmet ditt er feil.

En feil betyr en feil der programmet ikke samsvarer med spesifikasjonene. Dette er mer alvorlig og sier i utgangspunktet enhver feil er et stort problem med programmet, og dette betyr at programmet er ikke egnet til å bli utgitt.

Forskjellen er i holdningen til programmererne som bruker vilkårene. Det er millioner av programmer som blir utgitt med feil, og folk har det bra fordi de godtar av en eller annen grunn at en feil er magisk og tilfeldig, og at hvert program inneholder minst en feil. Imidlertid kan en programmerer som bruker begrepet «defekt» bli ubehagelig med å gi ut et program med en feil fordi begrepet innebærer en større alvorlighetsgrad.

Implikasjonene av å foretrekke ett begrep fremfor det andre påvirker oss daglig.

Utenfor den spesifikke feilen / oppgaven / billetten / defekten / problemet / uansett hvilken sporingssysteminstans disse ordene ikke har noen eksakt betydning, og det er derfor meningsløst å diskutere forskjell mellom dem. Når du gjør opp arbeidsflyten din, bør du ordne terminologien og gi beskrivelser.

I mitt nåværende miljø er en «defekt» noe element i Jira. Ser ut som om Jira selv bruker begrepet «problem». Vi har kanskje arvet det fra et tidligere system.»Feil» er en type problem når noe ikke fungerer som forventet og beskrevet i dokumentasjonen. «Funksjonsforespørsel» når noe fungerer som forventet, men impvovement er ønsket (det kan være åpenbart og viktig, men hvis den aktuelle oppførselen blir beskrevet, er det fortsatt en funksjonsforespørsel). Det er flere typer, men de to brukes av folk utenfor utviklingsteamet til å spørre noe om det.

Hvis du velger navn for problemtyper, høres «bug» og «defect» ut som meg. Forskjellen mellom dem er stilistisk. Siden engelsk ikke er morsmålet mitt, kan jeg ikke se mye av det, og jeg er ikke sikker på om det jeg ser er riktig.