Aktualizované august 28, 2019
Odkedy bol softvér vyvinutý, testovanie sa široko používa ako súčasť vývoja softvéru. Business Intelligence (BI) však pomalšie prijíma testovanie ako integrovanú súčasť vývoja v softvéri BI, akým je napríklad IBM Cognos. Pozrime sa, prečo BI pomalšie preberá testovacie postupy a dôsledky NIE JE Testovanie.
Prečo organizácie netestujú BI…
- Časové obmedzenia. BI projekty sú pod neustálym tlakom, aby boli dodávané rýchlejšie. Niektoré organizácie si možno neuvedomujú, že najľahšou fázou na skrátenie času je testovanie.
- Obmedzenia rozpočtu. Myslíme si, že testovanie je príliš drahé a nemôže venovať testovací tím.
- Rýchlejšie je lepšie. Nie je to nevyhnutne „agilný“ prístup a môže vás len rýchlejšie dostať na nesprávne miesto.
- Mentalita „jednoducho to urobte správne prvýkrát“. Tento naivný prístup trvá na tom, že prítomnosť kontroly kvality by mala znížiť potrebu testovania.
- Nedostatok vlastníctva. Je to podobné ako v predchádzajúcej guľke. Myslíme si, že „naši používatelia to vyskúšajú“. Tento prístup môže viesť k nešťastným používateľom a množstvu lístkov na podporu.
- Nedostatok nástrojov. Mylná predstava, že nemajú správnu technológiu na testovanie.
- Nedostatočné porozumenie testovaniu. Napríklad,
- Testovanie by malo vyhodnotiť presnosť a platnosť údajov, konzistenciu údajov, aktuálnosť údajov, výkonnosť doručenia a jednoduchosť použitia mechanizmu doručovania.
- Testovanie počas projektu BI môže zahŕňať regresné testovanie, testovanie na jednotke, testovanie dymu, testovanie integrácie, testovanie akceptácie používateľom, testovanie ad hoc, testovanie stresu/škálovateľnosti, testovanie výkonu systému.
Aké sú náklady na NETESTOVANIE BI?
- Neefektívne prevedenie. Ak testovanie ignorujete, nemusí byť nájdená zlá architektúra. Problémy s dizajnom môžu prispieť k použiteľnosti, výkonu, opätovnému použitiu, ako aj k údržbe a údržbe.
- Problémy s integritou údajov. Problémy s poškodením údajov alebo dátovým radom môžu viesť k nedostatku dôvery v čísla.
- Problémy s overovaním údajov. Rozhodnutia o zlých údajoch môžu byť pre firmu zničujúce. Nie je nič horšie, ako sa snažiť spravovať pomocou metrík, ktoré sú založené na nesprávnych informáciách.
- Znížené prijatie používateľom. Ak čísla nie sú správne alebo ak aplikácia nie je užívateľsky prívetivá, vaša používateľská komunita váš lesklý nový podnikový softvér BI jednoducho nepoužije.
- Zvýšené náklady z dôvodu nedostatku štandardizácie.
- Zvýšené náklady na opravu defektov v neskorších fázach životného cyklu vývoja BI. Akékoľvek problémy objavené nad rámec fázy požiadaviek budú stáť exponenciálne viac, ako keby boli odhalené skôr.
Keď sme už vysvetlili, prečo organizácie nemusia testovať a aké úskalia sa môžu vyskytnúť, keď netestujete BI, pozrime sa na niekoľko štúdií o testovaní vo vývoji softvéru.
Štúdie Ukážka Testovanie vašej platformy BI šetrí peniaze!
Jedna štúdia 139 severoamerických spoločností Rozsah veľkosti od 250 do 10,000 5.2 zamestnancov hlásil ročné náklady na ladenie od 22 milióna do XNUMX miliónov dolárov. Tento rozsah nákladov odráža organizácie, ktoré nie mať zavedené automatizované testovanie jednotiek. Samostatne to zistil výskum spoločností IBM a Microsoft s zavedenie automatizovaného testovania jednotiek, počet defektov je možné znížiť o 62% až 91%. To znamená, že doláre vynaložené na ladenie by bolo možné znížiť z rozsahu 5 miliónov až 22 miliónov dolárov na rozsah 0.5 milióna až 8.4 milióna dolárov. To je obrovská úspora!
Náklady na rýchlu eskaláciu chýb.
Príspevok o úspešných taktikách vývoja softvéru ukazuje, že väčšina chýb sa robí na začiatku vývojového cyklu a že čím dlhšie čakáte na odhalenie a opravu, tým vyššie sú náklady na opravu. Nie je teda potrebný raketový vedec, aby dospel k evidentnému záveru, že čím skôr sú chyby odhalené a opravené, tým lepšie. Keď už hovoríme o raketovej vede, stáva sa, že NASA zverejnila dokument práve o tom - „Eskalovanie nákladov na chyby počas životného cyklu projektu.“
Je intuitívne, že náklady na opravu chýb sa zvyšujú s postupujúcim životným cyklom vývoja. Štúdia NASA bola vykonaná s cieľom zistiť, ako rýchlo postupujú relatívne náklady na odhalené chyby pri odstraňovaní. Táto štúdia použila tri prístupy na určenie relatívnych nákladov: metóda nákladov zdola nahor, metóda rozdelenia celkových nákladov a metóda hypotetického projektu zhora nadol. Prístupy a výsledky opísané v tomto článku predpokladajú vývoj hardvérového/softvérového systému s podobnými projektovými vlastnosťami, aké sa používajú pri vývoji veľkých, komplexných vesmírnych lodí, vojenských lietadiel alebo malých komunikačných satelitov. Výsledky ukazujú, do akej miery sa náklady stupňujú, pretože chyby sa zisťujú a opravujú v neskorších a neskorších fázach životného cyklu projektu. Táto štúdia predstavuje ďalší výskum, ktorý bol vykonaný.
Z vyššie uvedeného grafu ukazuje výskum spoločností TRW, IBM, GTE, Bell Labs, TDC a ďalších náklady na opravu chýb počas rôznych fáz vývoja:
- Náklady na opravu chyby zistenej počas fázy požiadaviek sú definované ako 1 jednotka
- Náklady na opravu tejto chyby, ak sa zistia vo fáze návrhu, sú zdvojnásobiť Že
- Vo fáze kódu a ladenia sú náklady na opravu chyby 3 jednotky
- Vo fáze testovania a integrácie jednotky vznikajú náklady na opravu chyby 5
- Vo fáze testovania systémov, náklady na opravu chyby sa zvýšia na 20
- A akonáhle je systém vo fáze prevádzky, relatívne náklady na opravu chyby sa zvýšili na 98, čo je takmer 100 -násobok nákladov na opravu chyby, ak sa zistí vo fáze požiadaviek!
Pointa je, že oprava defektov je oveľa drahšia, ak nie sú zachytené včas.
Závery
Bol vykonaný významný výskum, ktorý ukazuje hodnotu včasného a nepretržitého testovania vo vývoji softvéru. My, v komunite BI, sa môžeme pri vývoji softvéru učiť od našich priateľov. Napriek tomu, že väčšina formálneho výskumu bola vykonaná v súvislosti s vývojom softvéru, je možné vyvodiť podobné závery o vývoji BI. Hodnota testovania je nespochybniteľná, ale mnohé organizácie pomalšie využívajú výhody formálneho testovania svojho prostredia BI a integrujú testovanie do svojich procesov vývoja BI. Náklady na nie testovanie je skutočné. Riziká spojené s nie testovanie je skutočné.
Chcete vidieť nejaké automatické testovanie Cognos v prevádzke? Pozrite si videá v našom zozname skladieb od kliknutím tu!
