Yazılımda Uçtan Uca Kalite: Test Seviyeleri
0

Yazılımda uçtan uca kalite serimdeki ikinci konu olan test seviyelerinden bahsedeceğim bu yazıda. Test seviyeleri dört adettir ve bunlar sırasıyla, birim testi, entegrasyon testi, sistem testi ve kabul testidir. Bu başlıkların aynısını bir önceki Test Türleri yazımda da anlatmıştım. İki başlık da, farklı şeyler olmasına rağmen yeni başlayanlar için çoğu kez kafa karışıklığına yol açabiliyor. Bu sebeple öncelikle bu farklara değinmek istiyorum.

Test Türleri ve Test Seviyeleri

Test türleri, test seviyelerinin her basamağında koşarlar. Bu sebeple çoğu birbirinden bağımsız yürüyen olaylardır diyebiliriz. Mesela ekipler bir modülü geliştirdiğinde, bir yandan performans testi yapıp bir yandan da beyaz kutu testi yapabilirler. Ancak test seviyeleri, daha geniş kapsamlı düşünülmesi gereken sıralı, uzun süreçlerdir; Mesela ekipler performans testi ve beyaz kutu testini, hem entegrasyon testleri hem de sistem testleri seviyesinde koşabilirler.

Test Seviyeleri

Yazılım yaşam döngülerinin her basamağında teste başvurmak gerekir.  Diğer bir deyişle test seviyeleri, yazılım yaşam döngülerine entegre çalışan, döngülerin her basamağında yürütülen süreçlerdir ve dörde ayrılırlar. Bunlar sırasıyla, birim (Unit), entegrasyon (Integration), sistem (System), kabul (Acceptance) testleridir.

Resim-1

Birim (Unit) Test

En küçük modüllerin test edildiği bu test türü, bileşen (Component) testi olarak da geçmektedir. Buradaki amaç uygulamayı en küçük birimlerine ayırıp, her birinin işlevini yerine getirip getirmediğini saptamaktır. Birim testinden kabul testine doğru gittikçe, karmaşıklık da artacaktır. Bu sebeple hataların bu seviyede bulunması ise ekiplere zaman ve maliyet kazandıracaktır. Birim testlerini developerlar yürütür.

Resim-2

Entegrasyon (Integration) Testi

Farklı şekillerde uygulanabilen entegrasyon testi, birimlerin birlikte doğru çalışıp çalışmadığı kontrol etmeyi amaçlar. Ancak birim testlerine kıyasla, entegrasyon testlerini ekipteki yazılım uzmanları yürütür.

Ekipler, birleştirme anlamına gelen entegrasyon testinde, birbiriyle çalışacak modülleri gruplandırır ve teste tabi tutarlar. Ayrıca Büyük Patlama (Big Bang) Testinde, tüm bileşenler tamamlanır ve test bir bütün olarak yapılır. Bu işlem öncesi herhangi bir entegrasyon testi çalıştırılmaz. Hataları bulmak zordur bu yüzden küçük sistemler için uygundur . Birden fazla modülün aynı anda test edildiği bir sistemde, hatanın nereden kaynaklı olduğunu anlamak için modüllerin tekrar birimlere ayrılması gerekir.

Resim -3

Öte yandan Arttırımlı (Incremental) Testte, ikili – üçlü modüller tamamlanır ve ekipler test ederek ilerler. Bu sebeple, hatayla başa çıkma zorluğu bigbang testine göre daha azdır. Ancak big bang karşısında incremental yöntemde, test için modüllerin bitmesine gerek olmadığından çoğunlukla zaman kaybı yaşanır. Bunun yanında, incremental testte Stub ve Driver isimli iki öge vardır. Bunlar yazılım test sürecinde yer alır ve bir modülün geçici olarak yerine geçerler. Stub ve Driverleri açıklamak gerekirse; ikisi de hazır olmayan modül/birimlerin yerine, entegrasyon testinin başarıyla yürütülebilmesi için kullanılan ögedir. Stublar aşağıdan yukarıya (Bottom-Up) yaklaşımlı testlerde birimler eksik olduğunda kullanılır. Öte yandan Driverlar, yukarıdan aşağı (Top-Down) yaklaşımda ana modül eksik olduğunda çağırılırlar.

Aşağıdan yukarıya (Bottom-Up) yaklaşımlarda, test birimden modüle doğru ilerler. Buradaki entegrasyon testlerinde, eksik birimlerin yerini doldurmak için Stublar kullanılır. Yukarıdan aşağı (Top-Down) yaklaşımlarda ise, test modülden birime doğru iner. Buradaki entegrasyon testlerinde eksik modüllerin yerini doldurmak için ise Driverlar kullanılır. Öte yandan sandiviç (Sandwich) yaklaşımında ise, test hem modülden hem de birimden eş zamanlı olarak ilerler.

Resim-4

Sistem (System) Testi

Üçüncü aşamadaki sistem testi gereksinimlere odaklanır. Tüm entegrasyonlar tamamlandıktan sonra, gereksinimlerin karşılanıp karşılanmadığı bu aşamada kontrol edilir. Bu sebeple performans, stres, yük, güvenlik gibi fonksiyonel olmayan testlerin de dahil olduğu, kapsamlı testler gerekir. Bu aşama, ürünün teslimine çok yakın olduğu için canlıya yakın ortamda test edilir.Ve bu testleri, ürün gereksinimlerine hakim test ekibi yapar.

Resim-5

Kabul (Acceptance) Testi

Kabul testleri aşamasında ekip, müşteri ile arasındaki mutabakatı sağlar. Diğer bir deyişle taraflar, ürün son kullanıcı gereksinimleri karşısında yeterli mi, taraflar arası sözleşmenin maddelerini sağlıyor mu, uçtan uca testte sistemin fonksiyonel olan/olmayan herhangi bir noktasında hata var mı, sorularına yanıt ararlar. Kabul testlerini, temelde son kullanıcı ve kalite/test ekibi yapar. Bu aşamadaki kabul kriterleri bellidir. Bu nedenle, bu aşamadaki senaryolar önceden yazılmıştır. İki türlü kabul testinden söz etmek mümkün: Alfa ve Beta Testleri.

Kabul testlerinin ilki olan alfa testi, esas olarak şirket içi yazılım kalite/test ekipleri tarafından gerçekleştirilen testtir. Ancak istenirse, kurumların anlaşmalı olduğu üçüncü şahıslar da dahil olabilirler. Alfa testinden sonra yapılan Beta testinde ise, son kullanıcılar çıkış öncesi son kontrolleri yapar. Son kullanıcılar sistemi inceler, herhangi bir sorun bulduğunda geliştiriciye bildirir.

Bu yazımda, dört ana başlığı olan yazılımda test seviyelerinden bahsettim. Bu konuyla ilgili sorularınızı  alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.

Referanslar

www.mshowto.org

R1: Software Testing Levels/ professionalqa.com

R2: Differences Between the Different Levels & Types of Testing/ reqtest.com

R4: Stubs And Drivers Demystified/QAtechnicals

R5: All About System Testing an Important Part of Our Software Testing Effort/ softwaretestinggenius.com

Kapak R: by vectorjuice/ Freepik

TAGs: software testing, software quality, functional testing, non-functional testing, test levels, integration testing, system testing, acceptance testing, stub and driver, top-down approach, bottom-up approach, bigbang approach, test nedir, test türleri

Bu İçeriğe Tepkin Ne Oldu?
  • 11
    harika_
    Harika!!
  • 0
    be_enmedim
    Beğenmedim
  • 0
    _ok_iyi
    Çok iyi
  • 1
    sevdim_
    Sevdim!
  • 0
    bilemedim_
    Bilemedim!
  • 0
    olmad_
    Olmadı!
  • 0
    k_zd_m_
    Kızdım!

Merve Algı, 1996 yılında İstanbul’da doğdum. 2016 yılında başladığım Sakarya Üniversitesi Bilgisayar Mühendisliği’nin altıncı yarıyılında eğitim amaçlı Portekiz’e gittim. Kalbimi orda bırakıp döndüm ve lisans eğitimimi tamamladım. Yarım dönem PM olarak çalıştıktan sonra test alanına yöneldim ve şimdi Yazılım Test Mühendisi olarak çalışıyorum. Boş zamanlarımda ise veri görselleştirilmesi ve makine öğrenmesi üzerine çalışmalar yapıyorum.

Yazarın Profili
İlginizi Çekebilir

Bültenimize Katılın

Tıklayın, üyemiz olun ve yeni güncellemelerden haberdar olan ilk kişi siz olun.

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