लाइव साइट को छुए बिना वेब डिज़ाइन टेस्ट एनवायरनमेंट कैसे बनाएं: स्टेजिंग, लोकल और होस्टिंग विकल्प

webmaster

웹디자인 테스트 환경 설정법 - Photorealistic web design testing workspace, Indian developer seated at a clean desk comparing a res...

वेब डिज़ाइन बदलावों को सुरक्षित तरीके से जाँचने के लिए लोकल, स्टेजिंग और अलग टेस्ट सर्वर का चुनाव समझें। सेटअप चरण, लागत देखने के बिंदु, टीम सहयोग और लाइव साइट पर गलती रोकने की चेकलिस्ट पाएं।

웹디자인 테스트 환경 설정법 관련 이미지 1

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

एक नज़र में

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

सुरक्षित परीक्षण के लिए पहले सही एनवायरनमेंट चुनें

तीन पंक्तियों में उत्तर: लोकल, स्टेजिंग और अलग टेस्ट सर्वर का उपयोग

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

लाइव साइट पर सीधे बदलाव करना कब जोखिमपूर्ण होता है

होमपेज लेआउट, नेविगेशन, फॉर्म, संपर्क विवरण, ट्रैकिंग या भुगतान से जुड़े हिस्सों में बदलाव लाइव साइट पर सीधे करना जोखिम बढ़ा सकता है। अधूरा डिज़ाइन आगंतुकों को दिख सकता है। कोई फॉर्म टूटने पर संभावित पूछताछ छूट सकती है। गलत ट्रैकिंग या गलत लिंक का पता केवल बाद में लग सकता है।

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

शुरू करने से पहले बैकअप, पहुँच अधिकार और टेस्ट डेटा की तैयारी

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

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

Advertisement

लोकल, स्टेजिंग और टेस्ट सर्वर की तुलना कैसे करें

सेटअप समय, लागत, गति और टीम सहयोग के आधार पर तुलना

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

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

छोटी बिज़नेस वेबसाइट के लिए कौन-सा विकल्प व्यावहारिक है

छोटी बिज़नेस वेबसाइट में यदि बदलाव कम होते हैं और एक ही व्यक्ति साइट संभालता है, तो लोकल टेस्टिंग या होस्टिंग की उपलब्ध स्टेजिंग सुविधा पर्याप्त हो सकती है। यदि मालिक, मार्केटिंग व्यक्ति और डिज़ाइनर सभी बदलाव देखते हैं, तो साझा स्टेजिंग साइट समीक्षा को स्पष्ट बना सकती है।

यह न मानें कि हर छोटी साइट के लिए अलग क्लाउड सर्वर जरूरी है। पहले यह देखें कि CMS, प्लगइन, कस्टम कोड और वर्तमान होस्टिंग व्यवस्था किस तरह का सेटअप संभाल सकती है। साइट जितनी सरल हो, प्रक्रिया भी उतनी ही सरल रखना अक्सर बेहतर रहता है।

कब प्रबंधित होस्टिंग या वेबसाइट मेंटेनेंस सेवा का मूल्य बनता है

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

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

Advertisement

टेस्ट वेबसाइट बनाने की व्यावहारिक प्रक्रिया

लाइव साइट की सुरक्षित कॉपी तैयार करना

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

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

टेस्ट URL, लॉगिन और पहुँच सीमाएँ तय करना

टेस्ट वेबसाइट के लिए अलग डोमेन या सबडोमेन उपयोग करने पर नाम ऐसा रखें जिससे टीम उसे लाइव साइट न समझे। अलग लॉगिन बनाएँ और हर व्यक्ति को आवश्यकतानुसार ही पहुँच दें। क्लाइंट को केवल समीक्षा करनी हो तो पूर्ण प्रशासनिक पहुँच देना जरूरी नहीं हो सकता।

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

डेटाबेस, मीडिया फाइल और कॉन्फ़िगरेशन की जाँच

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

यदि टेस्ट कॉपी में फॉर्म ईमेल, ऑटोमेशन या भुगतान से जुड़ी सुविधा मौजूद है, तो उसे अलग से समीक्षा करें। अनजाने में वास्तविक ग्राहकों को संदेश जाना या वास्तविक प्रक्रिया सक्रिय होना समस्या पैदा कर सकता है।

डिज़ाइन बदलाव को चरणों में प्रकाशित करने का कार्यप्रवाह

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

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

Advertisement

टेस्टिंग के दौरान होने वाली आम गलतियाँ और बचाव

टेस्ट साइट का खोज परिणामों में दिख जाना

अलग टेस्ट साइट को सार्वजनिक छोड़ देना पर्याप्त नहीं है। उसकी खोज इंजन इंडेक्सिंग और सार्वजनिक पहुँच की सेटिंग की समीक्षा करें। टेस्ट पेज खोज परिणामों में दिखने लगें तो उपयोगकर्ता गलत संस्करण पर पहुँच सकते हैं और ब्रांड अनुभव प्रभावित हो सकता है।

असली ग्राहक डेटा, भुगतान या ईमेल ऑटोमेशन का अनजाने में उपयोग

웹디자인 테스트 환경 설정법 관련 이미지 2

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

मोबाइल, अलग ब्राउज़र और फॉर्म सबमिशन को न जाँचना

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

टेस्ट और लाइव एनवायरनमेंट के बीच संस्करण अंतर बढ़ने देना

टेस्टिंग लंबी खिंचने पर लाइव साइट में भी अन्य अपडेट हो सकते हैं। तब टेस्ट कॉपी और लाइव साइट में अंतर बढ़ सकता है। बदलाव रिकॉर्ड रखें और प्रकाशन से पहले वर्तमान लाइव स्थिति से मिलान करें। इससे यह समझना आसान होता है कि कौन-सा बदलाव वास्तव में प्रकाशित होना है।

Advertisement

फ्रीलांसर, टीम और क्लाइंट वेबसाइट के लिए अलग रणनीति

एक व्यक्ति के पोर्टफोलियो या छोटी साइट का सरल सेटअप

एक व्यक्ति के पोर्टफोलियो या सीमित पेज वाली साइट के लिए प्रक्रिया हल्की रखें: बैकअप की उपलब्धता देखें, लोकल या स्टेजिंग कॉपी पर बदलाव करें, मोबाइल और फॉर्म जाँचें, फिर लाइव करें। हर बदलाव के लिए जटिल सर्वर संरचना जरूरी नहीं होती।

फिर भी लाइव साइट पर बिना जाँचे बदलाव न करना इस छोटे सेटअप का मूल नियम है।

कई संपादकों वाली बिज़नेस साइट में अनुमोदन प्रक्रिया

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

अनुमोदन प्रक्रिया लिखित रूप में रखने से “मैंने समझा था कि यह लाइव हो चुका है” जैसी उलझन कम हो सकती है। बदलाव रिकॉर्ड में तारीख, बदलाव का उद्देश्य और मंजूरी की स्थिति जोड़ना उपयोगी है।

एजेंसी या बाहरी डेवलपर को काम देते समय पहुँच और हैंडओवर चेकलिस्ट

एजेंसी, फ्रीलांसर या बाहरी डेवलपर को काम देते समय केवल डिज़ाइन फाइल साझा करना पर्याप्त नहीं है। यह स्पष्ट करें कि टेस्ट साइट कहाँ होगी, किसके पास लॉगिन रहेगा, बैकअप किसके नियंत्रण में होगा और काम पूरा होने पर हैंडओवर कैसे होगा।

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

Advertisement

चयन मानदंड और तुलना सारांश

निर्णय लेने से पहले इन बिंदुओं पर जाँच करें:

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

अपनी साइट के आकार, अपडेट की आवृत्ति और टीम पहुँच के अनुसार विकल्प मिलाएँ। होस्टिंग, प्रबंधित मेंटेनेंस या आउटसोर्स डेवलपर की विस्तृत सुविधाएँ और शर्तें संबंधित सेवा के आधिकारिक पेज पर जाँचें।

कम बजट में नियंत्रित टेस्टिंग के लिए चुनाव

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

तेज अपडेट और कम तकनीकी मेहनत के लिए चुनाव

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

सेवा, होस्टिंग या डेवलपर कोटेशन की तुलना करते समय पूछने वाले प्रश्न

पूछें: क्या स्टेजिंग शामिल है? क्या बैकअप और पुनर्स्थापना की प्रक्रिया बताई गई है? टेस्ट साइट की खोज दृश्यता और पहुँच कैसे नियंत्रित होगी? फॉर्म, ईमेल और ट्रैकिंग की जाँच कौन करेगा? काम पूरा होने पर लॉगिन, दस्तावेज़ और बदलाव रिकॉर्ड किसे मिलेंगे?

Advertisement

समापन

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

Advertisement

जानने योग्य उपयोगी बातें

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

Advertisement

महत्वपूर्ण बातें

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

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

Q1. क्या छोटी वेबसाइट के लिए अलग स्टेजिंग एनवायरनमेंट जरूरी है?

A1. हर छोटी वेबसाइट के लिए अलग स्टेजिंग एनवायरनमेंट अनिवार्य नहीं है। यदि बदलाव सीमित हैं, तो लोकल टेस्टिंग या उपलब्ध होस्टिंग स्टेजिंग सुविधा उपयोगी हो सकती है। फिर भी लाइव साइट पर सीधे अधूरे बदलाव करने से बचना बेहतर है।

Q2. लोकल टेस्टिंग और होस्टिंग की स्टेजिंग सुविधा में किसे चुनना बेहतर है?

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

Q3. क्या टेस्ट वेबसाइट को सार्वजनिक रखने से सुरक्षा या SEO की समस्या हो सकती है?

A3. सार्वजनिक टेस्ट साइट को खोज इंजन या सामान्य आगंतुक देख सकते हैं, जिससे भ्रम या अनचाही दृश्यता की स्थिति बन सकती है। इसलिए इंडेक्सिंग, सार्वजनिक पहुँच, लॉगिन और साझा लिंक की सेटिंग की अलग समीक्षा करें। फॉर्म ईमेल और अन्य ऑटोमेशन भी टेस्ट साइट पर अनजाने में सक्रिय न हों, यह जाँचना जरूरी है।