Päivitetty elokuu 28, 2019
Testausta on käytetty laajasti osana ohjelmistokehitystä ohjelmiston kehittämisen jälkeen. Business Intelligence (BI) on kuitenkin ollut hitaampi omaksumaan testauksen osana BI -ohjelmistojen, kuten IBM Cognosin, kehittämistä. Katsotaanpa, miksi BI on ollut hitaampi omaksumaan testauskäytäntöjä ja seurauksia ÄLÄ testaus.
Miksi organisaatiot eivät testaa BI: tä…
- Aikarajoitteet. BI -projektit ovat jatkuvan paineen alla nopeammin. Jotkut organisaatiot eivät ehkä ymmärrä, että helpoin vaihe lyhentää aikaa on testaus.
- Budjettirajoitteet. Ajatus on, että testaus on liian kallista eikä se voi omistaa testausryhmää.
- Nopeampi on parempi. Tämä ei välttämättä ole "ketterä" lähestymistapa ja saattaa viedä sinut nopeammin väärään paikkaan.
- "Tee se oikein ensimmäisellä kerralla" mentaliteetti. Tämä naiivi lähestymistapa vaatii, että laadunvalvonnan pitäisi vähentää testaustarvetta.
- Omistuksen puute. Tämä on samanlainen kuin edellinen luoti. Ajatuksena on, että "käyttäjät testaavat sen". Tämä lähestymistapa voi johtaa tyytymättömiin käyttäjiin ja paljon tukilippuja.
- Työkalujen puute. Väärä käsitys, että heillä ei ole oikeaa tekniikkaa testaukseen.
- Testauksen ymmärtämisen puute. Esimerkiksi,
- Testauksessa olisi arvioitava tietojen paikkansapitävyys ja pätevyys, tietojen johdonmukaisuus, tietojen oikea -aikaisuus, toimituksen suorituskyky ja toimitusmekanismin helppokäyttöisyys.
- Testaus BI -projektin aikana voi sisältää regressiotestauksen, yksikkötestauksen, savutestauksen, integraatiotestauksen, käyttäjien hyväksymistestauksen, ad hoc -testauksen, stressi-/skaalautuvuustestin, järjestelmän suorituskyvyn testauksen.
Mitkä ovat BI: n testaamatta jättämisen kustannukset?
- Tehottomat mallit. Huonoa arkkitehtuuria ei ehkä havaita, jos testaus jätetään huomiotta. Suunnitteluongelmat voivat vaikuttaa käytettävyyteen, suorituskykyyn, uudelleenkäyttöön sekä ylläpitoon ja ylläpitoon.
- Tietojen eheysongelmat. Tietojen korruptio tai tietojen siirtohaasteet voivat johtaa luottamuksen puutteeseen numeroihin.
- Tietojen vahvistusongelmat. Huonoista tiedoista tehdyt päätökset voivat olla tuhoisia liiketoiminnalle. Ei ole mitään pahempaa kuin yrittää hallita virheellisiin tietoihin perustuvilla mittareilla.
- Vähentynyt käyttäjien hyväksyntä. Jos numerot eivät ole oikein tai sovellus ei ole käyttäjäystävällinen, käyttäjäyhteisösi ei vain käytä uutta kiiltävää yrityksen BI-ohjelmistoa.
- Lisääntyneet kustannukset standardoinnin puutteen vuoksi.
- Lisääntyneet kustannukset vikojen korjaamisesta BI -kehityksen elinkaaren myöhemmissä vaiheissa. Kaikki vaatimukset -vaiheen jälkeen löydetyt ongelmat maksavat eksponentiaalisesti enemmän kuin aikaisemmin.
Nyt kun olemme selittäneet, miksi organisaatiot eivät ehkä testaa, ja sudenkuopat, joita ilmenee, kun et testaa BI: tä, katsotaanpa joitain tutkimuksia ohjelmistokehityksen testaamisesta.
Tutkimukset osoittavat, että BI -alustasi testaaminen säästää rahaa!
Yksi tutkimus 139 Pohjois -Amerikan yrityksestä vaihtelivat kooltaan 250–10,000 5.2 työntekijää, raportoivat vuosittaiset virheenkorjauskulut 22–XNUMX miljoonaa dollaria. Tämä hinta -alue kuvastaa organisaatioita, jotka älä on käytössä automaattinen yksikkötestaus. Erikseen IBM: n ja Microsoftin tutkimus havaitsi sen with Automaattinen yksikkötestaus, vikojen määrää voidaan vähentää 62%: sta 91%: iin. Tämä tarkoittaa sitä, että virheenkorjaukseen käytetyt dollaria voitaisiin alentaa 5 miljoonan dollarin - 22 miljoonan dollarin alueesta 0.5 miljoonan dollarin arvoon 8.4 miljoonan dollarin alueeseen. Se on valtava säästö!
Kustannukset virheiden korjaamisesta lisääntyvät nopeasti.
Paperi onnistuneesta ohjelmistokehitystaktiikasta osoittaa, että useimmat virheet tehdään kehitysvaiheen alkuvaiheessa ja että mitä kauemmin odotat havaitsemista ja korjaamista, sitä korkeammat korjauskustannukset. Joten ei tarvita rakettitieteilijää tekemään selvää johtopäätöstä, että mitä nopeammin virheet havaitaan ja korjataan, sitä parempi. Rakettitieteestä puhuttaessa tapahtui vain, että NASA julkaisi paperin juuri tästä - "Virhekustannusten nousu projektin elinkaaren aikana."
On intuitiivista, että virheiden korjaamisesta aiheutuvat kustannukset kasvavat kehityksen elinkaaren edetessä. NASAn tutkimus tehtiin sen selvittämiseksi, kuinka nopeasti havaittujen virheiden korjaamisen suhteelliset kustannukset etenevät. Tässä tutkimuksessa suhteellisten kustannusten määrittämiseen käytettiin kolmea lähestymistapaa: alhaalta ylöspäin suuntautuva kustannusmenetelmä, kokonaiskustannusten jaottelumenetelmä ja ylhäältä alaspäin hypoteettinen projektimenetelmä. Tässä artikkelissa kuvatut lähestymistavat ja tulokset edellyttävät sellaisen laitteisto-/ohjelmistojärjestelmän kehittämistä, jonka projektiominaisuudet ovat samankaltaiset kuin suuret, monimutkaiset avaruusalukset, sotilaslentokoneet tai pienet viestintäsatelliitit. Tulokset osoittavat, missä määrin kustannukset kasvavat, kun virheitä havaitaan ja korjataan projektin elinkaaren myöhemmissä ja myöhemmissä vaiheissa. Tämä tutkimus edustaa muita tehtyjä tutkimuksia.
Yllä olevasta taulukosta TRW: n, IBM: n, GTE: n, Bell Labsin, TDC: n ja muiden tutkimukset osoittavat virheiden korjaamisen kustannukset eri kehitysvaiheissa:
- Vaatimusvaiheen aikana havaitun virheen korjaamisesta aiheutuvat kustannukset määritellään seuraavasti 1 yksikkö
- Virheen korjaaminen, jos se havaitaan suunnitteluvaiheessa, maksaa kaksinkertainen että
- Koodi- ja virheenkorjausvaiheessa virheen korjaaminen maksaa 3 yksiköt
- Yksikön testaus- ja integrointivaiheessa virheen korjaamisesta tulee kustannuksia 5
- Järjestelmän testausvaiheessa virheen korjaus maksaa 20
- Ja kun järjestelmä on käyttövaiheessa, Virheen korjaamisen suhteelliset kustannukset ovat nousseet 98: een, mikä on lähes 100 kertaa virheen korjaamisen kustannus, jos se havaitaan vaatimusten vaiheessa!
Tärkeintä on, että vikojen korjaaminen on paljon kalliimpaa, jos niitä ei havaita ajoissa.
Päätelmät
On tehty merkittävää tutkimusta, joka osoittaa varhaisen ja jatkuvan testauksen arvon ohjelmistokehityksessä. Me BI -yhteisössä voimme oppia ystäviltämme ohjelmistokehityksessä. Vaikka suurin osa muodollisesta tutkimuksesta on tehty ohjelmistokehitykseen, samanlaisia johtopäätöksiä voidaan tehdä BI -kehityksestä. Testauksen arvo on kiistaton, mutta monet organisaatiot ovat olleet hitaampia hyödyntämään BI -ympäristönsä muodollista testausta ja integroimaan testaus BI -kehitysprosesseihinsa. Kustannukset emme testit ovat todellisia. Liittyvät riskit emme testit ovat todellisia.
Haluatko nähdä joitain automaattisia Cognos -testejä toiminnassa? Katso soittolistamme videot klikkaamalla tästä!
