Geliştirici “bitti” dedi, sistem testi geçti. Sıra kullanıcı kabul testinde (UAT, user acceptance testing): iş birimi, sistemin kendi işini gerçekten çözüp çözmediğine karar verir. İş analisti çoğu ekipte senaryoları hazırlar, testi yürütür ve kararı destekler. Onayı iş birimi verir.
| Test | Soru | Kim? |
|---|---|---|
| Birim ve entegrasyon testi | Kod doğru çalışıyor mu? | Geliştirici |
| Sistem testi | Sistem gereksinimi karşılıyor mu? | Test uzmanı |
| UAT | Bu işi kabul ediyor muyuz? | İş birimi, iş analisti destekler |
Kabul kriterinden senaryoya
Her kabul kriteri en az bir senaryo olur. Üç tür düşün:
- Olumlu (positive): kural işlemeli. 3.000 saniyelik teslimat 30 TL alır.
- Olumsuz (negative): sistem bir şey yapmamalı. İptal edilen sipariş kupon almaz.
- Sınır (boundary): hatalar en çok sınırda çıkar. 2.700, 2.701, 3.600, 3.601.
| Senaryo | Durum | Süre | Bu ayki kupon | Beklenen |
|---|---|---|---|---|
| olumlu-30 | teslim | 3.000 | 0 | 30 |
| olumsuz-iptal | iptal | boş | 0 | 0 |
| sinir-2700 | teslim | 2.700 | 0 | 0 |
| sinir-2701 | teslim | 2.701 | 0 | 30 |
| aylik-sinir | teslim | 4.000 | 2 | 0 |
| sonradan-iade | teslim, sonra iade | 3.000 | 0 | 30, sonra kupon iptal |
Test verisi
Sınır durumu canlı veride her zaman bulunmaz. Test ortamında kendi verini kurarsın. Kişisel veri içeren canlı kaydı test ortamına kopyalama; gerekirse maskele (KVKK dersi isteğe bağlı bölümde). Burada test verisini küçük bir tablo olarak tutuyoruz:
CREATE TABLE ba_test (
senaryo VARCHAR(30),
status VARCHAR(10),
sure_sn INT,
aylik_kupon INT,
beklenen INT
);
INSERT INTO ba_test VALUES ('olumlu-30', 'teslim', 3000, 0, 30);
INSERT INTO ba_test VALUES ('olumlu-60', 'teslim', 4000, 0, 60);
INSERT INTO ba_test VALUES ('olumsuz-zamaninda', 'teslim', 1800, 0, 0);
INSERT INTO ba_test VALUES ('olumsuz-iptal', 'iptal', NULL, 0, 0);
INSERT INTO ba_test VALUES ('olumsuz-iade', 'iade', 4000, 0, 0);
INSERT INTO ba_test VALUES ('sinir-2700', 'teslim', 2700, 0, 0);
INSERT INTO ba_test VALUES ('sinir-2701', 'teslim', 2701, 0, 30);
INSERT INTO ba_test VALUES ('sinir-3600', 'teslim', 3600, 0, 30);
INSERT INTO ba_test VALUES ('sinir-3601', 'teslim', 3601, 0, 60);
INSERT INTO ba_test VALUES ('aylik-sinir', 'teslim', 4000, 2, 0);
SELECT senaryo, status, sure_sn, aylik_kupon, beklenen FROM ba_test ORDER BY senaryo;
Kuralı SQL ile yazıp her senaryoda sonucu karşılaştırmak, geliştiriciden bağımsız ikinci bir hesap demektir. Boş dönen fark sorgusu testin geçtiğini gösterir; bu Veri kalitesi ve SQL kodunu test etmek derslerindeki “hata varsa satır döndür” kalıbıdır.
Mutabakat (reconciliation)
Test verisi kuralı sınar, mutabakat işi sınar: gerçek dönem verisinde üretilen kuponlar beklenenle aynı mı? Bağımsız bir “beklenen” listesi kur, sonra üç soru sor: fazla kim, eksik kim, tutarı farklı kim?
WITH b AS (
SELECT order_id,
CASE WHEN ROUND((julianday(delivered_at) - julianday(placed_at)) * 86400) > 3600 THEN 60 ELSE 30 END AS tutar
FROM lk_orders
WHERE status = 'teslim'
AND placed_at >= '2024-12-01' AND placed_at < '2025-01-01'
AND ROUND((julianday(delivered_at) - julianday(placed_at)) * 86400) > 2700
)
SELECT COUNT(*) AS beklenen_kupon, SUM(tutar) AS beklenen_tutar FROM b;
Alıştırmalarda hatalı bir kupon işinin çıktısını bu listeyle karşılaştırıp hataları bulacaksın.
İyi hata kaydı (defect report)
Hata kaydını okuyan, sana sormadan hatayı yeniden üretebilmeli.
Başlık: Tam 2.700 saniyelik teslimata 30 TL kupon üretiliyor Ortam: UAT, sürüm 1.4.0, 12.03 tarihli veri Adımlar: 1. Teslim süresi tam 2.700 saniye olan sipariş oluştur (test kaydı: sinir-2700) 2. Kupon işini çalıştır 3. ba_kupon tablosunu sipariş numarasıyla sorgula Beklenen: Kupon yok (Kural K2: "aşan" sınırı dahil etmez; GRS-04) Gerçekleşen: 30 TL kupon oluştu Etki: Dönem verisine göre birkaç sipariş; tutar etkisi küçük ama kural yanlış Ek: Sorgu ve ekran görüntüsü
“Kupon çalışmıyor” başlığı hata kaydı değildir. Yorum yazma, gözlem yaz. Gereksinim numarasına bağla: bu izlenebilirlik (traceability) sayesinde hangi kuralın test edildiği belli olur.
Önem ve öncelik (severity, priority)
Önem hatanın sistem üzerindeki etkisidir, teknik olarak değerlendirilir. Öncelik ne zaman düzeltileceğidir, iş kararıdır. İkisi farklı şeydir.
| Örnek | Önem | Öncelik |
|---|---|---|
| Kupon işi her gece duruyor | yüksek | yüksek |
| Bildirim metninde şirket adı yanlış | düşük | yüksek |
| Yılda bir kez çalışan arşiv raporu hata veriyor | yüksek | düşük |
Onay (UAT sign-off)
Onay kapısı baştan yazılır, test bitince tartışılmaz. Örnek çıkış ölçütü: bütün senaryolar çalıştı, yüksek önemli açık hata yok, açık kalan düşük hatalar sahibi ve tarihiyle listelendi, mutabakat farkı sıfır. Onayı veren kişi iş birimidir, belge kayıt altına alınır. Şartlı onay da mümkündür: “şu iki hata ilk haftada kapanacak” yazılır.