QA CV'sinde Otomasyon ve Bug-Bounty Başarılarının Stratejik Anlatımı: ATS'nin "Test Yaptım" Diyen Satırları Neden Elemediğinin Anatomisi

"Test Yaptım" Cümlesi Neden Yetmiyor?

Bir yazılım test uzmanının CV'sine ilk bakıldığında gözler genelde iki yere gider: kullanılan araçlar listesi ve son işverenin adı. Bu iki bilgi gerçekten önemli olabilir ama tek başına durduklarında QA hakkında çok az şey anlatır. "Selenium kullandım", "JUnit yazdım", "üç yıldır test ediyorum" gibi cümleler, ATS'nin (ATS Nasıl Çalışır? Aday Takip Sisteminin Arkasındaki Mantık ve CV Hazırlığın Gerçek Kuralları" data-seo-auto-link="true">Aday Takip Sistemi) metin eşleştirmesinden geçer ama insan gözüne ulaştığında arkalarında bir kalite anlatısı yoktur. İşe alım yöneticisi bu satırları okuduğunda zihninde tek bir soru oluşur: "Bu kişi sadece test mi yaptı, yoksa kaliteyi mi şekillendirdi?"

İşte otomasyon ve bug-bounty başarıları tam burada devreye girer. Bunlar, bir QA'nın CV'sinde "test yaptım" cümlesini sessizce yükselten iki güçlü sinyaldir. Bir yanda tekrar eden regresyon süreçlerini otomatikleştirme disiplini, diğer yanda güvenlik açıklarını üretim öncesi yakalayan araştırmacı bakış açısı. Bu ikisi doğru hikâyeyle anlatıldığında, CV bir "test eden" profilinden "kaliteyi tasarlayan" profiline dönüşür.

Bu yazı, Cv hazırlama sürecinde bu iki sinyalin nasıl yazılacağını, ATS'nin nasıl okuduğunu ve insan gözüne nasıl ulaştığını katman katman ele alıyor.

ATS'nin QA CV'sinde Aslında Ne Gördüğü

ATS bir insan değil. Anahtar kelime eşleştirmesi yapar, bölüm başlıklarını tanır, geçmiş zaman sıralamasını kontrol eder ve bazı sistemlerde süresi dolmuş teknolojileri otomatik olarak düşük puanlar. Bir QA CV'si açısından bu durum iki kritik sonuç doğurur:

• Araç isimleri doğru ve güncel yazılmadığında CV, ilk filtreden geçemez. Örneğin "Selenium" yerine "selenyum", "Playwright" yerine "playwrite" gibi yazımlar basit bir Cv analiz sürecinde bile kayda değer puan kaybettirir.
• Başarılar ölçülebilir yazılmadığında ATS bunu fark etmez ama işe alım yöneticisi fark eder. Yani ATS'yi geçen ama insanı etkilemeyen bir CV hazırlamak mümkündür; bu, test uzmanları için en sık yapılan hatadır.

Bu yüzden QA CV'si yazarken iki kitle birden düşünülmeli: algoritma ve insan. Algoritma için anahtar kelime disiplini, insan için ise hikâye disiplini gerekir.

Otomasyon Becerilerini Stratejik Konumlandırmanın Üç Katmanı

Bir QA'nın CV'sinde otomasyon becerileri genelde tek bir paragrafa sıkıştırılır. Oysa bu beceri, kendi içinde üç farklı katmanda anlatılmayı hak eder: araç, yaklaşım ve etki. Bu üç katmanı ayrı ayrı düşünmek, Cv hazırlama sürecinde fark yaratan en küçük ama en etkili hamledir.

1. Katman: Araç

Bu katman ATS için yazılır. Selenium, Cypress, Playwright, Postman, JMeter, RestAssured, pytest, JUnit, TestNG gibi araç isimleri doğru biçimde, güncel hâlleriyle listelenmelidir. Burada iki noktaya dikkat etmek gerekir:

• Listeyi uzatmak değil, doğru sıralamak önemlidir. Günlük iş akışında kullanılan araçlar üstte, destekleyici olanlar altta yer almalıdır.
• Araç isimleri versiyonu ile birlikte düşünülmelidir. Örneğin sadece "Selenium" yazmak yerine "Selenium WebDriver (Java/Python)" biçiminde yazmak, hem ATS'nin hem insanın daha net eşleştirme yapmasını sağlar.

2. Katman: Yaklaşım

Bu katman insan gözü için yazılır. Hangi test türlerinde otomasyon yapıldığı, hangi metodolojinin izlendiği burada anlatılır. Örneğin:

• Smoke testlerinin her deploy sonrası otomatik koşturulması
• Regression suitinin gece çalıştırılıp sabah raporlanması
• API kontrat testlerinin CI/CD hattına entegre edilmesi
• Veri odaklı testlerde parametrik yaklaşımın kullanılması

Bu tür cümleler, QA'nın testi bir görev olarak değil, bir sistem olarak gördüğünü gösterir. Cv analiz araçları bunu doğrudan puanlamaz ama işe alım yöneticisinin zihninde oluşan izlenimi belirler.

3. Katman: Etki

Bu katman CV'yi diğer adayların önüne geçirir. Otomasyon sonucunda regresyon süresinin kısaldığını, kritik bugların daha erken yakalandığını, manuel test yükünün azaldığını somut cümlelerle anlatmak şarttır. Burada "iyileştirme sağladım" gibi belirsiz ifadeler yerine, mümkün olan en kısa biçimde neyin değiştiğini yazmak gerekir. Ölçü sayısı uydurmadan, gerçek bir etkiyi tek cümleyle ifade etmek yeterlidir.

ATS anahtar kelimeyi arar, insan etkiyi arar. QA CV'si ancak ikisini aynı anda yakaladığında işe yarar.

Bug-Bounty Başarılarını CV'ye Taşımanın Kuralları

Bug-bounty deneyimi, bir QA için altın değerinde bir sestir. Ancak bu sesi CV'ye taşımak, otomasyon kadar hassas bir dengenin korunmasını gerektirir. Çünkü burada gizlilik, doğruluk ve etik sınırlar bir arada bulunur.

Kural 1: Şirketlerin NSD (Non-Disclosure) Sözleşmelerine Sadık Kal

Bug-bounty programlarının büyük çoğunluğu, kabul edilen zafiyetlerin nerede, nasıl ve hangi detayla paylaşılabileceğini açıkça belirtir. CV'de "XYZ şirketinde X kritik bug buldum" gibi cümleler yazmak, hem etik hem hukuki açıdan sorun yaratabilir. Bunun yerine anonimleştirilmiş veya genelleştirilmiş bir anlatım tercih edilmelidir: "Finans sektöründe faaliyet gösteren bir e-ticaret platformunda kimlik doğrulama katmanında zafiyet tespiti" gibi.

Kural 2: Platform Adını ve Seviyesini Görünür Kıl

HackerOne, Bugcrowd, Intigriti gibi platformlarda alınan ödüller ve seviyeler, CV'de somut bir güven sinyalidir. "HackerOne üzerinden X rapor kabul edildi, Y tanınırlık seviyesine ulaşıldı" biçiminde yazılan bir satır, ATS'nin güvenlik anahtar kelimeleriyle eşleşir ve insan gözünde net bir yetkinlik sinyali oluşturur.

Kural 3: Zafiyet Türünü Genel Olarak Yaz, Detayı Bağlantıya Bırak

CV'de zafiyet açıklamasının tamamını vermek hem yer kaplar hem de yanlış ellere geçebilecek bilgi anlamına gelebilir. Bunun yerine OWASP kategorilerine atıfta bulunmak daha sağlıklıdır: "IDOR, XSS ve broken access control kategorilerinde kabul edilmiş raporlar" gibi. Detaylı teknik açıklama, özel bir blog yazısında veya GitHub üzerindeki özgeçmiş ekinde paylaşılabilir.

Kural 4: Etik Çerçeveyi Görünür Kıl

Bir QA'nın en büyük farkı, zafiyet bulmak değil, bulduğu zafiyeti sorumlu biçimde raporlamasıdır. CV'de "responsible disclosure prensiplerine uygun şekilde raporlama" ifadesi, bu etik çerçeveyi görünür kılar ve güvenlik bilinci olan bir aday olduğunu net biçimde ortaya koyar.

QA CV'sinde "Test Ettim" Yerine Ne Yazılır?

Bu soru, çoğu QA'nın CV'sinde açıkça görülen zayıf halkadır. Aynı işi yapan iki adaydan biri "Test senaryoları yazdım ve koştum" yazarken, diğeri aynı işi farklı kelimelerle anlatır. İkinci aday, Cv hazırlama sürecinde dil bilincini göstermiş olur. Birkaç dönüşüm örneği:

• Test senaryosu yazdım yerine: "Kullanıcı kabul kriterlerine dayalı, uçtan uca kapsayan senaryolar tasarladım."
• Bug raporladım yerine: "Üretim öncesi ve sonrasında kök neden analizi ile birlikte bug raporları hazırladım."
• Selenium kullandım yerine: "Selenium WebDriver ile veri odaklı regresyon süiti geliştirdim ve CI hattına entegre ettim."
• Manuel test yaptım yerine: "Keşif testleri ile otomasyonun kaçırdığı senaryoları yakaladım."

Bu küçük dil değişiklikleri, Cv analiz araçlarında aynı anahtar kelimeleri yakalarken, insan gözünde daha yetkin bir profil çizer.

Ölçülebilir Başarı: Test Kapsamı, Süre Azalması, Yakalanma Oranı

QA'nın yaptığı işin somut etkisini göstermek için üç kategori son derece işlevseldir:

• Test kapsamı: Otomasyonun ulaştığı modül veya ekran sayısı, kapsanan API endpoint sayısı.
• Süre azalması: Regresyon süitinin manuel koşmasıyla otomatik koşması arasındaki fark, deploy sonrası smoke testin hızlanması.
• Yakalama oranı: Otomasyonun üretim öncesi yakaladığı bug sayısı, escape olan bugların azalma eğilimi.

Bu üçlüden herhangi biri için somut bir sayı varsa, CV'de tek cümleyle yazılabilir. Sayı yoksa, sayı uydurmadan etkiyi betimlemek daha dürüst bir yaklaşımdır. Örneğin: "Regresyon süresini otomasyon sonrası birkaç güne yayılan bir döngüden, her deploy sonrası dakikalar içinde tamamlanan bir sürece taşıdım." Bu cümle sayı vermeden aynı etkiyi yaratır.

ATS'nin QA CV'sinde Aradığı Sinyaller

Bir Cv analiz sürecinde ATS'nin özellikle dikkat ettiği kalıplar şunlardır:

• Bölüm başlıklarının standart olması: "Deneyim", "Eğitim", "Beceriler", "Sertifikalar" gibi başlıklar ATS'nin doğru alanlara eşleştirme yapmasını kolaylaştırır.
• Tarih formatının tutarlı olması: "Ocak 2022 - Haziran 2024" gibi tek biçim ATS'nin süre hesaplamasını kolaylaştırır.
• Teknik terimlerin doğru yazılması: "Java" ile "JAVA", "CI/CD" ile "CI CD" arasındaki küçük farklar eşleşmeyi bozabilir.
• Özgeçmişin tek sütunlu veya ATS dostu iki sütunlu bir tasarımda olması.

Bu sinyaller tek başına iş garantisi değildir ama ilk filtrede elenme riskini ortadan kaldırır.

Sık Yapılan Hatalar: QA'ların CV'sini Sessizce Zayıflatan Alışkanlıklar

Test uzmanlarının CV'sinde tekrar eden birkaç zayıf nokta vardır. Bunlar fark edilmeden yapılır ama toplamda CV'nin etkisini ciddi biçimde düşürür.

Hata 1: Araç Listesinin Hikâyeden Önde Olması

Bazı QA CV'leri, en üstte dev bir araç listesiyle başlar. Bu liste ATS'yi besler ama insan gözüne bir şey anlatmaz. Aslında olması gereken, önce ne yapıldığını anlatan kısa bir özet, sonra araçların bu özeti nasıl mümkün kıldığını gösteren bir bağlamdır.

Hata 2: Bug-Bounty Başarılarının "Hobi" Gibi Yazılması

Bazı adaylar, bug-bounty deneyimlerini CV'nin en altına "Hobiler" bölümüne sıkıştırır. Oysa bu deneyim, doğru yazıldığında "Sertifikalar" veya "Ek projeler" bölümünde yer almayı hak eder. Çünkü bu çalışmalar çoğu zaman gerçek bir kullanıcı kitlesini etkileyen sistemlerde gerçekleşmiştir.

Hata 3: Otomasyon ve Manuel Testin Ayrılmadan Yazılması

İkisi farklı beceri setleridir. Manuel test gözlem ve keşif yeteneği gerektirir, otomasyon ise mühendislik disiplini. Bunları aynı paragrafta eritmek, ikisinin de etkisini zayıflatır. Ayrı bölümler hâlinde yazıldığında, her birinin ağırlığı daha belirgin olur.

Hata 4: Şirket İçi Jargonlarla Dolu Cümleler

"Story puanı tamamladım", "sprint'e katıldım", "daily'e girdim" gibi cümleler, ne yaptığınızı değil nerede çalıştığınızı anlatır. Bunlar Cv hazırlama sürecinde zaman kazandırır gibi görünür ama gerçekte etkisiz satırlardır. Bunun yerine, o süreçte somut olarak ne ürettiğinizi yazmak gerekir.

Cv Bedava Platformlarında QA CV'si Hazırlarken Dikkat Edilecek Noktalar

Ücretsiz CV oluşturma araçları, hızlı ve düzenli bir başlangıç için gerçekten işe yarar. Özellikle Cv bedava seçenekleri sunan platformlar, ATS uyumlu şablonlarıyla ilk filtrede elenme riskini azaltır. Ancak bu platformlarda hazırlanan bir QA CV'sinin güçlü kalabilmesi için birkaç noktaya dikkat etmek gereklidir:

• Hazır şablonların bölüm başlıklarını değiştirmemek, çünkü ATS bu standart başlıklara göre eşleştirme yapar.
• Teknik beceriler bölümünü serbest metin olarak değil, etiket veya liste biçiminde doldurmak.
• Hazır şablonun sınırladığı alanlarda bile her bir aracın yanına kullanım seviyesini belirten kısa bir ifade eklemek.

Bu küçük dokunuşlar, ücretsiz bir şablonun profesyonel bir CV'ye dönüşmesini sağlar.

QA Anlatısının Görünmeyen Katmanı: Kalite Kültürü

Bir QA'nın CV'sinde en güçlü anlatı, bazen tek bir cümlede gizlidir: "Testi yapan kişi değil, kalite kültürünü şekillendiren kişi." Bu cümle bir slogan değil, bir duruştur. Bunu yansıtmak için CV'nin tamamında küçük ipuçları bulunmalıdır.

• Test stratejisi dokümanları yazdıysa, bu CV'de bir satır olarak görünmelidir.
• Yeni geliştiricilere test yaklaşımı konusunda mentorluk yaptıysa, bu "mentorlük" kelimesiyle ifade edilmelidir.
• Bug triage sürecinde aktif rol aldıysa, bunu sadece "bug takibi yaptım" değil, "önceliklendirme ve kök neden analizi süreçlerine katkı sağladım" biçiminde yazmak gereklidir.

Bu tür satırlar, ATS'de anahtar kelime olarak görünmese de insan gözünde çok belirgin bir kalite sinyali oluşturur.

Sertifikaların CV'deki Yeri: CTFL, CTAL ve Güvenlik Sertifikaları

QA CV'lerinde sıklıkla unutulan bir bölüm, sertifikalardır. ISTQB CTFL veya CTAL, güvenlik tarafında CEH, CompTIA Security+ veya OSCP gibi sertifikalar, ATS'de anahtar kelime olarak yakalanır ve CV'nin güvenilirliğini artırır. Ancak burada da dikkat edilmesi gereken bir nüans vardır: sertifika isimleri tam ve doğru yazılmalıdır. Kısaltmaları yanlış yazmak, Cv analiz araçlarının eşleştirme yapamamasına neden olur.

Sertifikalar, "Deneyim" bölümünden ayrı olarak listelendiğinde hem ATS hem insan için daha okunabilir bir yapı oluşur.

CV'de Güç Sıralaması: En Üstte Ne Görünmeli?

Bir QA'nın CV'sinin ilk üçte biri, okuyucunun kararını büyük ölçüde belirler. Bu alanda şu sıralama genelde iyi sonuç verir:

1. Kısa özet: İki veya üç cümlede kim olduğu, kaç yıllık deneyimi olduğu, hangi alanlarda uzmanlaştığı.
2. Temel teknik beceriler: Araç ve teknoloji listesi.
3. Öne çıkan başarılar: Otomasyon veya bug-bounty kaynaklı, somut etki içeren iki-üç kısa madde.
4. İş deneyimi: Ters kronolojik sıra ile detaylı anlatım.

Bu yapı, ATS'nin ilk taramasında anahtar kelimeleri yakalamasını sağlarken, insan okuyucuya da hızlı bir özet sunar.

Bug-Bounty'yi İş Deneyiminden Ayrı Tutmalı mıyım?

Kısa cevap: evet. Bug-bounty çalışmaları genelde bağımsız, harici ve belirli bir zaman dilimine yayılmayan faaliyetlerdir. İş deneyimi içine serpiştirildiğinde kronolojik akış bozulur. Bunun yerine "Açık Kaynak ve Güvenlik Çalışmaları" veya "Bağımsız Güvenlik Araştırmaları" gibi ayrı bir bölüm açmak, hem ATS'nin hem insan okuyucunun daha rahat gezinmesini sağlar.

Bu bölümde platform adı, varsa tanınırlık seviyesi, OWASP kategorilerine göre zafiyet türleri ve toplam rapor sayısı gibi bilgiler nebilir. Detaylar için bir blog bağlantısı veya GitHub reposu bağlantısı eklemek, ATS dostu bir Cv hazırlama pratiği olarak kabul edilir.

İki Profili Tek CV'de Birleştirmek: Full-Stack QA Anlatısı

Son yıllarda test uzmanları yalnızca manuel ya da yalnızca otomasyon tarafında değil, performans testleri, güvenlik testleri, API testleri ve hatta CI/CD mühendisliği gibi birden fazla alanda çalışıyor. Bu genişlemiş profil, CV'de "QA" başlığı altında tek bir paragrafta anlatılmaya çalışıldığında boğulur. Bunun yerine becerileri katmanlara ayırmak gerekir:

• Fonksiyonel test: Manuel, keşif, kullanıcı kabul testi.
• Otomasyon: UI otomasyonu, API otomasyonu, veri odaklı testler.
• Performans: Yük testi, stres testi, dayanıklılık testi.
• Güvenlik: OWASP Top 10 odağında zafiyet testleri, bug-bounty deneyimi.

Bu katmanlı anlatı, ATS'nin ilgili anahtar kelimeleri eşleştirmesini kolaylaştırır ve insan okuyucuya QA'nın sadece "test eden" değil, kaliteyi uçtan uca şekillendiren biri olduğunu gösterir.

Sonuç: QA CV'sinin Gerçek Gücü "Test Yaptım" Cümlesinin Ötesindedir

Bir yazılım test uzmanının CV'si, otomasyon disiplini ve bug-bounty sorumluluğu bir araya geldiğinde tamamen farklı bir hikâye anlatır. Bu hikâye, ATS'nin anahtar kelimelerini yakaladığı ama insan gözünün etkilendiği, dengeli bir anlatıdır.

Bu denge için Cv hazırlama sürecinde üç ilke hatırlanmalıdır:

• Teknik gerçeklik: Kullanılmayan bir aracı yazmak, mülakatta çözülür ve güven sarsar.
• Ölçülebilir etki: Sayı uydurmadan, somut bir değişimi tek cümleyle ifade etmek yeterlidir.
• Etik çerçeve: Özellikle bug-bounty söz konusu olduğunda, gizlilik ve sorumlu ifşa ilkelerine bağlılık mutlaka görünür olmalıdır.

Bu üç ilkeyle hazırlanan bir QA CV'si, ne kadar sade olursa olsun, otomasyonun mühendislik tarafını ve güvenliğin araştırmacı tarafını bir araya getiren güçlü bir anlatıya dönüşür. ATS'nin ilk filtresinden geçer, insan okuyucunun zihninde kalıcı bir iz bırakır ve sonuçta QA'nın sadece test eden değil, kaliteyi tasarlayan biri olduğunu sessizce ortaya koyar.