LQA Nedir? Yerelleştirme Kalite Analizi Sürecinin Dört Aşaması

Yerelleştirme projelerinde kalite tartışması genellikle teslimden sonra başlar. Oysa kaliteyi belirleyen kararların çoğu, ilk kelime çevrilmeden önce alınır. Hangi hataların kabul edilemez olduğu, testi kimin yapacağı, bulguların nasıl kaydedileceği baştan belirlenmezse denetim aşaması bir tartışmaya dönüşür.

İçindekiler

Sektörde bu işin adı LQA. Peki LQA nedir? Miguel A. Jiménez-Crespo, yerelleştirilmiş ürünün kalitesini denetleme sürecinin test etme, kalite güvencesi ya da yerelleştirme kalite güvencesi olarak adlandırıldığını belirtiyor ve sürecin ürünün düzgün çalışmasını, kullanılabilir ve erişilebilir olmasını amaçladığını yazıyor (2024, s. 61).

Bu yazıda LQA sürecinin dört aşamasını, her aşamanın somut çıktısını ve satın alan tarafın hangi noktalarda müdahale etmesi gerektiğini anlatıyoruz.

LQA nedir ve neyi kapsar?

LQA, yerelleştirilmiş ürünün beklenen niteliklere sahip olduğunu doğrulamak için yürütülen bütün işlemlerin ortak adı. Kapsamı yalnızca metnin okunmasıyla sınırlı değil: ürünün çalışması, ekranda doğru görünmesi ve engelli kullanıcılar dâhil herkes tarafından kullanılabilmesi de bu çerçeveye giriyor.

Süreç, yerelleştirme türüne ve içerik tipine göre değişiyor. Kitap, sektörde tek beden herkese uyan bir yaklaşım bulunmadığını, uygulamaların içerik türüne, kalite stratejisine ve seçilen kalite çerçevesine göre farklılaştığını vurguluyor (Jiménez-Crespo 2024, s. 61).

Süreci yürüten kişi genellikle bir kalite ya da test yöneticisidir. Aşamaları planlar, takvimlendirir ve farklı dillerdeki test uzmanlarını koordine eder. Küçük projelerde bu rolü proje yöneticisi üstlenir; ancak rol tanımsız kaldığında aşamalar birbirine karışır ve sorumluluk kimsede kalmaz.

LQA’yı bir kerelik kontrol olarak düşünmemek gerekiyor. Aşamalar art arda ya da yinelemeli biçimde işletilebiliyor, farklı değerlendiriciler tarafından yürütülebiliyor ve bir bölümü otomatik araçlara devredilebiliyor. Süreç, projenin büyüklüğüne ve içeriğin kritikliğine göre daralıp genişleyen esnek bir çerçeve olarak kuruluyor.

Aşama 1: Planlama ve kalite tasarımı

İlk aşamaya “kalite tasarımı” da deniyor ve kalite gerekliliklerinin dikkatle belgelenmesini kapsıyor. Dunne’ın müşteri odaklı LQA önerisinde bu aşamanın önemi özellikle vurgulanıyor (aktaran Jiménez-Crespo 2024, s. 67). Burada atlanan her madde, ilerleyen aşamalarda katlanarak maliyet üretiyor.

Belgelenmesi gereken alanlar üç başlıkta toplanıyor: dilsel gereklilikler, terminolojik gereklilikler ve görsel gereklilikler. Bunlara ek olarak hangi tür kalite güvence ve kalite kontrol süreçlerinin uygulanacağı da yazılıyor.

Planlama aşaması ayrıca test takvimini, kullanılacak hata türü sınıflandırmasını, hata bildirim aracını ve seçilen kalite çerçevesini tanımlıyor. Bu dört kararın işin başında verilmesi, denetim raporunun karşılaştırılabilir olmasını sağlıyor.

Planlamanın gözden kaçan bir işlevi daha var: beklentiyi kısıtlarla hizalamak. Bütçe, teslim tarihi ve mevcut insan kaynağı bu aşamada masaya konduğunda, hangi kalite seviyesinin gerçekçi olduğu da netleşiyor. Sonradan yaşanan hayal kırıklıklarının çoğu, bu hizalamanın hiç yapılmamış olmasından kaynaklanıyor.

Aşama 2: Test öncesi hazırlık

İkinci aşamada her dildeki test uzmanları talimatları, yerelleştirme kitlerini ve stil kılavuzlarını alıyor. Bu belgeler olmadan yapılan test, denetçinin kişisel tercihlerini ölçmekten öteye gitmiyor; aynı dosyayı iki denetçi okuduğunda iki farklı rapor çıkıyor.

Talimatlar bazen çok somut olabiliyor. Kitap, oyun yerelleştirmesinde talimatların kaç saat oynanacağını ya da kaç bölümün geçilmesi gerektiğini bile içerebildiğini aktarıyor (Jiménez-Crespo 2024, s. 67). Bu tür bir sayısallaştırma, testin kapsamını ölçülebilir hâle getiriyor.

Stil kılavuzu bu aşamanın en değerli belgesi. Mozilla’nın açık erişimli yerelleştirme stil kılavuzu, üslup, hitap biçimi, sayı ve tarih biçimleri gibi başlıkların nasıl belgelendiğine iyi bir örnek sunuyor ve kendi kılavuzunuzu hazırlarken şablon olarak kullanılabiliyor.

Yerelleştirme kitinin içeriği de bu aşamada netleşiyor: kaynak dosyalar, terim listesi, ekran görüntüleri, karakter sınırları ve varsa önceki sürümün çeviri belleği. Bu paketin eksik gönderilmesi, test aşamasında bulunan hataların önemli bir bölümünün asıl nedeni oluyor.

Aşama 3: Testin yürütülmesi

Asıl test, yerelleştirilmiş içeriğin gözden geçirilmesini kapsıyor. Bu gözden geçirme iki dilli bir biçimde, yerelleştirme ve çeviri araçları üzerinden ya da doğrudan hedef sürüm üzerinde yapılabiliyor. Hangisinin seçileceği yerelleştirme türüne bağlı.

Bulunan hatalar aynı şekilde işlenmiyor. Dilsel nitelikli hatalar doğrudan düzeltilebiliyor; işlevsel ya da görsel nitelikli hatalar ise hata bildirim mekanizmalarına kaydediliyor, çünkü çözümleri kod veya yerleşim değişikliği gerektiriyor. Oyun yerelleştirmesinde dilsel sorunlar da hata raporuna işleniyor (Jiménez-Crespo 2024, s. 67).

Otomatik testler bu aşamanın bir bölümünü üstlenebiliyor. Etiket bütünlüğü, sayı tutarlılığı, boş segment ve terim uyumu gibi kontroller makineyle yapılabiliyor. Ancak otomatik kontrol yalnızca biçimsel sorunları yakalıyor; anlam ve uygunluk kararları insanda kalıyor.

Aşama 4: Düzeltmelerin uygulanması ve kayıt

Son aşamada hata bildirim ve takip araçları kullanılarak düzeltmeler uygulanıyor ve yapılan işlemler belgeleniyor. Bu belgeleme, projenin kapanışında değil, bir sonraki projenin planlamasında değer üretiyor.

Kaydedilen hata verileri, yerelleştirme ve test süreçlerinin nasıl iyileştirileceğini analiz etmek için saklanıyor. Kitap bu geri beslemenin gelecekteki LQA planlamasını ve kalite tasarımını iyileştirdiğini vurguluyor (Jiménez-Crespo 2024, s. 67).

Uygulamada en sık atlanan aşama bu. Hatalar düzeltilir, dosya teslim edilir, veri kaybolur. Oysa üç projeden sonra hata kayıtlarına bakan bir ekip, tekrar eden sorunların hangi kaynaktan geldiğini genellikle net biçimde görebiliyor. Kaynağın kaynak metin mi, stil kılavuzu mu, yoksa araç yapılandırması mı olduğu ancak bu birikimle anlaşılıyor.

QA ile QC arasındaki fark

Bu iki kısaltma sıkça karıştırılıyor. Kalite güvencesi, sürecin öncesinde, sırasında ve sonrasında yordamlar kurarak önceden belirlenmiş gerekliliklerin karşılanmasını sağlamayı ve başarısızlığı önlemeyi hedefliyor.

Kalite kontrol ise bitmiş ürünü inceleyip oluşmuş başarısızlıkları saptamayı ve bunların müşteriye geçmesini engellemeyi amaçlıyor. Kaynak metnin hazırlanmasından teslimata kadar bütün döngüde uygulanıyor ve kalite güvencesinin bir alt kümesi sayılıyor (Jiménez-Crespo 2024, s. 68).

Fark pratikte şuna denk geliyor: kalite güvencesi olmadan yalnızca kalite kontrol yapan bir proje, aynı hataları her seferinde yeniden yakalar. Hataların kaynağı kurutulmadığı için maliyet her sürümde tekrarlanır ve denetim bütçesi zamanla şişer.

Kalite kontrol genellikle standartlaştırılmış ölçütlerle, hata analizine dayalı olarak yürütülüyor. Yani hatalar sayılıyor, ağırlıklandırılıyor ve bir eşikle karşılaştırılıyor. Bu yöntemin gücü karşılaştırılabilir sonuç üretmesi; sınırı ise yalnızca sayılabilen sorunları görebilmesi ve kullanıcı deneyimini doğrudan ölçememesi.

Sürekli yerelleştirmede döngü nasıl işliyor?

Aşamalar art arda uygulanabildiği gibi, sürekli yerelleştirme ortamlarında yinelemeli olarak da işletilebiliyor. Bu ortamlarda içerik küçük paketler hâlinde ve sık aralıklarla akıyor; klasik bir test dönemi ayırmak mümkün olmuyor.

1. Kalite gereklilikleri bir kez yazılır, her sürümde yeniden kullanılır.
2. Test uzmanları sabit kalır, böylece bağlam bilgisi birikir.
3. Otomatik kontroller her pakete uygulanır, insan denetimi örneklemle yapılır.
4. Hata bildirimleri tek bir sistemde toplanır.
5. Belirli aralıklarla kayıtlar incelenir ve şartname güncellenir.

Aşağıdaki tablo dört aşamanın çıktısını ve sorumlusunu özetliyor. Bir projede bu satırların karşılığı boş kalıyorsa, o aşama fiilen yürütülmüyor demektir.

Aşama	Somut çıktı	Tipik sorumlu
Planlama	Kalite gereklilikleri belgesi	Kalite yöneticisi ve müşteri
Hazırlık	Stil kılavuzu ve yerelleştirme kiti	Proje yöneticisi
Test	Hata listesi ve bildirimler	Test uzmanı
Uygulama	Düzeltilmiş sürüm ve kayıt	Yerelleştirmeci ve geliştirici

Türkiye bağlamı

Türkiye’de yerelleştirme projelerinin önemli bölümü ajans üzerinden ilerliyor ve LQA aşamaları çoğu zaman tek bir “redaksiyon” kalemine sıkışıyor. Planlama ve kayıt aşamaları görünmez olduğu için, aynı terim hatası farklı projelerde tekrar tekrar ortaya çıkabiliyor.

Stil kılavuzu eksikliği burada özel bir sorun. Türkçede hitap biçimi, tarih ve saat gösterimi, ondalık ayırıcı, birim yazımı ve marka adlarının ek alıp almayacağı gibi kararlar kılavuza yazılmazsa her çevirmen kendi tercihini uyguluyor. Sonuçta metin doğru ama tutarsız oluyor.

Kamu ihalelerinde ise şartnameler genellikle süreç değil, çıktı tanımlıyor. Bir kalite tasarımı belgesi istenmediği için testin kapsamı sağlayıcıya bırakılıyor. İhale şartnamesine tek bir maddeyle test yöntemi ve hata sınıflandırması eklemek, sonucun karşılaştırılabilirliğini belirgin biçimde artırıyor.

Bu sizin için ne anlama geliyor?

Yerelleştirme satın alıyorsanız, LQA sizin de sorumluluğunuzda olan bir süreç. Planlama aşamasının girdilerinin çoğu sizde bulunuyor: ürünün amacı, hedef kullanıcı, terim tercihleri ve arayüz kısıtları.

Sağlayıcınızdan hangi aşamaların dâhil olduğunu açıkça sorun. Test bir kalem olarak fiyatlandırılmıyorsa, muhtemelen yapılmıyordur. Hangi hizmet kapsamının hangi denetimi içerdiğini çeviri hizmetlerimiz sayfasında karşılaştırabilir, proje ayrıntılarını iletişim sayfamızdan paylaşabilirsiniz.

Son olarak hata kayıtlarını isteyin. Düzeltilmiş dosya tek başına bir çıktıdır; hata kaydı ise bir sonraki projenin maliyetini düşüren bir varlıktır. İki üç sürüm sonra bu kayıtlar, hangi içerik türünde hangi denetime yatırım yapmanız gerektiğini size kendisi söyler.

Sık sorulan sorular

LQA nedir, kısaca nasıl tanımlanır?

LQA, yerelleştirme kalite analizi ya da yerelleştirme kalite güvencesi anlamına gelir. Yerelleştirilmiş ürünün düzgün çalıştığını, kullanılabilir ve erişilebilir olduğunu, gözle görülür hata içermediğini doğrulamak için yürütülen tüm süreçleri kapsar.

QA ile QC arasındaki fark nedir?

QA, hataya hiç düşmemek için süreç öncesinde, sırasında ve sonrasında kurulan yordamlardır. QC ise bitmiş ürünü kontrol edip oluşmuş hataları müşteriye ulaşmadan yakalamayı hedefler. QC, QA’nın bir alt kümesi sayılır ve genellikle hata analizine dayalı ölçütlerle yapılır.

Test aşamasında bulunan her hata aynı şekilde mi işlenir?

Hayır. Dilsel nitelikteki hatalar çoğu zaman doğrudan düzeltilebilir. İşlevsel ya da görsel nitelikteki hatalar ise hata bildirim sistemine kaydedilir, çünkü çözümleri kod veya yerleşim değişikliği gerektirir. Oyun yerelleştirmesinde dilsel sorunlar da bildirime işlenir.

Küçük bir web sitesi projesinde bu dört aşama gerekli mi?

Aşamalar ölçeklenebilir. Küçük bir projede planlama tek sayfalık bir belgeye, hazırlık bir stil kılavuzu bağlantısına, test yayına almadan önceki bir gözden geçirmeye inebilir. Önemli olan aşamaların atlanması değil, boyutlarının işe uydurulmasıdır.

Kaynaklar

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, s. 61, 67-68.
• Dunne, K. J. (2011). Müşteri odaklı LQA süreci önerisi; aktaran Jiménez-Crespo 2024, s. 67.
• Mozilla Yerelleştirme Stil Kılavuzu, mozilla-l10n.github.io/styleguides/mozilla_general/
• Esselink, B. (2000). A Practical Guide to Localization. John Benjamins.