लॉन्च से पहले अपने ऐप की टेस्टिंग कैसे करें: व्यावहारिक प्री-लॉन्च योजना

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

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

चरण 1: वे यात्राएं लिखें जो मायने रखती हैं

यात्रा (journey) वह शुरू से अंत तक का काम है जो यूज़र करने आता है। ज़्यादातर ऐप में तीन से छह ऐसी यात्राएं होती हैं जो सच में मायने रखती हैं। बुकिंग ऐप के लिए:

1. साइन अप करें और खाता कन्फ़र्म करें
2. एक क्लास खोजें और बुक करें
3. बुकिंग रद्द करें
4. क्लास पास के लिए पेमेंट करें
5. स्टाफ़: आज की बुकिंग देखें

अगर आपने यूज़र स्टोरीज़ लिखी हैं, तो उनकी स्वीकृति शर्तें आपके टेस्ट केस पहले से हैं। नहीं लिखी, तो हर यात्रा के लिए एक पंक्ति लिखें कि “सफल” होने का मतलब क्या है।

उन्हें प्राथमिकता दें। जो यात्राएं पैसा बनाती हैं या जिन्हें हर यूज़र छूता है (साइन अप, लॉगिन, मुख्य क्रिया), उन्हें सबसे पहले और सबसे ज़्यादा टेस्ट करें।

चरण 2: नए यूज़र के रूप में सामान्य रास्ता टेस्ट करें

“हैप्पी पाथ” वह यात्रा है जो ठीक वैसे चलती है जैसा इरादा था। इसे वैसे टेस्ट करें जैसे कोई अनजान व्यक्ति अनुभव करेगा:

• प्राइवेट ब्राउज़र विंडो इस्तेमाल करें, ताकि आप लॉगिन न हों और कोई सेव डेटा न हो।
• एक ताज़ा खाता इस्तेमाल करें, एक असली ईमेल के साथ जिसे आप चेक कर सकें।
• होम पेज या किसी लिंक से शुरू करें, किसी ऐसे पेज से नहीं जिसे आपने बनाते समय बुकमार्क किया था।

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

चरण 3: इसे तोड़ने की कोशिश करें

अब हर यात्रा दोहराएं और जानबूझकर गलत काम करें।

रिफ़्रेश पर खास ध्यान दें: अगर ऐप क्लिक करके चलता है पर किसी गहरे पेज पर रिफ़्रेश करने से 404 दिखता है, तो डिप्लॉय के बाद 404 एरर कैसे ठीक करें देखें।

चरण 4: दो खातों से अनुमतियां टेस्ट करें

खातों वाले किसी भी ऐप के लिए यह सबसे ज़रूरी टेस्ट है, और अक्सर छूट जाता है।

दो सामान्य यूज़र, A और B, बनाएं, और (अगर आपके ऐप में हैं) एक एडमिन।

• A के रूप में एक रिकॉर्ड बनाएं। B के रूप में लॉग इन करें। क्या B उसे देख, बदल या मिटा सकता है? नहीं सकना चाहिए, जब तक डिज़ाइन में यह न हो।
• A के रिकॉर्ड का URL कॉपी करें। B के रूप में लॉग इन करके वह URL सीधे खोलें।
• सामान्य यूज़र के रूप में टाइप करके एडमिन पेज खोलने की कोशिश करें।
• पूरी तरह लॉग आउट करें और वही URL आज़माएं।

अगर यहां कोई समस्या मिले, तो लॉन्च तब तक न करें जब तक वह ठीक न हो। जांच सर्वर पर होनी चाहिए, सिर्फ़ बटन छिपाकर नहीं। AI से बने ऐप के लिए सुरक्षा चेकलिस्ट इसमें और गहराई से जाती है।

चरण 5: असली डिवाइस पर टेस्ट करें

ऐप को सिर्फ़ संकरी ब्राउज़र विंडो में नहीं, असली फ़ोन पर खोलें।

• क्या आप हर बटन ज़ूम किए बिना टैप कर सकते हैं?
• क्या कीबोर्ड उस फ़ील्ड को ढक देता है जिसमें आप टाइप कर रहे हैं?
• क्या टेबल और चौड़ा कंटेंट स्क्रॉल होता है या लपेटा जाता है, बजाय पेज को बगल में धकेलने के?
• क्या टेक्स्ट बिना ज़ूम के पढ़ा जा सकता है?

कम से कम एक iPhone (Safari) और एक Android फ़ोन (Chrome) पर टेस्ट करने की कोशिश करें, अगर मिल सके। Safari में तारीखों, वीडियो और फ़िक्स्ड-पोज़िशन एलिमेंट्स की अपनी अलग समस्याएं होती हैं।

चरण 6: पैसे और ईमेल को शुरू से अंत तक टेस्ट करें

कार्ड चार्ज करने या ईमेल भेजने वाली हर चीज़ को पूरी तरह से चलाकर देखना होगा।

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

ईमेल। दो-तीन अलग-अलग प्रदाताओं के असली पतों से साइन अप करें। जांचें कि ईमेल पहुंचते हैं, स्पैम में नहीं जाते, और उनके हर लिंक लाइव डोमेन की ओर इशारा करते हैं, प्रीव्यू पते की ओर नहीं।

चरण 7: स्पीड और एरर जांचें

• ब्राउज़र के डेवलपर टूल (राइट-क्लिक → Inspect) खोलें और हर मुख्य पेज पर Console टैब देखें। लाल एरर ठीक करने लायक हैं, भले ही कुछ टूटा न दिखे।
• वाई-फ़ाई के बजाय मोबाइल डेटा पर फ़ोन से साइट लोड करें। अगर पहली स्क्रीन कई सेकंड लेती है, तो सबसे पहले तस्वीरों का आकार देखें।
• Chrome के डेव टूल में Lighthouse जैसा मुफ़्त ऑडिट चलाएं, परफ़ॉर्मेंस और एक्सेसिबिलिटी का त्वरित अंदाज़ा पाने के लिए।

चरण 8: प्रीव्यू नहीं, पब्लिश्ड ऐप टेस्ट करें

प्रीव्यू और पब्लिश्ड ऐप एक ही माहौल नहीं हैं। किसी को लॉन्च के बारे में बताने से पहले लाइव URL पर मुख्य यात्राएं दोहराएं:

• क्या पब्लिश्ड ऐप के लिए सभी एनवायरनमेंट वेरिएबल और सीक्रेट सेट हैं?
• क्या सही डेटाबेस इस्तेमाल हो रहा है, जिसमें वह डेटा है जिसकी आपको उम्मीद है?
• क्या लॉगिन रीडायरेक्ट और ईमेल लिंक लाइव डोमेन इस्तेमाल करते हैं?
• क्या किसी गहरे पेज पर रिफ़्रेश सही ढंग से लोड होता है?

चरण 9: किसी और को इसे इस्तेमाल करते हुए देखें

एक या दो लोगों को एक लक्ष्य दें (“शनिवार के लिए एक योग क्लास बुक करो”), निर्देश नहीं। देखें, मदद न करें, और लिखें कि वे कहां रुकते हैं। यह भ्रमित करने वाले शब्द और छिपे हुए बटन ढूंढने का सबसे तेज़ तरीका है। इसका बड़ा रूप देखने के लिए बीटा टेस्ट कैसे चलाएं पढ़ें।

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

टेस्ट के लिए AI का इस्तेमाल

अगर आप AI से बना रहे हैं, तो वह टेस्ट की योजना बनाने और चलाने में मदद कर सकता है:

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

दो अलग टेस्ट यूज़र से लॉग इन करो और जांचो कि क्या यूज़र B, यूज़र A के बनाए किसी भी चीज़ को देख या बदल सकता है, A के रिकॉर्ड के URL सीधे खोलकर भी। कुछ ठीक करने से पहले जो मिले उसकी रिपोर्ट दो।

AI की अपनी टेस्ट रिपोर्ट को पहला ड्राफ्ट मानें। पैसे और अनुमति वाली यात्राएं खुद क्लिक करके जांचें।

Mythex में टेस्टिंग

Mythex में /test कमांड App Testing चलाता है: एजेंट लाइव प्रीव्यू के खिलाफ एक ब्राउज़र चलाता है, पेजों पर क्लिक करता है, स्क्रीनशॉट लेता है और टूटे फ़्लो की रिपोर्ट चैट में देता है। यह किसी खास यात्रा के साथ सबसे अच्छा काम करता है, जैसे “साइन अप और एक क्लास बुक करना टेस्ट करो”। जो मिले उसे /fix या सामान्य संदेश से ठीक करें, फिर /test दोबारा चलाएं। App Testing प्रीव्यू का इस्तेमाल करता है, इसलिए पब्लिश करने के बाद लाइव URL पर मुख्य यात्राएं खुद जांचें। देखें डॉक्स में App Testing, और जब कुछ फेल हो तो AI से बने ऐप को डीबग कैसे करें पढ़ें।

आम गलतियां

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

प्री-लॉन्च चेकलिस्ट

• मुख्य यात्राएं लिखी और प्राथमिकता दी गईं
• हर यात्रा प्राइवेट विंडो में बिल्कुल नए यूज़र के रूप में पास होती है
• खाली, गलत, लंबे और डुप्लीकेट इनपुट संभाले गए
• हर पेज पर रिफ़्रेश काम करता है
• यूज़र एक-दूसरे का डेटा नहीं देख या बदल सकते, URL से भी नहीं
• सामान्य यूज़र और लॉग आउट विज़िटर के लिए एडमिन पेज बंद हैं
• असली iPhone और Android फ़ोन पर काम करता है
• पेमेंट टेस्ट हुए: सफल, अस्वीकृत, रद्द, और भुगतान के बाद ऐप अपडेट होता है
• ईमेल पहुंचते हैं, स्पैम से बचते हैं, और लाइव डोमेन से लिंक होते हैं
• मुख्य पेजों पर कंसोल में कोई लाल एरर नहीं
• पब्लिश्ड URL पर मुख्य यात्राएं दोहराई गईं
• कम से कम एक बाहर के व्यक्ति ने आपके सामने इसे आज़माया

सवाल