Uppdaterad augusti 28, 2019
Testning har använts i stor utsträckning som en del av mjukvaruutveckling sedan programvara har utvecklats. Business Intelligence (BI) har dock varit långsammare att anta tester som en integrerad del av utvecklingen i BI -programvara som IBM Cognos. Låt oss utforska varför BI har varit långsammare att anta testmetoder och konsekvenserna av INTE testning.
Varför organisationer inte testar BI ...
- Tidsbegränsningar. BI -projekt är under konstant press för att levereras snabbare. Vad vissa organisationer kanske inte inser är att den enklaste fasen för att minska tiden är testning.
- Budgetbegränsningar. Tanken är att testning är för dyr och inte kan ägna ett testteam.
- Snabbare är bättre. Detta är inte nödvändigtvis ett ”smidigt” tillvägagångssätt och kan bara få dig till fel ställe snabbare.
- "Gör det rätt första gången" -mentaliteten. Detta naiva tillvägagångssätt insisterar på att närvaron av kvalitetskontroll bör minska behovet av testning.
- Brist på ägande. Detta liknar den tidigare kulan. Tanken är att "våra användare kommer att testa det." Detta tillvägagångssätt kan leda till missnöjda användare och massor av supportbiljetter.
- Brist på verktyg. Missuppfattningen att de inte har rätt teknik för testning.
- Bristande förståelse för tester. Till exempel,
- Testning bör utvärdera dataens noggrannhet och giltighet, datakonsistens, aktualitet av data, leveransprestanda och enkel användning av leveransmekanismen.
- Testning under ett BI -projekt kan innefatta regressionstest, enhetstestning, röktestning, integrationstestning, test av användaracceptans, ad hoc -testning, stress-/skalbarhetstestning, systemprestanda.
Vad kostar det att INTE testa BI?
- Ineffektiva mönster. Dålig arkitektur kanske inte upptäcks om testning ignoreras. Designfrågor kan bidra till användbarhet, prestanda, återanvändning samt underhåll och underhåll.
- Dataintegritetsproblem. Datakorruption eller utmaningar med datavetenskap kan leda till brist på förtroende för siffrorna.
- Datavalideringsproblem. Beslut som fattas om dålig data kan vara förödande för verksamheten. Det finns inget värre än att försöka hantera med mätvärden som är baserade på felaktig information.
- Minskad användarantagande. Om siffrorna inte stämmer, eller om programmet inte är användarvänligt, kommer din användargrupp bara inte att använda din glänsande nya företags BI-programvara.
- Ökade kostnader på grund av bristande standardisering.
- Ökade kostnader för att reparera defekter i senare skeden av BI -utvecklingens livscykel. Alla problem som upptäcks bortom kravfasen kommer att kosta exponentiellt mer än om de upptäcktes tidigare.
Nu när vi har lagt fram varför organisationer kanske inte testar och de fallgropar som uppstår när du inte testar BI, låt oss titta på några studier om testning inom mjukvaruutveckling.
Studier visar att testa din BI -plattform sparar pengar!
En studie av 139 nordamerikanska företag varierar i storlek från 250 till 10,000 5.2 anställda, rapporterade årliga felsökningskostnader på 22 miljoner dollar till XNUMX miljoner dollar. Detta kostnadsintervall återspeglar organisationer som returnera inte har automatiserad enhetstestning på plats. Separat fann forskning från IBM och Microsoft det med automatiserad enhetstestning på plats kan antalet defekter minskas med mellan 62% och 91%. Det betyder att dollar som spenderas på felsökning kan reduceras från $ 5M - $ 22M till $ 0.5M till $ 8.4M. Det är en enorm besparing!
Kostnader för att åtgärda fel snabbt eskalera.
En uppsats om framgångsrik mjukvaruutvecklingstaktik visar att de flesta fel görs tidigt i utvecklingscykeln och att ju längre du väntar på att upptäcka och korrigera, desto högre kostar det dig att åtgärda. Så det krävs ingen raketforskare för att dra den uppenbara slutsatsen att ju tidigare fel upptäcks och åtgärdas, desto bättre. På tal om raketvetenskap händer det bara att NASA publicerade ett papper om just det - "Felkostnadsupptrappning genom projektets livscykel."
Det är intuitivt att kostnaderna för att åtgärda fel ökar när livscykeln utvecklas. NASA -studien utfördes för att avgöra hur snabbt den relativa kostnaden för att fixa fel som upptäcktes fortskrider. Denna studie använde tre tillvägagångssätt för att bestämma de relativa kostnaderna: bottom-up-kostnadsmetoden, metoden för total kostnadsfördelning och hypotetisk projektmetod uppifrån och ner. De tillvägagångssätt och resultat som beskrivs i detta dokument förutsätter utveckling av ett hårdvara/mjukvarusystem med projektegenskaper som liknar dem som används vid utvecklingen av ett stort, komplext rymdfarkoster, ett militärt flygplan eller en liten kommunikationssatellit. Resultaten visar i vilken grad kostnaderna eskalerar, eftersom fel upptäcks och åtgärdas vid senare och senare faser i projektets livscykel. Denna studie är representativ för annan forskning som har gjorts.
Från diagrammet ovan visar forskning från TRW, IBM, GTE, Bell Labs, TDC och andra kostnaden för att åtgärda fel under de olika utvecklingsfaserna:
- Kostnaden för att åtgärda ett fel som upptäcktes under kravfasen definieras som 1 enhet
- Kostnaden för att åtgärda det felet om det hittas under designfasen är dubbla den där
- Vid kod- och felsökningsfasen är kostnaden för att åtgärda felet 3 enheter
- Vid enhetstest och integreringsfas blir kostnaden för att åtgärda felet 5
- Vid systemtestfasfasen, kostnaden för att åtgärda felet hoppar till 20
- Och när systemet väl är i driftfasen, den relativa kostnaden för att rätta till felet har stigit till 98, nästan 100 gånger kostnaden för att rätta till felet om det finns i kravfasen!
Slutsatsen är att det är mycket dyrare att reparera defekter om de inte fångas tidigt.
Slutsatser
Betydande forskning har bedrivits som visar värdet av tidig och kontinuerlig testning inom mjukvaruutveckling. Vi i BI -gemenskapen kan lära av våra vänner inom mjukvaruutveckling. Även om den mest formella forskningen har gjorts relaterad till mjukvaruutveckling kan liknande slutsatser dras om BI -utveckling. Värdet av testning är obestridligt, men många organisationer har varit långsammare att dra nytta av formell testning av sin BI -miljö och integrera testning i deras BI -utvecklingsprocesser. Kostnaderna för inte tester är verkliga. Riskerna i samband med inte tester är verkliga.
Vill du se några automatiska Cognos -tester i aktion? Titta på videorna på vår spellista av klicka här!
