Otomasyon QAQA Otomasyon Mühendisi

Yerelleştirme (i18n) arayüzü ve yorumların otomatik kontrolünü nasıl gerçekleştirebiliriz: sorunun geçmişi, sorunlar ve çözüm yolları?

Hintsage yapay zeka asistanı ile mülakatları geçin

Cevap.

Otomatik testlerin ilk dalgası, temel pazarların İngilizce arayüze odaklanması nedeniyle yerelleştirme (i18n) kontrolünü pek ele almıyordu. Ancak uygulamaların küreselleşmesiyle birlikte yerelleştirme kalite gereksinimleri arttı: arayüz, desteklenen tüm dillerde doğru şekilde görüntülenmeli ve metin kaynakları ile biçimlendirilmiş dizeler, seçilen yerelleştirmeye bağlı olarak düzgün bir şekilde yüklenmelidir.

Temel sorun – manuel kontrol çok masraflıdır ve otomatik testler format, bağlam, dillerin özellikleri (örneğin, sağdan sola veya dilbilgisel özellikler) gibi değişkenler nedeniyle karmaşıktır. Bir parça için çevirinin olmaması, biçimlendirme hataları, düzen hataları olabilir.

Çözümler, her yerelleştirme için test verileri ile çalışma, snapshot testleri kullanma, UI öğelerini referanslarla karşılaştırma, kaynak dosyaları için "anahtar-değer" ilkesi ile kontrol araçları entegre etme, API arayüzü aracılığıyla dizeleri otomatik çıkarma ve karşılaştırma yapma ve kaynak dosyaları üzerinde düzenli olarak linterler çalıştırmayı içerir.

Ana özellikler:

  • Tüm desteklenen dillerin varlığının ve doğru görüntülenmesinin kontrolü.
  • Referans çevirileri ile arayüzdeki mevcut görüntülemenin karşılaştırılması.
  • Biçimlendirme hatalarının önlenmesi için metinlerin uzunluk ve biçim doğrulayıcıları.

Sinsi Sorular.

Herhangi bir yerelleştirmeyi tek bir script ile doğrulayan evrensel bir test yapılabilir mi?

Kısmen evet, ancak dillerin incelikleri (durumlar, cins, giriş yönü) genellikle bu tür testlerde manuel düzeltmeler veya ek koşullar gerektirir. %100 evrensellik mümkün değildir.

Eğer çeviri dosyası varsa ve başarılı bir şekilde yüklenmişse, bu, i18n testinin geçtiği anlamına mı gelir?

Hayır. Dosya uygulama tarafında hatalı bağlanmış olabilir, anahtarında hata olabilir, çeviri kullanımı bağlamı ihlal edilmiş olabilir, hesaba katılmamış özel karakterler olabilir vb.

%1'den az kullanıcıya sahip diller için yerelleştirme testlerini otomatikleştirmenin anlamı var mı?

Evet, eğer bir kullanıcının işletme açısından önemi büyükse, örneğin sözleşme yükümlülüklerini yerine getirme ya da özel gereksinimler olan pazarlar için. Otomasyon, manuel kontroller karşısında kaynakları önemli ölçüde tasarruf ettirir.

Tipik Hatalar ve Anti-Desenler

  • Yalnızca dosyanın varlığını kontrol etmek, UI'de gerçek görüntülenmesini değil.
  • Dilin gramer ve format özelliklerine dikkat etmeden katı string karşılaştırması yapmak.
  • Bir yerelleştirmeden diğerlerine uyarlama yapmadan kör kopyalama testi.

Gerçek Hayattan Bir Örnek

Olumsuz Durum

Ekip, .po dosyasındaki anahtarların orijinal İngilizce metinle karşılaştırılmasını sağlayan otomatik testler uyguladı ve bunun yeterli olduğunu düşündü. UI testleri yapılmadığından, Arapça sürümün çıkışında tüm metin düğmelerin dışına kaymış durumda bulundu ve bazı satırlar tamamen yanlış anahtarlar nedeniyle çevrilmemişti.

Artılar:

  • i18n otomasyonu hızlı bir şekilde uygulandı.

Eksiler:

  • Gerçek kullanıcı senaryolarının düşük kapsamı.
  • Önemli UX hataları gözden kaçtı.

Olumlu Durum

Kaynakların linting'i ile tüm dillerde arayüzü döngüsel olarak test eden, ekran görüntüleri alan ve bunları referans düzenlemelerle karşılaştıran bir bağlantı gerçekleştirildi. RTL/LTR öğelerin karıştığını tespit eden ekip, kök nedeni buldu ve bunu sürümden önce giderdi.

Artılar:

  • Gerçek koşullarda tüm senaryoların maksimum kapsamı.
  • Yeni diller eklenirken kolay destekleme.

Eksiler:

  • Referanslar tabanının desteklenmesi yüksek maliyetli.
  • Biçimlendirme ile ilgili karmaşık durumların periyodik manuel kontrolü gerekmektedir.