Performans Test Mühendisi: Görevleri, Araçları ve Kariyer Yolu

Performans test mühendisi kimdir?

Performans test mühendisi, bir yazılımın gerçek kullanım koşullarında ne kadar hızlı, kararlı ve ölçeklenebilir davrandığını ölçen kişidir. Fonksiyonel test "düğme çalışıyor mu" sorusuna bakar; performans testi ise "çok sayıda kullanıcı aynı anda aynı düğmeye bastığında sistem hâlâ makul sürede yanıt veriyor mu" sorusuna. Rol, iş ilanlarında yük testi uzmanı, performans test uzmanı ya da performance test engineer adlarıyla da geçer.

Rolün asıl çıktısı bir test aracı raporu değildir. Çıktı şu bilgidir: sistem hangi yükte bozulmaya başlıyor, sınırı hangi bileşen çiziyor ve bunu gevşetmek için neye dokunulmalı. Bu yüzden rol hem test tasarımı hem de sistem mimarisini okuma becerisi ister; mühendis yalnızca isteği gönderen kişi değil, yanıtın neden yavaş geldiğini çözümleyen kişidir.

Bir iş gününde ne yapar?

Örneğin bir e-ticaret şirketi büyük bir indirim kampanyası öncesinde sepet ve ödeme akışının dayanıklılığını görmek istiyor. Performans test mühendisi bu talebi şu işlere çevirir:

• Hedefleri netleştirir: kampanya sırasında beklenen eşzamanlı kullanıcı, kabul edilebilir yanıt süresi ve izin verilen hata düzeyi iş birimiyle birlikte yazıya dökülür.
• Yük profilini çıkarır: gerçek trafik kayıtlarına bakarak kullanıcıların hangi sayfalara hangi oranda gittiğini, ürün arama, sepete ekleme ve ödeme adımlarının ağırlığını belirler.
• Senaryoyu yazar: oturum açma, çerez ve token yönetimi, değişken test verisi ve kullanıcı bekleme süreleri (think time) senaryoya eklenir.
• Ortamı doğrular: test ortamının canlıya ne kadar benzediğini, veri hacmini ve önbellek durumunu kontrol eder.
• Testi koşar ve izler: yük kademeli artırılırken uygulama sunucusu, veritabanı ve ağ metrikleri aynı anda gözlenir.
• Sonucu yorumlar: yavaşlamanın başladığı noktayı bulur, geliştirici ve altyapı ekibiyle birlikte kök nedeni arar (yavaş bir sorgu, bağlantı havuzunun dolması, bellek baskısı gibi).
• Raporlar: yönetime "kampanyaya hazır mıyız" sorusunun yanıtını, teknik ekibe ise somut aksiyon listesini verir.

Düzeltmeler yapıldıktan sonra aynı senaryo yeniden koşulur; karşılaştırmanın anlamlı olması için senaryo ve ortam sabit tutulur.

Hangi test türlerini yönetir?

Performans testi tek bir test değildir; her tür farklı bir soruyu yanıtlar:

• Yük testi: beklenen normal ve yoğun kullanımda sistemin hedeflere uyup uymadığını gösterir.
• Stres testi: yükü sistemin sınırının ötesine taşıyarak nerede ve nasıl bozulduğunu, bozulduktan sonra toparlanıp toparlanmadığını ölçer.
• Ani artış (spike) testi: kampanya başlangıcı ya da bildirim gönderimi gibi trafiğin bir anda sıçradığı durumları taklit eder.
• Dayanıklılık (soak) testi: uzun süre orta düzey yük altında bellek sızıntısı, bağlantı birikimi ve disk dolması gibi yavaş gelişen sorunları arar.
• Kapasite testi: iş büyümesine göre kaç sunucu, ne kadar veritabanı kaynağı gerektiğini hesaplamak için veri üretir.

Sonuçlar ortalama değerle değil, dağılımla okunur. Ortalama yanıt süresi iyi görünürken yüzdelik dilimlerde (örneğin kullanıcıların en yavaş karşılaşılan kesimi) yanıt çok uzayabilir. Mühendis ayrıca saniyedeki istek sayısını (throughput), hata oranını ve işlemci, bellek, disk, ağ kullanımını birlikte okur.

Hangi araç ve becerilere ihtiyaç duyar?

Araç tarafında yaygın olanlar Apache JMeter ve JavaScript ile senaryo yazılan k6'dır; Gatling gibi kod tabanlı araçlar da kullanılır. Araç seçimi ekibin diline ve süreçlerine bağlıdır: görsel arayüzle hızlı başlamak isteyen ekip JMeter'e, test senaryolarını kod deposunda sürümleyip CI/CD hattında koşturmak isteyen ekip k6 gibi araçlara yönelebilir. Sonuçları görmek için Grafana ve Prometheus gibi izleme araçları, uygulama performans izleme (APM) çözümleri ve log analizi araçlarıyla çalışılır.

Araçtan daha kalıcı olan beceriler şunlardır:

• HTTP, oturum, önbellek, yük dengeleyici ve veritabanı bağlantı havuzu gibi temel mimari kavramlar
• SQL ve sorgu planı okuyabilme
• Temel istatistik: ortalama, medyan, yüzdelik dilim, standart sapma
• Linux komut satırı, konteyner ve bulut ortamında kaynak izleme
• Bulguyu yöneticiye ve geliştiriciye ayrı ayrı anlatabilme

Sık yapılan hatalar ve nasıl önlenir?

Performans testlerinin en pahalı hatası, güven veren ama yanıltıcı bir sonuç üretmektir. Sık görülen durumlar şunlardır:

• Canlıya benzemeyen ortam: küçük veritabanı, ısınmış önbellek ya da farklı yapılandırma gerçek sınırları gizler. Veri hacmi ve yapılandırma farkı rapora açıkça yazılmalıdır.
• Yük üreten makinenin darboğaz olması: test aracının kendisi işlemci ya da ağ sınırına dayanırsa ölçülen yavaşlık uygulamaya ait değildir. Yük üreticilerin kaynak kullanımı da izlenmelidir.
• Bekleme süresi koymamak: gerçek kullanıcı sayfalar arasında düşünür. Hiç beklemeyen sanal kullanıcı gerçek kullanıcıdan çok daha ağır bir yük üretir.
• Tek bir veriyle çalışmak: her sanal kullanıcı aynı ürünü aradığında önbellek sonucu şişirir. Parametrik ve çeşitli veri kullanılmalıdır.
• Yalnızca ortalamaya bakmak: yavaş kuyruk gözden kaçar.
• Hedefsiz test: kabul ölçütü baştan yazılmamışsa sonuç "iyi mi kötü mü" sorusuna cevap veremez.

Performans test mühendisi nasıl olunur?

Rolün tek bir zorunlu diploması yoktur; bilgisayar, yazılım ya da endüstri mühendisliği geçmişi yaygındır ama çoğu kişi komşu rollerden geçer. Giriş yolları genelde şunlardır: manuel ya da otomasyon testçisi olarak çalışırken yük testine açılmak, backend geliştirici olup kendi servislerinin performansıyla ilgilenmek, DevOps ya da altyapı tarafından gelip izleme ve kapasite deneyimini testlere taşımak.

Öğrenme sırası olarak şu akış işe yarar: önce web uygulamasının nasıl çalıştığını (istek, yanıt, oturum, veritabanı) kavramak; sonra tek bir araçta basit bir yük senaryosu yazmak; ardından sonucu izleme araçlarıyla birlikte okumak; en son da testi CI/CD hattına bağlayıp düzenli koşturmak. Kişisel bir demo servisi ayağa kaldırıp kasıtlı olarak yavaş bir sorgu eklemek ve testin bunu yakaladığını göstermek, işe başvururken somut bir kanıttır.

Yakın rollerden farkı nedir?

Test mühendisi ya da kalite güvence uzmanı işlevsel doğruluğa odaklanır; performans test mühendisi aynı doğru işlevin yük altındaki davranışına odaklanır. Bazı ekiplerde ikisi aynı kişidir, büyük ekiplerde ayrı uzmanlıktır. Site güvenilirliği mühendisi (SRE) canlı sistemin sürekliliğini işletir; performans test mühendisi ise sistem canlıya çıkmadan ya da değişiklik yapılmadan önce sınırı ölçer. Performans mühendisi (performance engineer) ise yalnızca ölçmekle kalmayıp kod ve mimari düzeyinde iyileştirme de yapar; birçok kurumda bu başlıklar iç içe kullanılır.

Mindset programlarında bu rol nerede çalışılır?

Mindset kataloğunda bu rolün çalışma alanına doğrudan oturan programlar var. Performance Testing (JMeter, k6) programı performans testi kavramlarından JMeter ile test tasarımına, k6 ile modern yaklaşıma ve sonuç analizinden kapasite planlamasına uzanır; test ve kalite ekibinde çalışanlar için uygundur. Backend Performans Testi ve Kapasite Modelleme programı ise performans hedefleri ve yük profili, test türleri ve yürütme, darboğaz teşhisi, kapasite modelleme ve otomasyon başlıklarıyla backend geliştirme ve altyapı ekiplerine yöneliktir. Kurumsal ekipler, kampanya ya da sürüm öncesi performans doğrulamasını standart bir süreç haline getirmek için bu programları birlikte düşünebilir.