Yazılım Test Süreçleri ve Metodolojileri
Yazılım testine giriş yazısında test, yazılım kalitesi, defect ve bug gibi kavramları gördük. Regresyon testi, fonksiyonel test, güvenlik testi gibi tüm test tekniklerinin anlatıldığı Yazılım Test Teknikleri yazısıyla birlikte yazılım test süreçleri ile hedefe ve amaca göre yazılım test seviyelerini işliyoruz. Her iki yazıyla birlikte yaygın bir şekilde kullanılan yazılım test tekniklerini ve metodolojilerini göreceğiz.
Yazılım test süreçleri başta kullandığı metodolojilere göre açık kutu testi (white box testing) ve kapalı kutu testi (black box testing) olarak ayrılmaktadır. Ayrıca yazılım test süreçleri içerisinde gray box testing de ayrı bir kapsam olarak uygulanmaktadır.
Açık Kutu Testi (White Box Testing)
Türkçe’de daha çok “açık kutu testi” olarak tabir etmeyi tercih ettiğimiz bu test yapısal test demektir (structural testing). Bir bileşenin ya da sistemin iç mekanizması ile ilgili yapılan testtir. White box testing yani açık kutu testi, uygulamanın kodunu temel alır ve programın çalışmasını, içyapılarını test eder.
Cam (glass box testing), açık (open box testing), temiz (transparent box testing) olarak da adlandırılan açık kutu testinde, testi yapan kişi (geliştirici, yazılım test mühendisi veya yazılım test uzmanı) sorunlu kısmı bulmak için kodu incelemektedir. Açık kutu testi, ekstra kod parçasını çıkararak kodun optimizasyonunu sağlar. Hangi verinin yazılan kodu en iyi şekilde test edeceğini belirler. Ancak, kodu inceleyip tek tek hata bulmak zor bir işlemdir ve bu test yapıldığında maliyet artar.
Test biriminin bu test sürecini gerçekleştirebilmesi için kaynak kodu bilmesi ve hangi kısmın uygun olmayan bir şekilde davrandığını bilmesi gerekmektedir.
Avantajları
»
Testi yapan kaynak kodu bildiği için uygulamanın etkin bir şekilde test edilmesi için hangi veri türlerinin yardımcı olabileceğini de daha kolay bulabilmektedir.
»
Kaynak kodun optimize edilmesine yardımcı olmaktadır. Algoritmaların doğru tanımlanmış ve yazılmış olup olmadığını ve yazılım doğruluğunun belirlenmesini sağlar.
»
Gizli defect’lerin / kusurların ortaya çıkmasına sebep olabilecek kod satırlarının kaldırılmasına yardımcı olmaktadır.
»
Kaynak kodun bilinmesi sayesinde test senaryolarının kapsamının olabilecek en üst seviyede olmasına yardımcı olmaktadır.
Dezavantajları
»
Bu test için deneyimli ve yetenekli bir testçiye ihtiyaç olduğu için maliyeti artırabilir.
»
Sorun oluşturabilecek gizli defect’lerin/kusurların tespit edilebilmesi için her köşeye bakmak imkânsızdır.
»
Kodu analiz eden ve hata ayıklayan araçlar gibi özel araçlar gerektirdiğinden bu testi yapmak zordur. Yani aynı yazılım paketine göre kapalı kutu testinin aksine daha fazla kaynağa ihtiyacı vardır.
Kapalı Kutu Testi (Black Box Testing)
Kapalı kutu testi fonksiyonellik testidir. Bu test yöntemi, kod ya da tasarımla ilgilenmez, işlevsellik ve fonksiyonel ihtiyaçlara göre test yapılır. Black box testing yani kapalı kutu testi; fonksiyonellik testi, closed box testing ya da opaque testing olarak da adlandırılır. Kapalı kutu testi yapılırken bir testçi girişlerin nasıl ve nerede yapıldığını ve çalıştığını bilmeden girdi sağlayarak ve çıktıları inceleyerek sistemin kullanıcı ön yüzü ile ilgilenir.
Avantajları
»
Büyük kod parçaları için çok uygundur.
»
Yük testi, kullanılabilirlik testi gibi sadece kapalı kutu testi ile yapılabilecek test sınıflarının çoğunu gerçekleştirmemizi sağlar.
»
Açık kutu testlerine göre daha az kaynak gerektirir.
»
Kaynak koduna erişime gerek yoktur.
»
Açıkça tanımlanan rollerle kullanıcının bakış açısını geliştirici perspektifinden ayırır.
»
Orta derecede test kullanıcısı altyapı, programlama dili, uygulama bilgisi olmadan test yapabilir.
Dezavantajları
»
Yanlışlıkla veya es-kaza birkaç hatanın birlikte doğru sonuç üretmesi durumunda buradaki hataları kapalı kutu testi kolayca tespit edemez.
»
Test case / test durumu kapsamına alınmayan bazı kod satırlarının test edilmemesi durumu oluşabilir.
»
Sadece sınırlı sayıda test senaryosu gerçekleştirilebilir.
»
Test case / test durumlarının tasarlanması zordur.
Bunlardan ayrı “gray box testing” de ayrı bir yöntem olarak kullanılmaktadır. White box testinde sistemin iç yapısı bilinir, black box testinde iç yapı hiç bilinmemektedir. Gray box testing yönteminde ise sistemin iç yapısı kısmen bilinmektedir. Black box testinin basit tekniğini alarak bunu white box testinin teknikleri ile birleştirir. Ürünün genel kalitesini artırmak için hem geliştiricilerin hem de test kullanıcılarının giriş değerlerini aynı anda içerir. Fonksiyonel ve fonksiyonel olmayan testlerin uzun süreçlerinin zaman tüketimini azaltır. Daha detaylı bilgi için https://en.wikipedia.org/wiki/Gray_box_testing adresine göz atabilirsiniz.
Hedefe Göre Yazılım Test Seviyeleri
Hedefe göre yazılım test seviyeleri nelerdir? Yazılım test aktiviteleri genelde geliştirme ve bakım süreçleri boyunca farklı düzeylerde gerçekleştirilir. Yani testin hedefi değişebilir: tek bir modül, bu modüllerden oluşan bir grup ya da bütün bir sistem. Bu 3 test aşaması olan birim, entegrasyon ve sistem testi sonrasında da kabul / yeterlilik testi de müşterinin gereksinimini karşılayıp karşılamadığını ölçmek için yapılır. Bu yazılım test türleri nelerdir görelim.
Birim Testi (Unit Testing)
Test seviyeleri ile ilgili olarak, en düşük seviyede yapılan testtir. Test edilebilir en küçük yazılım parçası olan ve çoğu zaman “birim”, “modül”, “bileşen” olarak adlandırılan yazılımın temel kısımlarını test eder. Bu test, resmi olarak test ekibi testlerini koşmadan önce geliştiriciler tarafından gerçekleştirilir. Geliştiriciler kalite güvence ekibinin verisinden farklı test verilerini kullanır.
Birim testinin amacı, her bir modülü veya birimi izole ederek bu kısmın gereksinimler ve işlevsellik açısından doğru olduğunu göstermektir.
Bu birimlerin test edilebilmesi için bağımlı olduğu diğer modül veya bileşenler hazır değilse bu kısımlar stub ve driver adı verilen “dummy module”ler kullanılır.
Entegrasyon Testi (Integration Testing)
Entegrasyon testi, bir uygulamanın birleşik bölümlerinin, doğru şekilde işlev görüp görmediğini test etmek için test edilmesi olarak tanımlanır. Entegrasyon testi, yazılımdaki modüllerin veya bileşenlerin birbirleri arasındaki etkileşimin doğrulanması sürecidir.
Entegrasyon testlerinde test metodolojileri genellikle büyük ölçüde değişebilir ancak bunlar iki temel test stratejisi çerçevesinde uygulanır:
Bigbang Testi – Bigbang Testing
Test edilecek tüm paket hazır olduğunda ürünün tamamını test etme.
Artımlı Test – Incremental Testing
Yazılımı modüller halinde parça parça test etmek için birim testleri; daha sonra tamamlanan modüllerle bu modül gruplarını test etmek için entegrasyon testleridir. Bu işlem tüm paket test edilinceye kadar devam eder. Bu aşamalar tamamlandıktan sonra sistem bir bütün halinde test edilir. Ek olarak, artımlı test de bottom-up testing (aşağıdan yukarıya) ve top-down testing (yukarıdan aşağıya) olmak üzere iki temel stratejiye göre gerçekleştirilir. Her iki artımlı test stratejisi, yazılım paketinin yazılım modüllerinin bir hiyerarşisinden yapıldığını varsaymaktadır. Top-down testlerde, test edilen ilk modül ana modüldür, yazılım yapısındaki en üst seviye modüldür; test edilecek son modüller en düşük seviye modülleridir. Bottom-up testlerde, test sırası tersine çevrilir: en düşük seviyedeki modüller önce test edilmiş ana modül ile test edilir.
Uygulama tam ve çalışan bir uygulamaya bağlandığında arabirimler entegrasyon testi sırasında daha uygun bir şekilde test edilir. Bu entegrasyon sürecinin bir sonucu olarak, entegrasyon testi sırasında yazılım alt sistemleri ve son olarak tamamlanmış bir sistem bir araya getirilir. Tamamlanan sistem daha sonra sistem testi için hazırdır.
Sistem Testi (System Testing)
Sistem testi bütün bir sistemin davranışı ile ilgilidir. Fonksiyonel başarısızlıkların çoğu birim ve entegrasyon testlerinde zaten tespit edilmiş olmalıdır. Sistem testi; güvenlik, hız, doğruluk, güvenirlik gibi fonksiyonel olmayan sistem gereksinimleri konusunda karşılaştırma yapılabilmesi için uygundur.
Sistem testi önemlidir çünkü:
- Uygulamanın bir bütün olarak test edildiği yazılım geliştirme yaşam döngüsünün ilk adımıdır.
- Uygulamanın fonksiyonel ve teknik özelliklerini karşıladığından emin olmak için iyice test edilmiştir.
- Uygulama, yaygınlaştırıldığı ortama çok yakın bir ortamda test edilmiştir.
- Sistem testi, hem kullanıcı gereksinimlerini hem de uygulama mimarisini test etmemizi, geçerleme yapmamızı ve doğrulamamızı sağlar.
Entegrasyon testleri tamamlandığında, bir yazılım bir araya getirilmiş ve ana alt sistemleri test edilmiştir. Bu noktada geliştiriciler / testçiler bunu bir bütün olarak test etmeye başlar. Sistem testi planlaması gereksinimler fazında başlamalıdır. Sistem testi planlaması karmaşık bir iştir. Planın, test yaklaşımları, maliyetler, çizelgeler, test senaryoları ve test prosedürleri gibi hazırlanması gereken birçok bileşeni vardır.
Sistem testi güvenilirlik, kullanılabilirlik, performans ve güvenlik gibi fonksiyonel davranışları ve kalite gereksinimlerini değerlendirir. Bu test aşaması, örneğin farklı koşullara, kilitlenmelere, kesinti ve istisnai işlem sorunlarına ve etkin olmayan bellek kullanımı gibi harici donanım ve yazılım önyüzü hatalarını tespit etmek için özellikle yararlıdır. Sistem testinden sonra yazılım, kabul testi veya alfa/beta testi sırasında değerlendirme için kullanıcılara teslim edilecektir. Kullanıcılar/istemciler sistemi kullanmaya başlamadan önce yazılımın kalitesinin ölçüldüğünden ve değerlendirildiğinden emin olmak isteyecektir. Aslında sistem testi, kabul testi için iyi bir prova senaryosu olarak hizmet eder. Çeşitli amaçlara göre yapılan test türlerini (fonksiyonel test, performans testi, stres testi, yapılandırma testi, güvenlik testi vb.) Amaca Göre Test Seviyeleri yazımızdan inceleyebilirsiniz.
Kabul/Yeterlilik Testi (Acceptance/Qualification Testing)
Uygulamanın istenen özelliklere uygun olup olmadığını ve müşterinin gereksinimini karşılayıp karşılamadığını ölçmek için müşteri veya kalite güvence ekibi tarafından yürütülür. Kabul testi sistem davranışını müşterinin gereksinimlerine karşı kontrol eder. Müşteriler gereksinimlerin karşılandığını görebilmek için sistem üzerinde gereken görevleri üstlenirler. Yani sistem testi başarıyla tamamlanmış olsa da müşteri tarafından kabul testi istenmektedir yani yazılım üzerinde testi müşteri yapmaktadır. Burada yapılan testler sistem testinde ele alındığı için çoğunlukla tekrarlayıcıdır. Bu sürece sistem geliştiricileri de dahil olabilir. Yeterlilik testi ise yazılımın gereksinimlere uygunluğunu doğrulamak için yapılır ve müteakip kabul testleri için bir temel oluşturur.
Kabul testi çeşitleri şunlardır:
- Kullanıcı Kabul Testi (User Acceptance Test – UAT)
- İş Kabul Testi (Business Acceptance Testing – CAT)
- Sözleşme Kabul Testi (Contract Acceptance Testing – CAT)
- Yönetmelik / Uygunluk Kabul Testi ( Regulations/Compliance Acceptance Testing – RAT)
- Operasyonel Kabul Testi (Operational Acceptance Testing – OAT)
- Alfa Testi (Alpha Testing)
- Beta Testi (Beta Testing)
Alfa ve beta testleri için ayrıca Yazılım Test Teknikleri yazısını ziyaret edebilirsiniz.
