Ажурирано август 28, 2019
Тестирањето е широко прифатено како дел од развојот на софтверот уште од развивањето на софтверот. Меѓутоа, деловната интелигенција (БИ) беше побавно да го прифати тестирањето како интегриран дел од развојот на БИ софтверот, како што е IBM Cognos. Ајде да истражиме зошто БИ е побавно да ги усвои практиките за тестирање и последиците од тоа НЕ тестирање.
Зошто организациите не го тестираат БИ ...
- Временски ограничувањаНа БИ проектите се под постојан притисок да се испорачаат побрзо. Она што некои организации можеби не го сфаќаат е дека најлесната фаза за намалување на времето е тестирањето.
- Буџетски ограничувањаНа Мислењето е дека тестирањето е премногу скапо и не може да посвети тим за тестирање.
- Побрзо е подоброНа Ова не е нужно „агилен“ пристап и може побрзо да ве одведе на погрешно место.
- Менталитетот „само направете го тоа правилно за прв пат“На Овој наивен пристап инсистира на тоа дека присуството на контрола на квалитетот треба да ја намали потребата за тестирање.
- Недостаток на сопственостНа Ова е слично на претходниот куршум. Мислењето е дека „нашите корисници ќе го тестираат“. Овој пристап може да доведе до несреќни корисници и многу билети за поддршка.
- Недостаток на алаткиНа Заблудата дека немаат соодветна технологија за тестирање.
- Недостаток на разбирање за тестирањеНа На пример,
- Тестирањето треба да ја оцени точноста и валидноста на податоците, конзистентноста на податоците, навременоста на податоците, изведбата на испораката и леснотијата на користење на механизмот за испорака.
- Тестирањето за време на проект за БИ може да вклучува тестирање на регресија, тестирање на единици, тестирање на чад, тестирање за интеграција, тестирање за прифаќање на корисници, тестирање на ад хок, тестирање на стрес/приспособливост, тестирање на перформансите на системот.
Кои се трошоците за НЕ тестирање на BI?
- Неефикасни дизајниНа Лошата архитектура може да не се открие ако се игнорира тестирањето. Проблемите со дизајнот можат да придонесат за употребливост, перформанси, повторна употреба, како и одржување и одржување.
- Прашања за интегритетот на податоцитеНа Корупцијата на податоците или предизвиците за лозата на податоци може да доведат до недоверба во бројките.
- Прашања за валидација на податоциНа Одлуките донесени за лоши податоци може да бидат катастрофални за бизнисот. Нема ништо полошо од обидот да се управува со метрика што се базираат на неточни информации.
- Намалено усвојување на корисницитеНа Ако бројките не се точни или ако апликацијата не е лесна за користење, вашата корисничка заедница едноставно нема да го користи вашиот сјаен нов софтвер за претпријатие БИ.
- Зголемени трошоци поради недостаток на стандардизација.
- Зголемени трошоци за поправка на дефекти во подоцнежните фази од животниот циклус на развојот на БИНа Сите прашања откриени надвор од фазата на барања, ќе чинат експоненцијално повеќе отколку ако беа откриени порано.
Сега кога утврдивме зошто организациите можеби не тестираат и замките што се јавуваат кога не го тестирате BI, ајде да погледнеме некои студии за тестирање при развој на софтвер.
Истражувањата покажуваат Тестирање на вашата БИ платформа заштедува пари!
Едно истражување на 139 северноамерикански компании со големина од 250 до 10,000 вработени, објавија годишни трошоци за дебагирање од 5.2 до 22 милиони американски долари. Овој опсег на трошоци ги одразува организациите што не имаат воспоставено автоматско тестирање на единици. Одделно, истражувањето на IBM и Microsoft го откри тоа со воспоставено автоматско тестирање на единицата, бројот на дефекти може да се намали помеѓу 62% и 91%На Ова значи дека долари потрошени за дебагирање може да се намалат од 5 до 22 милиони американски долари до 0.5 милиони до 8.4 милиони американски долари. Тоа е огромна заштеда!
Трошоците за брзо ескалирање на грешките.
Труд за успешни тактики за развој на софтвер покажува дека повеќето грешки се прават рано во циклусот на развој и дека колку подолго чекате да се откријат и поправат, толку повеќе ве чини да ги поправите. Значи, не е потребен ракетен научник да донесе очигледен заклучок дека колку порано грешките се откријат и поправат, толку подобро. Зборувајќи за ракетна наука, се случува НАСА да објави труд токму за тоа - „Грешка во ескалацијата на трошоците преку животниот циклус на проектот“.
Интуитивно е дека трошоците за поправање грешки се зголемуваат како што напредува животниот циклус на развојот. Студијата на НАСА беше направена за да се утврди колку брзо напредува релативната цена за откривање грешки. Оваа студија користеше три пристапи за да ги одреди релативните трошоци: методот на трошоци од дното нагоре, методот на расчленување на вкупните трошоци и хипотетичкиот проект од горе надолу. Приодите и резултатите опишани во овој труд претпоставуваат развој на хардвер/софтверски систем со карактеристики на проектот слични на оние што се користат во развојот на големо, сложено вселенско летало, воен авион или мал комуникациски сателит. Резултатите го покажуваат степенот на ескалација на трошоците, бидејќи грешките се откриваат и фиксираат во подоцнежните и подоцнежните фази од животниот циклус на проектот. Оваа студија е претставник на други истражувања што се направени.
Од горната табела, истражувањето од TRW, IBM, GTE, Bell Labs, TDC и други ги покажува трошоците за поправање грешки за време на различните развојни фази:
- Трошоците за поправање грешка откриена во фазата на барања се дефинираат како 1 единица
- Трошокот за поправање на таа грешка е доколку се најде во фазата на дизајнирање двојно Дека
- Во фазата на кодирање и дебагирање, трошокот за поправање на грешката е 3 единици
- Во фаза на тестирање и интегрирање на единицата, трошокот за поправање на грешката станува 5
- Во фазата на тест за системи, трошоците за поправање на грешката скокаат на 20
- И откако системот е во фаза на работа, релативните трошоци за поправање на грешката се искачија на 98, речиси 100 пати повеќе од трошоците за поправање на грешката доколку се најдат во фазата на барања!
Во крајна линија е дека е многу поскапо да се поправат дефектите ако не се најдат рано.
Заклучоци
Спроведено е значајно истражување кое ја покажува вредноста на раното и континуирано тестирање во развојот на софтверот. Ние, во заедницата БИ, можеме да учиме од нашите пријатели во развојот на софтвер. Иако се направени повеќето формални истражувања поврзани со развој на софтвер, може да се извлечат слични заклучоци за развојот на БИ. Вредноста на тестирањето е неспорна, но многу организации беа побавни да ги искористат предностите од формалното тестирање на нивната БИ околина и да го интегрираат тестирањето во нивните процеси за развој на БИ. Трошоците за не тестирањето е реално. Ризиците поврзани со не тестирањето е реално.
Сакате да видите некои автоматски тестирања на Cognos во акција? Погледнете ги видеата на нашата плејлиста од кликнете тука!
