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
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
Yazılım Test Mühendisliği
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,
Yazılım Test Mühendisliği
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
