Yazılım Test Uzmanı CV Şablonu: Hata Avcılığından Kalite Stratejisine, Bir Testçinin Özgeçmişinde Delil Odaklı Anlatı Kurgusu

Test uzmanının özgeçmişi neden standart bir şablona sığmaz?

Sahada, yazılım geliştirme ekiplerinde herkesin işi görünür: geliştirici commit'leri, mimari kararları, DevOps pipeline'ı, ürün yöneticisinin backlog'u. Test uzmanının emeği ise çoğu zaman "yokluğuyla" tanınır; nitelikli çalışan bir üründe testçinin katkısı. Kullanıcının fark etmediği sessiz bir başarıdır. İşte bu yüzden birCv şablonuPratikte, arayışı, test profesyonelleri için diğer teknik rollerden daha farklı bir problem yaratır.

Net konuşmak gerekirse, hazır şablonlar size "X şirketinde Y projesinde Z teknolojisi kullanıldı" formatında boş alanlar sunar. Ne var ki test uzmanının asıl değeri, hangi teknolojiyi kullandığı değil; nasıl düşündüğüdür. Çoğu durumda, bir testçi, geliştiricinin "burada bir edge case var mı?" sorusunu sormadan önce zihninde on başka senaryo kurar. Bu düşünce yapısınıCvŞöyle ki, 'ye aktarmak, klasik bir "sorumluluk listesi" yazmaktan çok daha ince bir iştir.

Bu yazı, manuel test becerilerinden otomasyon mühendisliğine. API testinden performans senaryolarına kadar uzanan geniş yelpazeyi tek bir tutarlı anlatıda nasıl toplayacağınızı anlatıyor. Gaye, sizi "Selenium bilen birisi" olmaktan çıkarıp "ürün kalitesini savunan. İşin aslı, riski önceden tespit eden bir mühendis" olarak konumlandırmak.

Hata defterini stratejik bir anlatıya çevirmek

Test uzmanlarının doğal anlatı birimi "bug"dur. Kısaca, çoğu özgeçmiş bu birimi isabetsiz kullanır: "X kadar bug buldu" gibi ifadeler ya övünme gibi durur ya da abartılı rakamlar yüzünden sorgulanır. Oysa bir bug, aslında bir gözlem, bir hipotez ve bir çözüm önerisi içeren sınırlı bir vaka dosyasıdır. Özgeçmişte bunu nasıl çervelediğiniz, sizin hakkınızda her şeyi anlatır.

Hata kaydınızı anlatırken üç katmanı gözetin:

• Gözlem: Net, tekrarlanabilir ve bağlamsal bir senaryo. Pratikte, "Ödeme ekranında 3D Secure doğrulaması başarısız olduğunda hata mesajı İngilizce kalıyordu" gibi.
• Etki: Bu hata hangi kullanıcı kitlesini, hangi iş sürecini etkiliyordu. Sadece "kritik" yazmak yerine somut iş etkisini tarif edin.
• Çözüm yaklaşımı: Geliştiriciye nasıl yönlendirdiniz, regresyonu nasıl doğruladınız, hangi test case'leri güncellediniz.

Somut olarak, bu üç katmanı özgeçmişin deneyim bölümünde tek bir cümleye sıkıştırabilirsiniz. İşe alım uzmanı, sizin teknik bilgiden çok düşünce kalıbınızı okuyacaktır. Açıkçası, "300 bug buldu" diyen bir adaydan çok, "ödeme akışında sessiz kalan hata mesajlarını İngilizce-Türkçe yerelleştirme açısından yakaladı ve bunu geliştiriciyle birlikte çözerek müşteri şikayetlerini azalttı" diyen bir aday. Çok daha akılda kalıcı olur.

Manuel test becerilerini görünür kılmak

"Manuel test biliyorum" cümlesi, ne yazık ki hiçbir şey ifade etmez. Herkes manuel test yapar; asıl soru, hangi derinlikte ve hangi sistemde yaptığınızdır. Manuel test becerinizi yazarken, aşağıdaki dört ekseni ayrı ayrı değerlendirin:

Test tasarımı yetkinliği

Equivalence partitioning, boundary value analysis. Decision tables, state transition, pairwise testing gibi teknikleri bilmek, sizi rastgele tıklayan birinden ayırır. Özgeçmişinizde bu teknikleri proje bağlamında kullanıldığı şekliyle anlatın. Mesela "10 farklı ülke için vergi hesaplama akışlarında decision table yöntemiyle 45 test case tasarladım" gibi somut bir cümle. "test senaryoları yazdım" ifadesinden kat kat güçlüdür.

Keşif testi (Exploratory testing) yaklaşımı

Şöyle ki, önceden yazılmış hamle adım testler yerine, charter bazlı keşif testi yürüten birisi misiniz? Bu, hem yaratıcılığınızı hem de ürünü çabuk öğrenme kapasitenizi kanıtlar. "Taze özellik lansmanlarında 90 dakikalık keşif oturumları düzenleyerek, dokümantasyon dışı senaryolarda bug tespit ettim" gibi bir cümle. Test ekibininize olan katkınızı netleştirir.

İş Birliği ve İletişim

Bir noktada, manuel testin en ciddi kısmı aslında insanlarla konuşmaktır. Ürün yöneticisiyle edge case'leri netleştirmek. Geliştiriciyle hata üzerinde birlikte debug yapmak, müşteri destek ekibinden gelen şikayetleri kalıplara dönüştürmek. Kısaca, bu becerilerinizi "cross-functional communication" gibi jargona kaçmadan, günlük iş diliyle yazın.

Alan Bilgisi

Şöyle ki, e-ticaret, fintech, sağlık, oyun sektörü, her alanın kendi riskleri ve düzenleyici gereksinimleri vardır. PCI-DSS, KVKK, HIPAA gibi regülasyonlar, test uzmanının göz ardı edemeyeceği çerçeveler yaratır. Sektör bilginizi özgeçmişte bağlamsal olarak vurgulayın.

Otomasyon becerilerini net çerçevelemek

"Selenium, Cypress, Playwright biliyorum" diye sıralanan bir yetenek listesi artık hiçbir şey ifade etmiyor. Somut olarak, işe alım uzmanı sormadan önce sizin otomasyonu nasıl konumlandırdığınızı anlamak istiyor: Smoke test mi yazıyorsunuz. Regression mu, yoksa full E2E mi? Test piramidinin neresinde duruyorsunuz?

Test piramidindeki yeriniz

Birim testi seviyesinde geliştiriciyle birlikte mi çalışıyorsunuz, entegrasyon testlerini mi sahipleniyorsunuz, yoksa kullanıcı akışlarını mı otomatize ediyorsunuz? Bu üç katmanın hepsi değerlidir ama farklı yetkinlikler gerektirir. Özgeçmişinizde hangi katmanda yoğunlaştığınızı açıkça vurgulayın.

Framework tasarımı mı, framework kullanımı mı?

Mevcut bir framework'le script yazmak başka şey. Sıfırdan page object model kurmak, test data yönetimi eklemek, paralel çalıştırma mimarisi tasarlamak başka şey. "Selenium ile 200 test yazdım" yazan bir adayla "Page Object Model tabanlı. Paralel çalışan ve JSON test data kullanan bir framework kurdum" yazan aday. Teknik seviyede aynı havuzda bile değildir. Siz hangisisiniz?

CI/CD Entegrasyonu

Somut olarak, yazdığınız testler her gece mi çalışıyor, her PR'da mı tetikleniyor? Hangi CI aracında, hangi raporlama araçlarıyla entegre? Sahada, jenkins, GitHub Actions, GitLab CI, Azure DevOps gibi araçlarda deneyiminiz varsa, bunu bağlamıyla birlikte yazın. "Jenkins'te pipeline kurdum" değil, "GitHub Actions'da her PR'da smoke test çalışacak şekilde pipeline kurdum. Allure raporlarıyla sonuçları ekip kanalına otomatik gönderdim" şeklinde.

Araç ekosistemi: teknoloji yığınını özgeçmişte dengelemek

Test uzmanının kullandığı araçlar, geliştiricinin kullandığı araçlardan daha geniş bir yelpazeye yayılır. Bug tracking, test yönetimi, API testi, performans testi, gözlemlenebilirlik. Özgeçmişte bunları mantıklı gruplara ayırmak kayda değer.

Bir öneri olarak yetenek listenizi şu gruplarla düzenleyin:

• Test Yönetimi: TestRail, Zephyr, qTest, Xray, PractiTest
• Bug Tracking & Proje Yönetimi: JIRA, Azure DevOps, YouTrack, Linear
• Kısaca, aPI Testi: Postman, Insomnia, RestAssured, SoapUI, Karate DSL
• UI Otomasyon: Selenium WebDriver, Cypress, Playwright, WebdriverIO
• Mobil Test: Appium, XCUITest, Espresso, Detox
• Performans: JMeter, Gatling, k6, Locust
• Gözlemlenebilirlik: Kibana, Grafana, Sentry, Datadog

Her aracı aynı detayda yazmak yerine, o araçla ne yaptığınızı yazın. "Postman kullandım" ile "Microservices tabanlı ödeme servisinde 300+ endpoint için Postman collection hazırladım. Contract test olarak CI'a entegre ettim" arasında devasa bir ayrım var.

Test metriklerini uydurmadan sayısallaştırmak

Net konuşmak gerekirse, "Uydurma istatistik eklemeyin" diye başlayan bir cümle garip duruyor ama özgeçmişlerde tam da bu yapılıyor. Gerçekçi olmayan "test coverage %95'e çıkardım" veya "1500 bug kapattım" gibi ifadeler, mülakatta sorgulandığında çöker. Bunun yerine, metriklerinizi akış ve kalıpla ilişkilendirin.

Şu türden metrikler, abartıya kaçmadan yazılabilir:

• Güncel feature için ortalama test hazırlık süreniz
• Sprint başına yazdığınız test case sayısı (ekip ortalamasıyla karşılaştırılabilir)
• Keşif testi oturumlarında tespit edilen bug oranı
• Net konuşmak gerekirse, otomasyon regression süresini manuel regresyona göre ne kadar kısalttığınız
• Taze ekip üyesinin test süreçlerine adaptasyonu için hazırladığınız onboarding dokümanları

Eğer gerçekten somut bir sayı varsa. Somut olarak, söz gelimi regression suite'inin çalışma süresini 8 saatten 45 dakikaya indirdiyseniz, bu sayıyı tercih edin. Ama uydurmadan.

Sertifikalar ve sürekli öğrenme bölümü

Yazılım test dünyasında sertifikaların ağırlığı diğer rollerden biraz farklıdır. Aslına bakılırsa, ıSTQB sertifikasyon programı, sektörde fiili bir standart haline gelmiştir. Foundation Level, Agile Tester Extension, Test Manager gibi seviyeler, bilhassa Avrupa'da ve ciddi kurumsal şirketlerde ciddiye alınır.

Sertifikaları özgeçmişe koyarken şu nüanslara dikkat edin:

• Sahada, foundation Level tek başına yeterli değil, üzerine ne eklediğiniz daha belirleyici
• CTFL, CTAL-TM, CTAL-TA gibi kodları doğru yazın (sınav veren bunları bilir)
• Çoğu durumda, üniversite veya bootcamp sertifikalarıyla karışmayacak şekilde ayrı bir bölümde tutun
• Alınma tarihini kesinlikle yazın; 2015'te alınmış bir sertifika, 2024'te alınmışla aynı tazelikte değildir

Sertifika dışında, konferans katılımları, blog yazıları, açık kaynak katkıları da "sürekli öğrenme" sinyali verir. Bunları "Hobiler" bölümüne değil, "Mesleki Gelişim" gibi bir başlık altında toplayın.

ATS uyumlu yapısal kurgu

İşin aslı, çoğu büyük şirket başvuruları ATS (Applicant Tracking System) üzerinden alır. Test uzmanı özgeçmişleri için ATS uyumu hem teknik bir gereklilik hem bir mesajdır: "Sistemleri anlıyorum. Test edilebilir bir özgeçmiş yazıyorum." İşte ironi tam burada, sizin cv'niz de bir test objesidir.

Dosya formatı ve isimlendirme

Gerçekte, pDF tercih edin ama görsel değil, metin tabanlı PDF olduğundan emin olun. ATS birçok tasarımı düz metne dönüştüremiyor. Dosya adını "Ad_Soyad_Test_Uzmanı_CV_2025.pdf" gibi açık ve standart bir formatta tutun.

Anahtar kelime yerleşimi

Kısaca, iş ilanında geçen "test automation", "API testing", "Agile" gibi terimleri özgeçmişinizde doğal cümleler içinde tercih edin. Anahtar kelime doldurma taktiği bugün artık ATS'ler tarafından ayrım ediliyor. "Selenium, Selenium, Selenium, Selenium" yazan bir özgeçmiş. "Selenium WebDriver ile Java tabanlı Page Object Model framework'ü kurdum" yazan özgeçmişten daha düşük puan alır.

Bölüm Başlıkları

ATS'ler bölüm başlıklarını belirli kelimelerle arar. "Experience" yerine "İş Deneyimi" ya da "Professional Experience" yazabilirsiniz, ama "Kariyer Yolculuğum" gibi yaratıcı başlıklar ATS'i kırar. Standart kalın.

Deneyim Bölümünü Yıldız Bullet'larla Yazmak

Deneyim bölümünün her madde işaretinde üç soruyu yanıtlamalısınız:

1. Ne yaptım?: Somut eylem. "Test otomasyonu kurdum" değil, "Web ve mobil için paralel çalışan regression suite tasarladım."
2. Nasıl yaptım?: Teknik ve araç. Somut olarak, "Cypress ile component test yazarak geliştiriciye süratli feedback sağladım."
3. Ne değişti?: Etki. Açıkçası, "Manuel smoke test süresini 3 saatten 12 dakikaya düşürdüm."

Üç madde de varsa, cümleniz güçlüdür. Biri eksikse zayıftır. Çoğu test uzmanının yaptığı hata, sadece birinciyi yazmaktır: "Test yazdım. Aslına bakılırsa, çalıştırdım, bug raporladım." Bu, herkesin yaptığı bir şeydir; sizi farklılaştırmaz.

Bir de "başarı" odaklı yazmak mühim ama her cümle kahramanlık hikayesi olmak zorunda değil. Genelde, bazen "Karmaşık bir legacy sisteme test stratejisi uyarlamak 6 ay sürdü. Bu süreçte ekipteki üç yeni testçiye mentoring yaptım" gibi bir cümle. "Sıfır bug sızdırdım" gibi abartılı bir cümleden daha değerlidir. Gerçeklik, özgeçmişin en ciddi savunma kalkanıdır.

Test stratejisi ve aşama sahiplenmesini göstermek

Kıdemsız test uzmanları genellikle sadece verilen görevleri yapar. Orta ve üst seviye test profesyonelleri ise süreci sahiplenir. Özgeçmişinizde bu geçişi göstermek, sizi "testçi" olmaktan "kalite mühendisi" veya "QA lead" konumuna taşır.

Akış sahiplenmesi şu şekillerde görünür:

• Yeni ekip için test stratejisi dokümanı hazırlamak
• Definition of Done içinde kalite kriterleri tanımlamak
• Release öncesi gate review sürecini yönetmek
• Test ortamı ve test verisi yönetimini üstlenmek
• Otomasyon oranı hedefleri belirleyip ekiple birlikte takip etmek

Bu maddelerden birkaçını deneyim bölümünüze serpiştirin. Başta orta kıdemden üst kıdeme geçişte bu fark, işe alım kararını belirleyen kıstas olur.

Sık yapılan hatalar ve kaçınma yolları

Test uzmanı özgeçmişlerinde sıkça karşılaşılan sorunları ve çözümlerini sıralamak, sizin yazım sürecinizde de yol gösterici olabilir:

"Her şeyi biliyorum" sendromu

Pratikte, 15 değişik test aracını, 8 programlama dilini, 6 test türünü listelemek, hiçbirinde derinleşmediğiniz izlenimini verir. Bunun yerine 3-4 araçta gerçekten derinleştiğinizi ve diğerlerinde temel seviyede olduğunuzu açıkça vurgulayın. Dürüstlük, ATS öncesi mülakatta sizi korur.

Sürekli "Test ettim" ile başlayan cümleler

Genelde, "Test ettim, doğruladım, onayladım", bu pasif fiiller özgeçmişi uyuşuk gösterir. "Tespit ettim, tasarladım, savundum, kurdum, otomatize ettim", aktif fiiller, sizin eylemli bir mühendis olduğunuzu anlatır.

Teknik olmayan başarıları görmezden gelmek

Mentorluk yaptınız, hiring sürecinde mülakat tasarladınız, konferansta konuşma yaptınız. Bunlar yazılım projeleri kadar değerli. Test uzmanlarının çoğu özgeçmişini salt teknik beceri listesi olarak tasarlar ve "soft skill" bölümünde jenerik ifadelerle doldurur. Bunun yerine, spesifik mentorlük deneyimlerinizi, ekip içinde üstlendiğiniz rolleri yazın.

Portfolyo ve kanıt eksikliği

Test profesyonelleri için portfolyo kavramı taze taze oturuyor. Ama yapılabilir: GitHub'da paylaştığınız otomasyon örnekleri. Yazdığınız blog yazıları, hazırladığınız test stratejisi şablonları (anonimleştirilmiş), bunlar cv'nin ötesinde sizi destekleyen kanıtlardır. Özgeçmişe bu bağlantıları eklemek, "ben sadece söylemiyorum, yapıyorum" mesajı verir.

Özgeçmiş şablonunun iskeleti: sıralama ve yerleşim

Test uzmanı Cv şablonuTasarlarken en çok tartışılan konulardan biri bölüm sırasıdır. Standart bir sıralama şu şekilde işler:

1. İletişim ve Özet: Ad, iletişim, lokasyon, 2-3 cümlelik profesyonel özet.
2. Teknik Beceriler: Gruplandırılmış, bağlamsız liste.
3. İş Deneyimi: Ters kronolojik, her pozisyon için 4-6 bullet.
4. Projeler (opsiyonel): Yan proje, açık kaynak, konferans katkıları.
5. Sahada, sertifikalar ve Eğitim: ISTQB ve ilgili eğitimler öne çekilebilir.
6. Mesleki Gelişim: Konferans, kitap, blog, topluluk katkıları.

Yeni mezun veya 2 yıldan az deneyimliyseniz eğitim bölümünü öne çekebilirsiniz. Deneyimli bir test uzmanıysanız, deneyim bölümü en az sayfanın yarısını kaplamalıdır. Özgeçmiş tek sayfa mı çift sayfa mı sorusu sürekli tartışılır; ancak 7 yıl ve üzeri deneyimde tek sayfa artık gerçekçi değildir.

Kapanış: özgeçmişiniz de bir test objesidir

Test profesyonelleri olarak kariyerimizde ürünleri test ederken kullandığımız ilkelerin çoğu, kendi özgeçmişimize de uygulanabilir. Net, ölçülebilir, tekrarlanabilir, bağlama uygun.Cv şablonuArayışınız, bir "boşluk doldur" işi değil; bir tasarım problemidir. Tıpkı bir test planı yazmak gibi: scope'u netleştirin, riskleri belirleyin, isabetli araçları seçin, etkiyi ölçün.

İşe alım uzmanı sizin özgeçmişinizi açtığında. Sadece teknik yetkinliğinizi değil; düşünce kalıbınızı, iletişim kalitenizi, detaylara verdiğiniz önemi okuyacaktır. Üç satırda "X'in neden bu role uygun olduğunu" anlatabilen bir özgeçmiş. İki sayfalık jargon yığınından daima daha güçlüdür.

Genelde, bu rehber, size bir şablon değil; bir düşünce çerçevesi sunuyor. İçine kendi projelerinizi, kendi araçlarınızı, kendi etkinizi yazmanız gerekiyor. Zira en güçlü test uzmanı özgeçmişi. Genelde, en çok öğrenilen hata sayısını değil; en çok öğrenilen düşünce biçimini anlatanıdır.