Frissítve augusztus 28, 2019
A tesztelést a szoftverfejlesztés óta széles körben alkalmazzák a szoftverfejlesztés részeként. Az Business Intelligence (BI) azonban lassabban fogadta el a tesztelést a BI szoftver, például az IBM Cognos fejlesztésének integrált részeként. Vizsgáljuk meg, hogy a BI miért lassabban fogadta el a tesztelési gyakorlatokat és ennek következményeit NEM tesztelés.
Miért nem tesztelik a szervezetek a BI -t…
- Időkorlátok. A BI projektek állandó nyomás alatt vannak, hogy gyorsabban lehessen őket megvalósítani. Amit egyes szervezetek talán nem vesznek észre, az az, hogy a legegyszerűbben lezárható szakasz a tesztelés.
- Pénzügyi megszorítások. A gondolkodás az, hogy a tesztelés túl drága, és nem tud kijelölni egy tesztelő csoportot.
- A gyorsabb jobb. Ez nem feltétlenül „agilis” megközelítés, és lehet, hogy csak gyorsabban vezet rossz helyre.
- A „csak először jól csináld” mentalitás. Ez a naiv megközelítés ragaszkodik ahhoz, hogy a minőség -ellenőrzés jelenléte csökkentse a tesztelés szükségességét.
- A tulajdon hiánya. Ez hasonló az előző ponthoz. A gondolkodás az, hogy „felhasználóink tesztelni fogják”. Ez a megközelítés boldogtalan felhasználókhoz és sok támogatási jegyhez vezethet.
- Eszközök hiánya. Az a tévhit, hogy nincs megfelelő technológiájuk a teszteléshez.
- A tesztelés megértésének hiánya. Például,
- A tesztelésnek értékelnie kell az adatok pontosságát és érvényességét, az adatok következetességét, az adatok időszerűségét, a szállítás teljesítményét és a kézbesítési mechanizmus egyszerű használatát.
- A BI -projekt során végzett tesztelés tartalmazhat regressziós tesztelést, egységtesztelést, füstvizsgálatot, integrációs tesztet, felhasználói elfogadási tesztet, eseti tesztelést, stressz-/skálázhatósági tesztet, a rendszer teljesítményének tesztelését.
Mennyibe kerül a BI tesztelésének hiánya?
- Nem hatékony tervek. A tesztelés figyelmen kívül hagyása esetén előfordulhat, hogy a rossz architektúra nem fedezhető fel. A tervezési problémák hozzájárulhatnak a használhatósághoz, a teljesítményhez, az újrafelhasználáshoz, valamint a karbantartáshoz és karbantartáshoz.
- Adatintegritási problémák. Az adatkorrupció vagy az adatvonalak kihívásai a számokba vetett bizalom hiányához vezethetnek.
- Adatellenőrzési problémák. A rossz adatok alapján hozott döntések pusztítóak lehetnek az üzlet számára. Nincs rosszabb annál, mint ha helytelen információkon alapuló mutatókkal próbál kezelni.
- Csökkent felhasználói elfogadottság. Ha a számok nem megfelelőek, vagy ha az alkalmazás nem felhasználóbarát, a felhasználói közösség egyszerűen nem fogja használni a fényes új vállalati BI szoftvert.
- Megnövekedett költségek a szabványosítás hiánya miatt.
- Megnövekedett költségek a hibák kijavítására a BI fejlesztési életciklusának későbbi szakaszaiban. A követelmények szakaszán túl felfedezett problémák exponenciálisan többe kerülnek, mint korábban.
Most, hogy leírtuk, miért nem tesztelik a szervezetek, és milyen buktatók merülnek fel, ha nem teszteli a BI -t, nézzünk meg néhány tanulmányt a szoftverfejlesztés teszteléséről.
Tanulmányok azt mutatják, hogy a BI platform tesztelése pénzt takarít meg!
Egy tanulmány 139 észak -amerikai vállalatról 250 és 10,000 5.2 alkalmazott között, éves hibakeresési költsége 22–XNUMX millió dollár. Ez a költségtartomány azt a szervezetet tükrözi, amely nem automatikus egységvizsgálatot hajtottak végre. Külön az IBM és a Microsoft kutatásai azt találták val vel automatizált egység tesztelés esetén a hibák száma 62% és 91% között csökkenthető. Ez azt jelenti, hogy a hibakeresésre fordított dollárt 5 millió dollárról 22 millió dollárra csökkenthetjük 0.5 millió dollárról 8.4 millió dollárra. Ez óriási megtakarítás!
A hibák gyors javításának költségei nőnek.
Dokumentum a sikeres szoftverfejlesztési taktikáról azt mutatja, hogy a legtöbb hiba a fejlesztési ciklus elején következik be, és minél tovább vár az észlelésre és kijavításra, annál magasabb költségekkel jár a javítás. Tehát nem kell egy rakétakutatónak levonnia azt a nyilvánvaló következtetést, hogy minél hamarabb felfedezik és kijavítják a hibákat, annál jobb. Ha már a rakéta tudományáról beszélünk, akkor a NASA éppen erről adott ki egy dokumentumot - „Hiba -költségek növekedése a projekt életciklusa során.”
Érthető, hogy a hibák kijavításának költségei a fejlesztési életciklus előrehaladtával nőnek. A NASA tanulmányát annak érdekében határozták meg, hogy a felfedezett hibák kijavításának relatív költsége milyen gyorsan halad előre. Ez a tanulmány három megközelítést alkalmazott a relatív költségek meghatározására: az alulról felfelé irányuló költség módszer, a teljes költségmegosztási módszer és a felülről lefelé irányuló hipotetikus projekt módszer. Az ebben a cikkben ismertetett megközelítések és eredmények olyan hardver/szoftver rendszer kifejlesztését feltételezik, amelynek projektjei hasonlóak a nagy, összetett űreszközök, katonai repülőgépek vagy kis kommunikációs műholdak fejlesztésében használthoz. Az eredmények azt mutatják, hogy a költségek milyen mértékben nőnek, mivel a hibákat a projekt életciklusának későbbi és későbbi fázisaiban fedezik fel és javítják. Ez a tanulmány reprezentálja az egyéb kutatásokat, amelyeket eddig végeztek.
A fenti táblázatból a TRW, az IBM, a GTE, a Bell Labs, a TDC és mások kutatása mutatja a hibák kijavításának költségeit a különböző fejlesztési fázisokban:
- A követelmények szakaszában felfedezett hiba kijavításának költsége a következő 1 egység
- A hiba kijavításának költsége, ha a tervezési fázisban található kétszeresére hogy
- A kód- és hibakeresési szakaszban a hiba kijavításának költsége 3 egységek
- Az egység tesztelési és integrálási fázisában a hiba kijavításának költségei nőnek 5
- A rendszer tesztelési fázisában, a hiba kijavításának költsége 20 -ra ugrik
- És ha a rendszer az üzemi fázisban van, a hiba kijavításának relatív költsége 98 -ra emelkedett, közel 100 -szorosa a hiba kijavításának, ha a követelmények szakaszában találják!
A lényeg az, hogy sokkal drágább a hibák kijavítása, ha nem észlelik őket korán.
Következtetések
Jelentős kutatásokat végeztek, amelyek bizonyítják a korai és folyamatos tesztelés értékét a szoftverfejlesztésben. Mi, a BI közösségben, tanulhatunk a barátainktól a szoftverfejlesztésben. Annak ellenére, hogy a legtöbb hivatalos kutatás szoftverfejlesztéssel kapcsolatos, hasonló következtetéseket lehet levonni a BI fejlesztésről. A tesztelés értéke vitathatatlan, de sok szervezet lassabban használta ki a BI környezetének formális tesztelését, és integrálta a tesztelést a BI fejlesztési folyamataiba. A költségek nem a tesztek valódiak. A kapcsolódó kockázatok nem a tesztek valódiak.
Szeretné látni néhány automatikus Cognos tesztelést működés közben? Nézze meg a lejátszási listánkban található videókat ide kattintva!
