नॉन-टेक्निकल टीम्स के लिए 30 मिनट का प्री-लॉन्च टेस्ट प्लान

क्यों एक छोटा प्री-लॉन्च टेस्ट बाद में दर्द बचाता है

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

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

एक छोटा प्री-लॉन्च टेस्ट प्लान उन्हीं पलों पर लक्षित होता है। 30 मिनट में आप यह साबित नहीं कर रहे कि पूरा सिस्टम परिपूर्ण है। आप उन समस्याओं को पकड़ रहे हैं जो पहले दिन सपोर्ट टिकट, रिफंड और चर्न पैदा करती हैं।

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

इस टेस्ट को चलाने के लिए सबसे अच्छा व्यक्ति बिल्ड टीम के बाहर होना चाहिए: ऑपरेशन्स, सपोर्ट, या PM। अगर आप AppMaster जैसे नो-कोड टूल में बना रहे हैं, तो गैर-टेक्निकल स्टाफ के लिए ग्राहक की तरह फ्लो फॉलो करना और भी आसान होता है। हर रिलीज़ से पहले चलाएँ, यहाँ तक कि छोटे-छोटे बदलावों पर भी, क्योंकि छोटे बदलाव बड़े मोमेंट्स को तोड़ देते हैं।

सेटअप: अकाउंट्स, टेस्ट डेटा, डिवाइस और कड़ा टाइमबॉक्स

एक 30-मिनट का टेस्ट तभी काम करता है जब आप पहले बुनियादी तैयारियाँ कर लें। लक्ष्य चौड़ाई नहीं, फोकस है।

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

टाइमर शुरू करने से पहले ये तैयार रखें:

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

इसे टाइमबॉक्स करें ताकि यह “बस एक और चीज़” में न बदल जाए। एक सरल विभाजन जो काम आता है:

• 5 मिनट: जर्नीज़, अकाउंट्स और डिवाइस कन्फर्म करें
• 20 मिनट: बिना रुकावट के वॉकथ्रू चलाएँ
• 5 मिनट: मुद्दों को लिखें और तय करें क्या लॉन्च को ब्लॉक करता है

अगर आप AppMaster का उपयोग कर रहे हैं, तो पहले से टेस्ट यूज़र सेट करें, अपनी Stripe मॉड्यूल मोड (test या live) कन्फर्म करें, और ईमेल/SMS/Telegram नोटिफिकेशन सुरक्षित टेस्ट रिसीपिएंट्स पर पॉइंट करें। जब टाइमर शुरू हो, तो आपको अनुभव टेस्ट करना चाहिए, क्रेडेंशियल्स ढूँढना नहीं।

स्टेप-बाय-स्टेप: 30-मिनट वॉकथ्रू

टाइमर सेट करें। एक सामान्य यूज़र अकाउंट (एडमिन नहीं) का उपयोग करें। जो भी तकनीकी रूप से काम कर रहा हो पर भ्रमित लगे, उसे लिख लें।

एक वास्तविक जर्नी end-to-end चलाएँ: ऐप खोलें, साइन इन करें, कुछ बनाएं, भुगतान करें (यदि लागू हो), और पुष्टि करें कि आपको सही संदेश मिला। लॉन्च पर जो वातावरण यूज़र्स देखेंगे वही इस्तेमाल करें, किसी विशेष प्रिव्यू के बजाय।

इस टाइमिंग को मार्गदर्शक के रूप में उपयोग करें:

• पहले 3 मिनट: पुष्टि करें ऐप लोड होता है, प्रमुख पेज खुलते हैं, और लेआउट स्पष्ट रूप से टूटे नहीं हैं।
• अगले 7 मिनट: दो पर्सोनाज़ (नया यूज़र और रिटर्निंग यूज़र) के साथ एक्सेस टेस्ट करें। साइन अप, साइन इन, लॉग आउट और भूल गया पासवर्ड चेक करें।
• अगले 8 मिनट: एक महत्वपूर्ण फॉर्म पूरा करें। सेव, एडिट, रिफ्रेश करें और पुष्टि करें कि बदलाव सचमुच सेव हुआ।
• अगले 7 मिनट: भुगतान पूरा करें। पुष्टि करें कि ऐप में “paid” स्टेटस अपडेट होता है और ग्राहक को स्पष्ट प्रमाण दिखता है।
• अंतिम 5 मिनट: नोटिफिकेशन ट्रिगर करें और डिलीवरी वेरिफाई करें। आपने क्या अपेक्षा की थी बनाम क्या हुआ, यह कैप्चर करें।

अगर कोई teammate बिना मदद मांगे जर्नी पूरा नहीं कर सकता, तो उसे लॉन्च बग मानें। मकसद यह है कि आपके पहले ग्राहक आपके टेस्टर्स न बनें।

लॉगिन और एक्सेस चेक (तेज़, पर लापरवाह नहीं)

लॉन्च-डे की समस्याएँ अक्सर सामने के दरवाजे से शुरू होती हैं। अगर लोग साइन इन नहीं कर सकते, तो बाकी सब बेकार है।

साफ़ लॉगिन के साथ शुरू करें जो एक असली ग्राहक जैसा दिखता हो। अगर आप SSO (Google, Microsoft, Okta) सपोर्ट करते हैं, तो एक SSO साइन-इन भी करें। छोटी कॉन्फ़िगरेशन बदलने के बाद ये फ्लोज़ आश्चर्यजनक रूप से अक्सर फेल होते हैं।

इन चेक्स को क्रम में चलाएँ:

• सही ईमेल और पासवर्ड से साइन इन करें, रिफ्रेश करें, और पुष्टि करें कि आप अभी भी साइन इन हैं।
• एक बार गलत पासवर्ड एंटर करें और पुष्टि करें कि संदेश स्पष्ट और मददगार है।
• पूरा forgot password flow करें: ईमेल आए, लिंक खुले, नया पासवर्ड काम करे।
• लॉग आउट करें, फिर फिर से साइन इन करें। अगर आप “Remember me” ऑफर करते हैं तो दोनों स्थितियाँ टेस्ट करें।
• सामान्य यूज़र के रूप में एक एडमिन-ओनली पेज खोलने की कोशिश करें और पुष्टि करें कि आप ब्लॉक हैं या आपको एक दोस्ताना संदेश/रिडायरेक्ट मिलता है।

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

अगर आप AppMaster में बनाते हैं, तो यह आपके authentication सेटअप और role rules की पुष्टि करने का भी अच्छा समय है कि वे शिप करने से पहले आपकी अपेक्षा के अनुसार हैं।

फॉर्म्स: वैलिडेशन, सेविंग और समझने योग्य एरर मैसेज

फॉर्म वे जगह हैं जहाँ छोटी समस्याएँ खोए हुए साइनअप और सपोर्ट वर्क में बदल जाती हैं।

सामान्य पाथ से शुरू करें: सब कुछ सही भरें, सबमिट करें, और एक स्पष्ट सफलता स्थिति देखें (संदेश, रीडायरेक्ट, या नया स्क्रीन)। फिर पुष्टि करें कि रिकॉर्ड स्टाफ वहाँ खोज सके जहाँ वे उम्मीद करते हैं।

अगला, फॉर्म को वास्तविक तरीकों से तोड़ने की कोशिश करें। आपका लक्ष्य “हैक” करना नहीं है। आप यह देख रहे हैं कि क्या ऐप एक सामान्य व्यक्ति को रिकवर करने में मदद करता है।

फॉर्म चेक्स का त्वरित सेट:

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

“सफलता” के बाद, पुष्टि करें कि स्टाफ वास्तव में सबमिशन को उनके एडमिन व्यू या इनबॉक्स में ढूँढ सकता है। अगर ऐप कहता है कि यह सेव हुआ पर कोई इसे नहीं ढूँढ पाता, तो ग्राहक समझेंगे कि आपने उन्हें अनदेखा किया।

पेमेंट्स: मनी फ्लो और ग्राहक साबित करना कन्फर्म करें

पेमेंट छोटी गलतियों को महंगा बना देते हैं। आपका टेस्ट ग्राहक अनुभव, मनी फ्लो और आपकी इनτερनल रिकॉर्ड्स के मैच होने को साबित करना चाहिए।

एक खरीद को शुरुआत से अंत तक चलाएँ: एक प्लान चुनें (या कार्ट में जोड़ें), चेकआउट पूरा करें, और एक स्पष्ट कन्फर्मेशन स्क्रीन पर land करें। ऐसी कीमत चुनें जिसे एक नज़र में पहचानना आसान हो ताकि गलतियाँ स्पष्ट हों।

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

एक न्यूनतम पेमेंट सैनीटी चेक:

• कुल और मुद्रा सही हों
• पेमेंट सफल होने के बाद ही ऑर्डर “paid” दिखे
• विफलता पर स्पष्ट संदेश और सुरक्षित retry पाथ हो
• रिफंड (यदि सपोर्ट करते हैं) ऑर्डर और कस्टमर रिकॉर्ड को अपडेट करे

इच्छा से फेल्योर भी टेस्ट करें किसी ज्ञात फेलिंग टेस्ट कार्ड या कंसल्ड पेमेंट का उपयोग करके। पुष्टि करें कि ऑर्डर paid नहीं दिखता, संदेश समझने योग्य है, और retry डुप्लिकेट नहीं बनाता।

अगर आपने चेकआउट AppMaster में Stripe के साथ बनाया है, तो पुष्टि करें कि ग्राहक जो देखता है और इन्टरनल ऑर्डर स्टेटस दोनों वही दिखाते हैं जो Stripe ने प्रोसेस किया।

नोटिफिकेशन: ईमेल, SMS और पुश चेक्स

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

हर संदेश को उसी तरीके से ट्रिगर करें जैसा असली ग्राहक करेगा। एडमिन-ओनली शॉर्टकट से टेस्ट संदेश भेजने से बचें जब तक कि ग्राहक वही पथ न उपयोग करें।

प्रत्येक संदेश के लिए पुष्टि करें:

• समय: यह तेज़ी से और लगातार आता है
• भरोसे के संकेत: भेजने वाला नाम, from पता/नंबर, विषय और preview टेक्स्ट सही दिखते हैं
• सामग्री: यह जो अभी हुआ उसका मेल खाता हो और सही नाम व ऑर्डर विवरण उपयोग करता हो
• लिंक: बटन सही स्क्रीन खोलते हैं और लॉगआउट के बाद भी काम करते हैं

किसी लिंक पर क्लिक करने के बाद, टेस्ट को एक प्राइवेट विंडो में दोहराएँ। कई टीमें मिस कर देती हैं कि मैजिक लिंक या रिसेट लिंक केवल तभी काम करता है जब आप पहले से साइन इन हों।

स्टाफ नोटिफिकेशन्स को भी मत भूलिए। नया ऑर्डर या नया टिकट ट्रिगर करें और पुष्टि करें कि सही लोग अलर्ट पाते हैं। साथ ही यह सुनिश्चित करें कि यह शोर न हो: एक एक्शन से तीन ईमेल और दो चैट मैसेज नहीं बनना चाहिए।

अगर आप AppMaster का उपयोग कर रहे हैं, तो authentication, payments, या message templates में बदलाव के बाद इस सेक्शन को फिर से चलाएँ। ये वे इलाके हैं जहाँ "छोटे" एडिट अक्सर डिलीवरी तोड़ देते हैं।

अतिरिक्त चेक्स जो असली ग्राहक का दर्द पकड़ते हैं

असली यूज़र्स पुराने फोन्स, कमजोर कनेक्शन और खाली अकाउंट्स पर आते हैं।

एक स्लो-नेटवर्क मोमेंट करें: एक फोन को सेलुलर (या कमजोर Wi-Fi) पर रखें और एक प्रमुख क्रिया जैसे लॉगिन, फॉर्म सबमिट, या चेकआउट दोहराएँ। अनंत स्पिनर, गुम लोडिंग मैसेज और ऐसे बटन्स जिन पर दो बार टैप किया जा सके, उन पर ध्यान दें।

फिर खाली स्टेट्स चेक करें। नए यूज़र्स के पास कोई ऑर्डर नहीं होता, कोई सेव्ड कार्ड नहीं होता, कोई हिस्ट्री नहीं होती। खाली स्क्रीन यह बतानी चाहिए कि आगे क्या करना है, खराब नहीं दिखना चाहिए।

कुल मिलाकर पाँच मिनट के कुछ तेज़ एक्स्ट्राज़:

• डिवाइस स्विच करें (एक फोन, एक डेस्कटॉप) और कोर फ्लो फिर चलाएँ
• रसीदों, बुकिंग्स और “last updated” लेबल पर तारीखें और समय चेक करें
• बटन टेक्स्ट और एरर मेसेज ज़ोर से पढ़ें ताकि पता चले क्या वे स्पष्ट हैं
• सफलता स्पष्ट है या नहीं (स्क्रीन, ईमेल, रसीद) की पुष्टि करें

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

गैर-टेक्निकल टीम्स की आम गलतियाँ

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

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

टीमें बैक ऑफिस परिणाम की पुष्टि करना भी भूल जाती हैं। सिर्फ यह काफी नहीं कि स्क्रीन कहे “Success.” सुनिश्चित करें कि रिकॉर्ड मौजूद है, स्टेटस सही है (paid बनाम pending), और आपकी इन्टरनल व्यू वही दिखाता है जो ग्राहक ने अभी किया।

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

अंत में, टेस्ट्स drift करते हैं। बिना टाइमर और लिखित नोट्स के लोग बस क्लिक करते हुए निकल जाते हैं और विचार छोड़ देते हैं कि “ठीक लग रहा है।” इसे टाइट रखें और सटीक स्टेप्स लॉग करें।

कुछ सरल तरीके इन जालों से बचने के:

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

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

हर रिलीज़ से पहले चलाने के लिए त्वरित चेकलिस्ट

इसे अपने शिप करने से पहले आखिरी 10-30 मिनट का हिस्सा रखें। यह गहरा QA नहीं है। यह उन मुद्दों के लिए एक तेज़ चेक है जिन्हें ग्राहक पहले नोटिस करते हैं।

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

पाँच चेक:

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

यदि कुछ भी भ्रमित, धीमा, या inconsistent है, तो उसे बग मानें भले वह “काम करता” हो।

अगर आप नो-कोड टूल जैसे AppMaster से बना रहे हैं, तो उसी प्रकार की डिप्लॉयमेंट के खिलाफ यह चेकलिस्ट चलाएँ जिसे आप लॉन्च पर उपयोग करेंगे (cloud बनाम self-hosted) ताकि आखिरी मील समान तरीके से व्यवहार करे।

उदाहरण परिदृश्य: साइनअप-टू-पेमेंट जर्नी टेस्ट करें

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

इसे पाँच स्टेप्स में चलाएँ:

• नया अकाउंट बनाएं (ताज़ा ईमेल) और पुष्टि करें कि लॉगआउट के बाद आप फिर लॉग इन कर सकते हैं।
• मुख्य रिक्वेस्ट फॉर्म सामान्य डेटा के साथ सबमिट करें, फिर एक गलत फील्ड आज़माएँ ताकि एरर मैसेज दिखे।
• अपने टेस्ट मेथड से पे करें और पुष्टि करें कि आप सफल स्क्रीन पर पहुँचे।
• ग्राहक प्रमाण चेक करें: रसीद पेज, ऑर्डर ID, और एक स्पष्ट “हमें मिल गया” कन्फर्मेशन।
• बैक ऑफिस वेरिफाई करें: यूज़र मौजूद है, रिक्वेस्ट सेव हुआ है, और पेमेंट सही स्टेटस दिखा रहा है।

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

सेवेरिटी सरल रख सकते हैं: यदि यह साइनअप, फॉर्म सबमिशन, पेमेंट, या कोर टास्क ब्लॉक करता है, तो यह ब्लॉकर है। अगर यूज़र पूरा कर सकता है पर कुछ गलत दिखता है (भ्रामक कॉपी, गायब ईमेल), तो इसे workable पर urgent मार्क करें।

अगले कदम: इसे दोहराने लायक बनाना

यह टेस्ट तब सबसे अधिक फायदा देता है जब यह रूटीन बन जाता है।

वॉकथ्रू के तुरंत बाद, 10 मिनट निकालकर जो आप पाए उसे छोटे, रिपीटेबल चेक्स में बदल दें जिन्हें आप हर रिलीज़ से पहले चला सकें। इन्हें संक्षेप और सादे भाषा में लिखें, एक अपेक्षित परिणाम के साथ। फिर हर एरिया के लिए एक ओनर असाइन करें (ओनर्स को टेक्निकल होने की ज़रूरत नहीं, बस कंसिस्टेंट होना चाहिए): login/access, forms/data saving, payments/refunds, notifications, और admin/support टूल्स।

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

अगर आपकी टीम AppMaster का उपयोग करती है, तो आप इन रीटेस्ट्स को प्रैक्टिकल रख सकते हैं द्वारा प्रमुख फ्लोज़ (signup, checkout, password reset) को स्टैण्डर्डाइज़ करके और परिवर्तनों के बाद उन्हें दोबारा चलाकर। जब requirements बदलें, एप्लिकेशन को regenerate करना मदद करता है कि उत्पन्न सोर्स कोड साफ़ और कंसिस्टेंट रहे, जो नए रिलीज़ में "पुराने फिक्स" के बने रहने को कम करता है।

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