CASE + CAST = APS

November 1991

Temeljite spremembe pri poslovanju so v preteklih letih doletele prenekatero firmo, predvsem z uporabo računalniško podprtih aplikativnih sistemov. Spoznanje, da računalnik ne omogoča v najboljšem primeru le podporo operativnemu delu, kot moderen knjigovodski stroj, je danes prisotno v mnogih podjetjih, ki se borijo za svoj tržni delež. Poudarek je na sprotnih (online) aplikativnih programskih sistemov (APS).

APS in ustrezna računalniška podpora postajata vse bolj zahtevni in kompleksni nalogi ter občasno presegata trenutne zmogljivosti, tako človeške kakor tudi strojne. Dodatna komplikacija in nevarnost je tudi hitrost, ki jo morajo dosegati ljudje, APS in strojna oprema s ciljem spremljanja tekočega dogajanja in konkurenčnosti.

To je čas, ko se je pojavil CASE (Computer Aided Software Engineering) kot ključ, nekateri so ga imenovali kar čudežni, ki bo rešil vse ali skoraj vse probleme in težave pri razvoju in vzdrževanju APS. Lahko se je našlo celo ekonomsko opravičilo, saj so reklame in oglasi za CASE orodja obljubljali mnogo, predvsem za majhen denar.

Jasno je, da od celotne in vsestranske rešitve CASE v praksi pokriva le zgodnje načrtovanje in razvoj APS v njenem celotnem življenjskem ciklusu. Za postopke testiranja, ki so izjemno pomembni za izdelavo čiste in zaupanja vredne programske kode pred samo uporabo v rednem delu, je CASE naredil bolj malo. CASE sam po sebi in kot tak ne more izdelati kvalitetnega in zanesljivega APS.

Ali je morda CAST (Computer Aided Software Testing) manjkajoči člen za normalno pot pri razvoju, testiranju in uvajanju orodij za celovite (integralne) pakete? Vsekakor sta CASE in CAST izdelana približno hkrati. Toda poznavanje in razumevanje obeh je bistveno različno.

CASE je način - metodologija za avtomatično in kompleksno testiranje vseh funkcij pri razvoju novega ali spreminjanju obstoječega APS. S pojavom CASE tehnologije se bistveno povečala hitrost izdelave novih in predvsem zahtevnost APS. To pa je tudi povečalo problemi testiranja, ki je bil potisnjen na rob razvoja in uporabe APS.

Nujno zlo med izdelavo APS je testiranje, čeprav proizvajalci CASE opreme o nepogrešljivosti ravno njihovega produkta vedo povedati vse najboljše. Tragično je, ko se slabo testirani programi prenesejo v produkcijo. Lep primer je firma American Airlines, ki je zaradi programske napake v sistemu rezervacij (booking) v pičlih 3 (treh) mesecih imela ca. 50 mio USS izgube! Prav zato, da se prepreči podobne napake, so mnogi pripravljeni investirati v programsko opremo za testiranje.

In kje je rešitev? Odgovor je treba iskati tudi v boljšem vzdrževanju APS. Znani so podatki, da se tudi do 50% vseh stroškov neke APS porabi za njeno vzdrževanje. To ni le nesmiselno in absurdno temveč tudi neuspeh za organizacijo in izdelavo samega APS. Redki so uporabniki, ki realno ocenijo, da je testiranje APS zelo pomemben korak pri razvoju APS. Vsak napor in strošek se kasneje obrestujeta.

Trditev, da je testiranje med razvojem nepotrebno (podaljšuje čas izdelave, viša stroške), ni resna. Če se testira sproti in med razvijanjem, se vse odkrite napake popravi takoj in ne šele pri prekinitvah med rednim delom.

CAST naredi testiranje bolj vodljivo, uspešno in omogoča uporabniku izdelavo načrta testiranja v vsakem trenutku razvoja ali uporabe APS. CAST vsebuje štiri tehnike testiranja: (1) diagnostiko napak, (2) interaktivno popravljanje, (3) avtomatizirano testiranje in (4) uporaba podatkov - datotek. V CAST okolici so na razpolago orodja, ki skupaj s CASE omogočajo dobro in kvalitetno izdelavo APS.

Razvoj aplikacijskih programskih sistemov z uporabo CASE in podobni orodij se ocenjuje in meri z meseci in leti oziroma  kako hitro se izdela APS v primerjavi z običajnimi metodami. Nasprotno, pri CAST uporabljamo minute in kvečjemu še ure kot mero uspešnosti pri odkrivanju napak. Nekatere APS lahko obsegajo nekaj deset ali celo sto sprotnih, on-line, interaktivnih programov, ki jih je treba testirati. Kar nekaj pripomočkov je na razpolago, ki olajšajo to mukotrpno delo.

Običajno lahko celotno testiranje opredelimo z naslednjimi štirimi metodami:

1. diagnostika napak,
2. interaktivno popravljanje,
3. avtomatizirano testiranje,
4. uporaba podatkov - datotek.

Bistveni postopki obsegajo naslednjih pet korakov:

1. testiranje posameznega programa,
2. združevanje več že preizkušenih programov v zaokroženo celoto,
3. spreminjanje programov, da se prepričamo v predvidene (napačne ali pravilne) rezultate,
4. vzporedno delovanje dveh ali več programov in dveh ali več uporabnikov istega programa ter opazovanje vseh negativnih efektov, pa čeprav takšen način dela morda nikakor ni možen pri rednem delu,
5. obremenitev SW in HW kot v normalnem delovanju.

Eden med pomembnimi in bistvenimi faktorji aplikativnega testiranja je tudi delovanje v ekstremnih pogojih. Tako kot avtomobilska industrija testira in preobremenjuje nove izdelke pred redno proizvodnjo in prodajo, tako je treba tudi APS »obremeniti« - intenzivna uporaba, maksimalno število uporabnikov, velike količine podatkov in podobno.

Celovito testiranje pa ni prisotno le med razvojem programov in APS. Upoštevati je treba tudi hiter razvoj strojne opreme. Res je, da je kompatibilnost od starega na novo zagotovljena že s strani proizvajalca strojne opreme. Vprašanje pa je, če neki stari APS res dobro izkorišča novo strojno opremo. Ko pride do odločitve, da se mora APS prilagoditi novim značilnostim strojne opreme, potem to ne sme na noben način vplivati na delo uporabnikov - spremembe ne smejo niti zaznati, kaj šele, da so pri tem moteni.

Tako zanesljiv in gladek prehod na spremenjeni APS lahko olajša tudi uporaba CAST pripomočkov. Tehnično gledano, uporaba CAST ni težka ali problematična. Največji problem je v tem, da se vsi, ponudniki in uporabniki CASE, ne zavedajo dovolj kaj je učinkovito testiranje. Načrt testiranja in testni podatki morajo biti določeni v vsaki fazi razvoja APS. Kot rečeno, hierarhija testiranja se prične pri posameznem programu in se zaključi kot vsestranski test celotnega APS v resnični okolici delovanja.

Prednosti pripomočkov CAST so nesporne: bistveno skrajšajo čas izdelave APS, odkrijejo napake, vse skupaj pa poceni celoten »proračun« določenega APS. Vsekakor ni razlogov za tekmovanje med CASE in CAST. CAST je dopolnilo CASE, oba skupaj nudita čist dizajn in razvojne prednosti ter zmanjšujeta morebitne možnosti napak - rezultat je boljši APS. Poudarek mora biti na celotnem področju uspešnosti: hiter razvoj, dobro testiranje, zadovoljstvo končnega uporabnika ter natančnost, točnost in ažurnost podatkov.