ऐसे टेस्ट केस लिखना जो बिज़नेस टेस्टर समझें

बिज़नेस टेस्टरों को अलग टेस्ट केस क्यों चाहिए

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

इसलिए UAT टेस्ट केस को ऐसे व्यक्ति के लिए काम करना चाहिए जो:

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

साफ़ टेस्ट केस पर लगाया गया हर घंटा टेस्ट डे पर कई घंटे बचाता है: कम सवाल, कम ऐसे इश्यू जो बाद में ग़लतफ़हमी निकलते हैं, और ऐसे नतीजे जिन पर आप go/no-go पर भरोसा कर सकें।

यूज़र स्टोरी और प्रक्रियाओं से

टेस्ट केस दो जगहों से आते हैं, और आपको दोनों चाहिए।

यूज़र स्टोरी और उनके एक्सेप्टेंस क्राइटेरिया

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

कवरेज जाँचें: स्कोप की हर यूज़र स्टोरी के लिए कम से कम एक टेस्ट केस चाहिए। जिस स्टोरी का कोई टेस्ट केस नहीं, वह एक कमी है, और कमियाँ प्रोडक्शन में मिलती हैं।

बिज़नेस प्रक्रियाएँ, शुरू से आख़िर तक

यूज़र स्टोरी डेवलपरों के लिए छोटे हिस्सों में काटी जाती हैं। बिज़नेस प्रक्रियाओं में काम करता है, जो कई स्टोरी से होकर गुज़रती हैं: lead to cash, quote to order, ईमेल से समाधान तक केस मैनेजमेंट। कोई स्टोरी अपने आप में पास हो सकती है, जबकि दो टीमों के बीच हैंड-ओवर पर प्रक्रिया टूट जाती है।

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

UAT Studio मेंUser stories कार्ड पर Jira या Azure DevOps से यूज़र स्टोरी पढ़ें, और कमियाँ देखने के लिए Only stories without test cases पर टिक करें। AI test design मॉड्यूल के साथ, AI आपकी स्टोरी या किसी प्रक्रिया के विवरण से टेस्ट केस प्रस्तावित करता है, आपकी कंपनी के अपने मॉडल पर भी। जब तक आप मंज़ूर न करें, कुछ भी टेस्ट केस नहीं बनता। मॉड्यूल के बिना, Prepare with your own AI एक prompt देता है जिसे आप अपनी कंपनी के AI में पेस्ट कर सकते हैं; [CHECK] से चिह्नित स्टेप ऐसी धारणाएँ हैं जिन्हें जाँचना है।

हर टेस्ट केस का एक लक्ष्य

एक टेस्ट केस एक बिज़नेस परिदृश्य को टेस्ट करता है, एक लक्ष्य के साथ। उसका टाइटल बिज़नेस के शब्दों में बताता है कि टेस्टर क्या हासिल करता है:

• मौजूदा अकाउंट वाली लीड को कन्वर्ट करें
• 20% से ज़्यादा डिस्काउंट वाले कोट को मंज़ूर करें
• किसी जाने-पहचाने ग्राहक की ईमेल को सही क्यू में रूट करें

न कि लीड ऑब्जेक्ट को टेस्ट करें, और न ही लीड, अपॉर्च्युनिटी और कोट। जब किसी टेस्ट केस के कई लक्ष्य होते हैं, तो एक फ़ेलियर सबको रोक देता है, और नतीजा कम बताता है: क्या फ़ेल हुआ, और क्या अब भी काम करता है?

एक टेस्ट केस कितना बड़ा हो?

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

end-to-end टेस्ट केस अपवाद हैं। वे पूरी प्रक्रिया को फ़ॉलो करते हैं और लंबे हो सकते हैं। उन्हें रखें, लेकिन ध्यान रखें कि प्रक्रिया के हर हिस्से का अपना छोटा टेस्ट केस भी हो, ताकि किसी फ़ेलियर की जगह आसानी से पता चले।

अपेक्षित नतीजे वाले स्टेप

हर स्टेप के दो हिस्से होते हैं: एक एक्शन (टेस्टर क्या करता है) और एक अपेक्षित नतीजा (क्या होना चाहिए)। अपेक्षित नतीजा ही स्टेप को टेस्ट करने लायक बनाता है। इसके बिना टेस्टर तय करता है कि क्या काफ़ी अच्छा है, और दो टेस्टर अलग-अलग तय करते हैं।

एक्शन लिखें

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

अपेक्षित नतीजा लिखें

• बताएँ कि टेस्टर क्या देखता है: एक मैसेज, किसी फ़ील्ड में वैल्यू, एक नया रिकॉर्ड, एक स्टेटस।
• सटीक रहें। अपॉर्च्युनिटी Qualification स्टेज में है, न कि यह काम करता है।
• जब ज़रूरी हो, बताएँ कि क्या नहीं होना चाहिए: कोई दूसरा अकाउंट नहीं बनता।
• जो चीज़ें सिस्टम अपने-आप करता है, उनके लिए बताएँ कि कहाँ देखना है: केस एक मिनट के भीतर Benelux Support क्यू में दिखता है।

टेस्ट डेटा और रोल

टेस्ट डेटा

टेस्टर UAT के किसी भी दूसरे हिस्से से ज़्यादा समय डेटा ढूँढने में गँवाते हैं। जहाँ भी डेटा मायने रखता है, उसे टेस्ट केस में डालें: कौन-सा ग्राहक, कौन-सा प्रोडक्ट, कौन-सी प्राइस लिस्ट या price book, कितनी राशि। वह डेटा पहले टेस्ट डे से पहले टेस्ट परिवेश में तैयार करें।

• ऐसे नाम इस्तेमाल करें जो साफ़ तौर पर टेस्ट डेटा हों, जैसे Jansen Logistics (test)।
• जब टेस्टर डेटा बदलते हैं, तो हर टेस्टर को उसके अपने रिकॉर्ड दें, ताकि दो लोग एक ही अपॉर्च्युनिटी को एडिट न करें।
• सीमाओं पर वैल्यू जोड़ें: सीमा से ठीक नीचे और ठीक ऊपर का डिस्काउंट, एक खाली ज़रूरी फ़ील्ड।
• जहाँ बच सकें, वहाँ ग्राहकों के असली व्यक्तिगत डेटा का इस्तेमाल न करें।

रोल

CRM में यूज़र क्या देख और कर सकता है, यह उसके रोल पर निर्भर करता है: Salesforce में एक profile और permission sets, Dynamics 365 में सुरक्षा भूमिकाएँ और एक business unit। UAT यह साबित करता है कि हर रोल अपना काम कर सकता है, और सिर्फ़ अपना काम। इसलिए हर टेस्ट केस बताता है कि कौन-सा रोल उसे टेस्ट करता है, और टेस्टर ठीक उसी रोल वाले टेस्ट यूज़र से साइन इन करता है।

कभी एडमिनिस्ट्रेटर से टेस्ट न करें। एडमिनिस्ट्रेटर सब कुछ देखता है और सब कुछ कर सकता है, इसलिए जो समस्याएँ UAT को ढूँढनी चाहिए, वे छिपी रह जाती हैं।

UAT Studio मेंहर स्टेप में एक एक्शन, एक अपेक्षित नतीजा और, चाहें तो, टेस्ट डेटा होता है। हर टेस्टर को एक Test role और एक Test account मिलता है, जो उनके टेस्ट के ऊपर Log in as … के रूप में दिखता है, और रोल उनके दर्ज किए हर इश्यू पर उनके नाम के साथ दिखता है।

प्राथमिकता और जोखिम

सब कुछ बराबर अच्छी तरह टेस्ट करने का समय कभी काफ़ी नहीं होता। हर टेस्ट केस को चिह्नित करें, ताकि ज़रूरी टेस्ट पहले हों, और समय ख़त्म होने पर भी पूरे हों।

इसके साथ जोखिम जोड़ें: गो-लाइव के बाद यह गलत होने पर इसकी क्या कीमत होगी। इनवॉइस पर गलत कीमत ऊँचा जोखिम है; रिपोर्ट पर गलत लेबल कम। एक ही प्राथमिकता में, टेस्टर ऊँचे जोखिम से शुरू करते हैं।

Must के साथ सख़्त रहें। जब आधे टेस्ट केस Must हों, तो इस लेबल का कोई मतलब नहीं रहता: इसे उसके लिए रखें जिसके बिना बिज़नेस काम नहीं कर सकता। प्राथमिकताएँ प्रक्रिया-मालिकों के साथ तय करें: वे go/no-go पर भी फ़ैसला करते हैं, जहाँ पास न हुए Must टेस्ट केस सबसे ज़्यादा गिने जाते हैं।

UAT Studio मेंएडिटर में या इम्पोर्ट करते समय एक कॉलम में Priority (Must, Should, Could) और Risk (High, Medium, Low) सेट करें। दूसरे टूल की वैल्यू भी पढ़ी जाती हैं: Critical और High Must बन जाते हैं, Medium और Normal Should, Low Could। टेस्टर अपने Must टेस्ट केस पहले देखते हैं, और हर प्राथमिकता में ऊँचा जोखिम पहले।

एक उदाहरण

टेस्ट केस 12: 20% से ज़्यादा डिस्काउंट वाले कोट को मंज़ूर करें

प्राथमिकता Must, जोखिम High। यूज़र स्टोरी CRM-118। रोल: सेल्स रेप (स्टेप 1 से 3) और सेल्स मैनेजर (स्टेप 4 और 5)।

ध्यान दें कि इसे क्या कारगर बनाता है: टाइटल में एक लक्ष्य, हर स्टेप में एक एक्शन, ऐसा अपेक्षित नतीजा जिसे टेस्टर जाँच सके, डेटा और रोल का नाम, और स्टेप 3 में एक unhappy path। सीमा से नीचे के डिस्काउंट के लिए एक दूसरा टेस्ट केस जोड़ें, जिसमें कोई मंज़ूरी नहीं लगनी चाहिए।

आम गलतियाँ

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

किसी की-यूज़र से समीक्षा करवाएँ

टेस्ट डे से पहले, बिज़नेस के किसी की-यूज़र से टेस्ट केस पढ़ने और उनमें से दो या तीन को टेस्ट परिवेश में आज़माने को कहें। उन्हें वह दिखता है जो लिखने वाला नहीं देख पाता: ऐसा स्टेप जो पहले से जानकारी मानकर चलता है, ऐसा लेबल जो बदल गया, ऐसी प्रक्रिया जो किसी दूसरे देश में अलग चलती है।

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

UAT Studio मेंटेस्ट केस Excel, Azure DevOps, Xray या Zephyr Scale वाले Jira, या TestRail से इम्पोर्ट करें, या उन्हें एडिटर में लिखें। टेम्पलेट लाइब्रेरी, जो हर पेड प्लान का ऐड-ऑन है, में Salesforce और Dynamics 365 के लिए तैयार स्क्रिप्ट हैं, जिन्हें आप अपने सेटअप के अनुसार बदल सकते हैं।

इस्तेमाल के लिए मुफ़्त

UAT से पहले, दौरान और बाद में बाक़ी जो कुछ तय करना है, उसके लिए देखें CRM गो-लाइव के लिए UAT चेकलिस्ट, जो मुफ़्त Excel फ़ाइल के रूप में भी है।