Yazılımın Test Edilebilirliği

Sözleşmelere genelde eklenen ama ne sözleşmeyi yazanların ne de proje takımlarının net olarak bilmediği bir konu olan Yazılımın Test Edilebilirliği ile ilgili bir blog mesajıdır bu.

Aşağıdaki 1. bölüm Wikipedia'dan tercümedir (tercüme sonrasında anlamın korunmasına gayret ettim).
2. bölümde standartlardaki konu ile ilgili açıklamalar verilmiştir.

1) Yazılım test edilebilirliği, bir yazılım ürününün (örneğin bir yazılım sistemi, yazılım modülü, gereksinim veya tasarım dokümanı) test faaliyetini desteklemesidir.
Test edilebilirlik bir yazılım ürünün doğal olarak içinde olan bir özellik değildir ve doğrudan ölçülemez. Aksine, test edilecek ürün ile testin amaçları, kullanılan test yöntemleri ve test kaynakları arasındaki karşılıklı bağımlılıktan doğan dışsal bir özelliktir.
Düşük seviye test edilebilirlik, test eforunun artmasına sebep olur. Bir uç durum olarak, test edilebilirliğin olmayışı yazılımın test edilecek parçalarının gizlenmesine sebep olabilir.

Yazılım bileşenlerinin (modüller, sınıflar) test edilebilirliği aşağıdaki gibi faktörler tarafından belirlenir:
Kontrol Edilebilirlik: Test edilmesi gereken bileşenin bulunduğu durumun kontrolüne ne ölçüde imkan sağlandığı,
Gözlemlenebilirlik: Ara veya nihai test sonuçlarının gözlenmesine ne ölçüde imkan sağlandığı,
İzole Edilebilirlik: Teste tabi bileşenin izole bir ortamda test edilebilme seviyesi,
Sorumluluğun Ayrıştırılması: Teste tabi bileşenin ne seviyede iyi tanımlı, tek bir sorumluluğu olduğu,
Anlaşılabilirlik: Teste tabi bileşenin ne seviyede dokümante edildiği veya kendinden-anlaşılabilir olduğu,
Otomatikleştirilebilmesi: Teste tabi bileşenin testlerinin otomatikleştirilmesine ne oranda imkan sağlandığı,
Ayrışıklık: Paralel olarak farklı test yöntemlerinin ve araçlarının kullanımının gerektiği.

Yazılım bileşenlerinin test edilebilirliği Test-Odaklı Geliştirme ve Test Edilebilirlik için Tasarım yaklaşımları ile artırılabilir.

Gereksinimlerin Test Edilebilirliği: Test edilebilir olması için gereksinimlerin aşağıdaki kriterleri sağlaması gerekmektedir:
Tutarlı,
Tam,
(Tartışmasız bir şekilde) Kesin,
Nicel ("hızlı tepki süreleri" gibi ifadeler olmamalı),
Uygulamada Doğrulanabilir (Test, sınırlı kaynaklar ile sadece teoride değil uygulamada da yapılabilir olmalı).

2) Bu bölümde doğrulama ile ilgili çeşitli standartlardaki Test Edilebilirlik tanımları verilmiştir:
IEEE Std 12207-2008: "Tarafsız ve uygulanabilir bir testin, bir gereksinimin karşılanıp karşılanmadığını belirlemesi ölçütü"


ISTQB (ISO 9126'dan faydalanarak): "Bir yazılımın ürününün, değiştirilmiş yazılımın test edilmesine imkan sağlama kabiliyetidir".

Fonksiyonel Olmayan Gereksinimlere Örnekler

Sistem mühendisliği ve gereksinim mühendisliğinde fonksiyonel olmayan bir gereksinim belirli davranışlardan ziyade sistemin işleyişini yargılamak için kullanılabilecek kriterleri belirten bir gereksinimdir. Bu açıdan, belirli davranış veya fonksiyonları tanımlayan fonksiyonel gereksinimden farklıdırlar. Fonksiyonel gereksinimler sistem analizi / tasarımında detaylandırılırken, fonksiyonel olmayan gereksinimler sistem mimarisinde detaylandırılırlar.

Fonksiyonel gereksinimler bir sistemin ne yapması gerektiğini belirtirken, fonksiyonel olmayan gereksinimler ise sistemin nasıl olması gerektiğini belirtirler. Fonksiyonel olmayan gereksinimlere aynı zamanda sistemin kalite karakteristikleri de denir.

Fonksiyonel olmayan gereksinimleri iki ana kategoriye ayırabiliriz:
- İcra Özellikleri: Güvenlik, Kullanışlılık gibi işleyiş süresi içinde gözlemlenebilenler.
- Gelişim Özellikleri: Test Edilebilirlik, İdame Edilebilirlik, Genişleyebilirlik ve Ölçeklenebilirlik gibi yazılım sisteminin durağan yapısına gömülü olanlar.

Fonksiyonel olmayan gereksinimlerden sıklıkla kullanılanlarından bazılarını aşağıda listeledim. Her biri için yapılan tanımın altında örnekleri de verdim:

Bütünlük
Emniyet
Erişebilirlik
Erişim Güvenliği
Esneklik
Gizlilik
Hayatta Kalabilirlik
İdame Edilebilirlik
Kullanılabilirlik
Kurulabilirlik
Ölçeklenebilirlik
Taşınabilirlik
Tekrar Kullanılabilirlik