İçeriğe geç

Yazılım Test Günlüğü: Neden Test Ederiz?

Uzun zamandır planladığım ama bir türlü hayata geçiremediğim işler listesinde başı çeken, yıllardır yazdığım blog’umda profesyonel işim olan Test Mühendisliği ile alakalı bilgileri de paylaşmak için 2018 yılında daha düzenli bir paylaşım yapmaya karar verdim. Bu süreçte de ilk yazımı bugün yazmaya başlıyorum ve Allah izin verirse de her çarşamba günü Yazılım Testi konusunda bir yazıyı sizinle paylaşmayı planlıyorum. Bu süreçte ilk yazılarım genel olarak ISTQB ( International Software Testing Qualifications Board) tarafından standartlaştırılan sertifikasyon müfredatı kapsamında olacaktır.

[symple_highlight color=”red”]Bu konuda da sizlerin desteğini de görebilirsem gerçekten çok memnun olurum. [/symple_highlight]

Yazılım Sistemleri

Yazılım Sistemleri, artık yaşamımızın ayrılmaz bir parçası durumundadır. Bu yazıyı yazarken dahi bir yazılım aracılığı ile gerçekleştiriyoruz. Kullandığımız araçları, cihazları kullanılabilir hale getiren kodlanmış komutlar sistemi olarak kısaca tanımlayabiliriz. Buna örnek olarak kullandığımız saatlerimizden, cep telefonlarımızdan ve hatta arabalarımıza kadar hayatımızın içine giren yazılım sistemleri olmadan hayatımızı idame ettiremediğimiz bir dönemdeyiz.

Yazlım Hataları ve Nedenleri

Yazılım bu denli hayatımızzın içinde olduğunda bu yazılımların hatlarına da mutlaka denk gelmişizdir. Mesela instagramda bir dönem gün içinde karşılaştığım yazılım hatalarını fotoğraflıyordu.

Test Hata

İİnsanoğlu beşerdir ve hata yapabilir. İnsan tarafından yapılan bu hata program kodunda ve ya dokümanında (Analiz vs.) bir hatanın(Defect) oluşmasına neden olabilir. Yazılımın beklendiği gibi çalışmamasına Arıza (Failure) diyoruz. Her hata arızaya sebep olmayabilir.

Ama bu her hata insan kaynaklıdır demek değildir. İnsanlardan kaynaklanan hatalar olabildiği gibi radyasyon, manyetizma, elektronik alanlar ve kirlilik gibi çevresel koşullardan da kaynaklanabilir.

Bu hatalar para, zaman ve itibar kaybı gibi birçok probleme yol açabilir ve hatta yaralanmaya ve ölüme neden olabilir.

Gelin tarihte en çok bilinen yazılım hatalarından bir kısmına birlikte bakalım:

1. Mariner 1 Uzay Roketi: ( 28 Temmuz 1962 )

Bugün ki değeri 135 milyon dolar olan Mariner 1 Uzay Roketi 1962 yılında bir kağıda kurşun kalemle yazılan formülün bilgisayar ortamına yanlış geçirilmiş olmasından kaynaklandığı araştırmalarla bulunmuş. Bu hata Roketin fırlatma sırasında yörüngesinin dışına çıkmasına ve kontrol ekibi tarafından Atlantik Okyanusu’nda yok edilmesine neden oldu.

2. Therac-25 Tedavi Cihazındaki Hata: (1982 – 1986)

Cihazın Hata mesajı verdiği durumda sinyalin hastaya uygulanmamış olması gerekirken yüksek güçlü radyasyon hastalara uygulanmıştı. Operatörün işlemi birkaç kere tekrar etmesiyle hastalar çok büyük oranda radyasyona maruz kalmışlardı. Cihazdaki hata sonucu 1985-1987 yılları arasında 6 kişi hayatını kaybetti.

3. Kara Pazartesi: (1987)

19 Ekim 1987’de dünya borsalarının kısa bir zaman zarfında büyük değer kayıpları yaşaması sonucunda o güne Kara Pazartesi ismi verilmiştir. Düşüş Hong Kong borsasında başladı, zaman farklarıyla sırasıyla düşüşleri Avrupa borsaları ve ABD izledi. Gün sonunda Dow Jones Borsası 508 puanlık düşüşle %22.6 değer yitirdi. Büyüklü küçüklü fon sahiplerinin borsada yaşanacak aşırı yoğun işlemlere yönelik otomatik alım veya satım yapma yeteneği yüklenmiş bilgisayar programları olan Trading Programlarının hisselerin otomatik satış talimatlarını yanlış zamanda tetiklenmesiyle ortaya çıktığı belirtilmiş.

İşte bu şekilde sonuçlanan trajik olaylarla karşılaşmamak adına yazılımlar bu yüzden test edilmelidir.

Bunun yanı sıra testin yazılım geliştirme, bakım ve operasyonları sürecinde test etmek yazılımda oluşabilecek hataların önceden bulunup ortadan kaldırılması hata riskini azalttığı gibi yazılım kalitesini de arttırır. Aynı zamanda yazılımların sözleşme, yasal gereksinimleri ya da endüstriye özel standartları karşılamak için de test edilmesi gerekebilir.

Test ve Kalite:

Test sayesinde yazılımın hem fonksiyonel hem de fonksiyonel olmayan gereksinimleri (örn. güvenilirlik, kullanılabilirlik, verimlilik, sürdürülebilirlik ve taşınabilirlik) açısından kalite seviyesini belirlenebilir. Testte bulunan hataların sayısı, bu hataların önemi ve önceliği yazılımın kalitesi hakkında güven sağlamaya yardımcı olur. Doğru şekilde tasarlanmış olan ve başarıyla geçen bir test, bir yazılımdaki genel risk algısının düşmesini sağlar. Test sonucunda bulunan hatalar düzeltildiği takdirde yazılımın kalitesi artar.

Yapılan test projelerinden dersler çıkarılmalı, bir sonraki test projelerine bu tecrübeler aktarılmalıdır. Diğer projelerde bulunan hataların kök nedenleri incelenerek süreçler iyileştirilebilir ve böylece bu hataların tekrar oluşması önlenir. Sonuç olarak ileride geliştirilecek yazılımların kalitesinde iyileşme sağlanmış olur. Bu süreç kalite güvencenin bir parçasıdır. Test, yazılım geliştirme sürecine kalite güvence aktivitelerinin bir parçası olarak entegre edilmelidir.

Ne kadar test etmeliyiz?

Ne kadar testin yeterli olacağına karar vermek için riskleri, zaman ve bütçe gibi proje kısıtlarını göz önünde bulundurmak gerekir. Test sonuçları, paydaşlara yazılımın piyasaya sürülme kararı, bir sonraki yazılım geliştirme aktivitesine geçiş veya müşteriye devri gibi karar süreçlerinde yardımcı olmalı, yeterince bilgi sağlamalıdır.

Unutulmamalıdır ki hiç bir zaman %100 test mümkün değildir.

Mesela bir karakterlik sayısal giriş imkanı sunulan bir input alanının tamamen test edilebilmesi için 10 sayı dışında, 28 Büyük harf, 28 Küçük harf  ve en az 6 özel noktalama karakterlerle birlikte boşluk karakterinin de girlemediğinin test edilmesi gerekmektedir. bu da 72 tane test demektir. Bu da belki sadece bu işlem için yapılabilir görünse de bu alanlardan 15 tane olduğunu düşündüğümüzde en basitinden sadece 1 karakterlik sayısal değer girişine imkan veren 15 tane input elementi için 1080 tane test yapılması gerekir. Buna hiç bir şirketin para ve zaman ayıracağını sanmıyorum.

Kısaca ne kadar test edeceğimize paydaşlar tarafından belirlenen riskler, zaman ve bütçe kısıtlarına göre karar vermek en doğrusudur. İlerleyen yazılarımda bu kavramlara daha detaylı gireceğiz.

 

[symple_box color=”black” fade_in=”true” float=”center” text_align=”left” width=””]“A clever person solves a problem. A wise person avoids it.” (“Akıllı bir kişi bir sorunu çözer. Bilge biri bunu engeller. “) – Albert Einstein[/symple_box]

 

Kaynaklar:

  1. ISTQB Foundation Level Syllabus
  2. FOUNDATIONS OF SOFTWARE TESTING ( Dorothy Graham, Erik van Veenendaal, Isabel Evans, Rex Black)
  3. https://www.itworld.com/article/2717299/it-management/mariner-1-s–135-million-software-bug.html
  4. https://hackaday.com/2015/10/26/killed-by-a-machine-the-therac-25/
  5. https://en.wikipedia.org/wiki/Black_Monday_(1987)

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Bu site, istenmeyenleri azaltmak için Akismet kullanıyor. Yorum verilerinizin nasıl işlendiği hakkında daha fazla bilgi edinin.