Bugün, Tableau yazı serime paralel olacak yeni bir seriye başlamak istiyorum. Yazılımda test ve kaliteden bahsedeceğim bu yazıların konusu ayrıca benim kariyer pathimde de başrol oyuncusu. İlk yazımda ise, test nedir ve test türleri nelerdir konusundan bahsedeceğim.
Yazılım testi hataların bulunmasına yönelik yapılan geliştirmelerdir. Hataların bulunması aslında direkt olarak kaliteyi dolaylı yoldan da güveni etkilemektedir. Tam performansla çalışan, istenen en yakın yazılımın teslim edilmesi; müşteriyi memnun etmekle birlikte geliştiriciye karşı güven sağlayacaktır.
Yazılım testlerinde 100’den fazla tür olduğunu söylemek mümkün. Ancak bu yazıda en çok kullanılan türlerden bahsedeceğim. Önemli bir konu ise test türlerinin test seviyeleri ile karıştırılmaması gerektiği. Test seviyeleri 4 tanedir ve bunlar, Birim Testi, Entegrasyon Testi, Sistem Testi ve Kabul Testidir ve her test türü, her test seviyesinde uygulanabilir. Bu başka bir yazının konusu olmakla birlikte test türlerinin anlatmaya başlayabilirim.
Resim -1
Test türlerini ayırmada birçok kaynak farklı fikirlere sahip olsa da ben ISTQB yönlendirmesinden baz alacağım. 4’e ayırdığımız test türlerinde ilk başlığımız Fonksiyonel Testler. Bu test türünde çoğunlukla girdi verilir ve çıktısı kontrol edilir. Esas olarak kara kutu (back box) testini çalıştırır yani uygulama içeriği ile ilgilenilmez. Örneğin bir login işleminde kullanıcı adı ve şifre girilir ancak butona bastıktan sonra gerçekleşen işlemler (db, response time vb.), başarı alana kadar kara kutu testi yapanı ilgilendirmez. Başarılı giriş yapıldıktan sonra test geçmiş demektir. Testi gerçekleştirmek için en gerekli unsur gereksinim dokümanıdır/ listesidir. Fonksiyonel testlerin altında bir çok test türü olsa da en çok kullanılanları açıklamak istiyorum.
Birim (Unit) test, development aşamasındaki unit test ile karıştırılmamalı. Fonksiyonel testlerin altında incelenen birim testler her seviyede uygulandığı gibi, ele alınacak her birimin istenildiği gibi olup olmadığına cevap arar.
Entegrasyon (Integration) testi, farklı birimlerin birbiriyle olan entegrasyonunun istenildiği gibi olup olmadığını test eder. Oldukça gereklidir çünkü projelerde entegrasyon sonrası değişen birimlerin testleri yapılmadığında, birim testine inecek geri dönüşler yapılabilir ki bu da efor ve maddi kayba yol açacaktır.
Resim – 2 (2 Unit Test, 0 Integration Test)
Duman (Smoke) testi, kapsamlı testler koşulmadan önce, development sonrası koşulan testtir. Yazılımın kritik işlevlerinin çalışıp çalışmadığını kontrol etmek amacıyla yapılır. Buradaki sonuçlar raporlanır ve eğer bu kritik kısımlarda hatalar varsa bir sonraki adımda koşacak olan regresyon koşulmaz, hata düzelmesine gidilir.
Akıl sağlığı (Sanity) testinde ise, hata düzeltildikten sonra istenilen şekilde davranıyor mu ve başka modülleri etkilemiş mi, sorusuna cevap aranır. Küçük işlevleri beceremeyen yazılımlarda büyük testlere gidilmez ki efor ve maliyet kaybı yaşanmasın. Testin sanity olarak adlandırılması ise, test edilen modülde rasyonellik ve güvenilirlik beklendiği içindir.
Smoke & Sanity testlerini, birbirine en çok karıştırılan test türleri olduğunu söyleyebiliriz. Halbuki küçük bir diyagramla bu ayrımı açıklamak mümkün (Resim-3).
Resim – 3
Kabul (Acceptence) testinde, son kullanıcıya istenen gereksinimler sağlanmış mı, sorusuna cevap aranır. Alfa ve Beta olmak üzere iki alt başlığı vardır. Alfada, testler proje hakkında bilgi sahibi olan ekip üyeleri tarafından yapılırken, Beta testinde ürün hakkında bilgisi olmayan son kullanıcılar tarafından yapılır.Alfanın amacı son hataları temizlemek iken, Betanın amacı müşteriye teslim öncesi son kontroldür.
Fonksiyonel Olmayan (Non-functional) testler, sistemin işlevini nasıl yaptığıyla ilgilenir. Performanstan, uyumluluğa kadar bir çok testi içerir. Fonksiyonel testler kadar önemlidir ve memnuniyeti aynı derecede etkiler. Tüm test seviyelerinde sıkça yapılmalıdır ki her noktada stabilitenin sağlandığı görülsün.
Güvenilirlik (Reliability) testi, isminden dolayı güvenlik testi ile karıştırılmakta ancak güvenilirlik testinde, uygulamanın verdiği başarılı cevapların ,modül farketmeksizin, sürekli olması beklenir. Örneğin uygulamda alınan response time bugün 4sn iken yarın 54 sn olmaması beklenir.
Güvenlik (Security) testinde, sistemin açıkları denenerek gelebilecek saldırılara karşı herhangi bir güvenlik açığı varsa bunlar aranır.
Performans testini, bazı kaynaklar dört alt başlık şeklinde açsa da ben o dört başlığı (Stres, yük, hacim, ölçeklenebilirlik) ayrı ana başlıklar olarak anlatacağım.Performans testinde, uygulama istenen sürede cevap veriyor mu sorusuna cevap aranır.
Resim -4
Yük (Load) testinde, gerçek senaryoda karşılaşılması beklenen yük sisteme verilir ve bu yük altında sistemin performansı izlenir. Bu şekilde sistemin optimum çalışma seviyeleri bulunur.
Stres testinde ise, yük testine benzer olarak sisteme yüklenilir ancak burada sistem kapasitesinin üzerine, yük arttırılmak, suretiyle çıkılır. Buradaki amaç sistemin stres altında güvenilir olup olmadığını izlemektir. Yük testlerinden sonra çalıştırılır çünkü ilk olarak sistemin maksimum kapasitesinin ölçülmesi gerekir. Belirlenen bu kapasitenin üstüne çıkılarak işlev kırılmaya çalışılır.
Hacim (Volume) testinde ise, sistem fazla veriyle zorlanır ve kapsitenin üstüne çıkılmaya çalışılır. Hacim testi veri tabanı odaklıdır ve test sırasında veritabanındaki veri hacmi artırılır.Bu sayede olası veri kayıplarının önüle geçilmeye çalışılır.
Ölçeklenebilirlik (Scability) testi , kullanıcı isteklerinin sayısı değiştirildiğinde bir sistemin veya ağın performansını ölçen test yöntemidir. Ölçeklenebilirlik testinin amacı, sistemin kullanıcı trafiğinde, veri hacminde, işlem sayısı sıklığında vb. öngörülen artışı karşılayabilmesini sağlamaktır. Sistem artan ihtiyaçları karşılayabiliyor mu, sorusuna yanıt aranır.
Beyaz Kutu (White Box) testleri çoğu kaynakta fonksiyonel test kategorisine alınsa da, ben kaynağımı istqb olarak belirlediğimi yazmıştım. Burada, kara kutu testlerinin aksine girdi-çıktı cevabından çok, yazılımın içeriği ile ilgilenilir. Bu sebeple testçilerin yürüttüğü bir koşum değildir. Kodu yazan developerın ilgilendiği test türüdür.
Resim -5
Bakım (Maintenance) testlerinden, canlıdaki yazılımlar için bahsetmek mümkündür. Örneğin yılar sonra bile, güncelleme gelen cihazlardaki uyumluluk sorunlarını bulmak için bakım testleri koşabiliriz.
Regresyon testinde, ana amaç değişen bir modül olduğunda o modülün hala istendiği gibi çalıştığını doğrulamaktır. Regresyonlar oldukça kapsamlı koşulur, dolayısıyla maliyeti ve eforu yüksektir. Bu sebeple, regresyona dahil edilecek modüller iyi analiz edilmelidir. Genellikle, canlıda çok hata alınan, son kullanıcının yoğunlukla kullandığı, karmaşık ve riskli fonksiyonlar regresyona dahil edilir.
Yukarıda anlatılan test türlerinin dışında, Accessibility (Ulaşılabilirlik), Ad-hoc (Kurgusuz), Configuration (Yapılandırma), Endurance (Dayanıklılık), Exploratory (Keşif), Gorilla, Localization (Yerelleştirme), Penetration (Sızma),End to End (Uçtan Uca), UI (Arayüz) gibi yaygın test türlerini de sayabiliriz.
Resim -6
Bu yazımda, test türlerinden bahsettim. Bir sonraki yazımda, test türleri ile en çok karıştırılan test seviyelerinden bahsedeceğim. Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
Resim-2: Approaching Testing on Android/proandroiddev.com
Resim-4: A Guide To: White Box, Black Box, and Gray Box testing/careerist.com
Resim-6: Functional Testing Vs Non-Functional Testing/pcloudy.com
Kapak Resmi: by upklyak / Freepik
TAGs: software testing, software quality, functional testing, non-functional testing, test types, white box, black box, regression, unit testing, integration testing, stress vs volume, stress vs load,test nedir, test türleri
