YAZILIM MÜHENDİSLİĞİ - 1 BÖLÜM 6: TEST (TESTING) Bölüm Kapsamında İncelencek Konular: Kalite ve Kalite Güvencesi Non-execution-based testing (her şeyi test etme) Execution-based testing (kodu test etme) Neleri test etmeliyiz? GİRİŞ Klasik yazılım yaşam döngüsü modellerinin çoğu, uygulama (implementation) safhasından sonra, teslim sonrası bakımdan (postdelivery maintenance) önce ayrı bir test safhasını içerir. Neden test yapıyoruz? Yazılım ürününün kaliteli olmasını sağlamak için test yapıyoruz. Test tüm yaşam döngüsü boyunca yapıldığından, bir yazılım süreci veya aktivitenin ayrılmaz bir bileşenidir. Gereksinimler işakışı (requirements workflow) boyunca gereksinimler kontrol edilir. Analiz işakışı (analysis workflow) boyunca şartname (specification) ve yazılım proje yönetim planı kontrol edilir. Tasarım işakışı (design workflow) boyunca her adım dikkatli bir şekilde kontrol edilir. - 1 -
Uygulama işakışı (implementation workflow) boyunca da, her bir kod birimi (artifact) test edilmeli ve bu kod birimleri birleştirildikten sonra ürün bir bütün olarak test edilmelidir. Yazılım müşterinin bilgisayarına kurulduktan (install) ve kabul testini (acceptence testing) geçtikten sonra teslim sonrası bakım başlar. Bakım ile yazılım ürününün düzeltilen sürümlerinin kontrolü devam eder. Sonuç olarak her işakışının sonunda düzenli olarak test yapılmalıdır. TEST (TESTING) Test in (testing) iki temel tipi vardır: Execution-based testing (kodu test etme) Non-execution-based testing (her şeyi test etme) - 2 -
Doğrulama (verification) ve Sağlama (validation) terimlerini daha önce 1. Bölümde görmüştük. Doğrulama (verification): Her işakışının sonunda yapılan test işlemine doğrulama (verification) denir. Yani bir işakışının doğru olarak tamamlanıp tamamlanmadığını tespit etmek için bu test işlemi gerçekleştirilir. Sağlama (validation): Müşteriye ürünü teslim etmeden önceki test işlemine sağlama (validation) denir. Yani bir bütün olarak ürünün müşterinin isteklerini karşılayıp karşılamadığını tespit etmek için bu test işlemi gerçekleştirilir. Uyarı! Bu ders kapsamında doğrulamayı (verification) sadece işakışını kontrol etmek için kullanmıyoruz. Doğrulama (verify) terimi bazen nonexecution-based testing (her şeyi test etmek) içinde kullanılıyor. - 3 -
YAZILIM KALİTESİ (SOFTWARE QUALITY) Yazılım mühendisliğinde kalite için, mükemmellik (excellence) denilmiyor. Şartname yazılım ürününü ne kadar fazla sağlarsa veya karşılarsa, sistem o kadar kalitelidir diyebiliriz. Yani bir yazılım ürünü, şartname dokümanında belirtilenleri ne kadar yerine getiriyorsa ürün o kadar kalitelidir. Her yazılım uzmanının (bu geliştirici veya bakımcı olabilir) görevi her zaman yüksek-kaliteli yazılımlar ortaya çıkarmaktır. İşin doğru olarak yapıldığının kontrolü, her geliştirici veya bakımcının kişisel sorumluluğundadır. Her kişi yapmış olduğu işin kaliteli olmasını sağlamalıdır. Kalite sonradan olmaz, en baştan itibaren olur. - 4 -
Yazılım Kalite Güvencesi Geliştiricilerin işini yüksek kalitede yapıp yapmadığının kontrolünü Yazılım Kalite Güvence Grubu (SQA Group) üyeleri yapar. Yani SQA grubu yazılım ürününün kaliteli olup olmadığını kontrol eder. Bu kontrol; Her işakışının sonunda (verification), Bütün ürün tamamlandıktan sonra (validation) yapılır. Kalite güvencesi, yazılım sürecinin tamamına uygulanmalıdır. - 5 -
Yönetimsel Bağımsızlık Burada geliştirme grubu ile SQA grubu arasında yönetimsel bağımsızlık olmalıdır. Hem geliştirme grubunun hem de SQA grubunun bir yöneticisi olmalıdır. Bu iki yönetici birbirinden bağımsız olmalıdır. Bir kişiye hem geliştirme, hem de SQA grubun yönetimi verilmemelidir. Bir grubun diğer grup üzerinde üstünlüğü olmalıdır. Büyük organizasyonlarda SQA grubu tüm grup üyeleri arasından belirli bir yüzde ile seçilerek bulunur. Örneğin; 100 kişilik bir organizasyonun 30 kişisini SQA grubuna atayabiliriz. Küçük organizasyonlar da ise SQA grubu ayırmak saçma olur. Örneğin; 4 ya da daha az kişiden oluşan bir grupta 1 ya da 2 kişiyi SQA grubu olarak atamak anlamsız olur. - 6 -
Bir yazılım ürününün son teslim tarihi (deadline) yaklaştı, fakat yazılımda ciddi hatalar bulundu. Böyle bir durumda daha kıdemli yönetim, bu yazılım ürününü müşteriye hataları ile birlikte mi teslim edip etmeyeceğine veya yazılımdaki hataları düzeltip müşteriye ürünü daha mı geç teslim edip etmeyeceğine karar verir. Kalite grubunun lideri ürünün müşteriye hatasız bir şekilde teslim edilmesini ister, fakat geliştirme grubunun lideri ise ürünün zamanında müşteriye teslim edilmesini ister. Bu yüzden kararlar ne SQA grubu lideri ne de geliştirme grubu lideri tarafından verilmelidir. Kararları her ikisinin de üstünde bulunan bir yönetici vermelidir. - 7 -
NON-EXECUTION-BASED TESTING (HER ŞEYİ TEST ETME) Bu test tipinin altında yatan temel prensipler; Grup içinde çalışırken kendi yaptığımız işi kesinlikle test etmemeliyiz. Yazılımı gözden geçirirken hemen hemen her insanın bilinçaltında bulunan bir önyargı veya bir kör nokta (blind spot) vardır. Örneğin, kendi yazmış olduğumuz programdaki hatayı iki saat arasınız, hatanın nerede olduğunu bulamayabilirsiniz. Fakat başka biri gelip hatanın nerede olduğunu çok kolay bulabilir. Grup birlikteliği (group synergy)! Grup içindeki üyelerin değişik yetenekleri olduğu için, hataları bulma şansı artıyor. Bu durum, gözden geçirme (review) kavramının önemini ortaya çıkarıyor. Gözden geçirmenin (review) iki tipi vardır: Adım adım inceleme (walkthroughs) Denetleme (inspection) - 8 -
ADIM ADIM İNCELEME (WALKTHROUGHS) Adım adım inceleme (walkthroughs), resmi olmayan bir gözden geçirme (review) dir. Bu gözden geçirme (review) grubu genellikle 4 ile 6 arasında kişiden oluşur. Bu gözden geçirmede; mevcut işakışını gerçekleştiren takımın temsilcisi, bir sonraki işakışını gerçekleştirecek takımın temsilcisi ve SQA grubu temsilcileri yer alır. Dokümanlar toplantıdan önce dağıtıldığından, herkes ön hazırlık yaparak bir liste oluşturur. Bu listeye, programda anlamadığı kısımları veya yanlış olarak gözüken kısımları yazarlar. - 9 -
ADIM ADIM İNCELEMENİN YÖNETİMİ SQA grubu temsilcisi bu toplantıya başkanlık eder. Adım adım incelemenin (walkthroughs) amacı, hataları tespit etmektir, onları düzeltmek değildir. Bu grup tarafından yapılan düzeltmenin düşük kalitede olması muhtemeldir. Çünkü hata olarak işaretlediğimiz kod aslında doğru çalışıyor olabilir. Bunu hata sayıp düzeltmeye kalktığımızda programın kalitesi düşebilir. Hata düzeltmenin maliyeti oldukça yüksektir. İşaretlenmiş bütün maddeler gerçekte yanlış olmayabilir. Adım adım inceleme (walkthroughs) iki saatten daha uzun sürmez. Zaman kısıtlı olduğu için hatalar düzeltilemez. - 10 -
Adım adım inceleme (walkthroughs), katılımcıya-dayalıdan (participantdriven) ziyade dokümana dayalı (document-driven) olmalıdır. Katılımcıya-dayalı (participant-driven): Her kişi elindeki listeyi alıp okuyor, kafasında soru işareti bırakan yani kendisine yanlış gelen veya anlamadığı kısımları söylüyor. Dokümana dayalı (document-driven): Bir kişi programla ilgili sunumu yapıyor. Diğerleri dinliyor ve düşüncelerini söylüyor. Sorular dinamik olarak sunumu yapan kişi konuşmasını sürdürürken ortaya çıkıyor. Hangisi daha iyi dersek, birisi anlatıp diğerleri onu dinleyip soru sorduğunda yani dokümana dayalı (document-driven) yaklaşım hata bulmada daha yararlıdır. Sözle ifade hata bulunmasını sağlar. Adım adım inceleme (walkthroughs) performans değerlendirmesi için asla kullanılmamalıdır. - 11 -
DENETLEME (INSPECTIONS) 1976 lar da bu yöntem sadece tasarım ve kodlama da kullanılmış, ama diğer safhalar içinde kullanılabilir. Denetleme (inspections) resmidir. Ön hazırlık gerektirir. Beş resmi adım vardır; Gözden geçirme (overview), Hazırlık (preparation); hata türleri istatistiksel olarak belirlenir, Denetleme (inspection); hatalar tespit edilir ama düzeltilmez, Tekrar çalışma (rework); bütün hataları çözmek, İş takibi (follow-up); sona erdirmek. - 12 -
Bu denetlemede genellikle 4 kişi bulunur. Bu toplantıda; Toplantı başkanı (moderator), Mevcut iş akışını gerçekleştiren takımın üyesi, Bir sonraki işakışını gerçekleştirecek takımın üyesi, SQA grubundan bir üye yer alır. Burada toplantı başkanı (moderator), okuyucu (reader) ve yazıcı (recorder) önemli rol oynar. - 13 -
HATA İSTATİSTİKLERİ (FAULT STATISTICS) Bir gözden geçirmede (review), hatalar önem derecesine göre kaydedilir. Örneğin; büyük (major) veya küçük (minor) Hatalar, hata türlerine göre kaydedilir. Tasarım hataları. - Şartname deki her şey tasarımda ele alınmış mı? - Güncel ve resmi parametreler birbiri ile uyumlu mu? - 14 -
Gözden geçirme esnasında, gerçekleştirilen işakışı için, önceki yazılım ürünlerindeki hata oranları ile güncel hata oranları karşılaştırılır. Bir birim (artifact) içindeki hataların sayısı aşırı fazla ise önlem alınır. Baştan yeniden tasarlamak iyi bir alternatiftir. Hata istatistiklerini bir sonraki işakışına taşımalıyız. Güncel denetleme içinde, belirli bir tipin bütün hatalarını tespit edemeyiz. - 15 -
Denetleme Üzerine İstatistikler Aşağıda IBM denetlemelerinin; 1976 da bütün hataların %82 sini tespit ettiği, 1978 de bütün hataların %70 ini tespit ettiği, 1986 da ise bütün hataların %93 ünü tespit ettiği görülmektedir. Switching system 1986 da tespit ettiği hataların maliyette %90 azalma sağladığı görülmektedir. JPL 1980 de her iki saatte bir; 4 büyük hata ve 14 küçük hata tespit etmiştir. Her incelemede 25.000$ tasarruf etmiştir. 1992 de bu safha sayesinde hataların sayısında üssel (exponentially) olarak bir azalma görülmüştür. - 16 -
Uyarı! Hata istatistikleri performans değerlendirmesi için asla kullanılmamalıdır. Altın yumurtlayan kazı öldürme Adım Adım İnceleme ve Denetlemenin Karşılaştırılması: Adım Adım İnceleme (Walkthrough) 2 adım vardır, resmi olmayan bir süreç - Hazırlık (preparation), - Analiz (analysis) Denetleme (Inspection) 5 adım vardır, resmi bir süreç - Gözden geçirme (overview), - Hazırlık (preparation), - Denetleme (inspection), - Tekrar çalışma (rework), - İş takibi (follow-up) - 17 -
Gözden Geçirmenin (Reviews) Güçlü ve Zayıf Yönleri: Gözden geçirmeler (reviews) etkili olabilir. Hatalar bu süreç içinde erkenden tespit edilir. Eğer bu süreç yetersizse, gözden geçirmeler (reviews) daha az etkilidir. Büyük ölçekli yazılım, genelde başlı başına küçük parçaları içermelidir. Bir önceki işakışının dokümantasyonu tam ve çevrimiçi hazır olmalıdır. - 18 -
DENETLEME İÇİN ÖLÇÜTLER Denetleme oranı (inspection rate); her saat denetlenen tasarım sayfaları, Hata sıklığı (fault density); her bin satırda (KLOC) denetlenen hata sayısı, Hata tespit oranı (fault detection rate); her saat tespit edilen hataların sayısı, Hata tespit verimliliği (fault detection efficiency); her saat tespit edilen küçük ve büyük hataların sayısı. Hata bulma oranındaki %50 artış, Kalitenin azaldığını mı ifade eder, yoksa Denetleme sürecinin daha verimli mi olduğunu ifade eder. - 19 -
EXECUTION-BASED TESTING (KODU TEST ETME) Organizasyonlar yazılım bütçesinin %50 sini teste harcıyor, ama teslim edilen yazılım çoğunlukla güvenilmezdir. Dijkstra (1972) Program testi program tarafındaki hataların bulunmasını gösteren çok etkili bir yoldur, ama aynı zamanda hata bulunmadığını göstermede yetersizdir. - 20 -
NE TEST EDİLMELİ? Execution-based testing in tanımı; Seçilen girişler ile bilinen bir ortamda ürünün execution ından veya çalıştırılmasından elde edilen sonuçlara dayanarak, ürünün belirli davranışsal özelliklerini ortaya çıkaran süreç olarak tanımlanabilir. Bu tanımda üç imalı kelime bulunmaktadır. - 21 -
Ortaya çıkarma (inference); programın mantığına ve sonucuna bakarak hatasını tahmin etmek zordur. Bilinen ortam (known environment); donanım/yazılım ve diğer kullanılan prosedürler hakkında emin olmalıyız. Seçilen girişler (selection inputs); girişleri seçmek kolay olmayabilir. Örneğin; uçuş kontrol sistemi. Hata raporuna bakarak bunu anlamak zordur. Çeşitli girişler gerekiyor. Bunları sisteme ne şekilde vereceksin, nasıl sonuçlar elde edeceksin. Bunun için simülasyon şart! Yazılımın test aşamasında aşağıdaki özellikleri test etmeliyiz: Yararlılık (Utility), Güvenilirlik (Reliability), Sağlamlık (Robustness), Performans (Performance), Doğruluk (Correctness). - 22 -
YARARLILIK (UTILITY) Ürünün kapsamı müşterinin ihtiyaçlarını karşılayacak mı? Örneğin; Ürünün kullanımı kolay mı? Kullanıcı için yararlı fonksiyonlar var mı? Ürün müşteri için maliyet etkinliğini (cost effectiveness) karşılıyor mu? GÜVENİLİRLİK (RELIABILITY) Yazılım ürününün ne kadar güvenilir olduğu kontrol edilir. Hangi sıklıkla hata oluyor? Bir hatayı düzeltmek ne kadar zaman alıyor? Bir hata sonucunda ortaya çıkan problemleri düzeltmek ne kadar zaman ve ne kadara mal oluyor? gibi sorulara cevap arıyoruz. - 23 -
SAĞLAMLIK (ROBUSTNESS) Yazılım ürünü değişik şartlar altında hatasız olarak kullanılabiliyorsa o kadar sağlamdır (robust tur) diyebiliriz. Ayrıca şartname dokümanı ile uyumlu sonuç verip vermediğine bakarız. Kasıtlı olarak hatalı bir veri verilince, sistem buna ne şekilde cevap verecek? Sorusuna cevap arıyoruz. PERFORMANS (PERFORMANCE) Yazılım ürününün kapasite ve süre kısıtlarını karşılayıp karşılamadığına bakılıyor. Donanımsal olarak hangi donanımda daha iyi sonuç veriyor? Sorusuna cevap aranıyor. Sistemin çok yavaş olmasından dolayı veri kaybı yaşanırsa, bu verileri geri kurtarmanın yolu yoktur. - 24 -
DOĞRULUK (CORRECTNESS) Yazılım ürünü şartnameyi sağlıyorsa yani her şey şartnameye uygun olarak yapılmışsa, bu yazılım ürünü için doğrudur diyebiliriz. - 25 -