Uzun bir aradan sonra Podtest geri döndü!
Bu bölümde Tunç, Alper ve Arda hepimizin içini burkan bir gerçekle yüzleşiyor: Exhaustive testing is impossible.
Ama gerçekten öyle mi? Yoksa “her şeyi test edemeyiz” bahanesi, test stratejilerimizin zayıflığını mı saklıyor?
Ekip bu sorudan yola çıkarak yazılım dünyasının en temel paradokslarından birini tartışıyor:
100% test mümkün olmasa da, neden hâlâ deniyoruz?
Zaman, kaynak ve kapsam üçgeninde nerede kayboluyoruz?
“Tam test” yerine “doğru test” yapmak ne demek?
Ve asıl mesele: testlerden öğreniyor muyuz, yoksa sadece koşuyor muyuz?
Bol kahkaha, bol itiraz ve biraz da Gandalf referansı içeren bu bölüm, testin sınırlarını konuşurken aslında yazılım ekiplerinin sınırlarını da sorguluyor.
Bu bölümde konuğum Berk Dülger. Türkiye’den Avrupa’ya uzanan kariyer yolculuğunda yazılım testinden mühendislik yönetimine, kültür şokundan takım yönetimine kadar birçok konuyu masaya yatırdık.
🔧 QA konuşmadık mı? Konuştuk.
🏙️ Yurt dışı hayatı konuştuk mu? Evet.
📉 “5000 test koşuldu ama hata oldu” diyen CEO'lara lafımızı da söyledik.
💡 Birlikte çalışmanın, karar almanın ve kalitenin arkasındaki kültürel dinamikleri tartıştık.
🏙️ İstanbul eski sevgili mi? Berlin yabancı mı?
Dolu dolu, sorgulayıcı ve kahkahalı bir bölüm oldu.
"Beynelmilel testçi olur mu?" sorusuna birlikte cevap aradık.
Cevaplar bizde; buyur gel, dinle. 🎧
Bu bölümde Tunç (yönetsel), Alper (şiirsel) ve Arda (kitabi), yazılım testinin en temel taşlarından biri olan test prensiplerini masaya yatırıyor.
“Absence of errors is not proof of correctness” ilkesinden yola çıkarak şu soruları tartışıyoruz:
Test yapmanın gerçek amacı nedir?
Hataların yokluğu bizi neden kandırır?
Kan şekeri testi analojisiyle yazılım testini nasıl kıyaslayabiliriz?
Yedi prensip neden sırayla anlatılmaz ve her zaman işe yaramaz?
Prensipler bir manifestoya mı dönüşmeli?
Kimi zaman ciddiyet, çoğu zaman mizah eşliğinde, testin anlamını, sınırlarını ve eksiklerini sorguluyoruz.
Yeni bölümlerde her prensibi tek tek ele alıp, gerçek proje hikayeleriyle bağlamayı planlıyoruz.
📌 Neler mi konuştuk?
✔ Yapay zeka entegrasyonlarının perde arkası
✔ #ISTC2025 notları – orada olanlar, orada kalmadı
✔ Geyik ama dozajlı (merak etme, ölçü bardağı elimizdeydi)
✔ Gerçek hikâyeler – hem komik hem düşündüren cinsten
Bu bölümde QA işe alım süreçlerini didik didik ettik.
Neleri konuştuk?
– QA’den beklentiler nerede başlıyor, nerede saçmalıyor?
– Pozisyon açmadan önce işin analizini yapıyor muyuz?
– Adayın değil, sürecin nezaketi konuşulmalı mı?
– QA işi öğrenme/öğretme fırsatına dönüşebilir mi?
– Ve tabii ki, bizce olmazsa olmaz: samimi, bol hatıralı sohbetler.
-- Bir QA pozisyonu açmadan önce bu bölümü dinleyin deriz.
Kaliteye giden yol, önce dürüstlükten geçiyor. Bu bölümde, testin ekipler tarafından nasıl bir “sıkıştırılmış aktivite” olarak görüldüğünü, aslında bu yaklaşımın kaliteye karşı bir dürüstlük sorunu yarattığını konuştuk. Kendi deneyimlerimizden yola çıkarak, yönetime yaptığımız test eforunu doğru bir dille anlatmanın neden hayati olduğunu tartıştık. Son olarak da, kalite ve risk arasındaki dengenin ne kadar hassas olduğunu ve bu dengeyi kurmanın projelerin gerçek başarısı için neden kritik olduğunu vurguladık.
Son bölümümüzde Oobeya'nın Kurucu Ortağı ve Ürün Direktörü Emre Dündar ile yazılım geliştirme yaşam döngüsünde metriklerin rolünü ve önemini ele aldık. Emre Bey, metriklerin ekiplerin performansını artırmadaki katkılarını ve Oobeya.io platformunun bu süreçte nasıl bir destek sağladığını paylaştı. Ayrıca, metriklerin yanlış kullanıldığında nasıl olumsuz sonuçlara yol açabileceğini ve bu durumun önüne geçmek için nelere dikkat edilmesi gerektiğini tartıştık. Bu keyifli sohbeti kaçırmayın!
ürün: https://oobeya.io/
Emre Dündar LinkedIn: https://www.linkedin.com/in/emredundar/
2024 yılı yazılım dünyasında hatalarla dolu bir yıl oldu. Bu bölümde, yıl boyunca karşılaştığımız en büyük ve ilginç yazılım hatalarını masaya yatırdık.
• CrowdStrike Güncelleme Krizi: Mavi ekranların ötesinde, milyar dolarlık kayıplar.
• Concord Video Oyunu : Ağustos 2024'te Firewalk Studios, PlayStation 5 ve Windows için “Concord” adlı bir kahraman nişancı oyunu yayınladı. 8 yıllık geliştirme süreci ve 400 milyon doları aşan maliyete rağmen oyun, Lansmandan iki hafta sonra oyun satıştan kaldırıldı ve sunucuları kapatıldı.
• 40 Milyon Dolarlık Kayıp: Etiyopya’daki yazılım hatasının ilginç hikayesi.
• Birmingham Şehir Konseyi Oracle Arızası: Birmingham Şehir Konseyi, 38 milyon sterlinlik bir Oracle muhasebe sistemi uyguladı ancak sistem ilk altı ayda 8.000'den fazla soruna yol açtı. Bu durum manuel muhasebe işlemlerinin 40.000 saati aşmasına neden oldu.
-------
Bölümümüzde sadece hataların teknik detaylarını değil, bunların ekipler, şirketler ve dünya üzerindeki etkilerini de ele aldık. 2024’te yaşanan yazılım hatalarından çıkarılacak dersler neler? Milyon dolarlık kayıplar nasıl önlenebilirdi?
Eğlenceli bir tonla, yılın en dikkat çeken hatalarını tartışırken hem güldük hem de düşündük. Yazılım dünyasında hatasız bir yıl dileriz, ama bilirsiniz… hata yapmadan öğrenemeyiz!
Bu bölümde, yazılım geliştirme dünyasının kaçınılmaz gerçeklerinden biri olan bug’ların yaşam döngüsünü masaya yatırdık. Bir bug’ın fark edilme anından çözümüne kadar geçen süreçte hangi evrelerde ekiplere ve yazılıma zarar verdiğini tartıştık.
Eğlenceli bir tonla teknik bilgiyi harmanlayarak bazen yazılımdaki hata süreçlerine şiirsel yaklaştık bazende güvelere ışık olduk! :) Bug’lar sadece birer hata mı, yoksa ekiplere daha derin bir hikaye anlatan fırsatlar mı? Buna siz karar verin!
🎙️ Yeni Podtest Bölümü Yayında! 🎉
Bu bölümde Jr.Torçuk’un aramıza katılmasını, geç de olsa, kutladık, bölümümüzü kendisine adadık ve güvelerin takımlara ve şirketlere etkisini tartıştık. Yer yer Türkçe bile konuşamadık, ama olsun, yine de çok keyifli bir sohbet oldu! En azından biz keyif aldık!
🌟 Dinleyin, düşüncelerinizi bizimle paylaşın: Güvelerin şirketlerde nasıl fark edildiğini, nasıl verimli kullanılabileceğini hakkında siz nasıl düşünüyorsunuz?
‘Yazılım hatalarından neden kurtulamıyoruz?’ diye soranların buluştuğu güve sezonunun ilk bölümüne hoş geldiniz. Yazılım hatalarını daha iyi anlayabilmek için; yazılım testi ve kalite konusunda daha iyi bir okur yazar olabilmek için; yazılım hatalarının anlattıklarını daha iyi anlamak ve yorumlayabilmek gerekiyor. Bu sebeple, yazılım hatalarının nerden başladığıyla, hataların tarihinden konuşmaya başladık.
Sanmayın ki öyle bir tarih dersi... kah güldük kah ağladık! Gerçeklerden de dert yandık!
Güve sezonu önümüzdeki bölümlerde hata tiplerine, raporlama ve metriklerine, nasıl bildirilmeleri gerektiğine ve bize nasıl para kazandırabileceği hakkında bölümlerle devam edecek!
