Абноўлены жнівень 28, 2019
Тэставанне стала шырока распаўсюджаным у рамках распрацоўкі праграмнага забеспячэння з таго часу, як было распрацавана праграмнае забеспячэнне. Аднак Business Intelligence (BI) стаў павольней прымаць тэсціраванне як інтэгральную частку распрацоўкі праграмнага забеспячэння BI, напрыклад IBM Cognos. Давайце разбярэмся, чаму BI павольней укараняе практыку тэставання і наступствы гэтага НЕ тэставанне.
Чаму арганізацыі не тэстуюць BI ...
- Часовыя абмежаванні. Праекты бізнэсу знаходзяцца пад пастаянным ціскам, каб іх рэалізаваць хутчэй. Чагосьці некаторыя арганізацыі не разумеюць, што самы просты этап скарачэння часу - гэта тэставанне.
- Бюджэтныя абмежаванні. Думаецца, што тэсціраванне занадта дарагое і не можа вылучыць каманду па тэсціраванні.
- Хутчэй лепш. Гэта не абавязкова "спрытны" падыход і можа толькі хутчэй даставіць вас у няправільнае месца.
- Менталітэт "проста зрабі гэта правільна з першага разу". Гэты наіўны падыход настойвае на тым, што наяўнасць кантролю якасці павінна знізіць неабходнасць тэставання.
- Адсутнасць уласнасці. Гэта падобна на папярэднюю кулю. Думаюць, што "нашы карыстальнікі будуць гэта правяраць". Такі падыход можа прывесці да няшчасных карыстальнікаў і вялікай колькасці квіткоў у службу падтрымкі.
- Адсутнасць інструментаў. Памылковае меркаванне, што ў іх няма адпаведнай тэхналогіі для тэставання.
- Неразуменне тэставання. Напрыклад,
- Тэставанне павінна ацэньваць дакладнасць і сапраўднасць дадзеных, узгодненасць дадзеных, своечасовасць дадзеных, эфектыўнасць дастаўкі і зручнасць выкарыстання механізму дастаўкі.
- Тэсціраванне падчас праекта BI можа ўключаць у сябе рэгрэсійнае тэставанне, модульнае тэсціраванне, тэсціраванне дыму, інтэграцыйнае тэсціраванне, тэставанне прыняцця карыстальнікаў, спецыяльнае тэставанне, стрэс/маштабаванасць, тэставанне працы сістэмы.
Якія выдаткі на НЕ тэставанне BI?
- Неэфектыўныя канструкцыі. Дрэнная архітэктура не можа быць выяўлена пры ігнараванні тэставання. Пытанні дызайну могуць спрыяць зручнасці выкарыстання, прадукцыйнасці, паўторнага выкарыстання, а таксама абслугоўванню і абслугоўванню.
- Пытанні цэласнасці дадзеных. Пашкоджанне дадзеных або праблемы з лініямі перадачы дадзеных могуць прывесці да недаверу ў лічбах.
- Пытанні праверкі дадзеных. Прыняцце рашэнняў аб дрэнных дадзеных можа быць разбуральным для бізнесу. Няма нічога горшага, чым спрабаваць кіраваць паказчыкамі, заснаванымі на няправільнай інфармацыі.
- Зніжэнне колькасці карыстальнікаў. Калі лічбы не адпавядаюць правілам, або калі прыкладанне не зручнае для карыстальнікаў, ваша супольнасць карыстальнікаў проста не будзе выкарыстоўваць ваша бліскучае новае праграмнае забеспячэнне для бізнес-BI.
- Павелічэнне выдаткаў з -за адсутнасці стандартызацыі.
- Павелічэнне выдаткаў на рамонт дэфектаў на пазнейшых этапах жыццёвага цыкла распрацоўкі BI. Любыя праблемы, выяўленыя пасля фазы патрабаванняў, будуць каштаваць у геаметрычнай прагрэсіі даражэй, чым калі б яны былі выяўлены раней.
Цяпер, калі мы высветлілі, чаму арганізацыі не праводзяць тэставанне, і падводныя камяні, якія ўзнікаюць, калі вы не правяраеце BI, давайце паглядзім на некаторыя даследаванні па тэсціраванні пры распрацоўцы праграмнага забеспячэння.
Даследаванні паказваюць, што тэставанне вашай платформы BI эканоміць грошы!
Адно даследаванне 139 паўночнаамерыканскіх кампаній памерам ад 250 да 10,000 5.2 супрацоўнікаў, штогадовыя выдаткі на адладку складаюць ад 22 да XNUMX мільёнаў долараў. Гэты дыяпазон выдаткаў адлюстроўвае арганізацыі, якія ня маюць аўтаматызаванае адзінкавае тэсціраванне. Асобна гэта выявілі даследаванні IBM і Microsoft з аўтаматызаванае адзінкавае тэсціраванне, колькасць дэфектаў можна знізіць на 62% да 91%. Гэта азначае, што даляры, выдаткаваныя на адладку, можна скараціць з дыяпазону ад 5 да 22 мільёнаў долараў да дыяпазону ад 0.5 да 8.4 мільёна долараў. Гэта велізарная эканомія!
Хутка павялічваюцца выдаткі на выпраўленне памылак.
Дакумент аб паспяховай тактыцы распрацоўкі праграмнага забеспячэння дэманструе, што большасць памылак дапушчана ў пачатку цыкла распрацоўкі і што чым даўжэй вы чакаеце выяўлення і выпраўлення, тым даражэй вам прыйдзецца выправіць. Такім чынам, ракетнаму навукоўцу не трэба рабіць відавочную выснову, што чым раней памылкі будуць выяўлены і выпраўлены, тым лепш. Калі казаць аб ракетнай навуцы, так здарылася, што НАСА апублікавала дакумент менавіта пра гэта - "Эскалацыя кошту памылкі праз жыццёвы цыкл праекта".
Інтуітыўна зразумела, што выдаткі на выпраўленне памылак павялічваюцца па меры праходжання жыццёвага цыкла распрацоўкі. Даследаванне NASA было праведзена, каб вызначыць, наколькі хутка прагрэсуе адносная кошт выяўленых памылак. У гэтым даследаванні былі выкарыстаны тры падыходы для вызначэння адносных выдаткаў: метад знізу ўверх, метад разбіўкі агульных выдаткаў і гіпатэтычны метад праекта зверху ўніз. Падыходы і вынікі, апісаныя ў гэтым дакуменце, мяркуюць распрацоўку апаратна -праграмнай сістэмы, якая мае праектныя характарыстыкі, аналагічныя тым, якія выкарыстоўваюцца пры распрацоўцы вялікага складанага касмічнага карабля, ваеннага самалёта або малога спадарожніка сувязі. Вынікі паказваюць ступень нарастання выдаткаў, паколькі памылкі выяўляюцца і выпраўляюцца на больш позніх і позніх этапах жыццёвага цыкла праекта. Гэта даследаванне з'яўляецца рэпрэзентатыўным для іншых даследаванняў, якія былі зроблены.
З прыведзенай вышэй дыяграмы даследаванні TRW, IBM, GTE, Bell Labs, TDC і іншых паказваюць кошт выпраўлення памылак на розных этапах распрацоўкі:
- Кошт выпраўлення памылкі, выяўленай на этапе патрабаванняў, вызначаецца як 1 блок
- Кошт выпраўлення гэтай памылкі, калі яна знойдзена на этапе праектавання, складае ўдвая Што
- На этапе кода і адладкі кошт выпраўлення памылкі складае блокі 3
- На этапе адзінкавага тэставання і інтэграцыі кошт выпраўлення памылкі становіцца большым 5
- На этапе выпрабаванняў сістэмы, кошт выпраўлення памылкі вырастае да 20
- І як толькі сістэма знаходзіцца ў фазе эксплуатацыі, адносныя выдаткі на выпраўленне памылкі выраслі да 98, што амаль у 100 разоў перавышае кошт выпраўлення памылкі, калі выяўляецца на этапе патрабаванняў!
Сутнасць у тым, што ліквідаваць дэфекты значна даражэй, калі іх не выявіць рана.
Высновы
Былі праведзены значныя даследаванні, якія дэманструюць каштоўнасць ранніх і бесперапынных выпрабаванняў у распрацоўцы праграмнага забеспячэння. Мы, у супольнасці BI, можам вучыцца ў нашых сяброў у распрацоўцы праграмнага забеспячэння. Нягледзячы на тое, што большасць афіцыйных даследаванняў было зроблена, звязаных з распрацоўкай праграмнага забеспячэння, можна зрабіць аналагічныя высновы аб распрацоўцы BI. Каштоўнасць тэставання бясспрэчная, але многія арганізацыі павольней выкарыстоўвалі фармальнае тэсціраванне асяроддзя BI і інтэгравалі тэставанне ў працэсы распрацоўкі BI. Выдаткі на ня тэставанне рэальнае. Рызыкі, звязаныя з ня тэставанне рэальнае.
Хочаце ўбачыць аўтаматычнае тэставанне Cognos у дзеянні? Глядзіце відэа ў нашым плэйлісце па націснуўшы тут!
