Cognos in stroški NE TESTIRANJA BI

by December 4, 2014Cognos Analytics, MotioCI, Testiranje0 komentarji

Posodobljeno avgust 28, 2019

Testiranje je bilo široko uporabljeno kot del razvoja programske opreme odkar je bila razvita programska oprema. Poslovna inteligenca (BI) je počasneje sprejela testiranje kot sestavni del razvoja programske opreme BI, kot je IBM Cognos. Raziščimo, zakaj je BI počasneje sprejemal preskusne prakse in posledice NE testiranje.

Zakaj organizacije ne testirajo BI ...

  • Časovne omejitve. Projekti BI so pod nenehnim pritiskom, da jih je mogoče hitreje izvesti. Nekatere organizacije se morda ne zavedajo, da je najlažja faza za skrajšanje časa testiranje.
  • Proračunske omejitve. Misli se, da je testiranje predrago in ne more posvetiti testne ekipe.
  • Hitreje je bolje. To ni nujno "agilni" pristop in vas lahko le hitreje pripelje na napačno mesto.

Povoj-Citat

  • Miselnost "samo naredi pravilno prvič". Ta naiven pristop vztraja, da bi morala prisotnost nadzora kakovosti zmanjšati potrebo po testiranju.
  • Pomanjkanje lastništva. To je podobno prejšnji točki. Misli se, da bodo "naši uporabniki to preizkusili." Ta pristop lahko povzroči nesrečne uporabnike in veliko vstopnic za podporo.
  • Pomanjkanje orodij. Napačno prepričanje, da nimajo ustrezne tehnologije za testiranje.
  • Nerazumevanje testiranja. Na primer,
    • Testiranje bi moralo oceniti točnost in veljavnost podatkov, doslednost podatkov, pravočasnost podatkov, uspešnost dostave in enostavnost uporabe mehanizma za dostavo.
    • Testiranje med projektom BI lahko vključuje regresijsko testiranje, enotno testiranje, testiranje dima, integracijsko testiranje, testiranje sprejemljivosti uporabnikov, ad hoc testiranje, testiranje obremenitve/razširljivosti, testiranje delovanja sistema.

Kakšni so stroški NI TESTIRANJA BI?

  • Neučinkovite oblike. Slaba arhitektura morda ne bo odkrita, če preskušanja ne upoštevate. Oblikovalske težave lahko prispevajo k uporabnosti, zmogljivosti, ponovni uporabi ter vzdrževanju in vzdrževanju.
  • Težave pri celovitosti podatkov. Poškodovanje podatkov ali izzivi rodov podatkov lahko privedejo do pomanjkanja zaupanja v številke.
  • Težave pri preverjanju veljavnosti podatkov. Odločitve o slabih podatkih so lahko za podjetje uničujoče. Ni hujšega kot poskušati upravljati z meritvami, ki temeljijo na napačnih informacijah.

Risanka Dilbert- podatki so napačni

  • Zmanjšano število uporabnikov. Če številke niso pravilne ali če aplikacija ni uporabniku prijazna, vaša uporabniška skupnost preprosto ne bo uporabljala vaše svetleče nove poslovne programske opreme za podjetja.
  • Povečani stroški zaradi pomanjkanja standardizacije.
  • Povečani stroški odpravljanja napak v kasnejših fazah življenjskega cikla razvoja BI. Vsa vprašanja, odkrita zunaj faze zahtev, bodo stala eksponentno več, kot če bi bila odkrita prej.

Zdaj, ko smo ugotovili, zakaj organizacije morda ne testirajo, in pasti, ki se pojavijo, ko ne preizkusite BI, poglejmo nekaj študij o testiranju pri razvoju programske opreme.

Študije kažejo, da testiranje vaše BI platforme prihrani denar!

Ena študija 139 severnoameriških podjetij v velikosti od 250 do 10,000 zaposlenih, poročali o letnih stroških odpravljanja napak od 5.2 do 22 milijonov USD. Ta razpon stroškov odraža organizacije, ki ne imajo avtomatizirano testiranje enot. Ločeno sta to ugotovili raziskavi IBM -a in Microsofta z avtomatsko testiranje enot, število napak se lahko zmanjša za 62% do 91%. To pomeni, da bi se lahko dolarji, porabljeni za odpravljanje napak, zmanjšali z območja od 5 do 22 milijonov USD na območje od 0.5 do 8.4 milijona USD. To je ogromen prihranek!

Odpravljanje napak pri stroških brez testiranja in s preskušanjem

Stroški hitrega odpravljanja napak.

Dokument o uspešnih taktikah razvoja programske opreme dokazuje, da se večina napak zgodi v zgodnjem razvojnem ciklu in da dlje ko čakate na odkrivanje in odpravljanje, višje vas stane popraviti. Zato raketni znanstvenik ne potrebuje očitnega zaključka, da prej ko bodo napake odkrite in odpravljene, tem bolje. Ko že govorimo o raketni znanosti, se je zgodilo, da je NASA objavila članek ravno o tem - "Naraščanje stroškov napak skozi življenjski cikel projekta."

Intuitivno je, da se stroški odpravljanja napak povečujejo z napredovanjem življenjskega cikla razvoja. Študija NASA je bila izvedena, da bi ugotovili, kako hitro napredujejo relativni stroški odpravljanja odkritih napak. Ta študija je uporabila tri pristope za določanje relativnih stroškov: metodo stroškov od spodaj navzgor, metodo razčlenitve celotnih stroškov in metodo hipotetičnega projekta od zgoraj navzdol. Pristopi in rezultati, opisani v tem prispevku, predvidevajo razvoj strojno -programskega sistema s projektnimi značilnostmi, podobnimi tistim, ki se uporabljajo pri razvoju velikega, kompleksnega vesoljskega plovila, vojaškega letala ali majhnega komunikacijskega satelita. Rezultati kažejo stopnjo naraščanja stroškov, saj se napake odkrijejo in odpravijo v poznejših in poznejših fazah življenjskega cikla projekta. Ta študija je reprezentativna za druge raziskave, ki so bile opravljene.

SDLC Stroški popravka lestvice napak

Iz zgornje tabele raziskave TRW, IBM, GTE, Bell Labs, TDC in drugih kažejo stroške odpravljanja napak v različnih razvojnih fazah:

  • Stroški odpravljanja napake, odkrite v fazi zahtev, so opredeljeni kot 1 enota
  • Stroški odprave te napake so, če jih odkrijete v fazi načrtovanja podvojila da
  • V fazi kode in odpravljanja napak so stroški za odpravo napake 3 enote
  • V fazi preizkusa enote in integracije nastanejo stroški za odpravo napake 5
  • V fazi preskušanja sistemov, stroški za odpravo napake skočijo na 20
  • Ko je sistem v fazi delovanja, relativni stroški popravka napake so se povečali na 98, kar je skoraj 100 -kratnik stroškov popravka napake, če jih najdemo v fazi zahtev!

Bistvo je, da je popravilo napak veliko dražje, če jih ne odkrijete zgodaj.

Sklepi

Izvedene so bile pomembne raziskave, ki dokazujejo vrednost zgodnjega in stalnega testiranja pri razvoju programske opreme. V skupnosti BI se lahko od prijateljev učimo pri razvoju programske opreme. Čeprav je bila večina uradnih raziskav opravljenih v zvezi z razvojem programske opreme, je mogoče do podobnih zaključkov priti do razvoja BI. Vrednost testiranja je nesporna, vendar so mnoge organizacije počasneje izkoristile formalno testiranje svojega okolja BI in vključile testiranje v svoje razvojne procese BI. Stroški za ne testiranje je resnično. Tveganja, povezana z ne testiranje je resnično.

Želite videti nekaj avtomatiziranega testiranja Cognos v akciji? Oglejte si videoposnetke na našem seznamu predvajanja do kliknite tukaj!

MotioCI
MotioCI Namigi in triki
MotioCI Namigi in triki

MotioCI Namigi in triki

MotioCI Nasveti in triki Najljubše funkcije tistih, ki vam prinesejo MotioCI Smo vprašali Motiorazvijalci programske opreme, strokovnjaki za podporo, ekipa za implementacijo, preizkuševalci QA, prodaja in vodstvo katere so njihove najljubše funkcije MotioCI so. Prosili smo jih, naj...

Preberi več

MotioCI
MotioCI Poročila
MotioCI Namenska poročila

MotioCI Namenska poročila

MotioCI Poročanje Poročila, zasnovana z namenom – pomagati odgovoriti na določena vprašanja, ki jih imajo uporabniki ozadje Vse MotioCI poročila so bila pred kratkim preoblikovana z enim samim ciljem - vsako poročilo bi moralo odgovoriti na določeno vprašanje ali vprašanja, ki jih...

Preberi več