8.2. Sektördeki Gerçek Senaryo: İki Haftalık Sprint Çıkmazı ve “Bize Test İçin Vakit Kalmadı!” Krizi

Avrupa pazarına hizmet veren bir dijital bankacılık ekibinde kalite mühendisi olduğunu düşün. Şirket, Scrum yöntemini uyguluyor ve işleri iki haftalık çalışma döngüleri (Sprint) halinde planlayarak canlıya alıyor.

Bu iki haftalık sprintin büyük hedefi ise şu: Kullanıcıların IBAN numarasıyla uğraşmadan, yalnızca cep telefonu numarasını girerek saniyeler içinde 7/24 anında mikro-kredi çekebilmesi.

Ekipteki işleyiş kağıt üzerinde “Agile” görünse de, perde arkasında şöyle bir takvim işletiliyor:

  • Sprintin 1. ile 7. Günleri: Ürün Sahibi (Product Owner – PO) ve yazılımcılar ekran tasarımlarını konuşuyor, veritabanını kuruyor, arka yüz (Backend) ve arayüz (Frontend) kodlarını yazıyor.

  • Test Mühendisinin Sessizliği: Bu süreçte test uzmanı Caner, şirket panosundaki (Jira) biletlerin “Geliştiriliyor (In Development)” sütununda durmasını kenardan izliyor ve içinden şunu geçiriyor: “İşler henüz yazılımcılarda, kodlama bitsin bana gelsin, sonra test ederim.”

  • Sprintin 9. Günü (Bitişe Son 24 Saat): Yazılımcılar yazdıkları kod parçalarını birleştirip test ortamına (Staging) yüklüyor ve biletin durumunu gururla güncelliyor: Ready for QA (Test Edilmeye Hazır!)

Son 6 Çalışma Saati ve Patlayan Saatli Bombalar

Sprintin kapanmasına ve pazarlama ekibinin reklamları yayına almasına yalnızca saatler var. Caner’in önünde ise devasa bir kredi onay algoritması, kimlik doğrulama adımları ve para transferi akışı duruyor.

Test etmek için kalan toplam süre: Yalnızca 6 çalışma saati!

Caner klavyenin başına geçip sistemi kurcalamaya başladığı ilk 30 dakikada şunları keşfediyor:

  1. Kullanıcı başvuru formunda doğum tarihini boş bırakıp “İlerle” dediğinde uygulama aniden kapanıyor (Crash).

  2. Kredi faiz hesaplama motorunda, kuruş basamakları aşağı yuvarlanacağına yukarı yuvarlanıyor ve faiz tablosu müşteri sözleşmesiyle uyuşmuyor.

  3. En ölümcülü: İnternetin hafif zayıf olduğu bir anda “Krediyi Onayla” butonuna peş peşe basıldığında; sistem aynı kullanıcıya mikro saniyeler içinde iki ayrı kredi tanımlayıp hesaba iki kat para aktarıyor!

Caner panikle Jira panosunda art arda kırmızı alarmlar açıyor:

❌ “Kritik hatalar var! Kredi motoru çift para veriyor, bu özellik bu gece asla yayına çıkamaz!”

Ofiste anında sinirler geriliyor.

  • Yazılımcılar savunma kalkanlarını kaldırıyor: “Sprint bitiyor Caner, bunları söylemek için 9 gün boyunca neredeydin? Bize küçük bir form dediler, çift tıklama kuralını analiz dokümanına kimse yazmamıştı!”

  • Ürün Yöneticisi araya giriyor: “Canlıya çıkış lansmanını genel müdürlüğe duyurduk, bu tarihi erteleyemeyiz. Yamalık bir şeyler atıp bu gece bu paketi canlıya alacaksınız!”

Sonuç: Ekip gece saat 03:00’e kadar ofiste kalarak birbirini suçluyor; aceleyle atılan yamalı kodlarla canlıya çıkılıyor ve iki gün sonra yüzlerce müşterinin hesabında limit aşımı kaosu patlak veriyor.

Kök Neden Analizi: Hata Kimdeydi?

İlk bakışta suçlu, işi son güne bırakan Caner ya da eksik analiz yazan Ürün Yöneticisi gibi görünebilir. Oysa bu krizin arkasında sektörü kasıp kavuran kronik bir hastalık yatar: Sprint İçi Şelale Tuzağı (Mini-Waterfall).

[ SPINT İÇİ ŞELALE TUZAĞI (MINI-WATERFALL) ]
Gün 1-7 : Analiz ve Kodlama (Testçi Beklemede...)
Gün 8-9 : Büyük Kod Birleştirmesi
Gün 10  : [TEST SIKIŞMASI VE PANİK!] ---> Gece Yarısı Krizi

[ GERÇEK ÇEVİK (AGILE) VE SHIFT-LEFT AKIŞI ]
Hikâye Küçük Parçalara Bölünür (Dikey Dilimleme):
Parça 1 (Form): Kodlandı [Test Edildi] |
Parça 2 (Faiz): Kodlandı [Test Edildi] | -> Sürekli, Sakin ve Güvenli Çıkış
Parça 3 (Onay): Kodlandı [Test Edildi] |

Bu ekip Scrum yaptığını iddia ediyordu; ancak geleneksel Şelale modelinin o hantal “kodla, bekle, en son duvara çarp” mantığını sadece 10 güne sıkıştırmışlardı.

Eğer Caner ve ekibi gerçek bir Agile Kalite Kültürü ile hareket etseydi ne olurdu?

  1. Gereksinim Arıtma (Refinement) Masasında (1. Gün): Caner masaya oturup henüz tek satır kod yazılmadan soracaktı: “Kullanıcı bu butona sabırsızca iki kez basarsa ne yapacağız? Kuruş yuvarlama kuralımız BDDK mevzuatına göre aşağı mı yukarı mı yuvarlanmalı?” Bu sorularla hatalar henüz kodlanmadan yok edilecekti.

  2. Dikey Dilimleme (Vertical Slicing): Yazılımcılar koca sistemi 9. güne kadar tek bir devasa paket olarak tutmayacak; ilk 3 günde önce sadece kredi formunu test edilebilir küçük bir parça halinde Caner’e verecek, test ve geliştirme el ele yürüyecekti.

Test mühendisi, sprintin son vagonuna binip imdat frenini çeken yolcu değildir; lokomotifin rotasını makinistlerle birlikte baştan çizen kılavuz kaptandır.

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

💡 Bir de Şöyle Düşün: Düğün Pastası Fırından Çıkınca Tuzluysa…

Büyük bir düğün pastası hazırlayan bir mutfak ekibini hayal et:

  • Mini-Waterfall Yaklaşımı: Şefler 9 saat boyunca mutfağa kapanır, 5 katlı devasa pastayı krema ve süslerle tamamlar. Düğüne 15 dakika kala pastayı tadımcıya (testçiye) uzatırlar. Tadımcı pastayı ağzına alır ve dehşetle haykırır: “Şeker yerine tuz koymuşsunuz, bu pasta yenmez!” O saatten sonra o koca pastayı çöpe atmaktan ve rezil olmaktan başka çare yoktur.

  • Agile Yaklaşımı (Shift-Left): Tadımcı mutfağa un ve yumurta çırpılırken girer. Hamur fırına girmeden önce parmağının ucuyla kremanın tadına bakar; “Şefim, şeker yerine tuz kavanozunu açmışsınız” der. Sorun henüz 2. dakikada, fırın bile ısınmadan, tek kuruş ziyan olmadan 5 saniyede çözülür.

Testin maliyeti ve stresi; ürüne ne kadar geç dokunduğunla doğru orantılı olarak katlanarak büyür.

5. Mini Alıştırma

Senaryo: Yeni bir sprint planlama toplantısındasın. Yazılımcı arkadaşın Jira’daki “Sepete Ekle Butonu ve Stok Düşme Akışı” başlıklı büyük bir geliştirme kartını işaret ederek şöyle diyor:

“Ben bu özelliğin tüm veritabanını, arka plan servislerini ve ekranını tek başıma kodlayıp sprintin son günü sana teslim edeceğim; sen de son gün hepsini birden topluca test edersin.”

Soru: Sprint İçi Şelale (Mini-Waterfall) tuzağını bilen bir Çevik Test Mühendisi olarak, işin son gün kilitlenmesini önlemek adına bu geliştiriciye hangi somut çalışma modelini (işi nasıl bölmeyi) önerirsin?

Örnek Çözüm:

İşi sprintin son gününe kadar tek parça halinde tutmak yerine, küçük ve bağımsız test edilebilir dikey dilimlere (Vertical Slices / alt görevlere) bölmeyi öneririm:

  1. Dilim: Önce sadece butonun arayüzü ve sepete ekleme mantığı tamamlansın, ben bunu test ederken;

  2. Dilim: Arka plandaki stoktan düşme ve hata kontrolü mantığı kodlansın.

    Böylece test ve kodlama paralel yürür; hatalar son gün topluca patlamak yerine gün gün eritilir.

ÖncekiSonraki