Test Mühendisliğinde Mentorluk: Tecrübeden Öğrenmenin Gücü

Paylaş
Test Mühendisliğinde Mentorluk: Tecrübeden Öğrenmenin Gücü
Photo by Desola Lanre-Ologun / Unsplash

Yazılım testinde bilgi çoğu zaman dokümante edilmez. Öğretilmez de. Daha çok aktarılır. Bir bakışta, bir yorumda, bir toplantıda söylenen tek bir cümlede ya da bir hatanın neden “böyle” ele alındığını anlatan kısa bir sohbette ortaya çıkar. Bu yüzden test mühendisliğinde mentorluk, resmi bir süreçten çok, zamanla oluşan bir öğrenme ilişkisi olarak var olur.

Yeni başlayan bir test mühendisi için test teknikleri öğrenilebilir, araçlar kavranabilir, süreçler ezberlenebilir. Ancak testçilik dediğimiz şeyin asıl zor kısmı bunlar değildir. Asıl zor olan; neyin önemli olduğunu ayırt edebilmek, hangi sorunun sorulmaya değer olduğunu sezebilmek ve belirsizlik karşısında panik yerine düşünmeyi seçebilmektir. İşte bu noktada mentorluk devreye girer.

Mentorluk, bilgiyi hızlandırmaz; bakış açısını derinleştirir.


Mentorluk Bilgi Aktarmak Değil, Düşünme Biçimi Kazandırmaktır

Test mühendisliğinde mentorluk çoğu zaman yanlış anlaşılır. Birçok kişi mentorluğu, “bildiğini anlatan kişi” olarak görür. Oysa gerçek mentorluk, hazır cevaplar vermekten çok, doğru soruların nasıl sorulacağını göstermektir.

Bir mentor şunu yapmaz:

  • “Bunu şöyle test et” diye direktif vermez.
  • “Doğrusu budur” diyerek noktayı koymaz.
  • Karşısındakini kendi kopyasına dönüştürmeye çalışmaz.

Bunun yerine şunu yapar:

  • “Burada sence risk nerede?” diye sorar.
  • “Bu senaryoyu neden böyle düşündün?” diye dinler.
  • “Başka nasıl bozulabilirdi?” diye zihni açar.

Mentorluk, teknik bilginin ötesinde, karar verme kasını geliştirir.


Testte Tecrübe, Yıllarla Değil Tekrar Eden Hatalarla Oluşur

Test mühendisliğinde tecrübe, kaç yıl çalışıldığıyla doğrudan orantılı değildir. Aynı hatayı beş yıl boyunca yapan biri, hâlâ acemidir. Aynı hatayı bir kez yapıp nedenini anlayan kişi ise hızla olgunlaşır.

Mentorluk bu noktada kritik rol oynar çünkü çoğu hata, tek başına fark edilemez. Bir test mühendisi bir senaryoyu eksik düşündüğünü, ancak başka biri bunu ona gösterdiğinde fark eder. İşte mentor, bu farkındalığı sağlayan kişidir.

Burada önemli olan hata göstermek değil, hatanın düşünsel kökenini açmaktır. “Burayı atlamışsın” demek öğretmez. “Bu alanı neden gözden kaçırdın?” sorusu öğretir.


Mentorluk Resmi Olmak Zorunda Değildir

Mentorluk çoğu zaman resmi programlarla, eşleşmelerle, takvimlere konan görüşmelerle tanımlanır. Bunlar faydalı olabilir ama zorunlu değildir. Test ekiplerinde en etkili mentorluk çoğu zaman gayriresmidir.

  • Bir test senaryosu üzerinden yapılan kısa bir sohbet
  • Bir hatanın neden geç fark edildiğinin konuşulması
  • Bir refinement toplantısından sonra yapılan beş dakikalık değerlendirme
  • “Bunu neden böyle düşündüğünü merak ettim” diye başlayan bir diyalog

Bu anlar, resmi mentorluk oturumlarından çok daha öğreticidir çünkü gerçek bağlamın içindedir.

Mentorluk planlanabilir ama dayatılamaz.


Mentor Olmak Üstünlük Değil Sorumluluktur

Test ekiplerinde deneyimli kişilerin en sık düştüğü tuzaklardan biri, bilgiyi güç olarak görmektir. Bilgiyi saklamak, paylaşımı geciktirmek ya da “zamanım yok” diyerek kapıyı kapatmak kısa vadede konfor sağlar ama uzun vadede ekibi zayıflatır.

Mentor olmak, her şeyi bilmek demek değildir. Bilmediğini açıkça söyleyebilmek, birlikte düşünmeyi teklif edebilmek ve karşısındakinin gelişimine alan açabilmektir.

Gerçek mentorlar:

  • Bilgiyi tekelleştirmez
  • Sürekli konuşmaz, dinler
  • Yanılabileceğini kabul eder
  • Öğrenmenin çift yönlü olduğunu bilir

Mentorluk tek taraflı bir aktarım değil, karşılıklı bir gelişim ilişkisidir.


Mentor–Mentee İlişkisinde Güven Belirleyicidir

Mentorluk ancak güven varsa işler. Güven yoksa mentee soru sormaz, risk paylaşmaz, eksiklerini gizler. Bu da öğrenmeyi durdurur.

Güvenin oluşması için:

  • Yargılayıcı dil kullanılmamalı
  • Kıyas yapılmamalı
  • “Ben olsam” cümleleri dikkatli seçilmeli
  • Öğrenme süreci bir yarış gibi sunulmamalı

Test mühendisliği zaten yeterince belirsizlik içerir. Mentorluk bu belirsizliği artırmamalı, yönetilebilir hale getirmelidir.


Mentorluk Kültürü Olan Ekipler Neden Daha Dayanıklıdır?

Mentorluk kültürü gelişmiş ekiplerde bilgi kişilere değil, ekibe aittir. Bu da şu sonuçları doğurur:

  • Bir kişi ayrıldığında sistem çökmez
  • Yeni gelenler daha hızlı adapte olur
  • Aynı hatalar tekrar tekrar yapılmaz
  • Ekip içi iletişim daha açıktır
  • Sorumluluk paylaşımı doğallaşır

Bu ekiplerde kalite bireysel kahramanlıklara değil, kolektif farkındalığa dayanır.


Mentorluk Sadece Yeni Başlayanlar İçin Değildir

Yaygın bir yanlış algı da mentorluğun sadece junior’lar için gerekli olduğu düşüncesidir. Oysa deneyimli test mühendisleri de mentorluğa ihtiyaç duyar. Çünkü teknoloji değişir, ürünler değişir, beklentiler değişir.

Deneyimli kişiler için mentorluk:

  • Kör noktaları fark etmeyi
  • Alışkanlıkları sorgulamayı
  • “Bunu hep böyle yapıyorduk” tuzağından çıkmayı sağlar.

Mentorluk tek yönlü değildir.

Herkesin öğrenecek bir şeyi vardır.


Sonuç

Test mühendisliğinde mentorluk, hızlı sonuç üretmez ama kalıcı etki bırakır. Bir kişiyi değil, bir düşünme biçimini geliştirir. Araçlar değişir, süreçler evrilir, teknolojiler eskir; fakat iyi bir mentorun kazandırdığı bakış açısı kalır.

Test ekipleri büyümek istiyorsa sadece otomasyon yatırımı yapmamalı, sadece süreç iyileştirmemeli; bilginin nasıl aktarıldığını, tecrübenin nasıl paylaşıldığını ve öğrenmenin nasıl teşvik edildiğini de düşünmelidir.

Çünkü testte gerçek ustalık, bildiklerini anlatmakta değil; başkalarının düşünmesini sağlayabilmektedir.

Devamını oku

Balıkta Beklemek ile Bug Aramak Arasındaki O İnce Çizgi: Sabır

Balıkta Beklemek ile Bug Aramak Arasındaki O İnce Çizgi: Sabır

Seri 3: Testçinin Zihni – Bölüm 1 Sabahın çok erken saatlerinde, henüz gün ağarmadan bir kıyıda ya da kayalıkların üstünde durduysanız bilirsiniz; deniz size hemen cevap vermez. Takımı hazırlarsınız, sahteyi iğneye takarsınız, mesafeyi ayarlayıp atışı yaparsınız. Sonra sararsınız. Bir kez daha, bir kez daha... Dakikalar geçer, rüzgâr yön değiştirir, suyun akıntısı

Savaş Avcu tarafından
Prod’a Çıkış Gecesi Yaşananlar: En Kusursuz Plan Neden Patlar?

Prod’a Çıkış Gecesi Yaşananlar: En Kusursuz Plan Neden Patlar?

Seri 2: Sahadan Hatalar – Bölüm 3 Saat gece yarısını geçmiş. Teams kanalında veya toplantı odasında gergin ama aynı zamanda işi bitirmiş olmanın getirdiği yorgun bir rahatlama var. Tüm feature branch’ler birleştirilmiş, staging ortamında regression testleri başarıyla tamamlanmış, checklist’teki maddelerin yanına tek tek yeşil tikler atılmış. "Deployment Plan&

Savaş Avcu tarafından
Test Verisi Çöplüğü: Bir Ekip Kendi Yarattığı Veride Nasıl Boğulur?

Test Verisi Çöplüğü: Bir Ekip Kendi Yarattığı Veride Nasıl Boğulur?

Seri 2: Sahadan Hatalar – Bölüm 2 Yazılım geliştirme süreçlerinde çoğu zaman kodun kendisine, mimariye veya pipeline konfigürasyonlarına odaklanılır. Ancak bir test mühendisinin günlük mesaisini en çok tüketen, sabrını en çok sınayan gizli bir canavar vardır: Test verisi. Bir gün test ortamında koştuğumuz kritik bir ödeme akışının sürekli patladığını gördük. Kod

Savaş Avcu tarafından