İyi Bir Test Mühendisi Ne Zaman "Ben Bu İşi Bırakıyorum" Der?

Seri 1: Liderin Masası – Bölüm 2

Kariyeri boyunca iyi bir test mühendisiyle çalışmış olanlar bilir; onların ayrılışı genelde gürültülü olmaz. Büyük tartışmalar, kapı çarpmalar ya da masaya yumruk vurmalar yaşanmaz.

İyi bir testçi gitmeye karar verdiğinde önce biraz sessizleşir. Eskiden toplantılarda ardı arkası kesilmeyen o rahatsız edici sorular azalır. Kabul kriterlerindeki açıkları yakalayan o keskin merak yerini sıradan bir onay mekanizmasına bırakır. Ve bir gün masanıza o istifa maili düşer.

Yöneticiler genelde bu ayrılıkları maaşa, piyasa şartlarına ya da uzaktan çalışma imkanlarına bağlamayı tercih eder. Bunlar elbette etkendir; ancak iyi bir testçiyi içten içe tüketen asıl dinamikler çok daha derinde, sürecin görünmeyen çatlaklarında birikir.

Kapı Bekçisi Rolüne Sıkıştırılmak

Birçok organizasyon test mühendisliğini hâlâ üretim bandının sonundaki "son kontrol noktası" gibi görüyor. Analiz aşamasında fikri sorulmayan, mimari kararlar alınırken masaya çağrılmayan bir testçi düşünün. Kod yazılmış, sürenin sonuna gelinmiş, sprint bitmek üzere ve iş masaya bırakılıyor: "Savaş, akşama canlıya çıkıyoruz, hızlıca bir bakar mısın?"

Bu yaklaşım, mesleğini sadece butonlara basmak değil, bir kalite kültürü inşa etmek olarak gören bir mühendis için en büyük tükenmişlik kaynağıdır.

Sorumluluk dağ gibi üzerinize yıkılır; prod ortamında çıkacak en ufak sorunda ilk bakışlar size döner. Ama o sorumluluğu yönetecek yetki, zaman ve söz hakkı size asla verilmemiştir. Sadece hataları yakalayan bir "bekçi" muamelesi görmek, yaratıcı zekâyı zamanla köreltir.

Çöp Kutusu Sendromu: Kapanmayan ve Önemsenmeyen Hatalar

İyi bir test mühendisini işinden soğutan en sinsi şeylerden biri de açtığı bug'ların kaderidir.

Saatlerini verip derin bir edge-case yakalamışsınızdır. Sistemin belirli bir yük altında nasıl kararsızlaştığını adım adım dokümante etmiş, logları toplamış, analizini yapmışsınızdır. Sonra bir grooming ya da sprint planning toplantısında şu cümle duyulur:

"Bunu prod'da hangi kullanıcı yaşar ki? Won't Fix yapalım ya da backlog'un altına atalım, sonra bakarız."

Bu sahne birkaç kez tekrarlandığında test mühendisi şu mesajı alır: Senin titizliğin, bu ürün için bir değer değil, sadece süreci yavaşlatan bir pürüz.

Bir süre sonra insan ister istemez kendine sorar: "Kimsenin düzeltmeye niyetinin olmadığı bir hatayı bulmak için ben neden bu kadar kafa yoruyorum?" İşte şüphecilik refleksinin öldüğü an tam olarak burasıdır.

Kaliteyi Yalnız Başına Sırtlanmanın Ağırlığı

Yazılım dünyasında en zehirli yanılgılardan biri, kalitenin sadece test ekibinin zimmetinde olduğunu sanmaktır.

Geliştirici kendi yazdığı kodu temel seviyede dahi test etmeden doğrudan test ortamına atıyorsa, ürün yöneticisi sırf takvime yetişmek için eksik işleri içeri itiyorsa ve günün sonunda tüm defoları örtme görevi yalnızca testçinin omuzlarına kalıyorsa, o ekipte çatlama kaçınılmazdır.

Kalite kolektif bir sorumluluk olmaktan çıkıp tek bir kişinin vicdanına kaldığında, o vicdan bir süre sonra yorulur. Çünkü tek başınıza bir kültürü taşıyamazsınız; sadece ezilirsiniz.

Liderin Masasındaki İşaretler

Bir lider olarak ekibinizdeki iyi bir mühendisi kaybetmek istemiyorsanız metrik tablolarına değil, günlük çalışma dinamiklerine bakmanız gerekir:

• Toplantılarda "Böyle yaparsak sistem şurada patlayabilir" diyen o itiraz sesi kesildi mi?
• Açılan hata raporlarındaki detaylar, açıklamalar kısalmaya başladı mı?
• Eskiden süreçleri iyileştirmek için öneri getiren kişi, artık sadece verilen task'ı bitirip çekiliyor mu?

Bunlar yaklaşan vedanın ayak sesleridir.

İyi testçiler zor işten, yoğun sprintlerden ya da karmaşık mimarilerden kaçmaz. Onlar; seslerinin duyulmadığı, titizliklerinin "engelleme" olarak görüldüğü ve kaliteyi tek başlarına savunmaktan yoruldukları yerden sessizce çekip giderler.

Serinin üçüncü bölümünde, yazılım geliştirme süreçlerinin en kadim ve en hassas ilişkisine odaklanacağız: Developer ile testçi arasındaki o görünmez duvarı gerçekten kim örüyor?