UAT से पहले
जो UAT बिगड़ते हैं, उनमें से ज़्यादातर यहीं बिगड़ते हैं: अस्पष्ट स्कोप, ऐसी स्क्रिप्ट जिन्हें किसी ने जाँचा नहीं, ऐसे टेस्टर जिनका अकाउंट काम नहीं करता।
स्कोप
- तय करें कि कौन-सी प्रक्रियाएँ और यूज़र स्टोरी UAT में हैं, और जो नहीं हैं उन्हें लिख लें।
- हर प्रक्रिया के लिए बिज़नेस से एक ओनर तय करें: वह व्यक्ति जो साइन ऑफ़ करता है।
- पहला इश्यू दर्ज होने से पहले तय करें कि Critical, High, Medium और Low का क्या मतलब है।
टेस्ट केस
- हर बिज़नेस सिनेरियो के लिए एक टेस्ट केस लिखें, उन लोगों के शब्दों में जो उसे टेस्ट करते हैं।
- हर स्टेप को एक ऐक्शन और एक अपेक्षित नतीजा दें, और जहाँ ज़रूरी हो वहाँ टेस्ट डेटा।
- हर टेस्ट केस को Must, Should या Could चिह्नित करें, ताकि ज़रूरी टेस्ट केस पहले टेस्ट हों।
- unhappy path भी जोड़ें: ग़लत वैल्यू, छूटा हुआ फ़ील्ड, बिना सही रोल वाला यूज़र।
- जाँचें कि स्कोप की हर यूज़र स्टोरी का कम से कम एक टेस्ट केस हो।
- टेस्ट के दिनों से पहले बिज़नेस के किसी की-यूज़र से स्क्रिप्ट की समीक्षा करवाएँ।
टेस्टर
- ऐसे टेस्टर चुनें जो यह काम रोज़ करते हैं, सिस्टम इस्तेमाल करने वाली हर टीम से।
- हर टेस्टर को एक ग्रुप और उसकी अपनी स्क्रिप्ट दें।
- उनके कैलेंडर में टेस्ट के दिन ब्लॉक करें और उन्हें रोज़ के काम से मुक्त करें।
- आधे घंटे में उन्हें ब्रीफ़ करें: नतीजा कैसे दर्ज करें और इश्यू कैसे दर्ज करें।
एनवायरनमेंट और टेस्ट डेटा
- एक ऐसा टेस्ट एनवायरनमेंट तैयार करें जो प्रोडक्शन जैसा हो: कॉन्फ़िगरेशन, इंटीग्रेशन और डेटा।
- हर रोल के लिए एक टेस्ट अकाउंट बनाएँ, और जाँचें कि हर एक से साइन इन हो सकता है।
- टेस्ट डेटा लोड करें: ग्राहक, प्रोडक्ट, प्राइस लिस्ट और खुले रिकॉर्ड।
- जहाँ भी हो सके, ग्राहक डेटा की जगह टेस्ट डेटा इस्तेमाल करें।
- तय करें कि टेस्ट के दिनों में फ़िक्स टेस्ट एनवायरनमेंट में कब deploy होंगे।
शेड्यूल
- टेस्ट के दिनों की योजना ब्लॉक में बनाएँ, हर दिन ट्राइएज के लिए एक तय समय के साथ।
- फ़िक्स के बाद एक रीटेस्ट राउंड के लिए समय रखें।
- go/no-go मीटिंग की तारीख़ तय करें, और स्टीयरिंग कमेटी को अभी आमंत्रित करें।
- Salesforce या Dynamics 365 का रिलीज़ कैलेंडर देखें: आपके UAT के बीच में आया प्लेटफ़ॉर्म रिलीज़ बदल देता है कि आप क्या टेस्ट करते हैं।
एंट्री क्राइटेरिया
- सिस्टम टेस्ट पूरा हो चुका है, और उसका कोई Critical defect अब खुला नहीं है।
- टेस्ट एनवायरनमेंट, टेस्ट अकाउंट और टेस्ट डेटा तैयार हैं।
- बिज़नेस ने टेस्ट केस की समीक्षा कर ली है।
- हर टेस्टर को आमंत्रित किया जा चुका है और उसने एक बार साइन इन कर लिया है।
UAT के दौरान
दिन छोटे रखें और जानकारी एक जगह, ताकि समस्याएँ उसी दिन मिलें, उन पर फ़ैसला हो और वे ठीक हों।
रोज़ाना स्टैंड-अप
- हर दिन की शुरुआत पंद्रह मिनट से करें: क्या टेस्ट हुआ, क्या रुकावट है, आज क्या प्लान है।
- हर ग्रुप की प्रगति की तुलना प्लान से करें, और टेस्टरों को वहाँ लगाएँ जहाँ उनकी ज़रूरत है।
इश्यू दर्ज करना
- हर समस्या के लिए एक इश्यू दर्ज करें: स्टेप, आपने क्या उम्मीद की थी और उसकी जगह क्या हुआ।
- एक स्क्रीनशॉट और रिकॉर्ड का लिंक जोड़ें।
- पहले मौजूदा इश्यू खोजें, ताकि एक ही समस्या दो बार दर्ज न हो।
- पक्का करें कि हर fail हुए स्टेप का एक इश्यू हो, या न होने की वजह।
ट्राइएज
- ट्राइएज हर दिन करें, बिज़नेस और डेवलपमेंट टीम एक साथ।
- हर नए इश्यू को एक गंभीरता, एक प्राथमिकता और उसे ठीक करने वाला कोई व्यक्ति दें।
- हर एक के लिए तय करें: इसे ठीक करें, अस्वीकार करें, या इसे change request बना दें।
- change request को बैकलॉग पर रखें, इस रिलीज़ में नहीं।
रीटेस्ट
- फ़िक्स deploy होते ही, जिस टेस्टर ने इश्यू पाया था वही उसे रीटेस्ट करे।
- लिख लें कि हर रीटेस्ट किस रिलीज़ और build पर हुआ।
- बड़े फ़िक्स के बाद नया राउंड शुरू करें, और फ़िक्स के आसपास की प्रक्रियाएँ फिर से टेस्ट करें।
UAT का समापन
UAT एक फ़ैसले के साथ ख़त्म होता है। यह फ़ैसला तथ्यों के आधार पर लें, और लिख लें कि किसने क्या तय किया।
एग्ज़िट क्राइटेरिया
- हर Must टेस्ट केस पास हो चुका है।
- कोई Critical इश्यू खुला नहीं है।
- हर खुले High इश्यू के लिए एक वर्कअराउंड या फ़िक्स की एक तारीख़ है, जिसे बिज़नेस स्वीकार करता है।
- स्कोप के हर टेस्ट केस का एक नतीजा है।
साइन-ऑफ़
- हर प्रक्रिया के ओनर से साइन ऑफ़ करने को कहें: स्वीकृत, शर्तों के साथ स्वीकृत, या अस्वीकृत।
- हर शर्त लिख लें, साथ में यह कि उसे कौन करेगा और कब तक।
Go/no-go
- go/no-go मीटिंग स्क्रीन पर आँकड़ों के साथ करें, याददाश्त से नहीं।
- फ़ैसला, शर्तें और फ़ैसला किसने लिया, यह दर्ज करें।
रिपोर्ट
- बताएँ कि स्कोप में क्या था, और क्या टेस्ट नहीं हुआ।
- नतीजे हर ग्रुप और हर प्राथमिकता के अनुसार दिखाएँ, और वह रिलीज़ और build जो टेस्ट हुआ।
- खुले इश्यू गंभीरता के अनुसार सूचीबद्ध करें, हर एक पर लिए गए फ़ैसले के साथ।
- साइन-ऑफ़ जोड़ें, उनकी शर्तों के साथ।
- गो-लाइव के बाद के पहले हफ़्तों के लिए ज्ञात जोखिम और वर्कअराउंड बताएँ।
गो-लाइव के बाद
- टेस्ट केस सँभालकर रखें: वे अगले CRM रिलीज़ के लिए रिग्रेशन टेस्ट हैं।
- अगले UAT में क्या अलग करना है, यह अभी लिख लें, जब तक बात ताज़ा है।
वही चेकलिस्ट, बिना स्प्रेडशीट के
UAT Studio इस सूची का ज़्यादातर हिस्सा आपके लिए करता है। readiness check टेस्ट डे से पहले दिखाता है कि क्या कमी है, टेस्टर एक कोड से साइन इन करते हैं और सिर्फ़ अपनी स्क्रिप्ट देखते हैं, fail हुआ स्टेप स्क्रीनशॉट के साथ एक इश्यू बन जाता है, ट्राइएज एक साझा स्क्रीन पर चलता है, और आख़िरी नतीजा आते ही go/no-go रिपोर्ट तैयार होती है। इसे अपने प्रोजेक्ट पर 14 दिन के मुफ़्त पायलट के साथ आज़माएँ।
Salesforce या Dynamics 365 का रिलीज़ टेस्ट कर रहे हैं? देखें Salesforce UAT और Dynamics 365 UAT।
