Yazılım Test Günlüğü yazı dizisinin 5. yazısında sizlere test seviyeleri hakkında kısa bir yazı ile giriş yapmak istiyorum. Bir önceki yazımda Yazılım Geliştirme Modellerine değinmiştik. Bu modeller arasında olan V modelde de her bir yazılım seviyesine karşılık gelen test seviyelerini belirtmiştik. Bu yazıda da buradaki yazılım test seviyelerini biraz daha detaylı olarak inceleyeceğiz.
Çeşitli test seviyelerinin ayrıntılı bir şekilde anlaşılması ve tanımlanması, eksik alanları belirleyecek ve çakışmayı ve tekrarlamayı önleyecektir. Bazen, belirli riskleri ele almak için kasıtlı çakışmayı isteyebiliriz. Farklı seviyelerdeki testleri birleştirmek veya boşlukları kaldırıp kaldırmamamız gerektiğini anlamak, test seviyelerini daha tamamlayıcı hale getirir, böylece daha etkin ve verimli testlere imkan sağlar.
Gelin bu seviyeleri birlikte inceleyelim.
Birim (Unit) Testi:
Bileşen , modül ve program testi olarak da bilinen birim testi, ayrı olarak test edilebilir olan yazılımların (ör. Modüller, programlar, nesneler, sınıflar, vb.) işlevlerini doğrular ve kusurlarını araştırır. Yazılım test seviyelerinin en alt seviyesinde yer alır. Koda yöneliktir.
Birim testleri, geliştirme yaşam döngüsü ve sistem bağlamına bağlı olarak sistemin geri kalanından ayrı olarak yapılır. Çoğu zaman stubs ve driverlar eksik yazılımın yerini almak ve yazılım bileşenleri arasındaki arayüzü basit bir şekilde taklit etmek için kullanılır. Test edilecek yazılım bileşenine stubs denir; bir driver ise test edilecek bir bileşeni çağırır. Bileşen testi; fonksiyonalite testi, fonksiyonel olmayan testler, yapısal testleri veya sağlamlık testlerinden oluşabilir. Test senaryoları, bileşenin gereksinimi, yazılım tasarımı veya veri modeli gibi test esaslarından türetilebilir.
Birim testinde genellikle test edilen koda erişim söz konusudur. Aynı zamanda, birim testi çerçevesi ya da hata ayıklama aracı gibi bir geliştirme ortamının desteğiyle gerçekleştirilir. Uygulamada, bileşen testi genellikle kodu yazan programcı tarafından yapılır. Birim testlerinde çoğunlukla hatalar bulundukları anda kayıt altına alınmadan düzeltilir.
Birim testine yönelik yaklaşımlardan biri, kodlamadan önce test senaryolarını hazırlamak ve otomasyona geçirmektir. Bu yaklaşıma test öncelikli yaklaşım veya test güdümlü geliştirme (TDD) adı verilir ve oldukça döngüseldir. Test senaryolarını geliştirme, ardından küçük kod parçalarını oluşturma ve entegre etme ardından da tüm sorunları düzelterek ve başarılı olana kadar yineleyerek birim testlerini yürütme döngüsüne dayanır.
Entegrasyon (Integration) Testi:
Entegrasyon testi, bileşenler arasındaki arayüzleri, yazılımın işletim sistemi, dosya sistemi ve donanım gibi sistemin farklı bölümleriyle etkileşimlerini ve sistemler arasındaki arayüzleri test eder. Yazılım test seviyelerinden ikinci seviyesidir.
Birden fazla entegrasyon testi seviyesi olabilir ve aşağıdaki gibi çeşitli boyutlardaki test nesneleri üzerinde gerçekleştirilebilir:
- Bileşen entegrasyon testi, yazılımın bileşenleri arasındaki etkileşimleri test eder ve bileşen testinden sonra yapılır.
- Sistem entegrasyon testi, farklı sistemler veya donanım ve yazılım arasındaki etkileşimleri test eder ve sistem testinden sonra yapılabilir.
Entegrasyonun kapsamı ne kadar geniş olursa, hataların belirli bir bileşene veya sisteme indirgenmesi de o kadar zor olur, bu durumda daha fazla risk ortaya çıkar ve sorun gidermeye harcanan süre artar.
Sistematik entegrasyon stratejileri, sistem mimarisine (yukarıdan aşağıya veya aşağıdan yukarıya gibi), fonksiyonel görevlere, işlemleri ele alma sıralarına veya sistem ya da bileşenlerle ilgili diğer bazı kapsamlara dayanabilir. Kusur izolasyonunu kolaylaştırmak ve hataları erken saptamak için entegrasyonun “büyük patlama” yerine aşamalı olması gerekir.
Fonksiyonel olmayan karakteristiklerin (örn. performans) test edilmesi işlemi, fonksiyonel teste dahil edilebileceği gibi entegrasyon testine de dahil edilebilir.
Her bir entegrasyon aşamasında yalnızca entegrasyona odaklanılır. Örneğin, A modülü B modülüne entegre ediliyorsa, her bir modülün fonksiyonalitesini değil sadece bu modüller arasındaki iletişimi test edilmelidir. İdeal yaklaşım, test uzmanlarının mimariyi anlayıp entegrasyon testi kurgusunu planlamasıdır. Örneğin, entegrasyon testleri bileşenlerin veya sistemlerin oluşturulmasından önce planlandıysa, bu bileşenlerin entegrasyon testlerini en etkin şekilde yapabilmek için gereken sırada oluşturulmasını sağlayabilirler.
Sistem (System) Testi:
Sistem testi, tüm sistemin/yazılımın davranışı ile alakalıdır. test seviyelerinin üçüncü basamağındadır.
Master test planında veya ilgili test seviyesinin planında sistem testinin kapsamı açıkça belirtilir. Sistemin çalışacağı ortamla ilgili hata riskini en aza indirmek için sistem testinde test ortamı mümkün olduğunca canlı ortama yakın olmalıdır.
Sistem testi, risklere ve/veya gereksinimlere, iş süreçlerine, kullanım senaryolarına veya sistem davranışını tanımlayan metinlere ya da modellere, işletim sistemiyle etkileşimlere ve sistem kaynaklarına dayanabilir.
Sistem testi, sistemin fonksiyonel ve fonksiyonel olmayan gereksinimlerini ve veri kalitesini sorgulamalıdır. Bu seviyede test uzmanlarının tamamlanmamış gereksinimlerle de ilgilenmesi gerekir. Fonksiyonel gereksinimlerle ilgili sistem testi, test edilecek sistem için en uygun gereksinim bazlı (kara kutu) teknikler kullanılarak başlar. Örneğin, iş kurallarında tanımlanan etkilerin kombinasyonları için karar tablosu test tekniği kullanılabilir. Ardından, yapısal testlere (beyaz kutu) geçilerek gereksinim bazlı testlerin yakalayamadığı hatalar yakalanabilir. Menü yapısı ve web sayfası navigasyonunu test nesnesi olarak ele alan yapısal testler. Sistem testi genellikle bağımsız bir test ekibi tarafından gerçekleştirir.
Kabul (Acceptance) Testi:
Kabul testi genellikle bir yazılımın müşterilerinin veya kullanıcılarının sorumluluğundadır; bu seviyedeki testlere diğer paydaşlar da dahil olabilir. Test seviyelerinin son basamağındadır.
Kabul testinin amacı, sisteme, sistemin parçalarına veya sistemin fonksiyonel olmayan gereksinimlerine karşı güven oluşturmaktır. Kabul testinde ana odak hataları bulmak değil, sistemin canlıya hazır olduğunu göstermektir.
Kabul testinin son test seviyesi olmadığı durumlar olabilir buna rağmen kabul testinde sistemin canlıya alınmaya ve kullanıma hazır olup olmadığı denetlenebilir. Örneğin, geniş ölçekli sistem entegrasyon testi, kabul testinin ardından yapılabilir.
Kabul testi yazılım geliştirme yaşam döngüsünde birçok kez yapılabilir, mesela:
- Bir paket yazılım kurulduğunda veya entegre edildiğinde kabul testinden geçebilir.
- Bir bileşenin kullanılabilirliği ile ilgili kabul testi, bileşen testi sırasında yapılabilir.
- Yeni bir fonksiyonel geliştirme ile ilgili kabul testi, sistem testinden önce yapılabilir.
Genel kabul testi biçimleri aşağıdaki gibi listelenebilir:
Kullanıcı kabul testi:
Sistemin son kullanıcılar tarafından kullanımının uygun olduğunu doğrular.
Operasyonel (kabul) test:
Sistemin, sistem yöneticileri tarafından kabulüdür;
- Yedekleme/geri yükleme testi,
- Felaket kurtarma,
- Kullanıcı yönetimi,
- Bakım görevleri,
- Veri yükleme ve veri göçü görevleri,
- Güvenlik açıklarının periyodik kontrolleri gibi testleri içerir.
Sözleşme ve yasal mevzuata göre yapılan kabul testleri:
Sözleşmeye göre yapılan kabul testi, müşteriye özel geliştirilen yazılımın sözleşmenin şartlarına göre gerçekleştirilir. Kabul kriteri, taraflar sözleşmeyi kabul ettiğinde belirlenmelidir. Mevzuata göre yapılan kabul testi, devletin belirlediği, yasal veya emniyetle ilgili düzenlemeler gibi uyulması gereken mevzuatlara göre gerçekleştirilir.
Alfa ve beta (veya saha) testi:
Paket yazılım geliştiren şirketler geliştirdikleri yazılımı satış için pazara sunmadan önce potansiyel veya var olan müşterilerinden geri bildirim almak isterler. Alfa testi, yazılımı geliştiren şirketin kendi bünyesinde kontröllü bir şekilde yapılırken beta testi veya saha testi, müşterilerin veya potansiyel müşterilerin kendi ortamlarında kontrolsüz bir şekilde gerçekleştirilir. Terminolojide beta testleri için fabrika kabul testi veya saha kabul testi gibi terimler de kullanılmaktadır.
Kaynaklar:
- ISTQB Foundation Level Syllabus
- FOUNDATIONS OF SOFTWARE TESTING ( Dorothy Graham, Erik van Veenendaal, Isabel Evans, Rex Black)