Karar Tablosu Testi ile Karmaşık İş Kurallarını Yönetmek

Yazılım projelerinde bazen öyle iş kurallarıyla karşılaşırız ki bir özelliğin çalışması aynı anda 3-4 farklı koşulun kombinasyonuna bağlanmıştır. "Kullanıcı premium mu? Sepet tutarı 500 TL üstü mü? Kupon kodu geçerli mi? İlk siparişi mi?" gibi uzayıp giden if-else girdaplarında körlemesine test senaryosu yazmaya çalışmak, mutlaka bazı kritik senaryoları gözden kaçırmamıza neden olur.

Uluslararası yazılım testi standartlarında (ISTQB), bu tarz karmaşık iş kurallarını gözden kaçırmadan, matematiksel bir kesinlikle test etmek için Karar Tablosu Testi (Decision Table Testing) tekniğini kullanırız.

Gelin bu tekniğin mantığını, kombinasyon matematiğini ve backend tarafındaki yansımasını bir örnek üzerinde inceleyelim.

Karar Tablosu Mantığı ve Kombinasyon Matematiği

Karar tablosu oluştururken sistemin girdilerini Koşullar (Conditions), bu girdilerin kombinasyonları sonucunda sistemin üreteceği çıktıları ise Sonuçlar (Actions) olarak belirleriz.

Eğer sistemde birbiriyle ilişkili n adet iki durumlu (Doğru/Yanlış) koşul varsa, yazmamız gereken maksimum kural (senaryo) sayısı 2 üzeri n formülüyle hesaplanır.

Gelin, kurumsal bir e-ticaret ödeme sistemindeki şu iki koşullu senaryoyu matrise dökelim:

• Koşul 1 (C1): Kullanıcı giriş yapmış mı?

• Koşul 2 (C2): Ödeme yöntemi onaylandı mı?

Oluşan Karar Tablosu:

Tablo Optimizasyonu: Tabloya dikkat ettiyseniz, kullanıcı giriş yapmadığı sürece (C1 = Hayır), ödemenin onaylanıp onaylanmamasının (C2) sistem sonucu için bir önemi yoktur; her iki durumda da kullanıcı login sayfasına yönlendirilir. Gerçek projelerde R3 ve R4 kurallarını birleştirerek test eforumuzu optimize edebiliriz.

İş Kurallarının Arka Planı: Java Uygulaması

Yukarıda haritasını çıkardığımız karar tablosunun backend tarafında nasıl bir Java koduyla can bulacağını görelim. Kurumsal mimariye uygun, temiz bir PaymentProcessor sınıfı kurgulayalım:

Java

public class PaymentProcessor {

    public String processPayment(boolean isUserLoggedIn, boolean isPaymentApproved){
        // Kural 3 & Kural 4: Kullanıcı giriş yapmadıysa direkt engelle
        if (!isUserLoggedIn) {
            return "Kullanıcı girişi gerekli.";
        }
        
        // Kural 1: Kullanıcı giriş yapmış ve ödeme onaylanmışsa
        if (isPaymentApproved) {
            return "Ödeme başarıyla gerçekleştirildi. Sipariş hazırlanıyor.";
        } 
        
        // Kural 2: Kullanıcı giriş yapmış ama ödeme reddedilmişse
        return "Ödeme onayı alınamadı. Lütfen bilgilerinizi kontrol edin.";
    }
}

Bu Java metodu önümüze geldiğinde, yazdığımız karar tablosundaki R1, R2 ve birleştirdiğimiz R3/R4 kuralları için doğrudan Birim Testleri (Unit Tests) veya API Test senaryoları kurgulayabiliriz. Tablo elimizde olduğu sürece hangi kombinasyonun ne döneceğini ezbere değil, dökümante edilmiş kurallara göre test ederiz.

Karar Tablosu Testi Bize Ne Kazandırır?

• Sıfır Kör Nokta: Tüm mantıksal kombinasyonlar gözümüzün önünde bir matris olarak durduğu için "Aklıma gelmemişti" diyebileceğimiz hiçbir açık kapı kalmaz.

• Gereksinim Analizi (Requirement Review): Tabloyu çizerken bazen iş analistlerinin (PO) bile düşünmediği çelişkili kuralları fark eder, kod yazılmadan önce hatayı (ambiguity) masada çözeriz.

• Test Otomasyon Altyapısı: Tablodaki her bir sütun (Rule), otomasyon süreçlerindeki Veri Güdümlü Test (Data-Driven Testing) senaryolarımız için hazır birer veri seti (Test Data) demektir.

Özetle

Karar tablosu testi; bankacılık, sigorta prim hesaplamaları, sepet indirim motorları gibi karmaşık kurallarla örülü sistemleri test ederken bir QA mühendisinin en büyük pusulasıdır. Kodu yazan geliştirici arkadaşınız iç içe if-else veya switch-case yapıları arasında kaybolsa bile, siz elinizdeki matris sayesinde sistemi her zaman doğru çıktıya zorlayabilirsiniz. Projelerinizde karmaşık kuralları satırlara dökmeyi ve matematiksel gücü arkanıza almayı unutmayın!