Yazılımda Test Gerçekleri

... konulu sunumlar: "Yazılımda Test Gerçekleri"— Sunum transkripti:

1 Yazılımda Test Gerçekleri

2 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.

3 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.

4 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.

5 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

6 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

7 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ı

8 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.

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

10 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

11 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

12 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.

13 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.

14 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

15 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

16 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?

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