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.
1.
2.
3.
4.
5.
6.
7.
8.
9.
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.
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!
Varsayım 2 (cont’d)
Yazılım testi riske dayalı bir uygulamadır
• 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.
Kaçırılan hataların
sayısı
M
i
k
t
a
r
Az Test
Test maliyeti
İdeal test
Çok test
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.
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.
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)
– «Ü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?
Download

03-testing-realities_TR