Regresyon Testi Gerekli mi?

Şekil 1

Regresyon Testi Nedir?

Yazıma regresyon testinin tanımını paylaşarak başlamak istiyorum. Regresyon testi, daha önce geliştirilmiş ve test edilmiş olan yazılımın değişikliklerden sonra da beklendiği gibi çalışıp çalışmadığı hakkında bilgi sağlayan bir yazılım testi türüdür [1].

Regresyon testi ISTQB (International Software Testing Qualifications Board) yazılım testi terimler sözlüğünde şöyle tarif edilmektedir: ‘Yazılımda yapılan değişiklik veya düzeltme sonrasında bu değişiklik veya düzeltmenin yazılımın başka yerlerinde sebep olabileceği hataları bulmaya yönelik olarak yazılımın değiştirilmeyen veya düzeltilmeyen taraflarının tekrar test edilmesi. Yazılım veya yazılımın ortamı değiştiğinde uygulanan testlerdir’ [2].

Terimde belirtildiği gibi kod ile ortamda değişiklik veya yenilik gibi durumlar yoksa bu durumda regresyon testine de gerek yoktur. Günümüzde birçok yazılım sürekli olarak yeni özelliklerden dolayı, hata çözümlerinden dolayı veya değişikliklerden dolayı değişime uğramaktadır. Yazılım yanı sıra aynı durum ortamlar ve donanımlar içinde geçerli olabilmektedir.

Hatasız Kul Olmaz

Bildiğiniz gibi hatasız kul olmaz, bu durumdan dolayı birçok insan tarafından yazılmış olan dokümantasyonlarda ve yazılımlarda da hata bulunabilmektedir. Bu hatalar farklı nedenlerden oluşabilmektedir. Yazılım mühendisine dokümantasyonda eksik bilgi gelmesi veya yazılım mühendisinin farklı nedenlerden dolayı (insanlık hali: dalgınlık, hastalık zaman darlığı, stres vs.) eksik/hatalı kod yazabilmektedir. Yazılım geliştirme süreçlerinde geliştirmenin yapıldığı kısımlar detaylı olarak test edilse de bu kısım dışında kalan daha önce yazılmış olan kodun sunduğu özelliklerin regresyon testi atlanabilmektedir. Aynı şekilde bir hata çözümü yapıldığında hata çözümü tekrar test edilirken, bu çalışmanın farklı alanlarda farklı sıkıntılara neden olup olmadığının (regresyon) testi yapılmadan canlı ortama geçilebilmektedir.

Şekil 2

Test Otomasyon Piramidi

Regresyon testleri ana hatlarıyla 3 farklı katmanda yapılabilmektedir: birim, servis ve ekran [3]. Sırasıyla yazım/bakım maliyeti ve koşum süresi olarak üst katmana geçtikçe artış olacaktır, güvenilirliğinde ise azalış olacaktır. Bu nedenlerden dolayı test sayısı olarak en fazla birim katmanında olmalı sonrasında servis ve en son olarak sadece riskli kritik senaryoların ana akışları ekran seviyesinde olmalıdır.

İdealde yazılımda her değişiklikten sonra regresyon testlerinin koşmasında fayda vardır, fakat özellikle ekran katmanında olanların koşum süreleri uzun ve kırılgan oldukları için sürekli entegrasyon süreçlerine çok uygun olmamaktadırlar. Yazılım mühendislerinin yazmış oldukları birim testleri her değişiklikte koşulduğunu varsayarak, servis testlerini de test ortamına geçişle beraber otomatik koşularak değişikliklerin etkisi hakkında geribildirim alabilmek önemlidir. Boehm kuralında bahsedildiği gibi geliştirme sürecinde sorun ne kadar erken keşfedilirse çözüm maliyeti de o azalacaktır [4]. Hatalar yazılıma düşmeden analiz veya tasarım aşamasında keşfedilirse anında düzenleme ile birlikte çözülür. Yazılım mühendisinin bilgisayarında geliştirme aşamasında birim testinde iken karşılaşılan hata yine gayet hızlı çözülür, fakat test ortamında yazılım test mühendisi tarafından test edilirken bulunursa yazılım mühendisi bunu analiz ve debug edip çözmesi gerekecektir. Preprod gibi canlı ortama en yakın test ortamı ve canlı ortama geçtikten sonra artık çözüm maliyeti ve süresi de iyice artacaktır. Hele ki canlı ortama geçti ise ve kullanıcı tarafından dönüldüyse maliyet yanı sıra kullanıcı memnuniyetsizliği ve imaj zedelenmesi gibi zararlar verecektir.

Şekil 3

Regresyon Testleri Nasıl Koşulmalıdır?

Regresyon testi manuel koşulması durumunda doğası gereği sıkıcı, zaman ve efor alan bir testtir. Sürekli daha önce geliştirilmiş olan yazılımın tekrar ve tekrar insan tarafından test edilmesi bu durumdan dolayı çok verimli değildir. Bu testler ayrıca yazılımı kullanan kitlenin çoğunluğunun kullandığı konfigürasyonlarda yapılması hedeflenmektedir. Mesela bir mobil uygulama düşündüğümüzde kullanıcıların çoğunluğu iPhone 14-iOS 16, iPhone 15-iOS 17, Redmi Note 8-Android 12, Samsung S22Ultra-Android 13 kullanıyor ise en azından bunlarda regresyon testleri koşmak isteyeceğimiz için regresyon test koşumlarının sayıları artacaktır. Örnek verecek olursak 500 adet regresyon testimiz var ise koşumlar 500×4=2000 adet olacaktır. İnsan olarak bu testleri detaylı bir şekilde mesela ekran görüntülerini de adım adım alarak koşmak çok zordur.

Bu durumlardan dolayı birim testlerinin zaten geliştirme aşamasında yazıldığını varsayarak riskli ve kritik gördüğümüz özelliklerin regresyon testlerin değerlendirmesini yaparak otomasyona uygunluğu değerlendirilmelidir ve uygun olması durumunda kodu yazılarak düzenli olarak otomatik koşum sağlanmalıdır. Böylece yazılım her değiştikten sonra CI sürecine dahil edilerek koşum yapılabilir veya periyodik koşumlar yaparak değişikliklerin etkisi hakkında geri bildirimde bulunulabilir. Otomatik regresyon testlerin insan bağımsız ve 7/24 koşulabilme avantajı bulunmaktadır. Regresyon testinin otomatik yapılması ciddi manada zaman ve maliyet kazanımı sağlayarak daha verimli yapılmasını sağlamaktadır [5]. Regresyon testleri üzerinde çalışılarak mümkün olduğu kadar otomatik koşmak yatırım getirisi yüksek ve verimlidir.

Şekil 5. Telefon Parkımızın Gelişimi

Otomatik Birim Regresyon Testleri

Birim testleri yazılım mühendisleri tarafından yazılım geliştirmeden önce (TDD: Test Driven Development) veya sonrasında yazılması gerekmektedir. TDD yaklaşımında test kodu hatta yazılım kodu öncesinde yazılıp ve başarılı oluncaya kadar kod yazılarak devam eder [6]. Birim testleri düzenli ve verimli yazılması durumunda yazılım mühendisine kod değişikliklerinde çok hızlı regresyon ile ilgili geribildirimde bulunabilmektedir. Böylece yazılım mühendisi yazdığı kodun veya değiştirdiği kodun nerelerde sorunlara neden olacağını bildiği için test ortamına kodlarını göndermeden kendi bilgisayarında sorunları çözme imkanı sağlayacaktır. Hatalı kodların test ortamlarına geçilemeyeceği için test ortamının da sağlıklı çalışmasında katkı sağlayacaktır. Regresyon testleri en fazla çeşitliliği ve kapsama oranı ile bu katmanda olması en verimlisi olacaktır. Canlıda veya test ortamlarında manuel olarak yakalanan bir hata eğer regresyon testleri tarafından yakalanmadı ise bu durumda yine ilk olarak acaba bunun için bir birim testimiz yok muydu sorusu ile başlanarak ona birim testi yazıp, ihtiyaç halinde servis testi ve en son risk/kritiklik durumu değerlendirilerek ekran seviyesinde testi yazılmalıdır [7].

Otomatik Servis Regresyon Testleri

Servis testleri birim testlerinden sonra kapsamlı otomatik regresyon testlerinin olması gereken kısımdır. Birim testleri kadar hızlı olmasa da ekran katmanından çok daha hızlı ve sağlıklı çalışıp değişikliklerin etkisi (regresyon) hakkında geri bildirimde bulunacaktır. Testler genelde yazılım test mühendisleri tarafından yazılıp, bakımları yapılmakta ve koşum sonuçları incelenip raporlanmaktadır. Hatalar hata yönetim aracında kayıt altına alına alınıp canlı ortama geçmeden çözüm sağlanması hedeflenmektedir. Bu katmanda yine birim testlerinde olduğu gibi olduğunca detaylı farklı senaryolar eklenmeye uygundur. Ana pozitif akışlar yanı sıra, hata mesajları ve negatif senaryolarda otomatik regresyon testi setine dahil edilebilmektedir. Şu an Architecht test mühendisleri olarak REST ve SOAP servislerimizin otomatik regresyon testleri için açık kaynak kodlu Citrus/REST-assured/Karate gibi test frameworkleri kullanmaktayız.

Otomatik Ekran Regresyon Testleri

Ekran otomatik regresyon testleri ise pastanın üzerindeki çilek olarak düşünülebilir, yani test otomasyon piramidinin en küçük üst kısmı. Buraya hangi testleri dahil edelim veya etmeyelim kararları belirli bir strateji belirlenerek kararlaştırılması gerekmektedir. Yazım, bakım ve koşum maliyeti nedeniyle buradaki test senaryo sayısını kısıtlı tutmakta fayda vardır [8]. Ekran seviyesinde bir test senaryo 5 dakika sürebilecek iken aynı senaryo servis katmanı ve birim tarafında saniyeler içinde tamamlanmaktadır. Hızlı geribildirim almak çok mümkün değildir bu testlerde ve hata alan testler doğrudan hata olmayabilmektedir. Bir test ekran seviyesinde yapılan küçük bir değişiklikten veya küçük bir akış değişikliğinden etkileneceği için test sonuçları detaylı incelenmesi gerekmektedir. Test senaryolarının koşum süresi ve sonuçların inceleme süresi toplandığında hızlı geribildirim maalesef çok mümkün olmamaktadır. Ekran seviyesi testlerinin sağlıklı koşulup başarılı olabilmesinde yazılım mühendisleri ve test mühendislerinin birlikte çalışması değerlidir. Ekranların yazılırken otomatik regresyon testlerinde kullanılması üzere sayfa bazlı benzersiz tanım (ID) verilmesi önemlidir. Bu otomatik regresyon testlerinin düzenli olarak hızlı ve sağlıklı koşmasının yanı sıra test kodlarının bakım maliyetini de düşürecektir. Bir diğer artısı ise uygulamada dil ve akış bağımsız koşuma imkan sağlamasıdır. Nasıl ki yazılım yapılacağında iş birimi tüm özellikler olsun yazılsın ister, fakat fayda, imkan, zaman ve maliyet açısından kapsam belirlenip yazılım yapılır ise bu katmanda da her test yazılıp eklenmesi uygun olmayacaktır. Zamanla koşum süreleri, sonuç inceleme süreleri, bakım süreleri gibi konularda sorunlar çıkma ihtimali yüksektir. Fayda ve maliyet analizi yapılarak ekran seviyesinde otomasyona uygunluk değerlendirilerek her senaryonun ekran seviyesinde otomatik regresyon testi olarak yazılmaya uygun olmadığının farkındalığı olmalıdır. Web ve iOS/Android mobil uygulamalarımızın ekran seviyesinde otomatik regresyon testleri için Architecht test mühendisleri olarak açık kaynak kodlu test frameworkler Selenium ve Appium kullanmaktayız.

Şekil 5. Mobil Önyüz Denetleme Örneği

Kapsam ve Koşum Yönetimi

Regresyon testleri yeni özellikler eklendikçe sayı olarak artacağı için test koşumu için farklı teknikler kullanılabilmektedir. Zaman ve imkan olması durumunda testlerin tamamının koşulması tercih edilebilmektedir. Tekniklerden diğeri zamanın yeterli olmayacağı veya tam koşumun gereksiz olduğu durumda belirli risk/kritiklik seviyesinde olan testlerin sadece otomatik regresyon testi olarak koşulmasıdır, kısmi koşum olarak da bilinmektedir. Bu durumda paydaşların yüksek öncelik verdikleri senaryolar seçilmektedir. Diğer bir teknikte farklı seviyelerde olan testler zaman kapsamında öncelik seviyesine göre sıralanıp koşulmaktadır. Son olarak seçim ve önceliklendirmenin birlikte kullanıldığı hibrit durumdur [9].

Şekil. 6

Yani Regresyon Testi Gerekli mi?

Günümüzde yazılım ve ortamlarda sürekli olarak değişiklikler olduğu için regresyon testleri gereklidir ve değişikliklerin etkisi hakkında hızlı geri bildirim verebilmelidir. Hızlı geribildirimde test otomasyonu piramidinde belirtildiği gibi birim testleri ve sonrasında servis testleri ile mümkündür. Regresyon testleri sürekli tekrar koşum gerektiren testleri olduğu için mümkün olduğunca otomatik koşulması verimlilik adına, zaman ve maliyet adına kazanım sağlayacaktır.

Kaynaklar