Mobil Testlerde Karşılaşılan 10 Yaygın Sorun

Günümüzde teknolojinin gelişmesiyle birlikte mobil uygulamalar da hızlı bir şekilde artış gösteriyor. Bugünümüze baktığımızda alışveriş,oyun,iletişim ve birçok şeyi telefondan halleder olduk. Durum böyle iken mobil geliştirme dünyası hızlandı ve kullanıcılara hata oranın çok düşük olduğu uygulamalar üretmeye başlandı.

Kullanıcılar telefonuna indirdiği ve yeni keşfettiği her mobil uygulamada rahat, hatasız bir kullanım, güzel bir kullanıcı deneyimi görmek istiyorlar. Bugun ben de marketten bir uygulama indirdiğimde crash ,bug gördüğüm veya UI UX açısından yetersiz olduğunu düşündüğüm çoğu uygulamayı kaldırma eğilimdeyim. Bunun gibi örneklerle birlikte kullanıcıların tahammül seviyesi azaldığından potansiyel olarak kullanıcı kaybetmemek için kullanıcılara; geliştirmesi ve testleri stabil olarak yapılmış kaliteli ürünler üretmek gerekiyor.

Peki bu ürünlerin gelişiminde, test aşamalarında yaygın olarak nasıl sorunlarla karşılaşılıyor kendi görüşlerim doğrultusunda bunları 10 maddede özetlemek istedim. Gelin bir yakından bakalım.

1. Sürümler arasında nelerin değiştiği hakkında bilginin olmaması

Sprint boyunca geliştirmeler teste geldiğinde ve test işlemi manuel olarak yapıldığında test uzmanı yeni sürümdeki değişikliklerin ne olduğu konusunda yeterince bilgilendirilmeyebilir. Bu da testin verilen bilgi ışığında yetersiz kalmasına sebep olabilir.

Bu gibi durumları önlemek için bir CI/CD toolu kullanmak ve yapılan değişikliklerin commitlere bakarak testleri gerçekleştirebilir. Örneğin bir özellik veya bir bugfix test edilecekse değişiklikler commitlerden anlaşılabilir.

2. Etki Analizinin Bilinmememesi

Bir geliştirme veya bugfix yapılırken birçok yer etkilenebilir. Etki analizinin net olmaması veya test uzmanı tarafından bilinmemesi test sürecini olumsuz yönde etkileyebilir.

Otomatik CI / CD tarafından sağlanan sürümlerde daha fazla bilgi sağlandığında, etki ve temel neden analizleri çok daha bilgili bir şekilde yapılır ve sorunları çözmek için geçen süreyi azaltır.

3. Önceki Sürüm Bilgilerinin Dağınık ve Organize Olmaması

Bazı etki analizlerinde önceki sürümlere bakmak gerekebilir. Hangi sürümde nelerin değiştiğini görüntülemek CI/CD aracının olmadığı yapılarda mailler arasında kaybolmanıza sebep olabilir. Tüm bu geliştirme sürecinin geçmişine organize şekilde saklanmaması ve test uzmanının her sürümde ne gibi değişikliklerin yapıldığını bulamaması geliştirme sürecindeki zorluklardan biridir.

4. Test için Sınırlı Sayıda Cihaz Bulunması

Uygulamaları test ederken genellikle elimizdeki bulunan cihazlardan kabul testlerini gerçekleştiririz. Fakat piyasada oldukça fazla cihaz ve her bir markanın farklı özellikleri bulunmaktadır. Örneğin test cihazlarınızın arasında çentik özellikte bir telefon yoksa uygulamanızın iphone x gibi çentik özellikteki cihazlarda görünümünü test edemeyebilirsiniz. Bunun gibi sorunlara çözüm için bir device farm setinin satın alınması ve testlerin bunun gibi yapılar üzerinden test edilmesi uygulamaların farklı cihazlar üzerindeki davranışlarını görüntülemede fayda sağlayacaktır. Aynı zamanda bu sistemler uygulamayı test ederken Ram ve Cpu kullanımını gibi bilgileri de sizlere verebilir.

5. Beta Versiyonlar için Ortam Değişimleri Zorlukları

Uygulamaların yeni iOS ve Android sürümlerinn releaseinden önce Xcode ve Android SDK’nın beta sürümleriyle uygulamalar oluşturmak ve test etmek gerekir. Bunun için de iki farklı ortamda yapılar oluşturmak CI/CD yapıları olmadan zorlayıcıdır.

6. Bug life cycle döngüsünü Takip etme Zorluğu

Jira ve Tfs gibi iş takip sistemlerinde bir bugın yaratıldığı andan itibaren geliştiriciler ve test uzmanları tarafından takibini yapmak CI/CD hattının olmadığı yapılarda zor olabiliyor. Sorunun önceliğini belirlemek veya geliştirilen çözümün test edilip edilmediğini anlamak da mobil test süreçlerinin zorlukları arasında.

7. Teste gelme Sürelerinin Sprint Sonuna Sarkması

Bazen sprint boyunca geliştirmenin teste gelmesi manuel build işlemlerinden dolayı son günlere kalabiliyor. Bu da testlerin sıkışmasına sprintin son günlerine testlerin yığılmasına ve böylece test hacminin azalmasına, hataların gözden kaçmasına sebep olabiliyor.

Fakat CI/CD gibi yapılarda bu sorunlar her bir commit sonrasında otomatik build edilerek testcilere otomatik iletiliyor. Bu da bu sorunları çözümleme konusunda etkili olarak ekibin verimliliğini artırmada etkili olabilir.

8. Hata Durumlarında Build Kırıcı Sistemlerin Olmaması

Mobil CI/CD hattı kurulan yapılarda geliştiricinin yazdığı birim testlerinin sonucunda build çıkmadan hata olduğunda otomatik build kırılarak hatalar teste gelmeden önce farkedilip düzeltilebilir. Fakat bu yapılar olmadan böyle bir engelleme sistemi olmaz ve hatalar testte farkedilip geri geliştirmeye gönderilir. Bu da zaman kaybına ve gereksiz efora sebep olur.

9. Bug Kaydı Açarken Zaman Kaybı Oluşması

Manuel olarak bir mobil uygulamayı test ettiğinizde bug kaydı açarken bunları ekran görüntüsü ve videolar ile desteklemeniz gerekir. Fakat bu ekleri test cihazında yakalayıp buglarla ilişkilendiğinizde zaman kaybı oluşabilir.

Bir çözüm yöntemi olarak mobil cihazları önizleme ve ekran kaydını otomatik yakalayarak paylaşan yapılar bu zaman kaybının önlenmesinde fayda sağlayabilir.

10. Manuel Deployment ve Tekrar Eden Test Senaryoları

Genel olarak bu süreçler manuel bir şekilde ilerlediğinde regresyon senaryoları otomatize edilmeden hep benzer şeyleri yapmak sıkıcı olabiliyor. Veya manuel bir şekilde paket alımı da zaman kaybına yol açabiliyor.

Test otomasyonu ve CI/CD hattının düzgün bir şekilde ilerlediği yapılarda hata oranları daha düşük ve daha verimli çıktılar oluşturarak son kullanıcının faydasına yönelik bir üretim sağlanacaktır. Böylece hem geliştirme ekibi kaliteli bir ürün üretecek hem de son kullanıcı mutlu bir deneyim yaşayacaktır.

Bu yazımda Mobil geliştirme dünyasında özellikle CI/CD yapıları olmayan test süreçlerinde yaşanılan zorluklardan bahsetmeye çalıştım. Dilerseniz bu gibi sorunlara çözüm getiren AppCircle’’ı inceleyebilirsiniz. https://appcircle.io/

Bir Sonraki yazılarımda görüşmek dileğiyle.🙋‍♀️