उपयोगकर्ता कहानी और स्वीकृति मानदंड क्या है (उदाहरण)

उदाहरण:

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

एक स्वीकृति मानदंड क्या है?

स्वीकृति मानदंड स्वीकृत शर्तों या व्यावसायिक नियमों का एक समूह है जिसे कार्यक्षमता या सुविधा को संतुष्ट करना चाहिए और मिलना चाहिए, ताकि उत्पाद स्वामी / हितधारकों द्वारा स्वीकार किया जा सके।

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

इसका प्रारूप इस प्रकार है:

' कुछ पूर्वधारणा को देखते हुए जब मैं कुछ कार्रवाई करता हूं तो मुझे परिणाम की उम्मीद होती है ”।

लोड परीक्षण और प्रदर्शन परीक्षण के बीच अंतर

उदाहरण (w.r.t ऊपर उपयोगकर्ता की कहानी के लिए):

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

इसलिए, उपयोगकर्ता कहानी किसी भी कार्यक्षमता या सुविधा के लिए आवश्यकता को परिभाषित करती है, जबकि स्वीकृति मानदंड उपयोगकर्ता कहानी या आवश्यकता के लिए 'की गई परिभाषा' को परिभाषित करता है।

क्यूए के रूप में, उपयोगकर्ता की कहानी और इसके स्वीकृति मानदंड को गहराई से समझना बहुत महत्वपूर्ण है, क्योंकि परीक्षण की शुरुआत में एक भी संदेह शेष नहीं है '। आगे बढ़ते हुए आइए समझते हैं कि उपयोगकर्ता कहानियों और स्वीकृति मानदंडों में 'गहरा' खोदना क्यों बेहद महत्वपूर्ण है।

उपयोगकर्ता कहानियों में गहरी खुदाई

शुरुआत करने के लिए, आइए पहले एक बुनियादी और मूलभूत चीज़ के-इन-डेप्थ ’अध्ययन के महत्व को समझें अर्थात् प्रयोक्ता कहानियां।

निम्नलिखित मामले मेरे अपने वास्तविक अनुभव हैं।

मामला एक:

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

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

आइए कल्पना करें कि मोबाइल ऐप अभी लॉन्च किया गया है और उनके पोर्टल्स पहले से मौजूद हैं और ऊपर हैं।

संकट: स्प्रिंट के लिए आपके उत्पाद के मालिक के पास इस मोबाइल ऐप के लिए एक उपयोगकर्ता कहानी है 'एक पोर्टल व्यवस्थापक के रूप में, मुझे डिलीवरी के समय डिलीवरी व्यक्ति द्वारा लिए गए हस्ताक्षर को देखने में सक्षम होना चाहिए' । यहां पर पोर्टल (वेब ​​ऐप) हस्ताक्षर को प्रतिबिंबित करने के लिए बदले और अपडेट किए गए हैं।

क्यूए के रूप में आपको यह सत्यापित करना होगा कि मोबाइल एप्लिकेशन में कैप्चर किए गए हस्ताक्षर पोर्टल में अपेक्षित रूप से प्रतिबिंबित हो रहे हैं।

यदि आप इस उपयोगकर्ता कहानी को देखते हैं, तो यह सरल दिखता है, लेकिन यहां एक छिपी आवश्यकता है कि 'ऐतिहासिक प्रसव के लिए, कोई हस्ताक्षर प्रतिबिंब कार्यक्षमता नहीं थी, इसलिए यदि पोर्टल लोग ऐतिहासिक प्रसव देखते हैं तो क्या होना चाहिए?' क्या ऐतिहासिक आंकड़ों को मिटा दिया जाना चाहिए? क्या हमें ऐसे डेटा के लिए क्रैश या त्रुटियों की अनुमति देनी चाहिए?

बिल्कुल नहीं, यह शालीनता से संभाला जाना चाहिए।

उपाय: जब संबंधित डीबी तालिकाओं को हस्ताक्षर स्थान के लिए एक नया कॉलम जोड़ने के लिए अपडेट किया जाता है, तो पुराने डेटा में एक NULL या 0 मान होना चाहिए जिसे चेक किया जाना चाहिए और 'कोई हस्ताक्षर मौजूद नहीं है' संदेश दिखाया जाना चाहिए।

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

केस # 2

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

संकट: द प्रोडक्ट ओनर आपको एक यूजर स्टोरी देता है 'एक सलाहकार के रूप में, मैं अपने वित्तीय विवरण के आधार पर अपने ग्राहक की रिपोर्ट देखना चाहता हूं'।

यहां 2 छिपी आवश्यकताएं थीं और मैं इसे एक अधूरी कहानी के रूप में कहूंगा क्योंकि:

सेवा मेरे) रिपोर्टों को दैनिक मुद्रा रूपांतरण दर पर विचार करना चाहिए और ऐतिहासिक नहीं जैसा कि अंतिम देखी गई रिपोर्ट और

बी) यदि ग्राहक के वित्तीय विवरण प्रदान करने के बाद मुद्रा को बदल दिया जाता है, तो रिपोर्ट को परिवर्तित मुद्रा में दिखाना चाहिए।

उपाय: मैंने सीधे अपने प्रोडक्ट ओनर के साथ इस चिंता को उठाया और उसे अवगत कराया कि इन दोनों को जल्द से जल्द पूरा करना था। उन्होंने मेरे साथ सहमति व्यक्त की और आगामी स्प्रिंट के लिए 2 अलग-अलग कहानियों को प्राथमिकता के साथ बनाया।

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

अपनी सोच के बारे में बीए और डेवलपर्स के साथ चीजों को आसान बनाने और चर्चा करने के लिए नोट्स बनाएं।

स्वीकृति मानदंड पर गहराई से देखें

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

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

आपके कथन को डाउनलोड करने के लिए फ़ाइल के प्रकार का चयन करने का विकल्प है। यदि आप केवल क्रेडिट / डेबिट / दोनों डाउनलोड करना चाहते हैं तो चुनने का विकल्प है।

अब कल्पना कीजिए कि उत्पाद स्वामी आपको यह उपयोगकर्ता कहानी 'एक ग्राहक के रूप में, मैं अपना खाता विवरण डाउनलोड करना चाहता हूं ताकि मैं एक विशिष्ट अवधि के लिए किए गए मेरे सभी लेनदेन देख सकूं'।

निम्नलिखित स्वीकृति मानदंड के साथ:

• यह देखते हुए कि मैं डाउनलोड ऐतिहासिक विवरण पृष्ठ पर हूं, मुझे उस अवधि का चयन करना चाहिए जिसके लिए मैं वक्तव्य डाउनलोड करना चाहता हूं।
• यह देखते हुए कि मैं डाउनलोड ऐतिहासिक विवरण पृष्ठ पर हूं, मुझे उस खाते का चयन करना चाहिए जिसके लिए मैं वक्तव्य डाउनलोड करना चाहता हूं।
• यह देखते हुए कि मैं ऐतिहासिक विवरण पृष्ठ डाउनलोड कर रहा हूं, मुझे भविष्य के am तारीख ’के लिए वक्तव्य डाउनलोड करने की अनुमति नहीं दी जानी चाहिए।
• यह देखते हुए कि मैं डाउनलोड ऐतिहासिक विवरण पृष्ठ पर हूं, मुझे अतीत से 10 साल पहले की तारीख से 'का चयन करने की अनुमति नहीं दी जानी चाहिए।
• यह देखते हुए कि मैं अपना वक्तव्य डाउनलोड करता हूं, मुझे डाउनलोड की गई फाइल देखने में सक्षम होना चाहिए।
• यह देखते हुए कि मैं डाउनलोड ऐतिहासिक विवरण पृष्ठ पर हूं, मुझे अपने बयान को डॉक, एक्सेल और पीडीएफ प्रारूपों में डाउनलोड करने में सक्षम होना चाहिए।

यदि आप इस स्वीकृति से गुजरते हैं, तो यहां 3 चीजें गायब हैं:

• डाउनलोड किए जाने वाले फ़ाइल नाम का नाम और प्रारूप।
• फ़ाइल में कौन सी जानकारी (कॉलम नाम) प्रदर्शित की जानी है।
• विकल्प यह चुनने के लिए सूचीबद्ध होता है कि ग्राहक किस तरह का लेनदेन चाहता है यानी केवल डेबिट या केवल क्रेडिट या दोनों।

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

प्रारंभिक चरण में पाए जाने वाले कीड़े की लागत compared परीक्षण ’चरण की तुलना में कुछ भी नहीं है।

उपयोगकर्ता कहानी / स्वीकृति मानदंड में विसंगतियां खोजने का महत्व

विकास या परीक्षण शुरू होने से पहले ही प्रारंभिक चरण में उपयोगकर्ता की कहानियों और स्वीकृति मानदंडों में एक गहरा गोता लगाने के लिए हमेशा महत्वपूर्ण होता है।

क्योंकि इसमें शामिल हैं:

(१) समय की बर्बादी:

यदि उपयोगकर्ता की कहानी / स्वीकृति मानदंडों में विसंगतियां या गलतियां पाई जाती हैं, जब विकास चल रहा है या परीक्षण चल रहा है, तो शेष स्प्रिंट समय में बहुत सारे काम करने की आवश्यकता हो सकती है।

ऐसा नहीं होता है कि भले ही प्रोडक्ट ओनर को कुछ चीजें याद न हों, लेकिन वे यूजर स्टोरी को आने वाले स्प्रिंट में स्थानांतरित कर देंगे। 95% संभावना है कि वे टीम को आवश्यक कार्यान्वयन करने के लिए कहें और इसे उसी स्प्रिंट में जारी करें।

इसलिए यह टीम के लिए एक बुरा सपना बन जाता है क्योंकि उन्हें अतिरिक्त समय बिताना होता है, सप्ताहांत पर आना होता है या देर रात तक काम करना होता है। इसका अध्ययन और संभावित प्रारंभिक स्तर पर उपयोगकर्ता की कहानी / स्वीकृति मानदंडों पर चर्चा करके इससे बचा जा सकता है।

# 2) प्रयासों का अपव्यय:

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

ऐसी स्थिति में, विकास या परीक्षण चरण में गलतियों की संभावना है। यदि आप ऐसी स्थिति में आते हैं तो 'देवक्यूए पेयरिंग' के लिए जाएं। केक पर एक टुकड़े के रूप में, आपको अतिरिक्त काम के लिए मुआवजा नहीं मिल सकता है।

निष्कर्ष

उपयोगकर्ता कहानी की गहरी समझ और स्वीकृति मानदंड केवल इसका अध्ययन करने में अपार समय खर्च करके प्राप्त किया जा सकता है।

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

सक्रिय रूप से प्री-प्लान मीटिंग में भाग लेना, बीए से बात करना, अपने आप से अध्ययन करना ही आपको इसे हासिल करने में मदद कर सकता है। जितना अधिक आप प्रयास करते हैं, उतना ही आप सीखते हैं और बढ़ते हैं।

यह क्यूए या डेवलपर्स हो, हर किसी को उपयोगकर्ता की कहानियों और उनकी स्वीकृति मानदंडों के बारे में एक ही पृष्ठ पर होना चाहिए, तभी ग्राहक की उम्मीदों को सफलतापूर्वक प्राप्त किया जा सकता है।

क्या आपके पास उपयोगकर्ता कहानियों के साथ काम करने के अपने अनुभवों के बारे में हमारे साथ साझा करने के लिए कुछ नया है? कृपया अपने विचार नीचे व्यक्त करें !!

अनुशंसित पाठ

• MongoDB उपयोगकर्ता बनाएं और उदाहरणों के साथ भूमिकाएँ असाइन करें
• उदाहरणों के साथ स्वीकृति परीक्षण रिपोर्ट के लिए नमूना टेम्पलेट
• MongoDB में उपयोगकर्ता प्रमाणीकरण
• JMeter डेटा परिशोधन उपयोगकर्ता परिभाषित चर का उपयोग कर
• यूनिक्स अनुमतियाँ: उदाहरणों के साथ यूनिक्स में फ़ाइल अनुमतियाँ
• स्वीकृति परीक्षण क्या है (एक पूर्ण गाइड)
• उपयोगकर्ता स्वीकृति परीक्षण (UAT) क्या है: एक पूर्ण गाइड
• उदाहरणों के साथ अजगर डेटाइम ट्यूटोरियल