Aktualizováno v srpnu 28, 2019
Testování bylo široce přijato jako součást vývoje softwaru od doby, kdy byl software vyvinut. Business Intelligence (BI) však pomalu přijímá testování jako integrovanou součást vývoje v softwaru BI, jako je IBM Cognos. Pojďme prozkoumat, proč BI pomalu přijímala testovací postupy a důsledky NENÍ testování.
Proč organizace netestují BI…
- Časová omezení. BI projekty jsou pod neustálým tlakem, aby byly doručovány rychleji. Některé organizace si možná neuvědomují, že nejjednodušší fází zkrácení času je testování.
- Omezení rozpočtu. Myšlení je, že testování je příliš drahé a nemůže věnovat testovací tým.
- Rychlejší je lepší. Nejde nutně o „agilní“ přístup a může vás jen rychleji dostat na špatné místo.
- Mentalita „udělej to hned napoprvé“. Tento naivní přístup trvá na tom, že přítomnost kontroly kvality by měla snížit potřebu testování.
- Nedostatek vlastnictví. Je to podobné jako u předchozí kulky. Myšlenka je taková, že „naši uživatelé to otestují“. Tento přístup může vést k nešťastným uživatelům a spoustě lístků podpory.
- Nedostatek nástrojů. Mylná představa, že nemají správnou technologii pro testování.
- Nedostatek porozumění testování. Například,
- Testování by mělo vyhodnotit přesnost a platnost dat, konzistenci dat, aktuálnost dat, výkonnost doručení a snadné použití mechanismu doručování.
- Testování během projektu BI může zahrnovat regresní testování, testování jednotek, testování kouře, testování integrace, testování přijatelnosti uživatelem, testování ad hoc, testování stresu/škálovatelnosti, testování výkonu systému.
Jaké jsou náklady na NETESTOVÁNÍ BI?
- Neefektivní návrhy. Pokud je testování ignorováno, nemusí být nalezena špatná architektura. Problémy s designem mohou přispět k použitelnosti, výkonu, opětovnému použití, údržbě a údržbě.
- Problémy s integritou dat. Problémy s poškozením dat nebo datovou linií mohou vést k nedostatku důvěry v čísla.
- Problémy s ověřováním dat. Rozhodnutí o špatných datech mohou být pro firmu zničující. Není nic horšího, než se snažit spravovat pomocí metrik založených na nesprávných informacích.
- Snížené přijetí uživatelem. Pokud čísla nejsou správná nebo pokud aplikace není uživatelsky přívětivá, vaše uživatelská komunita váš lesklý nový podnikový software BI prostě nepoužije.
- Zvýšené náklady kvůli chybějící standardizaci.
- Zvýšené náklady na opravu vad v pozdějších fázích životního cyklu vývoje BI. Jakékoli problémy objevené nad rámec fáze požadavků budou stát exponenciálně více, než kdyby byly objeveny dříve.
Nyní, když jsme vysvětlili, proč organizace nemusí testovat a úskalí, která nastávají, když netestujete BI, podívejme se na některé studie o testování při vývoji softwaru.
Studie Ukázat testování vaší platformy BI šetří peníze!
Jedna studie 139 severoamerických společností od 250 do 10,000 5.2 zaměstnanců vykazovaly roční náklady na ladění od 22 mil. USD do XNUMX mil. USD. Tento rozsah nákladů odráží organizace, které ne mít zavedené automatické testování jednotek. Samostatně to zjistil výzkum společností IBM a Microsoft s zavedeno automatické testování jednotek, počet defektů lze snížit o 62% až 91%. To znamená, že dolary vynaložené na ladění by mohly být sníženy z rozsahu 5 mil. USD - 22 mil. USD na rozsah 0.5 mil. USD až 8.4 mil. USD. To je obrovská úspora!
Rychlé eskalace nákladů na opravu chyb.
Článek o úspěšných taktikách vývoje softwaru ukazuje, že většina chyb se provádí na začátku vývojového cyklu a že čím déle čekáte na detekci a opravu, tím vyšší jsou náklady na opravu. Není tedy nutné, aby raketový vědec dospěl ke zjevnému závěru, že čím dříve jsou chyby objeveny a opraveny, tím lépe. Když už mluvíme o raketové vědě, stane se, že NASA zveřejnila článek právě o tom - "Eskalace nákladů na chyby během životního cyklu projektu."
Je intuitivní, že náklady na opravu chyb se zvyšují v průběhu životního cyklu vývoje. Byla provedena studie NASA s cílem zjistit, jak rychle postupují relativní náklady na objevené chyby při opravách. Tato studie použila tři přístupy ke stanovení relativních nákladů: metoda nákladů zdola nahoru, metoda rozdělení celkových nákladů a metoda hypotetického projektu shora dolů. Přístupy a výsledky popsané v tomto článku předpokládají vývoj hardwarového/softwarového systému, který má charakteristiky projektu podobné těm, které se používají při vývoji velkých, složitých kosmických lodí, vojenských letadel nebo malých komunikačních satelitů. Výsledky ukazují, do jaké míry se náklady stupňují, protože chyby se objevují a opravují v pozdějších a pozdějších fázích životního cyklu projektu. Tato studie představuje další výzkum, který byl proveden.
Z výše uvedeného grafu ukazuje výzkum společností TRW, IBM, GTE, Bell Labs, TDC a dalších náklady na opravu chyb během různých fází vývoje:
- Náklady na opravu chyby zjištěné během fáze požadavků jsou definovány jako 1 jednotka
- Náklady na opravu této chyby, pokud jsou nalezeny během fáze návrhu, jsou zdvojnásobit že
- Ve fázi kódu a ladění jsou náklady na opravu chyby 3 jednotky
- Ve fázi testování a integrace jednotky vznikají náklady na opravu chyby 5
- Ve fázi fáze testování systémů náklady na opravu chyby vyskočí na 20
- A jakmile je systém ve fázi provozu, relativní náklady na opravu chyby vzrostly na 98, téměř stonásobek nákladů na opravu chyby, pokud jsou nalezeny ve fázi požadavků!
Pointa je v tom, že je mnohem nákladnější opravit závady, pokud nejsou chyceny včas.
Závěry
Byl proveden významný výzkum, který ukazuje hodnotu raného a kontinuálního testování při vývoji softwaru. My, v komunitě BI, se můžeme učit od našich přátel při vývoji softwaru. Přestože většina formálního výzkumu byla věnována vývoji softwaru, lze o vývoji BI vyvodit podobné závěry. Hodnota testování je neoddiskutovatelná, ale mnoho organizací pomaleji využívá formální testování svého prostředí BI a integruje testování do svých vývojových procesů BI. Náklady na ne testování je skutečné. Rizika spojená s ne testování je skutečné.
Chcete vidět nějaké automatizované testování Cognos v akci? Sledujte videa v našem seznamu skladeb od kliknutím zde!
