स्थानीयकरण परीक्षण क्या है? उदाहरण परीक्षण मामले और चेकलिस्ट

⚡ स्मार्ट सारांश

स्थानीयकरण परीक्षण यह जांचता है कि सॉफ़्टवेयर किसी विशिष्ट क्षेत्र, स्थान या संस्कृति के लिए सही ढंग से व्यवहार करता है या नहीं, जिसमें अनुवादित सामग्री, उपयोगकर्ता इंटरफ़ेस लेआउट, मुद्रा, दिनांक और समय प्रारूप और उस बाजार में उपयोगकर्ता द्वारा अपेक्षित स्थानीय परंपराएं शामिल हैं।

  • 🌐 संक्षिप्त रूप: इस तकनीक को L10N लिखा जाता है, क्योंकि स्थानीयकरण में L और N के बीच दस अक्षर होते हैं।
  • 🎯 मुख्य लक्ष्य: सामग्री और उपयोगकर्ता इंटरफ़ेस परीक्षक द्वारा दर्ज की जाने वाली लगभग हर स्थानीयकरण संबंधी त्रुटि को अवशोषित कर लेते हैं।
  • 🧭 चार चरण: बिल्ड वेरिफिकेशन, फंक्शनल टेस्टिंग, रिग्रेशन टेस्टिंग और फाइनल साइन-ऑफ एक सामान्य चक्र का हिस्सा हैं।
  • 📐 लेआउट जोखिम: अनुवादित स्ट्रिंग्स का विस्तार होता है, और डबल-बाइट और दाएं से बाएं लिखी जाने वाली लिपियां उन लेआउट को तोड़ देती हैं जिन्हें अंग्रेजी ने कभी उजागर नहीं किया था।
  • 🤖 स्वचालन: स्क्रिप्टेड सुइट्स एक ही तरह के परिदृश्यों को कई स्थानों पर चलाने पर जल्दी ही अपना खर्च निकाल लेते हैं।
  • 🔀 यह I18N के समान नहीं है: अंतर्राष्ट्रीयकरण कोड तैयार करता है; स्थानीयकरण एक पूर्ण बाजार को सत्यापित करता है।

किसी लक्षित स्थान के लिए भाषा, मुद्रा और दिनांक प्रारूपों का स्थानीयकरण परीक्षण

स्थानीयकरण परीक्षण

स्थानीयकरण परीक्षण एक सॉफ्टवेयर परीक्षण तकनीक है जिसमें किसी सॉफ्टवेयर के व्यवहार को किसी विशिष्ट क्षेत्र, लोकेल या संस्कृति के लिए परखा जाता है। किसी सॉफ्टवेयर के लिए स्थानीयकरण परीक्षण करने का उद्देश्य किसी विशेष लोकेल के लिए उपयुक्त भाषाई और सांस्कृतिक पहलुओं का परीक्षण करना है। यह लक्षित भाषा और देश के अनुसार सॉफ्टवेयर को अनुकूलित करने की प्रक्रिया है।

स्थानीयकरण परीक्षण से प्रभावित होने वाले प्रमुख क्षेत्र में विषय-वस्तु और यूआई शामिल हैं।

यह एक वैश्विक अनुप्रयोग के परीक्षण की प्रक्रिया है जिसका UI, डिफ़ॉल्ट भाषा, मुद्रा, दिनांक, समय प्रारूप और दस्तावेज़ीकरण लक्षित देश या क्षेत्र के अनुसार डिज़ाइन किया गया है। यह सुनिश्चित करता है कि अनुप्रयोग उस विशेष देश में उपयोग के लिए पर्याप्त रूप से सक्षम है।

उदाहरण:

1. यदि परियोजना भारत के तमिलनाडु राज्य के लिए डिज़ाइन की गई है, तो डिज़ाइन की गई परियोजना तमिल भाषा में होनी चाहिए, तमिल वर्चुअल कीबोर्ड मौजूद होना चाहिए, आदि।

2. यदि परियोजना अमेरिका के लिए डिज़ाइन की गई है, तो समय प्रारूप को यूएसए मानक समय के अनुसार बदला जाना चाहिए। साथ ही, भाषा और मुद्रा प्रारूप को यूएसए मानकों का पालन करना चाहिए।

नीचे दिया गया चित्र एक ही उत्पाद को विभिन्न स्थानों के लिए अनुकूलित होते हुए दिखाता है, जिसमें भाषा, मुद्रा और स्वरूपण नियम बदलते हैं जबकि मूल संरचना समान रहती है।

स्थानीयकरण परीक्षण में एक उत्पाद बिल्ड को कई लक्षित स्थानों के लिए अनुकूलित करना शामिल है।

स्थानीयकरण परीक्षण क्यों करें?

स्थानीयकरण परीक्षण का उद्देश्य किसी विशेष स्थान के लिए उपयुक्त भाषाई और सांस्कृतिक पहलुओं की जाँच करना है। इसमें उपयोगकर्ता इंटरफ़ेस या आवश्यकताओं के अनुसार प्रारंभिक सेटिंग्स में बदलाव करना शामिल है।

इस प्रकार के परीक्षण में, कई अलग-अलग परीक्षक एक ही कार्य को दोहराएंगे। वे टाइपोग्राफिकल त्रुटियों, UI की सांस्कृतिक उपयुक्तता, भाषाई त्रुटियों आदि जैसी विभिन्न चीजों को सत्यापित करते हैं।

इसे "L10N" भी कहा जाता है क्योंकि लोकलाइज़ेशन शब्द में L और N के बीच 10 अक्षर होते हैं।

इस प्रयास के पीछे एक व्यावसायिक कारण भी है। गलत अनुवादित लेबल या 03/04 की तारीख को अप्रैल के बजाय मार्च बताने से उस बाजार में विश्वास कम हो जाता है जिसमें प्रवेश करने के लिए टीम पहले ही भुगतान कर चुकी है, और ये खामियां लक्षित क्षेत्र के परीक्षक द्वारा खोजी जाती हैं, न कि किसी अन्य कंपनी द्वारा। जीयूआई परीक्षण अंग्रेजी में प्रस्तुत किया गया।

स्थानीयकरण परीक्षण बनाम अंतर्राष्ट्रीयकरण परीक्षण

ये दोनों गतिविधियाँ एक-दूसरे के विपरीत नहीं बल्कि क्रमिक रूप से होती हैं। अंतर्राष्ट्रीयकरण परीक्षण (I18N) यह पुष्टि करता है कि कोड बेस किसी भी लोकेल को स्वीकार कर सकता है; स्थानीयकरण परीक्षण (L10N) फिर यह पुष्टि करता है कि एक विशिष्ट लोकेल सही है।

स्थानीयकरण परीक्षण (L10N) अंतर्राष्ट्रीयकरण परीक्षण (I18N)
यह सत्यापित करता है कि उत्पाद एक लक्षित क्षेत्र में सहज रूप से काम करता है। यह सत्यापित करता है कि उत्पाद को पुनः विकसित किए बिना कई क्षेत्रों में समर्थन मिल सकता है।
अनुवादित पाठ, मुद्रा, तिथि, समय और सांस्कृतिक अनुकूलता की जाँच करता है यह कैरेक्टर एन्कोडिंग, स्ट्रिंग एक्सटर्नलाइज़ेशन और लोकेल-अवेयर कोड की जाँच करता है।
यह प्रक्रिया तब चलती है जब उस बाज़ार के लिए अनुवादित बिल्ड उपलब्ध हो जाता है। यह प्रक्रिया सबसे पहले चलती है, अनुवाद के लिए कोई भी पाठ भेजने से पहले।
स्थानीय भाषा जानने वाले परीक्षक या समीक्षक की आवश्यकता है। इसे कोर टीम द्वारा छद्म-अनुवादित बिल्ड का उपयोग करके निष्पादित किया जा सकता है।

इस ट्यूटोरियल को देखें स्थानीयकरण और वैश्वीकरण परीक्षण के बीच अंतर.

स्थानीयकरण परीक्षण कैसे करें

एक विशिष्ट स्थानीयकरण परीक्षण के लिए, हमने बिल्ड सत्यापन परीक्षण की स्थापना की, क्रियात्मक परीक्षण, प्रतिगमन परीक्षण, और अंतिम हस्ताक्षर।

1. बिल्ड सत्यापन परीक्षण का एक छोटा सा उपसमूह है क्रियात्मक परीक्षणयह प्रक्रिया QA द्वारा किसी भी विस्तृत परीक्षण शुरू करने से पहले की जाती है। यह मूल रूप से इसके समान है। धुआँ परीक्षणयदि भाषा पैक लोड करने में पूरी तरह विफल हो जाता है, तो स्थानीयकृत बिल्ड को तुरंत अस्वीकार कर दिया जाता है।

2. सामान्य परीक्षण, सामान्य परीक्षण मामलों को चलाने और निष्पादन के दौरान लॉग दोषों को खोजने का चरण है।

3. प्रतिगमन परीक्षण है दोष प्रतिगमन प्रक्रिया यह सुनिश्चित करती है कि दोष ठीक हो जाए, जबकि आसपास के क्षेत्रों पर ठीक किए गए दोषों का कोई प्रभाव न पड़े।

4. अंतिम साइन-ऑफ का अर्थ है ग्राहक को डिलीवरी से पहले बिल्ड पर अंतिम जांच करना।

प्रत्येक चरण को उत्पाद के लिए एक बार नहीं, बल्कि प्रत्येक स्थान के लिए दोहराया जाता है। फ़्रेंच बिल्ड में ठीक की गई किसी भी त्रुटि को जर्मन और जापानी बिल्ड में भी ठीक करना पड़ता है, क्योंकि अक्सर दोनों बिल्ड में एक ही स्ट्रिंग संसाधन साझा किया जाता है।

स्थानीयकरण परीक्षण में स्वचालन

यदि परियोजना बड़ी है और उसे बार-बार परीक्षण की आवश्यकता है, तो हम इसका विकल्प चुनते हैं स्वचालन परीक्षण.

  • स्क्रिप्ट लिखने के लिए स्वचालन उपकरण चुनें.
  • स्थानीयकरण रणनीति के लिए परीक्षण हेतु परिदृश्य लीजिए।
  • उसके अनुसार स्क्रिप्ट लिखें.
  • परिणाम एकत्रित करें और परिदृश्य को पास/फेल के रूप में अपडेट करें।

नोट: Selenium इस क्षेत्र में अग्रणी उपकरणों में से एक है। यह बहुत ही सुविधा संपन्न है, हालांकि, इसका उपयोग करने के लिए अधिक तकनीकी ज्ञान की आवश्यकता होती है।

स्वचालन की एक सीमा है जिसे स्पष्ट रूप से बताना आवश्यक है। एक स्क्रिप्ट यह साबित कर सकती है कि मुद्रा चिह्न बदल गया है और कोई स्ट्रिंग अधूरी नहीं है, लेकिन यह निर्णय नहीं कर सकती कि अनुवाद स्वाभाविक है या कोई चिह्न आपत्तिजनक है। मशीनी जाँच यांत्रिक स्तर को संभालती है; जबकि मूल भाषा का समीक्षक भाषाई स्तर को संभालता है।

स्थानीयकरण परीक्षण उपकरण

स्थानीयकरण के काम में तीन अलग-अलग प्रकार के उपकरणों का उपयोग होता है, और अधिकांश टीमें अंततः तीनों का उपयोग करती हैं।

  • कार्यात्मक स्वचालन ढाँचे: Selenium, Appium और तुलनीय फ्रेमवर्क प्रत्येक लोकेल बिल्ड के विरुद्ध उसी सूट को दोबारा चलाते हैं, जहाँ अधिकांश दोहरावदार सत्यापन होता है।
  • अनुवाद प्रबंधन प्रणालियाँ: स्ट्रिंग संसाधनों को रखने वाले प्लेटफ़ॉर्म अनुवादकों, डेवलपर्स और परीक्षकों को एक ही शब्दावली से काम करने की सुविधा देते हैं, ताकि एक ही शब्द का अनुवाद दो अलग-अलग स्क्रीन पर दो अलग-अलग तरीकों से न हो।
  • छद्म-स्थानीकरण उपयोगिताएँ: ये वास्तविक अनुवाद शुरू होने से पहले अंग्रेजी वाक्यों को उच्चारणयुक्त, लंबे प्लेसहोल्डर्स से बदल देते हैं, जिससे हार्ड-कोडेड टेक्स्ट और लेआउट सामने आ जाते हैं जो लंबे शब्दों को अवशोषित नहीं कर सकते।

डिवाइस और ब्राउज़र कवरेज उतना ही महत्वपूर्ण है जितना कि टूल। फ़ॉन्ट, इनपुट विधियाँ और डिफ़ॉल्ट लोकेल विभिन्न प्लेटफ़ॉर्म पर भिन्न होते हैं, इसलिए स्थानीयकृत बिल्ड को वास्तविक लक्षित डिवाइसों पर परीक्षण के दौरान जांचना आवश्यक है। मोबाइल परीक्षण और ब्राउज़र में परिभाषित सेट के लिए वेब एप्लिकेशन परीक्षण.

स्थानीयकरण परीक्षण के लिए सर्वोत्तम अभ्यासों की चेकलिस्ट

  • आई18एन इंजीनियरिंग में विशेषज्ञता रखने वाली लोकलाइज़ेशन फर्म को नियुक्त करें।
  • सुनिश्चित करें कि आपकी स्थानीयकरण परीक्षण रणनीति डबल-बाइट भाषाओं के लिए अधिक समय उपलब्ध कराती है।
  • यह सुनिश्चित करें कि आपने DBCS के लिए अपने कोड का उचित अंतर्राष्ट्रीयकरण कर लिया है।tracअनुवाद के लिए भेजने हेतु कोई भी पाठ।
  • सबसे पहले प्रत्येक स्ट्रिंग को संसाधन फ़ाइलों में अलग कर दें, ताकि उपयोगकर्ता को दिखाई देने वाला कोई भी टेक्स्ट स्रोत में हार्ड-कोडेड न रहे।
  • शुरुआत में ही छद्म-स्थानीयकृत बिल्ड चलाएं, क्योंकि इससे अनुवाद पर पैसा खर्च होने से पहले ही टेक्स्ट में मौजूद कमियों और हार्ड-कोडेड टेक्स्ट का पता चल जाता है।
  • पाठ के विस्तार के लिए लेआउट में जगह आरक्षित रखें, क्योंकि अंग्रेजी से अनुवाद अक्सर मूल लेबल से लंबे होते हैं।
  • अरबी और हिब्रू जैसी दाएं से बाएं लिखी जाने वाली भाषाओं का परीक्षण वास्तविक स्क्रीन पर करें, जहां मिरर लेआउट और मिश्रित दिशा वाले टेक्स्ट अक्सर विफल हो जाते हैं।
  • प्रत्येक स्थान के लिए एक शैली मार्गदर्शिका बनाए रखें जिसमें तिथि क्रम, दशमलव विभाजक, संबोधन प्रारूप, सम्मानसूचक शब्द और लहजा शामिल हो।
  • किसी ऐसे व्यक्ति से तैयार स्क्रीनशॉट की समीक्षा करवाएं जो मूल भाषा बोलता हो, क्योंकि स्क्रिप्ट के आधार पर सांस्कृतिक अनुकूलता का दावा नहीं किया जा सकता है।

इनमें से दो आइटम भाषा के बजाय प्लेटफ़ॉर्म पर निर्भर करते हैं, यही कारण है कि स्थानीयकृत बिल्ड आमतौर पर साथ में ही शेड्यूल किए जाते हैं। संगतता परीक्षण और कॉन्फ़िगरेशन परीक्षण उनके बाद नहीं बल्कि उनके बाद।

स्थानीयकरण परीक्षण के लिए उदाहरण परीक्षण मामले

नीचे दी गई तालिका में जाँचों का एक प्रारंभिक सेट दिया गया है। प्रत्येक पंक्ति एक पूर्ण सेट बन जाती है। परीक्षण का मामला एक बार जब विशिष्ट स्थान के लिए अपेक्षित परिणाम भर दिया जाता है।

S.No परीक्षण का मामला Descriptआयन
1 संदर्भ एवं जांच के लिए शब्दावलियां उपलब्ध हैं।
2 लक्ष्य क्षेत्र के लिए समय और दिनांक उचित रूप से स्वरूपित है।
3 फ़ोन नंबर प्रारूप लक्ष्य क्षेत्र के लिए उपयुक्त हैं.
4 लक्ष्य क्षेत्र के लिए मुद्रा.
5 क्या वर्तमान वेबसाइट (क्षेत्र) लाइसेंस और नियमों का पालन कर रही है।
6 पृष्ठों में पाठ सामग्री लेआउट त्रुटि-रहित, फ़ॉन्ट स्वतंत्रता और पंक्ति संरेखण है।
7 विशेष वर्ण, हाइपरलिंक और हॉटकी कार्यक्षमता।
8 इनपुट फ़ील्ड के लिए सत्यापन संदेश.
9 उत्पन्न बिल्ड में सभी आवश्यक फ़ाइलें शामिल हैं।
10 स्थानीयकृत स्क्रीन में स्रोत उत्पाद के समान ही तत्व और संख्याएं होती हैं।
11 सुनिश्चित करें कि सॉफ्टवेयर या वेब अनुप्रयोगों का स्थानीयकृत उपयोगकर्ता इंटरफ़ेस लक्ष्य ऑपरेटिंग सिस्टम और उपयोगकर्ता वातावरण में स्रोत उपयोगकर्ता इंटरफ़ेस से मेल खाता है।
12 क्रम निर्धारण और वर्णानुक्रमिक क्रम लक्ष्य भाषा के नियमों का पालन करते हैं, न कि स्रोत भाषा के।
13 दाएँ से बाएँ की ओर जाने वाले लोकेशंस नेविगेशन, आइकन और मिश्रित-दिशा स्ट्रिंग्स सहित लेआउट को सही ढंग से प्रतिबिंबित करते हैं।
14 कीबोर्ड इनपुट, स्पेल चेक और सर्च में उच्चारण वाले और मल्टी-बाइट कैरेक्टर स्वीकार किए जाते हैं।

स्थानीयकरण परीक्षण के लाभ

स्थानीयकरण परीक्षण के लाभ निम्नलिखित हैं

  • समग्र परीक्षण लागत में कमी
  • समग्र समर्थन लागत में कमी
  • परीक्षण के समय को कम करने में मदद करता है।
  • इसमें अधिक लचीलापन और मापनीयता है।

ये बचत स्थानीय खामियों को बाज़ार समर्थन कतार के अनुसार एक बार पकड़ने के बजाय, एक ही बार में केंद्रीय रूप से पकड़ने से होती है। इसके परिणामस्वरूप अक्सर पहुंच में भी सुधार होता है, क्योंकि वही अनुशासन जो लंबे जर्मन वाक्यों के तहत लेआउट को बरकरार रखता है, वही लेआउट को बड़े किए गए टेक्स्ट के तहत भी बरकरार रखता है। पहुँच क्षमता परीक्षण.

स्थानीयकरण परीक्षण के नुकसान

स्थानीयकरण परीक्षण की चुनौतियाँ निम्नलिखित हैं

  • डोमेन विशेषज्ञ की आवश्यकता है
  • स्थानीय अनुवादक को नियुक्त करने से अक्सर प्रक्रिया महंगी हो जाती है
  • विभिन्न देशों में DBCS वर्णों का भंडारण भिन्न होता है
  • परीक्षक को शेड्यूल संबंधी चुनौतियों का सामना करना पड़ सकता है

समय-सीमा का दबाव वह पहलू है जिसे अधिकांश टीमें कम आंकती हैं। अनुवाद प्रक्रिया में स्वाभाविक रूप से देर से आता है, इसलिए स्थानीयकरण संबंधी दोष रिलीज़ के ठीक पहले सामने आते हैं, और यही वह समय होता है जब लेआउट में बदलाव सबसे महंगा पड़ता है। स्थानीयकरण की योजना बनाना व्यापक योजना का हिस्सा है जिसका वर्णन इसमें किया गया है। सॉफ्टवेयर परीक्षण के प्रकार उस दबाव को नियंत्रण में रखता है, और सामान्य तौर पर सॉफ्टवेयर परिक्षण परिचय में यह बताया गया है कि यह चरण समग्र रूप से कहाँ स्थित है।

अक्सर पूछे जाने वाले प्रश्न

डिवाइस को अरबी या हिब्रू भाषा में बदलकर देखें और सुनिश्चित करें कि पूरा लेआउट (नेविगेशन, आइकन, प्रगति संकेतक और स्क्रॉल दिशा) सही है। जहां लैटिन उत्पाद का नाम अरबी पाठ के अंदर होता है, वहां अक्सर समस्या आती है।

अनुवादित पाठ अक्सर अंग्रेज़ी मूल पाठ से लंबा होता है, इसलिए बटन, मेनू और टेबल हेडर या तो ओवरफ्लो हो जाते हैं या कट जाते हैं। डिज़ाइन में अतिरिक्त चौड़ाई आरक्षित करके और फिर उसे सबसे लंबी लक्षित भाषा पर सत्यापित करने से इनमें से अधिकांश दोषों को दूर किया जा सकता है।

यह अनुवाद योग्य प्रत्येक वाक्य को उच्चारणयुक्त, जानबूझकर लंबे किए गए संस्करण से बदल देता है। सादे अंग्रेज़ी में दिखाई देने वाला कोई भी पाठ हार्ड-कोडेड होता है, और कोई भी छोटा किया गया लेबल यह दर्शाता है कि लेआउट विस्तार को समायोजित नहीं कर सकता। ये दोनों चीजें अनुवाद खरीदने से पहले ही पता चल जाती हैं।

एक QA इंजीनियर कार्यात्मक और लेआउट जांच करता है, और लक्ष्य भाषा का मूल वक्ता शब्दों, लहजे और सांस्कृतिक अनुकूलता की समीक्षा करता है। इस तरह से काम करने से भाषाविज्ञानी को बार-बार यांत्रिक त्रुटि जांच करने के लिए भुगतान करने की आवश्यकता नहीं रहती।

हार्ड-कोडेड अंग्रेजी स्ट्रिंग्स, अधूरे लेबल, अस्पष्ट तिथि क्रम, गलत दशमलव और हजार विभाजक, टूटे हुए उच्चारण वाले अक्षर, और जुड़े हुए वाक्य जो निरर्थक अनुवाद देते हैं क्योंकि टुकड़ों को कोड में इकट्ठा किया गया था।

स्ट्रिंग्स के एक्सटर्नलाइज़ होते ही स्यूडो-लोकलाइज़्ड चेक शुरू हो जाते हैं, अनुवाद से काफी पहले। पूर्ण लोकेल पास तब शुरू होते हैं जब पहला अनुवादित बिल्ड उपलब्ध होता है, और रिलीज़ से पहले एक पास की प्रतीक्षा करने के बजाय प्रत्येक स्प्रिंट में दोहराए जाते हैं।

मशीन लर्निंग स्थानीयकृत स्क्रीनशॉट की तुलना मूल लेआउट से करके कटी-फटी और ओवरलैप की पहचान करती है, शब्दावली में विचलन के लिए अनुवादों को स्कोर करती है, और उन स्थानों को रैंक करती है जिनमें सबसे अधिक जोखिम होता है। अंतिम सांस्कृतिक निर्णय अभी भी एक मूल भाषा के समीक्षक द्वारा ही लिया जाता है।

हाँ। यह लोकेल-पैरामीटराइज्ड ड्राफ्ट तैयार करता है। Selenium स्केफोल्डिंग, रिसोर्स-फाइल अभिकथन और लोकेल कोड पर आधारित डेटा-संचालित लूप। प्रत्येक लोकेल के लिए अपेक्षित मान अभी भी स्टाइल गाइड से आने चाहिए, न कि मॉडल से।

इस पोस्ट को संक्षेप में इस प्रकार लिखें: