Bijgewerkt augustus 28, 2019
Testen wordt al sinds de ontwikkeling van software op grote schaal toegepast als onderdeel van softwareontwikkeling. Business Intelligence (BI) is echter trager geweest om testen toe te passen als een geïntegreerd onderdeel van de ontwikkeling in BI-software zoals IBM Cognos. Laten we eens kijken waarom BI trager is geweest met het toepassen van testpraktijken en wat de gevolgen zijn van: NIET testen.
Waarom organisaties BI niet testen...
- Tijdsdruk. BI-projecten staan constant onder druk om sneller opgeleverd te worden. Wat sommige organisaties zich misschien niet realiseren, is dat testen de gemakkelijkste fase is om tijd te besparen.
- Budget beperkingen. De gedachte is dat testen te duur is en geen testteam kan inzetten.
- Sneller is beter. Dit is niet per se een "agile" benadering en kan u alleen maar sneller op de verkeerde plaats brengen.
- De "doe het de eerste keer goed" mentaliteit. Deze naïeve benadering dringt erop aan dat de aanwezigheid van kwaliteitscontrole de noodzaak van testen zou moeten verminderen.
- Gebrek aan eigendom. Dit is vergelijkbaar met de vorige bullet. De gedachte is dat "onze gebruikers het zullen testen". Deze aanpak kan leiden tot ontevreden gebruikers en veel supporttickets.
- Gebrek aan gereedschap. De misvatting dat ze niet de juiste technologie hebben om te testen.
- Gebrek aan begrip van testen. Bijvoorbeeld,
- Testen moeten de nauwkeurigheid en validiteit van gegevens, gegevensconsistentie, tijdigheid van gegevens, leveringsprestaties en gebruiksgemak van het leveringsmechanisme evalueren.
- Testen tijdens een BI-project kunnen regressietests, unittests, rooktests, integratietests, gebruikersacceptatietests, ad-hoctests, stress-/schaalbaarheidstesten en systeemprestatietests omvatten.
Wat zijn de kosten van het NIET testen van BI?
- Inefficiënte ontwerpen. Slechte architectuur wordt mogelijk niet ontdekt als testen wordt genegeerd. Ontwerpproblemen kunnen bijdragen aan bruikbaarheid, prestaties, hergebruik, maar ook aan onderhoud en onderhoud.
- Problemen met gegevensintegriteit. Gegevenscorruptie of uitdagingen op het gebied van gegevensafstamming kunnen leiden tot een gebrek aan vertrouwen in de cijfers.
- Problemen met gegevensvalidatie. Beslissingen die worden genomen over slechte gegevens kunnen verwoestend zijn voor het bedrijf. Er is niets erger dan te proberen te beheren op basis van statistieken die zijn gebaseerd op onjuiste informatie.
- Verminderde gebruikersacceptatie. Als de cijfers niet kloppen, of als de applicatie niet gebruiksvriendelijk is, zal uw gebruikersgemeenschap uw glimmende nieuwe enterprise BI-software gewoon niet gebruiken.
- Hogere kosten door gebrek aan standaardisatie.
- Hogere kosten voor het repareren van defecten in latere stadia van de levenscyclus van BI-ontwikkeling. Alle problemen die buiten de vereistenfase worden ontdekt, zullen exponentieel meer kosten dan wanneer ze eerder werden ontdekt.
Nu we hebben uitgelegd waarom organisaties misschien niet testen en wat de valkuilen zijn als je BI niet test, gaan we eens kijken naar enkele onderzoeken naar testen in softwareontwikkeling.
Studies tonen aan dat het testen van uw BI-platform geld bespaart!
Eén onderzoek onder 139 Noord-Amerikaanse bedrijven variërend in grootte van 250 tot 10,000 werknemers, rapporteerden jaarlijkse debugging-kosten van $ 5.2 miljoen tot $ 22 miljoen. Dit kostenbereik weerspiegelt organisaties die: geen beschikken over geautomatiseerde unit testing. Afzonderlijk bleek uit onderzoek van IBM en Microsoft dat: Met geautomatiseerde unit-testing aanwezig, het aantal defecten kan worden verminderd met tussen 62% en 91%. Dit betekent dat de dollars die aan foutopsporing worden uitgegeven, kunnen worden teruggebracht van het bereik van $ 5 miljoen - $ 22 miljoen naar het bereik van $ 0.5 miljoen tot $ 8.4 miljoen. Dat is een enorme besparing!
Kosten om fouten snel op te lossen escaleren.
Een paper over succesvolle softwareontwikkelingstactieken laat zien dat de meeste fouten vroeg in de ontwikkelingscyclus worden gemaakt en dat hoe langer u wacht met detecteren en corrigeren, hoe hoger het herstel kost. Er is dus geen raketgeleerde voor nodig om de voor de hand liggende conclusie te trekken dat hoe eerder fouten worden ontdekt en verholpen, hoe beter. Over raketwetenschap gesproken, het is gewoon zo dat NASA een paper heeft gepubliceerd over precies dat - "Foutkostenescalatie door de levenscyclus van het project."
Het is intuïtief dat de kosten om fouten te herstellen toenemen naarmate de ontwikkelingscyclus vordert. De NASA-studie werd uitgevoerd om te bepalen hoe snel de relatieve kosten van het oplossen van ontdekte fouten vorderen. In dit onderzoek zijn drie benaderingen gebruikt om de relatieve kosten te bepalen: de bottom-up kostenmethode, de totale kostenanalysemethode en de top-down hypothetische projectmethode. De benaderingen en resultaten die in dit document worden beschreven, veronderstellen de ontwikkeling van een hardware/softwaresysteem met projectkenmerken die vergelijkbaar zijn met die welke worden gebruikt bij de ontwikkeling van een groot, complex ruimtevaartuig, een militair vliegtuig of een kleine communicatiesatelliet. De resultaten laten zien in welke mate de kosten escaleren, omdat fouten in latere en latere fasen van de projectlevenscyclus worden ontdekt en verholpen. Dit onderzoek is representatief voor ander onderzoek dat is gedaan.
Uit de bovenstaande grafiek blijkt uit onderzoek van TRW, IBM, GTE, Bell Labs, TDC en anderen de kosten van het oplossen van fouten tijdens de verschillende ontwikkelingsfasen:
- De kosten voor het herstellen van een tijdens de vereistenfase ontdekte fout worden gedefinieerd als: 1 eenheid
- De kosten om die fout op te lossen als ze tijdens de ontwerpfase worden gevonden, zijn: verdubbelen dat
- In de code- en debugfase zijn de kosten om de fout te herstellen: 3 eenheden
- In de eenheidstest- en integratiefase worden de kosten om de fout te herstellen: 5
- In de fase van de systeemtest, de kosten om de fout te herstellen springen naar 20
- En als het systeem eenmaal in de exploitatiefase is, de relatieve kosten om de fout te corrigeren zijn gestegen tot 98, bijna 100 keer de kosten van het corrigeren van de fout als ze in de vereistenfase worden gevonden!
Het komt erop neer dat het veel duurder is om defecten te repareren als ze niet vroeg worden opgemerkt.
Conclusies
Er is veel onderzoek gedaan dat de waarde van vroeg en continu testen bij softwareontwikkeling aantoont. Wij, in de BI-gemeenschap, kunnen leren van onze vrienden in softwareontwikkeling. Hoewel het meeste formele onderzoek is gedaan met betrekking tot softwareontwikkeling, kunnen soortgelijke conclusies worden getrokken over BI-ontwikkeling. De waarde van testen staat buiten kijf, maar veel organisaties hebben trager geprofiteerd van het formele testen van hun BI-omgeving en het integreren van testen in hun BI-ontwikkelingsprocessen. De kosten van niet testen is echt. De risico's die gepaard gaan met: niet testen is echt.
Wilt u enkele geautomatiseerde Cognos-tests in actie zien? Bekijk de video's op onze playlist door hier te klikken!
