8.5. Bölüm Sonu Uygulama Görevi (Hands-on Challenge)

Bölüm 8 boyunca modern bir Çevik (Agile) takımda test mühendisinin bir “kapı nöbetçisi” değil; proaktif bir kalite mimarı ve iletişim ustası olduğunu öğrendin.

Şimdi bu stratejik kaslarını, gerçek hayatta her sprint yaşanan o meşhur “Aman canım ne var ki bunda, sadece bir kutucuk ekleyeceğiz” krizini yönetmek için kullanma vakti!

Görev Senaryosu: “Kapıda Temassız Teslimat” Krizi

Hızla büyüyen bir yemek siparişi mobil uygulamasında Test Mühendisi olarak göreve başladın. Ekip 10 günlük bir Scrum sprinti koşuyor.

Geliştirilecek Kullanıcı Hikâyesi (User Story):

“Bir kullanıcı olarak, sepetimdeki ürünleri sipariş verirken ‘Kapıda Temassız Teslimat’ seçeneğini işaretleyebilmek ve kuryeye özel bir teslimat notu (maksimum 150 karakter) ekleyebilmek istiyorum; böylece siparişimi kapıda fiziksel temas kurmadan güvenle teslim alabilirim.”

Sprint Planlama toplantısındasınız. Geliştirici ekip dokümana bakıp gülüyor:

“Bu çocuk oyuncağı! Ön yüze bir onay kutucuğu (checkbox), altına da 150 karakterlik bir metin kutusu koyacağız. 2 gün geliştiririz, sprintin son günü testçiye atarız, 1 saatte bakar canlıya çıkarız.”

İş Analistinin yazdığı Kabul Kriterleri (Acceptance Criteria) ise sadece şu iki maddeden ibaret:

  1. Kullanıcı temassız teslimat kutucuğunu işaretleyebilmelidir.

  2. Teslimat notu alanı 150 karakterden fazla olmamalıdır.

Bir Kalite Mimarı olarak bu hikâyenin bu haliyle sprintin son gününde patlayacağını biliyorsun.

Senden İstenenler

Aşağıdaki 4 stratejik adımı tamamla ve ekibin için resmi bir Çevik Kalite Stratejisi hazırla:

  1. Three Amigos (Gereksinim Sorgulama) Soruları: Analizde unutulmuş olan ve koda dökülürse sistemi çökertebilecek en az 4 adet kritik iş kuralı / uç senaryo (edge case) sorusu üret.

  2. Shift-Left (Erken Test) Eylem Planı: Geliştiricinin “son gün test edersin” yaklaşımını kırmak için; sprintin ilk 3 gününde masaya koyacağın somut çıktıları ve geliştiriciyle kuracağın iş birliği modelini yaz.

  3. Kriz İletişimi Simülasyonu: Yazılımcı sprintin son gününde özelliği teslim etti ve test ederken temassız teslimat seçilmesine rağmen kullanıcının hâlâ “Kapıda Nakit Ödeme” seçebildiğini fark ettin (Nakit parada temassız teslimat yapılamaz!). Yazılımcının savunmaya geçmesini engelleyen ve çözüm odaklı 1 adet profesyonel mesaj kaleme al.

  4. Retrospektif Süreç Önerisi: Bu teslimat sıkışıklığının bir sonraki sprintte tekrarlanmaması için ekibin oylamasına sunacağın 1 adet resmi süreç iyileştirme maddesi yaz.

🔍 Görev Çözüm Kılavuzu ve Referans Çizelgesi

Kendi stratejini kurguladıktan sonra sektör standardı çözümle kıyasla:

1. Three Amigos Toplantısında Sorulacak 4 Kritik Soru

  • Ödeme Yöntemi Kısıtlaması (İş Kuralı Çatışması): “Temassız teslimat işaretlendiğinde ‘Kapıda Nakit’ ve ‘Kapıda Kredi Kartı POS’ seçenekleri otomatik olarak pasife (disabled) alınıp sadece ‘Online Kredi Kartı / Cüzdan’ zorunlu kılınacak mı? Kapıda nakit para alışverişi olursa bu işlem nasıl temassız sayılacak?”

  • Kurye Uygulaması Entegrasyonu (Arka Yüz / Veri Akışı): “Kullanıcının yazdığı bu 150 karakterlik not kuryenin mobil uygulamasında tam olarak nerede ve nasıl görünecek? Kurye yoldayken bu not ekranında anlık bildirim (Push Notification) olarak mı patlayacak yoksa sipariş fişine mi basılacak?”

  • Özel Karakterler ve Güvenlik (Veri Hijyeni): “Not alanına emoji (örneğin: 🚪 📦) veya çift tırnak (") yazıldığında veritabanı bunu doğru kaydedebiliyor mu? Yoksa karakter kodlama hatası verip siparişin kurye ekranına düşmesini engelliyor mu?”

  • Karakter Sayacı ve Kesme Davranışı (UX/Arayüz): “Kullanıcı 151. karakteri yazmaya çalıştığında sistem yazmayı anında engelliyor mu yoksa hata mesajı mı veriyor? İnternetten 500 karakterlik hazır metin kopyalayıp (paste) yapıştırırsa ilk 150 karakteri kırpıyor muyuz?”

2. Shift-Left (Erken Test) Eylem Planı (İlk 3 Gün)

  • Somut Çıktı (Test Senaryoları): İlk 3 gün içinde kodun gelmesini beklemem. Yukarıdaki soruların netleşen yanıtlarıyla 15 adet detaylı Test Senaryosunu (Pozitif, Negatif, BVA sınır değerleri ve Güvenlik denemeleri) yazar ve Jira biletine iliştiririm.

  • Geliştiriciye İş Birliği Teklifi: Geliştirici arkadaşımın yanına gidip şunu söylerim:

    “Can, ben bu özelliğin tüm uç sınırlarını ve test senaryolarını çıkardım. Kodunu yazarken bu senaryo listesine göz atarsan, hata ihtimalini baştan sıfırlarız. Ayrıca ekranın tamamını bitirmeyi bekleme; arka yüz servislerini tamamladığın 4. günde bana haber ver, ben Postman ile servisleri test ederken sen ekran tasarımını yaparsın; paralel ilerleriz.”

3. Kriz İletişimi Mesaj Metni (Slack / Teams Simülasyonu)

“Selam Can, eline sağlık, temassız teslimat ekranını test ortamında inceledim; arayüz akışı ve 150 karakterlik sınır kontrolü tıkır tıkır çalışıyor.

Testler sırasında önemli bir iş mantığı çelişkisi fark ettim: Kullanıcı ‘Temassız Teslimat’ seçtiğinde, ödeme seçeneklerinde hâlâ ‘Kapıda Nakit Ödeme’ seçilebiliyor. Müşteri kapıda nakit para uzatırsa fiziksel temas kaçınılmaz olacağı için kurye operasyonu ve şirket vaadimiz riske giriyor.

Bu durumu PO (İş Analisti) Zeynep ile 2 dakika konuştuk; kural gereği temassız teslimat seçilince nakit seçeneğinin gizlenmesi gerekiyor. Kodda bu kontrolü eklemek senin ne kadar vaktini alır? Sprint hedefini riske atmadan birlikte nasıl çözelim?”

4. Retrospektif (Retro) Süreç İyileştirme Maddesi

================================================================================
RETRO ÖNERİSİ: "Sprint İçi Ara Teslim (Mid-Sprint Delivery) Kuralı"
================================================================================
Gözlem    : Bu sprintte geliştirme son güne kadar tek parça tutulduğu için test 
            süreci son 6 saate sıkışmış ve canlıya çıkış riske girmiştir.
Aksiyon   : Bir sonraki sprintten itibaren "Definition of Ready (DoR)" kuralı 
            olarak; büyüklüğü 3 Story Point üzerindeki işler dikey parçalara 
            (Vertical Slices) bölünecek ve en geç Sprintin 6. gününde ilk test 
            edilebilir paket QA ortamına teslim edilecektir.
================================================================================

4. “Bir de Şöyle Düşün” (Kutu İçeriği)

💡 Bir de Şöyle Düşün: Restoranda “Acısız Kebap” Siparişi

Bir restoranda müşterinin “Ben acısız Adana kebap istiyorum” dediğini düşün:

  • Yüzeysel Garson (Kötü Testçi): Mutfağa gider ve aşçıya “Adana kebap yap ama acısız olsun” der. Aşçı köfteyi hazırlar, acı pul biber koymaz ama yanına közlenmiş zehir gibi acı sivri biberleri doldurur. Müşteri o biberi yer ve fenalaşır.

  • Çevik Kalite Zihniyeti (Three Amigos): Garson masadayken müşteriye sorar: “Acısız istiyorsunuz ama tabağa közlenmiş acı biber koyalım mı? Ezme salatamız da acılıdır, onu da tatlı domatesle değiştirelim mi?”

Bütünsel kalite; sadece kullanıcının söylediği tek bir cümleye bakmak değil, o cümlenin tabağın geri kalanındaki tüm sosları ve garnitürleri nasıl etkileyeceğini görebilmektir.

5. Mini Alıştırma

Mülakat Sorusu: Çevik bir takımın mülakatında sana şu soru yöneltiliyor:

“Sprint içinde bir geliştirici ile bir gereksinimin yorumlanması konusunda tamamen zıt düştünüz. Geliştirici ‘Bu durum şartnamede yazmıyor, dolayısıyla ben bunu kodlamam, bilet geçmiştir’ diyor; sen ise bu durumun sistemi çökerteceğini biliyorsun. Bu teknik tıkanıklığı kırmanın en profesyonel yolu nedir?”

Bu soruya Çevik takım dinamiklerini kavramış bir mühendis olarak en fazla iki cümleyle nasıl yanıt verirsin?

“Geliştiriciyle ikili bir ego çatışmasına girmek yerine; senaryonun iş riskini ve kullanıcı deneyimine vereceği zararı somut verilerle özetleyerek Ürün Sahibini (Product Owner) masaya davet ederim. Nihai iş kuralı kararını PO ile birlikte ‘Three Amigos’ zihniyetiyle netleştirir, kararı kabul kriterlerine resmi olarak yazdırırım.”