4.2. Sektördeki Gerçek Senaryo: Mars Uydusunu Yok Eden Statik Hata

Yıl 1999. Amerikan Havacılık ve Uzay Dairesi (NASA), Mars’ın iklimini, atmosferini ve olası su izlerini incelemek üzere tam 125 milyon dolar değerindeki Mars Climate Orbiter uzay aracını fırlattı. Araç, uzayın derinliklerinde 9 ay boyunca yaklaşık 670 milyon kilometre kusursuzca yol aldı.

Mars’a varıldığında, aracın gezegenin etrafında güvenli bir eliptik yörüngeye oturabilmesi için ana motorlarını ateşleyip kritik bir frenleme manevrası yapması gerekiyordu.

Planlanan uçuş rotasına göre aracın Mars yüzeyine en fazla 140 ile 150 kilometre yaklaşması planlanmıştı. Bu irtifa, hem frenleme için idealdi hem de uydunun atmosfer sürtünmesinden zarar görmesini engelliyordu.

Ancak manevra başladıktan kısa bir süre sonra NASA kontrol merkezindeki telemetri sinyalleri aniden kesildi. Uzay aracı Mars yüzeyine 150 kilometre yerine tam 57 kilometreye kadar kontrolsüzce yaklaşmıştı. İnce Mars atmosferinin yarattığı sürtünme ve cehennemi andıran aşırı ısınma, 125 milyon dolarlık aracı saniyeler içinde metal bir alev topuna çevirerek uzayda parçaladı.

125 Milyon Dolarlık İletişim Körlüğü

NASA başmühendisleri enkazın ardından kriz masasını topladığında ortaya çıkan kök neden tüm mühendislik dünyasını dehşete düşürdü.

Sistemde iki temel yazılım modülü birlikte çalışıyordu:

  1. İtki Kontrol Yazılımı: Uzay aracının motorlarını üreten yüklenici firma (Lockheed Martin) tarafından yazılmıştı. Bu modül motorların itme gücünü İngiliz ölçü birimi olan Pound-Force saniye (lbf·s) cinsinden hesaplayıp iletiyordu.

  2. Yörünge Navigasyon Yazılımı: NASA’nın kendi mühendisleri tarafından geliştirilmişti. Bu yazılım ise gelen veriyi uluslararası bilim standardı olan metrik sistemde, yani Newton-saniye (N·s) cinsinden bekliyordu!

İşin matematiği son derece basitti: $1\text{ Pound-Force}$, yaklaşık $4.45\text{ Newton}$‘a eşitti.

İki yazılım modülü arasındaki bu tek kelimelik birim farkı yüzünden; yer kontrol yazılımı motorlara planlanandan tam 4.45 kat daha sert bir itme emri vermişti. Gemi planlanan nazik kavis yerine, doğrudan gezegenin yakıcı atmosferine kafa üstü dalmıştı.

Bilgisayarı Bile Açmadan Çözülebilecek Bir Hata

Bu felaketin en acı dersi şudur: Bu hatayı yakalamak için uydunun 9 ay boyunca uzayda yol almasına, milyonlarca kilometre mesafe kat etmesine ya da motorların fiilen ateşlenmesine (yani Dinamik Test yapılmasına) asla gerek yoktu!

Eğer proje sürecinde iki ekibin hazırladığı veri transfer sözleşmeleri ve arayüz dokümanları masaya yatırılsaydı; ISTQB standartlarında Resmi Teftiş (Formal Inspection) dediğimiz disiplinli bir Statik İnceleme uygulansaydı ne olurdu?

Bir test mühendisi, eline alacağı kırmızı bir kalemle veri transfer şartnamesindeki şu satırı okuyacaktı:

  • Modül A Çıktısı: thrust_data (Unit: lbf*s)

  • Modül B Girdisi: thrust_data (Unit: N*s)

Mühendisin o kağıt üzerindeki iki kelimenin altını çizmesi sadece 10 saniyesini alacaktı.

İşte Statik Testin (Static Testing) inanılmaz gücü tam olarak budur: Kodu derlemeden, tek bir tuşa basmadan, sistemi hiç çalıştırmadan sadece dokümanı ve kod yapısını okuyarak; canlıda yüz milyonlarca dolarlık felaketlere yol açabilecek o gizli kusurları (defect) henüz kağıt üzerindeyken yok edersin.

4. “Bir de Şöyle Düşün” (Kutu İçeriği)

💡 Bir de Şöyle Düşün: Fiş ve Priz Uyuşmazlığı

Amerika’dan satın aldığın 110 Volt ile çalışan lüks bir kahve makinesini Türkiye’deki 220 Voltluk ev prizine takmaya çalıştığını hayal et:

  • Dinamik Test (Pahalı ve Tehlikeli): Makineyi prize takıp “Aç” düğmesine basmaktır. Sonuç: Evin sigortaları atar, makine yanar ve mutfağı duman kaplar (Failure).

  • Statik Test (Bedava ve Güvenli): Kutunun üzerindeki etiketi okumaktır: “Giriş: 110V”. Ardından duvardaki prizin voltaj tablosuna bakarsın: “Şebeke: 220V”.

Makineyi prize bile takmadan, kutunun üzerindeki iki satır yazıyı okuyarak cihazın yanacağını anlarsın. Statik test; sistemi ateşe atmadan önce etiketleri, sözleşmeleri ve kod satırlarını okuma basiretidir.

5. Mini Alıştırma

Senaryo: İki farklı ekibin geliştirdiği mikroservislerin birbirine bağlandığı bir finans projesinde çalışıyorsun. Analiz toplantısında iki servisin entegrasyon dokümanını inceliyorsun (Statik Test yapıyorsun):

  • Banka Ödeme Servisi Çıktısı: transfer_amount (Transfer tutarını kuruş cinsinden tamsayı olarak gönderiyor: 15000 = 150.00 TL).

  • Mobil Bildirim Servisi Girdisi: amount (Tutarı doğrudan TL cinsinden ondalıklı bekliyor: 150.00).

Soru: Sistemi hiç çalıştırmadan sadece dokümanı okuyarak bu kusuru yakalayan bir test mühendisi olarak; bu sistem canlıya çıksaydı kullanıcı telefonuna gelen SMS’te nasıl bir arızayla (failure) karşılaşırdı ve bu statik inceleme şirketi hangi krizden kurtarmıştır?

  • Canlıdaki Arıza (Failure): 150 TL transfer yapan bir kullanıcının telefonuna: “Hesabınızdan 15.000 TL transfer edilmiştir” şeklinde yanlış bir bildirim SMS’i düşerdi.

  • Önlenen Kriz: Bu hata bankanın çağrı merkezinin dakikalar içinde kilitlenmesine, binlerce müşterinin paniğe kapılarak kartlarını iptal ettirmesine ve markaya duyulan güvenin ağır darbe almasına yol açardı. Statik test, bu devasa krizi tek bir satır kod çalıştırılmadan engellemiştir.

ÖncekiSonraki