Test Mühendisliğine Giriş Eğitimi - Bölüm 2

Test Mhendislii Giri Eitimi - Blm 2
Kaynaklar: Takip ettiim ve eitimi hazrlanken baz yerlerde ok ksa bilgi, baz yerlerde grafik alarak yararlandm kaynaklar aadaki gibidir. http://www.istqb.org/downloads/finish/16/15.html http://www.istqb.org/downloads/finish/16/16.html http://www.istqb.org/downloads/finish/20/14.html http://www.istqb.org/downloads/finish/41/87.html http://www.istqb.org/downloads/finish/6/88.html http://www.amazon.com/Testing-Computer-Software-2ndKaner/dp/0471358460/ref=sr_1_1?s=books&ie=UTF8&qid=1348123327&sr=11&keywords=0471358460 http://www.amazon.com/Software-Testing-Real-WorldImproving/dp/0201877562/ref=sr_1_1?s=books&ie=UTF8&qid=1348123373&sr=11&keywords=software+testing+in+real+world http://www.slideshare.net/onsoftwaretest/istqb-iseb-lecture-notes-presentation http://www.slideshare.net/yogindernath/istqb-iseb-foundation-exam-practice-2 http://www.slideshare.net/yogindernath/istqb-iseb-foundation-exam-practice http://www.slideshare.net/yogindernath/istqb-iseb-foundation-exam-practice-4 Ivar Jacobson: http://blog.ivarjacobson.com/ivarblog/ W. Edwards Deming: http://www.youtube.com/watch?v=HBW1_GhRKTA James O. "Jim" Coplien: http://users.rcn.com/jcoplien/ Mel Conway: http://www.melconway.com/research/committees.html
Trkesi: Bug, Defect, Error, Failure, Fault, Mistake: Hata (Malesef herbir terim iin kelime retmemiiz), dilimizde de ngilizceleri kullanlmaktadr. Quality: Kalite Risk: Risk, hata kma olasl Software: Yazlm Testing: Yazlm testi Exhaustive Testing: Eksiksiz, detayl test
Yazlm bir hobi almas olmad ve vadedilen bir takm ileri; hzl, gvenilir, kolay, arzu edilen herzaman yerine getirmesi planlaryla yapldndan stte sralanan zelliklere sahip olmas gerekir.
ngilizce'de hata denildiinde bir ok terim kullanlrken Trke'de tek bir kelime ile bunu anlatmak zor hatta imkanszdr. Bu yzden bu kavramlarn ingilizcelerini aklamak daha kolay gnn birinde her kelimenin Trke karl olduunda onlar kullanmak iletiimin ve anlgy kolaylatrr.
Hata SLDC gz nne alndnda, yazlm hayat dngsnn her yerinden yaplabilir. En byk ve dnlmesi olmayan hatalar gereksinimlerin toplanmas aamasnda yaplan hatalardr. Bu tip hatalarn dzeltilmesi iin, tekrar saha almas yaplarak dzeltmeler yaplmal ve daha sonraki sreler baarl iletilmeli. En az soruna neden olan hatalar ise yazlm aamasnda yaplan ve bulunan hatalardr. Test mhendisleri tarafndan bulunan defectler ilgili yazlmcya haber iletiime geilerek abucak dzeltilebilinir.
Yazlm Gelitirme Hayat Dngs (SDLC) Gereksinimlerin mterilerden toplanarak analiz edilip daha sonra tasarm, gelitirme, test ve yaynlama gibi evrelerinden oluan bir dngdr. Bu dng ierisinde hatann bulunduu yere gre yazlma maliyeti farkllk gstermektedir. Son evrelerde yakalanan hatann maliyeti, erken evrelerde yakalanan hatann maliyetine zamann karesiyle (exponential) orantl olarak artmaktadr. Bu testin nemini arttrmaktadr. Ksaca iyi test Ciddi hatalar erken bulmaktr! zay Civelek, Testurk.com.
10
11
Ariane 5: 4 Haziran 1996da Avrupa Hava Ajansnn (ESA) ilk roket havalandktan ksa bir sre sonra dt. Dme sebebinin daha sonradan yazlmdaki bir hatadan kaynakland anlald. Hatann 64 bit ondalkl integern 16 bit iaretli integere dntrlrken ondalk ksmda oluan hatay kontrol eden exception handling yapsnn olmamasndan kaynakland anlald. Marine Space Probe to Venus: 28 Temmuz 1962de Mariner1 isimli hava tatn roketinin yn belirlenen ynden aniden karak teklikeli yola girdiinde baka bir roket Atlantik okyanusundan imha etti. Roketin ynndeki deiime neden olan hata, mhendislerin kat zerine yazdklar formln koda aktarlrken yanllk yapmasndan kaynaklanyordu. Hartford Coliseum Collapse : 1978de Harttford, Connecticutda bulunan spor salonunun catsnda biriken sulu karn arln atnn kmesine neden olmu. kme sebebi projenin hesaplanmasnda kullanlan CAD proramnn cat yk hesabn yanl yapmasndan kaynaklanyordu. World War III Almost (1983) Radar sistemini Amerika tarafndan 5 adet bazilistik fzesinin zerlerine gnderildiini raporlaynca, savunmak amal nukleer fzelerin gnderilmesi son anda iptal edildi. Sorumlu asker Amerikann byle bir saldry yapmak iin 5 adet fzeden ok daha fazla fze gndermesi gerektiini dnerek savunma fzelerinden vazgeti. Hata radarn filtrelemesini yapan kodda olduu anlald, gne yansmasnn formule dahil edilmemi.
12
12
13
Anahtar kelimeler
Code: Program paralar Debuging: yazlm gelitirme sresince yazlan program paralarnn altrlmas Development of software: Yazlm gelitirme Requirement: Yazlm gereksinimleri, neden yazlm gerekli, kullanc ihtiyalar Review: Gzden geirme Test basis: Tm birim veya sistemlerin est iin gerekli dkmanlar Test Cases: Test case; testin tanm, admlar, amalarn ieren dkmanlar Test objective: Test yapmaktaki ama nedir.
14
Src Testi Nedir? Eer src eitli yollar deneyerek bir rotay takip eder ve eitli manevralar yaparak rotasn gvenli bir ekilde tamamlar ise src testi baarldr denir. Sr srasnda rotann tamamlanmasna engel olabilecek tek bir ciddi hata tm srn baarsz olmasna sebep olur fakat sr srasnda birok kk hata rn baarl saylmasna engel deildir. Yazlm testi asndan bakldnda, yazlm birok kk hatalar olabilir hatta bunlar bulmak uzman test mhendisleri iin dahi zor olabilir, yazlm testi bu tip hatalardan ziyade yazlmn konusuna ve nemine gre dikkat alnacak olan ciddi hatalarn bulunmas ve raporlanmas olarak aklanabilir. Hatalardan tamamen ayklanm bir yazlm sadece hayal rndr fakat hatalarn kontrol edildii, risk deerlendirilmesi yapld ve raporland test anlay daha uygulanabilir bir test anlaydr.
15
Proses (process) Test tek bir aktiviteden ziyade bir sretir. Belli kaideleri vardr ve herbir olgu bu kurallar iinde deerlendirilir. Srecin kalitesi aslnda iletilen testin de kalitesini verir. Test kalite ierisinde en nemli balkt fakat test bir sre dahilinde iletiliyorsa. SLDC boyunca Test Yaplr Test sadece gelitirme tamamlandktan sonra yaplan ve burada biten bir activite deil SDLCnin her bir evresinde deiik test tipleri iletilerek yazlm srecine katkda bulunulur. Unutmaynzki iyi SDLCnin erken evrelerinde bulunan hatalar kolay zlebilir ve daha dk maliyetler haranr. Statik (static) ve Dinamik (dynamic) testler vardr Test sadece kara kutu (black box) deil ayn zamanda beyaz kutu (white box) ve gri kutu (gray box) testleride kapsamaktadr. Testin alan sadece ekran karsndan bilenin fonksiyonlarn doru almasn kontrol etmek deil ilerde deinilecei gibi daha geni bir kapsam vardr. Planlama (planning) Test plan teste hazrlk ksmnda yaplr ve buna bal kalmak arttr. Hazrlanma (preparation) Testle ilgili herey bu evrede hazrlanr ve teste balama kriterlerinin (start enterance criteria) olumasyla teste balanr. Test sonlandrma kriterleri (test exit criteria) ile de test sonlandrlr.
16
Deerlendirme (eveluation) Test sonladrlmas ile test sonular deerlendirilir.
16
Test hatann varln kantlar Test sadece bulunan hata ile ilgilidir yazlmn geri kalan hakknda bilgi vermez yani uzun sre koturulan testlerden sonra halen hata (bug) bulunamyorsa bu yazlmn artk hatalardan arnd anlamna gelmez. Detayl (exhaustive) test imkanszdr Bir yazlm utan-uca hereyini test etmek imkanszdr. Mutlak test edilemeyen ya da edilmesi imkansz olan baz durumlar olabilir. Bu yzden %100 test ettik laf hataldr. Erken teste balamak daha iyidir (early testing) Hatalarn zm daha kolay ve maliyeti dktr. Hatalar kmelenir (defect clustering) Eer bir hata bulunmu ise bu hatay tetikleyen baka noktalarda olabilir. Genel anlamda hata noktalarnda yazlmcnn kt gn gibi psikolojik sebeplerde vardr bu yuzden hatann bulunduu evreye dikkat edilmelidir. Gbre paradoksuna dikkat et (pesticide paradox) Bir yazlm zerine srekli ayn testleri koturmak bir sre sonra yazlm zerinde hata bulunamamasna sebep olur bu durum yazlmn hatadan ayklandna deil uygulanan testlerin deitirilmesi gerektiinin belirtisidir. Topra srekli ayn gbre ile gbrelemek onun verimi srekli arttrmaz, bir noktadan sonra zayflatr. Test balam bamldr (context dependent) Yazlmn konusuna gre testler farkllk gstermelidir. rnein e-bussiness projesi ile bir askeri proje ayn test yntemleri ile test edilmemelidir. Hata bulmak ve dzeltmek kullanclarn isteklerini karlamaz. (absance-of-error fallacy) Hatay oluturan durum kullancnn istemedii durum olabilir yalnz bu hatann dzeltilmesi kullancn
17
isteklerini yerine getirmek demek deildir.
17
Anahtar kelimeler:
Conformance Testing: Compliance testing, uyumluluk testleri Exit Criteria: Testi sonlandrma kriterleri Incident: Hadise, vaka, (hata) Regression Testing: Regresyon testi; bulunan hata sonucu yazlmda yaplan deiikliin sisteme etkisinin testi Test Condition: Testi gerekletirmek iin gerekli koullar Test Date: Testin gerekletirildii tarih Test Execution: Testin gerekletirilmesi Test Log: Test gereklemesi srasnda tutulan hertrl kayt, dkman, vb. Tets Summary Repor: Test sonrasnda testin sonularnn zet halinde sunulduu test dkman Testware: Test sonrasnda ortaya kan her trl test kaytlar, rnleri, vb., Tets Plan: Test srasnda uyulmas gereken kurallarn bulunduu test balamadan nce hazrlanan plan
18
19
MTP Master Test Plan ierisinde test ynetimine ait tm bilgileri ieren dkmandr. Bu dkman planlama aamasnda hazrlanr ve tamamlandktan sonra tm ilgili paydalarn (yazlmc, analist, testi, proje yneticisi, ...) herzaman ulaabilecei ekilde yaynlanr. MTP daha sonraki aamalarda ikilik kmas durumunda bavurulacak kaynak niteliindedir bu yzden zenle hazrlanmal ilgili kiilerin onaylar alnmaldr. Teste Balama Kriteri Test balama kriterleri, herhangi bir yazlm ktnn testine balamadan nce sahip olmas gerekli en temel zelliklerin listesidir. Bu liste SDLC gz nne alndnda eitli kriterlerden sz edilebilir. rnein, gelitirme tamamland ve yazlm zerinde fonksiyonel testlere balanacak, yazlmn hazr olup olmadn kontrol etmek gerekiyor. Bu durumda uzman ya da moderator tarafndan u kontroller yaplabilir: 30 dk boyunca kontrol edildi ve bir sayfada 3 byk defectten baka birey bulanmyor ise, 5 deiik sayfada 10dan fazla nemli defect bulunmam ise, ... Testi Sonlandrma Kriterleri Test iin sonsuz zaman ve kaynak olmadndan bir sre sonra test sonlandrmak gerekir. Genelde risk analizi yaplarak nekadar test yaplacana karar verilir. Test sonlandrmak iin belirlenmi kriterlere exit criteria denir.
20
Test Stratejisi: Test yaklamnn ana hatlarn izen ve projeye zg hazrlanan kurallar btndr. Organizasyondaki herkesin bilgilenmesi ve bu dorultuda hareket etmesini salar. Test caselerin tasarlanmas, test srelerin belirlenmesi, teste balama ve testi sonlandrma kriterlerin belirlenmesinde ana rol oynar. Test Yaklam: Projeyi oluturulan btn bileenleri ierisine katarak daha baarl test sonular yakalamak iin kullanlan test tiplerinin gruplandrld test anlaydr. Deerledirilmesi gereken bileenler: Test stratejisini ve yaklamn belirlemek iin bu kriterler gz nne alnmaldr.
21
rnek bir deerlendirme yaplr ise; Bir e-ticaret firmasn rnek olarak aldmzda 2 Alanda inceleme yaplabilir: Proje konusu ve Gelitirme Ortam Analitik Yaklam: nternet zerinden sat yapld iin baz riskler vardr. rnein; gvenlik problemleri, firma imajn zedeyecek grsel ve yazm hatalar, ... Olmasndan dolay test caselerin risklerinin snflandrlmasnda kullanlabilir. Dinamic Yaklam: Gereksinimlerin olmad, planlamann tam olarak yaplmad hzl bir yazlm gelitirme ortam olmasndan tr de dinamik test yaklam kullanlabilir. Analitik ve Dinamic test stratejilerinin bileiminden oluan; Risk Temelli - Dinamik test yaklam belirlenebilir. Hata verme olasl ve daha yksek alanlara daha fazla test yapmak Keif tabanl testler yaparak hata tahminlerinde bulunarak, ilgili alanlara younlamak
22
Yazlmn doru altndan emin olduunuzda Yazlm gereksinimleri gz nne alndnda ok fazla olmayabilir veya uzun bir zaman aralalnda testlerinizi baarl bir ekilde tamamlam ve daha fazla hata bulamyor olabilirsiniz bu durumda yazlmn doru alt konusunda kendinizi emin hissediyorsanz testleri durdurarak yayna almak (go live) gerekir. Fakat emin olma durumu kiiden kiiye gre ve deneyimlere gre deiiklik gsterdii iin bu madde herzaman geerli deildir. Yazlmn risk deerlendirmesine bal olarak Test iin zaman herzaman kstldr. Hereyi planland gibi test etmek genelde mmkn olmaz bu durumda riskleri gz nne alarak: Nelerin en ok, Nelerin ilk, Hangi blmn kismi veya tamamn, Test edilecek blmlerin nekadarlk zaman iinde, Nelerin test edilmeyeceini Belirleyerek test zamann en etkin nasl kullanlmas gerektiinin analizi yapldnda ve bu zamann sonlanmas ile test bitirilebilir.
23
dentify Neyin test edilceini belirlenmeli ve test edilebilecek (testability) konular bir liste haline getirilerek nem srasna gre sralanmaldr. Testin baarl sonulanmas iin gerekli yeter koullar berlirlenmeli ve oluabilcek en kt durumlar ve bu durumda yazlm kararllk tablosu kartlmal. Yazlmn yaps hakknda bilgiler edinilir. Design st dzey test caseler kartlr. Belirlenen konularn nasl test edilecei belirlenmeli ve test caselerin yazm iin gerekli almalar yaplmaldr. Teste kullanlacak veriler belirlenmeli, veriler (input) sonucunda yazlmn verdii cevap (output) belirlenmeli. Build Test caseleri yazlmal. Scriptler yazlarak test aralar zerinden testlerde yaplabilir.
24
25
Deerlendirme ve Raporlama MTP dkmmanna uyarak ve test sonlandrma kriterleri gerekletiinde daha fazla test yaplmadan test sonular deerlendirimelidir. Bu aamada bulunan hatalar ve bu hatalarn sonucunda oluturulan raporlar incelenmeli, halen dzeltilmeyi bekleyen hatalar var ise bunlar vurgulanmaldr.
26
Exit Criteria Test Coverage (iletilen testlerin toplam testlere oran) kontrol edilmelidir. Coverage u balklar altnda incelenebilir: Branch coverage Statement coverage Condition coverage User requirements Saptanan hatalar Para ve zaman Eer sre sonunda testi sonlandrma kriterleri yeterli deil ise tekrar test detaylarna baklarak sre yeniden iletilmelidir.
27
28
29
Test Yaklam Projeye uygulanacak test tiplerini belirleyen anlaya test yaklam denir. Baarl test yaklam ile detay analizden ortaya kan test caseleride ierisine katan test caseleri hazrlamak mmkn olur. st dzey analiz ktlar daha kolay anlalr olduundan, acemice uygulanan bir test yaklam ile bunun tesine gitmek zor olabilir. Daha iyi bir test yaklam ile; Yazlmn neleri yapt ortaya kartlr ve bunlarn ierisinden de yapmamas gereken zellikler ayklanr ve bunlar hata olarak raporlanr. Ayrca yazlmn yapmas gereken fakat yapmad fonksiyonlarda ortaya kartlm olur. Geleneksel test yaklam ile kolay test caseleri hazrlanr ve ancak yzeysel hatalar bulunabilir. Sonu olarak bulunmas gereken hatalar yazlmda kalr ve geresinimlerden yazlma aktarlmam olan fonksiyonlar saptanmam olur. Bu da yazlmn kalitesini ve mteri memnuniyetini drr.
30
31
Test bir sretir! Bu yzden uygulamann bir zelliinden te uygulamann hayat dngsnn test edilmesi gerekmektedir. Uygulamann tm ynleri ele alnmal; gereksinimlerden yola karak uygulamann istenilene nekadar yakn?, stenilenin de ideale nekadar yakn? gibi sorular karsnda pratik cevap verebilen kiilerin test mhendisliini tercih etmeleri gerekir. Ayrca gelitirme sreleri herzaman ideal yapda olmayabiliyor bununla birlikte planan srelerde sapmalardan dolay uygulamann teste hazr olmasndaki gecikmeler test sresinin ksalmasna veya testin amacnn deitirilmesine neden olabiliyor. Testten sorumlu kiilerin bu durumu iyi ynetmeleri gerekmektedir. letiim yetenekleri gl ve test srelerini uygulatmak gibi hedefleri olan kiiler olmaldr. Bir yazlm ekibinde sreler nekadar zayfsa oradan kacak rnlerde okadar zayf olur bu yzden test ekinin daha kaliteli ve hedefleri daha net olmas gerekir. Test ortam eitli sebeplerden dolay herzaman ideal yapda olmayabilir bu durumda test mhendisi, ideal test ortami ile mevcut test ortam arasndaki fark bilmeli ve test edilemeyen fonksiyon yaynlanan ortamda ne gibi hatalara sebep olacan analiz edebilen zellikte olmal.
32
Test yapabilmek iin baz yetkilerin ve haklarn organizasyonda test mhendislerine tannmas gerekmektedir. Bu yetkiler sayesinde testciler, daha iyi test yapma, saptanan hatalar tarafsz bir ekilde raporlama ve zdrebilme kabiliyeti kazanr. Test bir sre olmasndan dolay, test srelerinde saptanan hatalar dzeltme yetkisiyle birlikte daha iyi test yapabilmenin n alabilir.
33
Testcinin grevi atanan yazlm belirlenen test planna uyarak testlerini gerekletirmektir. Burada ama ise yazlmn gereksinimlerinin onaylanmas ve dorulanmasdr (verification and validation). Bu ii gerekletirirken bulunan hatalar tarafsz ve herkesin anlayaca bir ekilde raporlanmal ve unutulmamldr ki yazlmc deil yazlm test ediliyor bu yzden hatalar tekrar kontrol edilmeli ve kibar bir dil kullanlmaldr.
34
35
36
SDLC (Software Development Life Cycle Yazlm Gelitirme Yaam Dngs) boyunca test etmek niin gerekli bu nitede tartlacak. Yazlm gelitirme methodlar neler olduu ve farkl methodlarda nasl daha iyi test edilecei yine bu nitenin konusu ierisindedir.
37
Anahtar Kelimeler:
COTS (Commercial off-the-shelf): paket proramlar Incremantel developmant model: Arttrmsal (iteratif) yazlm gelitirme modeli Test level: Test seviyesi, birim-entegrasyon- ... Validation: Dorulama Verification: Onaylama V-model: elale modele alternatif olarak gelitirilen, testing herbir aamada olduu yazlm gelitirme modeli
38
elale modeline gre yazlm gelitirme sreleri birbirini takip eden farkllam yazlm uzmanlk alanlarndan olumaktadr. Yazlmn ihtiya duyulmas (stek, Kanun Deiiklii, vb) aamasndan balar en sondaki aama olan test ile sonlanr ve yazlm devreye alnr. Yani her bir aamada kendisine i gelene kadar beklemektedir. Burada karlalan en byk sorun ise zamanlama sorunudur. Yazlma balanrken uygulanan plana bal kalnmad durumlarda, rnein test aamasna gelene kadar her aamadaki aamadaki ufakda olsa geikmeler kmlatif olarak toplandnda test iin ayrlan srenin ksalmas veya olmamas durumuyla kar karya kalnabilir. elale modelinde zellikle analizde oluan hatalar testte yakalandnda hatann maliyeti ok yksek olmaktadr. Yani hatal durum iin yeniden analiz-tasarm-kodlama-test srelerinin iletilmesi gerekmekte ve planlanan sreyi uzatmaktadr. Genel olarak byk projelerde elale modelinin uygulanmas nerilmemektedir.
39
ekilde grnen yazlm gelitirme modeli eklinde dolay V-Model ismini almtr. Buradaki alnda iki ksma ayrlabilir. Birinci ksm stek Toplama Kod Gelitirme ve ikinci ksm ise Kod Gelitirme Kullanc Kabul Testlerine kadar olan ksmdr. V-Modeline gre herbir yazlm srecine farkl test yntemleri uygulanr bylece ortaya kabilecek hatalar daha nce bulma yetenei kazanr. Byle test aktivitesi yazlm gelitir hayat dngs boyunca uygulanm olur.
40
Ge tasarm modelinde Kod Gelitirme sreci bittiinde test sreci balar. Daha ncesinde test iin hazrlk yaplmamasndan dolay, testlerin koturulmasndan nce test caselerin hazrlanmas yani tasarm yaplmas gerekmektedir. Bu durumda V-Modelin avantaj tam olarak kullanlmayp yine test uzmanlar test aktivitesine balamak iin kod gelitirme srecinin tamamlanmasn beklerler. Bu durumda ise erken test tasarm olmadndan dolay yine test sreci baladnda test tasarm balamaktadr.
41
Erken test modelinde test aktivitesi daha erken balamaktadr. steklerin ald aamadan itibaren test aktivitesi test tasarm ve model base test eklinde gerekletirilebilir. Yani gereksinimler toplanmasyla birlikte gereksinimler test edilebilir veya analiz ktlar ortaya ktnda sre ierisinde mantksz, muallak veya iletilmesi anlamsz olan sreler kartlarak daha kod gelitirme srecinde yazlmc iin daha ak ve net analiz ktlar salanabilir. Daha sonra hazrlanan test caseler, test case altrma aamasnda hzla altrlarak sre daha hzl iletilebilir. Bu model ile sre toptan iyiletirilmi ve test aamasna daha olgun yazlmn gelmesine fayda salayabilir.
42
teratif yazlm gelitirme yntemi, elale modelinin (geleneksel yntemler) alternatifi olarak dnlebilir. nk elale modelini ele aldmzda tm yazlm sreci tek bir iterasyondan olumakta ve en son admda test sreci bir patlama eklinde hereyi test etmeyi amalamaktadr. teratif yazlm gelitirme modelinde ise tm yazlm tek bir iterasyondan te sresi belli olan ve bu sre ierisinde yazlm ilgili paralara blerek belirlenen sre ierisinde bitirmeyi amalamaktadr. teratif modelde her iterasyonun sresi bellidir yazlm ierisindeki tm roldeki kiiler bu zamanlamann farkndadr ve olas geikmeler sadece ilgili iterasyonu etkiler. Bu sebepten ynetilebilirlii dier modellere gre daha iyidir.
43
Agile metodu iteratif yazlm gelitirme ierisinde yeralr. Daha fazla insan odakldr nk konularn (ilerin) gnlk olarak yaplan ksa toplantlarda zerinden geilir ve yazlmcnn cann skan durumlar var ise onlar dile getirilir ve paylalr. Agile dahada zellemi bir yntemi olan XP (extreme programming) yntemi ise ncelikle test caseler iin scriptler yazlr ve bu scriptler zaman zaman altrlarak tamamen hatasz geene kadar yazlm gelitirilir. Yani nce test scripleri yazlr sonra rn kodu. Bunun iindirki bu yntemde herkes biraz test mhendisidir, test mhendisleride yazlm uzmandr; yani herkes yazlm uzman olarak deerlendirilir.
44
Anahtar Kelimeler: Alpha-beta testing: Alfa testi, yazlm gelitirme ortamnda yaplan kullanc kabul testleridir; Beta testi ise kullanclarn kendi ortamlarnda bir fiil uygulamay kullanarak yaptklar test aktiviteleridir. Eer belirli sayda ve davet ile belli profilde kullanclara izin verilerek beta testi amalanyor ise buna closed-beta testi denir; kullanclarda herhangi bir snrlama yok ise open-beta testi denir. Component testing: Birim testi (unit testing) Driver: Src Functional req. : Fonksiyonel Gereksinimler ntegration testing: Entegrasyon testi Non-functional testing: Fonksiyonel olmayan testler. rn: performans, gvenlik, kullanlabilirlik, ... Operational testing: Operasyonel testler Compliance - acceptance testing: Uygunluk (kurallar, yasalar, vb) testi Robustness testing: Salamlk testi, Birim veya sistemin uygun olmayan durumlarda alabilmesi Stub: Bir birimi test etmek iin hazrlanm proram paralar System testing: Sistem tesleri, entegre alan sistemlerin testi Test-driven development: Test ynelimli yazlm gelitirme. Test caseler nce hazrlanr ve tm caseler testten geene kadar yazlm devam eder. Test environment: Test ortam User acceptance testing: Kullanc kabul testleri
45
Test seviyeleri testin hangi derinlikte yapla ile ilgilidir. rnegin birim test veya birim entegrasyon test seviyeleri genelde kod dzeyindedir ve burada yazlan kodlarn doruluu, gereklilii tartlrken daha st seviyedeki testlerde rnein kabul testlerinde genelde karakutu olarak adlandrlan testler uygulanarak gereksinim, kanun, vb. Kriterlere uygunluguna baklr. Bu yzden farkl testvseviyelerinde farkl testler uygulanr.
46
Birim testleri genelde yazlmcnn sorumluluunda olan testlerdir. Kod seviyesinde yaplr. Birim kelimesi tek bir fonksiyonun testide olabilir bir snf veya bir moduln testinide ierebilir. Kapsam kodu yazan kii tarafndan belirlenir. Tek bir i test edildii iin balantl dier birimlerden izole edilmelidir yani giri ve klarn herzaman dogru dnd dnlerek test yaplr. Bu yuzden dier birimlerle olan alveriler stub veya driver olarak adlandrlan objelerle gerekletirilir. Dier birimlerde karlalacak sorunlarn zm birim entegrasyon testinin ierisinde zlebilir.
47
Farkl birimlerin ya da sistemlerin birlikte alrken ortaya kabilecek sorunlarn test edilmesine entegrasyon testi denir. Birden fazla birim test ediilir ise birim entegrasyon; birden fazla sistem test edilirse sistem entegrasyon testi denir. Neler test edilir: Farkl birimlerin iletiimi Bireysel olara set edilemeyen birimler Fonksiyonel olmayan zellikler (memory leak, ...)
48
Yazlm gelitirmede belli bir olgunlua geldiinde uygulanan test seviyedir. Bu seviyede herey test edilir. Bu yzden yazl olan gereksinimler dnda kiilerin deneyimleride nemlidir ve bu testler genelde test uzmanlar veya bu konuda uzmanlam test danmalar eklinde yaplmas nerilmektedir. Bu aamada kara kutu testleri kadar beyaz kutu testleride yapmak mmkndr. rnein kullancya sunulan bir tablodaki deerlerle retilen bir liste de deerlerin doru geldiini ya da hatal istek durumunda sistemin verdii hata ve uyar mesajlarn doruluu yine bu test seviyesinde test edilir. Test edilen yazlmn versiyonuda yine test eden grup tarafndan kontrol edilmeli bu yzden test ortamnn kontrol test uzmanlarnda olmaldr.
49
Kullanc Kabul Testleri Kullanclardan toplanan gereksinimlere uygunluk test edilir (verification). Kullanclarn her istedii doru olmayabilir. Bu gibi durumlar analiz edildiyse analiz sonular gz nne alnarak yaplan testler de (validation) bu grubta yeralr. Operasyonel Kabul Testleri Yazlmn operasyonel dier grublarla olan almalar test edilir. Herhangi bir backup/restore durumunda yazlmn kararl srme dnme hz ve bu sre boyunca gsterdii kararsz durumlar test edilir. Ayrca bakm ve gvenlik kontrollerinde karlalabilecek zorluklar test edilir. Uyumluluk Testleri ki grupta incelenebilir. Yazlmn kullanld lkenin kurallarna olan uyumluk ve dier kiisel haklara zarar verebilecek zellikler test edilir. Tarayc uyumluluk ise, web uygulamalarnda geerli testlerdir. Kullanclarn kulland tarayclardan desteklenenlerde oluabilecek grsel, fonsiyonel, gvenlik ve performans gibi zelliklerin test edilmesi tarayc uyumluluk testleri ierisinde yeralr. Alfa Testi Gelitirmenin sonlanmasna yakn gelitirme ortamnda yaplan testlerdir. Beta Testi Yazlmn belli bir olgunlua geldikten sonra sadece hedef kullanclar ile gelitirme ortam dnda kullancnn kendi ortamnda yapt testlerdir.
50
Anahtar Kelimeler: Black-box: Kara kutu testleri Code coverage: Yazlan kodlarn nekadarnn altrldn ve nekadarnn altrlmadn kontrol eden testler btn Re-testing: Bulunan hata sonrasinda yaplan deiikliin test edilmesi Functional Testing: Fonksiyonel testler Iteroperability Testing: Birim veya sistemlerin birlikte alabilmelerinin testi Load Testing: Yk testi, belli bir ykte(yogunlukta) yazlmn verdii cevaplar Maintainability Testing: Bakm yaplmasna nekadar uygun olduu, gncellemenin maliyeti Regression Testing: Regresyon testleri Performance Testing: Performans testi Portability Testing: Tanabilirlik testleri Reliabity Testing: Tutarllk testleri Security Testing: Gvelik testleri Specification-based Testing: Gereksinimlerden yola klarak test etmek Stress Testing: Yk testi, snr deerleri bulmak iin yaplan ypratc testler Structural Testing: Beyaz kutu testleri Test suite: Test yaplmas iin gerekli ortam Usability Testing: Kullanlabilirlik testi White-box Testing: Beyaz kutu testleri
51
52
Yazlmn fonksiyonlar test edilir. Yazlm kararlatrld gibi fonksiyonlarn yerine getirip getirmediine baklr. Fonksiyonlarn doruluu iki ekilde kontrol edilebilir. Birincisi kullanclardan toplanan gereksinimlere uygunluu ve ikinci olarak da i sre modeline bakarak doru bir sre iletildii kontrol edilebilir. Yani yazlmn ... Durumunda ne yapar? sorusuna cevap veren testlerdir. Fonksiyonel testler genelde kara-kutu testler olarak adlandrlr fakat bunla birlikte beyaz-kutu testlerde olabilir. Yazlmn i yaps genelde grlmez, yazlma verilen girdilerin ktlar kontrol edilir. Fakat baz durumlarda rnein ok fazla girdinin manuel olarak iletilemedii durumlarda (rnein performans testlerinde) scriptler yardmyla yaplan fonksiyonel testlerde olabilir, byle durumlar ise beyaz-kutu testlere rnektir.
53
Yazlmn fonksiyonel olmayan dier kalite unsurlar test edilir. Bu kriterler; gvenlik, hz, tutarllk, bakm yaplabilirlii, kullanlabilirlik, tanabilirlik, ... eklinde srlamak mmkndr. Performance, stress, load: Performans lmlenir. Performance testinde istenilen performans deerleri ierisinde kullanlabilecek maksimum kullanc testpit edilir, load testinde ise belirli bir ykte yazlm verdii cevap sresi; stress testinde ise yazlmn dayanabilecei en byk yk tespit edilir. Usability: Yazlmn kullanc deneyimleri bakmndan doru olmayan yanlar, kullanm zorlatran zellikleri tespit edilir. Genelde kullanlabilirlik test uzmanlar tarafndan test edilir. Maintainability: Bakm srasnda yazlmn nekadar sorun yarataca test edilir. Reliability: farkl ortamlarda ve koullarda yazlmn verdii cevaplar test edilir. Portability: Yazlmn farkl bir platforma tanmas durumunda ne gibi sorunlar oluturaca tespit edilir. Security: Gvenlik aklar olup olmad, kullancn yaamak istemeyecei durumlar tespit edilir. Compatibility: Kullancnn ortamlar gz nne alnarak farkl kullanc ortamlarnda oluabilecek hatalar tespit edilir. Genelde beyaz-kutu testlerdir yani kod, script, test aralar ile yaplabilen testler olmakla birlikte performance, kullanlabilirlik tarafndan yazlmn fonksiyonlarnn fonksiyonel olmayan gereksinimlere uygunluu test edilir. Yani kara-kutu testlerde bu blmde olabilir.
54
55
Regresyon ve onaylama testleri bir arada anlatlr cnk her iki test trde yazlmda yaplan deiiklik sonras yaplmas gereken test aktiviteleridir. Onayalama (confirmation) testleri, en son bulunan hatann dzeltilmesi sonrasndan hatann var olup olmadnn kontroldr. Bu yzden hatal durum ne ise ayn durum tekrar edilir, yazlm yerel olarak test edilmi olur. Regresyon (regression) testleri ise yazlmda zerinde herhangi bir deiiklik var ise bunun etkilieri gz nne alnarak olumsuz etkilenebilecek tm alt sistemler test edilir. Yani yerel testler ziyada daha genel testlerdir. Regresyona dahil edilecek modl veya fonksiyonlar tamamen deiiklik yaplan konuya zeldir. Zaman snrlamas, risk deerlendirilmesi ve etki analizi sonrasnda kapsam belirlenebilir. Sk-sk yapldndan otomasyona uygundur. Farkl kapsam olan otomasyon test scriptleri ile regresyon testleri yaplabilir.
56
Anahtar Kelimeler: Impact Analysis: Etki analizi, yaplan gncellemenin sistem zerine etkileri nasl anlalr Maintanence Testing: Bakm testleri, yazlm devreye alndktan sonra bakm gerektirdii durumlarda gncelleme sonrasnda yaplan testlerdir.
57
Bakm testleri neden gereklidir? Bir yazlm devreye alndktan sonra bazen yllarca deiiklik yaplmadan kullanlabilir. Fakat gnmzde bir ok yazlm esitli sebeplerden dolay sk sk gncelleme gerektirebilir. Bu sebeplerden bazlar: Deien iletim sistemleri, kullanc ortamlarnda olabilecek hertrl deiiklikler Kalitenin devamll iin saptanan iyiletirmeler yaplabilir, Performans kayplar, gvenlik aklar, yeni teknolojilere uyumluluk problemleri, Kiilerin istekleri deimi olabilir, Yasalardaki deiiklikler yazlmn deimesine neden olabilir. Yeni zellikler eklenebilecei gibi var olan zelliklerin kaldrlmasna veya deitirilmesine sebep olabilir. Bakm testi gerekli hallerde ve bilinen periodlarda olabilir. Test edilen ilevler herdurumda ayn olmayabilir fakat genel olarak sistemin tamam da test edilebilir. Bakm testi yazlmn bakma uygun olup olmadnn testi deil yazlmn ilevlerini normal ekilde devam ettirip etirmedeinin testidir.
58
Bakm testleri planl yaplmaldr nk yazlm kullanan tm kullanclar ilgilendiren durumlar olabilir. Bakm srasnda yazlmn hizmetinde kstlamalar olabilir veya test iin kullanlacak zel objeceler olabilir. Bu durumdan kullanclarn haberdar olmal ve planlama yapmaldr. Dier yandan etki analizi yaplarak deiikliin etkisi aratrlmal ve bakm testinin ierii belirlenmelidir. Plan dahilinde bakm testine hazrlk yapmak gerekebilir. Bakm testi srasnda test sonularn karlatrmak iin mutlaka baz dkmanlara gerek vardr. Gereksinim, uzman gr, mevcut doru alan sistemler test girdisi olarak alnabilir. Dier yandan bu gereksinimler olmaksnzn yaplan testler sadece dorulama olur onaylama olmaz. Without a specification, you cannot really test, only explore. You can validate, but not verify. Kaynak: http://www.slideshare.net/onsoftwaretest/istqb-iseb-lecture-notes-2presentation
59
60
61
Statik Test Teknii Yazlm gelitirme boyunca kod seviyesine inen ve gelitirme yapan mhendislere destek vererek hatalar nceden kestirmelerine yardmc olabilen yazlm destek teknikleridir. Statik test teknikleri uygunlandnda herhangi bir kod altrmas olmaz ve yazl olan herey gzden geirme srecine dahil edilerek ktlar zerindeki hatalar nceden kestirilir. Baz statik analiz yapan aralar ile yazlan kodun kalitesi ortaya konabilir. Bu aralar genel anlamda yazlan kod satr saysn, kodun nekadar karmak yapda olduunu, nekadar snf, nesne, fonksiyonun var olduu ve almasna olanak olmayan (un-reachable code) kod parlarn aratrmaya yarar. Statik test teknikleri ile oluabilecek hatalar nceden kestirebiliriz fakat hibir zaman dinamik test (dynamic testing methods) tekniklerinin yerine gemez.
62
Anahtar kelimeler Statik Testing (Statik Testler): Yazlmn kodu altrlmadan, yazlmn kalitesiyle ilgili detaylarnn tartld genelde kod seviyesinde olan ve yazlmcnn kendi hatalarn bulmas eklinde gerekleen yazlm test aktiviteleridir. Genelde dnce hatas(error, mistake) bulunur. Dynamic Testing (Dinamik Testler): Yazlmn altrlarak yaplan testlerdir. Genelde kod belli bir olgunluk seviyesine gelir ve versiyon (srm) numaras verilerek dinamik testlere balanr. Giri-klar kontrol edilir yani yazlma girilen her bir aktivitede yazlmn verdii cevaplarn doruluu kontrol edilir. Genelde hatalar (failure) bulunur. Reviews (Gzden Geirme): Statik test teknikleri ierisinde yeralr. Kod, dkman, gereksinimler daha uzman kiilerce gzden geirilerek daha sonra ortaya kabilecek hatalar ayklanm olur.
63
Bireysel olarak yaplan gzden geirme yntemleri yazlmcnn kendisinin yaplt test yntemleridir. Bu yntemlerle grup gzden geirmeleri ncesinde kendi hatalarn azaltarak daha olgun bir bir kod ortaya kartr. Birey aktiviteler aadaki isimlerle anlrlar: Desk Checking (masada kontrol): Yazlan kodun kts alnr ve yazlmc masa banda bilgisayardan yardm almadan satr satr kod zerinden geerek olay simule etmi olur. Yazlmc mantk sorgular kontrol eder ve hatalar kendi bulur. Proof Reading (uzman deneyimi): Daha nceden yaplm ve sorunsuz alan uzmanlar tarafndan hazrlanm kod, algoritma vb., dkmanlar okuyarak kendi ktlarn test edilir. Grup olarak yaplan gzden geirmler ise konuda uzmanlam kiiler tarafndan yaplr. Burada ama sistematik bir ekilde n yarglardan uzaklaarak baka kiilerin yakayabilecei hata veya hataya sebep verebilecek zayf yaplar ortadan kaldrmak amalanr. Grup gzden geirmeleri aadaki methodlardan oluur: Reviews (Gzden geirme): Formal ya da informal yaplabilir. Bireysel veya grup olarak yaplabilir fakat genelde grup yaplr. Formal yaplan gzden geirmeler hazrlkl ve zamanlamas nceden planlanm olur. Uzmanlar konuyu deerlendirerek kendi fikirlierini ortaya koyar ve bir ortak karar kmas durumunda uygulamasna geilir. nformal olarak yaplan gzden geirmeler genelde hazrlksz ve ksa grmeler eklinde gerekleir. Walkthrough (zerinden geme): Planl bir ekilde ve ncesinde katlmclarn hazrlanarak katld grmelerdir. Walkthroughda dkmann veya kodun sahibi toplantda ktlarn zerinden satr satr geer. Inspection (inceleme): En formal olan gzden geirme tekniidir. Planl, dkmante ve aralar yardm ile yaplr. Gzden geirme srasnda saptanan hatalar raporlanr ve dzeltilmesi iin yazlmcya haber verilir. Bu sayede inspector (inceleyeciler) ile kodu yazan kii ortak kanya vardklarnda sre tamamlanm olur ve onaylanan kod, dkman bir sonraki srece geer.
64
Gzden geirme ilemleri genel anlamda yazlmcnn rettii kod paralarnn hedef almakla birlikte SDLCde her srete retilen ktlar gzden geirmeye dahil edilebilir. Bylelikle konudan ve detaydan bamsz olarak sreteki tm ktlarn kalitesi artar ve test sreci boyunca yakalanan hata ve etkileri enaza indirgenmi olur.
65
Gzden geirme faliyetlerinin salad faydalar; zellikle gereksinimlerin gzden geirilmesinde saptanan tutarszlklar yazlm maliyeti zerine nemli etkileri vardr. Erken evrelerde yakalanan hatalarn dzeltilmemesi daha sonraki sreler nekadar iyi olursa olsun rettii ktlar hatal olacaktr. Bu durumda yazlm rn ortaya ktnda bu tr hatalarn dzeltilmesi ancak hatann balad sreteki tutarszln bulunmas ve ordan sonraki tm srelerde bulunan hatann dzeltilmesiyle giderilecektir. Gzden geirme ile daha fazla bilgi paylam ve gruplar arasndaki ahenk artar. Mterinin istekleri daha net anlalr ve tutarszlklar giderilebilir. Bu sayede mteri memnuniyeti artar.
66
Anahtar Kelimeler: Entry criteria (Teste balama kriteri): Gelitirmenin belli bir olgunluga eriip (smoke testten geebilen) test alnmas iin gerekli kriterlerdir. Exit Criteria (Testi sonlandrma kriterleri): Yeterli miktarda test yaplip yaplmadnn anlalmas iin konulan kriterlere testi sonlandrma kriterleri denir. Risk ynetimi yapmak daha salkl sonular verir. Formal Review (Formal gzden geirme): Planl ve hazrlanarak yaplan ve sreleri olan gzden geirmelerdir. Informal Review (Formal olmayan gzden geirmeler): Hzlca ve plansz bir ekilde sonuca gitmek adna uzman kiilerle yaplan ve genelde dkmante edilmeyen toplantlardr. Inspection (nceleme): Kurallar olan ve bulgularn raporland ve bir lider tarafndan ynetilen bireysel veya grubca yaplan gzden geirme toplantlardr. Moderator (Moderatr): Toplantlar yneten kiiler Reviewer (neleyici): Kod, dkman, vb. inceleyen uzmanlam kiiler Scribe (Ynetici): Planlamay yapar, ynetir, iletiim kurar. Technical Review (Teknik gzden geirmeler): Kod, sistem gereksinimleri, database tasarm gibi teknik konularn tartld toplantlardr. Teknik gzden geirmelerin sorunu zmek, alternatif zmler zerine tartmak ve en efektifine zme karar vermek, kurallara uygunluu denetlemek gibi amalar olabilir. Walkthrough: stnden gemek. Yazarn neler yaptn ilgili kiilere aktarr, yazc (scribe) katlabilir, ve amac retmek, hata bulmak, katlmc yorumu almak eklinde sralanabilir.
67
Bu sreler formal gzden geirmeler iin geerlidir. Formal olmayan gzden geirmeler genelde planl ve hazrlkl olmad iin herhangi sreden bahsetmek zordur. Formal gzden geirmeler ise: Plan Yapma almalar Bilgilendirme Takip Etme Hazrlanma Toplantlar Dzeltme
eklinde sralanabilir. Takip etme sreci saptanan hata ve eksiklerin giderilmesinin kontrol edilmesi eklindedir ve herzaman olmayabilir.
68
Roller Leader/ Moderator (Lider/Moderatr): Toplantlar yneten kiiler Author (Yazar): Kod, dkman, vb. sahibi Reviewers/Inspectors (neleyici): Kod, dkman, vb. inceleyen uzmanlam kiiler Managers (Ynetici): Planlamay yapar, ynetir, iletiim kurar. Scribe (Yazc): Toplat srasndaki tm bulgular, gereklilikleri, vb. Kayteder.
69
70
Anahtar Kelimeler:
Complier (Derleyici): Yazlan kodlarn derlenmesi ve altrlmasn salayan aralardr. Cyclomatic Complexity: Yazlan kodun nekadar karmak olduunu gsteren bir parametre. Control Flow (Ak emas): Yazlan kodun iletilmesi srasnda neleri yapacan gsteren yol, ak ema. Data Flow (Veri Ak): Veri akn (oluturma kullanma yoketme) admlarn soyut bir ekilde anlatan ak emalardr. Static Analysis (Statik analiz): Yazlm oluturan paralarn (kod, analiz, gereksinim, vb.) altrmakszn analiz edilmesidir.
71
Statik analiz yapan aralar programlar altrmazlar, analiz yaparlar. Analiz yaplacak paralar kod olabilecei gibi HTML veya XML gibi dosyalarda olabilir. Bu tr proramlar ak emasn ve data akn kartabilir. Bu aklar yardmyla yazlan kodla ilgili (dngler, satr says, tekrar eden kod paralar, vb.) bilgiler verir.
72
Statik analiz sonucunda bulunan hatalar yazlmn i yapsyla ilgilidir. Burada bulunan herbir bulgunun nemi, dzeltilmedii durumda yazlma maliyeti ok byk olur. Kullanlan dile gre deiiklikler gsterebilir. Bu tr aralar kullanmak beraberinde yazlm dilini iyi bilmeyi zorunlu hale getirir, bu yzden genelde yazlm gelitiriciler tarafndan kullanlr. Bulunan hatalarn anlamlandrlmas gerekir ve dzeltme yapldktan sonra ayn statik analiz teknikleri kullanlarak tekrar analiz yaplmas gerekir. zellikle birim ve birim entegrasyon testi srasndaki testlerde ok sayda uyar veya hata verebilir, bu uyarlarn dikkatli bir ekilde ynetilmesi gerekir.
73
74
75
Test Tasarm Teknikleri Statik test teknikleriyle kod veya dkman incelemesi yaplyor ama bahis konusu olan kod altrlmadan uygun tekniklerle hatalar saptanyordu. Dinamik test teknikleriyle (dynamic test tecniques) ise kod altrlyor ve test teknikleri alan koda uygulanyor. Bu yzden yazlmn belli bir olgunlua erimi olmas gerekir. teratif yazlm gelitirme sreci iletiliyor ise iterasyon ierisindeki ilerin tamamlanm olmas ideal dnyada istenilen durumdur.
76
Anahtar kelimeler Test cases (Test Kase): Bir bulguyu test etmek iin gerekli tm bilgileri (test datas, test admlar, test aklamas, test baarl sonucu, vb.) ierisinde barndran test faliyetine genel olarak test case denir. Test case specification (Test Kase Aklamas): Bir grub test case iin (test set) hazrlanm ve o test seti koturmak iin gerekli bilgileri ieren dkmandr. Test condition (Test Koulu): Bir veya birden fazla test casenin koturulmas iin gerekli koullar. Test data (Test Verisi): Test caseleri koturmak iin kullanlan veriler (kullanc bilgilieri, ifre, kupon, kod, numara, vb.) Test procedure specification (Test Koturma Admlar): Test caseleri koturmak iin yaplmas gerekenlerin (test steps) sral bir ekilde (adm-adm) verildii dkman. Tets script: Test caseleri otomatik koturmak iin yazlm kod paralar. Traceability: Dkman veya program ierisinde ilgili paralarn izlenebilmesine (ilgili kod nerden carld, nerelerde kullanld, vb.) olanak veren bir zelliktir.
77
Testilerin test yaparken kullandklar dkman ve testleri sonucunda ortaya koyduklar dkmantasyon formal ve formal olmayan firmalar arasnda farkllklar gsterebilir. Millyonlarca kiinin kulland bir web uygulamas ile belirli bir grub tarafndan kullanlan bir grafik uygulamasnn gereksinimleri veya kurumsal kltr olan ok uluslu bir firma ile start-up firmasnn i kltr arasndaki farkllklardan dolay her iki durumuda farkl deerlendirmek gerekir. Genel manada ie yarayandan fazla dkman retmek kimsenin faydasna olmad gibi dinamik yapyada zarar verebilir. Test yapabilmek iin baz bilgilerin hazr olmas gerekir. Gerekli tm gereksinimlerin aratrlmas iine test analizi denir. Gerekli bilgiler ksaca unlardan oluur: Neyin test edilecei Nasl test edilecei Test etmek iin gerekli veriler Testin baarl olmas iin gerekli koullar Testin sonularn deerlendirmek iin gerekli bilgiler Herhangi bir zelliin (fonksiyon, snf, vb.) deimesine mkatip yazlm ierisinde etkilenen ksmlarn izlenmesi ve etkilenen test caselerin yeni duruma gre gncellenmesi gerekir. Eger bir yazlmda bu zellik kolay anlalr deil ise gncellemeler karsnda test caseleri dzenlemek zorlar.
78
Test edebilmek iin test tasarmnn yaplmas gerekir (test case hazrlayabilmek iin). Test tasarm iin ncelikle tasarm srasnda gerekli bilgilerin toplanmas ve bunlara bal kalarak tasarma geilmelidir. Test tasarmnda en nemli nokta hatal durumun varln ortaya koyacak gerekli artlar ve bu artlar altnda yaplmas gerekenler ve daha sonra istenile durumun ne olduudur. Hatal durumdan bamsz olarak doru durumun bulunmas iin gerekli bilgiler test oracle denir. Test caseler hazrlandktan sonra tatbikine (test implementation) geilmeden nce test caseler amalar ve fonksiyonlar gz nne alarak ynetilebilir gruplar (test set) haline dntrlmelidir. Gruplanan test caseleri ise kendi icerisinde sralamak, nceliklendirmek gerekir. rnein satnalma yaplmadan sipari iptali yaplamaz veya yama (patch) yazlma aktarlmadan sonuc grlemez gibi mantk sralamas yaplmaldr.
79
Anahtar kelimeler BB Test Design Tech. (Black Box Kara Kutu Test Teknikleri): Yazlmn fonksyionlar test edilir. Yazlmn i yaps (kod, database, aktarm, vb.) grlmedii iin kullanc gibi test test edilir, bu yzden kara-kutu testler denir. Girilere karlk gelen klar kontrol edilir, hatal klar saptanr. Exp. Based Design Tech. (Experience Based Deneyim Temelli Test Teknikleri): Testcilerin deneyimlerinden yola karak test edilir. Farkl alanlar iin farkl test metodlar kullanlr. Hatalarn beklemesi (defect clustering) bu test tekniinde nemli yeralr. Spec. Based Design Tech. (Specification Based Fonksiyon Temelli Test Teknikleri): Kara kutu test teknikleridir. Struc. Based Design Tech (Structural Based Yapsal Test Teknikleri): Beyaz kutu test teknikleridir. WB Design Tech. (White Box Beyaz Kutu Test Teknikleri): Yazlmn i dinamikleri (algoritmalar, mantk yaplar, database sorgular, mimari yaps, vb.) gz nne alnarak analiz ktlar test edilir.
80
81
Test Tekniklerinin Kullanm: Kara Kutu testleri (black box) yazlmn her seviyesinde kullanlabilir fakat fonksiyonlarn ortaya km olmas gerekir. Kullanc kabul testleri veya sistem testlerinde gereksinimler baz alnabilir, birim veya entegrasyon testlerinde ise alt seviye analiz dkmanlar veya tasarm dkmanlar baz alnabilir. Beyaz Kutu testleri (yapsal testler) yazlmn i yapsyla ilgili olduu iin gelitirici birim testlerinde veya birimlerin entegrasyonu srasnda yapsal testleri kullanabilir. Aralar yardmyla birlikte kod kapsamnn (code coverage) testi iinde kullanlabilir. Deneyim temelli testler ise beyazkutu ve karakutu testleri tamamlayc olarak grev yapar. Tanml fonksiyon ve gereksinimlerin olmad (analiz eksikliinde) kullanlabilir. Kiilerin deneyimlerinden yola karak test edildii iin baz nemli eksikler veya projeye zel maddeler gz ard edilebilir. Genel olarak dk riski veya zaman basksnn fazla olduu durumlarda kullanlabilir.
82
Anahtar Kelimeler Boundary Value Analysis (Snr Deer Analizi): Snr deerler kontrol edilir. rnein: gereksinimler ierisinde 18 ya snr var ise yazlmn 17, 18 ve 19 girdilerine kar rettii ktlar test edilir. Decision Table Testing (Karar Tablosu Testi): Eer kontrol edilecek ok sayda durum var ise her bir durumu tablo ierisine alnr ve herbir duruma kar yazlmn vericei cevaplar yine tabloya yerletirilerek karar tablosu oluturulur. Equivalence Partitioning (Edeer Aralk Test): Ayn sonular reten girdiler gruplanarak sadece farkl sonular reten giri deerleri grublanm snrlandrlm olur. Test iin her bir gruptan bir giri deerini kullanmak yeterli olacaktr. rnein: gereksinimler ierisinde 18 ya snr var ise yazlmn 18 yana kadar olanlar (1, ...17) iin hayr, 18den sonras iin (18, ...) evet retecekse 5 ve 25 burada kullanlabilir. State Transition Testing (Durum ei Testi): Yazlmn durum geii gsterdii yerlerin testleridir. Use Case Testing (Fayda Analizi Test): Analiz ktlarnn testidir.
83
Equivalence Partitioning Edeer aralk yntemi, ayn blgedeki deerler girdi olarak kullanldnda ayn sonucu verir n koulundan almaktadr. rnekte verilen kod parasnda 5 ya ve daha kkler bebek, 6-17 ya aralnda bulunanlar ocuk ve 18 ya stndekiler yetikin olarak deerlendiriliyor. Byle bir durumda e deer (ayn sonucu veren) blgeleri say dorusu zerinde grebiliriz. Bu yntemle test etmek istediimizde kullanabilceimiz giri deerleri srasyla (3, 12, 25) veya kurala uygun baka deerler olabilir. Burada dikkat edilmesi gereken bir baka konu ise giri deerlerini 0 ile +sonsuz arasnda snrlandn dndk fakat gerek hayatta kullanclarn her trl giri deerleri girebilecei unutulmamaldr. Fakat bu yntemde bu gz ard edilir ve yazlmn bu kontrolleri yapt varsaylr.
84
Snr Deer Testleri Snr deer testleri deiim noktalarnda yazlmn kararlln test etmek zere yaplr. Bu yuzden edeer aralklarn kartlmas ve en byk ve en kk deiim noktalarnn saptanmas gerekir. 2-deerli ve 3-deerli snr deer testi yaklam vardr. 2-deerli yaklamda deiim noktas ve bir sonraki deer alnrken 3-deerli yaklamda deiim noktas, bir nceki ve bir sonraki deerleri de ierisine alan farkl deer test edilir. Buradaki rnegimizde 17 ya deiim noktasdr yani 17 girdisiyle ocuk ve 18 girdisiyle yetikin ktlar alcaktr; ayn ekilde 5 deeride deiim noktasdr ve 5 ile bebek, 6 ile ocuk ktlar alcaktr. Bu durumda 2-deer yaklam ile (5, 6; 17, 18) snr deerleri test iin kullanmak gerekir. 3-deer yaklamnda ise deiim noktalarnn bir nceki deerleri hesaba katlr yani snr deer girdileri (4, 5, 6; 16, 17, 18) olarak kullanlmas gerekir.
85
Karar TablosuTestleri kurallar veya gereksinimlerden test edilecek koullarn says fazla ise mevcut durum bir tablo zerine aktarlarak karar tablosu oluturalabilir. ekilde grld gibi her bir durum kural olarak tanmlanmtr. Burada her koul sadece dogru (T) veya yanl (F) deerleri ald gz nne alnmtr dolaysyla 3 artn olas kombinasyonu (2^3 = 8) ile test edilebilcek durum says 8 adettir. Bu durum daha karmak sistemlerde daha byk rakamlara ulaabilir, byle durumlarda olas durumlar gruplamak ve her gruptan bir test set oluturmak mantkl olacaktr veya risk analizi yapmak test set saysn azalmakta faydal olabilir. Bu tabloda yazlmn vermesi gereken sonular Actions ksmnda gsterilmitir.
86
Durum Gei Testi Gei durumlarnda ortaya kabilicek sorunlarn kontrol edilmesidir. ekilde grld gibi bir atmde olas durumlar ortaya konmutur. Kullancnn kartn atmye yerletiresiyle balayan sre snrl durumlar arasnda gei yaparak kullancnn isteklerini yerine getirmesini salamaktadr. rnein, kiinin hesap bilgilerine ulamas iin ncelikle ifresini doru girmesi ve hesap bilgilerine tklamas gerekmektedir. Eer kii hesap bilgilerini 3kez art arda doru girmesse kullancnn kartn atm el koymaktadr. Baka bir durum ise hesabna erierek hesabndan para ekmesidir. Hesabnda yeteince para ver ise parasn ekebilir yok ise bu sefer gei durumunda hata oluacak ve para de durumuna gei yapmadan limit yetersiz uyars durumuna gei yapmas gerekecektir.
87
Fayda Analizi Testi Use-case anlam olarak bakldnda, bir sistemin harici bir kaynaktan gelen isteklerine verdii cevap olarak tarif etmek mmkndr. Use-Case test tekniinde bir kullanc aktr (A) ve yazlma karlk olarakta bir sistem (S) vardr. Aktrn her hareketi ve bu hareketine karlk sistemin verdii cevaplar geerli bir durum olarak kayt edilir. Use case testi ile entegrasyondan kaynakl hatalar bulmak kolaydr nk aktr farkl arayzler arasnda srekli iletiim kurarak gerek dnyadaki ilerini yapar. ekilde de grld gibi aktrn (A) istekleri sistem (S) tarafndan verdii cevaplar srasyla ilerlemektedir bu ilerleyite herhangi bir sorun yoktur ver kullanc mutludur yani buras mutlu yol (happy path) olarak adlandrlr. Ek bilgilerde (extensions) ise sistem tarafnda verilebilecek alternatif cevaplar yeralmaktadr.
88
Anahtar Kelimeler Code Coverage (Kod Kapsam): Hangi kod paralarnn altrlp hangilerinin altrlmadn lmek iin kullanlan bir birimdir. Decision Coverage (Kontrol Noktalarnn Kapsam): Kod ierisinde nekadar dngnn altrldn gstermek iin kullanlan bir birimdir. altrlan toplam dnglerin koddaki tm dnglere oran ile bulunur Statement Coverage (Tm Noktolarn Kapsam): koddaki ifadelerin altrma orann bulmak iin kullanlan bir birimdir. Structural Testing (Yapsal Testler): Beyaz kutu testleride denilen yazlmn i yapsn test etmeye ynelik test teslerdir.
89
Test Kapsam Yazlm zerinde nekadar test yapldn anlamak zere gelitirilmi metriklere kapsama (coverage) denir ve genel olarak toplam altrlan test casenin altrlmas gereken toplam test caselere orandr. Farkl kapsamlar lmek iin ayn forml kullanlsa da her bir kapsam kendi ierisinde deerlendirilir. Bu blm ierisinde deerlendirilecek baz kapsamlar unlardr: Statement Coverage (fadelerin Kapsam) Decision / Branch Coverage (Karar Noktalarn Kapsam) Linear Code Sequence And Jump (LCSAJ) (Olabilecek Tm Durumlarn Kapsanmas) Cyclomatic Complexity Kodun ak diaram kartldktan sonra kodun nekadar karmak olduunu gsteren bir metriktir. Formlle hesaplanabilecei gibi en basit ekliyle toplam karar ifadelerinin (if) says art bir eklinde de hesaplanabilir.
90
91
92
93
Anahtar Kelimeler Error Guessing (Hata Tahmini): Deneyimlerden yola karak, uygulama ve konu bazl hata oluabilecek fonksiyon, durum, analiz noktalarnn tahmin edilerek o amaca ynelik testleri planlamak. Analizin olmad ve zaman kstnn olduu durumlarda bu yola bavurulabilir. Exploratory Testing (Keif Temelli Test): Yine deneyimlerin n planda olduu, analizin olmad durumlarda sistematic olarak uygulamann incelenmesi ve test edilmesine dayal test tekniidir.
94
Hata Tahmini Hatalar tahmin etme yntemi tamamlayc bir yntem olduundan ilk method olarak kullanlamaz. Kural yoktur bu yzden testinin deneyimleri n plandadr ve daha nceden benzer uygulamalar test etmi olmak nemli bir avantajdr. Analizin olmad ve srenin kstl olduu durumlarda kullanlabilir. Deneme yanlma eklinde yazlmn verdii cevaplarn manta uygunluu kontrol edilir. Tam olarak bir method olmasada, yazlm grubunun veya uygulama bazl daha nceden kaydedilmi hatalar (defect) yazlmn ekibinin gl ve zayf yanlarn verebilir ve buradan kartlacak defect haritas hata tahmininde kullanlabilir.
95
Keif Temelli Test Analizin zayf ve olmad ve zaman sknts olan durumlarda yaplabilecek bir test teknii veya dier test tekniklerini tamamlayc olarak uygulamak doru bir davrantr. Analiz ve tasarm olmadndan, test yaplrken (test execution) srasnda bu iler paralel olarak yaplr. Test srasnda dkmantasyon yoktur sadece bulunan hatalar raporlanr. Testler manuel iletilir bu yzden test scriptleri yoktur. Bir metoda bal kalarak iletilmese de test srasnda testinin karar verdii yntemler kullanlr. Keif temelli testler isminden de anlalaca zere yazlm kefetmek amac gtmektedir. Yazlma testler yaparak yazlmn gl, zayf yanlarn bulmak; yazlmn neler yapp neler yapmadn ve neleri yanl yapt renmek zere yaplr.
96
Hangisi Doru Teknik Doru tekniin bulunmas testin baars ve yeterli kalitenin zaman kst ierisinde yakalanmas asndan nemlidir. En iyi teknii kullanmak istenir fakat her durum iin farkl teknikler farkl tr hatalarn bulunmasn salar. Bu yzden en iyi teknii aramak yerine, mevcut durum incelenmeli kstlar ve imkan gz nne alnmal ve verilere gre uygun yntemler denenmelidir. Uygun yntemi bulmak iin sralanm faktrler gz nne alnmaldr, bu faktrler buradakilerle snr olmamakla birlikte nem sralamas yazlmn trne ve risk trlerine gre farkllklar gsterebilir.
97
98
99
Test Tasarm Teknikleri Statik test teknikleriyle kod veya dkman incelemesi yaplyor ama bahis konusu olan kod altrlmadan uygun tekniklerle hatalar saptanyordu. Dinamik test teknikleriyle (dynamic test tecniques) ise kod altrlyor ve test teknikleri alan koda uygulanyor. Bu yzden yazlmn belli bir olgunlua erimi olmas gerekir. teratif yazlm gelitirme sreci iletiliyor ise iterasyon ierisindeki ilerin tamamlanm olmas ideal dnyada istenilen durumdur.
100
Anahtar Kelimeler Tester (Testi): Test yapan kiiler. Test Leader (Test Lideri): Geni test gruplar ierisinde testilere grevlerini datan, biraz daha stten bakabilen kiilerdir. Sanlann aksine birebir test yaparlar. Test Manager (Test Grubu Yneticisi): Test grubunu yneten kiilerdir.
101
Yazlm biriminin rettii kodlar test etmek iin farkl organizasyonlar oluturulabilir. Bunlarn en basiti yazlmc tarafndan yazlan kod yine kendisi tarafndan test edilerek kullancnn kullanmna sunulmas eklindedir. Bu tr yaplarda test organizasyonundan bahsetmek gtr cnk aslnda yazlmcnn yapt test deil kendini snamasdr. Bu tr bir test iinde ciddi sorunlar veya riskler olmasndan dolay bu tip test aktivitesi daha ok snrl sayda ve bilinli kullanclarn kulland programlar iin geerli olabilir. Daha gelimi test organizasyonlarnda ise gerek bir formal yapdan bahsedilebilir. Herbir organizasyonun kendi zel iyi ve kt yanlar bulunmaktadr. Bu yzden en uygun yapy belirlerken yazlm grubunun ihtiyalar, yeterliliklerini ve elde bulunan kaynaklar iyi analiz etmek gerekir. Test grubu genel anlamda dier birimlere hizmet sunar yani retime katks snrldr fakat retilen rnn kalitesinde nemli rol oynar. Bu yzden kalite gibi bir ama var ise test grubu olmazsa olmazlardandr.
102
Yazlmc kendi yazd kodu test eder. Yazlmc daha ok kod yazan kiiler olduundan dolay bak as herzaman kod dzeyinde olur. Yazlan kodun iersinde mantk ak, fonksiyon parametleri gibi en alt dzeyde incelemeler yapmaya alkndr. Bu yzden kendi yazd kodu ok iyi bilir, zayf yanlarn tespit eder fakat st dzeyde bakmak zorlar. Yani entegrasyon gibi dier birimlerin testin ierisinde dahil olmasnda grlebilecek hatalar zerine dnmez ve bu gibi etkileimlerin sorunsuz alt zerine yazar ve test eder. zellikle iyi bir analiz edilmeden yazlmcdan kod yazmasn beklemek hatal sonular verebilir nk istenilenlerin analizi yazlmcya kalr. Yazlmc ise analizi kendi kod snrlar ierisinde deerlendirme tehlikesi tar ve test srecine geldiinde ise hatal sonular grmeme gibi durumlar veya kendi iini bozmaktan kanmak gibi tehlikeler olabilir. Fakat bununla birlikte bulduu hatalar abucak zebilir.
103
Bir yazlmcnn yazd kodu yine baka bir yazlmc test eder. Test eden kii yazlmc olmasndan dolay teknik bilgisi ve kod yazma yetenei gelimitir bu yzden saptanan hatalar daha iyi raporlama yapabilir ve kodu yazan yazlmc ile daha kolay anlaabilir. Yazlmclarla birlikte i yapmasndan dolay yardmlama daha st seviyededir. Fakat yazlmclarn yapt testler daha ok teknik detaylara odaklanma eklinde olabilir ve i birimlerinin istekleri gz ard edilebilir. Ayrca yazlmc test iini ek i olarak grr nk esas ii kendisine atanm yazm gelistirme ilerine zaman harar bu yzden oluan bask tarafsz i yapmasn engelleyebilir. Ksa zamanda daha iyi test yapmak ancak test yeteneklerinin gelimesi ve doru test tekniinin doru zamanda uyulanmasyla olabilir. Yazlmclarn test zerine fazla eitim almadn sylemek yanl olmaz.
104
Yazlm grubunun yannda ayrca esas ii test yapmak olan test grubunun bulunmasyla oluan bir organizasyondur. Test grubu kendi kalite standartlarn belirler ve buna uygun tamamlanm ileri gerek ayrk olarak gerek entegrasyon balamnda test ederek oluan srmleri, paketleri, proramlarn kullancya alp almamas (deployment) kararn ortaya koyar. Test grubunun sorumluluk alan genelde yazlm grubunun rettii hereyi test etmek ve firmann kalite standartlarnda olup olmadn teyit etmek ve var ise riskleri raporlamaktr. Yani tarafsz bir ekilde yazlm deerlendirebilir. Test grubu bozulmaya msait bir gruptur nk farkl gruplarn karlar bu grup tarafndan kontrol edilmektedir. grubunun isteklerinin doruluu (validation), veya yazlm grubunun vaadettiinin geerlilii (verification) kontrol edilirken her bir grubun isteklerini tarafsz yerine getirmek ve bunu uzun sreler boyunca devam ettirmek zordur. Gerek ikili ilikiler gerekse ast-st kavramlarndan dolay veya patronun para odakl mantkl veya mantksz isteklerinden dolay tarafszl koruma zordur. Yalnzlama ihtimali yani test ileri bir kede bakalarnn istedii yapma riski vardr.
105
Yazlm grubunun yannda ayrca esas ii test yapmak olan test grubunun bulunmasyla oluan bir organizasyondur. Test grubu kendi kalite standartlarn belirler ve buna uygun tamamlanm ileri gerek ayrk olarak gerek entegrasyon balamnda test ederek oluan srmleri, paketleri, proramlarn kullancya alp almamas (deployment) kararn ortaya koyar. Test grubunun sorumluluk alan genelde yazlm grubunun rettii hereyi test etmek ve firmann kalite standartlarnda olup olmadn teyit etmek ve var ise riskleri raporlamaktr. Yani tarafsz bir ekilde yazlm deerlendirebilir. Test grubu bozulmaya msait bir gruptur nk farkl gruplarn karlar bu grup tarafndan kontrol edilmektedir. grubunun isteklerinin doruluu (validation), veya yazlm grubunun vaadettiinin geerlilii (verification) kontrol edilirken her bir grubun isteklerini tarafsz yerine getirmek ve bunu uzun sreler boyunca devam ettirmek zordur. Gerek ikili ilikiler gerekse ast-st kavramlarndan dolay veya patronun para odakl mantkl veya mantksz isteklerinden dolay tarafszl koruma zordur. Yalnzlama ihtimali yani test ileri bir kede bakalarnn istedii yapma riski vardr.
106
Yazlmn belli bir olgunlua eritikten sonra firma dnda ii yazlm testi yapmak olan firmalara test iinin yaptrlmas eklindedir. Yani bu tip organizasyonlar test ii bir hizmet olarak (testing as a service) harici kaynaklardan salanyor ve szleme bittikten sonra hizmet tamamlanm oluyor. Bu tr organizasyonun en byk faydalar farkl firmalarda bir ok test yapm danmanlarn geerleme (validation) srasnda eksik ve hatalar kolay grmeleri rnnn olgunluunu arttrr. n yarglardan uzak yazlm tarafsz deerlendirebilir. Genel olarak performance, gvenlik, kullanlabilirlik gibi fonksiyonel olmayan uzmanlk gerektiren ilerin bu tr kaynaklar vastasyla salanmas daha mantkldr. nk maliyetleri yksek ve esasndan firmann ierisinde olmadndan fonksiyonel testler iin rn bilgisi fazla yoktur. Ayrca yazlmn olgunluu yeterli olmad durumlarda fonksiyonel testlerde kan hatalar bu tip testiler tarafndan fazlaca bulunabilir ve buda test iin sreyi amaya neden olabilir. Geerleme testleri iin gerekli olan farkl firma ve rn deneyimi eer gizli veya gvenlii yksek olan iler yaplyorsa bu deneyimin, bilgi veya tekniin test danmanlar tarafndan dar kma ihtimali vardr.
107
Anahtar Kelimeler Entry criteria (Teste balama kriteri): Gelitirmenin belli bir olgunluga eriip (smoke testten geebilen) test alnmas iin gerekli kriterlerdir. Exit Criteria (Testi sonlandrma kriterleri): Yeterli miktarda test yaplip yaplmadnn anlalmas iin konulan kriterlere testi sonlandrma kriterleri denir. Risk ynetimi yapmak daha salkl sonular verir. Tets Plan (Test Plan): Test srasnda uyulmas gereken kurallarn bulunduu test balamadan nce hazrlanan plan Test level (Test Seviyesi): Test seviyesi, birim-entegrasyon- ... Test Approach (Test Yaklam): Hangi tip test grubunun hazrlanacan tanmlayan firmann benimsedii test methodlarnn semmeye yarayan yntemlerdir. Test Strategy (Test Stratejisi): Test yaklamnda belirlenen test trlerinin iletilmesi, teste balama, testi sonladrma kritleri, hata raporlamas, vb ierisine alan test ynetimi. Test Procedure (Test Admlar): Testi iletmek iin gerekli olan admlarn anlatld dkman.
108
Test plan proje kapsamndaki test ile alakal tm ileri iersinde barndran ve mantk sralamasna sokan proje plandr. Plana sadk kalarak test ilgili tm ileri yapmak mmkn olacak ekilde tm konular iermelidir. Fakat her iin nasl yaplaca gibi detay bilgiler yerine herkesin anlayabilicei lde detay ierir olmaldr. nk test plan farkl gruptan kiilerle iletiim kurmaya yardmc olur. Test srasnda oluabilecek sapmalarda manevra kabiliyeti olabilmeli nk test srasnda nekadar hatann bulunaca belli olmad iin plandan sapmalar ynetebilmeli ve olabildiince elemine etmelidir. Teste balamadan nce ilgili kiilerle grrlerek dnceleri toplanmal ve ortak mutabaka varlmaldr.
109
yi bir test plan sayl maddeleri iermelidir. Test plann amac nesnel bir ekilde projeyi test ederken oluabilecek skntlar ortaya koymaktr. Kstlar bu yzden nemlidir, test ortamnda veya test edilemeyecek ksmlarn bulmas teste harcanacak eforu daha salkl planlamaya yardmc olur ve daha verimli sonular alnabilir.
110
Teste balama kriterleri, gelitirilmekte olan rnden bir iterasyon alnp bu iterasyonun test hazr olup olmadn kontrol eden eksikleri belirlemek zere hazrlanm test kriterleridir. terasyonu alnan rnn test iin hazr olup olmadn smoke test yaparak anlayabiliriz. Smoke test ile temel baz fonksyionlar test eder ve ok fazla hata saptanmaz ise test ileri seviye testlere geebiliriz. Eer rn smoke testten geecek kadar olgunlamam ise teste balama kriterlerini salamad iin reddedilebilir. Teste balama kriterleri ayrca test srasnda ihtiya duyulacak olan ara-gere, dkman, personel ve test datasnda ierir. Test balanldnda testi sonlandrma kriterleri yerine geldiinde test sonlandrmak gerekir yani testi sonlandrma kriterleride teste baladktan sonra ihtiyac duyulacaktr.
111
Testi tamamland artk rn kullancya alabilir denilebilmesi iin gerekli kriterlere testi sonlandrma kriterleri (exit criteria) denir. Genel olarak ya test baarl bir ekilde tamamlan ya da test/yazlm iin ayrlan sre/bte/personel/vb. Kriterlerin tkendii zaman test sonlandrlr. kinci durumda test kullancya aclma kararn risk deerlendirmesi yaplarak sonulandrlabilir, karar vericilerin saptanan hatalarn douruca zararlar iiy analiz etmeleri gerekmektedir.
112
Teste balamadan nce baz tahminlerin yaplmas test srecinin planlanmas asndan nemlidir. Tahminler ierisinde en nemli olan kaliteli bir test sreci iin gerekli en az sre ve test organizasyonunda bulanacak personel says. Test srenin tahmin edilmesi iin gz nnde tutulmas gereken parameterler; test case says ve gereksinim saylardr. Buradan yol karak tahmini test sresi aagaki gibi hesaplanabilir: test sresi = (test_case_says X test_iletim_sresi) / testci_says Yazlmc bana den testi says enok merak edilen baka bir konudur. Byle bir sihirli say bulunmamakla birlikte bu say pk geni bir aralkta deiebilir. Bu say tamamen; projenin konusu, zorluk derecesi, yazlmcnn olgunluk seviyesi, riskler, gvenlik kriterleri, firmann imaj, kullanc profili gibi geni kriterlerden etkilenir.
113
Test Stratejisi: Test yaklamnn ana hatlarn izen ve projeye zg hazrlanan kurallar btndr. Organizasyondaki herkesin bilgilenmesi ve bu dorultuda hareket etmesini salar. Test caselerin tasarlanmas, test srelerin belirlenmesi, teste balama ve testi sonlandrma kriterlerin belirlenmesinde ana rol oynar. Test Yaklam: Projeyi oluturulan btn bileenleri ierisine katarak daha baarl test sonular yakalamak iin kullanlan test tiplerinin gruplandrld test anlaydr. Deerledirilmesi gereken bileenler: Test stratejisini ve yaklamn belirlemek iin bu kriterler gz nne alnmaldr.
114
rnek bir deerlendirme yaplr ise; Bir e-ticaret firmasn rnek olarak aldmzda 2 Alanda inceleme yaplabilir: Proje konusu ve Gelitirme Ortam Analitik Yaklam: nternet zerinden sat yapld iin baz riskler vardr. rnein; gvenlik problemleri, firma imajn zedeyecek grsel ve yazm hatalar, ... Olmasndan dolay test caselerin risklerinin snflandrlmasnda kullanlabilir. Dinamic Yaklam: Gereksinimlerin olmad, planlamann tam olarak yaplmad hzl bir yazlm gelitirme ortam olmasndan tr de dinamik test yaklam kullanlabilir. Analitik ve Dinamic test stratejilerinin bileiminden oluan; Risk Temelli - Dinamik test yaklam belirlenebilir. Hata verme olasl ve daha yksek alanlara daha fazla test yapmak Keif tabanl testler yaparak hata tahminlerinde bulunarak, ilgili alanlara younlamak
115
Anahtar Kelimeler Defect Density (Hata Younluu): Hatalarn bulunma skl, bir modl zerinde saptanan hata oran Failure Rate (Hata Oran): Testte hata veren test case oran Test Control (Test Kontrol): Plandan sapma olmas durumunda test caselerin sapmay nlemek iin kontrol edilmesi Test Coverage (Test Kapsam): Mevcut test caselerin yazlmn nekadarn test ettiini gsteren bir birim Test Monitoring (Test Grntleme): Test caseler altrlrken mevcut durum ile planlanan arasndaki farklar grntlemek amal kurulmu test ynetimi faliyeti Test Report (Test Raporu): Testlerin tamamlanmasna mtakip kan sonularn zet halinde sunulduu rapor.
116
Teste baladktan sonra testin gidiatn veya yazlmn kalitesini canl olarak grntleme iine test durum grntlemesi (test progress monitoring) denir. Genel olarak ynetici veya test takim liderleri anlk rapor vermek adna bu gibi faliyetleri kullanabilirler. Test durum grntlemesi ayrca test planna nekadar sadk kalndn veya sapmalar var ise sapmalarn nelerden kaynaklandn gsterebilir. Planda tahmin edilen hata saysndaki sapmalar phesiz test iletimi srasnda daha byk sapmalara neden olacaktr. Grntleme faliyetleri ayrca takm ierisinde herkes tarafndan grlebilir olduundan herkesin kendi iin tarafsz deerlendirmesine ve dierleri ile bilgi akn salar. Ayrca kalan test ii iin nekadar daha emek (test efor) gerektiinide buradan grntlenebilir.
117
ISTQB dkmannda verilen rnek raporda testte o anki mevcut durumu gsteren bir ok bilgi yeralmaktadr. rnein buradaki raporda Plan Effort planlanan test iin haranacak emei gsteriyor ve Actual Effort ise test iletilirken haranan gerek emei gstermektedir. Bunlar ilk test iin srasyla 4 ve 6 imi yani planan dah kk olduu iin planan srede testin tamamlanmas mmkn gzkmemektedir. Planan srede testlerin tamamlanmas iin mutlaka bir mdehale gerekir. Bu mdehaleler projeye gre farkllk gstermekle birlikte unlar olabilir: Testci saysn arttrmak Test case saysn azaltmak Risk analizi yaparak Belli riskleri kontrol altna alnabilir Sreyi uzatmak
118
Anahtar Kelimeler
Configuration Manegement (Konfigrasyon Ynetimi): Sistem ierisindeki tm ekipman ve yazlmlarn (hardware and software) kontrol edildii ynetim aralarna konfigrasyon ynetimi denir. Version Control (Versiyon Kontrol): Yazlmlar zerinde yaplan deiimleri kontrol amacyla gelitirilmi ve gerektiinde istenilen deiiklii (srm) geriye almaya yarayan yazlm aralardr.
119
Konfigrasyon Ynetimi Nedir?
Konfigrasyon ynetimi, yazlmn iinde bulunduu tm alt sistemleri bir btn halinde ynetmeyi amalayan sistem ynetim aralardr. Yazlm yaayan bir canl olarak dnldnde srekli ve deien ihtiyalar olan bir hizmet aracdr. Kullanc her nekadar cou zaman bu deiimleri hissetmesede gerek donanm gerekse yazlmda meydana gelen deiimler kimi zaman mecburi kimi zamanda isteklerden kaynaklanabilir. Konfigrasyon ynetimi ise bu deiimleri kontrol eden ve herhangi bir sorun kmas durumunda en dzgn (stable) konfigrasyonu ykleyebilen ve hizmet kesintisini en aza indirmeyi hedef edinmi bir yazlm hizmetidir. Test gurubu olarak bakldnda konfigrasyonun daha farkl anlamlar da vardr. Test ancak gvenli bileenler mant ile iletilebilir. Yani sistem ierisinde n tane deiken olabilir fakat ayn anda sadece bir deiken test edilebilir bu durumda (n 1) deikenin normal (hatasz) alt varsaylmaktadr. Byle bir sistemin kontroln ancak konfigrasyon ynetimi salayabilir. Yani test yaplrken hangi bileenlerin hangi versiyonda olduklar, hangi donanmlar zerinde koturulduu ve hangi bileenlerin gncellendiini bilerek test yaplabilir. Hata saptanmas durumunda ise bu bilgiler eliinde hata zme ulalabilir.
120
Konfigrasyon ynetimine bir ok sey dahil edilebilir. Sistemdeki tm bileemleri dahil etmek daha salkl bir hizmet vermek asndan daha iyi olacaktr.
Kaynak: http://ieee.metu.edu/iffet/blog/Konfigurasyon_Yonetimi_CMII-V1.2.pdf
121
Anahtar Kelimeler Risk: Hatann ortaya kma olasl. Product Risk (rn Riski): rnn istenildii gibi tamamlanmasn engelleyebilecek etkenler. Project Risk (Proje Riski): Projenin istenildii gibi tamamlanmasn engelleyebilecek etkenler. Risk Based Testing (Risk Temelli Test): Riskleri bilerek ve riskleri gz nnde tutarak test eforunu taksim etmek ve testleri yapmak riskin yksek olduu yerlerde younlatrmay amayan test yaklam (test approach).
122
123
124
125
Risk temelli testin en nemli zelliklerinde birisi risk analizi yaplmasdr. Risk analizi mevcut durum gz nne alnarak hazrlanm test caselere verilen puanlardr. Risk analizi yapmak demek konu zerine derinlemesine incelemek demektir. Test caseler yazlrken kullanlan dkmanlar bu boyutta tekrar gzden geirilebilir. Test caselere risklerine gre puanladrlrken farkl gruplarn karlar o gruptan kiiler tarafndan temsil edilmesi nemlidir. Buyzde tm paydalar bir araya gelmeli ve puanlandrma zerinde bamsz dncelerini dile getirerek en ok vurgulanan puan ilgili test case iin kullanlmaldr. Puanlandrma kullanlacak puan aral nemlidir 1-10 gibi bir aralk kullanlmas durumunda geni bir secim sunulmaktadr ve 6 ile 7nin farkn kavramak zor olabilir fakat 1-3 gibi bir aralkta ise test caselerin alcag puanlarn ogunda eitlik sz konusu olabilir. deal yapda 1-5 aral daha ok kullanlan yntemdir. Risk temelli test tekniinin son aamasnda ise puanladrlan test caseler test iin ayrlan zaman gz nne alnarak ilgili srenin paylatrlmasdr. Burada alnacak kararla en dk risk seviyesindeki baz test caselerin test edilmemesi eklinde olabilir.
126
Tabloda grlecei gibi 3 farkl durum sz konusu. Herhangi birisine puan verirken dierlerini gz nne almak gerekir. rnein Satnalma eer bir e-ticaret firmasyla ok nemli bir gereksinim bu yzden burda kabilcek bir sorunun etkiside en byk olacaktr. Fakat Kullanc Bilgilerini Grme ye iin ksmen nemli olabilir fakat orada oluabilecek hatann etkisi ok fazla olmayabilir, bu yzden en kck puan verilebilir. Yeni yelik ise e-ticaret firmas iin nemlidir fakat kii ye olmadan da alveri yapabiliyor ise etkisi biraz daha az olucaktr. Burada durum belki pazarlama grubu iin ok nemli olabilir fakat i gelitirme veya IT grubu iin daha dk neme sahip olabilir. Yani ortaya kan ikilemi tarafsz puan vererek ve ortalamas alnarak konulabilir. Budurumda ekisi iiin 4 denebilir. Gereksinimlerde hata kma olasl ise o fonksiyonun kullanma skl ve koduyla ilgilidir. Eer sk kullanlyor ve ok fazla test edilmemi olgun bir kod deil ise kma Olas yksek olacaktr. Aksi durumda ise daha dk deerler alabilir. Sonuta elde eilen Risk Deeri baz nekadar test edilmesi gerektii sylemektedir. Bir baka deyile ortak bir kararla risk deeri belli bir deerin altndakiler test edilmemeli gibi politik bir karar alnabilir. rnein burada 12den dk riski bulunanlar test edilmemelidir denildiinde geriye kalan test caseler iin test zaman daha efektif kullanlabilir.
127
Anahtar kelimeler ncident Logging (Vaka Kayd): Test srasnda saptanan her trl hata ve eksikliin otomatik kayt altna alnd kayt sistemi. Root Cause (Problemin z): Bir sorunu zmek iin yaplan neden sonu aratrmalardr.
128
Test srasnda karlalan sorunlar herzaman hata olmayabilir fakat beklenen sonulara uymayan sonular elde ediliyor ise bu durum bir vaka (incident) olarak adlandrlr ve raporlanmas gerekir. Hatann kaynaklar incelenmeli ve sorunun zm iin gerekli kiiler haberdar edilmelidir. Saptanan hatalar genel olarak gerekten yazlmdan kaynaklanan bir hatadr veya yazlmda sorun yoktur fakat dier faktrler hatal sonu almaya ynlendiriyordur. Bu durumda kararl (stable) bir test ortam herzaman gerekliliktir ve konfigrasyon ynetimi de arttr. Unutulmamaldrki hata yazlmda olabilecei gibi test ortamnda veya dkmantasyonda da olabilir. Bu yzden bir vakann hata (bug, defect) olarak adlandrlmadan nce emin olmak gerekir. Bulunan hatalar anlalr bir ekilde raporlanmaldr.
129
Saptanan hatalar grafiine bakldnda teste balamakla birlikte hatalar bulunur genelde ilk hatann bulunmasyla hata orannda byk bir art olur ve bunlarn dzeltip kapatlmasyla birlikte yeniden hata says artar fakat bir sre sonra hata bulunmaz veya bulunma skl ok azalm olur. Yani testi sonlandrma aktivitesine iaret eder. Fakat gerek test ortamnn iyi olmamas gerek test caselerin iyi yazlmamas veya iyi bir test yaklam uygulanmamasdan veya testilerin dikkatsizliindan dolay baz hatalar canl sisteme geiten sonra kullanclar tarafndan yakalanr. Testin verimliliini lmek adna Hata Yakalama Oran gelitirilmitir. Formlde verildii gibi testte saptanan hatalarn tm hatalara oran eklindedir.
130
Herhangi bir vaka (incident) ile karlaldnda raporlamadan nce hata olup olmadndan emin olmak gerekir aksi durumda bulunan vakann dier kiiler stne bo bir ura olacak ve hata deil denip kapatlacaktr. Bu durumda bo yere harcanm emek ve testcinin itibar kayb sz konusudur. Saptanan gerekten bir hata ise hatann nasl saptanld anlalr bir ekilde raporlanmal ve ilgili kiilere (yazlmc veya organizasyona gre proje ynetcisi, yazlm lideri, vb) atanmaldr (assign). Daha sonra hata zldnde hata fixed statsne ekilerek tekrar testciye atanp test edilip soruna yol amad anlaldnda hata testci tarafndan closed statsne ekilebilir. Farkl durumlar ekilde anlatld gibi olabilir.
131
132
133
134
Anahtar Kelimeler Debugging Tool (Hata Ayklama Aralar Debuging Aralar): Proramclarn hatalar oluturmak, aratrmak ve ayklamak veya proramlar adm adm altrmak iin kullandklar aralardr. Driver: Test srasnda olmayan bir birim veya bileen yerine kullanarak testi gerekletirmeye yarayan test yazlm elemanlar. Probe Effect (lc Etkisi): Test amacyla kullanlan bir ara test edilen biriminin zerine bir etki brakr. Test sonularna yansyan bu etkiye lc (probe) etkisi denir. Performans len aralarn performans llen rn zerine olumsuz etkisi gibi. Kod coverage yapan bir aracn kodu incelemeye almas ve baz kodlar dahil edememesi gibi durumda baka bir rnektir. Daha u bir rnek ise debugging yapan bir aracn varlnda hatann bulunamamas yani hatann olumas iin debuggerin almyo olmas kouludur. Bu probe effect Heizenbergin uncertainity princible (belirsizlik kural) ile Heizenbugs adn almtr. Stub: Yazlmn iletilemeyen ksmnda tanml bir fonksiyon grevi gren ve o fonksiyon altrlmadan proramcnn istedii sonucu reten kod paralardr. Program test etmek amacyla doru altndan emin olunmayan fonksiyonlar taklit ederek geriye kalan ksmlar test edilir.
135
Test ynetimi aralar genel olarak testleri ileyii ile ilgili genel ve detay seviyede bilgiler veren aralardr. Test execution (altrlmas) yoktur fakat baka amalar iin kullanlan test aralarna entegre aarak gerekli ynetimsel verileri ekebilir. Test ynetimi aralarnn esas amac test srecini ynetmek yani test planna sadk kalnarak testlerin ileyip ilemediini takip etmek ve gerekli mdehaleleri yapmak iin kullanlr.
136
Test ynetim aralar ayrca ynetimsel baz metrik raporlarnn hazrlanmasna olanak salamaldr. lgili verileri dier test aralarndan ekebilir ve buradan alnan verileri organizyonel ihtiyac karyacak ekilde raporlar sunabilir. En nemli raporlar yine test ynetimi ile ilgili olanlardr. altrlan / altrlmayan test case says, baarl / baarsz test case says, zlm / bekleyen / reddedilen / kapatlan hata saylar ve test iin planlanan srenin nekadar etkin kullanldna ynelik metrikler ierebilir.
137
Gereksinim ynetim aralar yazl gereksinimleri depolayarak gerekli hallederde durumlarna, zelliklerine , ncelik (priority) deerine gre esitli filtrelemeler yapan test aracdr. Gereksinim ynetim toolarnn genel amac gereksinimleri toplamak ve test case hazrlamasna yardmc olmaktr. Yani test ynetim/test execution aralarna entegre olmaldr. Bu adan bakldnda kimilerine gre gereksinim aralar test ynetim arac deildir fakat nemli olan nokta testler hazrlanm gereksinimlere gre yaplr (verification). Bu yzden gereksinim ynetim aralar test iin nemlidir. Baz gelimi test ynetim aralar gereksinimler iersindeki muallak ifadeleri kontrol ederek hatal isteklerin kmasn engelleyebilir. Gereksinimlerde olabilecek deiimleri gncelleme imkan sunmaldr. Ek aralar yardmyla gereksinimlerin kapsamn gsterebilen gereksinim ynetim aralarda vardr.
138
Trkesi vaka ynetimi olarak evrilen incident manegement aralar ayrca; defect-traking, defect-manegement, bug-traking veya bug manegement tool olarakta bilinir. Test sreleri boyunca saptanan her vakann hata, bug, defect olarak isimlendirmenin doru olmayaca iin incident management tool demek daha mantkldr. Bu aralarn grevi saptanan her trl vakann kaydedilmesine, takip edilmesine ve raporlanmasna olanak salamaktr. Vaka ynetimi aralar vastasyla saptanan hatalar zlmek zere ilgili kiilere atama yapmaya olanak salamaldr bu yzden test ynetimi veya mail serverleri ile entegre alabilmelidir. Ayrca hata yaam dngsndeki tm durumlarda gsterebilecek yenetekte olmaldr.
139
Konfigrasyon ynetimi direk olarak test ynetimini ieren bir ara deildir fakat iyi bir test organizasyonu iin olmazsa olmazdr. Test asndan bakldnda konfigrasyon ynetimi tm test aralarnn (testware) ve test edilen yazlm rnlerinin (software) srmlerini ynetmeye yarayan sistem aralardr. Doru yazlm srmnn doru testware srmnde test edildiindiinin kontrol yine konfigrasyon ynetimin aralarnn zellikleridir.
140
141
Anahtar Kelimeler Data Driven Testing: Testler otomasyonla iletilir. Test iin veriler giri (input) ve k (expected result) bir tabloya girilir ve otomasyon proram buradaki verileri kullanarak yazlm test edilir. Keyword Driven Testing: Fonksiyonel bazl kelimeler zerinden test case oluturularak otomatik test yntemidir. Login createUser - logout gibi her bir kelimenin kendisi test case olacak ekilde test scriptleri hazrlanr ve senaryoya uygun kombinasyonlarla test oluturulur. Scripting Language (Scripting Dili): Test otomasyonunda kullanlabilen programlama dili.
142
Test aralar skc olan ve manuel iletilmesi ok zaman alan, hata riski fazla olan veya manuel iletilmesine olanak olmayan iler iin salayaca avantajlar vardr. Bu tr ileri test aralar vastasyla daha ksa zamanda daha gvenilir yapmak mmkn olabilir. Burada kazanlan zamanla zarfnda testiler farkl testler veya analizler yaparak rn kalitesi zerine katk salayabilir. rnein bir e-ticaret sitesi iin fazla srm kmak (yazlm gncellemesi) olur ve firma iin en byk risk tayan satnalma, yeni yelik, siteye giri gibi test caselerin otomasyon yardmyla yapmak hem zamandan kazan salar hem de testin gvenirliliini arttrr. Farkl bir adan sitenin performans test edilecek yani ayn anda ka kiiye hizmet verilebiliyor bu kontrol edilecek. Byle bir durumu arasz test etmek mmkn deildir. Performans aralaryla istenilen sayda sanal kullanc oluturularak deiik senaryolar test edilebilir. Test araalar ayrca uygulama zerine yaplm bu gibi bilgileri barndrr ve gemi-gelecek balantsyla daha nesnel deerlendirmeler yapmaya yardmc olur.
143
Test arac genel olarak ileri kolaylatrmak ve daha ksa srede daha kaliteli rnler ortaya koymak amacyla kullanlr. Fakat kullanlan test aracnn ama ara ilikisini iyi kurmak gerekir yani ama arac kullanmak m yoksa ama kaliteyi ykselmek mi. Her iki durumda aratan beklentiler farkllk gsterir. Tabiki ama kaliteyi ykseltmektir yani ara bir ekilde daha fazla emek harcamamza ve ayn sonucu almamza yolayor ise arac daha fazla kullanmak amamzn ara olduu anlamna gelir. Bazende kalite veya yazlm srelerindeki hatalar ara olmamsna dayandrlarak hereyi mehur, pahal bir ara alnarak zlcei ynnde olur. Bu durumda ara sreci deitiremeyecei iin aratan beklentiler gereki olmayacaktr. Ayrca ara iyi bilinmeli yapmayaca ileride aractan beklenilmemelidir. Naslsa bu ii ara hzla yapyor denilerek plan yaplmamaldr. Sre dzgn iliyor ve ihtiyaca uygun bir ara seilmi olsa bile baz sorunlar irdelemek gerekir. rnein yeni bir aracn firma ierisinde ilkkez kullanlmaya balanlmas bir acemilik dnemi denektir ve baz durumlarda ise eitim gerektirir. Bununla birlikte ara kullanlmaya balandktan sonra devamllk iin bakm ve ilerletme almalar iinde belli bir emek harcamak gerekir. Harcaman emein miktar ve salad yararlar birbirine kyaslanmaldr.
144
Test arac seilmeden nce organizasyon incelenmeli ve gerekten neye ihtiya duyulduu tarafsz olarak deerlendirilmelidir. Ayrca arala birlikte srete ve bilgi seviyesinde yaanacak deiimlere kullanclarn nekadar hazr olduu ve kullanmak iin gerekli donanma (bilgi, deneyim, kariyer plan, eitim istei) sahip olup olmad gibi sorularda cevap bulmal. Piyasada test rnlerinin says ok fazladr bu yzden tercih edilecek rn tarafsz olarak deerlendirilmeli ve ihtiyalara cevap verip vermedii aratrlmaldr. Tercih edilecek rnn ilk kullanmn yaanacak skntlar zlemiyorsa destek alnabilecek rnler tercih edilmelidir. Ayrc rlerin kullanc says, eitim dkmanlar, sektrdeki itibar, forum siteleri, gelimeye akl gibi faktrlerde gz nnde tutulmaldr.
145

Test Mühendisliğine Giriş Eğitimi - Bölüm 2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Test Mühendisliğine Giriş Eğitimi - Bölüm 2

Uploaded by

Copyright:

Available Formats

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Deerlendirme (eveluation) Test sonladrlmas ile test sonular deerlendirilir.

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

isteklerini yerine getirmek demek deildir.

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2

Test Mhendislii Giri Eitimi - Blm 2