Yazılım Test Terimleri ve Açıklamaları
Bu yazımda yazılım testi alanında kullanılan terimleri ve açıklamaları hakkında peyderpey bilgi vereceğim.
Test, bir sistemin veya sistemin bileşenlerinin belirtilen gereklilikleri karşılayıp karşılamadığını öğrenmek amacıyla yapılan bir değerlendirme sürecidir.
Fonksiyonel Test: Fonksiyonel gereksinimler sistemin ne yapması gerektiğini tanımlar.
Fonksiyonel Olmayan Test: Fonksiyonel olmayan testler sistemin yapması gerekenleri “ne kadar iyi” yaptığını ölçümlemeye çalışır.
Statik Test: Yazılımın bu tür testleri, yazılım devreye alınmadan önce gerçekleştirilir. Algoritmalar, kodlar veya belgelerdeki hataları aramak için statik testler yapılır.
Dinamik Test: Yazılım tamamen derlenip sisteme yüklendikten sonra gerçekleştirilir. Dinamik testte yazılım, başka bir yazılım kullanılarak giriş ve çıkış parametrelerinin tutarlılığı için kontrol edilir.
Statik test, hataları yazılımın derlenmesinden önce bulduğundan ve kolaylıkla düzeltilebildiğinden, dinamik testten çok daha ucuzdur.
Test Seviyeleri
Birim Test — Bileşen Test — Modül Test: Yazılımın en küçük parçacığının test edildiği bir test yöntemidir. Amaç, yazılım kodunun her biriminin beklendiği gibi çalıştığını doğrulamaktır.
Entegrasyon Test: Entegrasyon testi, birbirinden bağımsız olarak test edilmiş olan iki yazılım ürününün birbirine bağlanması, birbiri arasında veri aktarımının sağlanması için birleştirilen modüllerin test edilmesidir.
Entegrasyon testinin amacı bu birleşim sırasında ortaya çıkabilecek hataları gidererek sorunsuz birleşimi sağlamaktır. Yazılımsal ürünlerin entegre edilecek modüllerinin tamamı test edilir.
Sistem Test: Sistemin şartnameye uygun olduğunu doğrulamak için yapılan son testtir. Sistem gereksinimleri, kullanım senaryoları, gereksinimler ve risk analiz raporlarından oluşur.
Kullanıcı Kabul Test: Yazılım kullanıcıları, spesifikasyonlara göre, gerçek dünya senaryolarında gerekli görevleri yerine getirebildiğinden emin olmak için yazılımı test eder. Kullanıcı Kabul Testlerinin amacı talep edilen işin içerdiği kullanıcı ihtiyaçlarının karşılanıp, karşılanmadığının belirlenmesi ve canlıya çıkışı için onay kararının verilmesidir.
Smoke Test: Yazılımın kritik işlevlerinin düzgün çalıştığını doğrulamak için build işlemi sonrasında gerçekleştirilen bir yazılım test tekniğidir.
Sanity Test: Hataların giderildiğini ve bu değişiklikler nedeniyle başka sorunların ortaya çıkmadığını doğrulamak için kodda veya işlevsellikte küçük değişikliklerle bir yazılım derlemesini aldıktan sonra gerçekleştirilen bir tür yazılım testidir.
Alfa Test: Ürün neredeyse kullanılabilir durumdayken, geliştirme sürecinin sonuna doğru yapılan bir test türüdür. Alfa testleri yazılım geliştiren kuruluşun tesislerinde, sadece yazılım geliştirme ekibi tarafından değil, potansiyel veya mevcut müşteriler ve/veya operatörler veya bağımsız bir test ekibi tarafından gerçekleştirilir. Alfa Testi, bir tür kabul testidir.
Beta Test: Beta testleri ise potansiyel veya mevcut müşteriler ve/veya operatörler tarafından kendi ortamlarında yapılır. Beta testleri alfa testlerinden sonra gelebilir veya öncesinde hiç alfa testi yapılmadan da gerçekleştirilebilir.
Değişikliğe Bağlı Testler
Retest — Onay Test: Yazılım test edildikten sonra raporlanan hataların yazılım geliştiriciler tarafından çözüldüğü bilgisi alındıktan sonra hatanın düzelip düzelmediğini kontrol etmek için yapılan bir testtir.
Regresyon Testi: Kod değişikliğinin mevcut özellikleri olumsuz etkilemediğini doğrulamak için yapılan bir tür yazılım testi olarak tanımlanır.
Bakım Testi: Sistemde yapılan düzeltme veya sisteme eklenen bazı ek özellikler nedeniyle yapılan değişikliklerin test edilmesi.
Test Teknikleri
Beyaz Kutu Test: Sistemin iç yapısına dayanan testleri oluşturur. İç yapı; kod, mimari, iş akışları ve/veya sistem içindeki veri akışlarını içerebilir.
Yaygın kullanılan bazı Beyaz Kutu test teknikleri:
1)Statement Coverage: Bu teknik, koddaki her olası durumun en az bir kere test edilmesidir.
2)Branch Coverage: Bu teknik, bir yazılım uygulamasının olası tüm yollarını(if-else ve diğer koşullu döngüler gibi) kontrol etmeye yöneliktir.
Siyah Kutu Test: Kara kutu testlerinde girdi ve çıktı değişimine göre sistemin nasıl çalıştığı test edilir. Kodun yapısı(structure), tasarımı(design) ve uygulanışı(implementation) ile ilgilenmez.
Eşit Bölümlere Ayırma Tekniği (Equivalence Partitioning): Bu teknikle test ederken, sistemde aynı şekilde davranan ve aynı sonucu veren girdiler bölümlenir. Bu bölümlerden alınan birer örnek girdilerle sistem test edilir. Bu teknikte amaç test case sayısını azaltmaktır.
Sınır Değerleri Analizi (Boundary Value Analysis): Çoğu sistemde uç noktalar daha fazla risk içermektedir. Bu teknikte sınır noktalarından örnekler kullanılarak sistem test edilir. Bu sayede sınır noktalarında oluşabilecek hataların önüne geçilir
Karar Tablosu (Decision Table): Bu teknikte test senaryoları, girdi ve nedenlerin tablolaştırılmasıyla oluşur. Karışık sistemlerin testinde genellikle bu yöntem kullanılır.
Durum Geçiş Tablosu (State Transition Table): Bu yöntem, geçerli tüm geçişleri ve geçersiz olan geçişleri gösterir. Genellikle, birbirine dönüşen durumlar olarak tanımlanan sistemlerde kullanılır.
Kullanım Durumları Testi (Use Case Testing): Adımlardan, durumlardan ve çıktılardan oluşan bu teknik kullanıcı tabanlı olduğu için gerçek kullanıcı davranışlarını simüle etmek açısından en iyi yöntemlerden biridir. Test caseler daha kolay tanımlanabilir. Doğru bir akış tanımlandığında, kullanıcının bütün davranışları ve sistemin vereceği çıktılar test edilmiş olur.
Önemli Test Terimleri
Verification(Doğrulama): Çıktının, ürünün şartlarında belirtilen özelliklere uygun olup olmadığını doğrulamak için yapılan bir işlemdir.
Validation(Geçerlilik): Çıktının veya ürünün, müşterinin beklentilerini karşılayıp karşılamadığını denetlemek içindir. Yani testçinin, yazılımcıdan gelen kodu müşterinin istediği asıl ürün ile karşılaştırıp doğru ürün üretilip üretilmediğinin kontrolünü yaptığı işlemler bütünüdür.
Verification, işlemi yazılım geliştiriciler (developer) tarafından yapılırken, Validation, işlemi test mühendisleri tarafından yapılır. Yazılım süreçlerinde genellikle ilk olarak verification işlemi yapılır.
Priority: Bir hataya kullanıcı bakış açısıyla atanmış itibar düzeyidir. Priority’i üç türe ayrılır.
- Low
- Medium
- High
Severity: Bir hatanın geliştirilmekte veya kullanılmakta olan bir sistemin üzerindeki etkisi derecesidir. Severity beş türe ayrılır.
- Critical
- Major
- Moderate
- Minor
- Cosmetic
Kalite Güvencesi (Quality Assurence): Hata veya kusurun önlenmesini hedefler.
Kalite kontrol (Quality Control): Hata veya kusurun tespit edilmesini ve iyileştirilmesini hedefler.
Bir takımda tüm takım üyeleri QA’dan sorumluyken, QC’den sadece test uzmanları sorumludur. Bir başka deyişle; QA, Yazılım Geliştirme Yaşam Döngüsünden (SDLC) sorumluyken QC, Yazılım Test Yaşam Döngüsünden (STLC) sorumludur.
Test, bir sistemin veya sistemin bileşenlerinin belirtilen gereklilikleri karşılayıp karşılamadığını öğrenmek amacıyla yapılan bir değerlendirme sürecidi
Yazılım Yaşam Döngüsü(Yazılım Geliştirme Yaşam Döngüsü): SDLC mümkün olan en kısa sürede, en yüksek kalitede ve en düşük maliyetle yazılım üreten bir süreçtir. SDLC, bir organizasyonun iyi test edilmiş ve üretimde kullanıma hazır yüksek kaliteli yazılımı hızla üretmesine yardımcı olan iyi yapılandırılmış bir aşama akışı sağlar.
SDLC altı aşamadan oluşur:
- Planlama,
- Tasarım,
- Uygulama ve Kodlama,
- Test,
- Dağıtım ,
- Bakım.
SDLC Adımları
Yazılım Test Yaşam Döngüsü(Software Testing Life Cycle): Testin de standartları ve optimizasyonu vardır. STLC işlemlerinde, her bir faaliyet planlı ve sistemli bir şekilde ifade edilir. Her aşamanın farklı hedefleri ve çıktıları vardır.
STLC aşamaları şunlardır;
- Gereksinim Aşaması,
- Planlama Aşaması,
- Analiz Aşaması,
- Tasarım Aşaması,
- Uygulama Aşaması,
- Yürütme Aşaması,
- Sonuç Aşaması,
- Kapatma Aşaması.
STLC Adımları
SDLC, bir yazılım ürünü geliştirmek için yazılım organizasyonu içindeki geliştirme ekibi tarafından takip edilen süreçtir. STLC, yazılımın kalitesini sağlamak için çeşitli faaliyetler gerçekleştirme işlemidir. Bu, SDLC ve STLC arasındaki temel farktır.
Hata Yaşam Döngüsü(Bug/Defect Life Cycle): Bir hatanın açılışından kapanmasına kadar geçirdiği evreler olarak tanımlanabilir. Yazılım projelerinde hatalar, projenin doğasına uygun sistematik bir yaklaşımla ele alınmalıdır.
Aşağıdaki şablon bir Bug — Defect yaşam döngüsüdür. Adım adım anlatmak gerekirse bir defect bulunur, tester tarafından designer’a atanır, desinger defect’i açar ve değerlendirir, değerlendirme sonucunda hatanın fix’lenip fix’lenmeyeceğine karar verir. Eğer fix’lenecek bir defect ise fix’i girer ve retest edilmesi için tester’a geri assign eder. Testler retest sonucunda başarısız bir senaryo ile karşılaşırsa aynı süreç designer’a tekrar assign edilerek devam eder. Eğer test başarılı bir şekilde gerçekleşirse verify edilir ve defect kapatılmış olur. Hata yaşam döngüsü bu şekilde tamamlanmış olur.
Bu bölümde, sistemin veya bir uygulamanın beklenmeyen durumlar olduğunda oluşan aksaklıklar vardır. Bazen bu aksaklıklara hata, bazen de kusur diyoruz. Bu terminolojileri kullanırken kafa karışıklığı yaşamamak adına Bug, Defect, Error, Fault & Failure terimlerin ne olduğunu tanımlamaya çalışacağım.
Error: Yazılımda üretilen yanlış bir sonuç doğuran aktivitilerdir.
Bug- Defect: Test ortamındaki veya test yazılımdaki hatalardır ya da error’den dolayı kodda ortaya çıkan yanlışlıklardır.
Fault — Failure: Beklenmedik test sonucu ya da bug’dan dolayı yazılımın verdiği hatalar.Canlı ortamlarda oluşan hata bir “fault” tur.
Yanlış Negatifler: Bulunması gereken hataları bulamayan testlerin sonuçlarıdır.
Yanlış Pozitifler: Hata olarak rapor edilmesine rağmen hata olmayan sonuçlardır.
Giriş Kriterleri: Test başlamadan önce yerine getirmemiz gereken maddeleri belirtir. Belirli bir test faaliyetinin gerçekleştirilmesi için gereken ön koşulları tanımlar.
Çıkış Kriterleri: Testi tamamlayabilmemiz için tamamlanması gereken maddeleri tanımlar. Bir test seviyesi veya bir test grubunu tamamlandı olarak tanımlamak için hangi koşulların sağlanması gerektiğini tanımlar. Test hedeflerine göre farklılık gösterebilecek olan giriş ve çıkış kriterleri her test seviyesi ve test çeşidi için tanımlanmalıdır.
