Seri 2: Sahadan Hatalar – Bölüm 4 Teknoloji dünyasının çok tipik bir hastalığı var: Bir problemi çözmek yerine, o problemi çözmek için kullanılan araçlara aşık olmak. Yazılım test ekipleri bu tuzağa belki de herkesten daha hızlı düşüyor. LinkedIn akışları, konferans başlıkları ve teknik bültenler sürekli "yeni nesil", "yapay
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&
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
Seri 2: Sahadan Hatalar – Bölüm 1 Bir test ekibinin başına gelebilecek en tehlikeli şeylerden biri, kulağa son derece havalı gelen bir hedefin peşine kontrolsüzce takılmaktır. Bizim için o hedef, günün birinde toplantı odasında birinin tahtaya yazdığı şu cümleydi: "Manuel testi tamamen bitiriyoruz, her şeyi otomatize edeceğiz." Dışarıdan bakıldığında
Seri 1: Liderin Masası – Bölüm 4 - Son Bir sprintin en gergin anları genelde Jira bildirimlerinin peş peşe düştüğü zamanlardır. Açılan kırmızı bir "Bug" ikonu, çoğu ekipte ister istemez bir alarm zili gibi yankılanır. Geliştiricinin ekranına düşen her yeni kayıt; ek bir iş, kaçan bir deadline ya da yapılmış
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
Seri 1: Liderin Masası – Bölüm 2 Kariyeri boyunca iyi bir test mühendisiyle çalışmış olanlar bilir; onların ayrılışı genelde gürültülü olmaz. Büyük tartışmalar, kapı çarpmalar ya da masaya yumruk vurmalar yaşanmaz. İyi bir testçi gitmeye karar verdiğinde önce biraz sessizleşir. Eskiden toplantılarda ardı arkası kesilmeyen o rahatsız edici sorular azalır. Kabul
Seri 1: Liderin Masası – Bölüm 1 Dashboard yeşil. Test koşumları sorunsuz tamamlanmış. Son rapora göre kod kapsama oranı yüzde doksanın üzerinde. Teorik olarak her şey yolunda görünür; hatta yöneticilere sunulan slaytlarda bu oran güven verici bir kalkan gibi durur. Ama cuma akşamı prod ortamına yeni sürüm çıkarken bir test liderinin
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
Hayat ve Yazılım Testi Üzerine
Test ekipleri çoğu zaman çıktı üzerinden değerlendirilir: kaç test yazıldı, kaç hata bulundu, otomasyon oranı ne kadar arttı. Oysa ekip gelişimi bu metriklerin çok ötesinde, daha sessiz ama daha belirleyici bir alanda gerçekleşir. Gerçek gelişim; insanların düşünme biçiminde, sorumluluk alma şeklinde ve belirsizlikle başa çıkma reflekslerinde ortaya çıkar. Test liderliği
Yazılım kalitesi çoğu zaman araçlarla, test senaryolarıyla, otomasyon oranlarıyla anlatılır. Raporlar grafiklerle dolar, metrikler konuşur. Ancak çoğu ekip şunu geç fark eder: Kaliteyi asıl belirleyen şey kullanılan araçlar değil, o araçları kullanan insanların tutumu ve davranışlarıdır. Aynı teknolojiye, aynı test setlerine, aynı otomasyon altyapısına sahip iki takım arasında dramatik kalite
Yıllar önce test ekipleri çoğunlukla ikiye ayrılıyordu: manuel testçiler ve otomasyon geliştiricileri. Arada çoğu zaman görünmez bir duvar olurdu. Bugün şirketlerin büyük kısmı o modeli terk etti. Çünkü tek yönlü uzmanlık hem ilerlemeyi yavaşlatıyor hem de kalite perspektifini daraltıyor. Artık beklenti daha net: manuel düşünebilen ve gerektiğinde otomasyon üretebilen hibrit
Test, işin sonunda yapılan kontrol değil; işin başından sonuna kadar süren akıl yürütme biçimidir. Agile sonrası yazılımcılık dünyasında değişmeyen tek şey var: hız değil, belirsizlik. İhtiyaçlar sabit değil, planlar kesin değil, teknoloji durmuyor. Bu ortamda testin rolü artık eskisinden daha geniş. Bugün test, sadece hatayı bulmak ve raporlamak değil, ürün
Bugün artık test otomasyonu, yazılım geliştirme ekiplerinin “ilerici” bir tercihi olmaktan çıkıp, neredeyse standart bir gereksinime dönüştü. Fakat ben yıllar içinde şunu fark ettim: Otomasyon yapmak tek başına bir hedef değil. Asıl hedef, akıllı test sistemleri kurmak. Klasik otomasyon, sadece komut verilen bir işçidir. Akıllı test sistemleri ise düşünür, önerir,
Test mühendisliğinde yıllar geçtikçe fark ettiğim bir gerçek var: Hatalar çoğu zaman koddan değil, yanlış kullanılan veriden çıkıyor. Test süreçlerinde genelde “senaryo”, “araç”, “otomatize test”, “CI/CD” gibi terimler öne çıkar. Ama perde arkasında sessizce duran, doğru kullanılmadığında sistemi çökerten bir unsur vardır: test verisi. Ben de ekibimle birlikte onlarca
Yıllar geçtikçe, bazı insanların ve şirketlerin neden değişmek için mücadele ettiğini görüyoruz. Bazıları yıllarca denemelerine rağmen bir türlü değişemezken, bazıları kendilerini bir gecede yeniden inşa ediyor gibi görünür. Sinir bilimciler, doğru alışkanlıkların başarılı olmak için çok büyük rol oynadığını söylüyor. 💡 Alışkanlıkların Gücü Nedir? Özünde Alışkanlıkların Gücü, hayatımızı dönüştürmemizi sağlayan bir
Yapay Zekâ Hangi Test Süreçlerinde Kullanılabilir? Gerçek Uygulama Alanlarına Yakından Bakış Yazılım test lideri olarak, her zaman test süreçlerini daha verimli, sürdürülebilir ve akıllı hale getirecek yollar arıyorum. Son yıllarda bu konuda en büyük dönüşümü yaratan unsur hiç kuşkusuz yapay zekâ oldu. AI artık test dünyasında bir yan araç değil,
Yazılım testi dünyasında son yıllarda yaşanan değişim beni her zamankinden daha fazla heyecanlandırıyor. Test lideri olarak ekiplerimizin nasıl daha verimli, öngörülü ve yenilikçi hale gelebileceğini her zaman merak ediyorum. Yapay zekâ artık sadece bir teknoloji trendi değil; test süreçlerimizi yeniden şekillendiren, düşünme biçimimizi dönüştüren bir gerçeklik. Bu yazıda, AI’nin
Yazılım test mühendisliği, her geçen yıl gelişen yeni teknolojiler, metodolojiler ve araçlarla birlikte dönüşmeye devam ediyor. 2025 yılında, test mühendislerinin daha etkili, hızlı ve güvenilir test süreçleri oluşturabilmesi için belirli alanlara odaklanması kritik hale gelecek. Bu yazıda, yazılım test mühendislerinin 2025 yılında odaklanması gereken alanları, kullanması gereken teknolojileri ve takip
Yazılım test mühendisliği, yazılım kalitesini güvence altına almak için kritik bir rol oynar. İyi bir test mühendisi, yalnızca hataları bulmakla kalmaz, aynı zamanda yazılım geliştirme sürecini daha verimli ve etkili hale getirecek yöntemler geliştirir. Peki, iyi bir yazılım test mühendisi olmak için hangi temel prensiplere dikkat etmek gerekir? İşte 10
Yazılım geliştirme, fikirden son kullanıcının eline ulaşana kadar geçen bir dizi planlama, tasarlama, geliştirme, test etme ve yayına alma sürecinden oluşur. Bu süreç Yazılım Geliştirme Yaşam Döngüsü (SDLC - Software Development Life Cycle) olarak adlandırılır ve farklı metodolojilerle ele alınabilir. Bu yazıda, Agile, DevOps ve yazılım test mühendisliğinin rolü üzerinde durarak
