PodTest

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.Hype driven development, yazılım dünyasında önemli bir kavram.AI'nin kod inceleme süreçlerinde henüz net bir faydası yok.Kod inceleme süreçleri, takım içi iletişimi artırabilir.AI, bazen Junior Developer gibi çalışıyor.Kod inceleme vakit kaybına sebep olabiliyor.Gelecekte AI'nin yazılım geliştirme üzerindeki etkileri tartışılacak.Gemini gibi araçlar hype yaratıyor.Kod inceleme süreçleri uzun sürüyor.AI, hype'ı artırıyor.Takım içi iletişim, yazılım geliştirme sürecinin önemli bir parçasıdır.Burak Yörük kimdir?

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 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. Karıncalar ekosistemde kritik bir rol oynar.Hata yönetimi, hatanın farkında olmakla başlar.Bug free olmak imkansızdır.Farkındalık, kültürel bir değişim gerektirir.Hata çıkarsa ne yaparız, çıkmaması için ne yaparız?Sistem çöküyor, hiç resilient değilizHerkesin bireysel eforu bir kültür haline gelmeli.Riskleri yönetmek, farkındalığı arttırmakla başlar.Mühendislik kültürü oluşturmak önemlidir.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!

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: LinkedinKişisel web bağlantısı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!

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/

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 etkisiTestte 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çekleriTest otomasyonunun sınırları ve AI ile birleşimi“Her şeyi test etmeye” çalışmanın neden anlamsız olduğuSektörde yanlış bilinen efsaneler ve komik anekdotlarSohbet 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

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.

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. Bug’ın Yaşam Döngüsü: Bug’lar nasıl doğar, büyür ve bazen geri döner? Paylaşım Dinamikleri: İnsanlar bug’ları genelde nasıl paylaşır, iletişim eksikliği veya yanlış yönlendirme nasıl sorunlara yol açar? Gerçek Hikayeler ve Dersler: Ekibimizden ve dinleyicilerimizden gelen gerçek tecrübelerle bug’ların nasıl yönetildiğini (ya da yönetilemediğini) konuştuk. 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!

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.