Cognos i cijena NE TESTIRANJA BI

by Decembar 4, 2014Cognos Analytics, MotioCI, testiranje0 komentari

Ažurirano avgust 28, 2019

Testiranje je široko prihvaćeno kao dio razvoja softvera od kada je softver razvijen. Poslovna inteligencija (BI) je, međutim, sporije usvajala testiranje kao integrirani dio razvoja BI softvera, poput IBM Cognosa. Hajde da istražimo zašto je BI sporije usvajao prakse testiranja i posljedice NIJE testiranje.

Zašto organizacije ne testiraju BI ...

  • Vremenska ograničenja. BI projekti su pod stalnim pritiskom da se brže isporuče. Ono što neke organizacije možda ne shvaćaju je da je testiranje najjednostavnija faza za smanjenje vremena.
  • Budžetska ograničenja. Misli se da je testiranje preskupo i da ne može posvetiti tim za testiranje.
  • Brže je bolje. Ovo nije nužno „agilni“ pristup i može vas samo brže odvesti na pogrešno mjesto.

Zavoj-Citat

  • Mentalitet „samo uradi prvi put“. Ovaj naivni pristup inzistira na tome da bi prisutnost kontrole kvalitete trebala smanjiti potrebu za testiranjem.
  • Nedostatak vlasništva. Ovo je slično prethodnom metku. Misli se da će "naši korisnici to testirati". Ovaj pristup može dovesti do nezadovoljnih korisnika i puno ulaznica za podršku.
  • Nedostatak alata. Zabluda da nemaju odgovarajuću tehnologiju za testiranje.
  • Nerazumevanje testiranja. Na primjer,
    • Testiranje bi trebalo procijeniti tačnost i valjanost podataka, dosljednost podataka, pravovremenost podataka, performanse isporuke i jednostavnost korištenja mehanizma isporuke.
    • Testiranje tokom BI projekta može uključivati ​​regresijsko testiranje, testiranje jedinice, testiranje dima, testiranje integracije, testiranje prihvatljivosti korisnika, ad hoc testiranje, testiranje naprezanja/skalabilnosti, testiranje performansi sistema.

Koliki su troškovi NE TESTIRANJA BI?

  • Neefikasni dizajni. Loša arhitektura se možda neće otkriti ako se zanemari testiranje. Problemi s dizajnom mogu pridonijeti upotrebljivosti, performansama, ponovnoj upotrebi, kao i održavanju i održavanju.
  • Problemi sa integritetom podataka. Oštećenje podataka ili izazovi loze podataka mogu dovesti do nedostatka povjerenja u brojeve.
  • Problemi s provjerom valjanosti podataka. Odluke o lošim podacima mogu biti pogubne za poslovanje. Ne postoji ništa gore od pokušaja upravljanja pomoću mjernih podataka koji se temelje na netočnim podacima.

Dilbert karikatura- podaci su pogrešni

  • Smanjeno usvajanje korisnika. Ako brojevi nisu tačni ili ako aplikacija nije prilagođena korisnicima, vaša korisnička zajednica jednostavno neće koristiti vaš sjajni novi poslovni BI softver.
  • Povećani troškovi zbog nedostatka standardizacije.
  • Povećani troškovi za popravljanje nedostataka u kasnijim fazama životnog ciklusa razvoja BI. Bilo koji problemi otkriveni izvan faze zahtjeva koštat će eksponencijalno više nego ako su otkriveni ranije.

Sada kada smo izložili zašto organizacije možda ne testiraju i zamke koje se javljaju kada ne testirate BI, pogledajmo neke studije o testiranju u razvoju softvera.

Studije pokazuju da testiranje vaše BI platforme štedi novac!

Jedna studija o 139 sjevernoameričkih kompanija u veličini od 250 do 10,000 zaposlenih, izvijestili su o godišnjim troškovima otklanjanja grešaka od 5.2 do 22 miliona USD. Ovaj raspon troškova odražava organizacije koje nemoj imaju automatsko testiranje jedinica. Odvojeno, istraživanje IBM -a i Microsofta otkrilo je to sa automatizirano testiranje jedinica, broj grešaka može se smanjiti za između 62% i 91%. To znači da bi se dolari potrošeni na otklanjanje grešaka mogli smanjiti sa raspona od 5 do 22 miliona USD na raspon od 0.5 do 8.4 miliona USD. To je ogromna ušteda!

Otklanjanje grešaka bez testiranja i sa testiranjem

Brzo eskaliraju troškovi za ispravljanje grešaka.

Rad o uspješnim taktikama razvoja softvera pokazuje da se većina grešaka pravi rano u razvojnom ciklusu i da što duže čekate na otkrivanje i ispravljanje, to vas više košta popraviti. Dakle, nije potreban raketni naučnik da izvede očigledan zaključak da što prije greške budu otkrivene i popravljene, to bolje. Kad smo već kod raketne znanosti, slučajno se dogodilo da je NASA objavila rad upravo o tome - “Eskalacija troškova greške kroz životni ciklus projekta.”

Intuitivno je da se troškovi ispravljanja grešaka povećavaju kako životni ciklus razvoja napreduje. Istraživanje NASA -e provedeno je kako bi se utvrdilo koliko brzo napreduje relativna cijena popravljanja otkrivenih grešaka. Ova studija koristila je tri pristupa za određivanje relativnih troškova: metodu troškova odozdo prema gore, metodu raščlanjivanja ukupnih troškova i metodu hipotetičkog projekta odozgo prema dolje. Pristupi i rezultati opisani u ovom radu pretpostavljaju razvoj hardverskog/softverskog sistema koji ima projektne karakteristike slične onima koje se koriste u razvoju velike, složene svemirske letjelice, vojnog aviona ili malog komunikacionog satelita. Rezultati pokazuju stepen do kojeg troškovi eskaliraju jer se greške otkrivaju i ispravljaju u kasnijim i kasnijim fazama životnog ciklusa projekta. Ova studija je reprezentativna za druga istraživanja koja su sprovedena.

SDLC skala troškova za ispravljanje grešaka

Iz gornjeg grafikona, istraživanje TRW -a, IBM -a, GTE -a, Bell Labs -a, TDC -a i drugih pokazuje cijenu popravljanja grešaka u različitim razvojnim fazama:

  • Cijena popravljanja greške otkrivene tokom faze zahtjeva definirana je kao 1 jedinica
  • Troškovi popravljanja te greške ako se otkriju u fazi projektiranja su dvostruko da
  • U fazi koda i otklanjanja grešaka, troškovi popravljanja greške su 3 jedinice
  • U fazi jediničnog testiranja i integracije, troškovi popravljanja greške postaju veći 5
  • U fazi ispitivanja sistema, troškovi popravljanja greške skoče na 20
  • A kada sistem bude u operativnoj fazi, relativni troškovi ispravljanja greške porasli su na 98, gotovo 100 puta više od cijene ispravljanja greške ako se nađu u fazi zahtjeva!

Zaključak je da je mnogo skuplje popraviti nedostatke ako se ne otkriju rano.

zaključci

Sprovedena su značajna istraživanja koja pokazuju vrijednost ranog i kontinuiranog testiranja u razvoju softvera. Mi, u BI zajednici, možemo učiti od svojih prijatelja u razvoju softvera. Iako je većina formalnih istraživanja provedena u vezi s razvojem softvera, mogu se izvesti slični zaključci o razvoju BI. Vrijednost testiranja je neosporna, ali mnoge organizacije su sporije iskorištavale formalno testiranje svog BI okruženja i integrirale testiranje u svoje razvojne procese. Troškovi ne testiranje je stvarno. Rizici povezani sa ne testiranje je stvarno.

Želite vidjeti neko automatizirano Cognos testiranje na djelu? Gledajte video zapise na našoj listi za reprodukciju do klikom ovdje!

MotioCI
MotioCI Savjeti i trikovi
MotioCI Savjeti i trikovi

MotioCI Savjeti i trikovi

MotioCI Savjeti i trikovi Omiljene karakteristike onih koji vam donose MotioCI Pitali smo Motioprogrameri, softverski inženjeri, stručnjaci za podršku, tim za implementaciju, QA testeri, prodaja i menadžment šta su njihove omiljene karakteristike MotioCI su. Zamolili smo ih da...

Čitaj više