Yazılım Testi Genel Konular

Bug Nedir ?

Bug kelime anlamı olarak “böcek” olsa da bizler için “sistem açığı” anlamına gelir. 1947 yılında Harvard Üniversitesi’nde test aşamasında olan Mark II isimli oda dolusu devasa bilgisayar çalışmasına rağmen istenilen sonucu veremiyordu. Dr. Grace Hopper bir terslik olduğunu anlar ve devreleri kontrol ederken devrelerin arasında ölmüş ve Mark II’nin çalışmasını engelleyen bir böcek bulur.

Bug kelimesi ilk kez Grace Hopper tarafından bu şekilde kullanılır. Binlerce satır koddan oluşan projelerde, oyunlarda ve işletim sistemlerinde hatalar olması çok doğaldır.

Yazılım Testi Nedir ?

Yazılım testi, bir yazılım içerisinde hata bulma amaçlı gerçekleştirilen eylemler dizisi olarak adlandırılabilir. Bu amaç rastgele şekilde değil sistematik bir şekilde gerçekleştirilir. Bu sistematik yaklaşım statik olabileceği gibi dinamikte olabilmektedir.

Biraz daha teknik konuşacak olursak. Yazılım testi, bir programın davranışını dinamik yöntemlerle, sonsuz bir küme içinden belirli sayıda seçilen test durumlarını kullanarak, beklenen davranışa uymadığı durumları bulma işlemidir.

Yazılım Testine neden ihtiyaç duyarız ?

Yazılım testi, önceden belirtilen gereksinimleri karşılayıp karşılamadığını, doğru çıktıyı üretip üretmediğini kontrol eden yapıdır. Çok sayıda test durumu ve test stratejisi hazırlanır. Bu testler tüm sorunları ortadan kaldırmak, yazılımın hatasız çalışmasını sağlamak ve en iyi çıktıyı elde etmek için yazılım testlerine ihtiyaç duyarız.

Yazılımda Karşılaşılan Problemlerin Kaynakları :

  1. Yetersiz yazılım testi
  2. Düzeltmeler
  3. Karmaşık sistemler
  4. Hatalı gereksinim belirleme
  5. Eksik tasarım

Hatalı Yazılımların Sonuçları :

  1. İletişim kaybı
  2. Müşterinin yazılıma olan ilgisinin azalması
  3. 2 Taraflı güven kaybı
  4. Maliyet artışı
  5. Zaman aşımı
  6. İlave hatalar

Test Yapan Kişinin Amacı :

  1. Hataları bulmak
  2. Yazılımın gelişimine mümkün olan en büyük katkıyı sağlamak
  3. Hatanın giderildiğinden emin olmak
Yazılımların sahip oldukları özelliklerin artması ve gereksinimlerin farklılaşması hatasız yazılımların üretilmesini neredeyse imkansız hale getirmiştir.

Safhalara Göre Oluşan Hataların Maliyetleri

  1. Gereksinim 1$
  2. Tasarım 10$
  3. Kodlama 100$
  4. Kullanım 100$

Safhalara Göre Yazılımda Hata

  1. Tanımlama %55
  2. Tasarım %25
  3. Kodlama %15
  4. Diğer %5

Yazılım Test Metodolojileri

Alfa Testi

Potansiyel kullanıcı/müşteri veya bağımsız test ekibi tarafından yazılım geliştiricinin kendi ortamında fakat yazılım geliştirme ekibinin kontrolü dışında yapılan operasyonel test.

Alfa Testi genelde kendi iç testleri şeklinde paket yazılımlar için yapılmaktadır.

Beta Testi

Potansiyel ve/veya varolan, harici konumda bulup, geliştiricelere dahil olmayan kullanıcı/müşteri ihtiyaçları ve iş süreçlerine uygunluğuna karar vermesi için yürütülen işlemsel test.

Beta testi genel olarak harici kabul testi olarak paket yazılım ürününün üzerinde pazardan geri bildirim almak amacı ile gerçekleştirilir.

Regresyon Testi

Yazılımda yapılan değişiklik veya düzeltme sonrasında bu değişiklik veya düzeltmenin yazılımın başka yerlerinde sebep olabileceği hataları bulmaya yönelik olarak yazılımın değiştirilemeyen veya düzeltilmeyen taraflarının tekrar test edilmesi.

Yazılım veya yazılımın ortamı değiştiğinde uygulanan testlerdir

Unit Test (Birim Testi)

Birim testi adından anlaşıldığı üzere yazılım birimlerinin test edilmesidir. Burada yazılım birimi dediğimiz şey ise test edilebilen en küçük yazılım bileşenidir. Nesneye yönelik programlama yaklaşımını ele alacak olursak, yazılım birimleri sınıflardır diyebiliriz. Yapılan şey basit olarak sınıf davranışlarının (metodlar) belirli girdiler sağlandığı zaman doğru bir şekilde çalışıp, istediğimiz sonucu üretip üretmediğini kontrol etmektir. Bu şekilde yazılımın küçük birimleri test edildiği zaman, bütünü oluşturan parçaların en azından kendi içlerinde çalıştığından emin olmuş oluruz.

Kabul Testi

Ürünün müşteri tarafından test edildiği metodolojidir. Top artık müşteridedir. Müşteri isterse bizim hazırladığımız test senaryolarıyla isterse kendi hazırladığı test senaryoları ile devam eder. Hatta bazen -eğer müşteri şartname dökümanına madde eklemişse- test vakaları dökümanlarını da isteyebilir.

Müşteri hangi yolu tercih ederse etsin gereksinimlerin gerçekleşip gerçekleşmediğini görebilecektir.

White Box Testi

Bir sistemin veya bir bileşenin iç yapısının analizine bağlı olarak test etme yöntemi, bu test tekniğinin en genel tarifi kodun kendisinin test edilmesidir. Tester uygulamaya ait girdi-çıktı, kod tasarımını ve kodun doğru çalışıp çalışmadığını kontrol eder.

Bu test tekniğini yapmak için kodlama bilgisinin iyi seviyede olması gerekir. Bunun sebebi testin arayüz seviyesinde değil de doğrudan doğruya kod seviyesinde yapılmasıdır.

Black Box Testi

Black Box Testinde kod ve tasarım ile ilgilenilmez. Testler gereksinim ve fonksiyonellik üzerine yapılır. Black Box test stratejisinde, kullanıcı sistemin gereksinimlerini ve bu gereksinimlere nasıl cevap vereceğini bilmelidir.

Black Box testlerini kullanıcı gereksinimine ihtiyaç duymayan testler ve kullanıcının gerekli olduğu testler olarak ikiye ayırabiliriz.

ISTQB Nedir ?

ISTQB® 100’den fazla ülkede kar amacı gütmeyen, gönüllü dernekler şeklinde yazılım test ve kalitesi konusunda faaliyetlerini sürdüren en büyük uluslararası organizasyondur.

Misyonu :

  1. Uluslararası standartlarda test eğitimi içeriklerinin (syllabus) oluşturulması
  2. Eğitimleri verecek kuruluşlara ilişkin akreditasyon koşullarının belirlenmesi

ISTQB Sertifikasyon

  1. ISTQB Certified Tester Foundation Level
  2. ISTQB Certified Tester Foundation — Agile Tester Extension
  3. ISQTB Advanced Level Certification

Yazılım Test Aracı : Source Monitor

Source Monitor bize yazdığımız kod ile ilgili bilgiler verir. Kod satır sayısı, metot bazlı karmaşıklık oranı, sınıf sayısı vb. Metrikler bulunur. Bunları basit bir şekilde bize gösteren bir arayüze sahiptir.

Source Monitor sayesinde, kodu iyileştirirken nelere dikkat etmemiz gerektiğini, öncelik verirken nelere dikkat etmemiz gerektiğini bu program sayesinde anlayabiliriz.

Burada görmüş olduğunuz küçük çaplı yazılımda satır ve sütun sayılarını elimizle girerek bir labirent yaratıyoruz. Ve o labirentin isteğimiz yerine faremizi koyup bir başka yere de peynirimizi koyuyoruz

Farenin amacı bütün labirenti dolaşarak en kısa yoldan peynire ulaşmak. Şimdi bu yazılımın kodlarını inceleyeceğiz.

Source Monitor içine proje dosyalarımızı attığımız zaman projenin içindeki satır sayısı, açıklama satırı sayısı, sınıflar, metotlar, ortalama karışıklık ve ortalama derinlik gibi bilgileri sayısal olarak görebiliyoruz.

Form1.cs dosyasına çift tıklayınca :

Böyle bir pencereyle karşılaşıyoruz, burada önemli olan verilerimizin kiviat grafiğinde yeşil bölgenin içinde kalmasıdır. Mesela burada Complexity verileri dışarı çıkmış yani kodumuzun karmaşıklığı ile ilgili bir sorunumuz var.

Form1 Designer.cs dosyasına çift tıklyınca :

Karşımıza çıkan pencerede kiviat grafiğinde bütün verilerimiz yeşil bölgenin içinde, çok da büyük bir problemimiz yok gibi gözüküyor :)

Tarihteki en önemli yazılım hataları

Mariner 1 22.06.1962

Fırlatma sırasında roketin yörüngeden ayrılmasına yol açtı. Kontrol yönetimi tarafından Mariner 1 Atlantik Okyanusu’nda yok edildi.

Kazayla ilgili inceleme yapıldığında, bir kağıda kurşun kalemle yazılmış formülün bilgisayara yanlış geçirilmiş olduğu ortaya çıktı.

“Formül : DO I=1.10 yerine I=1,10”

Natıonal Cancer Institute, Panama

Bir ABD firması olan Multidata Systems International tarafından yazılmış olan terapi planlama yazılımı, radyasyon terapisine girecek hastaya yollanacak uygun radyasyon dozunu yanlış hesapladı. 8 ölü ve 20’den fazla yaralıyla sonuçlanan süreçte doktorlar cinayetle suçlandı.

Intel Pentium işlemcide sorun 1992

Bir silikon hatası sonucu meydana gelen bu hata aslında matematiksel işlemlerde %0.006 hata yapıyordu fakat halkla ilişkiler kabusuna neden oldu.

Piyasaya sürülmüş 3–5 milyon arası yonga vardı. Başlangıçta Intel daha hassas hesaplamalara ihtiyacı olduğunu kanıtlayanlar için yonga değişikliği yapmayı önerdi ama sonunda teslim oldu. Şikayet eden herkesin yongası değiştirmeyi kabul etti. Sonunda bu görünmez hata Intel’e $475m maloldu.

Arıane 5 flıght 501

Ariane 4’ten daha hızlı motora sahip Ariane 5’de Ariane 4’e ait kalkış kodu kullanılınca roket fırlatıldıktan sonra tüm bilgisayarlar çöktü, roketin ana işlemcisi motorlara aşırı güç yüklenmesine yol açtı ve roket, fırlatıldıktan 37 saniye sonra parçalarına ayrıldı.

Roketin patlama anını buradan izleyebilirsiniz.