Opdateret August 28, 2019
Test er blevet bredt vedtaget som en del af softwareudvikling lige siden software er blevet udviklet. Business Intelligence (BI) har imidlertid været langsommere til at vedtage test som en integreret del af udviklingen i BI -software som IBM Cognos. Lad os undersøge, hvorfor BI har været langsommere med at anvende testpraksis og konsekvenserne af IKKE testning.
Hvorfor tester organisationer ikke BI ...
- Tidsbegrænsninger. BI -projekter er under konstant pres for at blive leveret hurtigere. Hvad nogle organisationer måske ikke er klar over, er, at den letteste fase for at reducere tid er test.
- Budgetbegrænsninger. Tanken er, at test er for dyrt og ikke kan dedikere et testteam.
- Hurtigere er bedre. Dette er ikke nødvendigvis en "smidig" tilgang og får dig måske kun hurtigere til at tage det forkerte sted.
- "Bare gør det rigtigt første gang" -mentaliteten. Denne naive fremgangsmåde insisterer på, at tilstedeværelsen af kvalitetskontrol bør reducere behovet for test.
- Manglende ejerskab. Dette ligner den tidligere kugle. Tanken er, at "vores brugere vil teste det." Denne tilgang kan føre til utilfredse brugere og masser af supportbilletter.
- Mangel på værktøj. Den misforståelse, at de ikke har den rigtige teknologi til test.
- Manglende forståelse for test. For eksempel,
- Testen skal evaluere nøjagtigheden og gyldigheden af data, datakonsistens, dataens aktualitet, leveringsydelse og brugervenligheden af leveringsmekanismen.
- Test under et BI -projekt kan omfatte regressionstest, enhedstest, røgtest, integrationstest, test af brugeraccept, ad hoc -test, test af stress/skalerbarhed, systempræstationstest.
Hvad er omkostningerne ved IKKE at teste BI?
- Ineffektive designs. Dårlig arkitektur opdages muligvis ikke, hvis test ignoreres. Designproblemer kan bidrage til brugervenlighed, ydeevne, genbrug samt vedligeholdelse og vedligeholdelse.
- Problemer med dataintegritet. Datakorruption eller udfordringer med datastrategi kan føre til manglende tillid til tallene.
- Problemer med datavalidering. Beslutninger om dårlige data kan være ødelæggende for virksomheden. Der er ikke noget værre end at prøve at styre med metrics, der er baseret på forkerte oplysninger.
- Nedsat brugeradoption. Hvis tallene ikke er rigtige, eller hvis applikationen ikke er brugervenlig, bruger dit brugerfællesskab bare ikke din skinnende nye enterprise BI-software.
- Øgede omkostninger på grund af manglende standardisering.
- Øgede omkostninger til reparation af fejl i senere stadier af BI -udviklings livscyklus. Eventuelle problemer opdaget ud over kravfasen vil koste eksponentielt mere end hvis de blev opdaget tidligere.
Nu hvor vi har lagt frem, hvorfor organisationer muligvis ikke tester og de faldgruber, der opstår, når du ikke tester BI, lad os se på nogle undersøgelser om test inden for softwareudvikling.
Undersøgelser viser, at testning af din BI -platform sparer penge!
En undersøgelse af 139 nordamerikanske virksomheder spænder i størrelse fra 250 til 10,000 ansatte, rapporterede årlige fejlfindingsomkostninger på $ 5.2 mio. til $ 22 mio. Dette omkostningsinterval afspejler organisationer, der ikke har automatiseret enhedstest på plads. Separat fandt forskning fra IBM og Microsoft det med automatiseret enhedstest på plads, kan antallet af fejl reduceres med mellem 62% og 91%. Det betyder, at dollars brugt på fejlfinding kan reduceres fra $ 5 mio. - $ 22 mio. Til $ 0.5 mio. Til $ 8.4 mio. Det er en kæmpe besparelse!
Omkostninger til at rette fejl hurtigt eskalere.
Et papir om succesfuld softwareudviklingstaktik viser, at de fleste fejl begås tidligt i udviklingscyklussen, og at jo længere du venter på at opdage og rette, jo højere koster det dig at rette. Så det tager ikke en raketforsker at drage den indlysende konklusion, at jo hurtigere fejl opdages og rettes, jo bedre. Når vi taler om raketvidenskab, sker det bare sådan, at NASA udgav et papir om netop det - "Eskalering af fejlomkostninger gennem projektets livscyklus."
Det er intuitivt, at omkostningerne til at rette fejl stiger, når udviklingslivscyklussen skrider frem. NASA -undersøgelsen blev udført for at bestemme, hvor hurtigt de relative omkostninger ved at rette opdagede fejl skrider frem. Denne undersøgelse anvendte tre tilgange til at bestemme de relative omkostninger: bottom-up omkostningsmetoden, metoden til samlede omkostninger og den top-down hypotetiske projektmetode. De fremgangsmåder og resultater, der er beskrevet i dette papir, forudsætter udvikling af et hardware-/softwaresystem med projektegenskaber, der ligner dem, der bruges til udvikling af et stort, komplekst rumfartøj, et militærfly eller en lille kommunikationssatellit. Resultaterne viser i hvilken grad omkostningerne eskalerer, da fejl opdages og rettes på senere og senere faser i projektets livscyklus. Denne undersøgelse er repræsentativ for anden forskning, der er blevet udført.
Fra ovenstående diagram viser forskning fra TRW, IBM, GTE, Bell Labs, TDC og andre omkostningerne ved at rette fejl i de forskellige udviklingsfaser:
- Omkostningerne ved at rette en fejl opdaget under kravfasen er defineret som 1 enhed
- Omkostningerne ved at rette denne fejl, hvis de findes i designfasen, er fordoble at
- I kode- og fejlfindingsfasen er omkostningerne til at rette fejlen 3 enheder
- Ved enhedstesten og integreringsfasen bliver omkostningen til at rette fejlen 5
- Ved systemtestfasen, omkostningerne til at rette fejlen springer til 20
- Og når systemet først er i driftsfasen, den relative pris for at rette fejlen er steget til 98, næsten 100 gange omkostningerne ved at rette fejlen, hvis den findes i kravsfasen!
Konklusionen er, at det er meget dyrere at reparere fejl, hvis de ikke fanges tidligt.
konklusioner
Der er blevet udført betydelig forskning, der viser værdien af tidlig og kontinuerlig test i softwareudvikling. Vi i BI -fællesskabet kan lære af vores venner inden for softwareudvikling. Selvom der er foretaget mest formel forskning vedrørende softwareudvikling, kan lignende konklusioner drages om BI -udvikling. Værdien af test er uomtvistelig, men mange organisationer har været langsommere med at drage fordel af formel test af deres BI -miljø og integrere test i deres BI -udviklingsprocesser. Omkostningerne ved ikke test er ægte. Risici forbundet med ikke test er ægte.
Vil du se nogle automatiserede Cognos -test i aktion? Se videoerne på vores playliste af at klikke her!
