AI Kod Kalitesi Yönetimi: Test Checklist ve Bug Akışı

AI Kod Kalite Yönetimi: Test Checklist ve Bug Akışı

AI araçlarıyla kod üretimi hızlandığında bir paradoks ortaya çıkıyor: yazma süresi kısaldı, ama test ihtiyacı azalmadı. Aksine arttı.

Sebebi basit. AI, verilen promptu karşılayan kodu üretiyor. Ama o kodun edge case'leri nasıl yönettiğini, mevcut sistemle nasıl entegre olduğunu, üretimde nasıl davranacağını test etmek hâlâ insan işi. AI bu soruları sormadan kod yazıyor. Testi atlayan geliştirici ise "AI yazdı, çalışır" varsayımıyla ilerliyor.

Bu varsayım prodüksiyonda kırılıyor.

AI Kodu Neden Daha Fazla Test Gerektiriyor?

Geleneksel geliştirmede geliştirici kodu satır satır yazarken zihinsel bir test süreci de yürütüyor. "Bu koşulda ne olur, şu durumda ne döner?" soruları kod yazılırken soruluyor. Bu süreç yavaş ama kaliteyi içselleştiriyor.

AI bu zihinsel süreci atlıyor. Geliştirici promptu yazıyor, çıktıyı alıyor, entegre ediyor. Araya giren zihinsel test süreci yok. Bu boşluk sistemli bir test süreciyle doldurulmadığında riskler görünmez kalıyor.

Bağlam bilgisi eksik. AI projenin tüm bağlamını bilmiyor. Ürettiği kod genel olarak doğru olabilir ama projeye özgü edge case'leri, iş kurallarını veya mevcut sistemin inceliklerini yansıtmayabilir.

Edge case kapsımı zayıf. AI mutlu yolu iyi yazıyor. Boş input, null değer, ağ hatası, eş zamanlı istek gibi durumları genellikle ikinci planda bırakıyor — sorulmadıkça.

Entegrasyon körü. AI üretilen kod kendi başına çalışabilir ama mevcut modüllerle entegrasyonu test edilmeden bilinemez. Entegrasyon sorunları en geç prodüksiyonda çıkıyor.

Güven yanılgısı. "AI yazdı, daha az hata olur" algısı test sürecini gevşetiyor. Oysa AI üretilen kodun hata oranı geleneksel koddan düşük değil — sadece farklı türde hatalar içeriyor.

Alios'ta Kalite Yönetimi Yapısı

Alios'ta AI kod kalite yönetimi üç katmanla çalışıyor: test checklist node'ları, bug node'ları ve dört aşamalı durum akışı.

Her AI üretilen feature veya modül için bu yapı kurulduğunda test süreci görünür, takip edilebilir ve tekrarlanabilir hale geliyor.

Dört Aşamalı Durum Akışı

Her test ve bug node'u dört durumdan birinde yaşıyor:

⬜ NOT_STARTED → henüz başlanmadı
🔄 IN_PROGRESS → aktif çalışılıyor
👀 REVIEW      → tamamlandı, onay bekleniyor
✅ DONE        → onaylandı, kapatıldı

Bu dört durum hem test checklist hem de bug node'ları için geçerli. Sistem tutarlı, öğrenme maliyeti sıfır.

Test Checklist Node'ları

AI üretilen her önemli kod parçası için bir test checklist node'u açılıyor. Bu node görev değil — kalite kapısı.

Test Checklist Node Şablonu

📌 TEST CHECKLİST — [Feature / Modül Adı]
Durum: NOT_STARTED
AI Aracı: [Claude / Cursor / Copilot vb.]
Geliştirici: [İsim]
Test Eden: [İsim — farklı kişiyse]
Deadline: [Test tamamlanma tarihi]
Bağlantılı Node: [İlgili görev veya PR]

─────────────────────────────

🤖 AI KODU ÖZET

Ne üretildi:
[1-2 cümle — AI ne yazdı, hangi promptla]

AI'ın bilmediği bağlam:
[Projeye özgü iş kuralları, kısıtlar veya
edge case'ler AI'a verilmedi mi?]

Risk seviyesi:
[ ] Düşük — izole, bağımsız modül
[ ] Orta — mevcut sistemle entegrasyon var
[ ] Yüksek — kritik iş akışını etkiliyor

─────────────────────────────

✅ FONKSİYONEL TEST

Mutlu Yol:
- [ ] Temel senaryo çalışıyor — [Açıklama]
- [ ] Beklenen çıktı doğrulandı
- [ ] UI/UX beklentiyle örtüşüyor (varsa)

Edge Case'ler:
- [ ] Boş input / null değer yönetimi
- [ ] Maksimum değer / karakter limiti
- [ ] Geçersiz format girişi
- [ ] Eş zamanlı istek / race condition
- [ ] [Projeye özgü edge case 1]
- [ ] [Projeye özgü edge case 2]

Hata Yönetimi:
- [ ] Ağ hatası — doğru mesaj gösteriliyor
- [ ] Timeout — kullanıcı bilgilendiriliyor
- [ ] Yetki hatası — doğru yönlendirme
- [ ] Beklenmedik hata — graceful degradation

─────────────────────────────

🔗 ENTEGRASYON TEST

- [ ] Mevcut modüllerle çakışma yok
- [ ] Veritabanı işlemleri doğru çalışıyor
- [ ] API response formatı uyumlu
- [ ] Auth / Permission kontrolleri çalışıyor
- [ ] [Projeye özgü entegrasyon 1]

─────────────────────────────

⚡ PERFORMANS TEST

- [ ] Normal yük altında response time kabul edilebilir
- [ ] N+1 sorgu problemi yok
- [ ] Memory leak belirtisi yok
- [ ] [Projeye özgü performans kriteri]

─────────────────────────────

🔒 GÜVENLİK KONTROL

- [ ] Input sanitization yapılıyor
- [ ] SQL injection / XSS riski yok
- [ ] Hassas veri log'a yazılmıyor
- [ ] Yetki kontrolü bypass edilemiyor

─────────────────────────────

📋 TEST SONUCU

Genel sonuç:
[ ] Tüm testler geçti — REVIEW'a hazır
[ ] Bug bulundu — bug node'ları açıldı
[ ] Kapsam dışı sorun tespit edildi — not düşüldü

Test notu:
[AI kodunda dikkat çeken bir davranış, bulgu
veya gelecekte referans alınacak gözlem]

Açılan bug sayısı: [N]
Bug node'ları: [Liste]

Checklist Kullanım Ritmi

Her test checklist node'u şu sırayla ilerliyor:

Geliştirici PR açıyor → Test checklist NOT_STARTED'dan
IN_PROGRESS'e geçiyor → Testler yapılıyor → Bug'lar
varsa ayrı node'lar açılıyor → Tüm maddeler tamamlanınca
REVIEW'a geçiyor → Test eden veya lead onaylıyor →
DONE → PR merge edilebilir

PR merge için test checklist'in DONE olması zorunlu. Bu kural "test edildi mi?" sorusunu sistemin kendisi soruyor hale getiriyor.

Bug Node'ları ve Kaydı Şablonu

Test sırasında bulunan her bug ayrı bir node olarak açılıyor. Test checklist'e not düşülmüyor — ayrı takip ediliyor.

Bug Kaydı Şablonu

📌 BUG — [Numara]: [Kısa, net başlık]
Durum: NOT_STARTED
Öncelik: [ ] Kritik  [ ] Yüksek  [ ] Orta  [ ] Düşük
AI Üretilen Kod: [ ] Evet  [ ] Kısmen  [ ] Hayır
Bulan: [İsim] — Tarih: [Tarih]
Atanan: [Geliştirici]
Deadline: [Fix beklenen tarih]
Bağlantılı Checklist: [Test checklist node adı]

🔍 ORTAM

Platform: [Web / iOS / Android]
Tarayıcı: [Chrome 122 / Safari 17 vb.]
Versiyon / Branch: [Hangi build'de]
Hesap türü: [Admin / User / Trial]
URL: [Bug'ın görüldüğü sayfa]

🔁 REPRO ADIMLARI

1. [İlk adım — spesifik]
2. [İkinci adım]
3. [Üçüncü adım]
4. [Bug'ın tetiklendiği adım]

Üretme sıklığı:
[ ] Her zaman üretiliyor
[ ] Ara sıra — yaklaşık %[N]
[ ] Bir kez gözlemlendi

✅ BEKLENEN DAVRANIŞ

[Ne olması gerekiyordu — net ve spesifik]

❌ GERÇEKLEŞEN DAVRANIŞ

[Ne oldu — ekran görüntüsü veya video varsa ek]

📋 LOG / HATA ÇIKTISI

Console hatası:
[Kopyalanmış hata mesajı — varsa]

Network isteği:
[İlgili API çağrısı ve response — varsa]

Sunucu logu:
[İlgili log satırları — varsa]

🤖 AI BAĞLANTI ANALİZİ

Bu bug AI üretilen koddan mı kaynaklanıyor?
[ ] Evet — AI edge case'i ele almadı
[ ] Evet — AI projeye özgü bağlamı bilmiyordu
[ ] Kısmen — AI kodu doğruydu, entegrasyon sorunu
[ ] Hayır — AI ile ilgisi yok

AI prompt'una ne eklenmeliydi?
[Bu bug'ı önleyecek bağlam veya kısıt neydi —
sonraki promptlar için öğrenme notu]

✅ KABUL KRİTERİ

Fix tamamlandı sayılmak için:
- [ ] Repro adımları tekrarlandı — bug üretilemiyor
- [ ] Beklenen davranış gerçekleşiyor
- [ ] [Edge case] durumunda da doğru çalışıyor
- [ ] Regresyon: [Etkilenebilecek özellik] hâlâ çalışıyor
- [ ] Log'da yeni hata yok

🔧 GELİŞTİRİCİ NOTU (fix sonrası)

Root cause: [Ne neden oluyordu]
Çözüm: [Ne değiştirildi]
PR: [Link]
AI prompt güncellendi mi: [ ] Evet  [ ] Hayır  [ ] N/A

AI Bağlantı Analizi Neden Önemli?

Şablondaki "AI Bağlantı Analizi" bölümü standart bug şablonlarında bulunmuyor. Ama AI destekli geliştirmede kritik.

Her bug'da "AI'a ne söylenmeliydi?" sorusu sorulduğunda iki şey oluyor: ekip AI'ı daha iyi kullanmayı öğreniyor, ve aynı bug kategorisi bir daha üretilmiyor. Bu bölüm hata kaydı değil, öğrenme kaydı.

Durum Akışı: Test'ten DONE'a

Test checklist ve bug node'larının birlikte çalışması şöyle görünüyor:

📁 FEATURE: Kullanıcı Davet Sistemi
│
├── 📌 TEST CHECKLİST — Davet Sistemi
│   Durum: IN_PROGRESS → REVIEW → DONE
│   Test eden: Zeynep
│   Bulunan bug sayısı: 2
│
├── 📌 BUG-001: Geçersiz e-posta formatı kabul ediliyor
│   Durum: NOT_STARTED → IN_PROGRESS → REVIEW → DONE
│   Öncelik: Yüksek
│   AI bağlantısı: Evet — validation promptta belirtilmedi
│
└── 📌 BUG-002: Davet linki 24 saat sonra hâlâ aktif
    Durum: NOT_STARTED → IN_PROGRESS → DONE
    Öncelik: Orta
    AI bağlantısı: Kısmen — expiry logic eksik

Feature DONE sayılması için: test checklist DONE, tüm Kritik ve Yüksek öncelikli bug node'ları DONE. Orta ve Düşük bug'lar backlog'a alınabilir ama kayıt altında.

Sprint Bazında Kalite Takibi

Her sprint sonunda test ve bug node'larından şu tablo çıkıyor:

📊 SPRINT [N] KALİTE ÖZETİ

AI üretilen kod oranı: [%N]

Test checklist:
- Açılan: [N]
- Tamamlanan: [N]
- Devir eden: [N]

Bug özeti:
- Toplam bulunan: [N]
- Kritik: [N] → Kapatılan: [N]
- Yüksek: [N] → Kapatılan: [N]
- Orta + Düşük backlog: [N]

AI bağlantılı bug oranı: [%N]

Öğrenme notu:
[Bu sprint AI kodunda en sık hangi hata kategorisi çıktı]
[Bir sonraki sprint'te AI promptlarına ne eklenecek]

Bu özet iki sprint sonra karşılaştırıldığında AI kullanımının kalite üzerindeki etkisi somut hale geliyor. "AI bağlantılı bug oranı" düşüyorsa ekip AI'ı daha iyi kullanmayı öğreniyor demektir.

Son Düşünce

AI kod yazma hızını artırıyor. Test etme sorumluluğunu ortadan kaldırmıyor.

Alios'ta test checklist node'ları ve bug node'ları bu sorumluluğu görünür ve takip edilebilir kılıyor. Her AI üretilen kod test kapısından geçiyor. Her bug öğrenme fırsatına dönüşüyor. Kalite kişiye bağlı kalmıyor — sisteme giriyor.

"AI yazdı, çalışır" varsayımının yerini "AI yazdı, test ettik, çalışıyor" gerçeği alıyor.