Yazılımda Test Gerçekleri

Yazılım süreç modelleri bir idealdir… gerçek değildir Hiçbir yazılım geliştirme girişimi bir süreci mükemmel bir şekilde uygulayamaz. Peki neden? Şartname asla müşterinin ihtiyaçlarını tam anlamıyla kapsamaz. Hiçbir zaman bütün test işlemini gerçekleştirmek için yeterli zaman olmaz. Bunlara rağmen ilerlemek için ideal bir modele ihtiyacımız var. İmtiyazlar kaçınılmazdır.

Yazılım testinde varsayımlar (aksiyomlar) Bir programı tamamen test etmek imkansızdır. Yazılım testi riske dayalı bir uygulamadır. Test, hataların yokluğunu gösteremez. Ne kadar fazla hata bulursan o kadar daha hata vardır. Bulunan bütün hatalar düzeltilemeyecektir. Bir hatanın gerçekten bir hata olduğunu söylemek zordur. Şartnameler asla son halini almayacak. Yazılım test uzmanları proje takımında pek popüler değillerdir. Yazılım testi disiplinli ve teknik bir uzmanlık alanıdır.

Varsayım 1 Programı tamamen test etmek imkansızdır. Etraflıca test etmek için kaç tane test durumuna (test case) ihtiyaç var: Powerpoint A calculator MS Word Tamamiyle emin olmak için tek yol olası bütün girdilerle bu girdilere karşılık üretilen çıktıları gözlelemektir. Şartnamenin de doğru ve eksiksiz olması lazım.

Varsayım 1 (cont’d) It is impossible to test a program completely Olası girdilerin sayısı çok fazladır. Olası çıktıların sayısı çok fazladır. Yazılımın içindeki yolların sayısı çok fazladır. Yazılım şartnamesi yoruma açıktır. İnterpretation: yorum

Varsayım 2 Yazılım testi riske dayalı bir uygulamadır Eğer yazılımı tüm girdiler için test etmezseniz risk almış olursunuz. Neyse ki birçok doğru çalışan girdi es geçilecek. Hataya sebep olan bir girdi atlanırsa? Risk: mali kayıp, güvenlik, can kaybı! Test yapan kişinin üstünde çok baskı vardır! breaking the bank: çok pahalıya mal olmak, el yakmak

Varsayım 2 (cont’d) Yazılım testi riske dayalı bir uygulamadır Kaçırılan hataların sayısı Test maliyeti Eğer çok fazla test yapılırsa, geliştirme maliyeti altından kalkılamaz hale gelir. Eğer çok az test yapılırsa yazılım hatalarının olasılığı artar ve bu hatalar bize çok fazla zaman kaybettirir. Miktar İdeal test Az Test Çok test Prohibitive: ulaşılamaz fiyat Test sayısı

Varsayım 3 Test, hataların yokluğunu gösteremez. «Program testi hataların varlığını göstermek için kullanılabilir ancak, asla yokluklarını göstermek için kullanılmaz!» Edsger Wybe Dijkstra Dijkstra programlama dilleri alanına önemli katkılarından dolayı 1972 ACM Turing ödülünü kazanmıştır.

Tartışma… ACM nedir? ACM Turing Ödülü nedir? Alan Turing kimdir?

Varsayım 4 Ne kadar fazla hata bulursan o kadar daha hata vardır Hatalar gruplar halinde görülür. Bir hata bulduğunuz zaman muhtemelen daha çok bulacaksınız … Peki neden? Programcıların kötü günleri olabilir Programcılar genelde aynı tip hataları yapmaya meyillidirler Bazı hatalar sadece buz dağının su üstündeki kısmıdır Boris Beizer coined the term pesticide paradox to describe the phenomenon that the more you test software the more immune it becomes to your test cases. «Yazılımı ne kadar fazla test ederseniz, test durumlarınıza o kadar bağışıklık kazanacaktır.» Boris Beizer Çare: Yazılımın farklı bölümlerini incelemek için sürekli yeni ve farklı test durumları oluşturmalısınız. Remedy: çare

Varsayım 5 Bulunan bütün hatalar düzeltilemeyecektir Bildiğin bir hatayı neden düzeltemeyesin? Yeterli zaman yoktur Zaman sınırları aşılamaz Gerçekten bir kod hatası olmayabilir. Şartname yanlış olabilir Düzeltmesi çok risklidir Bir hatanın düzeltmesinin sonuçları ağır olabilir (regresyon hatası) Düzeltmeye değmez Can alıcı olmayan bazı hatalar sonra düzeltilmek üzere bekletilebilir. Y2K: Year 2000 Fringe: kenar

Varsayım 6 Bir hatanın gerçekten bir hata olduğunu söylemek zordur Yazılımda bir problem varsa ve o zamana kadar kimse bunu fark edememişse… bu bir hata mıdır? Parodi “Ormanda bir ağaç düşerse, gerçekten gürültü çıkarır mı?” Fark edilmeyen hatalara örtülü/gizli hata (latent bug) denir.

Varsayım 7 Şartnameler asla son halini almayacak Amacı/hedefi değişen şartnameye göre bir ürün geliştirmek yazılım geliştirme dünyasında neredeyse kaçınılmazdır. Şiddetli rekabet Çok hızlı piyasaya sürme periyotları Yazılım çok «kolay» değişir Diğer mühendislik alanlarında bu doğru değildir Örneğin; Boğaziçi Köprüsünün inşası başladıktan sonra treninde geçmesi için uyarlanamaz.

Varsayım 8 Yazılım test uzmanları proje takımında pek popüler değillerdir Yazılım test uzmanının hedefi: Hataları bulmak Hataları erken bulmak Hataların düzeltildiğinden emin olmak Takında iyi karşılanmak için öneriler: Hataları erken bul Heyecanını bastır… profesyonelce davran Sadece kötü haberleri raporlama

Varsayım 9 Yazılım testi disiplinli ve teknik bir uzmanlık alanıdır Yazılımların daha basit ve yönetilebilir olduğu zamanlarda yazılımı test edenler genelde eğitimsizdiler ve test uygulaması metodik olarak yapılmıyordu. It is now too costly to build buggy software. Artık günümüzde hatalı yazılım üretmek çok maliyetlidir. Bu yüzden test uygulaması bir disiplin haline gelmiştir. Çok yönlü, gelişmiş teknikler Araç desteği Tatminkar kariyerler

Bazı önemli terimler Doğrulama (Verification) Sağlama (Validation) «Ürünü doğru bir şekilde üretiyor muyuz?» Yazılım şartnameyle örtüşüyor mu? Sağlama (Validation) “Doğru ürünü mü üretiyoruz?” Yazılım müşterinin ihtiyaçlarını karşılıyor mu?

Neler öğrendik… … Yazılım testindeki 9 varsayım … Yazılım doğrulaması (verification) nedir? … Yazılım sağlaması (validation) nedir?