Developer ile Testçi Arasındaki Görünmez Duvarı Kim Örüyor?

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

Yazılım takımlarında adı konmamış bir gerilim vardır. Bazen bir Teams mesajının tonunda, bazen bir PR incelemesinde, bazen de sprint sonuna sıkışan bir test döngüsünde kendini hissettirir.

Dışarıdan bakıldığında aynı hedefe koşan, aynı ürünü ayağa kaldırmaya çalışan iki disiplin: Geliştirici ve test mühendisi. Ama masaya oturduğunuzda, aralarında aşılması güç, şeffaf ama çok kalın bir duvarın varlığını fark edersiniz.

Genelde faturayı kişisel uyuşmazlıklara ya da "testçinin işi bozmak, developer’ın işi yapmak" gibi yüzeysel ezberlere kesmek kolayımıza gelir. Oysa sahadaki tecrübe bana şunu gösterdi: Bu duvarı insanlar kendi keyiflerinden örmüyor; organizasyonların kurguladığı yanlış teşvikler ve kültürel körlükler adım adım inşa ediyor.

Çatışan Hedefler: Hız ile Şüphe Arasında Sıkışmak

Bir düşünün; bir yazılım geliştirici çoğu şirkette neye göre takdir edilir?

• Story point’leri ne kadar hızlı erittiğine,
• Task’ları ne kadar çabuk "Test" sütununa taşıdığına,
• Sprint takvimine ne kadar sadık kaldığına.

Peki test mühendisinin odağı nedir?

• Sistemin nerelerde aksayabileceğini görmek,
• Varsayımları sorgulamak,
• Olası riskleri büyümeden yakalamak. Yani doğası gereği süreci biraz yavaşlatmak, derinleşmek ve düşünmek.

Siz bir tarafa "hızlı koş" derken, diğer tarafa "etrafı çok dikkatli incele" derseniz, bu iki insanın birbirine çarpması kaçınılmazdır. Testçinin bulduğu her geçerli açık, developer’ın gözünde takvimi aksatan, onu hedeflerinden uzaklaştıran bir engele dönüşür.

Ekipleri birbirine rakip hale getiren ilk harç işte burada karılır: Kaliteyi ortak bir başarı değil, bir tarafın diğerini yakaladığı bir "denetim" mekanizması olarak konumlandırmak.

“Benim Lokalimde Çalışıyordu” Savunması Neyi Anlatır?

Bir hata bildirildiğinde geliştiricinin verdiği ilk refleks çoğunlukla teknik değil, duygusaldır. Kod, geliştiricinin zihninde inşa ettiği bir yapıdır; oraya emek verir, üzerine düşünür. Bir testçinin gelip "Bu senaryoda sistem patlıyor" demesi, olgunlaşmamış bir iletişim ortamında kişisel bir eleştiri gibi algılanabilir.

Buradaki kırılma, testçinin hatayı nasıl ifade ettiğiyle doğrudan ilgilidir.

Eğer testçi hatayı "Bak yine burayı eksik yapmışsın" edasıyla, adeta bir açık yakalama zaferi gibi masaya koyuyorsa o duvar bir tuğla daha yükselir. Fakat yaklaşım, "Kullanıcı şöyle bir akış denediğinde servis beklenmedik bir cevap dönüyor, gel loglara birlikte bakalım" olduğunda, odak kişiden çıkıp ürüne kayar.

İletişimin dilini teknik bir analizden çıkarıp ego savaşına döndürdüğümüz an, ekip ruhu yerini savunma mekanizmalarına bırakır.

Duvarı Yıkmak: Birlikte Tasarlamak, Birlikte Sınamak

Peki bu duvar nasıl ortadan kalkar? Yıllar içinde gördüğüm en etkili reçete, testçiyi sürecin "sonundaki kontrolör" olmaktan çıkarıp "başındaki düşünce ortağı" haline getirmektir.

Geliştirici henüz kodu yazmaya başlamadan önce, test mühendisiyle kabul kriterlerini ve potansiyel riskleri konuşuyorsa; yani testçi akla gelmeyen uç durumları kod yazılmadan masaya getiriyorsa gerilim baştan söner. Çünkü o zaman testçi hata bulan değil, hatanın oluşmasını engelleyen bir partnere dönüşür.

Hatta bir adım ötesi: Unit ve entegrasyon testlerinin kurgusunda birlikte kafa yoran, birbirinin bakış açısını anlayan bir yapı kurabilmektir. Developer testçinin neden öyle düşündüğünü kavradığında, testçi de geliştiricinin mimari kısıtlarını anladığında o görünmez duvar kendiliğinden erir.

Liderin Aynası

Eğer bir ekibin stand-up toplantılarında developer ile testçi birbirine soru sormuyorsa, sorunlar sadece Jira kartlarının altındaki soğuk yorumlarda tartışılıyorsa, orada bir yönetim problemi var demektir.

Bir liderin görevi, testçiyi geliştiricinin ensesindeki bir polis memuru, geliştiriciyi de sadece yetiştirmesi gereken işleri olan bir kod üreticisi gibi konumlandırmamaktır.

Kalite, birinin diğerini denetlemesiyle değil; iki tarafın da ortaya çıkan işe aynı sorumlulukla ve aynı sahiplikle bakmasıyla yeşerir. Duvarı yıkan şey araçlar veya süreçler değil, aynı masada yan yana oturup bir soruna birlikte şaşırabilme olgunluğudur.

Serinin son bölümünde konuyu yine liderin masasında çok sık açılan bir diğer başlıkla toparlayacağız: Bug raporu bir eleştiri değil, bir teşekkür olabilir mi?