Bize Böyle Anlatmadılar #1
CV Yazacaktık, Hayata Geldik
Bu bölümde CV konuşacaktık.
Ama konuşamadık.
Çünkü CV’den önce kimsenin anlatmadığı bir şey var:
kendini tanımak.
Yeni mezunken ya da işe yeni başlamışken;
ne istediğini bilmeden hedef koymak,
yanlış yere çaba harcamak,
“ben buraya neden geldim?” diye ortada kalmak
çok normal. Ama kimse bunu açık açık söylemiyor.
Bu bölümde CV’den çok:
farkındalığı,
hedefi,
yanlış çabayı,
ve işin içine girince anlaşılan gerçekleri
konuşuyoruz.
Bu bir CV bölümü değil.
Bu, CV’den önce gelenler.
🎙️ Bize Böyle Anlatmadılar,
işe, teknolojiye ve hayata girerken kimsenin söylemediği şeylerin köşesi.
Karınca Açısı | Ölçeklenebilir Mühendislik için Dürüst Okuma Şart
Bu bölümde QA’yı “test yapmak”tan çıkarıp, organizasyonun kendi kendine ne kadar dürüst olabildiği yerden ele alıyoruz.
Dashboard’lar yeşil ama ekipler yanıyor mu?
Coverage yüksek ama gerçekten riskli yerleri mi ölçüyoruz?
QA bir bottleneck mi, yoksa şirketin röntgeni mi?
Bu bölümde konuşulanlar:
QA stratejisinin neden bir check-up olduğu
“Karpuz etkisi” (dışı yeşil, içi kırmızı organizasyonlar)
Yanlış metrikler ve sahte güven hissi
QA’siz takımların aldığı görünmez riskler
Süreç, fonksiyonel ve yapısal kalite arasındaki fark
Karıncalardan gelen beklenmedik ama çok net bir ders 🐜
Karınca Açısı’nda bu kez şunu soruyoruz:
Sürekli otopsi mi yapmak istiyoruz, yoksa düzenli check-up mı?
Dinle, düşün, rahatsız ol.
Çünkü bazen kalite tam da orada başlıyor.
Bu bölümde Tunch ve Burak, yazılım geliştirme süreçlerinde AI'nin rolünü ve hype driven development kavramını ele alıyor. Kod inceleme süreçlerinin zorlukları, AI'nin bu süreçlere etkisi ve takım içi iletişimin önemi üzerinde duruluyor. Ayrıca, gelecekte AI'nin yazılım geliştirme üzerindeki potansiyel etkileri tartışılıyor.
Bu bölümde karıncaların kolektif zekâsından ilham alarak yazılım ekiplerinde hata yönetimi, farkındalık ve ‘bug‑free’ fikrinin neden gerçekçi olmadığını tartışıyoruz. QA ve engineering kültürünün nasıl dayanıklı, öğrenen ve sürdürülebilir sistemlere dönüştürülebileceğini konuşuyoruz. Hata kaçınılmaz — önemli olan ona nasıl yaklaştığın.
Tunç ve Çağkan'a erişmek için LinkedIn ve infopodtest@gmail.com adresini kullanabilirsiniz.
Danışmanlık için bilgi almak isterseniz:
info@catchylabs.tech
adresinden de erişebilirsiniz!
Yeni köşemiz Piyasa Baskülü’nün ilk bölümünde Tunç ve Gökay, piyasayı tartıyor.
Ama öyle bir tartış ki…
Girişimcilik ekosisteminden fintech’e, yatırım kültüründen “ürüne aşık olma” hatasına kadar her taşın altına bakıyoruz.
Bu bölümde:
Girişimcilik mi, yoksa sadece “gelişken olmak” mı ayırt edilir?
Türkiye’de ve Avrupa’da yatırım kültürü neden bu kadar farklı?
Fintech niye patladı, gerçekten neyi çözüyor?
Bootstrap mümkün mü, yoksa masal mı?
Ürününe aşık olmanın startup'ı nasıl batırdığı…
Network her şey mi? Hiçbir şey mi?
“Kumaş” meselesi: Neden tek founder’lık çoğu zaman yürümüyor?
Kısacası, piyasanın baskülüne çıktık; tartı ne gösteriyorsa onu konuştuk.
Düz, filtresiz, abartısız, samimi bir sohbet.
Bu bölümde Tunç ve Çağkan olarak yazılım ekiplerinin yıllardır aynı döngüde sıkışıp kalmasının gerçek sebeplerine giriyoruz:
— görünmeyen hata maliyetleri,
— yangın söndürme kültürünün ekiplere çaktırmadan ödettiği bedeller,
— uptime takıntısının arka planındaki “güven” ekonomisi,
— ve tabii ki yeni köşemiz Karınca Açısı: Probleme bir karıncanın baktığı yerden bakabilirsek ne değişir?
Forbes ve Gartner araştırmalarından çıkan çarpıcı sonuçları masaya yatırıyoruz:
Kötü deneyim yaşayan kullanıcıların 0,88’i gidiyor,
ve gidenlerin 0,52’si geri dönmüyor.
Ekip içi maliyet, kültürel erozyon ve ürünün sessizce kan kaybetmesi… Bunları doğru metriklerle nasıl kontrol altına alacağımızı tartışıyoruz.
Sonunda şuna geliyoruz:
Kalite; testten değil, yönünü bulmuş bir zihinsel modelden doğar.
Ekipler “yangına koşmak” yerine stratejik olarak nefes almayı öğrendiğinde, işte o zaman gerçek iyileşme başlıyor.
Karıncaların bile bildiği şeyi hatırlıyoruz:
“Yolun varsa, yürürsün. Yönün varsa, varırsın.”
Çağkan Aksun Yüksel:
Not: 0,52 ve 0,82 yazdım zira bu yükleme aracında yüzde işareti koyamıyoruz.
Bu da böyle bir bulgu!
Bu bölümde siber güvenlik, yazılım testi ve yapay zekânın iş hayatındaki gerçek etkilerini konuşmak için Gökhan Pekşen’i ağırlıyoruz.
Etik hacking’den DevSecOps’a, kariyer yolculuğundan sektörün kronik hatalarına kadar birçok konuya hem teknik hem de mizahi bir dille giriyoruz. AI gerçekten işleri elimizden alacak mı? Test ekipleri neden hâlâ düşman gibi görülüyor? Güvenlik testleri neden son dakikaya bırakılıyor?
Hepsini açık açık konuştuk.
Ayrıca gençlerin bu alanda nasıl kariyer kurabileceğini, test tarafında “nicelik mi nitelik mi?” tartışmasını, güvenlik açıklarının nasıl yönetildiğini ve şirketlerin neden sürekli aynı döngüde takıldığını da masaya yatırıyoruz.
Her zamanki Podtest enerjisi, bol kahkaha ve bol gerçeklik ile…
Bölümden başlıklar:
Yapay zekânın güvenlik ve test dünyasına gerçek etkisi
Testte kalite vs hız: Hangisi gerçekten önemli?
Güvenlik ekiplerinin organizasyon içindeki yanlış konumlandırılması
Kariyere yeni başlayanlar için siber güvenlik yol haritası
Büyük şirketlerdeki test ve güvenlik süreçlerinin acı gerçekleri
Test otomasyonunun sınırları ve AI ile birleşimi
“Her şeyi test etmeye” çalışmanın neden anlamsız olduğu
Sektörde yanlış bilinen efsaneler ve komik anekdotlar
Sohbet boyunca hem güldük hem de ciddi ciddi dertlendik.
Siber güvenlik, test, DevSecOps veya AI ile ilgilenen herkes için çok şey var bu bölümde.
Keyifli dinlemeler!
Gökay'a erişmek isteyen arkadaşlar linkedin profilinden erişebilirler
Einstein bizi affetsin sanki e=mc²
Bu bölümde ISTQB’nin “Erken Test Zaman ve Para Kurtarır” ilkesini masaya yatırıyoruz – ama kitap gibi değil, saha gibi.
Yönetsel, Şiirsel ve Kitabi önce kaotik bir giriş yapıyor (şiir ödevi yapılmamış, bağlantı kopmuş, suçlu tabii ki Alper), sonra yavaş yavaş şu sorulara geliyorlar:
Erken test gerçekten zaman ve para mı kurtarır, yoksa bunu sadece sunumlarda mı söylüyoruz?
Otomasyon projelerine tonla para verilip “hiçbir şey değişmedi” hissi neden bu kadar yaygın?
Yönetim “15 gün önce çıkaralım” diye bastırırken, kim “ya kalite / itibar kaybı?” diye masaya vuruyor?
Test ekipleri riskten bahsedince neden kimsenin gözü parlamıyor?
Bölümde; akademik test prensipleri ile işin “gerçek dünya” baskıları (delivery tarihi, bütçe, itibar riski) arasında gidip geliyoruz.
Otomasyonun amacını, erken testin nereye kadar gerçekten işe yaradığını ve test ekiplerinin işini daha dürüst ve net nasıl anlatabileceğini tartışıyoruz.
Sonuç: Erken test sadece “kitap cümlesi” olmamalı; risk, maliyet ve itibar kaybı üzerinden konuşulmadıkça kimseyi ikna etmiyor.
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!