Hiba, bug és típusai a fejlesztésben és a változtatási kérelem
Valószínűleg ön is, mint bármely cég/megrendelő találkozott már a weboldala webalkalmazása fejlesztése során hibával, vagy legalább gondolta már úgy, hogy azzal találkozott. Nagyon fontos, hogy különbséget tudjunk tenni hiba és hiba között, illetve hiba és CR (változtatási kérelem) között.
Először is mi a hiba, mettől számít valami hibának? Nyilván nem tudunk mindent leírni a fejlesztőnek, hogy itt se dobjon hibát az oldal, és amott se egy üres fehér oldallal térjen vissza az alkalmazás, de szerencsére nem is kell. Ezek egyértelmű elvárások, melyekkel minden valamire való fejlesztő tisztában van. Nem próbálnak meg minden karakter leütésért CR-t felvetetni, hiszen egyértelmű, hogy egy-egy felhazsnálói interakió után az elvárt a normális, felhazsnálót támogató működés.
Lényegében minden olyan működés az elkészült fejlesztésben, legyen az akár weboldal vagy alkalmazás, amelyre szólóan van definiálva előzetesen egy elvárás, és annak nem tesz eleget, hiba. Nem szükséges tényleges hibának lennie, elég ha eltér az előzetesen megbeszéltektől (!és írásban rögzített, elfogadott) elvárásoktól - minden olyan működés azonban (megfordítva ezt a gondolatmenetet), amelyre vonatkozóan nincs definiált, leírt működési elvárás, nem tekinthető hibának. A nem definiált működésekkel kapcsolatban, vagy egy a működés MVP-jének elkészülte után, vagy annak teljes elkezdése előtt szükséges tisztázni a (további) részleteket....Erről hamarosan lesz még egy bejegyzésünk.
A hibákra visszatérve azonban, a szerintünk legfontosabb hiba-kategóriát egy-két mondatos leírással nemutatjuk önöknek. Reméljük segítségükre lesz a közeljövőben a hibák kategorizálásában, értelmezésében.
- Kritikus:
- A kritikus hibák minimum egy adott oldalt, de akár az egész site-ot vagy az üzleti igény végrehajthatóságát blokkolhatják/elérhetetlenné/funkciója ellátására képtelenné tehetik, valamilyen módon blokkolják tehát a felhasználót a weboldal megfelelő, üzleti igényekben megfogalmazott működésének gyakorlásától. Ezekben az eseteben nincs apelláta, azonnal szólni kell a fejlesztő(k)nek, akár cég, akár magánszemély, és azonnal el kell kezdeni dolgozni a hiba javításán, hiszen ez párezrestől, akár több millió forintig terjedő kárt is okozhat a weboldal tulajdonosának.
- Fontos, de nem kritikus:
- Ezek jellemzően olyan működésekben fellépő hibák, melyek nem befolyásolják, vagy nem jelentősen (ez szubjektív megítélésen alapul) / csak kis mértékben az üzleti eredményeket. Ez lehet gyakorlatilag bármi ami nem gátolja a felhasználót, illetve nem ijeszti el. Ezek a hibák nem SOS jellegűek ugyan, de szintén fontos a javításuk minél rövidebb időn belül, már csak a felhasználói élmény (UX - user experience) miatt. Lehet, hogy ugyan nem ijeszti el rövid távon a felhasználót egy-egy apróság, de a folyamatos kényelmetlenség hosszútávon megakadályozhatja a későbbiekben való, újbóli látogatástól / vásárlástól.
- Kis mértékben eltérő/"hibás" működés:
- Ezek a hibák a legkevésbé jelentenek ugyan problémát, de természetesen szintén pozitív a minél rövidebb időn belüli javításuk. Ilyen jellegű hibák esetében nem olyan fontos már az azonnali közbeavatkozás, persze itt is érdemes a működést mielőbb a megfelelő mederbe terelni, hiszen a jó UX pozitív tapasztalatokat jelent, és talán visszatérő felhasználókat.
Sokféleképpen lehet még a hibákat kategorizálni, például gyakran blocker - a felhasználót valamilyen folyamatban blokkoló - ; és white/blank page (fehér/üres oldal) - azaz valamilyen oldalon az elvártal ellentétben egy üres, fehér oldal jelenik meg - kategorizálást is használnak, melyek szintén utalnak a hiba természetére.
Akármilyen módon kategorizáljuk, vagy csak írjuk körül a hibát, a legfontosabb, hogy a lehető legpontosabb leírást tudjuk átadni a fejlesztőknek, hogy ezáltal növeljük, segítsük munkájukat a hiba természetének feltárásában és kijavításában.
Sok szerencsét az elvárt működések, és hibák meghatározásában!
Szerző: Dombi István
2010 óta fogalkozom webfejlesztéssel, az egyszerű céges weboldalaktól kezdve az e-kereskedelmi platformokon és különböző API integrációkon át (fizetési átjárók és egyéb harmadik féltől származó APIk), egészen a nemzetközi komplex webalkalmazásokig gyakorlatilag mindenféle projekten volt már szerencsém dolgozni. Fő stack-em a backend fejlesztés, azon belül PHP és a GO nyelv.