Geliştiriciler için Çevik Uygulama Geliştirme Süreçleri ve Araçları — II

Serkan Bingöl
AWS Certified User Group Turkey
5 min readJul 10, 2019

Merhabalar herkese, bir önceki yazımızda çevik süreçleri nasıl ele aldığımızı ve kullandığımız araçları kısaca sizlere aktarmaya çalışmıştık. Bir önceki yazımıza ulaşmak için aşağıdaki bağlantıyı kullanabilirsiniz.

Bu yeni yazımız ile kalite kontrol ve yönetim süreçlerini çevik yazılım geliştirme yaklaşımında nasıl kullanıyoruz bunlara kısada olsa değinmek istiyoruz. Yazımızı 2 alt başlık altında toplıyacağız. İlk kısımda genel yaklaşımlar hakkında bilgi vereceğiz. İkinci kısımda ise küçük bir senaryo ile kullandığımız test modellerinden biraz bahsedeceğiz.

Test Aşamaları ve Yaklaşımları

Yazılım kalite süreçlerinde, yazılım test metodolojileri farklı yaklaşımlar ile sistemin bütünüyle doğru çalışıp çalışmadığını farklı yaklaşımlar ile inceleyerek kontrol etmeyi hedefler. Yazılım test metodolojileri birçok kaynakta iki ana başlıkta toplanır; İşlevsel “functional” ve işlevsel olmayan “non-functional”.

Functional testler içerisinde:

  • Birim (“Unit”) testi
  • Duman (“Smoke”) testi
  • Bütünleşme (“Integration”) testi
  • Fonksiyonel (“functional”) test
  • Arayüz (“Interface”) testi
  • Sistem (“System”) testi
  • Regresyon (“Regression”) testi
  • Kullanıcı Kabul (“UAT-User Acceptance Test”) testi

Non-functional testler içerisinde;

  • Performans (“Performance”) testi
  • Yük (“Load”) testi
  • Stres (“Stress”) testi
  • Güvenlik (“Security”) testi
  • Güvenlik Açığı (“Vulnerability”) testi
  • Kullanılabilirlik (“Usability”) testi
  • Uygunluk (“Compatibility”) testi

Yazılım testleri ve süreçleri ile ilgili genel bilgilendirme için bu link üzerinden Türkçe ISTQB dokümanlarına ulaşabilirsiniz.

Biz yazılım geliştirme süreçlerimiz içinde bir çok test aşamasından faydalanmaktayız. Bu yazımızda ise BDD yaklaşımından bahsedeceğiz.

BDD - Behaviour Driven Development

Son zamanlarda adını sıkça duyduğumuz Behavior Driven development (BDD), yazılım süreçlerinin daha test odaklı gitmesini sağlayan bir yaklaşımdır. Prensip olarak öncelikle test kodları yazılsın daha sonrasında bu testler ön planda tutularak proje kodu yazılsın anlayışını benimsemektedir. Bu sayede hem müşteri isterlerimizi önceden belirlenen ve istenilen koşullara göre geliştirmiş hem de müşteri ile aramızda yaşayan ve sürekli güncellenen bir döküman oluşturmuş oluruz.

BDD, TDD ’ nin karmaşıklığını gidermek amacıyla çıkmıştır. İkili arasındaki en büyük fark TDD sayesinde geliştirici diğer classlara bağımlılığı az olan, classların sorumluluklarını ayırarak tekrar etmeyen bir kod geliştirme süreci yürütür. BDD ile ise, bir sistemin davranışını, bu davranışın nasıl geliştirildiğine dair ayrıntıları düşünmeden sadece tanımlamalar yaparak oluşturabildiğimiz bir test yazım yaklaşımıdır.

Gherkin dili , BDD testlerimizi okunabilir bir formatta yazılabilmemize imkan sağlar. Bu dosyaların uzantısı genelde .feature olmakla birlikte, yazılan dosya gherkins olarak adlandırılır. Gherkin’de features ve scenarios kavramları vardır. Bu kavramlar sayesinde, yazılım geliştirici ürün davranışlarını rahat bir şekilde yönetebilmektedir.

Gherkin’de bulunan scenarios, o dosyanın yaptığı işin tek cümlelik özeti olmalıdır. Yani kısaca aksiyon ve neticenin birleşiminden edinilen sonucu aktarır.

BDD , Cucumber , Gherkin gibi konularda detaylı dokümantasyonu https://cucumber.io/docs/ adresi üzerinden inceleyebilirsiniz.

BDD - Gerkhin, Specflow ve NUnit Kullanımı ve Test Senaryosu

Geliştirmekte olduğumuz uygulama içinde kullanıcı giriş ekranları olduğunu düşünelim. Müşterimizin kabul kriterleri arasında şifre kontrolü ile ilgili bir maddesi var olduğunu biliyoruz ve geliştiriciler olarak bu madde ile ilgili testlerin kesinlikle çalıştırılması gerekliliğinin farkındayız. Senaryoya göre login ekranı üzerinde yanlış kullanıcı adı ve şifre ile girildiğinde hata verilmeli , doğru kullanıcı ve şifre girildiğinde ana sayfaya yönlendirilme gerçekleştirilmelidir.

Yanlış hesap bilgileri kontrolü
Doğru hesap bilgileri kontrolü

İlgili authentication testlerin sayfalar üzerinden gerçekleştirilmesi adına Client Projesi içinde “LoginViewModel.cs” , “AccountController.cs” ve “Login.cshtml” sayfalarını ve kod bloklarını oluşturalım.

İlgili Model , View ve Controller sayfaları

BDD yaklaşımını .net core projemiz üzerinde kullanmak için bir adet .Net Core için NUnit Test Projesi oluşturuyoruz. Cucumber üzerinden BDD testlerimizi yazmak adına sırasıyla “SpecFlow“, “SpecFlow.Tools.MsBuild.Generationve SpecFlow.NUnit paket’lerini projeye NuGet üzerinden dahil edelim. Burada klasörleme yapısını oluşturmak adına “Features” , “StepDefinitions” ve “Extensions” adında 3 adet klasör oluşturalım. Genel configuration opsiyonları için ise, aşağıdaki gibi specflow.json adında bir configuration file’ı oluşturalım. Configuration file’ını oluşturduktan sonra, “Features” klasörü içine “LoginFunctionality” adında bir feature dosyası ekleyelim.

Burada Gherkin script dilini kullanacağız. Gherkin’de features ve scenarios kavramlarına sahibiz. Bu kavramlar sayesinde, ürün davranışlarını rahat bir şekilde yönetebileceğiz. Gherkin’de bulunan feature müşteri isterini basit dille anlatılmaktadır , scenario ise o dosyanın yaptığı işin tek cümlelik özeti olmalıdır. Yani kısaca aksiyon ve neticenin birleşiminden edinilen sonucu aktarır. Given, belirlenen senaryoda oluşturulan testimizin başlangıç durumunu belirtmek için kullanılır. When, testimizde yürütülecek gerçek olayları içermektedir. Then ise testimizin sonucu ortaya koymak için kullanılır. Daha detaylı gherkin kullanımı için başlangıçta verilen linki inceleyebilirsiniz. Biz burada 2 adet senaryo yazıyoruz. İlk senaryo ile yanlış bilgiler ile giriş yapmaya çalışıp aynı sayfada hata mesajı alacağız, ikinci senaryoda ise doğru bilgiler ile giriş yapıp ana sayfaya ulaşacağız.

xz

İlgili feature dosyamızı oluşturduktan sonra , bu dosya üzerinde sağ tıklayıp “Generate Step Definations” diyerek StepDefinations klasörü içinde senaryonun adımlarında kullanılacak metodları yazıyoruz. When ve then adımlarını kodlayarak gerekli işlemleri yapıyoruz.

Burada bir sayfa üzerinde kullanıcı işlemlerini otomatize edeceğimiz için “Selenium.WebDriver” pakedini indirip, yaralanıp browser davranışları için bir yardımcı “WebBrowser.cs” sınıfı hazırlayıp gerekli metodları burada tanımlıyoruz. Bu metodlar url bulma, sayfa üzerindeki inputları bulma ve bilgi girme gibi işlemlerdir.

İlgili Test projemizi derleyip “Test Explorer” üzerinden işlemlere baktığımızda yazmış olduğumuz testlerin direk sistem üzerinden takip edilebildiğini görmekteyiz.

Aşağıdaki videomuzda Text Explorer üzerinden sistemi "Run All" ile çalıştırdığımızda tüm işlemlerin otomatik bir şekilde yapıldığını ve testlerin çalıştırıldığını takip edebilmekteyiz.

Sonuç :

Bu yazımız ile birlikte çevik yazılım geliştirme metodolojilerine test yaklaşımlarımızı ve kullandığımız araçları kısaca da olsa açıklamaya çalıştık.

Bir sonraki yazımızda görüşmek üzere.

İlgili Linkler

--

--

Serkan Bingöl
AWS Certified User Group Turkey

Muzur bir oğlan babası, hayvan sever, Harry Potter hayranı, bazen maceracı düz yazılımcı.