#TestSüreçleri: Smoke Test
Test süreçlerinde hazırladığımız smoke(duman) süitlerimizin amacı sistemdeki temel/kritik işlevsel özelliklerin düzgün çalışıp çalışmadığına dair bilgi sahibi olmaktır. Ayrıca smoke süitlerin en büyük avantajı çalıştırılan ortamdaki dış bağımlılıkların sağlıklı çalıştıklarını görebilmemizdir.
Uygulamamızın dış bağımlılıklarına Network, Storage, Cluster, CDN gibi konuları örnek verebiliriz. Bu gibi dış etkenler yüzünden istenmeyen sorunlar yaşanabilir, buralarda oluşan hataları hemen fark edemeyebiliriz.
Deployment akışımız tamamladıktan sonra bazı şeylerden emin olamıyorsak ve sonrasında production ortamında göz gezdirmemiz gerekiyorsa, bu noktada smoke süitlere başvurabiliriz. Hazırlayacağımız basit süitler sayesinde başarılı bir deployment gerçekleştirdiğimize belirli ölçülerde (süitin kapsadığı durumlara göre) güvenebiliriz.
Smoke süitlerinde test etmemiz gereken temel işlevsel özellikler aslında proje özelinde değişiklik gösterebilir. Her sistemde diğer özelliklere karşın daha kritik olan bazı işlevsel özellikler mevcuttur.
Mesela para yatırma işlemleri ile mesajların listelenme sayfalarını düşünelim. Her iki işlem de gün içerisinde kritik öneme sahip olabilir. Bizim için para yatırma işlemleri daha önemli ve kesinlikle düzgün çalıştığından emin olmak istiyorsak, başlangıç da eforumuzu buna harcamalıyız. Smoke testleri yazarken en çok dikkat etmemiz gereken olay testlerin kapsadığı case ‘lerdir. Burada aşırıya kaçıp gereksiz testlerin eklenmesi, süitin amacının dışında çalışmasına neden olur ve testlerimizin süreleri ciddi artabilir.
İş sürecini iyi anlayıp case ’ler üzerinde seçici olmak önemlidir, aksi takdirde testleri yazacağımız ortam production ortamı olduğu için işler özelinde farklı durumlar da ortaya çıkabilir. Örnek verecek olursak para yatırma işlemlerinde ekstra KDV veya işlem ücreti kesildiğini düşünürsek smoke testlerimizin bize mali açıdan zararları olabilir. Bu gibi durumlarda testini yazacağımız modülün iç sürecini iyi bilmemiz gerekiyor, diğer türlü eforu yüksek ve hatta maliyetli testler bizi bekliyor olacaktır.
Smoke testlere “yatırım” yapmaya başlamadan önce, örnek verdiğimiz para yatırma ve mesaj listeleme süreçlerinde olması gereken test türlerini yukarıdaki örnek test süreçlerine bakarak temel olarak sıralayalım:
> Unit test
> Integration test
> Contract test
> Service test (api-acceptance)
> User Interface test (ui-acceptance)
Yukarıda yatırım kelimesini kullandım çünkü her bir test türü kendi içerisinde farklı eforlara sahiptir. Aynı test türü içerisinde bile sistemin/projenin sahip olduğu iş kuralları (business rules/logics) test eforunuzu değiştirebilir. Eforlar aslında işlere ve kurallara senaryo çıkarma yaklaşımınıza göre de artabilir.
İleride bir modül yeniden düzenlendiğinde(refactor edildiğinde) veya bir işe güncelleme (fix) çıkıldığında testlerin önemini gerçekten daha net anlıyoruz. Aslında sizin önceden çıkardığınız ve otomasyon testlerini yazdığınız senaryolar ne kadar fazla durumu (case) kapsıyorsa bizim t anında çalıştırdığımız regresyon süitlerine de güvenimizi o kadar artıracaktır.
Ayrıca smoke süitlere gereğinden fazla yük bindirmek ileriye dönük geliştirme sürecinizi olumsuz etkileyebilir. Testleri yazarken ve bunlar özelinde çalıştırılacak süitleri oluştururken tekrara düşmemeyi önemsemeliyiz. Çünkü günün sonunda her yazılan testin anlaşılabilir ve bakım yapılabilir olmasını bekliyoruz. Dikkat edilmediği durumlar da sprint ’lerden günlerinizi çalmaması için bir neden yok. :(
Örnek olması açısından aşağıya bir tane süit ekledim. Test süreçlerine yatırım yaptığımızı düşünerek artık smoke süitler hazırlamaya başlayabiliriz.
Süit hazırlarken bilmemiz gereken tag çeşitleri:
- <parameter>:
Süitlere environment geçerek testlerin koşacağı ortamı belirtebilirsiniz.
- <groups>:
Framework ‘lerdeki annotation ’ları kullanarak test metotlarına grup ekleyebilir ve süitlerinizin bu gruplara göre çalışmasını ayarlayabilirsiniz.
- <classes>:
Süit özelinde koşmasını istediğiniz test sınıflarını buraya ekleyebilirsiniz.
Not: Süitinize grup parametresi eklediğinizde , süite eklediğiniz test sınıfları içerisinden sadece ilgili test grubuna ait test metotlarının çalıştığını görebilirsiniz.
Bu tarz smoke süitler hazırlayarak hem bazı test süreçlerinden zaman kazanabilir hem de iş akışınızdaki kritik noktaların düzgün çalıştığına dair güven tazeleyebilirsiniz…
Smoke test yaklaşımlarını inceleyelim
Aşağıda örnek iki tane pipeline akışı göreceksiniz. Bunların sürekli teslimat (continuous-delivery) veya sürekli dağıtım (continuous-deployment) olmalarına takılmayalım lütfen :) sadece iki farklı projeymiş hissiyatı vermeye çalıştım.
Aslında ilk örnek Trendyol — SellerAds takımında da kullanmaya çalıştığımız pipeline akışlarına örnek olabilir. Tüm bu süreçler projelerin büyüklüğüne ve önemine göre değişebiliyor.
Trendyol genelinde takımlarımızın test süreçlerini kurgularken farklı yaklaşımları da deneyimliyor (PoC), iş sürecimize kattığı pozitif etkilere göre tercihlerimizi yapıyoruz.
Smoke testlerin çalıştırıldığı adımlara göre örnekleri değerlendirelim.
(CASE-1) İlk pipeline, tüm kabul (acceptance) test süreçlerini bitirip test ortamlarına ve production ortamına deploy alarak tamamladığını görüyoruz. Pipeline’nin son adımında, deployment ’in hemen sonrasında smoke testler çalıştırılmıştır.
Diğer pipeline ’de ise smoke testler acceptance testlerin hemen öncesinde çalıştırılmış ve akış continuous delivery standartında devam etmiştir.
Smoke testinin tanımını ve kullanım amacını bilen bir kişi yukarıdaki pipeline’nin smoke testlerin çalıştırıldığı adım açısından daha mantıklı olduğunu düşünebilir.
Bu yaklaşımın doğru olduğuna ben de katılıyorum. Fakat diğer yaklaşıma da yakından bakalım ve kullanım ihtiyaçlarının ne olduğunu anlamaya çalışalım.
(CASE-2) Aslında bu pipeline ’de smoke testin kullanım amacının dışına çıktığını da görebiliyoruz.
Aşırı uzun süren testlerin patladığı senaryolar da sürekli en temel fonksiyonel testlerin bile hata aldığı fark edilmiştir. Acceptance testlerden önce smoke testlerin koşmasına ihtiyaç duyulmasının en temel nedeni acceptance testlerinin aşırı uzun sürmesi veya stabil olmamasıdır.
Aslında temel işlevlerin(logic) test sonuçlarını erken görebilmek adına bu yola başvurulmuştur. Bu uzun süreyi beklemek yerine acceptance testlerin öncesine smoke süitlerin eklendiğini söyleyebiliriz.
Amacımız yukarıdaki örnekteki gibi uzun soluklu süitlerin koşmasından önce, bazı şeylerin doğru gittiğinden emin olmak olabilir. Bu gibi uzun bekleyişleri, regresyon süitlerimizden hata alma ihtimalimizin yüksek olduğu geliştirmeler(feature, bug fix, refactor) sonrasında daha net görebiliriz. Bazı geliştirmeler sonrasında, regresyon süitlerimizdeki testlerin kesin patlayacağı halde boşu boşuna tüm testlerin sonucunu beklemek yerine, bir bariyer ekleme ihtiyacı hissedebiliriz.
Burada başvurmamız gereken temel test yöntemi sağlık süitleri yani sanity testler olabilir. (Sanity hakkında detaylı bilgiye buradan ulaşabilirsiniz.)
Ama bildiğimiz gibi yazılım ve test dünyasında doğrular yanlışlar çok net olarak ayrılmış değil. Bu yüzden suite kullanımı vb. konularda şu yaklaşım kesinlikle doğrudur şu kesinlikle yanlıştır diyemeyiz. Farklı yaklaşımları inceleyip geliştirme sürecimize kattığı pozitif etkilere göre seçimler yapmalıyız.
Kesinliğin olmaması da çok doğal geliyor bana çünkü her projenin yapısı her takımın kültürü ve hedefi aynı değil :) aynı bizler gibi…
Süitlerdeki temel hatalar:
> İsimlendirme
> Kapsam
> Kullanım amacı
> Çalıştırılma zamanı vb…
Evet, yöntemler projeden projeye ve takımınınızın test yaklaşımına göre değişkenlik gösterse bile süitlerin kullanım amacında farklılıklar olabileceğini görebiliyoruz.
Bu yazı da smoke testlere başlamadan önce, dikkat etmemiz gereken temel süreçlerden bahsettik. Yazının devamında iki farklı smoke test yaklaşımını inceleyerek kullanım amaçlarını anlamaya çalıştık.
SellerAds takımında birlikte çalıştığımız Yiğitcan Uçum ve Metin Yücel Namli ‘ya destekleri için teşekkür ederim. Umarım faydalı olmuştur.
Bu süreçleri birlikte tartışıp birlikte geliştiren güzel bir ekibe dahil olmak istersen, başvurunu bekliyoruz.
#cometotrendyol :)
