स्टाफ के इस्तेमाल से पहले बिज़नेस ऐप के लिए वास्तविक जैसा टेस्ट डेटा

स्टाफ के ऐप इस्तेमाल करते ही अच्छे दिखने वाले डेमो क्यों विफल हो जाते हैं

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

असल काम इतना व्यवस्थित नहीं होता। कोई सेल्स असिस्टेंट फ़ोन नंबर के बिना संपर्क सहेज सकता है और बाद में सही ईमेल पते के साथ लौट सकता है। कोई ऑपरेशंस मैनेजर «Acme» खोजे और उसे मिलते-जुलते छह रिकॉर्ड दिखें। ग्राहक का मन बदलने पर किसी को बंद की गई रिक्वेस्ट फिर से खोलनी पड़ सकती है। वास्तविक जैसे टेस्ट डेटा इन स्थितियों को प्रोडक्शन में उलझन पैदा करने से पहले सामने लाता है।

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

साझा रिकॉर्ड वर्कफ़्लो बदल देते हैं

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

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

Koder.ai टीमों को चैट के ज़रिए वेब, सर्वर और मोबाइल ऐप बनाने देता है, लेकिन तेज़ विकास से सामान्य मानवीय व्यवहार को टेस्ट करने की ज़रूरत खत्म नहीं होती। पूरी टीम के इस पर निर्भर होने से पहले ऐप के पहले वर्शन को काम करने की वास्तविक आदतों के सामने परखें।

टेस्ट डेटा को असली जानकारी से अलग रखें

टेस्टिंग के दौरान काल्पनिक नाम, ईमेल पते, फ़ोन नंबर और कंपनी की जानकारी इस्तेमाल करें। रिकॉर्ड पर साफ़ लेबल लगाएँ, जैसे «TEST - Northside Supplies», ताकि कोई उसे असली ग्राहक न समझे। ग्राहक सूचियाँ, कर्मचारी रिकॉर्ड, वित्तीय विवरण या निजी नोट्स टेस्ट एनवायरनमेंट में कॉपी न करें।

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

स्टाफ के वास्तविक काम से शुरुआत करें

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

हर काम को साफ़ शुरुआत, कार्रवाई और अपेक्षित नतीजे वाले छोटे परिदृश्य में बदलें। भाषा इतनी सरल रखें कि कोई सहकर्मी तकनीकी मदद के बिना इसे समझ सके।

उदाहरण के लिए: «एक ग्राहक ऐसे ऑर्डर का डिलीवरी पता बदलने के लिए फ़ोन करता है, जिसे अभी भेजा नहीं गया है। सेल्स असिस्टेंट ऑर्डर खोजता है, पता बदलता है, उसे सहेजता है और ऑर्डर कन्फ़र्मेशन में नया पता देखता है।» इससे पता चलता है कि कौन-से रिकॉर्ड तैयार करने हैं और बदलाव के बाद ऐप को क्या दिखाना चाहिए।

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

कम आम कामों को भी टेस्ट करें। स्टाफ चरण भूल सकता है और मूल बिल्डर ने उन्हें कभी आज़माया ही न हो। इनमें ये काम शामिल करें:

• महीना बंद करना और बकाया इनवॉइस की जाँच करना
• गलत ग्राहक के नाम पर दर्ज ऑर्डर को सही करना
• मैनेजर की मंज़ूरी के बाद रिफंड प्रोसेस करना
• नौकरी छोड़ चुके कर्मचारी का खुला काम किसी और को सौंपना
• फ़ाइनेंस टीम या ऑडिटर के लिए रिपोर्ट एक्सपोर्ट करना

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

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

ऐसे रिकॉर्ड बनाएँ जो रोज़मर्रा के बिज़नेस डेटा जैसे लगें

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

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

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

कुछ सौ एक जैसे रिकॉर्ड से अक्सर वास्तविक जैसे पैटर्न का छोटा सेट ज़्यादा जानकारी देता है:

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

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

नोट छोटे लेकिन विश्वसनीय रखें। «ग्राहक ने डिलीवरी को दो विज़िट में बाँटने के लिए कहा» «Test note 14» से ज़्यादा उपयोगी है। टेस्ट ऐप में असली पते, अकाउंट नंबर, फ़ोन नंबर या निजी टिप्पणियाँ न डालें, चाहे यह आंतरिक परीक्षण ही क्यों न हो।

टीम को बुलाने से पहले यूज़र और अनुमतियों का मॉडल बनाएँ

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

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

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

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

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

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

Koder.ai के प्लानिंग मोड में स्टाफ को आमंत्रित करने से पहले भूमिकाओं का वर्णन करें। अलग-अलग टेस्ट अकाउंट बनाएँ और हर अकाउंट से वही छोटे काम दोहराएँ। जब ऐप में तेज़ी से बदलाव हो रहे हों, तब अनुमति से जुड़ी समस्याएँ ठीक करना आसान होता है।

सामान्य वर्कफ़्लो के आसपास की असहज स्थितियों को टेस्ट करें

ऐप की ज़्यादातर समस्याएँ साफ़ डेमो के दौरान नहीं, बल्कि सामान्य काम के बीच दिखाई देती हैं। वर्कफ़्लो के हर चरण के रिकॉर्ड बनाएँ, जिनमें रोज़मर्रा के काम जैसी तारीखें, नाम, नोट और राशियाँ हों।

ऑर्डर ऐप के लिए एक नया ऑर्डर बनाएँ, जिसे किसी ने नहीं छुआ है, एक ऐसा जिसे स्टाफ तैयार कर रहा है, एक जिसे मैनेजर ने मंज़ूर किया है और एक जिसे टीम ने पिछले महीने बंद किया था। हर चरण पर देखें कि स्टाफ कौन-से फ़ील्ड बदल सकता है। किसी बंद ऑर्डर का डिलीवरी पता बदलने पर वह चुपचाप «in progress» में वापस नहीं जाना चाहिए।

वास्तविक काम में होने वाली अपवाद स्थितियों को टेस्ट करें:

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

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

बाद में सवाल उठने पर स्टेटस हिस्ट्री महत्वपूर्ण होती है। एक सरल क्रम टेस्ट करें: Sam सुबह 9:10 पर रिक्वेस्ट बनाता है, Priya 9:25 पर उसे मंज़ूर करती है और ग्राहक के फ़ोन करने के बाद Sam 10:00 बजे उसे रद्द कर देता है। जिन स्टाफ सदस्यों को रिक्वेस्ट का ऐक्सेस है, उन्हें हर बदलाव करने वाला व्यक्ति, समय और ऐप में दर्ज कारण दिखना चाहिए। साथ ही उन्हें लंबे नोट्स पढ़े बिना मौजूदा स्टेटस भी समझ आना चाहिए।

Koder.ai ऐप के लिए बिल्ड शुरू करने से पहले इन स्थितियों का सरल भाषा में वर्णन करें। फिर स्क्रीन पूरी दिख रही है या नहीं, यह देखने के बजाय इन्हें काम के रूप में चलाएँ।

जानबूझकर ऐप में गलत इनपुट दें

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

एक ही फ़ॉर्म को कई बार इस्तेमाल करें और हर बार एक विवरण बदलें। इससे यह समझना आसान होता है कि कौन-सी जाँच विफल हुई और संदेश व्यक्ति को सुधार करने में मदद करता है या नहीं।

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

ऐप को सरल भाषा में बताना चाहिए कि किस चीज़ पर ध्यान देना है। «कम से कम 10 अंकों वाला फ़ोन नंबर दर्ज करें» स्टाफ को अगला कदम बताता है। «Validation error» ऐसा नहीं करता। जहाँ संभव हो, संदेश फ़ील्ड के पास रखें और यूज़र के सबमिट करने के बाद भी उसे दिखाई देते रहने दें।

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

असफल सबमिशन के बाद आगे बढ़ने का साफ़ रास्ता होना चाहिए: चिह्नित फ़ील्ड ठीक करना, सुरक्षित रूप से रद्द करना या अधूरे काम को ड्राफ्ट के रूप में सहेजना। ऐसे एरर पॉपअप से बचें जो स्टाफ के पढ़ने से पहले गायब हो जाएँ या ऐसी बटन से, जो असफल प्रयास के बाद काम करना बंद कर दे।

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

स्टाफ के एक वास्तविक परिदृश्य को पूरा चलाकर देखें

मान लीजिए 12 कर्मचारियों वाली एक हीटिंग और प्लंबिंग कंपनी है। वह एक ऐप में ग्राहक, सर्विस जॉब, इनवॉइस और भुगतान ट्रैक करती है।

ऑफ़िस मैनेजर Maya को Jordan Lee का फ़ोन आता है। रेडिएटर लीक कर रहा है। वह Jordan को खोजती है और उसे दो ग्राहक रिकॉर्ड मिलते हैं: «Jordan Lee» और «J. Lee», दोनों एक ही पते पर। Maya एक रिकॉर्ड चुनती है, बुधवार सुबह के लिए जॉब बनाती है, बताई गई समस्या जोड़ती है और टेक्नीशियन Sam को काम सौंपती है।

जॉब «Booked» स्टेटस से शुरू होती है। Sam साइट पर फ़ोन से ऐप खोलता है। वह एक फ़ोटो जोड़ता है, स्टेटस «Work complete» करता है और पार्ट्स तथा श्रम दर्ज करता है। यह लेबल अंतिम स्थिति जैसा लगता है, लेकिन इनवॉइस बनाने से पहले Maya को शुल्क जाँचना है। स्टाफ «Work complete» को «बिल बनाने के लिए तैयार» समझ सकता है, जबकि Sam का मतलब केवल साइट से निकलना हो सकता है।

«Awaiting office review» जैसा स्पष्ट स्टेटस इस्तेमाल करें। तब Maya को अगला कदम साफ़ दिखेगा और कोई व्यक्ति कीमत जाँचे बिना ऐप इनवॉइस नहीं भेजेगा।

Maya देखती है कि Jordan का एक पुराना इनवॉइस 45 दिनों से बकाया है। वह तय करती है कि नए काम की बिलिंग से पहले सुपरवाइज़र की मंज़ूरी ज़रूरी है। उसकी सुपरवाइज़र Priya, Sam के नोट्स देखती है और डिस्काउंट मंज़ूर करती है, क्योंकि पिछली मरम्मत विफल हो गई थी।

यह परिदृश्य जाँचता है कि ऐप वास्तविक फैसलों को संभाल सकता है या नहीं:

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

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

अगर Sam अपने फ़ोन से डिस्काउंट मंज़ूर कर सकता है, तो अनुमति के नियम ठीक करें। अगर Maya यह नहीं समझ पाती कि «Work complete» का अर्थ बिल बन चुका है या साइट पर काम पूरा हुआ है, तो स्टाफ के इस पर निर्भर होने से पहले स्टेटस का नाम बदलें।

एक सरल टेस्ट सेशन चलाएँ और नतीजे दर्ज करें

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

अगर वे रुकते हैं, गलत मेनू चुनते हैं या किसी लेबल का अर्थ पूछते हैं, तो इसे लिख लें। ये पल बताते हैं कि ऐप को अधिक स्पष्ट भाषा या सरल रास्ते की ज़रूरत कहाँ है।

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

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

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

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

पहले स्टाफ रोलआउट से पहले यह जाँच करें

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

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

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

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

हर अनुमति स्तर के लिए अलग टेस्ट अकाउंट बनाएँ, एक लॉगिन साझा न करें। इससे ऐक्सेस की समस्याओं को दोहराना और ठीक करना आसान होता है।

डुप्लिकेट ग्राहक नाम, पुराने बंद रिकॉर्ड, खाली वैकल्पिक फ़ील्ड, कई महीनों की तारीखें और लंबे नोट जोड़ें। «Smith» खोजें, स्टेटस के आधार पर फ़िल्टर करें, रिपोर्ट को सॉर्ट करें और उन्हीं नतीजों को फ़ोन पर खोलें। छोटे सैंपल सेट अक्सर धीमे पेज, भ्रमित करने वाले लेबल और बहुत सारे रिकॉर्ड होने पर विफल फ़िल्टर छिपा देते हैं।

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

टेस्टिंग का अगला दौर तैयार करें

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

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

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

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

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

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