8.3. Adım Adım Metodoloji: Çevik Ritüellerde QA Duruşu, İletişim ve Kariyer Mimarisi
Çevik bir yazılım ekibine katıldığında günlerin yalnızca monitöre bakıp buton tıklayarak geçmez. Test mühendisi, kod yazılmadan önceki analiz masasından yazılımın canlıya çıktığı ana kadar ekibin pusulasıdır.
Bunu başarmak için Scrum törenlerinde doğru duruşu sergilemeli, yapıcı bir mühendislik dili kurmalı ve kariyer basamaklarını nereye tırmandığını bilerek adımlamalısın.
8.3.1. Çevik Ritüellerde (Scrum Ceremonies) QA Duruşu
Bir sprint boyunca katıldığın her toplantının spesifik bir kalite amacı vardır:
+----------------------------------------------------------------------------------------------------+
| ÇEVİK (AGILE) TEST YAŞAM ALANI |
+----------------------+-----------------------------------------------------------------------------+
| TOPLANTI | SENİN MASADAKİ ASIL MÜHENDİSLİK GÖREVİN |
+----------------------+-----------------------------------------------------------------------------+
| 1. REFINEMENT | "Üç Amigo" masası: Kabul kriterlerini zorla, eksik senaryoları koda dökül- |
| (İş Arıtma) | meden önce yakala. |
+----------------------+-----------------------------------------------------------------------------+
| 2. SPRINT PLANNING | İşi sadece yazılımcının geliştirme süresine göre değil; test, veri hazırlığı|
| (Planlama) | ve otomasyon eforunu da katarak puanla (Story Point). |
+----------------------+-----------------------------------------------------------------------------+
| 3. DAILY STANDUP | Dün ne yaptığını ezbere saymak yerine; riskleri, ortam arızalarını ve |
| (Günlük Ayaküstü) | önündeki blokajları ekibe bildir. |
+----------------------+-----------------------------------------------------------------------------+
| 4. SPRINT REVIEW | Canlı demoda ürünün yalnızca "çalıştığını" değil; kullanıcıya ve işe kattığı|
| (Demo / İnceleme) | değeri, sınır koşullardaki sağlamlığını paydaşlara göster. |
+----------------------+-----------------------------------------------------------------------------+
| 5. RETROSPECTIVE | Canlıya kaçan hataları kişileri suçlamadan masaya yatır; süreçteki hangi |
| (Geriye Bakış) | denetim adımının yetersiz kaldığını çöz ve kültürü iyileştir. |
+----------------------+-----------------------------------------------------------------------------+
Adım 1: “Üç Amigo” (Three Amigos) ile Hatayı Doğmadan Yok Etmek
Kodlama başlamadan önce üç farklı zihnin aynı masa etrafında toplanması gerekir:
-
Ürün Sahibi / Analist (PO): “Hangi iş problemini çözüyoruz, kullanıcıya faydası ne?”
-
Yazılım Geliştirici (Dev): “Bunu teknik olarak hangi mimariyle, hangi veritabanı tablosuyla çözeriz?”
-
Test Mühendisi (Sen): “Bu mantık nerede kırılır? Kullanıcı interneti koparırsa, eksi sayı girerse ne olur? Neyi unuttuk?”
Bu toplantıda amacın hata aramak değil, karanlık noktaları aydınlatmaktır. Geliştirici kod yazmaya başlamadan ona şu soruyu sorarsın:
“Ahmet, sepet tutarı 0 TL olduğunda veya indirim kodu iki kez girildiğinde sistemin ne yapacağını kurallara yazmamışız. Ben test ederken bu sınır durumları mutlaka deneyeceğim. Kodunu kurgularken bu ihtimalleri gözetirsen benden tek seferde geçer.”
Bu 2 dakikalık diyalog, sprint sonundaki 3 günlük yeniden kodlama ve hata ayıklama krizini tamamen ortadan kaldırır.
Adım 2: Daily Standup Toplantılarında Doğru Durum Bildirimi
Her sabah yapılan 15 dakikalık ayaküstü toplantılarda çiçeği burnunda mühendislerin düştüğü klasik tuzak:
❌ “Dün 102 numaralı bileti test ettim. Bugün 103’e bakacağım. Önümde bir engel yok.”
Bu bildirim mekaniktir ve ekibe hiçbir değer katmaz. Yetkin bir kalite mühendisi risk, ortam durumu ve iş hizalanmasıyla konuşur:
“Dün sepet entegrasyonunun sınır değer senaryolarını tamamladım; 4 adet kritik hata yakaladık ve geliştirici Mehmet ile kök nedenini izole ettik. Bugün adres doğrulama servisini test edeceğim; ancak test ortamındaki SMS onay servisi kararsız yanıt veriyor. Eğer öğlene kadar bu servis düzelmezse ödeme testlerim riske girecek, DevOps ekibinden destek bekliyorum.”
Aradaki fark; şeffaflık, risk öngörüsü ve proaktif mühendislik duruşudur.
8.3.2. İletişimde “Biz” Dili ve Psikolojik Güvenlik İnşası
Test mühendisi ile yazılımcı arasındaki ilişki, doğası gereği gerilime açıktır. Çünkü testçi, geliştiricinin günlerce emek verdiği “dijital çocuğunun” kusurlarını bulmakla görevlidir. Bu gerilimi saygı ve verimliliğe dönüştürmek kullandığın iletişim diline bağlıdır:
| Yıkıcı / Suçlayıcı Dil (Amatör) | Yapıcı / Mühendislik Dili (Profesyonel) | Neden Bu Dili Seçiyoruz? (Bilişsel Etki) |
| ❌ “Kodun patlamış, yine veri kontrolü (validation) eklemeyi unutmuşsun.” | “Sistem, form boş gönderildiğinde beklenen uyarı mesajını üretmiyor; kullanıcı akışı kesintiye uğruyor.” | Suçlama doğrudan kişiye değil; sisteme ve gözlemlenen olguya yönelir. Geliştiricinin savunma kalkanı açılmaz. |
| ❌ “Analiz dokümanı çok yetersiz, hiçbir şey anlaşılmıyor.” | “Kullanıcı oturumunun zaman aşımına uğradığı durum analizde açıkta kalmış; bu senaryoyu netleştirebilir miyiz?” | Genel şikâyet yerine doğrudan çözülmesi gereken somut analitik boşluğu işaret eder. |
| ❌ “Bu hatayı acilen düzeltmen lazım, benim onayım olmadan canlıya çıkamazsın!” | “Bu açık canlıya taşınırsa kullanıcı bakiyelerinde çift çekim riski doğabilir; şirketi korumak adına bunu bu sprinte dahil etmeliyiz.” | Egomanyak bir bekçi otoritesi yerine; iş değerini, müşteri deneyimini ve şirket riskini merkeze koyar. |
8.3.3. Kariyer Mimarisi ve “T-Shaped” Mühendislik Vizyonu
Yazılım kalitesi dünyasında kariyer basamakları 3 aşamalı bir piramit üzerinde yükselir:
/ \
/ \ [ 3. KATMAN: MİMARİ & LİDERLİK ]
/ 3 \ Test Stratejisi, Şirket Kültürü, Metriklerle Yönetim
/-------\
/ 2 \ [ 2. KATMAN: MÜHENDİSLİK DERİNLİĞİ (SDET) ]
/ \ Test Otomasyonu, API/Performans/Güvenlik, CI/CD, Kodlama
/-------------\
/ 1 \ [ 1. KATMAN: TEMEL & DOMAIN BİLGİSİ (QA FOUNDATION) ]
/ \ Analitik Zihniyet, ISTQB Standartları, Kusur Yönetimi, Çevik İletişim
+-------------------+
-
Temel Katman (QA Foundation – Şu An Bulunduğun Yer): Analitik şüphecilik, iş kurallarını uç sınırlarda kırma kabiliyeti, ISTQB terminolojisi, Jira hata disiplini ve çevik takım iletişimi. Bu zemin olmadan üzerine otomasyon inşa edilemez.
-
Mühendislik Derinliği (SDET Transition): Software Development Engineer in Test (Test Odaklı Yazılım Geliştirici) katmanıdır. Kodlama dilleri (Java, Python, TypeScript), web servisleri (API), tarayıcı otomasyon çatıları (Selenium, Playwright, Cypress) ve otomatik montaj hatları (CI/CD).
-
Mimari ve Stratejik Liderlik (Mastery & QA Architecture): Şirket çapında test maliyetlerini düşürme, kalite kapılarını kurma, yapay zekâ test araçlarını sürece entegre etme ve ekipleri yönetme sanatı.
[ YATAY ÇİZGİ: Geniş Alan & İletişim ]
(İş Mantığı, Agile Kültür, Analiz, Takım İletişimi, Domain)
<=========================================================>
|
| [ DİKEY BACAK: Teknik Derinlik ]
| (API Testi, Kodlama,
| Otomasyon, CI/CD,
| Performans & Güvenlik)
v
Sen bir “T-Shaped” (T-Tipi) Mühendis olacaksın:
Yatay eksende geniş bir sektör, ürün ve iletişim vizyonuna sahip olurken; dikey eksende adım adım inşa edeceğin derin teknik yetkinliklerle fark yaratacaksın.
4. “Bir de Şöyle Düşün” (Kutu İçeriği)
💡 Bir de Şöyle Düşün: Uçaktaki Yardımcı Pilot
Kokpitteki test mühendisi, uçağın kaptan pilotunu sürekli azarlayan bir müfettiş değildir:
Kötü İletişim: Uçak türbülansa girdiğinde pilota dönüp “Yine irtifayı kaybettin, uçmayı bilmiyorsun” diye bağırmaktır. Bu yaklaşım pilotun elini titretir ve uçağı tehlikeye atar.
Mühendislik İletişimi: Göstergeye sakince bakar ve şunu söyler: “Kaptan, radar 10 mil ileride şiddetli dolu fırtınası gösteriyor; rotayı 5 derece güneye kırmayı öneriyorum.”
Yazılımcı kodu yazan kaptan pilottur; sen ise fırtınayı, yakıt durumunu ve kör noktaları önceden görerek uçağın sağ salim piste inmesini sağlayan radar operatörü ve yardımcı pilotsun. Hedefiniz ortak: Yolcuları (müşterileri) güvenle hedefe ulaştırmak.
5. Mini Alıştırma
Senaryo: İki haftalık sprintin ortasındasınız. Geliştirici arkadaşın, canlıya çıkacak yeni sepet özelliğinde kullanıcının kredi kartı son kullanma tarihini 00/00 girdiğinde sistemin bunu kabul ettiğini gösteren biletine çok sinirleniyor ve Slack genel kanalına şunu yazıyor:
“Kimse kartına 00/00 yazmaz, gerçek kullanıcılar aptal değil! Boş yere bilet açıp benim sprint puanımı ve vaktimi harcıyorsun!”
Soru: Çevik iletişim protokolünü ve “Biz” dilini kavramış bir test mühendisi olarak, gerilimi tırmandırmadan hem sistemi koruyacak hem de profesyonel sınırları çizecek en yapıcı yanıt ne olmalıdır?
“Haklısın, bilinçli hiçbir müşteri bilerek 00/00 girmez. Ancak kullanıcılar klavyede yanlışlıkla çift sıfıra basabilir veya kötü niyetli botlar sistemi geçersiz kart numaralarıyla manipüle etmeye çalışabilir. Bu durumda banka sanal POS’undan gereksiz yere ret yanıtı alıp işlem maliyeti ödememek ve sepet terk oranını artırmamak adına bu doğrulamayı ekranda tutmamız şirketimizi koruyacaktır. İstersen gereksinimi PO ile 2 dakika netleştirelim.”