Aktualisearre augustus 28, 2019
Testen is wiid oannaam as ûnderdiel fan softwareûntwikkeling sûnt software is ûntwikkele. Business Intelligence (BI) is lykwols stadiger west om testen oan te nimmen as in yntegreare diel fan ûntwikkeling yn BI -software lykas IBM Cognos. Litte wy ûndersykje wêrom BI stadiger is west om testpraktiken oan te nimmen en de gefolgen dêrfan NET testen.
Wêrom organisaasjes BI net testen ...
- Tiidbeperkingen. BI -projekten steane ûnder konstante druk om rapper te wurde levere. Wat guon organisaasjes miskien net beseffe, is dat testen de maklikste faze is om tiid te ferminderjen.
- Begrutting fan budzjet. It tinken is dat testen te djoer is en gjin testteam kin tawize.
- Sneller is better. Dit is net needsaaklik in "agile" oanpak en kin jo allinich rapper op it ferkearde plak bringe.
- De mentaliteit "doch it gewoan de earste kear goed". Dizze naïve oanpak insist dat de oanwêzigens fan kwaliteitskontrôle de needsaak foar testen moat ferminderje.
- Gebrek oan eigendom. Dit is gelyk oan de foarige kûgel. It tinken is dat "ús brûkers it sille testen." Dizze oanpak kin liede ta ûngelokkige brûkers en in protte stipekaarten.
- Tekoart oan ark. De misfetting dat se net de juste technology hawwe foar testen.
- Gebrek oan begryp fan testen. Bygelyks,
- Testen moat de krektens en jildigens fan gegevens, gegevenskonsistinsje, aktualiteit fan gegevens, prestaasjes fan levering, en maklik gebrûk fan it leveringsmeganisme evaluearje.
- Testen tidens in BI -projekt kin regressionstest, ienheidstest, reekstest, yntegraasje -testen, testen fan akseptaasje fan brûkers, ad hoc -testen, testen fan stress/skalberens, testen fan systeemprestaasjes omfetsje.
Wat binne de kosten foar it net testen fan BI?
- Ineffektive ûntwerpen. Min arsjitektuer kin net wurde ûntdutsen as testen wurdt negeare. Untwerpproblemen kinne bydrage oan brûkberens, prestaasjes, opnij gebrûk, lykas, ûnderhâld en ûnderhâld.
- Problemen mei gegevensyntegriteit. Gegevenskorrupsje as útdagings foar ôfstamming fan gegevens kinne liede ta gebrek oan fertrouwen yn 'e nûmers.
- Problemen mei gegevensvalidaasje. Besluten makke oer minne gegevens kinne it bedriuw ferneatigjend wêze. D'r is neat slimmer dan besykje te behearjen mei metriken dy't binne basearre op ferkearde ynformaasje.
- Fergrutte oanname fan brûkers. As de nûmers net goed binne, of as de applikaasje net brûkerfreonlik is, sil jo brûkersmienskip jo glânzgjende nije Enterprise BI-software gewoan net brûke.
- Ferhege kosten troch gebrek oan standerdisearring.
- Fergrutte kosten om defekten te reparearjen yn lettere stadia fan 'e libbenssyklus fan' e BI -ûntwikkeling. Elke problemen ûntdutsen bûten de easkenfaze sille eksponentiell mear kostje dan as se earder waarden ûntdutsen.
No't wy hawwe útlein wêrom't organisaasjes miskien net testen en de falle dy't foarkomme as jo BI net testje, litte wy nei guon stúdzjes sjen oer testen yn softwareûntwikkeling.
Studies litte sjen dat jo BI -platfoarm testen testet jild!
Ien stúdzje fan 139 Noard -Amerikaanske bedriuwen fariearjend yn grutte fan 250 oant 10,000 meiwurkers, rapporteare jierlikse debuggingskosten fan $ 5.2M oant $ 22M. Dit kostenberik wjerspegelt organisaasjes dy't do net hawwe automatyske ienheidstests yn plak. Apart fûnen ûndersiik fan IBM en Microsoft dat mei automatyske ienheidstests op it plak, kin it oantal defekten wurde fermindere mei tusken 62% en 91%. Dit betsjuttet dat dollars bestege oan debuggen koene wurde fermindere fan it $ 5M - $ 22M berik nei it $ 0.5M nei $ 8.4M berik. Dat is in enoarme besparring!
Kosten om flaters fluch te eskalearjen.
In papier oer suksesfolle softwareûntwikkelingstaktyk toant oan dat de measte flaters betiid wurde makke yn 'e ûntwikkelingssyklus en dat hoe langer jo wachtsje om te detektearjen en te korrigearjen, hoe heger it kostet jo te reparearjen. Dat, it nimt gjin raketwittenskipper om de foar de hân lizzende konklúzje te lûken dat de earder flaters wurde ûntdutsen en repareare, hoe better. Sprekke fan raketwittenskip, it bart gewoan dat NASA in papier publisearre oer dat - "Eskalaasje fan flaterkosten troch de syklus fan it projekt."
It is yntuïtyf dat de kosten om flaters op te lossen tanimme as de libbenssyklus fan 'e ûntwikkeling foarútgiet. De NASA -stúdzje waard útfierd om te bepalen hoe fluch de relative kosten foar it reparearjen fan flaters ûntdutsen ferrinne. Dizze stúdzje brûkte trije oanpak om de relative kosten te bepalen: de metoade fan bottom-up kosten, de metoade foar totale ferdieling fan kosten, en de top-down hypotetyske projektmetoade. De oanpakken en resultaten beskreaun yn dit papier geane út fan ûntwikkeling fan in hardware/softwaresysteem mei projektekarakteristiken gelyk oan dy brûkt by de ûntwikkeling fan in grut, kompleks romteskip, in militêr fleantúch, of in lytse kommunikaasjesatellyt. De resultaten litte sjen yn hoefier't kosten eskalearje, om't flaters wurde ûntdutsen en repareare op lettere en lettere fazen yn 'e libbenssyklus fan it projekt. Dizze stúdzje is represintatyf foar oar ûndersyk dat is dien.
Ut 'e boppesteande grafyk toant ûndersyk fan TRW, IBM, GTE, Bell Labs, TDC en oaren de kosten foar it reparearjen fan flaters tidens de ferskate ûntwikkelingsfazen:
- De kosten foar it reparearjen fan in flater ûntdutsen tidens de easkenfaze wurde definieare as 1-ienheid
- De kosten om dizze flater op te lossen as fûn yn 'e ûntwerphase is dûbel dat
- By de koade- en debug -faze binne de kosten om de flater op te lossen 3 units
- By de ienheidstest en faze yntegrearje, wurde de kosten om de flater op te lossen 5
- By de faze fan 'e systemtest, de kosten om de flater op te lossen springt nei 20
- En as it systeem ienris yn 'e operaasjefase is, de relative kosten om de flater te ferbetterjen is omheech gien nei 98, hast 100 kear de kosten foar it ferbetterjen fan de flater as fûn yn 'e easkenfaze!
De konklúzje is dat it folle djoerder is om defekten te reparearjen as se net betiid wurde fongen.
konklúzjes
Wichtich ûndersyk is útfierd dat de wearde toant fan iere en trochgeande testen yn softwareûntwikkeling. Wy, yn 'e BI -mienskip, kinne leare fan ús freonen yn softwareûntwikkeling. Hoewol it measte formele ûndersyk is dien relatearre oan softwareûntwikkeling, kinne ferlykbere konklúzjes wurde makke oer BI -ûntwikkeling. De wearde fan testen is net te bestriden, mar in protte organisaasjes hawwe stadiger west om te profitearjen fan formele testen fan har BI -omjouwing en testen te yntegrearjen yn har BI -ûntwikkelingsprosessen. De kosten fan net testen binne echt. De risiko's ferbûn mei net testen binne echt.
Wolle jo wat automatisearre Cognos -testen yn aksje sjen? Besjoch de fideo's op ús playlist troch hjir te klikken!
