Kara Kutu Test Teknikleri Nelerdir?

Bildiğiniz veya şuan öğrendiğiniz üzere müfredat yenilendi ve ben bu konuyu ele alalı iki buçuk yıl geçti yani çok şey değişti.  Bu teknikleri modern yazılım dünyasında nasıl uygulamalıyız? Artık sadece manuel testlerle değil, otomasyon, yapay zeka destekli analizler ve risk odaklı planlamalar da hayatımızda var olurken kara kutu test tekniklerini ne şekilde testlerimize uygulamalıyız?

Kara kutu test teknikleri, yazılım testi dünyasında temeli oluşturan en önemli konulardan biridir. Konuyu hem yeni başlayanlar için hem de zaten bilgi sahibi olan kişilere yani sizlere "açık ve sade" bir dille aktarmaya çalışacağım hem de günümüz teknolojileriyle nasıl birleştirildiğini örneklerle göstereceğim.

Kara Kutu Testi Nedir?

Kara kutu testi, yazılımın iç yapısına bakmadan, sadece girdi (input) ve çıktı (output) bazlı yapılan bir test türüdür. Yani sistemi nasıl kodladığınızı bilmemize gerek yoktur. Sadece ne girdi veriyorum, karşılığında ne bekliyorum, bunu test ederiz.

Kara kutu test tekniklerini tek tek inceleyelim:

1. Eşdeğerlik Sınıflandırması (Equivalence Partitioning)

2. Sınır Değer Analizi (Boundary Value Analysis)

3. Karar Tablosu Testi (Decision Table Testing)

4. Durum Geçişi Testi (State Transition Testing)

5. Kullanım Senaryosu Testi (Use Case Testing)

1-Eşdeğerlik Sınıflandırması (Equivalence Partitioning)

Bu teknikte, benzer çıktı verecek girdi grupları belirlenir. Her grup için bir test yeterlidir.

Bir yaş kontrol sistemi test ettiğinizi düşünelim ve bu sistem 18-65 yaş arasını kabul ediyor.

Denklik Sınıfı	Değer	Beklenen Sonuç
Geçerli Yaş Aralığı	30	Kabul edilsin
Geçersiz - Çok Genç	15	Reddedilsin
Geçersiz - Çok Yaşlı	80	Reddedilsin

Her sınıf için bir test senaryosu yazmak yeterli olacaktır.

Test Senaryoları:

1. Kullanıcı yaşı 30 girer → Sistem kabul eder.

2. Kullanıcı yaşı 15 girer → Sistem reddeder.

3. Kullanıcı yaşı 80 girer → Sistem reddeder.

   
   

Bu teknik hala çok etkili, ancak günümüzde "data-driven testing" ile daha da anlam kazanıyor. Test senaryolarını dinamik veri setleriyle çalıştırmak, API testlerinde ve form doğrulamalarında bizlere hızlı ve etkili çözümler sunuyor. Ne demek istediğimi açıklayayım.

Özellikle API testlerinde, input değerlerini farklı kategorilere ayırarak bu teknikleri uygularız. Postman'de bir test koleksiyonu oluştururuz ve bu koleksiyonda geçerli/ geçersiz/ sınır değerler içeren test case'ler tanımlarız. Daha sonra Newman ile bu testleri otomatik çalıştırırız.

Örneğin bir “yaş” parametresi alan API var. Kabul aralığı: 18-65 olsun. Gözünüzde canlanması adına json formatında göstereyim:

{
  "age": 18
}

17, 18, 65, 66 gibi değerlerle test yaparız. Postman test scriptleri ile beklenen HTTP yanıt kodunu kontrol ederiz (200 OK, 400 Bad Request gibi). Bu sayede veri kümelerine göre etkili test kapsamı sağlarız. Ayrıca hataları sınır değerlerde kolayca yakalarız.

2-Sınır Değer Analizi (Boundary Value Analysis)

Hataların genelde sınır noktalarında olması yüksek ihtimaldir. Bu nedenle minimum, maksimum ve kenar değerler test edilir.

Aynı şekilde bir yaş kontrol sistemi test ettiğinizi düşünelim ve bu sistem de 18-65 yaş arasını kabul ediyor olsun. Zaten eşdeğer ve sınır değer analizi sıklıkla birbiri ardına kullanılan yöntemlerdir.

Değer	Beklenen Sonuç
17	Reddedilsin
18	Kabul edilsin
65	Kabul edilsin
66	Reddedilsin

Test Senaryoları:

1. Kullanıcı 17 yaş girer → Sistem reddeder.

2. Kullanıcı 18 yaş girer → Sistem kabul eder.

3. Kullanıcı 65 yaş girer → Sistem kabul eder.

4. Kullanıcı 66 yaş girer → Sistem reddeder.

Yukarıda bahsettiğim gibi Selenium veya Postman-Newman ile sınır değer testlerini otomatikleştirerek sürekli entegrasyon (CI) süreçlerine dahil etmek mümkün ve bizlere dinamik veri setleriyle hızlı çalışma imkânı sağlarlar.

3-Karar Tablosu Testi (Decision Table Testing)

Bu teknik, farklı girdi kombinasyonlarının farklı sonuçlara yol açtığı durumlarda kullanılır. Çoklu iş kurallarını test etmek için birebirdir.

Üyelik ve ödeme bilgisi içeren bir sistemi test ettiğimizi düşünelim. Bir kullanıcı, üyelik ve ödeme bilgisi verdiyse sisteme giriş yapabilsin.

Üyelik Var	Ödeme Yapıldı	Girişe İzin Ver
Evet	Evet	Evet
Evet	Hayır	Hayır
Hayır	Evet	Hayır
Hayır	Hayır	Hayır

Test Senaryoları:

1. Kullanıcının üyeliği ve ödemesi var → Girişe izin verilsin.

2. Kullanıcının üyeliği var ama ödeme yapmamış → Girişe izin verilmesin.

3. Kullanıcının üyeliği yok ama ödeme yapmış → Girişe izin verilmesin.

4. Ne üyelik ne ödeme var → Girişe izin verilmesin.

   
   

Modern uygulamalarda karmaşık iş kuralları daha çok microservice mimarilerinde kullanılıyor. Karar tabloları, bu yapıların test edilmesinde çok kıymetli bir yere sahip. BDD (Behavior Driven Development) çerçeveleriyle örneğin Cucumber ile kolayca uyum sağlayabiliyor.

Cucumber, Given-When-Then formatıyla senaryolar tanımlamanıza imkan veren bir test aracıdır. Karar tablosu mantığıyla birebir uyum sağlaması da bize avantaj sağlar.

Gene gözünüzde canlanması adına bir örnek yapalım. Aşağıda Cucumber da Gherkin (plain-text language) yani düz metin şeklinde, herhangi bir biçimlendirme içermeyen dijital metin şeklinde yazılmış bir senaryo görüyorsunuz.

Scenario: Kullanıcı girişi
  Given kullanıcı üyelik sahibi
  And kullanıcı ödeme yaptı
  When giriş yapmak ister
  Then girişe izin verilir

Given kullanıcı üyelik sahibi:

Bu adımda, sistemde hali hazırda bir kaydı olan yani üye olmuş bir kullanıcıdan bahsediyoruz. Bu bilgi, sistem tarafından "kullanıcı tablosunda" bir kayıt olması anlamına gelir. Üyelik bilgisi olmayan bir kullanıcı için bu adım doğru olmaz.

And kullanıcı ödeme yaptı:

Bu adımda, kullanıcının hizmetten yararlanmak için gerekli ödemeyi yaptığı varsayılır. Sistem tarafından bu bilgi, fatura veya ödeme tablosunda "tamamlanmış" bir işlem kaydı olarak kontrol edilebilir.

When giriş yapmak ister:

Bu adım, kullanıcının sisteme giriş butonuna tıkladığı anda başlar. Burada kullanıcı adı şifre gibi bilgiler girilmiştir ve sistem, bu bilgileri kontrol etmeye hazırdır.

Then girişe izin verilir:

Bu adım, önceki koşullar sağlanıyorsa, sistemin kullanıcıyı içeri alacağı yani girişe izin vereceği anlamına gelir. Bu, kullanıcıyı ana sayfaya yönlendirme ya da dashboard ekranını gösterme şeklinde olur.

Tüm kombinasyonlar için ayrı senaryolar yazılır. Java, JavaScript, Python gibi dillerle bu adımlar kodlanır. Şartlara dayalı test senaryolarını çok net bir dille yazabilirsiniz. Şart kombinasyonlarını unutma riskinizi azaltabilirsiniz.

4-Durum Geçişi Testi (State Transition Testing)

Sistem bir durumdan diğerine geçiyorsa, bu teknik ile senaryo oluşturmak daha kullanışlıdır. Örneğin bankamatik kartlarının kullanımı: Şifre doğruysa "erişim" durumuna, yanlışsa "kilit" durumuna geçer.

Mevcut Durum	Girdi	Yeni Durum
Giriş Ekranı	Şifre Doğru	Ana Sayfa
Giriş Ekranı	Şifre Yanlış	Uyarı Ver
3 Hata	Şifre Yanlış	Hesap Kilitli

Test Senaryoları:

1. Kullanıcı doğru şifre girer → Ana sayfa açılır.

2. Kullanıcı şifreyi yanlış girer → Sistem uyarı verir.

3. Kullanıcı şifreyi 3 kere yanlış girer → Sistem hesabı kilitler.

   
   

Mobil ve IoT uygulamalarının karmaşık durum yapılarını test etmek için en uygun tekniklerden biridir. Model-Based Testing yaklaşımları ile bu testleri otomatikleştirme mümkün hale geldi. Durum diyagramlarından test senaryosu üreten araçlar artık piyasada mevcut.

Örneğin GraphWalker. Uygulamanın tüm durumları bir diyagram olarak tanımlanır. Bu durumlar ve geçişler (geçerli, geçersiz) GraphWalker gibi model-tabanlı test aracında betimlenebilir. Araç bu diyagrama göre test yollarını otomatik oluşturur ve çalıştırır. Çok yararlıdır ve diyagramın dinamik olarak görselleşmesi hata yapma olasılığınızı önemli ölçüde azaltır. Tüm durum değişimlerini test etme garantisi verir. Kullanıcı akışlarını şematik olarak test edebilirsiniz.

5-Kullanım Senaryosu Testi (Use Case Testing)

Sistemi kullanıcı gözüyle test ederiz. Genelde kabul testlerinde ve son kullanıcı deneyimi için uygulanır.

Bir sipariş sistemini test ettiğimizi düşünelim.

"Sipariş verme" senaryosu:

1. Kullanıcı ürünü seçer

2. Sepete ekler

3. Ödeme yapar

4. Sipariş onay ekranı gelir

   
   

Test Senaryosu:

1. Kullanıcı bir ürün seçer → Sistem sepete ekleme seçeneğini gösterir.

2. Kullanıcı sepete ekler → Sepette doğru ürün görünür.

3. Kullanıcı ödeme yapar → Sistem ödeme bilgisini kabul eder.

4. Sipariş onay ekranı görünür → Sipariş ID ve detaylar doğru gösterilir.

   
   

UX odaklı uygulamaları test ederken, kullanım senaryoları (Use Case) yalnızca işlevsellik değil, akış doğruluğu ve tutarlılık için de kullanılıyor. Test senaryolarını Jira veya TestRail gibi uygulamalarla izlenebilir hale getirmek kritik önem taşıyor. Burada önemli olan her bir aksiyona denk gelen bir beklenen durum olmasıdır. Tabi ki Excel gibi bir araç kullanılabilir ancak iyi yönetilemez ise bunun proje ve şirkete vereceği zarar başka bir yazının konusu.

Günümüzde bir sistemin fonksiyonları user story'lere bölünür. Bu user story'lere ait kabul kriterleri test senaryolarına dönüştürülür ve Jira Xray ya da TestRail gibi platformlarda tanımlanır. Bunun en büyük nedeni ve artısı Action(Aksiyon), Data(Test verisi) ve Expected(Beklenti) alanlarının standart olmasıdır.

Örneğin "Kullanıcı sepetine ürün ekleyebilmeli" kabul kriteri:

• Senaryo 1: Ürün seçildiğinde sepete eklenmeli.

• Senaryo 2: Sepet sayfasında eklenen ürün görünmeli.

Kabul testi senaryolarını organize eder ve izlenebilir hale getirir. Gereksinim karşılamalarının durumu kolayca takip edilebilir.

Test teknikleri bizlerin temel araçlarıdır, ancak uygulama yöntemleri zamanla gelişmek zorunda kalıyor. Kara kutu test teknikleri; yapay zeka destekli test araçları, otomasyon çerçeveleri ve çevik yaklaşımlar ile birleştirildiğinde daha da etkili hale gelebiliyor. ISTQB CTFL 4.0 bu temel yaklaşımı bize sunan bir temele sahip, bizlerin görevleri ise bunu güncel iş ortamımıza uyarlamaktır.

Testlerinizde başarılı sonuçlar almanız dileğiyle.