Bloga geri dön
Bir bankacılık uygulamasından para transferi yaptığımızda, navigasyon bizi doğru adrese ulaştırdığında ya da hastanede randevumuzu birkaç saniyede alabildiğimizde çoğumuz bunun doğal bir süreç olduğunu düşünürüz. Arka planda o çarkların nasıl döndüğünü, o sistemin sorunsuz çalışması için kaç kişinin ter döktüğünü pek sorgulamayız.
Peki ya o sistem kritik bir anda hata verirse?
Bazen bu sadece birkaç dakikalık bir ekran yenileme sürecidir, güler geçeriz. Ancak bazı sistemlerde o tek bir hata; milyonlarca dolarlık zarara, prestij kaybına veya insan hayatını riske atan sonuçlara yol açabilir.
Yazılım testini çoğunlukla "uygulamadaki bug'ları bulma faaliyeti" olarak basitleştirirler. Oysa işin mutfağında olanlar bilir; süreç bundan çok daha derin. Amaç sadece mevcut hataları yakalamak değil; olası riskleri daha tasarım aşamasında öngörmek, ürünün iş gereksinimlerini doğru karşıladığından emin olmak ve günün sonunda son kullanıcıya güven veren bir ürün teslim etmektir.
Bu vizyonu anlamanın en iyi yolu da teorik tanımlara boğulmak yerine, yazılım dünyasının dönüm noktası olan gerçek krizlerine bakmaktır.
1996 yılında Avrupa Uzay Ajansı’nın geliştirdiği Ariane 5 roketi, fırlatıldıktan kısa süre sonra kontrolden çıktı ve kendini imha etmek zorunda kaldı.
İlk bakışta insan donanımsal bir roket arızası düşünebilir. Ancak incelemeler çok tanıdık bir hatayı gösterdi: Önceki Ariane 4 projesinde yıllarca tıkır tıkır çalışan bir yazılım bileşeni, yeni roketin çalışma koşulları analiz edilmeden aynen kopyalanmıştı. Yeni uçuş profili, eski sistemin hiç görmediği veri değerleri üretince yazılımda taşma (overflow) hatası yaşandı.
Bu olay bize teknik bir hatadan fazlasını anlatıyor. Yazılım geliştirirken daha önce yazılmış, test edilmiş ve "güvenli" kabul edilen kodları yeniden kullanmayı severiz. Ancak gereksinimler değiştiğinde veya sistem yeni koşullara adapte edildiğinde, o eski güvenli kod en büyük risk haline gelebilir.
Ariane 5, Görsel 1
Bir QA mühendisi olarak kendimize sormamız gereken ilk soru tam olarak şudur:
"Bu bileşen geçmişte çalışıyordu ama yeni sistemin dinamiklerine ve yüküne hazır mı?"
Bazen analiz aşamasında sorulan bu tek bir soru, production (canlı ortam) sonrasında yazılacak onlarca test senaryosundan çok daha hayat kurtarıcıdır.
1999 yılındaki Mars Climate Orbiter görevinin başarısızlığı, popüler kültürde hep bir "birim dönüşümü hatası" (biri metrik, diğeri İngiliz ölçü birimi kullandı) olarak basitleştirilir. Ama resmin arkasına geçtiğimizde durum farklıdır.
Projedeki ekipler farklı ölçü birimleriyle çalışıyordu. Yani buradaki asıl problem yazılan kodun kendisinden ziyade; gereksinimlerin, varsayımların ve teknik beklentilerin ekipler arasında ortak bir dille konuşulmamasıydı.
Bu vaka bana her zaman şu gerçeği hatırlatır: Test süreçleri kod yazıldıktan sonra değil, analizin ilk başladığı, gereksinimlerin masaya yatırıldığı o ilk toplantıda başlar. Ekipler arasındaki iletişimi netleştirmek, belirsizlikleri henüz kağıt üzerindeyken gidermek yazılım kalitesinin en kritik ayağıdır. Çünkü bazen en büyük bug satırlarca kodun içinde değil, eksik kurulan bir iletişimde saklanır.
1980’lerde Therac-25 adlı radyoterapi cihazında yaşanan yazılım hataları, hastaların aşırı dozda radyasyona maruz kalmasına neden oldu. Tıp ve yazılım dünyasının en acı derslerinden biridir bu.
Therac 25,Görsel 2
Bir e-ticaret uygulamasındaki bug en fazla siparişin gecikmesine yol açar; bir video platformundaki hata kullanıcıyı anlık kötü deneyim yaşatabilir. Ancak sağlık, savunma ya da finans sektöründeyseniz riskin boyutu tamamen değişir.
Her yazılım aynı riski taşımaz, dolayısıyla aynı şekilde de test edilemez. Bir test planı hazırlarken sadece "hangi özellikleri test edeceğiz?" diye bakmayız. Olası bir hatanın yaratacağı etkiyi ve risk analizini masaya koyarız. Risk büyüdükçe, test yaklaşımımız da derinleşir ve sıkılaşır.
2012 yılında Knight Capital’ın otomatik işlem sistemine yapılan yeni bir kod dağıtımı (deployment), sadece 45 dakika içinde şirketi yüz milyonlarca dolar zarara uğrattı.
Problem sadece yeni eklenen kodda değildi. Güncellemenin tüm sunucularda aynı anda ve eksiksiz uygulanamaması, yeterli regresyon ve doğrulama testlerinin yapılmaması krizi tetikledi.
Canlı ortama yeni bir özellik eklerken onun doğru çalışması kadar, içerideki mevcut özellikleri ve entegrasyonları etkilemediğinden emin olmak gerekir. Deneyimli test uzmanları bu yüzden sadece "Bu yeni buton çalışıyor mu?" sorusuyla yetinmez. Gözümüz hep arka plandadır:
"Yaptığımız bu değişiklik, sistemin diğer uçlarındaki hangi bağımlılıkları tetikleyebilir?"
Uzay teknolojisi, sağlık, finans... Sektörler farklı olsa da bu dört olayın ortak noktası aynıydı: Hatalar fark edildiğinde artık geri dönüş için çok geçti.
Yazılım testi, sisteme sihirli bir değnek dokundurup sıfır hatalı bir ürün garantisi vermez; zaten test teorisinde "yüzde yüz hatasızlık" diye bir şey yoktur. Ancak test süreçleri, riskleri erkenden görünür kılarak iş kararlarının daha bilinçli alınmasını sağlar.
Uluslararası standartlar (ISTQB) ve modern test yaklaşımları da testi sadece bir "hata avcılığı" olarak görmez. Test; kaliteyi sürekli değerlendiren, riskleri minimize eden ve ürüne olan güveni inşa eden yaşayan bir süreçtir.
Belki de bu yüzden, başarılı bir test uzmanının mesleki tatmini ve en büyük başarısı; son kullanıcının ruhunun bile duymadığı, arka planda sessizce çözülmesini sağladığı o kritik problemlerdir.
Teknoloji ilerledikçe yazılım hayatımızın her hücresine sızıyor. Cebimizdeki uygulamalardan bindiğimiz akıllı araçlara kadar her şey kodlarla yönetiliyor.
Bu yüzden yazılım testi, projenin sonuna eklenmiş ve aceleyle tamamlanması gereken bir "kontrol listesi" değildir. Analizden tasarıma, geliştirmeden canlıya çıkış anına kadar süren o kalite yolculuğunun ta kendisidir.
Geçmişteki büyük vakaların bize gösterdiği tek bir gerçek var: Bazen bir bug sadece bir uygulamanın çökmesine neden olur, bazen de milyonlarca insanın güvendiği bir sistemi aşağı çeker. İyi kurgulanmış bir test süreci sadece bugünün hatalarını temizlemez; yarının olası krizlerini de öngörüp engeller. Yazılım testinin gerçek değeri ve bizlerin bu mesleğe olan tutkusu da tam olarak burada yatıyor.
Kaynakça
