236 Test Geçti, Ama Sürüm Hala Bozuk: Yazılım Kalitesinde Görünmez Engeller

236 Test Geçti, Ama Sürüm Hala Bozuk: Yazılım Kalitesinde Görünmez Engeller

Kaç kez bu senaryoyu yaşadınız? Tüm birim testleri (unit tests) ve entegrasyon testleri (integration tests) yeşil yanıyor, sürekli entegrasyon/sürekli dağıtım (CI/CD) boru hattı (pipeline) gururla ‘geçti’ diyor ama yeni sürüm (release) canlıya alındığında beklenmedik, hatta kritik sorunlar ortaya çıkıyor. Bu durum, yazılım geliştirme dünyasında sıkça karşılaşılan, moral bozucu ve maliyetli bir problem. Testlerin başarılı olması, her zaman ürünün hatasız olduğu anlamına gelmez. Peki, bu paradoksun arkasında yatan nedenler nelerdir ve bu tür hayal kırıklıklarını önlemek için neler yapabiliriz? Bu makalede, testlerin geçtiği ancak sürümün bozuk çıktığı durumların derinlemesine analizini yapacak, bu sorunların kökenlerine inecek ve kapsamlı çözüm stratejilerini adım adım inceleyeceğiz.

Test Başarılı Ama Ürün Hatalı: Neden Böyle Oluyor?

Yazılım geliştirme süreçlerinde testler, ürün kalitesini garanti altına almak için hayati öneme sahiptir. Ancak, “testler geçti” ifadesi, çoğu zaman yanıltıcı bir güven duygusu yaratabilir. Bir yazılımın yüzlerce veya binlerce testten başarıyla geçmesi, sistemin tüm yönlerinin kusursuz çalıştığı anlamına gelmez. Bu durumun altında yatan temel nedenler genellikle test kapsamının yetersizliği, test ortamları ile üretim ortamları arasındaki farklılıklar ve karmaşık entegrasyon sorunlarıdır. Yazılım ekosistemleri gün geçtikçe daha karmaşık hale gelirken, sadece kodun doğru çalıştığını doğrulayan testler, sistemin genel sağlığını yansıtmaktan uzak kalabilir. Bu bölümde, bu yaygın sorunların ana kaynaklarını detaylı bir şekilde ele alacağız.

Test Süitlerinin Sınırları ve Gerçek Dünya Uyumsuzlukları

Test süitleri, yazılımın belirli işlevlerini, bileşenlerini veya etkileşimlerini doğrulamak üzere tasarlanır. Birim testleri, kodun en küçük parçalarının (fonksiyonlar, metotlar) beklendiği gibi çalıştığından emin olurken, entegrasyon testleri farklı bileşenlerin birbiriyle doğru şekilde iletişim kurduğunu kontrol eder. Ancak, bu testlerin odak noktası genellikle izole edilmiş veya kısmen izole edilmiş senaryolardır. Gerçek dünya kullanım senaryoları ise çok daha karmaşık ve öngörülemez olabilir. Kullanıcılar, yazılımı tasarlanmamış veya test edilmemiş şekillerde kullanabilir, beklenmedik veri kombinasyonları girebilir veya eş zamanlı (concurrent) işlemlerle sistemi zorlayabilirler. İşte bu noktada test süitlerinin sınırları ortaya çıkar. Testlerin sadece pozitif senaryoları kapsaması, kenar durumları (edge cases) veya hata senaryolarını göz ardı etmesi, başarılı görünen test sonuçlarının aslında eksik bir resim çizmesine neden olabilir. Örneğin, bir ödeme sisteminde temel ödeme akışı test edilmiş olabilir, ancak aynı anda binlerce kullanıcının ödeme yapmaya çalıştığı veya bir kullanıcının ödeme sırasında internet bağlantısının kesildiği durumlar yeterince test edilmemiş olabilir. Bu tür senaryolar, ancak uçtan uca (end-to-end) testler, performans testleri veya keşifsel testler (exploratory testing) ile ortaya çıkarılabilir. Eğer testler, “bitti” tanımının (Definition of Done) bir parçası olarak bu tür geniş kapsamı içermiyorsa, yeşil yanan testler yanıltıcı bir güven sağlayacaktır.

Çevre Farklılıkları ve Konfigürasyon Yönetimi

Geliştirme, test, hazırlık (staging) ve üretim (production) ortamları arasındaki farklılıklar, “testler geçti ama sürüm bozuk” senaryosunun en yaygın nedenlerinden biridir. Bir yazılımın geliştirildiği ve test edildiği ortam, genellikle canlıya alındığı üretim ortamından farklılık gösterebilir. Bu farklılıklar, işletim sistemi versiyonlarından, veritabanı sürümlerine, ağ konfigürasyonlarından, üçüncü taraf servislerin versiyonlarına veya hatta çevresel değişkenlere (environment variables) kadar geniş bir yelpazeyi kapsar. Örneğin, geliştirme ortamında kullanılan bir veritabanı versiyonu, üretim ortamındaki veritabanı versiyonundan daha yeni veya daha eski olabilir ve bu durum, belirli SQL sorgularının veya ORM (Object-Relational Mapping) davranışlarının farklı çalışmasına neden olabilir. Aynı şekilde, bir API’nin test ortamında sınırsız çağrı hakkı varken, üretim ortamında belirli bir çağrı limiti olması, performans sorunlarına yol açabilir. Bu tür farklılıklar, genellikle gözden kaçan detaylardır ve otomatik testler tarafından tespit edilmesi zordur, çünkü testler kendi çalıştıkları ortamda doğru sonuç verirler. Bu sorunu aşmak için kapsayıcılaştırma (containerization) teknolojileri (örneğin Docker) ve altyapı kodu (Infrastructure as Code – IaC) araçları (örneğin Terraform, Ansible) kullanılarak ortamlar arasında tutarlılık sağlanmaya çalışılır. Ancak, bu araçlar dahi tüm farklılıkları ortadan kaldıramayabilir; insan hatası veya eksik konfigürasyon yönetimi her zaman bir risk faktörü olarak kalır. Tutarlı ve izole edilmiş test ortamları oluşturmak, bu tür sorunların önüne geçmek için kritik öneme sahiptir.

Kapsamlı Test Stratejileri Geliştirmek

Yukarıda bahsedilen sorunlar, yazılım kalitesini güvence altına almak için daha kapsamlı ve katmanlı bir test stratejisinin gerekliliğini ortaya koymaktadır. Sadece birim ve entegrasyon testlerine güvenmek, sistemin bütünsel davranışını ve gerçek dünya koşullarındaki performansını yeterince değerlendiremez. Bu nedenle, test piramidi modelini genişleterek ve farklı test türlerini sürece dahil ederek, yazılımın her yönünü güvence altına almak esastır. Başarılı bir sürüm için, sadece kodun doğru çalıştığından değil, aynı zamanda sistemin beklendiği gibi davrandığından, performans sorunları yaşamadığından, güvenlik açıklarının olmadığından ve kullanıcılar için kullanılabilir olduğundan emin olmalıyız. Bu bölümde, test kapsamını nasıl genişletebileceğimizi ve sürüm hatalarını önlemek için hangi test türlerini kullanabileceğimizi detaylandıracağız.

Birim Testlerinden Uçtan Uca Testlere: Piramidin Ötesi

Geleneksel test piramidi, temel olarak alt katmanda çok sayıda hızlı birim testi, orta katmanda daha az sayıda entegrasyon testi ve en üst katmanda çok az sayıda yavaş uçtan uca (E2E) test önerir. Bu model, test maliyetini ve hızını optimize etmek için hala geçerli olsa da, modern ve karmaşık uygulamalar için yeterli olmayabilir. Birim testleri, kodun bireysel parçalarının doğruluğunu kontrol ederken, entegrasyon testleri bu parçaların bir araya geldiğinde nasıl çalıştığını inceler. Ancak, bu testler genellikle gerçek bir tarayıcıda veya mobil cihazda kullanıcı arayüzü (UI) üzerinden bir kullanıcının tüm akışını taklit etmez. İşte bu noktada uçtan uca testler devreye girer. Uçtan uca testler, bir kullanıcının bir uygulamayı baştan sona nasıl kullanacağını simüle ederek, tüm sistemin, veritabanından kullanıcı arayüzüne kadar, beklendiği gibi çalıştığını doğrular. Örneğin, bir e-ticaret uygulamasında bir kullanıcının ürün aramasından, sepete eklemesine, ödeme yapmasına ve sipariş onayına kadar tüm akışı test etmek, gerçek dünya senaryolarını yakalamak için kritik öneme sahiptir. Cypress, Playwright veya Selenium gibi araçlar, bu tür testleri otomatikleştirmek için kullanılabilir. Ayrıca, API testleri, farklı mikroservisler veya harici sistemler arasındaki sözleşmeleri (contracts) doğrulayarak entegrasyon seviyesinde daha kapsamlı bir güvence sağlayabilir. Bu sayede, UI testlerinin yavaşlığı ve kırılganlığı azaltılırken, sistemin omurgası sağlamlaştırılır. Kapsamlı bir test stratejisi, sadece kod kalitesini değil, aynı zamanda kullanıcı deneyimini ve sistemin genel işlevselliğini de güvence altına almalıdır.

Performans, Güvenlik ve Kullanılabilirlik Testlerinin Önemi

Bir yazılımın işlevsel olarak doğru çalışması, onun başarılı olduğu anlamına gelmez. Kullanıcılar, hızlı, güvenli ve kolay kullanılabilen uygulamalar beklerler. Bu nedenle, performans, güvenlik ve kullanılabilirlik testleri, sürüm kalitesini sağlamak için vazgeçilmezdir. Bir özellik, tüm fonksiyonel testlerden geçse bile, eğer yoğun yük altında yavaşlıyorsa veya yanıt vermiyorsa, üretim ortamında başarısız olacaktır. Performans testleri (yük testi, stres testi, hacim testi), uygulamanın belirli bir kullanıcı veya veri yükü altında nasıl davrandığını ölçer. Apache JMeter, K6 veya Gatling gibi araçlar, bu tür testleri simüle etmek için kullanılabilir. Bu testler, sistemin darboğazlarını (bottlenecks) ve ölçeklenebilirlik sorunlarını ortaya çıkararak, canlıya çıkmadan önce düzeltilmesini sağlar. Benzer şekilde, güvenlik testleri (sızma testleri, güvenlik açığı taraması), uygulamanın potansiyel güvenlik açıklarını (SQL enjeksiyonu, XSS, kimlik doğrulama zayıflıkları vb.) belirleyerek, kötü niyetli saldırılara karşı korunmasını sağlar. OWASP ZAP veya Burp Suite gibi araçlar, bu süreçte önemli rol oynar. Son olarak, kullanılabilirlik (usability) testleri, uygulamanın kullanıcılar için ne kadar kolay ve sezgisel olduğunu değerlendirir. Fonksiyonel olarak doğru çalışan ancak karmaşık bir arayüze sahip bir uygulama, kullanıcılar tarafından benimsenmeyebilir. Bu testler, genellikle gerçek kullanıcılarla yapılan gözlem ve geri bildirim oturumları şeklinde gerçekleştirilir. Tüm bu test türleri, yazılımın sadece teknik olarak değil, aynı zamanda iş değeri ve kullanıcı memnuniyeti açısından da başarılı olmasını sağlamak için bir bütün olarak ele alınmalıdır. Bir sürümün “başarılı” sayılması için, bu boyutların her birinde belirli bir kalite seviyesine ulaşması gerekir.

Sürekli Entegrasyon ve Sürekli Dağıtım (CI/CD) Süreçlerini Güçlendirmek

Modern yazılım geliştirme pratiklerinde, sürekli entegrasyon (CI) ve sürekli dağıtım (CD) süreçleri, yazılım kalitesini artırmak ve sürüm döngülerini hızlandırmak için merkezi bir rol oynar. Ancak, “testler geçti ama sürüm bozuk” senaryosunun yaşanması, CI/CD boru hatlarının (pipelines) sadece otomatik testleri çalıştırmaktan öteye geçmesi gerektiğini göstermektedir. Etkili bir CI/CD stratejisi, testlerin doğru zamanda, doğru ortamda ve doğru kapsamda çalıştırılmasını sağlamalıdır. Bu süreçler, kodun her değişikliğinde otomatik olarak tetiklenerek erken geri bildirim sağlamalı, olası hataları üretim ortamına ulaşmadan tespit etmeli ve dağıtım sürecini güvenilir hale getirmelidir. Bu bölümde, CI/CD süreçlerini nasıl güçlendirebileceğimizi ve test otomasyonunu bu süreçlere daha entegre bir şekilde nasıl dahil edebileceğimizi inceleyeceğiz.

Otomatik Testlerin CI/CD Hattına Entegrasyonu

CI/CD boru hattı, bir yazılımın kaynak kod deposundan (repository) üretim ortamına kadar olan tüm yolculuğunu otomatikleştiren omurgadır. Bu hattın en kritik aşamalarından biri, otomatik testlerin entegrasyonudur. Ancak, çoğu zaman bu entegrasyon sadece birim testleri ve belki birkaç temel entegrasyon testi ile sınırlı kalır. Daha sağlam bir yaklaşım için, CI/CD hattı, birim testlerinin yanı sıra, statik kod analizi (static code analysis), güvenlik açığı taramaları (vulnerability scans), daha kapsamlı entegrasyon testleri ve hatta seçilmiş kritik uçtan uca (E2E) testleri de içermelidir. Her kod değişikliği, bu testlerin tamamını veya ilgili bir alt kümesini tetiklemelidir. Örneğin, bir çekme isteği (pull request) açıldığında, önce birim testleri ve statik analiz çalışmalı; kod birleştirildiğinde (merged), daha uzun süren entegrasyon ve E2E testleri ile performans testlerinin bir kısmı devreye girmelidir. Bu katmanlı yaklaşım, hataların mümkün olan en erken aşamada tespit edilmesini sağlar. Ayrıca, testlerin paralel çalıştırılması ve test sonuçlarının hızlı bir şekilde geri bildirim olarak geliştiricilere ulaştırılması, geliştirme hızını düşürmeden kaliteyi artırır. Bir testin başarısız olması durumunda, boru hattının otomatik olarak durması ve ilgili ekibe bildirim gönderilmesi, hatalı kodun daha ileri aşamalara geçmesini engeller. Aşağıdaki örnek, bir CI/CD boru hattında farklı test aşamalarının nasıl tanımlanabileceğini göstermektedir:

    # Örnek bir CI/CD aşaması tanımı (YAML benzeri)
    stages:
      - build
      - test
      - deploy

    test_stage:
      stage: test
      script:
        - echo "Birim testleri çalıştırılıyor..."
        - npm test --unit
        - echo "Entegrasyon testleri çalıştırılıyor..."
        - npm test --integration
        - echo "Uçtan uca testler (smoke tests) çalıştırılıyor..."
        - cypress run --spec "cypress/integration/smoke-tests/*.spec.js"
        - echo "Statik kod analizi yapılıyor..."
        - sonar-scanner
      only:
        - merge_requests
        - master
      

Bu örnekte görüldüğü gibi, farklı test türleri ayrı adımlar olarak tanımlanmış ve belirli koşullara göre tetiklenmektedir. Bu, boru hattının hem hızlı hem de kapsamlı olmasını sağlar.

Geriye Dönük Uyumluluk ve Versiyon Yönetimi

Yeni bir özellik geliştirilirken veya mevcut bir kodda değişiklik yapılırken, mevcut işlevselliğin bozulmaması, yani geriye dönük uyumluluğun (backward compatibility) korunması kritik öneme sahiptir. “Testler geçti ama sürüm bozuk” durumunun bir başka yaygın nedeni de, yeni kodun mevcut sistemle beklenmedik etkileşimlere girmesi ve regresyon hatalarına (regression bugs) yol açmasıdır. Bu tür sorunları önlemek için güçlü bir regresyon test süiti oluşturmak ve bunu CI/CD sürecine entegre etmek şarttır. Regresyon testleri, daha önce doğru çalıştığı bilinen işlevlerin, yeni değişikliklerden sonra da doğru çalışmaya devam ettiğini doğrular. Bu testler, genellikle otomatikleştirilmiş olup, her kod birleştirmesinde veya sürüm öncesinde çalıştırılmalıdır.

Ayrıca, API’ler ve harici servislerle entegrasyonlar söz konusu olduğunda, versiyon yönetimi (versioning) büyük önem taşır. Bir API’de yapılan değişikliklerin, bu API’yi kullanan diğer servisleri veya uygulamaları etkilememesi için dikkatli bir versiyonlama stratejisi izlenmelidir (örneğin, Semantik Versiyonlama). Sözleşme testleri (contract testing), farklı servisler arasındaki arayüz sözleşmelerinin (interface contracts) bozulmadığını otomatik olarak kontrol ederek bu tür entegrasyon sorunlarını önlemeye yardımcı olabilir. Pact gibi araçlar, servisler arasındaki sözleşmeleri tanımlamak ve doğrulamak için kullanılır. Son olarak, özellik bayrakları (feature flags) veya geçiş anahtarları (toggle switches), yeni özellikleri üretim ortamında kontrollü bir şekilde etkinleştirmeye veya devre dışı bırakmaya olanak tanır. Bu sayede, potansiyel olarak sorunlu bir özellik, tüm kullanıcılara açılmadan önce küçük bir kullanıcı grubuyla test edilebilir veya bir sorun durumunda hızla geri alınabilir. Bu kontrollü dağıtım stratejileri, sürüm riskini önemli ölçüde azaltır ve “bozuk sürüm” senaryolarının etkisini minimize eder.

İnsan Faktörü ve Ekip İçi İletişim

Yazılım geliştirme süreçlerinde teknoloji ve otomasyon ne kadar ilerlerse ilerlesin, insan faktörü ve ekip içi iletişim, nihai ürünün kalitesinde belirleyici bir rol oynamaya devam eder. “Testler geçti ama sürüm bozuk” gibi durumlar, genellikle teknik eksikliklerin yanı sıra, yanlış anlaşılmalar, eksik tanımlar ve zayıf iletişimden de kaynaklanır. Bir ekibin tüm üyeleri, bir özelliğin “bitti” olarak kabul edilmesi için gereken kriterler konusunda aynı anlayışa sahip olmalı ve sorunlar ortaya çıktığında şeffaf bir şekilde işbirliği yapabilmelidir. Bu bölümde, insan faktörünün ve ekip içi iletişimin sürüm kalitesi üzerindeki etkilerini ve bu alanlarda nasıl iyileştirmeler yapabileceğimizi ele alacağız.

Tanımların Senkronizasyonu: “Bitti” Ne Demek?

Bir yazılım projesinde, “bitti” (done) kelimesi herkes için aynı anlama gelmeyebilir. Geliştirici için kodun yazılıp birim testlerinden geçmesi “bitti” anlamına gelirken, test mühendisi için tüm test senaryolarının başarılı olması, ürün sahibi için ise özelliğin tüm gereksinimleri karşılaması ve kullanıcılar tarafından kabul edilebilir olması “bitti” anlamına gelebilir. Bu farklı tanımlar, sürüm öncesinde beklentilerin yanlış yönetilmesine ve dolayısıyla “geçen testlere rağmen bozuk sürüm” senaryolarına yol açabilir. Bu sorunu çözmek için, Agile metodolojilerinde sıkça kullanılan “Bitti Tanımı” (Definition of Done – DoD) kavramını benimsemek kritik öneme sahiptir. DoD, bir iş öğesinin (örneğin bir kullanıcı hikayesi veya görev) tamamlanmış sayılması için karşılanması gereken tüm kriterleri açıkça belirleyen bir kontrol listesidir. Bu kriterler şunları içerebilir:

• Kod incelendi (code review yapıldı).
• Birim testleri yazıldı ve geçti.
• Entegrasyon testleri yazıldı ve geçti.
• Uçtan uca test senaryoları güncellendi ve geçti.
• Performans testleri yapıldı ve kabul edilebilir sınırlar içinde.
• Güvenlik taramaları yapıldı ve kritik açık bulunmadı.
• Dokümantasyon güncellendi.
• Ürün sahibinden onay alındı.

Bu tanımın ekip içindeki herkes tarafından kabul edilmesi ve uygulanması, bir özelliğin veya sürümün gerçek kalitesini sağlamak için esastır. DoD, ekibin her üyesinin aynı hedefe odaklanmasını sağlar ve testlerin sadece teknik bir gereklilik olmaktan çıkıp, ürün kalitesinin ayrılmaz bir parçası haline gelmesine yardımcı olur. Ek olarak, “bozuk” veya “hatalı” kelimelerinin de ekip içinde net bir tanımının olması gerekir. Bir hata nedir? Hangi durumda bir sorun kritik olarak kabul edilir? Bu tür tanımlar, sorunların önceliklendirilmesini ve çözülmesini kolaylaştırır.

Post-Mortem Analizleri ve Öğrenme Kültürü

Her ne kadar önleyici tedbirler alınsa da, üretim ortamında sorunlar yaşanması kaçınılmazdır. Önemli olan, bu sorunlardan ders çıkarmak ve gelecekte benzer durumların yaşanmasını engellemektir. İşte bu noktada post-mortem analizleri (veya kök neden analizleri) devreye girer. Bir sürüm başarısız olduğunda veya üretimde kritik bir sorun yaşandığında, “suçlu aramak” yerine “ne oldu, neden oldu, bir daha olmaması için ne yapabiliriz?” sorularına odaklanan, suçlamadan uzak (blameless) bir post-mortem analizi yapmak çok önemlidir. Bu analizler, sorunun gerçek kök nedenini (root cause) bulmayı, soruna yol açan birden fazla faktörü belirlemeyi ve gelecekte benzer sorunları önlemek için uygulanabilir iyileştirme adımları tanımlamayı hedefler. Bir post-mortem toplantısı genellikle şu adımları içerir:

1. Sorunun kronolojisi ve etkisi.
2. Sorunun nasıl tespit edildiği ve çözüldüğü.
3. Kök neden analizi (5 Neden tekniği gibi).
4. Alınacak dersler ve uygulanacak eylemler (action items).

Bu eylemler, yeni test senaryoları yazmaktan, CI/CD boru hattını güncellemeyi, ekip eğitimleri düzenlemeye veya süreçleri iyileştirmeye kadar geniş bir yelpazeyi kapsayabilir. Şeffaf post-mortem analizleri ve bu analizlerden öğrenilen derslerin ekip içinde açıkça paylaşılması, bir “öğrenme kültürü”nün oluşmasına katkıda bulunur. Bu kültür, hataların birer öğrenme fırsatı olarak görülmesini sağlar ve ekibin sürekli olarak süreçlerini ve ürün kalitesini iyileştirmesine olanak tanır. Unutulmamalıdır ki, her hata, gelecekte daha sağlam ve güvenilir yazılımlar geliştirmek için değerli bir geri bildirim kaynağıdır.

Vaka Analizi: Başarısız Bir Sürümün Anatomisi

Şimdiye kadar ele aldığımız teorik bilgileri somutlaştırmak adına, “236 test geçti ama sürüm hala bozuk” senaryosuna dair gerçekçi bir vaka analizi yapalım. Bu senaryo, bir finans teknolojileri (fintech) şirketinin mobil bankacılık uygulamasında yaşanan kurgusal ama olası bir durumu ele almaktadır. Şirket, kullanıcı deneyimini iyileştirmek ve yeni özellikler eklemek amacıyla uygulamanın önemli bir güncellemesini hazırlamaktadır. Geliştirme ekibi, Agile prensiplere uygun olarak çalışmakta, kapsamlı birim ve entegrasyon testleri yazmakta ve CI/CD süreçlerini aktif olarak kullanmaktadır. Sürüm öncesi tüm testler yeşil yanmış, boru hattı başarılı bir şekilde tamamlanmış ve ekip, yeni sürümü güvenle canlıya almıştır.

Senaryo: Mobil Bankacılık Uygulaması Güncellemesi

Fintech şirketi “HızlıBank”, mobil uygulamasının 3.2.0 versiyonunu yayınladı. Bu versiyon, yeni bir “Hızlı Kredi Başvurusu” özelliği ve mevcut “Para Transferi” ekranında bazı UI/UX iyileştirmeleri içeriyordu. Sürüm öncesi, 500’den fazla birim testi, 150 entegrasyon testi ve 10 temel uçtan uca (E2E) “smoke” testi başarıyla geçti. CI/CD boru hattı, kod kalitesi analizleri ve güvenlik taramalarını da içeriyordu ve hepsi yeşil ışık yaktı. Ekip, her şeyin yolunda olduğunu düşünerek sürümü App Store ve Google Play’de yayınladı.

Sorun Ortaya Çıkıyor:

Sürüm canlıya alındıktan yaklaşık 2 saat sonra, müşteri hizmetleri ekibine art arda şikayetler gelmeye başladı. Kullanıcılar, “Hızlı Kredi Başvurusu” özelliğini kullanırken, belirli bir senaryoda (örneğin, daha önce red almış bir kullanıcı, belirli bir kredi kartı borcuyla başvurmaya çalıştığında) uygulamanın donduğunu veya aniden kapandığını bildiriyordu. Daha da endişe verici olanı, mevcut “Para Transferi” özelliğinde de, özellikle yüksek tutarlı transferlerde (örneğin 50.000 TL üzeri), transferin başarılı göründüğü ancak alıcıya ulaşmadığına dair şikayetler gelmeye başladı. Uygulama logları incelendiğinde, bu senaryolarda beklenmedik bir hata fırlatıldığı (exception) görülüyordu.

Kök Neden Analizi:

1. “Hızlı Kredi Başvurusu” Hatası:
   • Test Kapsamı Eksikliği: Yeni özellik için yazılan birim ve entegrasyon testleri, genellikle “mutlu yol” (happy path) senaryolarına odaklanmıştı. Daha önce red almış kullanıcıların durumu veya belirli kredi kartı borcu kombinasyonları gibi kenar durumlar (edge cases) için yeterli test senaryosu yazılmamıştı.
   • Veri Farklılığı: Test ortamındaki veritabanında, bu özel durumları tetikleyecek yeterince karmaşık veya gerçekçi kullanıcı profili verisi bulunmuyordu. Üretim ortamındaki daha zengin ve çeşitli kullanıcı verileri, bu gizli hatayı ortaya çıkardı.
   • Üçüncü Parti API Etkileşimi: Kredi başvurusu, bir üçüncü parti kredi puanlama servisiyle entegreydi. Test ortamındaki mock (sahte) servis, bu özel senaryolarda üretim servisinin döndüğü spesifik hata kodunu simüle etmiyordu. Üretimdeki gerçek API’den gelen beklenmedik bir hata kodu, uygulamanın çökmesine neden oluyordu.
2. “Para Transferi” Hatası:
   • Çevre Farklılığı (Veritabanı Trigger’ı): “Para Transferi” ekranındaki UI/UX iyileştirmeleri sırasında, arka uç ekibi farkında olmadan, veritabanında yüksek tutarlı transferler için tanımlanmış bir “trigger”ı (tetikleyici) etkileyen bir kolon adını değiştirmişti. Bu trigger, test ortamında mevcut değildi veya test veritabanı şeması güncellenmediği için testlerde tetiklenmiyordu. Üretim ortamında ise bu trigger, belirli bir eşiğin üzerindeki transferleri ek bir doğrulama sürecine sokmak için tasarlanmıştı ve kolon adı değişikliği nedeniyle çalışamaz hale gelmişti. Sonuç olarak, transfer işlemi veritabanında tamamlanmıyor, ancak uygulama tarafında başarılı mesajı dönüyordu.
   • Regresyon Testi Eksikliği: Mevcut “Para Transferi” özelliğine yönelik regresyon testleri vardı, ancak bu testler genellikle UI seviyesinde basit transferleri kontrol ediyordu ve veritabanı trigger’ının doğru çalıştığını veya yüksek tutarlı transferlerin tüm adımlarını kapsayan derinlemesine bir test içermiyordu.

Alınan Dersler ve İyileştirmeler:

HızlıBank ekibi, acil bir geri alma (rollback) işlemi gerçekleştirdi ve detaylı bir post-mortem analizi yaptı. Bu olaydan sonra şu iyileştirmeleri uygulamaya karar verdiler:

• Kapsamlı Test Senaryoları: Özellikle yeni özellikler için sadece “mutlu yol” değil, tüm kenar durumları, hata senaryoları ve negatif test senaryolarını kapsayan daha detaylı test senaryoları yazılacak.
• Üretim Benzeri Test Ortamları: Test ortamları, üretim ortamına mümkün olduğunca yakın hale getirilecek. Veritabanı şemaları, konfigürasyonlar ve üçüncü parti servislerin davranışları daha gerçekçi bir şekilde taklit edilecek veya gerçek servislerin sınırlı erişimli test ortamları kullanılacak.
• Sözleşme Testleri (Contract Testing): Üçüncü parti servislerle olan entegrasyonlar için sözleşme testleri uygulanacak. Bu, API’lerin beklendiği gibi davrandığını ve değişen davranışların erken tespit edilmesini sağlayacak.
• Gelişmiş Regresyon Testleri: Mevcut kritik özellikler için daha derinlemesine regresyon testleri oluşturulacak. Bu testler, sadece UI etkileşimlerini değil, aynı zamanda arka uçtaki veritabanı ve servis etkileşimlerini de kontrol edecek.
• CI/CD Hattına Daha Fazla Test: CI/CD boru hattına, özellik bayrakları ile kontrollü olarak, daha kapsamlı E2E testleri ve performans testlerinin erken aşamaları entegre edilecek.
• “Bitti Tanımı”nın Gözden Geçirilmesi: Ekibin “Bitti Tanımı” (Definition of Done) güncellenerek, performans, güvenlik ve kapsamlı regresyon testlerinin de bu tanıma dahil edilmesi sağlandı.
• Eğitim ve Bilgi Paylaşımı: Ekip içinde veritabanı trigger’ları, API versiyonlama ve karmaşık senaryo testleri konularında eğitimler düzenlendi.

Bu vaka analizi, testlerin başarılı olmasının tek başına yeterli olmadığını, ancak kapsamlı bir test stratejisinin, tutarlı ortamların ve güçlü bir ekip içi iletişimin birleşimiyle gerçek yazılım kalitesine ulaşılabileceğini açıkça göstermektedir.

Sonuç

“236 test geçti ama sürüm hala bozuk” ifadesi, yazılım geliştirme dünyasında derinlemesine düşünülmesi gereken bir paradoksu temsil eder. Bu durum, yalnızca teknik bir sorun olmaktan öte, test stratejilerimizin, CI/CD süreçlerimizin, ekip içi iletişimimizin ve hatta “kalite” tanımımızın bütünsel bir yansımasıdır. Başarılı test sonuçları, bir yazılımın belirli yönlerinin doğru çalıştığını gösterse de, sistemin gerçek dünya koşullarında, farklı entegrasyonlarla ve beklenmedik kullanıcı davranışlarıyla nasıl etkileşime girdiğini her zaman tam olarak yansıtmaz. Bu makalede, bu tür sorunların kök nedenlerini, yani test kapsamının yetersizliğini, geliştirme ve üretim ortamları arasındaki farklılıkları ve karmaşık entegrasyon sorunlarını detaylı bir şekilde inceledik. Ardından, bu sorunları aşmak için kapsamlı test stratejileri geliştirmeyi, birim testlerinden uçtan uca testlere kadar tüm test piramidini doğru bir şekilde kullanmayı, performans ve güvenlik testlerinin önemini vurguladık. CI/CD süreçlerinin sadece testleri çalıştırmakla kalmayıp, aynı zamanda tutarlı ortamlar sağlamak ve geriye dönük uyumluluğu güvence altına almak için nasıl güçlendirilmesi gerektiğini ele aldık. Son olarak, insan faktörünün ve ekip içi iletişimin kritik rolünü, “bitti” tanımının senkronizasyonunu ve hatalardan ders çıkarmak için post-mortem analizlerinin önemini vurguladık. Unutmayalım ki, mükemmel yazılım yoktur, ancak sürekli iyileştirme ve öğrenme kültürüyle, kullanıcılarımıza daha güvenilir ve değerli ürünler sunabiliriz. Yazılım kalitesi, tek bir test veya tek bir otomasyon aracıyla değil, bütünsel bir yaklaşımla elde edilir.

Sıkça Sorulan Sorular

1. Testlerimin hepsi geçiyorken sürüm neden hala bozuk olabilir?

Bunun birkaç nedeni olabilir: Test kapsamının yetersiz olması (gerçek dünya senaryolarını, kenar durumlarını veya negatif senaryoları kapsamaması), test ortamı ile üretim ortamı arasındaki farklılıklar (veritabanı versiyonları, konfigürasyonlar), karmaşık entegrasyon sorunları (üçüncü parti servislerle etkileşimler) veya performans/güvenlik gibi fonksiyonel olmayan gereksinimlerin yeterince test edilmemesi.

2. Test kapsamımı nasıl artırabilirim?

Kapsamlı bir test stratejisi benimseyin. Birim testlerinin yanı sıra, entegrasyon testleri, uçtan uca (E2E) testler, API testleri, performans testleri, güvenlik testleri ve kullanılabilirlik testlerini de geliştirme sürecinize dahil edin. Ayrıca, test senaryolarınızı sadece “mutlu yol” değil, kenar durumları ve hata senaryolarını da kapsayacak şekilde genişletin.

3. CI/CD süreçleri bu tür sorunları nasıl önleyebilir?

CI/CD boru hattınızı, kodun her değişikliğinde birim, entegrasyon, statik analiz, güvenlik taramaları ve hatta hafif E2E testleri gibi çeşitli testleri otomatik olarak çalıştıracak şekilde yapılandırın. Ortamlar arası tutarlılığı sağlamak için kapsayıcılaştırma (Docker) ve altyapı kodu (IaC) araçlarını kullanın. Özellik bayrakları (feature flags) ile kontrollü dağıtım yaparak riskleri azaltın.

4. Ekip içi iletişimin rolü nedir?

Ekip içi iletişim, yazılım kalitesi için kritik öneme sahiptir. Tüm ekip üyelerinin “Bitti Tanımı” (Definition of Done) konusunda aynı anlayışa sahip olması, beklentilerin netleşmesini sağlar. Sorunlar ortaya çıktığında, suçlamadan uzak post-mortem analizleri yapmak ve bu analizlerden öğrenilen dersleri paylaşmak, ekibin sürekli olarak süreçlerini iyileştirmesine ve benzer hataların tekrar etmesini önlemesine yardımcı olur.

5. Küçük ekipler için bu kadar kapsamlı test mümkün mü?

Evet, mümkündür. Küçük ekipler, test stratejilerini önceliklendirmeli ve otomasyona yatırım yapmalıdır. Her test türünü aynı anda uygulamak yerine, en kritik risk alanlarına odaklanarak kademeli bir yaklaşım izlenebilir. Örneğin, önce sağlam bir birim ve entegrasyon testi altyapısı kurmak, ardından en kritik kullanıcı akışları için E2E testleri eklemek ve zamanla diğer test türlerini genişletmek iyi bir başlangıç olabilir. Otomasyon araçları, küçük ekiplerin bile geniş bir test kapsamını düşük maliyetle yönetmesine olanak tanır.

#YazılımKalitesi #TestOtomasyonu #DevOps #CICD #SürümYönetimi