Uuendatud august 28, 2019
Testimist on tarkvara arendamise osana laialdaselt kasutusele võetud alates tarkvara väljatöötamisest. Business Intelligence (BI) on aga aeglasemalt kasutanud testimist BI -tarkvara, näiteks IBM Cognos, arenduse lahutamatu osana. Uurime, miks BI on testimispraktika kasutuselevõtt olnud aeglasem ja selle tagajärjed EI katsetamine.
Miks organisatsioonid BI -d ei testi ...
- Ajapiirangud. BI -projektid on pideva surve all, et neid kiiremini tarnida. Mõned organisatsioonid ei pruugi aru saada, et kõige lihtsam aja vähendamise etapp on testimine.
- Eelarve piirangud. Arvatakse, et testimine on liiga kallis ega saa testimismeeskonda pühendada.
- Kiirem on parem. See ei pruugi olla „vilgas” lähenemisviis ja võib viia teid kiiremini valesse kohta.
- Mentaliteet “tee seda esimest korda õigesti”. See naiivne lähenemine nõuab, et kvaliteedikontrolli olemasolu peaks vähendama testimisvajadust.
- Omandi puudumine. See on sarnane eelmise täpiga. Arvatakse, et „meie kasutajad katsetavad seda”. See lähenemine võib põhjustada õnnetuid kasutajaid ja palju tugipileteid.
- Tööriistade puudus. Eksiarvamus, et neil pole testimiseks õiget tehnoloogiat.
- Testimisest arusaamise puudumine. Näiteks,
- Testimisel tuleks hinnata andmete õigsust ja kehtivust, andmete järjepidevust, andmete õigeaegsust, kättetoimetamise toimivust ja edastamismehhanismi kasutusmugavust.
- Testimine BI -projekti ajal võib hõlmata regressioonitestimist, üksuste testimist, suitsu testimist, integratsioonitestimist, kasutajate aktsepteerimistesti, ad hoc testimist, stressi/mastaapsuse testimist, süsteemi jõudluse testimist.
Mis on kulud, kui BI -d ei testita?
- Ebaefektiivsed kujundused. Halba arhitektuuri ei pruugita avastada, kui testimist eiratakse. Disainiprobleemid võivad kaasa aidata kasutatavusele, jõudlusele, korduvkasutusele, samuti hooldusele ja hooldusele.
- Andmete terviklikkuse probleemid. Andmete riknemine või andmete liini väljakutsed võivad põhjustada numbrite usaldamatust.
- Andmete valideerimise probleemid. Halbade andmete põhjal tehtud otsused võivad ettevõttele laastavalt mõjuda. Pole midagi hullemat kui proovida hallata mõõdikute alusel, mis põhinevad valel teabel.
- Vähenenud kasutajate kasutuselevõtt. Kui numbrid pole õiged või kui rakendus pole kasutajasõbralik, ei kasuta teie kasutajaskond teie läikivat uut ettevõtte BI-tarkvara.
- Suurenenud kulud standardimise puudumise tõttu.
- Suuremad kulud defektide parandamiseks BI arendustsükli hilisemates etappides. Kõik probleemid, mis avastatakse väljaspool nõuete faasi, maksavad eksponentsiaalselt rohkem kui varem avastatud.
Nüüd, kui oleme välja toonud, miks organisatsioonid ei pruugi testida, ja lõksud, mis ilmnevad siis, kui te BI -d ei testi, vaatame mõningaid uuringuid tarkvaraarenduse testimise kohta.
Uuringud näitavad, et teie BI -platvormi testimine säästab raha!
Üks uuring 139 Põhja -Ameerika ettevõtte kohta ulatudes 250–10,000 5.2 töötajani, teatasid iga -aastased silumiskulud 22–XNUMX miljonit dollarit. See kulude vahemik kajastab organisatsioone, kes seda teevad ei seadmed on automatiseeritud. Eraldi leidsid IBM ja Microsofti uuringud, et koos Kui seadme automaatne testimine on paigas, saab defektide arvu vähendada 62% kuni 91%. See tähendab, et silumiseks kulutatud dollareid võib vähendada vahemikus 5–22 miljonit dollarit vahemikku 0.5 miljonit dollarit kuni 8.4 miljonit dollarit. See on tohutu kokkuhoid!
Kulud vigade kiireks parandamiseks suurenevad.
Paber eduka tarkvaraarenduse taktika kohta näitab, et enamik vigu tehakse arendustsükli alguses ja et mida kauem avastamist ja parandamist ootate, seda suuremad on selle parandamise kulud. Seega ei pea raketiteadlane tegema ilmseid järeldusi, et mida varem vead avastatakse ja parandatakse, seda parem. Rääkides raketiteadusest, juhtus nii, et NASA avaldas selle kohta paberi - „Veakulude suurendamine projekti elutsükli jooksul.”
On intuitiivne, et vigade parandamise kulud suurenevad arenduse elutsükli edenedes. NASA uuring viidi läbi, et teha kindlaks, kui kiiresti avastatud vigade parandamise suhteline maksumus areneb. Selles uuringus kasutati suhteliste kulude määramiseks kolme lähenemisviisi: alt-üles kulude meetod, kogukulude jaotamise meetod ja ülalt-alla hüpoteetiline projektimeetod. Käesolevas dokumendis kirjeldatud lähenemisviisid ja tulemused eeldavad sellise riist-/tarkvarasüsteemi väljatöötamist, mille projektiomadused on sarnased suurte keerukate kosmoseaparaatide, sõjalennukite või väikese sidesatelliidi arendamisel kasutatavatega. Tulemused näitavad kulude suurenemise määra, kuna vead avastatakse ja parandatakse projekti elutsükli hilisemates ja hilisemates etappides. See uuring esindab teisi tehtud uuringuid.
Ülaltoodud tabelist näitavad TRW, IBM, GTE, Bell Labs, TDC jt uurimused vigade parandamise kulusid erinevatel arendusetappidel:
- Nõuete faasis avastatud vea parandamise kulu on määratletud järgmiselt 1 üksus
- Selle vea parandamise hind, kui see leitakse projekteerimisetapis, on kahekordistada et
- Koodi ja silumisfaasis on vea parandamise kulud 3 üksused
- Seadme testimise ja integreerimise faasis suurenevad vea parandamise kulud 5
- Süsteemide testimise faasis vea parandamise hind tõuseb 20 -ni
- Ja kui süsteem on tööfaasis, vea parandamise suhtelised kulud on tõusnud 98 -ni, mis on nõuete faasis leitud vea parandamise kuludest ligi 100 korda suurem!
Põhimõte on see, et defektide parandamine on palju kulukam, kui neid varakult ei avastata.
Järeldused
On tehtud olulisi uuringuid, mis näitavad varajase ja pideva testimise väärtust tarkvaraarenduses. BI -kogukonnas saame tarkvaraarenduses sõpradelt õppida. Kuigi enamik ametlikke uuringuid on tehtud tarkvaraarendusega, võib sarnaseid järeldusi teha ka BI arendamise kohta. Testimise väärtus on vaieldamatu, kuid paljud organisatsioonid on aeglasemalt kasutanud oma BI keskkonna ametlikku testimist ja integreerinud testimise oma BI arendusprotsessidesse. Kulud mitte testid on reaalsed. Seotud riskid mitte testid on reaalsed.
Kas soovite näha mõnda Cognose automaatset testimist? Vaadake videoid meie esitusloendist klikkides siia!
