Yazılım Test Süreçleri Ve Önemi
Merhaba, bu içerikte yazılım test süreçleri, önemi ve bu sürecin eksikliğinde ortaya çıkan bazı tarihi buglar yer almaktadır.
YAZILIMDAKİ HATALARIN BÜYÜK SONUÇLARA YOL AÇTIĞI BAZI TARİHİ BUGLAR
Ariane 5 Roketinin Havaya Uçması
NASA, 4 Haziran 1996’da fırlatılması planlanan Ariane 5 uzay aracını kodlarken, Ariane 4 roketinin kodlarını kopyalayarak bir hata yaptığının farkında değildi. Kalkış başladığında hızlanarak yoluna 37 saniye boyunca devam eden Ariane 5 roketi o saniyeden sonra yanlış yöne doğru 90 derece dönmeye başladı. Bu durum, roketin kendini imha etme mekanizmasını tetikledi ve uzay aracı, dünyanın en pahalı havai fişeği olarak akıllara kazındı. Bu kaza, NASA’ya aşağı yukarı 370 milyon dolara mal oldu. Tarihteki en pahalı yazılım hatalarından biri arasına giren bu kazanın sebebi, yazılımda oluşan bir bugdı. Bu bug, milyarlarca potansiyel değeri temsil edebilen 64 bit değişkeni, yaklaşık 65 bin değer alabilen 16 bit değişkene sığdırmaya çalışmasına sebep oldu.
Aşırı Dozda Radyasyon Yayan Therac-25
Therac-25 olarak bahsedilen makine, kanser hastalarının tedavisinde kullanılmak yapılması için tasarlanmıştı. Önceki modelini temel alan Therac-25’te “geliştirilmiş” bir terapi sistemi bulunuyordu. Therac-25, X ışınlarını elektron tabancası ve hastanın arasında bulunan metal bir plakayla parçacıkları çarpıştırarak tedaviyi uyguluyordu. Bir diğer geliştirme ise Therac-20’de güvenlik önlemi olarak bulunan elektromekanik güvenlik kilitlerinin yazılımsal güvenlik önlemleriyle değiştirilmesiydi. Ne yazık ki gelişim olarak görülen bu hata, Therac-20’nin kodlarında bulunan ancak fark edilemeyen hatanın Therac-25’te ortaya çıkmasına sebep oldu.
Race condition olarak bilinen bir hata, Therac-25’in yüksek güç modunda çalıştırılmasına sebep oldu. Operatörlerin bilmediği şey ise cihazın bu modda çalıştığıydı, dolayısıyla metal plakayı yerine koymadılar. Bu bug yüzünden yaklaşık 5 hastanın ağır dozda radyasyon sebebiyle hayatını kaybettiği raporlandı. Diğer hastalar ise ciddi bir şekilde yaralanarak tedavi altına alındı.
Dakikalar İçinde Kaybedilen 460 Milyon Dolar
Knight Capital Group, 1 Ağustos 2012’de yeni bir yazılım güncellemesi yapma kararı aldı. Yaptıkları yazılım güncellemesiyle otomatik olarak stok alım satımı yapmayı planlayan şirket bir anda kendisini hiç ummadığı şekilde iflasın eşiğinde buldu.
Saat 09.00 sularında New York Borsası işlemler için açıldı ve Knight Capital’ın ilk perakende yatırımcısı varlıklarını satın almak veya satmak için talimat verdi. Yalnızca 45 dakika sonra Knight Capital’ın sunucuları 4 milyon işlem gerçekleştirdi ve şirkete 460 milyon dolar kaybettirerek iflasın eşiğine getirdi. NYSE’deki bazı hisseler %300’ün üzerinde arttı. Bunun sebebi, diğer firmaların algoritmaları Knight Capital’ın bu hatasını sömürmeye başladı.
Amerikan Üssünde Patlayan Füze
1991 yılının şubat aylarında gerçekleşen Körfez Savaşı sırasında Amerika Birleşik Devletleri’nin Suudi Arabistan’ın Zahran şehrindeki üssünde bir patlama yaşandı. Al Hussein Scud ismi verilen kısa menzilli bir balistik füze hedefini tutturmayı başararak Amerikan üssünde patlamıştı. Patlamanın sebebi ise üste bulunan anti balistik füze sisteminin doğru çalışmamasıydı.
Yapılan sorgulamaların ve araştırmaların sonucunda patlama sebebinin üste bulunan anti balistik füze sisteminin bir yazılım hatası yüzünden ateşlenmemesi olduğu anlaşıldı. Orta mesafe havadan gelen füzeleri yok etmesi gereken MIM-104 Patriot, 100 saati aşkın süredir çalışıyordu ve geçen her saatte dahili saat birkaç milisaniye ileri gidiyordu.
Bir insan için inanılmaz küçük olan 0,33 saniye, Al Hussein füzesini takip etmek için yapılan bir sistem için inanılmaz büyük bir hataydı. MIM-104 Patriot, havada bir cisim olduğunu algılamayı başardı ancak bug yüzünden cismi takip edemedi ve bunun bir füze olduğunu anlayamadı. Engellenemeyen füze yüzünden üste bulunan 28 asker hayatını kaybetti.
Mars Climate Orbiter Kazası
1998 yılında fırlatılan Mars Climate Orbiter uzay aracının amacı, Mars’taki iklimi kontrol etmek ve dünyaya iletmekti ancak ne yazık ki kodlarındaki bir bug yüzünden bu görevi hiç tamamlayamadı. Birkaç ay boyunca uzayda yoluna devam eden Mars Climate Orbiter, yönlendirme hatası yüzünden tahrip oldu.
Uzay aracını Dünya üzerinde kontrol eden takımlar, imperial birimi parametrelerini kullanıyorlardı. Uzay aracının yazılımı ise hesaplamaları metrik sisteme göre yapıyordu. Bu yanlış kodlama yüzünden Mars Climate Orbiter olması gerektiği rotadan saptı ve çarpışma yaşadı. Bunun sonucunda ise Mars atmosferinde çok fazla sürtünme yaşayan araç tahrip oldu.
Bilgisayar Tarihindeki İlk Bug
Tarihe geçen ilk bilgisayar bugı, gerçek bir böceğin bir bilgisayarın içine girmesiyle ortaya çıktı. 9 Eylül 1947 tarihinde gerçekleşen bu olay, böceği bulan kişinin rapor defterine bilgisayar sisteminde ilk defa bir bug bulunduğunu yazmasıyla tarihe geçti. Bir güve, Amerikan Donanması’na ait Harvard Mark II isimli bilgisayarın içine girerek işlevini bozmuştu.
Bug kelimesi ilk kez o zaman kullanılmamıştı ancak Harvard Mark II’de böceği bulan kişilerin bu kelimeyi raporlara geçirmesi, bugün bilgisayar ve yazılım hatalarında bug kelimesini daha çok kullanmamıza sebep oldu. Bu olay biraz dalga konusu oldu ancak zaman geçtikçe bug kelimesi bilgisayar ve yazılım hatalarının ortaya çıkmasıyla daha yaygın hale geldi. Dolayısıyla fotoğrafta gördüğünüz böceğe, bugün karşımıza çıkan tüm bugların anası diyebiliriz.
Yazılım Test Süreçleri
Bir projede ihtiyaç duyulan gereksinimler veya müşterinin projede istediği gereksinimler doğrultusunda yazılım geliştirilmedir. Bu geliştirmenin sonucunda ortaya çıkan projenin gereksinimlere uygun olup olmadığını anlamak için test edilmesi gerekmektedir. Gereksinimler belirli maddelere uygun olmalıdır. Bu maddeler SMART ile özetlenmiştir.
SMART’ a göre gereksinimler;
Spesific : Açık
Measurable : Ölçülebilir
Attaninable : Uygulanabilir
Realisable : Amaca uygun
Testable : Test edilebilir olmalıdır. Doğru tanımlanmış bir gereksinimin sonucunda yapılan proje test edilme aşamasına geçmektedir.
Yazılımın kalitesini artırmak, doğruluğunu sağlamak, hata ve kayıp riskini en aza indirmek için başarılı bir test sürecinden geçmesi gerekmektedir. Kaliteli yazılımlar müşterinin beklentisini karşılayan, hata yüzdesi az, zorlu durumlara yol açmayacak yazılımlardır.
Yazılım Testine Neden Gereksinim Duyulur?
Yazılımlarda yazılımın kalitesinden, teknik sorunlardan, beklenmeyen sorunlardan veya çeşitli problemlerden kaynaklı hatalar oluşabilir. Bu hataların olması oldukça olağandır. Hataları olabildiğince minimuma indirmek için yazılımların test edilmesi gerekmektedir. Çok küçük hatalar bile bazı projelerde çok büyük sonuçlara yol açabilmektedir.
Temel olarak;
· Hataları en aza indirmek,
· Müşterinin isteğini tam ve doğru yapabilmek,
· Kaliteli yazılımlar yapabilmek,
· Geliştirme için ayrılan efor ve maliyeti etkili kullanabilmek
için yazılımın test edilmesine ihtiyaç duyulmaktadır.
Yazılım Testinin 7 İlkesi
1. Test Hataların Varlığını Gösterir
Yazılım test edildikten sonra yazılımdaki hataları gösterir. Başka hata olmadığının garantisini vermez. Daha fazla case deneyerek daha farklı hatalar yakalanabilmektedir. Beklentiyi doğru karşılayacak, büyük sorunlara yol açmayacak çok fazla case deneyerek olduğunca minimum seviyede hata verecek testler yapılmalıdır.
2. Erken Test
Testin yazılım yaşam döngüsüne uygun şekilde yapılması ve erken yapılması hatanın da önceden bulunmasını sağlayacaktır. Hatalar ne kadar erken fark edilirse hatanın düzeltilmesi için harcanacak maliyette o kadar azalmaktadır. Projenin bitiminde veya tesliminde sonra bulunan hata ile projenin başında erken test ile bulunan hatanın götürüleri bir olmayacaktır.
3. Her şeyi Kapsayan Test Mümkün değildir
Test edilen yazılımda her şeyi kapsayacak şekilde testin yapılması pek mümkün olmayacaktır. Bunu yapmaya kalkmak zamandan ve maliyetten kayba neden olacaktır. Bu yüzden Eşdeğerlik Aralık ve Sınır Değer Analizi gibi değişik test teknikleri kullanılarak belirli şartlar test edilmesi gerekmektedir.
4. Test Alan Bağımlıdır
Sektöre göre yazılımın testide farklılık göstermektedir. Savunma, Ulaşım, Enerji ve Sağlık gibi sektörlerdeki görev kritik yazılımlar için gerçekleştirilecek yazılımların testi ile Bankacılık, Sigortacılık, Seyahat, Reklam vb. alanlardaki yazılım test faaliyetleri aynı derinlikte değildir. Emniyet kritik / görev kritik yazılımlar için yazılım kapsama/test kapsama analizleri gerekirken bir reklam veya seyahat yazılımı bir e-ticaret yazılımı için gerekmeyecektir.
5. Hata Kümelemesi
Yazılımdaki hataların büyük kısmı araştırmalara ve pareto yasasına göre genellikle yazılımın bir parçasında yoğunlaşmıştır. Bu yüzden yazılımı test ederken daha etkin olabilmek için hata dağılımı doğru tahmin edilmelidir. Pareto yasasına göre yazılım %20 kısmı hataların %80’inin içerir. Bu %20 lik kısım tespit edilebildiğinde testlerimizin vurucu gücü bu modüller üzerine yoğunlaşır.
6. Antibiyotik Etkisi/Tarım İlacı Paradoksu
Aynı test senaryolarının yazılım üzerinde sürekli kontrol edilmesi yeni hataları bulamamaya sebep olacaktır. Antibiyotik etkisi veya diğer ismi ile tarım ilacı paradoksu (Pesticide Paradox) ile adlandırılan bu durum antibiyotik direnci şeklinde de ifade edilebilmektedir. Bu durumda farklı senaryolar üretilmesi gerekmektedir.
7. Hata Yokluğu Yanılgısı
Yazılımı defalarca test etmiş olmak veya tüm caseleri denemek yazılımda hata olmadığı anlamına gelmemektedir. Bunları yaptıktan sonra hata yoktur olarak düşünmek yanlış bir algıdır. Hata her zaman olabilmektedir. Bu yüzden yazılım %100 doğru çalışıyor denilmemesi gerekmektedir, mutlaka hata payı oranı bırakılması ve hata yoktur diye düşünüp yanılmaması gerekmektedir.
Yazılım Test Çeşitleri Nelerdir?
Amaca yönelik birden fazla test çeşidi bulunmaktadır. Testin süreci türleri kendi içinde farklılık göstermektedir. Çok fazla sayıda test çeşidi bulunmaktadır, en çok kullanılan ve yaygın olan test çeşitleri aşağıdaki gibidir.
1. Birim Testi
Birim testi, testin ilk turudur. Genellikle geliştirici tarafından yapılır. Kod parçası her değiştirildiğinde yapılmalıdır. Birim testi, fonksiyon hazır olduğunda veya bir modül tamamlandığında yapılır. Her bir yazılım biriminin beklendiği gibi çalıştığını doğrulama. Birim, bir uygulamanın test edilebilir en küçük bileşenidir.
2. Entegrasyon Testi
Bu test seviyesi, modüller/fonksiyonlar arasındaki arayüz kusurlarını bulmak için tasarlanmıştır. Bu özellikle faydalıdır çünkü birimlerin birlikte ne kadar verimli çalıştığını belirler. Her birim ne kadar verimli çalışırsa çalışsın, düzgün şekilde entegre edilmezse, yazılım programının işlevselliğini etkileyeceğini unutmayın. Özet olarak, Yazılım bileşenlerinin veya işlevlerinin birlikte çalışmasının sağlanmasıdır.
3. Sistem Entegrasyon Testi
Sistem testi, uygulamanın tamamının bir bütün olarak test edildiği ilk seviyedir. Bu seviyedeki amaç, sistemin belirtilen tüm gerekliliklere uyup uymadığını değerlendirmek ve Kalite Standartlarını karşılayıp karşılamadığını görmektir. Sistem testi, programın geliştirilmesinde rol oynamamış bağımsız test uzmanları tarafından gerçekleştirilir.
4. Kabul Testi
Son seviye olan Kabul testi (veya Kullanıcı Kabul Testi), sistemin yayınlanmaya hazır olup olmadığını belirlemek için gerçekleştirilir. Yazılım geliştirme yaşam döngüsü boyunca, gereksinim değişiklikleri bazen kullanıcıların amaçlanan ihtiyaçlarını karşılamayan bir şekilde yanlış yorumlanabilir.
5. İşlevsel Test
İşlevsel gereksinimlere dayalı olarak iş senaryolarını taklit ederek işlevleri kontrol etme. Kara kutu testi, işlevleri doğrulamanın yaygın bir yoludur.
6. Performans Test
Yazılımın farklı iş yükleri altında nasıl performans gösterdiğinin test edilmesi. Örneğin yük testi, gerçek hayattaki yük koşulları altında performansı değerlendirmek için kullanılır.
7. Regresyon Test
Yeni özelliklerin işlevselliği bozup bozmadığını kontrol etme. Akıl sağlığı testi, tam bir regresyon testi için zaman olmadığında, yüzey seviyesinde menüleri, işlevleri ve komutları doğrulamak için kullanılabilir.
8. Stres Test
Başarısız olmadan önce sistemin ne kadar zorlanabileceğini test etme. İşlevsel olmayan bir test türü olarak kabul edilir.
Yazılım Test Yaşam Döngüsü nedir?
Yazılım testi, STLC (Software Testing Life Cycle) olarak da bilinen yazılım testi yaşam döngüsünü takip eder.
1. İhtiyaç analizi
Yazılım testi yaşam döngüsünün bu ilk aşamasında, test ekibi, neyin test edilebilir olduğunu belirlemek için tüm gereksinim belgelerini ve tasarımları inceler.
2. Test Planlaması
Neyin test edileceği, testin nasıl yapılması gerektiği ve kimin test edeceği gibi maddeler test planlama aşamasında belirlenir. Bu maddeler gereksinimler gözden geçirildikten sonra yapılmaktadır.
3. Test Vakası Geliştirme
Bu aşamanın amacı, “nasıl” test edileceğini ayrıntılı olarak belirlemektir. Test edene her testte rehberlik etmesi için test senaryoları yazılmalıdır.
4. Ortam Kurulumu
Test ortamı, test ekibinin testleri gerçekleştireceği yazılım veya donanımın yapılandırılmasıdır.
5. Test Döngüsü Kapatma
Tüm test senaryoları çalıştırıldığında, test yöneticisi gerekli tüm testlerin tamamlandığını onaylamalıdır. Bu, bulunan kusurların analizini ve kaç tane başarılı / başarısız / atlanmış test vakası gibi diğer ölçümleri içerir. Yazılım testi yaşam Döngüsünün bu son aşaması, test projesine / sürecine ilişkin bir retrospektif de içerebilir.
6. Test Yürütme
Artık testler hazır olduğuna ve ortam kurulduğuna göre, testleri çalıştırmanın zamanı geldi. Test eden kişi, test senaryolarını kullanarak her testi yürütür, beklenen sonuçları her testin gerçek sonuçlarıyla karşılaştırır ve başarılı / başarısız / atlama olarak işaretler.
