Mi a bug?

Az informatikában gyakran hallani a “bug” kifejezést, illetve azt, hogy egy program “bug-os”. A bugok bosszantóak, senki sem örül nekik, sem a létrehozói, sem pedig a felhasználói oldalon. Mi is a “bug”? Az elnevezés az IT világban programhibára vonatkozik, amely az adott számítógépes program és/vagy eszköz nem megfelelő működését eredményezi. Az angol “bug” szó bogarat jelent, azonban ne arra gondoljunk, hogy a hibát ténylegesen bogarak okozzák. Valójában rendszerint emberi tévesztés, a forráskódban vagy a programstrukúrában elkövetett tévesztés áll a háttérben.

Mielőtt bővebben kitérünk ezen hibák fajtáira, kihatásaira, a tesztelés fontosságára, először jöjjön a teljesség kedvéért egy rövidke ismertető magáról a szóról.

Hogyan alakult ki, hogy a bug szót használjuk a hibára?

Biztosra mondható, hogy a szó már több mint 150 éve használatban van a mérnöki szakzsargonban gépek, elektronikai berendezések tervezésben, gyártásban vagy működésben bekövetkezett, a működést akadályozó hibák jelölésére. Hogy néhány példát említsünk: Thomas Edison egyik 1878-ban, találmányaival kapcsolatos levelében is már használta a kifejezést. 1931-ben a világ első flippergépet garantáltan “bug-mentesként” reklámozták. A második világháborúban katonai felszerelések hibás működésével kapcsolatban is gyakorta volt használatos a bug szó.

Mint sok egyéb más kifejezéssel is történt, idővel ez a szó is átszivárgott a mérnöki szaknyelvből az informatikába.
Sokan a számítógépes programozás egyik úttörőjének számító amerikai hölgynek, Grace Hoppernek és csapatának tulajdonítják a szó informatikai használatának kezdetét. A ‘40-es években a Mark I, illetve II elnevezésű számítógépek létrehozásán dolgoztak a Harvard egyetemen. 1947-ben meghibásodott az egyik számítógép. A reléi közül egy elpusztult molylepke került elő. A lepkét óvatosan kiemelték, beragasztották a fejlesztési naplóba azzal a kétértelmű és kissé tréfás megjegyzéssel dokumentálva, hogy "First actual case of bug being found." A beírás magyarul körülbelül annyit tesz, hogy “Az első tényleges eset, amikor bogarat / hibát találtunk”. A híressé vált lepke ma is megvan, csakúgy mint a szóhasználat.

(Az első "dokumentált" bug. Forrás: Wikipedia)

A bugok fajtái

Összetett programozási feladatok esetében, különösen, ha több programozó dolgozik egy feladaton - bármennyire is gondosan járnak el - előfordul, hogy egy-egy kisebb vagy nagyobb bug marad a kódban. Van, amikor könnyen felfedezhetőek, de bizony előfordul, hogy kifejezetten nehéz az okot megtalálni.

A bug-ok többféle szempont szerint is csoportosíthatóak. Érdemes ezeken végigmenni, hogy lássuk szeretágazó mibenlétüket és hatásukat.

A legtipikusabb bugok

Logikai bug
A scriptben lévő logikai következetlenség vagy ütközés okozhat olyan helyzetet, hogy a program ugyan lefut, de rossz információt ad ki, vagy akár le sem fut, elakad, és nem ad ki kimenetet. A logikai bug tipikus példája az ún. infinite loop, vagyis a végtelen ciklus, amikor egy kódsorozat folyamatosan újra és újra lefut, nem áll le. Ilyen esetben meg kell találni a logikailag hibás feltételt és javítani.

Számítási bug
Ezek a bugok matematikai, műveleti hibák, amelyek miatt a kód nem működik megfelelően. (Például az Intel Pentium egyik szériája úgy került piacra, hogy a lebegőpontos számítási műveletekben rossz eredményt adott. A cég kénytelen volt a terméket visszahívni.)

Szintaktikai bug
Ezek a hibák nem megfelelő karakterhasználatból vagy egyszerűen csak elgépelésből származnak. Minden programozási nyelvnek eltérő szintaxisa van. Ha a megkövetelt szintaxistól eltér a programozó - néha akár csak egyetlen karakter elgépelésével -, akkor hibás, “bug”-os lesz a szoftver.

Interface bug
Ilyen akkor fordul elő, ha egymással inkompatibilis rendszerek találkoznak.

Kommunikációs bug
Ha valamilyen okból félremegy a kommunikáció a programozók között és nem egészen pontos a feladatmeghatározás vagy a kommentek megfogalmazása, az könnyen hibás eredményt adhat. Ez egyszerűen csak azt jelenti, hogy a szoftver - látszólag - hibátlan. Azonban a működés nem az eredeti célt valósítja meg.

Ha a felhasználó szemszögéből nézzük a bug-ok fajtáit, leginkább kétféle hibacsoportot szokás említeni:

Mit érint a hiba: látványt vagy működést?

• Működési bug, ha a például a felhasználó kattint egy gombra (pl. Tovább, Mentés, Feltöltés, Fizetés stb.) és nem történik meg a szándékolt, elvárt lépés.
• Látványt érintő, azaz vizuális bugról beszélünk, ha lefut ugyan a kívánt funkció, de vizuálisan nem követi a szoftver a működést. Ennek legegyszerűbb példája, amikor lefut egy funkció, de a képernyőn nem látszik, hogy megtörtént.

Mennyire zavaró a hiba a felhasználó számára?

• A kis kihatású (low-impact) bug a felhasználó élményt némileg zavarja, de magát a működést nem akadályozza. Nevezhetjük “nem szép, de még elmegy” kategóriának. Természetesen olyan esetekben, ahol a felhasználói élmény minden mozzanata különösen fontos, ezen apró hibák is feltétlenül javítást igényelnek.
• A nagy kihatású (high-impact) bug jelentősen kihat a működésre, de összességében maga a szoftver még használható marad.
• A kritikus hiba lehetetlenné teszi a használatot

Tesztelés, debugging

Komolyabb fejlesztési projekteknek (pl. operációs rendszer fejlesztés, app fejlesztés) alapvető és elengedhetetlen fázisa a debugging, vagyis célzottan a hibakeresés, tesztelés.

A hibakeresést egyes kódegységek megírása után kezdik a szoftvertesztelők, és a folyamat szisztematikusan, szakaszosan folytatódik, míg végül a termék kiadásra kerül.

Szintén bevett eljárás az ún. nyilvános béta-tesztelés, vagyis a még nem nyilvánosságra hozott szoftverek előzetes teszteltetése a célközönség egy speciálisan kiválasztott részével. A felhasználók tapasztalati nagy segítséget adnak ilyenkor abban, hogy láthatóvá váljanak olyan bugok, amik tényleges felhasználói környezetben, valódi munkavégzés, játék stb. során mutatják meg magukat.

Előfordul persze, hogy bizonyos bugok csak a termék piacra kerülése után derülnek ki. Ilyenkor bizonyos esetekben patch-ekkel orvosolható a helyzet. (De ahogy lentebb máris látni fogjuk, pl. gépjárműbe épített op rendszer esetében a távoli patch-elés nem megoldható, ott csak a termékvisszahívás marad.)

Aprócska bug - óriási következmények

Számos olyan eset vált ismertté, amikor egy bug igen nagy problémát okozott. Példaként íme néhány:

1962-ben igen nagy meglepetést okozott a Mariner I űrszonda, ugyanis fellövés után egyáltalán nem arra indult, amerre tervezték. Mint utólag kiderült, a kalkulációk papíron helyesek voltak, azonban a vezérlő számítógép rosszul fordította le formulát. A tévútra tévedt szondát végül kénytelenek voltak az óceán felett megsemmisíteni.

Szintén elhíresült eset a 80-as évek második feléből egy sugárkezelésre használt, bugos kórházi eszközzel (Therac-25) kapcsolatos. A berendezés programozási hibából adódóan sajnálatos módon túl nagy dózisokat adott és öt ember halált okozta.

Sokan emlékezhetnek, hogy 2005-ben a Toyota 160.000 Priust volt kénytelen visszahívni, mert az „okos-autó” operációs rendszerében lévő szoftver bug működést lehetetlenné tevő hibákat okozott (figyelmeztető lámpák indokolatlan villogása, motorleállás.) Bosszantó, blama és nem mellesleg szép kis anyagi veszteség. De akár említhetnénk az Intel Pentiumot is, nekik 475 millió dollárjukba került a mintegy ötmillió, számítási bugos chipjük visszahívása.

Gondolhatunk persze a hírekbe kerülő, önvezető autókkal kapcsolatos esetekre is. Például amikor a szoftver szembefényben nem vette észre a fehér járművet és baleset lett a vége.

***

Ha érdekel a téma és szívesen foglalkoznál szoftverhibák felderítésével, vagyis annak vizsgálatával, hogy mások mit és hol rontottak el, mi miért nem működik vagy nem jól működik, érdemes megnézd Szoftvertesztelő képzésünk leírását.