STANAG Doğrulama

Askeri (çoğunlukla NATO) projelerde sözleşmelerde tanımlı STANAG'lar kullanılarak ürünlerin geliştirilmesi ve doğrulanması gerekmektedir.

STANAG, Standardization Aggrement'in kısaltmasıdır ve tüm listeye buradan ulaşabilirsiniz; fakat çoğuna doğrudan erişim yoktur.

STANAG kullanılarak ürünleri geliştirmenin ve test etmenin güzel tarafı; istenen her yeteneğin detaylı olarak tanımlanmış olması, muğlaklıkların olmamasıdır. 

Zor tarafı ise, kimi STANAG 300-400 sayfa olabilmekte kimi zaman da diğer standartlara referanslar vererek binlerce sayfaya çıkabilmektedir. (Her zaman olduğu gibi) Bu zorluk aynı zamanda bir de fırsat yaratmaktadır. Sektörde bu kadar kalın dokümanları okumaya ve öğrenmeye hevesli çok kimse olmadığı için herhangi bir STANAG ailesini iyi öğrenmeniz durumunda hem yurtiçi savunma sanayinde hem de NATO ve diğer askeri oluşumlara yönelik yazılım yapan yurtdışı firmalarda kolaylıkla iş bulabilirsiniz. Fakat tekrar söyleyeyim; bu dokümanlara hâkim olmak kolay değildir. Çoğunlukla bu dokümanlara uygun olarak geliştirilen ürünler test edildiği zaman standartın ne anlattığı daha iyi anlaşılır olmaktadır.

STANAG kullanarak doğrulama yaparken dikkat edilmesi gereken konu, hazırlanacak test senaryolarının birebir standarttaki maddelerle eşleştirilmesidir; bir senaryo birden çok maddeyi içerebilir. Ve tabii her zaman olduğu gibi, izlenebilirlik matrisini de doğru ve detaylı hazırlamak önemlidir.

Bu Yöntemle Yazılım Kabul Testlerinde Başarıya Ulaşın

Projelerin kullanıma alınmadan önceki son test aşaması olan Kabul Testleri'nden önce yapılması gereken ama genelde vakit ayrılmayan önemli bir konu olan Oryantasyon'dan bahsedeceğim.

Test dokümanları genelde oldukça kapsamlı ve aşırı dikkat verilmediği sürece kolaylıkla içinde kaybolabileceğiniz belgelerdir.

Yazılım projelerinin kabul testlerinin başarıya ulaşmasında en etkili yöntemlerden biri katılımcılara verilecek olan Test Oryantasyonu'dur.

Oryantasyonun amacı, testin ilerleyişinin nasıl olacağı, hangi testte hangi yeteneklerin nasıl test edildiği, hiçbir gereksinimin gözden kaçırılmadığı, test sırasında verinin hangi kaynaktan nasıl girileceği, test çıktılarının nasıl toplanacağı ve saklanacağı, testte ortaya çıkan hataların ve isteklerin nasıl yönetileceği konularında test katılımcılarına detaylı bilgi vermektedir.

Bu yüzden, her ne kadar testten önce müşteri test belgelerini gözden geçirmiş olsa bile (ki çoğu zaman detaylı bir gözden geçirme de yap(a)maz müşteri), testin katılımcılarına (gerekirse 1-2 gün boyunca) oryantasyonun verilmesi, hem müşterinin test sürecine olan güveninin artırılmasına, hem test faaliyetine daha çok katkı sağlamasına, hem de ürünün nihai ortamdaki kullanımı sırasında ortaya çıkabilecek hataların çok daha erken farkedilmesine imkan sağlayacaktır.

Yazılım Testi ile Sistem Testi Arasında Ne Fark Vardır?

Sistem, yazılım ürünleri ile (kimi zaman) donanım ürünlerinin birleşiminden oluşmuş yapıya verilen isimdir.
Yazılım ise sadece yazılım ürünleri ve destekleyici konfigürasyon ve veri dosyalarından oluşan yapıya verilen isimdir.

Eğer geliştirilen ürün, sadece yazılım parçalarından oluşuyorsa, bu bütüne yazılım sistemi adı da verilebilmektedir.

Test açısından bakıldığında yazılım testi ile ifade edilen;

• yazılım seviyesi gereksinimlerin doğrulandığı,
• normal girdiler haricinde sınır değerlerin, boş değerlerin, hatalı ve eksik değerlerin de testlere dahil edildiği,
• testin akışının (test betiği / test durumu) sadece hedeflenen fonksiyonu test ettiği 

yapı anlaşılır.

Sistem testi dendiğinde ise;

• sistem seviyesi fonksiyonel gereksinimler ile kalite karakteristiklerinin doğrulandığı,
• (çok büyük çoğunlukla) sadece normal girdilerin testlere dahil edildiği,
• çünkü yazılım seviyesi testlerde ekranlardaki / servislerdeki sınır değerler vesaireyi zaten test ettik,
• belirli bir operasyonel konsept senaryosu kullanılarak sistemi baştan sona bir ana akış dahilinde test eden,
• yazılımın, sistemin diğer bileşenleri olan donanım ürünleri etkileşiminin de test edildiği,

bir yapı anlaşılır.

Yazılım testleri de birer senaryo dahilinde işletilir ama bu senaryolar sadece bir veya birkaç fonksiyonu içerir. 

Platform Uygunluk Testi

Platform Uygunluk Testi'nin amacı, geliştirilen ürünün hedef işletim sistemlerinin tamamında sorunsuz olarak çalıştığının doğrulanmasıdır. Web ürünlerinin farklı internet gezginlerinde çalışmasına yönelik testler de bu kapsamda değerlendirilebilir.

Normal şartlar altında, kurulum işlemleri hariç olmak üzere, ürünün arayüzünün ve yeteneklerinin her platformda birebir aynı olması beklenmektedir. Ancak, test adımlarında komut ekranı / terminal ekranında yazılması gereken komutlar varsa, Windows ve Linux temelli işletim sistemleri için bu komutlar farklı olduğundan, bu detay test adımlarında belirtilmelidir.

Bu test türünün zorluğu, aynı testlerin her bir platform için tekrarlanması gerekliliğidir. O sebeple, mümkün mertebe test otomasyonu yapılarak harcanacak eforun asgari seviyeye indirilmesi önemlidir [test otomasyonu için harcanacak efor da ayrıca göz önünde bulundurulmalıdır, çünkü kimi durumda otomasyon kodunun yazılması, bakımının yapılması, farklı platformlarda çalışır olduğunun garanti edilmesi çok zor olabilir].

Bu test türünde karşılaşılabilecek bazı sorunlar şunlardır:

• Kütüphane / eklenti uyumsuzlukları,
• Konfigürasyon dosyalarındaki dizin adreslerinin gösterim farklılıkları sebebiyle dosyalara erişim sorunu,
• Performans farkları,
• Dosya formatlarındaki farklılık sebebiyle gösterim sorunları.

Yazılım Test Yöntemleri

Yazılımları test etmek kullanılan farklı ana yöntemler vardır. Bunlar sırasıyla:

• Kara Kutu Testi
• Beyaz Kutu Testi
• Gri Kutu Testi

Sırasıyla detaylarına bakalım:

Kara Kutu Testi

Yazılım uygulamasının iç detaylarını bilmeden test yapma tekniğine kara kutu testi denir. Test mühendisi, sistem mimarisine hâkim değil ve kaynak kodunu görmüyordur. Test mühendisi kara kutu testini gerçekleştirirken sistemin kullanıcı arayüzlerini kullanarak sistem girdiler sağlar ve çıktılarını gözlemler; girdilerin nerede ve nasıl işlendiğini görmez.

Kara kutu testinin avantaj ve dezavantajları şu şekilde sıralanabilir.

• Avantajları:
1. Kapsamlı yazılımlarda etkin test yapabilme,
2. Koda erişimin gerekmemesi,
3. Geliştirici bakış açısından ziyade kullanıcı bakış açısıyla ürüne bakılabilmesi,
4. Orta seviyede yetkinliği olan pek çok test mühendisi tarafından bir arada testin gerçekleştirilebilmesi
• Dezavantajları:
1. Kısıtlı kapsama oranı; belirli sayıda test senaryosu test edilebilir,
2. Testin etkinliği, testi yapan kişinin yetkinliği ile sınırlıdır,
3. Kod kapsamada düşük etkinlik; çünkü test mühendisi yapılan testin hangi kod parçasını tetiklediğini bilemez.

Beyaz Kutu Testi

Bu test türü, yazılım kodunun yapısının ve iç mantığının detaylı bir incelemesidir. Bu teste aynı zamanda cam testi veya açık kutu testi de denmektedir. Bu testi yapabilmek için test mühendisinin kodun çalışma mantığını (ve dolayısıyla kodlamayı) bilmesi gerekmektedir.
Test mühendisinin koda bakarak / birim testler yazarak hangi kod parçalarının doğru çalışmadığını bulması gerekmektedir.


Beyaz kutu testinin avantaj ve dezavantajları şu şekilde sıralanabilir.

• Avantajları
• Test mühendisi kaynak koduna hâkim olacağı için, etkin bir test yapabilmek için hangi türdeki verilere ihtiyacı olacağını bulabilir,
• Çok daha yüksek bir test kapsama oranına ulaşılabilir.
• Dezavantajları
• Daha donanımlı bir test mühendisinin testleri yazmak zorunda olmasından dolayı maliyetler yükselir,
• Kaynak kod değişikliklerinde test kodlarının da gözden geçirilmesi gerekecektir.

Gri Kutu Testi

Uygulamanın çalışma prensipleri ile ilgili kısıtlı bir bilgiye sahipken yapılan teste verilen isimdir.
Sistemin çalıştığı alanda bilgi sahibi olan bir test  mühendisi, daha etkili testler yapabilecektir. Kara kutu testinden farklı olarak bu test türünde test mühendisi, tasarım belgelerine ve veritabanına erişim sağlayabilmektedir. Bu sayede çok daha uygun veri kümeleri ile daha detaylı test senaryoları hazırlayabilmektedir.

Bu test türünün;
  Avantajları:

• Hem kara kutu hem de beyaz kutu testlerinin güçlü yanlarından faydalanır,
• Kaynak koda ihtiyaç duyulmaz, bunun yerine arayüz tanımları, tasarım kararları ve gereksinimlere göre test yapılır,
• Tasarımcının değil son kullanıcının bakış açısıyla testler yapılır.

  Dezavantajları:

• Kaynak koda erişim olmadığı için testlerin kapsama oranı sınırlı olacaktır,
• Her girdi türünü denemek zaman kaybı olabilir, diğer türlü, diğer iş akışları yeterince test edilmeyebilir.

Bu 3 yöntemi şu şekilde karşılaştırabiliriz:

Kara Kutu Testi	Gri Kutu Testi	Beyaz Kutu Testi
Uygulamanın dahili çalışma mantığının bilinmesine gerek yoktur.	Test mühendisi, uygulamanın dahili çalışma mantığı ile ilgili sınırlı bilgi sahibidir.	Test mühendisi, uygulamanın dahili çalışma mantığı ile ilgili detaylı bilgi sahibidir.
Test mühendisi tarafından yapılır. Son kullanıcı tarafından da yapılabilir.	Son kullanıcı tarafından yapılması zordur.  Test mühendisi ve yazılım geliştirici tarafından yapılabilir.	Yazılım test mühendisleri ve yazılım geliştiriciler tarafından yapılır.
Daha kısa zamanda ama daha düşük kapsama oranı ile testler yapılabilir.	Diğer iki yöntemin arasındadır; kısmi olarak zaman ve efor harcanır.	En çok zaman ve efor harcanan testlerdir.
Algoritma testi için uygun değildir.	Algoritma testi için uygun değildir.	Algoritma testi için uygundur.
Sadece deneme-yanılma yöntemi ile yapılabilir.	Veri türleri ve dahili sınırlar test edilebilir.	Veri türleri ve dahili sınırlar daha kapsamlı olarak test edilebilir.

"Bu 3 test türünden hangisi ile test yaparsam uygulamamızı en kapsamlı şekilde test etmiş oluruz" şeklinde bir soru sorulacak olursa, doğal olarak cevap, "her 3 test türünü de kullanarak yapılan test" olacaktır.

Kabul Testi Nedir, Nelere Dikkat Etmek Gerekir

Gerek kamu gerekse özel sektöre yapılıyor olsun, yazılım projeleri bir nihai kabul makamı için geliştirilir. Yani bu projenin bütçesini oluşturan ve ödeme yapacak bir makam için geliştirilir.

Bu makamın görevlendirdiği ekip tarafından bir sözleşme hazırlanır, ihale süreci başlatılır ve bu sözleşmeyi karşılayacak sistem / yazılımı geliştirmeye tâlip şirketler ile görüşüldükten sonra sözleşme nihai haline gelir.

İhale sürecinin sonunda ihaleyi kazanan şirket, sözleşme isteklerine göre ürünü geliştirdikten ve dahili testlerini yaptıktan sonra, müşteri, müşteri temsilcisi ve/veya danışmanlık / müşavir firma katılımı ile, geliştirilen ürünün sözleşme isterleri ile uyumluğunun doğrulandığı kabul testi yapılır.

Kabul testi için, doğrudan sözleşme isterlerini doğrulayan bir Kabul Test Dokümanı kullanılabileceği gibi, müşteri onayı alınması durumunda, Sistem Test Dokümanı da kullanılabilir.

Bu aşamada dikkat edilmesi gerekenler:

• Kabul testinde kullanılacak test dokümanının, sözleşme isterlerinin tamamını test ettiğinden emin olunmalıdır,
• Test öncesinde, hatta Test Hazırlık Gözden Geçirme toplantısı öncesinde, müşteri temsilcileri ile ayrı bir toplantı yapıp, test dokümanının detayları, sözleşme maddelerinin hangi testlerle nasıl karşılandığı sunulmalıdır. Böylece, müşteri temsilcileri test dokümanına hâkim olacak, olası eksikler erken aşamada ortaya çıkmış olacak, müşterinin istediği ek testler varsa test dokümanına eklenebilecek ve müşteri temsilcileri sözleşmenin her maddesinin testten geçtiğini göreceği için içleri rahat olacaktır.
• Bu aşamada, testler öncesinde senaryo akışı anlatılmalı ve üzerinden mutabık kalınmalıdır.
• Kabul testine gelen kabul heyetinin (müşteri temsilcileri) asıl işlerinin yazılım geliştirme olmadığını düşünürsek, yazılacak test adımlarının yeterince açıklayıcı olması, test ettiği isterin ne olduğu açık olarak belirtilmelidir.

Bir Regresyon Testi Yaklaşımı Önerisi

Regresyon testi, tanımı gereği, test edilmiş ve doğrulanmış bir ürüne yeni bir özelliğin eklenmesi ve/veya var olan özelliklerdeki bir hatanın düzeltilmesi sonrasında, testten geçmiş ürünün bu değişikliklerden olumsuz etkilenmediğini doğrulamak amacıyla yapılır.

Adı geçen bu değişiklikler kullanıcı arayüzü üzerindeki kozmetik değişiklikler olabileceği gibi, bir modülün çalışma şekline müdahale eden bir değişiklik de olabilir. Dolayısıyla yapılan bu değişikliğin halihazırdaki ürünü bozmadığından emin olmak gerekir.

Bir projenin yaşamı süresince ortaya çıkabilecek bazı regresyon testi ihtiyaçlarını ve neler yapılması gerektiğini aşağıdaki şemada örneklendirdim:

Peki nasıl bir test yaklaşımı ile regresyon testlerini planlamak gerekir?

Geliştirilen ürünün yapısına bağlı olarak farklı yaklaşımlar ortaya çıkacaktır. Ancak genel bir yaklaşım olarak şöyle bir yöntem izlenebilir (burada verilen yaklaşımlar örnektir, kendi proje ihtiyaçlarınıza göre çeşitlendirebilirsiniz):

Kozmetik Değişiklik
	Ne Yapıldı?
		Yazım Hatası Düzeltildi
		Resim, İkon, Konum Değiştirildi
		Font Değiştirildi
	Nasıl Doğrulanacak?
		Ürünü farklı platformlarda çalıştır (İşletim sistemi, internet gezgini, mobil cihaz)
		Yapılan değişikliğin istendiği gibi göründüğünü doğrula
		Yapılan değişikliğin aynı kullanıcı arayüzündeki diğer nesneleri bozmadığını doğrula
Yetenek Üzerinde Değişiklik
	Ne Yapıldı?
		Kullanıcı Arayüzünde Bir Nesne Silindi / Eklendi
		Modüller Arası Arayüze Yeni Yetenek Eklendi / Varolan Silindi
		Bir sınıfın çalışma mantığı değiştirildi
		Veritabanı sorguları değiştirildi
		Rapor şablonu değiştirildi
		Kullanılan donanımlar değiştirildi
		...
	Nasıl Doğrulanacak?
		Kullanıcı arayüzünü test et, istenen sonuçta olduğunu doğrula
		Kullanıcı arayüzünü çağıran diğer arayüzleri test et, istenen sonuçta olduğunu doğrula
		Arayüzü kullanan modülleri test ederek, iletişimde bulunan modüllerin istenen girdi ve çıktıları sağladığını doğrula
		Değişiklik yapılan sınıfı birim test ile doğrula, bu sınıfı kullanan diğer sınıfları birim entegrasyon testi ile doğrula
		Veritabanına atılan sorguyu gözden geçir
		Ekran arayüzü üzerinden test yaparak veritabanına atılan sorguda doğru parametrelerin kullanıldığını doğrula
		Farklı sayıda girdiler kullanarak farklı sayıda sayfa içeren raporlar üret, içeriğin istenen sonuçları içerdiğini doğrula
		Donanıma özel olarak geliştirilmiş yeteneklerin olması durumunda, ilgili yeteneğin testlerini baştan sona tekrarla
Yaklaşım
		Test mühendisi, deneyimine dayanarak hangi yeteneklerin etkilenmiş olabileceğinin listesini hazırlar, liste üzerinden tüm ilgili yetenekleri test eder,
		Proje ekibi (en az 1 yazılılm mühendisi ve 1 test mühendisi), tasarım ve kod üzerinden etkilenmiş olabilecek yeteneklerin listesini çıkarır, birim seviyesi ve üst seviye testler tekrar edilir,
		Test otomasyonu varsa, değişiklikten etkilenen testler güncellenir ve (tercihen, zaman varsa tüm) testler tekrarlanır

Yazılım Testi - Entegrasyon Testi

Bana e-posta ile danışan arkadaşlara yazdığım cevapları blogumda (bazı yerlerini kırparak) paylaşıyorum.

Diğer test uzmanı ve adaylarına faydası olur umarım.

Soru: "ben sizin hazirladiginiz slayti internetteki arastimalarim sirasinda buldum. bir sistem gelistiren X kisilik bir grubumuz var. test kismi ile ben ilgileniyorum. entegrasyon testlerinin tam olarak nasil ve hangi toolla yapildigini aciklayan birseyler bulamadim. bu konuda bana yardimci olursaniz cok sevinirim."


Cevap: "Entegrasyon testleri size ne çağrıştırıyor? Araç kısmını boşverin şimdilik. Yöntem olarak neyi çağrıştırıyor? Bir de hangi seviyede test yapıyorsunuz? Birim mi yazılım mı? (Unit / CSCI / System / ...)"


Soru: "hazirladigimiz projenin gerekliligi olarak once unit test ardindan component test sonra integration test ve son olarak sistem testyapacagim. internetten ogrendigim kadariyla integration testleri birbirinden bagimsiz calisan komponentlerin birlikte dogru calisip calismadigini kontrol ediyor. ama acikcasi su anda herhangi birseyi cagristirmiyor :) daha evvel yalnizca unit test yaptim. "


Cevap: "V-cycle'ı biliyorsunuzdur. Her geliştirme seviyesine bir test karşılık geliyor. 
Birim testini sonuçta Software Design'a göre yapıyorsunuz.
Birim entegrasyon testini Interface Design maddelerine göre yapıyorsunuz.
Bileşen testini Software Requirements'a göre,
Sistem entegrasyon testini Interface Requirements'a göre (SRS veya SSS içindeki arayüz gereksinimleri) yapıyorsunuz.

Burada amaç nedir?
Kendi başına (gerektiğinde mock-up'la , simülatörle, ... desteklenerek) çalıştığını gördüğümüz bileşenleri, System Integration Verification Plan'da hangi sırada entegre edileceğini belirledikten sonra, entegrasyon sırasına göre bu bileşenleri "gereksinimlerine göre" test etmek.

Örnek: 4 tane bileşen olsun (1-2-3-4). Bunları bottom-up, top-down, big-bang gibi yöntemlerle entegre edebiliriz (ki genelde maliyeti düşürmek için big-bang yaparlar). Önce 1 ile 2, sonra 3 ile 4, sonra 12 - 34'ü entegre edebiliriz.
Ya da, Önce 2-3, sonra 1-23, sonra da 123-4'ü entegre edebiliriz...
Sıra ne olursa olsun, sonuçta bu entegre edilen bileşenler birbirlerinden bir bilgi alacak veya dışarıya bir bilgi vereceklerdir.
Entegrasyon testinde yapılan da bu giden-gelen bilginin doğru aktarılıp aktarılmadığını görmek, ki sistem seviyesi testte hem bu detayda teste zaman olmaz (gerek de olmaz). Bir diğer yararı da entegrasyon sebebiyle ortaya çıkacak hatalar daha erkenden tespit edilebilir..."