Etiket: STLC

  • Evaluation-Driven Development: AI Sistemlerinde Test Artık Kod Testi Değil

    Yazılım dünyasında test uzun yıllar boyunca daha çok şu soruya odaklandı:

    Kod doğru çalışıyor mu?

    Bu soru hâlâ önemli.

    Unit test, integration test, functional test, performance test, security test, UAT… Bunların hiçbiri önemini kaybetmedi.

    Ama AI-native ve agentic sistemlerde artık bu soru tek başına yeterli değil.

    Çünkü sistemin içinde sadece klasik kod yok.

    Artık prompt var.
    Context var.
    RAG var.
    Tool calling var.
    Memory var.
    Agent workflow var.
    İnsan onayı gereken karar noktaları var.

    Bu yüzden yeni soru şu hale geliyor:

    AI doğru bağlamda, doğru aracı, doğru sınırlar içinde kullandı mı?

    İşte Evaluation-Driven Development burada devreye giriyor.


    Evaluation-Driven Development nedir?

    Evaluation-Driven Development, AI destekli veya agentic sistemlerde çıktının sadece çalışıp çalışmadığını değil; doğru, güvenilir, izlenebilir ve beklenen davranışa uygun olup olmadığını değerlendirme yaklaşımıdır.

    Klasik test genelde şunu sorar:

    Fonksiyon beklenen sonucu verdi mi?

    Evaluation ise daha geniş bakar:

    AI bu sonuca nasıl ulaştı?
    Doğru bağlamı kullandı mı?
    Kaynakları doğru yorumladı mı?
    Gerekli yerde durup insana sordu mu?
    Yanlış aracı çağırdı mı?
    Uydurma bilgi üretti mi?
    Güvenlik veya politika sınırını aştı mı?

    Yani AI-native sistemlerde test, sadece kodun davranışını değil, AI’ın karar ve aksiyon sürecini de kapsar.


    Neden şimdi önemli?

    Çünkü AI çıktıları çoğu zaman ikna edici görünür.

    Cümleler düzgün olabilir.
    Kod çalışıyor olabilir.
    Test yazılmış olabilir.
    Dokümantasyon profesyonel durabilir.
    Analiz mantıklı görünebilir.

    Ama görünüm güvenilirlik değildir.

    AI yanlış context kullanabilir.
    Eksik bilgiyle karar önerebilir.
    RAG sonucunu yanlış yorumlayabilir.
    Yanlış tool çağırabilir.
    İnsan onayı gereken yerde otomatik ilerleyebilir.
    Hallucination üretebilir.
    Güvenlik veya gizlilik sınırını aşabilir.

    Bu yüzden AI-native SDLC’de sadece “test geçti mi?” demek yeterli olmaz.

    Şunu da sormak gerekir:

    AI davranışı değerlendirildi mi?


    Artık sadece output değil, süreç de test edilmeli

    Klasik yazılımda çoğu zaman sonuca bakarız.

    Fonksiyon beklenen sonucu verdi mi?
    API doğru response döndü mü?
    UI beklenen davranışı gösterdi mi?

    AI sistemlerinde sonuç kadar, o sonuca nasıl ulaşıldığı da önemlidir.

    Çünkü AI doğru cevaba yanlış yoldan ulaşabilir.

    Yanlış kaynağı kullanıp doğru görünen cevap verebilir.
    Yanlış tool çağırıp sonucu şans eseri doğru yorumlayabilir.
    İnsan onayı gereken yerde durmadan ilerleyebilir.
    Eksik context ile fazla özgüvenli bir çıktı üretebilir.

    Bu yüzden AI-native sistemlerde testin kapsamı genişler.

    Sadece çıktı değil, süreç de değerlendirilmelidir.


    Neleri evaluate etmeliyiz?

    Evaluation-Driven Development içinde birkaç temel alan öne çıkar.


    1. Output Evaluation

    İlk bakılacak şey AI çıktısının kendisidir.

    Şu sorular sorulur:

    • Çıktı doğru mu?
    • Beklenen formatta mı?
    • Eksik bilgi var mı?
    • Uydurma bilgi içeriyor mu?
    • Kullanıcı ihtiyacına gerçekten cevap veriyor mu?
    • Gereksiz özgüvenli veya yanıltıcı mı?

    Bu özellikle dokümantasyon, analiz, özet, kod açıklaması ve karar önerilerinde önemlidir.

    Çünkü AI çıktısı düzgün görünse bile yanlış olabilir.


    2. Context Evaluation

    AI’ın kalitesi büyük ölçüde kullandığı context’e bağlıdır.

    Yanlış context, yanlış sonuç üretir.

    Bu yüzden şu sorular önemlidir:

    • AI doğru dokümanları kullandı mı?
    • Güncel bilgiye mi dayandı?
    • Eski veya geçersiz bilgiyi mi kullandı?
    • Gereksiz context sonucu bozdu mu?
    • Kritik bağlam eksik miydi?

    AI-native sistemlerde context yönetimi test edilmeden güvenilirlik sağlanamaz.

    Çünkü çoğu hata modelden değil, yanlış veya eksik context’ten gelir.


    3. RAG Evaluation

    RAG kullanılan sistemlerde evaluation daha da önemlidir.

    Çünkü cevap sadece modelden değil, getirilen kaynaklardan da etkilenir.

    RAG için şu sorular sorulur:

    • Doğru kaynaklar getirildi mi?
    • Getirilen kaynaklar güncel mi?
    • Cevap kaynaklara dayanıyor mu?
    • Kaynakta olmayan bilgi uyduruldu mu?
    • Benzer ama yanlış doküman kullanıldı mı?
    • Kritik kaynak kaçırıldı mı?

    RAG sistemlerinde başarı sadece “cevap güzel mi?” değildir.

    Başarı, cevabın doğru kaynağa dayanmasıdır.


    4. Tool Calling Evaluation

    Agentic sistemlerde AI sadece cevap üretmez.

    Araç da çağırır.

    Kod çalıştırabilir.
    API çağırabilir.
    Veritabanı sorgulayabilir.
    Dosya okuyabilir.
    Ticket açabilir.
    Deployment başlatabilir.

    Bu yüzden tool calling mutlaka değerlendirilmelidir.

    Şu sorular sorulmalıdır:

    • Doğru araç çağrıldı mı?
    • Araç doğru parametrelerle kullanıldı mı?
    • Gereksiz tool call yapıldı mı?
    • Tool sonucu doğru yorumlandı mı?
    • Hata durumunda doğru davrandı mı?
    • Yetkisi olmayan bir aksiyon almaya çalıştı mı?

    Agentic sistemlerde tool calling kontrol edilmezse, AI sadece yanlış cevap üretmez; yanlış aksiyon da alabilir.


    5. Agent Workflow Evaluation

    Birden fazla adımı olan agentic sistemlerde sadece sonuç değil, akış da önemlidir.

    Ajan doğru sırayla mı ilerledi?
    Doğru noktada durdu mu?
    Gerekli kontrolü yaptı mı?
    İnsan onayı gereken yerde bekledi mi?
    Quality gate’i atladı mı?
    Hatalı adımdan geri dönebildi mi?

    Bu yüzden agent workflow test edilmelidir.

    Özellikle yazılım geliştirme ajanlarında bu çok kritiktir.

    Çünkü bir ajan gereksinimi yanlış yorumlarsa, diğer ajan kodu da yanlış yazabilir, test de yanlış senaryoyu doğrulayabilir.

    Hata zincir boyunca büyür.


    6. Human Decision Evaluation

    AI-native SDLC’de insan tamamen devreden çıkmaz.

    Ama insan her adımda da olmamalıdır.

    Önemli olan insanın doğru karar noktasında devreye girmesidir.

    Bu yüzden şu sorular test edilmelidir:

    • İnsan onayı gereken yerde sistem duruyor mu?
    • Düşük riskli durumda otomasyon ilerleyebiliyor mu?
    • Yüksek riskli durumda approval istiyor mu?
    • AI riskli bir kararı kendi vermeye çalışıyor mu?
    • Onay geçmişi kayıt altına alınıyor mu?

    Bu yaklaşımı şöyle özetleyebiliriz:

    Human-in-the-loop değil, human-at-the-decision-point.

    Yani insan her adımda süreci yavaşlatan kişi değil, kritik karar noktasında devreye giren kişidir.


    Evaluation sadece manuel yapılmaz

    Evaluation deyince her şeyi insanın tek tek kontrol etmesi anlaşılmamalı.

    Bazı değerlendirmeler otomatik olabilir:

    • output format kontrolü,
    • test sonucu,
    • güvenlik scan sonucu,
    • policy check,
    • regression eval,
    • golden dataset karşılaştırması,
    • hallucination kontrolü,
    • tool call doğrulaması,
    • RAG kaynak uygunluğu,
    • metrik bazlı kalite kontrolü.

    Bazı değerlendirmeler ise insan kararı gerektirir:

    • risk kabulü,
    • mimari istisna,
    • ürün kararı,
    • müşteri etkisi,
    • etik veya hukuki hassasiyet,
    • production release onayı.

    Yani evaluation, otomasyon ve insan kararının birlikte tasarlandığı bir kalite yaklaşımıdır.


    Evaluation-Driven Development ve Quality Gates ilişkisi

    Bir önceki yazıda quality gates konusunu konuşmuştuk.

    Evaluation-Driven Development, bu quality gate’lerin AI-native dünyadaki karşılığıdır.

    Klasik quality gate şunu sorar:

    Testler geçti mi?

    AI-native quality gate ise şunu da sorar:

    AI çıktısı güvenilir mi?
    AI doğru context kullandı mı?
    Ajan doğru aracı çağırdı mı?
    İnsan onayı gereken yerde durdu mu?
    Cevap kaynaklara dayanıyor mu?
    Süreç sonradan denetlenebilir mi?

    Bu yüzden evaluation, AI-native SDLC’nin merkezinde olmalıdır.

    Çünkü AI ile üretim hızlandıkça, değerlendirme disiplini zayıf kalırsa risk büyür.


    Evaluation nasıl uygulanabilir?

    Evaluation-Driven Development bir anda büyük ve karmaşık bir sistem kurmak zorunda değildir.

    Küçük başlanabilir.

    Örneğin:

    • AI çıktıları için beklenen format kuralları belirlenebilir.
    • Kritik prompt’lar için test veri setleri hazırlanabilir.
    • RAG cevapları için kaynak doğruluğu kontrol edilebilir.
    • Tool calling senaryoları için başarılı ve başarısız akışlar test edilebilir.
    • İnsan onayı gereken karar noktaları netleştirilebilir.
    • Agent workflow logları izlenebilir hale getirilebilir.
    • Kritik senaryolar için regression eval setleri oluşturulabilir.

    Buradaki amaç, AI’ı yavaşlatmak değildir.

    Amaç, AI’ın hızlı üretimini güvenilir hale getirmektir.


    Sonuç

    AI-native sistemlerde test artık sadece kod testi değildir.

    Kod hâlâ test edilmelidir.

    Ama bunun yanında AI çıktısı, context, RAG, tool calling, agent workflow, insan karar noktaları ve audit evidence da değerlendirilmelidir.

    Çünkü AI sadece metin üretmez.

    Karar önerir.
    Aksiyon alır.
    Araç kullanır.
    Süreçleri tetikler.
    Teslimat zincirine dahil olur.

    Bu yüzden yeni dönemde yazılım kalitesi iki soruyla ölçülecek:

    Sistem doğru çalışıyor mu?

    ve

    AI doğru davrandı mı?

    Bence Evaluation-Driven Development’ın özü burada.

    Ve yine aynı dengeye geliyoruz:

    AI üretir.
    Sistem değerlendirir.
    İnsan kritik kararı verir.


    Serinin devamı

    Bu yazı, Agentic Software Development serisinin altıncı yazısıdır.

    Serinin önceki yazısı:
    Quality Gates: AI Çıktısı Nasıl Teslimata Dönüşür?

    Serinin sonraki yazısı:
    AI Kötü Süreçleri Düzeltmez, Büyütür

  • Quality Gates: AI Çıktısı Nasıl Teslimata Dönüşür?

    AI artık yazılım geliştirme sürecinde çok şey üretebiliyor.

    Kod yazabiliyor.
    Test taslağı çıkarabiliyor.
    Dokümantasyon hazırlayabiliyor.
    Hata açıklayabiliyor.
    Riskleri listeleyebiliyor.

    Ama burada kritik bir ayrım var:

    AI’ın çıktı üretmesi, o çıktının teslimata hazır olduğu anlamına gelmez.

    Kod çalışabilir ama yanlış problemi çözebilir.
    Test yazılmış olabilir ama kritik senaryoları kapsamıyor olabilir.
    Dokümantasyon düzgün görünebilir ama gerçeği tam yansıtmayabilir.
    Deployment başarılı olabilir ama canlı ortamda sistem beklenen davranışı göstermeyebilir.

    Bu yüzden AI çıktısı doğrudan teslimat değildir.

    Önce doğrulanmalıdır.

    İşte burada quality gates, yani kalite kapıları devreye girer.


    Quality gate nedir?

    Quality gate, bir çıktının bir sonraki aşamaya geçmeden önce karşılaması gereken kontrol noktasıdır.

    Basitçe sistem şunu sorar:

    Bu çıktı ilerlemeye hazır mı?

    Ama bu soru sadece “testler geçti mi?” demek değildir.

    AI-native yazılım geliştirmede quality gate daha geniş bir güven zinciridir.

    Şu sorulara bakar:

    • Bu çıktı doğru ihtiyaca mı bağlı?
    • Kod anlaşılır ve sürdürülebilir mi?
    • Static analysis temiz mi?
    • Fonksiyonel davranış doğru mu?
    • Unit, integration ve system testler geçti mi?
    • Güvenlik riski var mı?
    • Performans kabul edilebilir mi?
    • Deployment kontrollü mü?
    • Canlı ortam izlenebilir mi?
    • İnsan onayı gereken yerde duruyor mu?
    • Sonradan denetlenebilir kanıt oluştu mu?

    Çünkü AI ile üretim hızlanırken, doğrulama zayıf kalırsa sadece daha hızlı risk üretmiş oluruz.


    Her projeye aynı kapılar gerekmez

    Burada denge önemli.

    Quality gates, her projeye aynı ağırlıkta uygulanacak sabit bir kontrol listesi değildir.

    Küçük ve düşük riskli bir uygulamada bazı kontroller daha hafif olabilir.

    Ama finans, sağlık, kamu, ödeme sistemleri, kritik veri veya regülasyonlu yapılarda kalite kapıları daha güçlü tasarlanmalıdır.

    Doğru yaklaşım risk bazlıdır.

    Yani önce şu sorular sorulmalıdır:

    • Sistem ne kadar kritik?
    • Hata olursa etkisi ne olur?
    • Güvenlik riski var mı?
    • Regülasyon var mı?
    • Deployment sonrası geri dönüş kolay mı?
    • AI çıktısı hangi kararı veya davranışı etkiliyor?

    Bu yüzden quality gate bir bürokrasi listesi değildir.

    Doğru tasarlanırsa, AI ile hızlanan üretimi güvenilir teslimata dönüştüren risk yönetimi mekanizmasıdır.


    AI üretir, sistem doğrular, insan karar verir

    Bu seride tekrar ettiğimiz ana cümle burada da geçerli:

    AI üretir.
    Sistem doğrular.
    İnsan karar verir.

    AI kod üretebilir.

    Ama sistem şunu kontrol etmelidir:

    • kod build oluyor mu?
    • static analysis temiz mi?
    • testler anlamlı mı?
    • güvenlik riski var mı?
    • performans bozuldu mu?
    • mimari kurallar korunuyor mu?
    • iş davranışı doğru mu?
    • deployment sonrası sistem sağlıklı mı?

    İnsan ise kritik noktada karar verir.

    Bu çıktı kabul edilecek mi?
    Release’e dahil edilecek mi?
    Risk alınacak mı?
    İstisna verilecek mi?
    Geri çevrilecek mi?

    Quality gates bu dengeyi kurar.


    AI-native SDLC’de temel kalite kapıları

    Bence AI-native bir yazılım geliştirme sürecinde kalite kapıları şu başlıklarda düşünülmeli.

    Ama tekrar vurgulamak gerekir: Bunların hepsi her projede aynı derinlikte uygulanmak zorunda değildir.


    1. Requirement ve Design Gate

    İlk soru şudur:

    Doğru problemi mi çözüyoruz?

    AI gereksinim özeti çıkarabilir, kabul kriteri önerebilir, tasarım alternatifi üretebilir.

    Ama kritik iş ve mimari kararlar insanda kalmalıdır.

    Çünkü yanlış ihtiyaca yazılmış kaliteli kod hâlâ yanlış sonuçtur.


    2. Development ve Static Analysis Gate

    AI kod yazabilir.

    Ama geliştiricinin anlamadığı kod, teknik borca dönüşebilir.

    Development Gate şunu sorar:

    • Kod okunabilir mi?
    • Kod sahiplenilebilir mi?
    • PR açıklaması yeterli mi?
    • Değişiklik ilgili task veya requirement ile bağlantılı mı?

    Static Analysis Gate ise kod çalışmadan önce riskleri yakalar:

    • code smell,
    • SAST,
    • dependency check,
    • secret scanning,
    • license compliance,
    • architecture rule check,
    • container ve IaC scanning.

    Bu kapının amacı erken uyarıdır.

    Kod daha çalışmadan görülebilecek riskleri yakalamak gerekir.


    3. Test Pyramid ve Test Automation Gate

    AI test yazabilir.

    Ama AI’ın test yazması, test stratejisinin doğru olduğu anlamına gelmez.

    Test otomasyonu test pyramid mantığıyla düşünülmelidir:

    Çok sayıda hızlı unit test
    Yeterli sayıda integration / contract test
    Daha az ama kritik API / E2E test
    İhtiyaca göre UAT, exploratory, alpha ve beta testleri

    Her şeyi UI testiyle doğrulamak yavaş ve kırılgan olur.

    Sadece unit testlere güvenmek de sistem davranışını kaçırabilir.

    Bu yüzden asıl soru şudur:

    Bu davranışı en hızlı, en güvenilir ve en az bakım maliyetiyle hangi seviyede test ederiz?

    Araç seçimi de buna göre yapılmalıdır.

    Örneğin unit test için xUnit, JUnit, pytest veya Jest; UI/E2E için Playwright, Cypress veya Selenium; performance için k6, JMeter veya Gatling düşünülebilir.

    Ama araçtan daha önemli olan şey şudur:

    Test otomasyonu güven vermeli, ekibe bakım yüküyle zarar vermemelidir.


    4. Functional Test & Automation Gate

    Teknik testlerin geçmesi, sistemin iş davranışını doğru yaptığı anlamına gelmez.

    Functional Test Gate şunu sorar:

    Sistem, kullanıcının ve iş biriminin beklediği davranışı gerçekten yapıyor mu?

    Burada ana iş akışları, kullanıcı rolleri, yetkiler, form validasyonları, iş kuralları, hata mesajları ve kabul kriterleri doğrulanır.

    AI teknik olarak doğru görünen ama iş kuralını yanlış uygulayan kod üretebilir.

    Bu yüzden fonksiyonel test otomasyonu AI-native SDLC’de kritik hale gelir.

    Özellikle sık tekrarlanan regresyon senaryoları, kritik iş akışları, login, yetkilendirme, ödeme, onay, kayıt gibi ana fonksiyonlar otomasyon için güçlü adaylardır.


    5. Integration, SIT ve System Test Gate

    AI ile üretilen kod lokal olarak doğru çalışabilir.

    Ama gerçek sorun çoğu zaman entegrasyon noktalarında çıkar.

    Bu kapı şu soruları sorar:

    • API contract bozuldu mu?
    • Database, queue, cache veya dış servis entegrasyonları çalışıyor mu?
    • Sistemler arası veri akışı doğru mu?
    • Kritik iş akışları uçtan uca geçiyor mu?
    • Hata durumlarında sistem beklenen davranışı gösteriyor mu?

    CIT, SIT ve system test seviyeleri kurumdan kuruma farklı isimlendirilebilir.

    Önemli olan isim değil, entegrasyon riskinin erken yakalanmasıdır.


    6. Dynamic Analysis, Security ve Performance Gate

    Static analysis kodun yapısına bakar.

    Dynamic analysis ise çalışan sistemin davranışına bakar.

    Burada DAST, API security testleri, runtime kontroller, load test, stress test, response time, throughput, CPU ve memory davranışı gibi başlıklar devreye girer.

    AI’ın ürettiği kod doğru çalışabilir ama performans açısından kötü olabilir.

    Ya da güvenlik açığı taşıyabilir.

    Bu yüzden security ve performance sonuçları sadece rapor olmamalıdır.

    Kritik risk varsa release durmalıdır.


    7. Release, Deployment ve Observability Gate

    Başarılı deployment, başarılı teslimat anlamına gelmez.

    Deployment sadece canlıya alma adımıdır.

    Asıl soru şudur:

    Canlı ortamda sistem sağlıklı mı?

    Bu yüzden release öncesinde rollback planı, migration planı, feature flag, deployment stratejisi, monitoring ve alert kuralları hazır olmalıdır.

    Deployment sonrasında ise observability devreye girer:

    • error rate arttı mı?
    • response time bozuldu mu?
    • loglarda beklenmeyen hata var mı?
    • trace, metric ve log korelasyonu var mı?
    • kritik iş metrikleri etkilendi mi?
    • rollback gerekiyor mu?

    AI-native sistemlerde buna ek olarak AI agent kararları, tool call kayıtları, prompt-context-output ilişkisi ve hatalı AI davranışları da izlenebilmelidir.

    Çünkü izleyemediğimiz sistemi güvenilir şekilde yönetemeyiz.


    8. Agentic Testing ve Audit Evidence Gate

    AI-native dünyada sadece uygulamayı değil, AI davranışını da test etmek gerekir.

    Özellikle agentic sistemlerde şu sorular önemlidir:

    • Ajan doğru bağlamı kullandı mı?
    • Doğru aracı çağırdı mı?
    • Tool call sonucunu doğru yorumladı mı?
    • RAG sonucu güvenilir mi?
    • İnsan onayı gereken yerde durdu mu?
    • Policy dışı çıktı üretti mi?
    • Hallucination riski var mı?

    Bu yüzden test artık sadece “kod doğru çalışıyor mu?” sorusu değildir.

    Asıl soru şudur:

    Ajan doğru bağlamda, doğru sınırlar içinde, doğru davranışı gösterdi mi?

    Son olarak tüm bu sürecin kanıtı tutulmalıdır.

    Hangi AI çıktısı kullanıldı?
    Kim review etti?
    Hangi testler geçti?
    Hangi riskler kabul edildi?
    Kim onay verdi?
    Ne zaman deploy edildi?
    Deploy sonrası sistem sağlıklı mıydı?

    Bu kanıt yoksa, süreç denetlenebilir değildir.


    Sonuç

    AI çıktısı değerlidir.

    Ama AI çıktısı tek başına teslimat değildir.

    Teslimat olması için doğrulanması gerekir.

    Doğru ihtiyaca bağlı olmalıdır.
    Development ve static analysis kapılarından geçmelidir.
    Test pyramid’e uygun testlerle doğrulanmalıdır.
    Fonksiyonel test otomasyonu iş davranışını kontrol etmelidir.
    Integration, SIT ve system testlerle sistem etkisi görülmelidir.
    Security ve performance kontrollerinden geçmelidir.
    Deployment kontrollü yapılmalıdır.
    Canlı ortam observability ile izlenmelidir.
    AI agent davranışları test edilebilir ve denetlenebilir olmalıdır.

    Ama bütün bunlar her projeye aynı ağırlıkta uygulanmak zorunda değildir.

    Doğru yaklaşım risk bazlıdır.

    Kritik sistemlerde kapılar daha sıkı olur.
    Düşük riskli sistemlerde daha hafif uygulanabilir.

    Önemli olan AI ile hızlanan üretimi kontrolsüz bırakmamaktır.

    Çünkü yeni dönemin temel dengesi değişmiyor:

    AI üretir.
    Sistem doğrular.
    İnsan karar verir.

    Quality gates, bu dengenin çalışmasını sağlayan güven zinciridir.

Top