Pregled načina testiranja moderniziranog Delphi softvera I najava knjige “Delphi Legacy Projects: Strategies And Survival Guide”.
Napisao Hagop Panosian i prvi puta objavljeno na blogs.embarcadero.com
Testiranje softvera jedan je od stupova životnog ciklusa razvoja softvera ili SDLC (Plan – Design – Implement – Test – Deploy – Maintenance). Cilj SDLC-a je pomoći programerima da izgrade softver isplativo i minimiziraju povezane rizike, istovremeno osiguravajući da isporučeni proizvod ispunjava očekivanja svojih krajnjih korisnika.
Dijelovi i vrste testiranja softvera
Kao programer softvera, testiranje koda prije objavljivanja zauzima veliki dio vašeg razvojnog procesa. Softver koji je stabilan, pouzdan, funkcionalan i siguran dovest će do visokog zadovoljstva kupaca, održati vaše poslovanje i pomoći u izgradnji vaše reputacije.
Međutim, planiranje i izvršenje projekta testiranja softvera može biti pomalo zastrašujuće. Najbolji način za ublažavanje problema koji se mogu pojaviti u testiranju softvera je učinkovito planiranje i izbor pravih alata i metodologije.
Na vašu strategiju i pristup testiranju softvera utjecat će i ono što testirate u bilo kojem trenutku, ali postoje zajedničke niti svih projekata testiranja softvera. Evo pet najkritičnijih aspekata kojima uspješan projekt testiranja softvera treba za učinkovito upravljanje:
Jasni ciljevi
Jasno definiranje ciljeva i zahtjeva testiranja kao prvog koraka oblikovat će ostatak vašeg pristupa. Koji je cilj koji vaš softver služi korisniku i kakvo iskustvo želite pružiti? Jasni ciljevi pomažu vam da prilagodite projekt testiranja kako biste se usredotočili na određena područja softvera koja želite poboljšati, kao što su performanse, funkcionalnost ili sigurnost.
Pravi pristup
Postoji više od jednog pristupa testiranju softvera, a odabir odgovarajućeg pristupa testiranju koji ima smisla za vaš projekt donijet će očekivane rezultate. Testiranje softvera može biti ručno, automatizirano ili kombinacija ta dva. Razina složenosti vašeg softvera, alati pri ruci i vještine vašeg testnog tima mogu vam pomoći da odlučite koji će pristup najbolje funkcionirati.
Detaljni plan
Sada kada znate koji pristup poduzeti, sljedeći korak je detaljno planiranje projekta testiranja softvera. Dobro pripremljen plan uključuje prikladne scenarije ispitivanja, testne slučajeve i podatke o ispitivanju, kao i potrebne alate i tehnike.
Temeljito izvršenje
Izvršenje uključuje provedbu plana testiranja, praćenje problema kako se pojavljuju i dokumentiranje nalaza i uvida. Važnost odgovarajuće dokumentacije ne može se precijeniti, jer se proteže daleko izvan jednog projekta testiranja i ključna je za cilj kontinuiranog poboljšanja softvera tijekom vremena.
Redovito ispitivanje regresije
Posljednji dio postupka testiranja softvera je regresijsko testiranje. Osiguravanje da aplikacija i dalje funkcionira prema očekivanjima nakon implementacije ažuriranja, promjena ili poboljšanja je ono što regresijsko testiranje radi.
Regresijsko testiranje ključan je zahtjev kada uvodite nove značajke ili ispravljate greške, osiguravajući održavanje stabilnosti i funkcionalnosti značajki vaše aplikacije.
Krajnji cilj – isporuka visokokvalitetnog softvera korisnicima
Testiranje softvera ponekad se može činiti zastrašujućim, ali razbijanje postupka testiranja softvera u njegovih pet gore navedenih komponenti učinit će ga mnogo manje strašnim i pomoći vam da razvijete učinkovitu strategiju testiranja koja će vas mnogo približiti vašem krajnjem cilju stavljanja visokokvalitetnog softvera u ruke korisnika.
Što je u ovom članku
U ovom članku detaljnije ćemo pogledati osnove testiranja softvera. Također gledamo izvrsnu knjigu MVP-a Williama Meyera i kako je možete koristiti za provedbu testiranja bez stresa za projekte objavljivanja, migracije i modernizacije vašeg softvera.
Testiranje softvera: Postavljanje pravih ciljeva
Postavljanje odgovarajućih ciljeva prva je prekretnica u vašem projektu testiranja softvera i izravno će utjecati na kvalitetu ishoda.
Isporuka visokokvalitetnog softvera zahtijeva da se razvojni rad testira u odnosu na nekoliko ključnih ciljeva prije nego što dođe do krajnjeg korisnika, a prvi cilj je utvrditi funkcionira li aplikacija koju ste stvorili kako se očekivalo.
Drugim riječima, testiranje započinje utvrđivanjem radi li aplikacija ono što bi trebala raditi i što njezini krajnji korisnici očekuju od nje. U ovoj fazi gledat ćete tehničke aspekte performansi, kao i jednostavnost korištenja aplikacije, kako biste utvrdili gdje aplikacija može pasti i na drugi način frustrirati svoje korisnike.
Zatim želite implementirati softverske testove koji određuju je li aplikacija sigurna. Sigurnost je najvažnija za dugoročnu održivost i zadovoljstvo kupaca te je trajna velika briga za programere.
Testovi softverske sigurnosti zumiraju ranjivosti aplikacije i ukazuju na načine njihovog popravljanja. Kao i svaki drugi aspekt izrade aplikacija, poboljšanje sigurnosti softvera kontinuirani je ciklus iteracija i testiranja kako bi se odgovorilo na rastuće prijetnje i ranjivosti.
Pouzdanost je treći standard prema kojem je potrebno testirati aplikaciju. Pouzdanost znači da aplikacija ostaje potpuno funkcionalna pod različitim uvjetima. Ispitivanjem pouzdanosti nastoje se utvrditi uvjeti u kojima se aplikacija može srušiti ili ne izvesti kako se očekuje te poduzeti mjere za poboljšanje funkcionalnosti u tim posebnim uvjetima.
Skalabilnost je sljedeća. Testiranje za rastuću upotrebu, promet i radno opterećenje brzo će identificirati točke na kojima se aplikacija uspori pod naprezanjem i eventualno lomi. Ispitivanje skalabilnosti i naknadna poboljšanja osmišljeni su za mjerenje učinkovitosti u sve većoj uporabi u odnosu na utvrđenu minimalnu prihvatljivu referentnu vrijednost.
Da biste pregledali, testiranje softvera nastoji izmjeriti vašu aplikaciju u odnosu na referentne vrijednosti za funkcionalnost, sigurnost, pouzdanost i skalabilnost. To su četiri široka područja za koja se utvrđuju referentne vrijednosti i mjeri uspješnost.
Pravi pristup testiranju: ručno i/ili automatizirano testiranje?
Pristupi testiranju spadaju u jednu od dvije široke kategorije: ručno testiranje i automatizirano testiranje.
U ručnom testiranju softvera programeri ručno implementiraju testne slučajeve kako bi promatrali kako se aplikacija ponaša i sastavljaju izvješća o svojim nalazima.
Ručno testiranje uobičajeno je u ranim fazama životnog ciklusa razvoja softvera, jer ga je lakše implementirati kada je aplikacija još uvijek u fazi izrade prototipa. Također je vrlo relevantan u slučajevima kada značajke koje se testiraju uključuju ljudsku interakciju, a posebno korisnička sučelja.
Jedan od važnih razloga zašto se ručno testiranje preferira u odnosu na druge opcije je taj što se u nekim scenarijima vidi da omogućuje sveobuhvatniju analizu ponašanja aplikacije. Također je pogodno za ad-hoc testiranje zbog svoje fleksibilnosti.
Ručno testiranje softvera razvojnim programerima nudi sljedeće prednosti:
- Fleksibilnost: ručno testiranje omogućuje razvojnim programerima da istraže razne scenarije testiranja, rubne slučajeve i tokove korisnika koje automatizirani pristupi mogu propustiti. Pokrivanje slučajeva koje automatizirani pristupi ne mogu programerima ponuditi veliku fleksibilnost.
- Troškovna učinkovitost: posebno za projekte s relativno malim opsegom kod kojih je ručno testiranje vrlo isplativ pristup. To zahtijeva samo ljudske testere koji mogu obavljati potrebne testove bez dodatnih troškova, bez skupih automatiziranih alata za testiranje.
- Točnost: Vjeruje se da ručno testiranje daje točnije rezultate u određenim situacijama od automatiziranih alata. Primjeri uključuju vizualni dizajn i probleme s korisničkim sučeljem, probleme koje automatizirani alati mogu propustiti.
S druge strane, ručno testiranje može biti dugotrajno, posebno u usporedbi s automatiziranim pristupima testiranju, i zahtijeva visoku razinu stručnosti i iznimnu pažnju prema detaljima. Programeri moraju nastaviti korak po korak dok dokumentiraju rezultate, što zahtijeva vrijeme i produljuje životni ciklus softvera.
Po definiciji je također sklono ljudskoj pogrešci, jer testeri mogu propustiti nedostatke ili napraviti vlastite pogreške tijekom postupka testiranja. Međutim, za mnoge scenarije ručno testiranje je pravi pristup.
Ručno testiranje također može biti ograničenog opsega i promašenih grešaka i drugih problema jer testeri ne mogu učinkovito testirati sve moguće scenarije i testne slučajeve.
Automatizirano testiranje
Automatizirano testiranje softvera uključuje korištenje prilagođenih alata za izvršavanje niza testnih slučajeva za identifikaciju i uklanjanje grešaka i pogrešaka iz isporučenog proizvoda.
Automatizirano testiranje razvojnim programerima nudi sljedeće prednosti:
- Brzina: ključna prednost automatizacije procesa testiranja softvera specijaliziranim alatima je brzina. Automatizirani testovi provode se brzo i provode veliki broj testova u kratkom razdoblju.
- Pokrivenost testnim slučajevima: automatizirani alati provode više testova u širem skupu scenarija od ručnog testiranja. To omogućuje programerima da isprave greške i isporuče pouzdanost u svim zasebnim komponentama svojih aplikacija.
- Dosljedni rezultati: Korištenje automatiziranih alata uklanja rizik od ljudske pogreške i daje dosljedne rezultate svaki put kada se provodi test.
- Mogućnost ponovne uporabe: Testiranje može koristiti testne skripte beskonačan broj puta, što eliminira potrebu za ručnim testiranjem i štedi vrijeme i trud.
- Skalabilnost: automatizirano testiranje može lako obraditi vrlo velike količine podataka i istovremeno testirati mnoge aplikacije i verzije. To omogućuje testerima da po potrebi skaliraju postupak testiranja.
Sve u svemu, automatizirano testiranje mnogo je brže od ručnog pandana, učinkovitije, manje sklono pogreškama od ručnog testiranja i s mnogo nižim zahtjevima za ljudsku uključenost i trud. Automatizacija je strategija testiranja koja uključuje ponavljajuće zadatke i regresijsko testiranje, kao i testiranje aplikacija koje se izvode na različitim platformama i s različitim konfiguracijama. To je zato što se automatizirano testiranje može lako prilagoditi potrebnom ispitnom okruženju, a njegova jednostavnost ponavljanja dugoročno ga čini vrlo isplativim unatoč mogućim visokim početnim troškovima za prave alate.
Nedostaci automatiziranog testiranja softvera su:
- Troškovi: Visoki početni troškovi postavljanja jedan su od nedostataka automatiziranog testiranja softvera, a ti troškovi uključuju instaliranje odgovarajućeg skupa alata i obuku osoblja za njegovo korištenje. Dugoročni troškovi uključuju i održavanje i ažuriranja.
- Niska ljudska interakcija: Niski zahtjevi za ljudsku uključenost i interakciju mogu dovesti do propuštanja određenih vrsta pogrešaka i grešaka.
- Ograničenja pokrivenosti: Automatizirani alati mogu pružiti širu pokrivenost, ali ipak, nekim aspektima testiranja trebaju se baviti ljudi, uključujući korisničko iskustvo i dizajn korisničkog sučelja.
Ručno, automatizirano ili oboje?
Prednosti, pokrivenost i različit opseg različitih pristupa testiranju softvera sugeriraju da će kombinacija ručnog i automatiziranog testiranja vjerojatno dati najbolje rezultate i smanjiti vjerojatnost grešaka.
Budući da ručni i automatizirani pristupi imaju prednosti i slabosti, na programerima je da pronađu ravnotežu između dva pristupa koji će pružiti najopsežniju analizu ponašanja i točaka prekida njihove aplikacije, što će dovesti do kvalitetnijeg proizvoda.
Funkcionalno i nefunkcionalno testiranje
Funkcionalno testiranje i vrste
Funkcionalno testiranje provjerava performanse aplikacije ili softverskog sustava u odnosu na funkcionalne specifikacije i zahtjeve koje je postavio klijent. Funkcionalno ispitivanje samostalno testira sastavne funkcije aplikacije nudeći ulaz i uspoređujući izlaz s postavljenim zahtjevima.
Funkcionalno ispitivanje obično se provodi prije nefunkcionalnog ispitivanja. Vrste funkcionalnih ispitivanja uključuju:
- Unit Testing
- Integration Testing
- User Acceptance Testing
- Smoke Testing
- Regression Testing
- Sanity Testing
- White Box Testing
- Black Box testing
Pogledajmo detaljnije svaku od ovih funkcionalnih vrsta testiranja:
Testiranje jedinica (Unit Testing)
Ispitivanje jedinica usmjereno je na pojedinačne komponente ili odvojene dijelove šireg sustava. Programeri se usredotočuju na najmanje neovisne jedinice koda kako bi ih testirali odvojeno prije nego što pogledaju ukupnu funkcionalnost aplikacije.
Testiranje jedinica može smanjiti troškove razvoja softvera pružajući programerima priliku da uhvate greške rano u razvojnom ciklusu, što također čini korektivne mjere bržim i lakšim.
Glavni nedostatak ispitivanja jedinica je da se poslovne aplikacije neizbježno sastoje od velikog broja provjerljivih jedinica koda, što znači da temeljito testiranje može biti vrlo dugotrajno i skupo za provedbu.
Testiranje integracije (Integration Testing)
S druge strane, testiranje integracije nastoji testirati način na koji različite jedinice sustava međusobno djeluju. Ova vrsta testiranja obično se događa nakon što su testirane brojne jedinice i dizajnirana je da odredi koliko dobro te jedinice rade zajedno.
Testiranje integracije može uhvatiti greške koje se ne pojavljuju u testiranju jedinica i identificira probleme s integracijom rano u ciklusu razvoja softvera, ali to može biti složen proces koji može biti sve dugotrajniji kako baza kodova raste.
Testiranje prihvaćanja korisnika (User Acceptance Testing)
Kao što ime sugerira, ova vrsta testiranja potvrđuje performanse sustava u odnosu na postavljene korisničke zahtjeve. Ova vrsta testiranja obično se dodjeljuje stvarnim korisnicima ili analitičarima, a usmjerena je na testiranje sustava u stvarnim uvjetima koji repliciraju potrebe korisnika i obrasce korištenja.
Osnovna prednost testiranja prihvaćanja korisnika je u tome što pomaže jamčiti da će sustav funkcionirati kako je predviđeno u stvarnom okruženju sa stvarnim slučajevima upotrebe. Međutim, to može biti dugotrajno i skupo ako postoji mnogo korisničkih persona i slučajeva upotrebe koje treba testirati.
Testiranje dima (Smoke Testing)
Testiranje dima poznato je i kao ispitivanje povjerenja ili ispitivanje provjere izrade. Ova metoda pomaže programerima da utvrde je li određena međuverzija spremna za sljedeću fazu testiranja i usredotočuje se na osnovnu funkcionalnost aplikacije prije nego što se testiraju detaljniji aspekti. Ako aplikacija ne prođe test dima, vraća se razvojnom timu.
Ispitivanje regresije (Regression Testing)
Uloga regresijskog testiranja je osigurati da promjena sustava ne stvara nove greške ili uzrokuje rušenja. Regresijsko testiranje uključuje provjeru sustava odmah nakon uvođenja promjena kako bi se osiguralo da se nisu pojavile nove greške ili nedostaci i da ne riskiraju razbijanje sustava.
Svrha regresijskog testiranja je uhvatiti pogreške koje se pojavljuju tijekom razvojnog procesa i vrlo je korisno za provjeru integriteta sustava u ažuriranjima softvera, nadogradnjama ili modernizaciji.
Testiranje zdravog razuma (Sanity Testing)
Testiranje zdravog razuma potkategorija je regresijskog testiranja, a njegova je svrha testirati funkcionira li nova verzija softvera kako je predviđeno. Obično je ograničenog opsega i usredotočen je na provjeru kritične osnovne funkcionalnosti, za razliku od identificiranja grešaka u sustavu.
Testiranje zdravog razuma jedan je od prvih testova provedenih nakon promjena u aplikaciji, a rezultati određuju mogu li se nastaviti planirana daljnja ispitivanja. Testovi zdravog razuma provode se nakon što aplikacija prođe početni test dima i uključuju validaciju kritičnih komponenti kao što su korisničko sučelje i unos/izlaz podataka.
Testiranje bijele kutije (White Box Testing)
Testiranje bijele kutije usredotočuje se na unutarnju strukturu i kod aplikacije kako bi se poboljšala sigurnost, upotrebljivost i dizajn. Također poznat kao Clear Box testiranje ili testiranje staklene kutije, traži probleme s unutarnjom sigurnošću i integritetom staza, ulaznih tokova i uvjetnih petlji. To može uključivati testiranje pojedinačnih izjava, objekata i funkcija, te na razini sustava, integracije i jedinice. U tom procesu, kôd je izravno vidljiv testerima.
Testiranje crne kutije (Black Box testing)
Testiranje ulaza i izlaza bez svijesti o izvornom kodu i unutarnjoj strukturi aplikacije poznato je kao testiranje crne kutije. Testiranje crne kutije provjerava komponente kao što su korisničko sučelje, povezivanje s bazom podataka, upotrebljivost, pristupačnost, sigurnost, komunikacija između klijenta i poslužitelja i uvjeti pogreške. Testovi crne kutije i funkcionalni testovi mogu biti ručni i automatizirani.
Nefunkcionalna testiranja i tipovi
Nefunkcionalno testiranje procjenjuje performanse, pouzdanost, upotrebljivost, skalabilnost, održivost, prenosivost i druge nefunkcionalne karakteristike aplikacije, kriterije koji se ne koriste u funkcionalnom ispitivanju. To pomaže smanjiti proizvodni rizik aplikacije.
Nefunkcionalno ispitivanje osmišljeno je tako da bude mjerljivo u odnosu na postavljene standarde kvalitete te pomaže u uklanjanju prepreka nesmetanoj instalaciji, konfiguraciji, izvršavanju, upravljanju i praćenju softverskog proizvoda.
Nefunkcionalno testiranje obično slijedi funkcionalno testiranje. Vrste nefunkcionalnih ispitivanja uključuju:
- Performance Testing
- Load Testing
- Volume Testing
- Stress Testing
- Security Testing
- Installation Testing
- Compatibility Testing
- Migration Testing
Pogledajmo detaljnije svaku od ovih nefunkcionalnih vrsta ispitivanja:
Testiranje performansi (Performance Testing)
Kao što ime sugerira, ispitivanje performansi mjeri kako aplikacija radi u različitim uvjetima opterećenja i okruženjima.
Cilj testiranja performansi je osigurati da aplikacija radi prema potrebi i da se nosi s očekivanim opterećenjem tijekom uporabe.
Testiranje opterećenja (Load Testing)
Modeli testiranja opterećenja očekivanih obrasci korištenja aplikacije, kao što je simulacija mnogih korisnika koji istovremeno pristupaju aplikaciji, kako bi se utvrdila njezina otpornost i kapacitet. Testiranje opterećenja stoga je korisno za višekorisničke sustave ili aplikacije od kojih se može zatražiti da se nose s naglim skokovima opterećenja.
Količinsko testiranje (Volume Testing)
Količinsko testiranje je oblik testiranja koji podvrgava aplikaciju velikoj količini podataka kako bi se odredila njezina ograničenja i mogućnosti obrade podataka.
Ispitivanje volumena korisno je za planiranje skalabilnosti i identificiranje točaka na kojima se stabilnost aplikacije počinje smanjivati.
Testiranje otpornosti na stres (Stress Testing)
Testiranje otpornosti na stres primjenjuje vršna opterećenja i unos korisnika na aplikaciju kako bi se utvrdile njezine točke prekida te odredile granice upotrebljivosti i treba li ih produljiti prije objave aplikacije. Testiranje otpornosti na stres pomaže razvojnim programerima da osiguraju da će aplikacija ispuniti očekivanja korisnika i koristiti obrasce.
Testiranje otpornosti na stres može se koristiti i za utvrđivanje uskih grla koja mogu usporiti primjenu i za sprečavanje zastoja ili neuspjeha. Može pomoći u određivanju skalabilnosti simuliranjem teških opterećenja na sustavu, bilo u isto vrijeme ili tijekom određenog razdoblja. To je također temeljna metoda testiranja za mjerenje povrata nakon pada ili greške u aplikaciji.
Sigurnosno testiranje (Security Testing)
Sigurnosno testiranje skenira aplikaciju za ranjivosti koje bi je mogle izložiti napadima zlonamjernih aktera. Sigurnosno testiranje poprima mnoge oblike, uključujući testiranje penetracije i skeniranje ranjivosti i pregled koda.
Rizici povezani sa sigurnosnim testiranjem mogu dovesti do lažno pozitivnih rezultata, što može trošiti resurse i vrijeme, te nepotpune pokrivenosti, što znači da ranjivosti mogu ostati i nakon završetka testiranja. Također može biti jako dugotrajno.
Testiranje instalacije (Installation Testing)
Testiranje instalacije osmišljeno je kako bi se osiguralo da se aplikacija može ispravno instalirati s pravim značajkama, konfiguracijama i bibliotekama prema zahtjevima određenog korisnika bez kvarova ili kvarova. Obično se izvodi nakon što se aplikacija u potpunosti razvije, završe druge vrste testova, a aplikacija je gotovo spremna za isporuku korisnicima.
Testiranje kompatibilnosti (Compatibility Testing)
Testiranje kompatibilnosti provjerava može li aplikacija funkcionirati na različitim vrstama operativnih sustava, platformi, preglednika, hardvera, mrežnih okruženja i uređaja.
Testiranje kompatibilnosti sa starijim verzijama provjerava ponašanje i kompatibilnost aplikacije s prethodnim verzijama, dok testiranje kompatibilnosti prema naprijed provjerava ponašanje i kompatibilnost aplikacije s novijim verzijama.
Testiranje migracije (Migration Testing)
Testiranje migracije postupak je provjere je li proces migracije naslijeđenog sustava na novi bio uspješan, uz minimalne poremećaje ili zastoje i bez gubitka podataka. Istodobno osigurava da su svi funkcionalni i nefunkcionalni zahtjevi i dalje ispunjeni nakon završetka procesa migracije.
Testiranje naslijeđenih projekata modernizacije softvera Delphi: temeljit referentni priručnik
Ažuriranje i modernizacija naslijeđenih Delphi projekata može se činiti rizičnim procesom prepunim mnogih načina za razbijanje aplikacije. Istodobno, novi zahtjevi korisnika i napredak tehnologije zahtijevaju ažuriranje i modernizaciju naslijeđenih projekata, često refaktoriranjem.
Jedan od najtežih izazova je znati odakle početi i kako planirati projekt modernizacije. Drugi je odabir prave strategije i pristupa.
Sve se to može činiti neodoljivim ako nemate jasan, dobro napisan i vrlo temeljit vodič za modernizaciju softvera. A to je upravo ono što dobivate s opsežnim djelom Williama Meyera pod nazivom “Delphi Legacy Projects: Strategies And Survival Guide”.
O autoru
William Meyer započeo je svoju karijeru u dizajnu hardverske logike i samostalno se školovao na assembly jeziku Z80. Kasnije je otkrio Turbo Pascal 1.0 za Z80, a očito još uvijek ima originalni priručnik. Nakon niza godina rada s Turbo Pascalom “upoznao se s Delphi-em i nikada se nije osvrnuo”.
Karijera Williama Meyera gotovo je u potpunosti u televizijskoj industriji, s kratkim boravkom u medicinskom softveru za ordinacije, također rađenom u Delphi-u.
William je u srpnju 2022 objavio knjigu “Delphi Legacy Projects: Strategies And Survival Guide”.
O “Delphi Legacy Projects: Strategies And Survival Guide”
Refaktoriranje i modernizacija naslijeđenih projekata zadatak je koji se mnogo razlikuje od dizajna i kodiranja novih aplikacija. Ovaj priručnik pregledava sve aspekte procesa i nudi strategije.
Posebno poglavlje 18, naslovljeno Testability, sadrži opsežne smjernice o kretanju u postupku testiranja moderniziranih naslijeđenih Delphi aplikacija.
Pogledajte također webinar Williama Meyera s Jimom McKeethom „Nadogradnja i održavanje naslijeđenih projekata za Delphi”
