Yazılım Hatalarının Neden Olduğu Mali Hasar
Bir yazılım mühendisi olarak hatalar günlük hayatımın bir parçası. Yazılım hataları yüzünden geciken projeler istisnadan çok normaldir. Sonuç olarak geciken projeler yüksek teknik maliyete neden olur.
Ancak, daha iyi bir test stratejisi sorunu çözebilir. Ancak yazılım geliştirmede, test bütçesi genellikle özellik sayısı arttıkça ayırılan azaltılan ilk bütçedir.
Yazılım Hatalarından Kaynaklanan Ekonomik Hasar
Yazılım hatalarının neden olduğu finansal hasar nedir? Tricentis, 2017 yılında yazılım hatalarına ilişkin bir rapor yayınlamıştı. Şirketlerin yaklaşık 1,7 trilyon ABD doları değerinde yazılım hatasıyla karşılaştığı sonucuna varıldı. Bu, nüfusun 3.6 milyarını etkiledi.
Bir vaka çalışmasına göz atalım. 2012 yılında, milyonlarca hisse senedi alış-verişi yapan bir yazılım güncellemesi sırasında Knight Capital Group’un bir sunucusu unutuldu. Sonuç olarak, işlemler kısa sürede yarım milyar doları aştı. Şirket sahipler şirketi 400 milyonla kefaletle serbest bırakıldı ve hisse senedi fiyatı iki gün içinde %75 düştü. Bu uç bir örnek, ancak tek bir durum değil.
%75 olmasına bile gerek yok. Şirketin dünya çapında en değerli olduğu düşünüldüğünde, yalnızca %3 bile büyük bir meblağ büyük kayıplara neden olabilir. Otopilot yazılımıyla bağlantılı olduğundan şüphelenilen son trajik Tesla kazası durumunda, %3 Tesla stok düşüşü yaklaşık 20 milyar dolar olarak gerçekleşti. Bu, küçük bir ulusun GSYİH’sini aşıyor.
‘Ama Daha Sonra Düzeltebiliriz’
Evet tabi. Ancak daha sonra düzeltmenin maliyeti çok daha yüksektir. Çeşitli aşamalarda keşfedilen bir hata, daha fazla çalışmaya yol açar:
- Gereksinimler aşaması: Gereksinimlerin değiştirilmesi gerekiyor. Maliyetler minimumdur.
- Geliştirme aşaması: Geliştirme süresi uzundur. Maliyetler, hatanın türüne ve keşfedilme şekline göre değişir.
- Test aşaması: Bir test uzmanı sorunu tespit ederse, maliyetler test uzmanının sorunu test etme, belgeleme ve iletme zamanına göre belirlenir. Üstelik, geliştiricinin sorunu düzeltme zamanı da maliyetlere eklenir.
- Müşteri Testi / UAT: Müşterinin sorunları test etmek ve iletmek için ihtiyaç duyduğu zamanla maliyetler artar. Genellikle sorun, sorunu doğrulamak ve gerçek bir hata olduğundan emin olmak için teste geri döner. Daha sonra geliştiricinin sorunu düzeltmesi gerekir.
- Üretim: Bir son kullanıcı tarafından bir hata fark edilir ve rapor edilirse, maliyetler yine daha yüksektir. Bu, sorunu izleme ve inceleme ihtiyacından kaynaklanmaktadır. Ek olarak, sorunu çözmek için bir üretim dağıtımı gereklidir. Sorunun çözülmesi operasyonel kuruluma bağlıdır; dakikalar veya günler arasında değişikli gösterebilir.
Gördüğünüz gibi, hatalarla ilgili maliyetler her adımda artıyor.
Teknik Borçtan Kaçınmak İçin Bir Çözüm
Test, ikincil bir öncelik olmamalıdır. Testin “Daha sonra gerçekleştirebiliriz” veya “daha fazla zamanımız olduğunda” yapmanız gereken bir şey değil, projenin erken bir aşamasında yapmanız gerekir.
Test, en iyi uygulamaların geliştirilmesi burada büyük bir rol oynar. Test odaklı geliştirme için yeterli zamanınız olduğundan emin olun. Uçtan uca testleri de kapsadığınızdan emin olun.
Testin sonuna doğru, gelecekte sorunların ortaya çıkmamasını sağlamak için ele alınması gereken birkaç soru var:
- Uygulama çalışıyor mu? Parçalar beklendiği gibi çalışmıyorsa, bu konuda ne yapılması planlanıyor?
- Tüm özellikler olması gerektiği gibi çalışıyor mu?
- Uygulama yüksek trafiği yönetebilir mi?
- Kullanıcıları tehlikeye atacak herhangi bir risk var mı?
- Uygulama kolaylıkla kullanılabilir mi?
Ayrıca bir yazılım test felsefesi geliştirmek de zorunludur. Bu, bir test kültürü geliştirmeyi, bir grup standart test hazırlık görevi oluşturmayı, test metodolojilerini uygulamayı, test sürecinin etkinliğini artırmayı ve nihai sonuçları kullanmanın uygun yolunu içerir.
Kaynak: Peter – Financial Damage Caused by Software Bugs
