Oppdatert August 28, 2019
Testing har blitt bredt vedtatt som en del av programvareutvikling siden programvare har blitt utviklet. Business Intelligence (BI) har imidlertid vært tregere til å vedta testing som en integrert del av utviklingen i BI -programvare som IBM Cognos. La oss undersøke hvorfor BI har vært tregere til å vedta testpraksis og konsekvensene av IKKE testing.
Hvorfor organisasjoner ikke tester BI ...
- Tidsbegrensninger. BI -prosjekter er under konstant press for å bli levert raskere. Det noen organisasjoner kanskje ikke skjønner er at den enkleste fasen for å redusere tid er testing.
- Budsjettbegrensninger. Tanken er at testing er for dyrt og ikke kan dedikere et testteam.
- Raskere er bedre. Dette er ikke nødvendigvis en "smidig" tilnærming og kan bare få deg til feil sted raskere.
- "Bare gjør det riktig første gangen" -mentaliteten. Denne naive tilnærmingen insisterer på at tilstedeværelsen av kvalitetskontroll bør redusere behovet for testing.
- Mangel på eierskap. Dette ligner på den forrige kula. Tanken er at "brukerne våre vil teste det." Denne tilnærmingen kan føre til ulykkelige brukere og mange støttebilletter.
- Mangel på verktøy. Misforståelsen om at de ikke har riktig teknologi for testing.
- Mangel på forståelse for testing. For eksempel,
- Testingen skal evaluere nøyaktigheten og gyldigheten av data, datakonsistens, aktualitet av data, leveringsytelse og brukervennlighet av leveringsmekanismen.
- Testing under et BI -prosjekt kan omfatte regresjonstesting, enhetstesting, røykprøving, integrasjonstesting, testing av brukeraksept, ad hoc -testing, tester av stress/skalerbarhet, systemytelsestesting.
Hva koster det å IKKE teste BI?
- Ineffektive design. Dårlig arkitektur kan ikke oppdages hvis testing blir ignorert. Designproblemer kan bidra til brukervennlighet, ytelse, gjenbruk, samt vedlikehold og vedlikehold.
- Problemer med dataintegritet. Datakorrupsjon eller datautstøtende utfordringer kan føre til mangel på tillit til tallene.
- Problemer med datavalidering. Beslutninger som tas om dårlige data kan være ødeleggende for virksomheten. Det er ingenting verre enn å prøve å styre med beregninger som er basert på feil informasjon.
- Redusert brukeradopsjon. Hvis tallene ikke er riktige, eller hvis programmet ikke er brukervennlig, bruker brukerfellesskapet bare ikke din skinnende nye enterprise BI-programvare.
- Økte kostnader på grunn av manglende standardisering.
- Økte kostnader for å reparere feil i senere stadier av livssyklusen til BI -utviklingen. Eventuelle problemer som oppdages utover kravfasen vil koste eksponensielt mer enn hvis de ble oppdaget tidligere.
Nå som vi har lagt frem hvorfor organisasjoner kanskje ikke tester og fallgruvene som oppstår når du ikke tester BI, la oss se på noen studier om testing i programvareutvikling.
Studier viser at testing av BI -plattformen din sparer penger!
En studie av 139 nordamerikanske selskaper varierer i størrelse fra 250 til 10,000 5.2 ansatte, rapporterte årlige feilsøkingskostnader på 22 millioner dollar til XNUMX millioner dollar. Dette kostnadsområdet gjenspeiler organisasjoner som ikke har automatisert enhetstesting på plass. Hver for seg fant forskning fra IBM og Microsoft det med automatisert enhetstesting på plass, kan antallet feil reduseres med mellom 62% og 91%. Dette betyr at dollar brukt på feilsøking kan reduseres fra $ 5 millioner - $ 22 millioner til $ 0.5 millioner til $ 8.4 millioner. Det er en enorm besparelse!
Kostnader for å fikse feil raskt eskalere.
Et papir om vellykket taktikk for utvikling av programvare viser at de fleste feilene blir gjort tidlig i utviklingssyklusen, og at jo lenger du venter på å oppdage og korrigere, desto høyere koster det deg å fikse. Så det tar ikke en rakettforsker å trekke den åpenbare konklusjonen at jo raskere feil blir oppdaget og fikset, jo bedre. Når det gjelder rakettvitenskap, hender det bare at NASA publiserte et papir om nettopp det - "Eskalering av kostnadskostnader gjennom prosjektets livssyklus."
Det er intuitivt at kostnadene for å fikse feil øker etter hvert som utviklingslivssyklusen utvikler seg. NASA -studien ble utført for å avgjøre hvor raskt den relative kostnaden for å fikse feil oppdager, utvikler seg. Denne studien brukte tre tilnærminger for å bestemme de relative kostnadene: kostmetoden bottom-up-kostnad, metoden for total kostnadsfordeling og hypotetisk prosjektmetode ovenfra og ned. Tilnærmingene og resultatene beskrevet i denne artikkelen forutsetter utvikling av et maskinvare-/programvaresystem som har prosjektegenskaper som ligner de som ble brukt i utviklingen av et stort, komplekst romfartøy, et militærfly eller en liten kommunikasjonssatellitt. Resultatene viser i hvilken grad kostnadene eskalerer, ettersom feil oppdages og rettes på senere og senere faser i prosjektets livssyklus. Denne studien er representativ for annen forskning som er gjort.
Fra diagrammet ovenfor viser forskning fra TRW, IBM, GTE, Bell Labs, TDC og andre kostnaden for å fikse feil i de forskjellige utviklingsfasene:
- Kostnaden for å fikse en feil som ble oppdaget under kravfasen er definert som 1 enhet
- Kostnaden for å fikse denne feilen hvis den blir funnet under designfasen er dobbelt Det
- I kode- og feilsøkingsfasen er kostnaden for å fikse feilen 3 enheter
- Ved enhetstesten og integreringsfasen blir kostnaden for å fikse feilen 5
- I systemtestfasen, kostnaden for å fikse feilen hopper til 20
- Og når systemet er i driftsfasen, den relative kostnaden for å rette feilen har steget til 98, nesten 100 ganger kostnaden for å rette feilen hvis den ble funnet i kravfasen!
Poenget er at det er mye dyrere å reparere feil hvis de ikke blir fanget tidlig.
Konklusjoner
Det er utført betydelig forskning som viser verdien av tidlig og kontinuerlig testing i programvareutvikling. Vi i BI -samfunnet kan lære av våre venner innen programvareutvikling. Selv om det har blitt gjort mest formell forskning knyttet til programvareutvikling, kan lignende konklusjoner trekkes om BI -utvikling. Verdien av testing er udiskutabel, men mange organisasjoner har vært tregere til å dra nytte av formell testing av BI -miljøet og integrere testing i deres BI -utviklingsprosesser. Kostnadene på ikke testing er ekte. Risikoen forbundet med ikke testing er ekte.
Vil du se noen automatiserte Cognos -tester i bruk? Se videoene på spillelisten vår av klikke her!
