Mobil Testle Neden Sola Kaymanız Gerekiyor?

Test etme kavramıyla her zaman bir aşk-nefret ilişkisi olduğunu hissediyorum. Şüphesiz, yaptığınız her şeyi test etmenin faydaları, müşterilerin aynı keşifleri bildirmelerini engellemenize yardımcı olur. Bu ilişkinin aşk kısmıdır.

Nefret kısmı, proje zaman çizelgelerinin testin daha düşük bir öncelik haline gelmesine neden olmasıdır… çoğu zaman mevcut bir sprint'te nadiren ortaya çıkan bir biriktirme listesi istek listesi öğesi haline geldiği noktaya kadar. Bu neredeyse müşterilerin sizinle beklenmedik sonuçlarla iletişime geçeceğini garanti eder.

Yazılım geliştirme yaşam döngüleri (SDLC'ler) olgunlaştıkça testler daha kolay hale geldi ve geliştiricilerin doğrulanan hususu tam olarak kapsayan birim testleri oluşturmasına olanak tanıdı. ChatGPT veya GitHub Co-Pilot'un kullanımı, bu tür birim testlerinin otomatik olarak oluşturulabileceği noktaya kadar olgunlaştı. Sürekli entegrasyon (CI) araç çözümleri, herhangi bir çekme talebinin (PR) birleştirilebilmesinden önce yüksek düzeyde kod kapsamını zorunlu kılacak şekilde geliştirildi. Bunu yapmak, ekiplerin geliştirme aşamasında sola kaymasına olanak tanıyarak sorunları geliştirme aşamasında ele almaya zorlar ve özelliklerin maliyetini düşürür.

Bu yaklaşım, geleneksel API'ler ve web çerçeveleri için harika çalıştı, ancak mobil uygulamaları test etmek genellikle ekiplerin manuel test yapmasını gerektirir; bu test, yönetilebildiği kadar çok farklı cihaz türü genelinde yayınlanmış bir adım listesinden yürütülür.

Mobil geliştirme ve testlerin sola kaydırma konseptini kullanabileceği bir yol belirleyip tanımlayamayacağımı görmek istedim.

Mobil Testte Neler Eksik?

Yüksek düzeyde, mobil uygulama alanı, bugün API'lerin ve web çerçevelerinin test ettiği şekilde özellikleri ve işlevleri test etme yeteneğine sahip olmalıdır. Bu, fiziksel cihazların veya emülatörlerin envanterini kullanarak testleri manuel olarak gerçekleştirme işinden çıkmak anlamına gelir.

Mobil testin bu ideal durumu, kullanıcı etkinliğine odaklanan şifreli testler yazmaktan kaçınmak için kullanıcı arayüzü odaklı olacaktır. Bu yaklaşım, araçları, vizyonlarını gerçeğe dönüştürmek isteyen iç tüketicilere veya ürün sahiplerine kadar genişletebilir.

Tıpkı geleneksel birim veya entegrasyon testlerinde olduğu gibi, modülleri tanıtma yeteneği, mobil uygulamanın küçük yönlerini doğrulayabilir ve daha büyük akışlar için yapı taşları olarak kullanılabilir. Ekipler bunu yaparak "kuru" kalabilecek (kendinizi tekrar etmemek) ve mükerrer işlerden kaçınabilecektir.

Son olarak, bu testlerin, grafiksel bir kullanıcı arayüzü tarafından yönlendirilmesine rağmen CI/CD hattının bir parçası haline gelebilmesi gerekecektir.

Bu ideal durumda, mobil yazılım mühendisleri mobil geliştirme ve test işlemleri için etkili bir şekilde sola kayabilirler.

Neyse, “Sola Kaydır” nedir?

Mobil test için "sola kaydır" dediğimde ne demek istediğimi netleştirmek iyi bir fikir.

Vikipedi test için sola kaydırmayı aşağıda belirtildiği gibi tanımlar:

“Sola kaydırma testi, testin yaşam döngüsünde daha erken gerçekleştirildiği (yani proje zaman çizelgesinde sola taşındığı) yazılım testi ve sistem testine yönelik bir yaklaşımdır. 'Erken ve sık sık test edin' ilkesinin ilk yarısıdır. 2001 yılında Larry Smith tarafından icat edildi.”

Basitçe sola kaydırmayı benimsemek, kusurların geliştirme aşamasında tanımlanmasına olanak tanır. Kaynağa odaklanan mühendisin/mühendislerin zihninde özellik henüz tazeyken sorun ele alınabileceği için bu önemlidir.

Sola kaydırmayı benimsemenin faydalarından bazıları şunlardır:

• Geliştirme sırasında sorunları bulup düzelterek özelliklerin sunulması için maliyet azaltımı.
• Teslimattan uzun süre sonra çözümleri yeniden gözden geçirmek için gereken sürenin azalması nedeniyle daha yüksek verimlilik.
• Geliştirme aşamasında tamamen kapsama ve doğrulama zorunluluğu nedeniyle daha yüksek kalite.

Sonuçta sola kayma konsepti, çözümler doğrulanmış ve beklendiği gibi çalışan tüketicilere ulaştığında rekabet avantajı sağlayacaktır.

Tosca Hakkında

Geçen yıl “ Müşteriye Yönelik Uygulama Kalitesini Tricentis Testim Kullanarak Artırma ” makalemde Tricentis Testim kullanımını araştırmıştım. Magic 8 Ball çözümümü GO tabanlı RESTful API ve Vue.js web tabanlı istemci kullanarak doğrulamanın ne kadar kolay olduğundan etkilendim. Tricentis'in ekiplerin mobil test için sola kaymasına olanak tanıyacak bir çözümü olup olmadığını görmek istedim.

Meğer Tosca diye bir ürünleri varmış.

Tosca ürünü, kodsuz test üretimi sağlayarak yeniden kullanılabilen ve otomatikleştirilebilen küçük modüllerin oluşturulmasına olanak tanır. Bu modüller, aralarında standart bir sözleşmenin kullanılması nedeniyle ihtiyaç duyulan yere bağlanabilen Lego blokları olarak düşünülebilir. Tosca, özellikleriniz için mobil testler oluşturmaya yardımcı olmak üzere yapay zekadan yararlanma yeteneği sağlayarak işleri daha geleneksel geliştirme yaşam döngülerine bir adım daha yaklaştırıyor.

Tosca ayrıca Tricentis Mobile Agent aracılığıyla ağır bir öğrenme eğrisi olmadan açık kaynak Appium projesinin gücünden yararlanıyor. Bu, önceki yazımda sağlanan tüm gücün, mobil geliştirme ile sola kayma yolculuğuna dahil edilmesini sağlar.

Sonuç olarak Tosca, yerel, hibrit ve web mobil uygulamalarının gerçek iPhone, Android, cep telefonu ve tablet cihazlarda, bu cihazların bakımını yapmadan ve bulundurmadan test edilmesine olanak tanır.

Tıpkı Testim ürünü gibi Tosca çözümü de testlerin CI/CD işlem hatlarının bir parçası olarak yürütülmesine olanak tanıyarak sola kaydırmanın benimsenmesine olanak sağlar.

Tosca'yı doğrudan bir iOS veya Android telefon üzerinde test etmek için kullanabileceğiniz gibi, Android Studio benzeri bir IDE aracılığıyla sunulan emülatörler veya simülatörler aracılığıyla da kullanabilirsiniz. Tosca'yı kullanarak uygulamanızı tarayabilir ve test senaryoları oluşturmasını sağlayabilirsiniz:

Tosca test senaryolarını oluşturduktan sonra siz de kendi test senaryolarınızı oluşturabilirsiniz.

Tosca'nın avantajlarından biri de kod yazmanıza gerek kalmadan test yazmanıza olanak sağlamasıdır. Bu, bir tarayıcıyı açmak veya bir formu doldurmak da dahil olmak üzere çoğu eylemi simüle edebilen modül kütüphanesi sayesinde mümkün olmaktadır.

Bu örnekte Tosca mobil test durumumuz için üç modül kullandık. Test ediyoruz:

1. Bir tarayıcı açmak ve uygulamamızın uç noktasına ulaşmak
2. Belirli bir araç tipinin seçilmesi
3. Söz konusu araç hakkında bir form doldurmak

Tek yapmamız gerekenin örnek girdiler sağlamak olduğuna dikkat edin (ekran görüntüsünde bunu yukarıda vurgulanan 3. adım için yapıyoruz). Test tamamlandığında Tosca hakkında bir teşhis raporu alacaksınız.

Mobil Test için sola kaydırın

Mobil geliştirmeye odaklanan yazılım mühendisleri, Tosca gibi bir üründen yararlanarak, mobil testlere bırakılan pislikleri kullanarak ekiplerine rekabet avantajı sağlayabilir:

• Mobil özellikler, hizmetler ve web çerçevelerine benzer şekilde geliştirme aşamasında doğrulanır.
• Testler, vizyonlarını sağlamlaştırmaya yardımcı olmak için dahili tüketicilere ve ürün sahiplerine genişletilebilecek bir kullanıcı arayüzü tarafından yönlendirilir.
• Test paketi, yeni özellikleri ve işlevleri tam olarak kapsayacak şekilde yapılandırılmış bir "kuru" modüller koleksiyonundan oluşturulabilir.
• Testler, bu tür cihazlara sahip olmadan ve bunların bakımını yapmadan, kapsamlı bir mobil cihaz envanterine karşı yürütülebilir.
• Birincil kod dalına yeni özellikler eklemeden önce, ilgili PR, kullanıcı arayüzü tarafından oluşturulan testleri, API veya web çerçevesi CI/CD işlem hatlarında birim veya entegrasyon testlerinin yürütüldüğü şekilde çağırırdı.

Çözüm

Okuyucularım, her BT uzmanına uygulanabileceğini düşündüğüm aşağıdaki misyon beyanına odaklandığımı hatırlayabilirler:

“Zamanınızı fikri mülkiyetinizin değerini artıran özellikler/işlevsellik sunmaya odaklayın. Diğer her şey için çerçevelerden, ürünlerden ve hizmetlerden yararlanın.” -J.Vester

Verimliliğin zirvesine ulaşmak için, mobil geliştirmeye odaklanan yazılım mühendislerinin mobil testlerde sola kaydırmayı benimsemeleri gerekir. Ancak ideal seçim, çözüm ararken ilgili öğrenme eğrisini ve desteklenebilirliği dikkate almalıdır.

Tosca ürünü, ekiplerin desteklenmesi ve bakımı gereken ek kaynak kodu olmadan sola kaydırma durumuna ulaşmasını sağlayarak kişisel misyon beyanıma uyuyor. Ürün aynı zamanda mühendis olmayan kişilerin de test geliştirme sürecine katılmasına olanak tanıyarak, tasarımların beklentilerle eşleşmesini sağlama konusunda ekiplere avantaj sağlıyor.

Ben birkaç yıldır kişisel olarak sola kaydırma yaklaşımını kullanıyorum ve sadece süreci takip ederek bir kusurun önlendiği her seferde elde ettiğim deneyimi takdir ediyorum. Mobil geliştirmenin sola kaydırma kavramını kullanma zamanı geldi.

Gerçekten harika bir gün geçirin!