Test Otomasyon
Bu makalemizde test otomasyonla ilgili aşağıdaki soruların cevaplarını vermeye çalışacağız ve başarılı bir test otomasyon mimarisinde dünyaca kabul edilmiş pratiklere değineceğiz.
- Neden test otomasyon? Ne kadar kapsamlı düşünmeliyim?
- Test otomasyon mimarimiz nasıl olmalı?
- Test piramidi ve her bir adım için kabul edilmiş pratikler ve kullanılan araçlar nelerdir?
Neden test otomasyon?
Bu sorunun bir çok cevabı olabileceği gibi en temelde 2 sebebi vardır:
- Müşterilere daha hızlı, daha güvenli ve daha problemsiz yenilikler sunmak
- Sistemimizin davranışını tanımlamak
Kapsam konusunda ise kesinlikle düşünmeden işe koyulmalıyız ve ilk adım olarak denemeler yapmalıyız. Çünkü test otomasyon konusunda başarıya giden en önemli etken sistemimizi iyi tanımak, ihtiyaçlarını iyi belirlemektir. Bu konuda basma kalıp kurallara asla bağlı kalmamalıyız, her bir sistemin kendi içerisinde farklı davranışları ve farklı ihtiyaçları var. Bu ihtiyaçları anlamak, bilmek bu işte başarılı olmanın altın kuralıdır diye düşünüyorum.
Doğru test otomasyon mimarisi nasıl olmalı?
Mimari konusunda düşünmeye başladığımızda yapmamız gereken en önemli şey; bu konuda kesin yazılı yasalar ve çok başarılı tek bir araç olmadığı kabulü ile ilerlemek olacaktır. Tek bir kural veya tek bir araca bağlı bir sistem kurduğumuzda, bu kural veya aracın başarısızlığı bizim sistemimizin de başarısızlığı olacaktır. Dolayısıyla farklı kurallar ve farklı araçları, önündeki problemi çözebilmek için kullanabilen esnek bir mimari, bizi başarıya ulaştıracaktır. Aynı zamanda böyle bir mimari bize ileride yaşayabileceğimiz performans sorunları için de esneklik sağlayacaktır. Bunun yanı sıra, test otomasyon mimarimizi kurgularken, aşağıdaki 4 maddeyi sürekli göz önünde bulundurmamız gerekiyor:
- Güvenilirlik; testlerimiz yani senaryolarımız bize güven veriyor mu? Bu senaryoları otomasyon sistemimize tamamen entegre ettiğimizde, arkamıza yaslanıp bu iş tamamdır diyebilecek miyiz?
- Maaliyet; düşündüğümüz mimariyi ne kadar zamanda geliştireceğiz? Mimarimizi hayata geçirdiğimizde bu testlerin bakım desteği için ne kadar efor sarf edeceğiz?
- Hız; testlerimiz ne kadar sürede koşacak ve test süreçlerimize nasıl bir katkısı olacak?
- Hedef; tüm bu testler ve mimarimiz bizi hedeflediğimiz noktaya doğru götürüyor mu?
Test piramidi ve stratejisi
Başarılı bir yazılım projesine giden yol başarılı bir test sürecinden geçmektedir. Bunun da en iyi yollarından bir tanesi Test piramididir. Bilinen en temel test piramidi ise aşağıdaki şekildedir.(Resim1)
Resim1ve Resim2'deki test piramidine baktığımız zaman manuel testleri görememekteyiz, genelde de piramidin yaygın 2 hali bu şekildedir. Çünkü test otomasyon tamamen manuel testlerin eşleniği ve yerini alacak olarak görülmekte. Aslında bunu günümüz teknolojilerinde böyle düşünmek biraz yanlıştır. En azından bir süre daha belirli durumları içeren manuel testlerimiz de devam edecek gibi görünüyor .
Manuel testlerin de hesaba katılıp, kapsamlı bir şekilde düşünüldüğü piramidimiz Resim3'deki halini alacaktır.
Peki en temel hali ile piramidin içerisindeki test tipleri nelerdir? Yaygın olarak kullanılan araçlar nelerdir?
Unit Test
Piramidimizin en alt basamağıdır, test senaryo sayısı olarak baktığımızda en çok sayının olmasını beklediğimiz adımdır çünkü maliyeti en düşük adımdır. Amacı da yazılım projemizin en küçük yapı taşlarının testinin gerçekleştirilmesidir. Dolayısıyla projenin tamamının başarılı olacağı garantisini vermez sadece ilgili birimin doğru çalıştığını garantiler. Bu kapsamda sorumlusu ve garanti altına aldığı kişi yazılımcıdır. Aslında ironik bir şekilde en büyük düşmanı da yazılımcıdır :) React geliştirme dünyasında unit test için en yaygın kullanılan 3rd parti kütüphaneler Jest, Enzyme ve React Testing Library’dir.
Entegrasyon Testi
Adından da anlaşılacağı üzere, birbirinden farklı parçaların bir araya geldiğinde çalışırlığının testinin yapıldığı adımdır. Bu bir veritabanı entegrasyonu olabilir, 3rd parti entegrasyonu veya framework entegrasyonu da olabilir.
End-to-End(E2E) Test
Piramidimizin en üst adımıdır, en maliyetli testlerimiz de bunlardır, dolayısıyla en dikkatli olmamız gereken test adımı da bu adımdır. Bu adımda amaç uçtan uca akışın kontrolüdür. Maliyetli olmasının sebebi hem koşuların uzun sürmesi hem de sistem bakımıdır.(Snapshot güncellenmesi, mock datalar vb..) Buradaki maliyetler ve beklentilerin farklılığı ile zaman içerisinde UI ve E2E testler olarak bu adım 2'ye bölünmüştür. Web platformlar ve mobil platformlar olarak düşünüldüğünde farklı araçlar kullanılmaktadır, mimari kısımında vurguladığım araç bağımsız mimari kurgusunun bir sebebi de budur. Örneğin web dünyasında daha çok Selenium kütüphanesi kullanılırken mobil dünyada daha çok Appium kütüphanesi kullanılmaktadır.
Okuduğunuz için teşekkür ederim.
Aşağıdaki hesaplar üzeriden benimle iletişime geçebilirsiniz.
