प्रत्येक उत्पाद टीम एक विचार के साथ शुरू होती है। यह एक चिंगारी के रूप में शुरू होती है, कॉफी के दौरान एक बातचीत या एक सफेद बोर्ड पर एक नोट के रूप में। इस चिंगारी को अक्सर कहा जाता हैअस्पष्ट विचार। इसमें संभावना होती है, लेकिन इसमें संरचना की कमी होती है। संरचना के बिना, एक विचार वास्तविक समस्याओं को हल करने वाले सॉफ्टवेयर में बदल नहीं सकता है। धुंधले विचार और काम करने वाले फीचर के बीच का सेतु हैपरीक्षण योग्य उपयोगकर्ता कहानी.
बहुत सी टीमें यहां परेशानी में हैं। वे ऐसी आवश्यकताएं लिखती हैं जिनकी व्याख्या अलग-अलग हो सकती है। डेवलपर्स एक तरीके से बनाते हैं, टेस्टर्स दूसरे तरीके से टेस्ट करते हैं, और प्रोडक्ट ओनर को लगता है कि परिणाम लक्ष्य से दूर है। इस असंगति की कीमत समय, पैसा और मनोबल के रूप में आती है। समाधान सटीकता में है। अस्पष्ट विचारों को परीक्षण योग्य उपयोगकर्ता कहानियों में बदलकर, टीमें स्पष्टता, पूर्वानुमान और गुणवत्ता प्राप्त करती हैं।
यह गाइड यह देखने का प्रयास करती है कि कच्चे विचारों को कैसे क्रियान्वयन योग्य आइटम में बदला जाए। हम एक मजबूत कहानी की रचना, स्वीकृति मानदंड की भूमिका और सहयोग के महत्व पर विचार करेंगे। यहां कोई जादुई उपकरण नहीं है, बस बेहतर डिलीवरी के लिए साबित व्यावहारिक तरीके हैं।
परीक्षण योग्य उपयोगकर्ता कहानी क्या है? 🧐
एक उपयोगकर्ता कहानी केवल ट्रैकिंग सिस्टम में एक टिकट नहीं है। यह एक बातचीत के प्रति प्रतिबद्धता है। यह एक अंतिम उपयोगकर्ता के दृष्टिकोण से एक क्षमता का वर्णन करती है। हालांकि, एक कहानी केवल तभी मूल्यवान होती है जब उसकी पुष्टि की जा सके। अगर आप उसके लिए एक परीक्षण मामला नहीं लिख सकते, तो वह तैयार नहीं है।
परीक्षण योग्यता का अर्थ है कि व्यवहार को देखा और मापा जा सकता है। यह अस्पष्टता को दूर करता है। जब एक कहानी परीक्षण योग्य होती है, तो सभी जानते हैं कि पूरा कैसा दिखता है, जब काम शुरू होने से पहले। इससे निर्गत से परिणाम की ओर ध्यान केंद्रित करने की ओर बदलाव आता है।
- भूमिका: इस फीचर के लिए कौन मांग कर रहा है?
- लक्ष्य: वे क्या हासिल करना चाहते हैं?
- लाभ: व्यवसाय या उपयोगकर्ता के लिए यह क्यों महत्वपूर्ण है?
इन तत्वों के बिना, एक कहानी सिर्फ एक कार्य है। एक कार्य एक निर्देश है। एक कहानी एक मूल्य प्रस्ताव है। लक्ष्य यह सुनिश्चित करना है कि प्रत्येक कहानी मूल्य प्रदान करे जिसकी पुष्टि की जा सके।
अस्पष्टता की कीमत 📉
जब आवश्यकताएं अस्पष्ट होती हैं, तो टीम को एक कीमत चुकानी पड़ती है। यह कीमत केवल मुद्रा में नहीं होती है; यह ज्ञानात्मक भार और समय में होती है। परिणामों को समझना सटीकता की ओर बढ़ने के लिए प्रेरित करता है।
1. पुनर्निर्माण और बर्बादी
अगर एक डेवलपर मानता है कि एक फीचर एक तरीके से काम करना चाहिए, लेकिन प्रोडक्ट ओनर ने दूसरा इरादा रखा है, तो कोड को फिर से लिखना होगा। यह बर्बादी है। यह विभिन्न संसाधनों को खर्च करती है जिनका उपयोग नए फीचर्स के लिए किया जा सकता था। अस्पष्टता अनुमानों की ओर जाती है, और अनुमान त्रुटियों की ओर जाते हैं।
2. परीक्षण के अंतराल
अगर आवश्यकताएं स्पष्ट नहीं हैं, तो टेस्टर्स एक मजबूत परीक्षण सेट नहीं बना सकते। वे अनुमान लगाएंगे। अगर वे गलत अनुमान लगाते हैं, तो बग प्रोडक्शन में घुस जाते हैं। बाद में, बग को ठीक करना पहली बार सही कोड लिखने से अधिक महंगा होता है। स्पष्ट कहानियां परीक्षण के लिए स्क्रिप्ट प्रदान करती हैं।
3. टीम में तनाव
जब उम्मीदों में अंतर होता है, तो विवाद उत्पन्न होते हैं। डेवलपर्स अस्पष्ट विवरणों के लिए प्रोडक्ट ओनर्स को दोषी ठहराते हैं। प्रोडक्ट ओनर्स दृष्टि को न देखने के लिए डेवलपर्स को दोषी ठहराते हैं। एक परीक्षण योग्य कहानी एक साझा अनुबंध के रूप में काम करती है। यह टीम को एक ही सफलता की परिभाषा के चारों ओर एकजुट करती है।
गुणवत्ता के लिए INVEST मॉडल 🏗️
कहानियों को परीक्षण योग्य बनाने के लिए, उन्हें विशिष्ट गुणवत्ता मानदंड पूरे करने चाहिए। द INVESTमॉडल एक चेकलिस्ट प्रदान करता है। प्रत्येक अक्षर एक अच्छी कहानी की विशेषता का प्रतिनिधित्व करता है।
| अक्षर | अर्थ | इसका क्यों महत्व है |
|---|---|---|
| I | स्वतंत्र | कहानियों को डिलीवर करने के लिए दूसरों पर निर्भर नहीं रहना चाहिए। |
| N | समझौते योग्य | विवरण चर्चा किए जाते हैं, पत्थर के रूप में निश्चित नहीं किए जाते। |
| V | मूल्यवान | इसे उपयोगकर्ता या व्यवसाय को मूल्य प्रदान करना चाहिए। |
| E | आकलन योग्य | टीम को प्रयास के आकार का आकलन करने में सक्षम होना चाहिए। |
| S | छोटा | बड़ी कहानियाँ परीक्षण और प्रबंधन के लिए कठिन होती हैं। |
| T | परीक्षण योग्य | स्वीकृति मानदंड की प्रमाणीकरण की जानी चाहिए। |
बहुत अधिक ध्यान केंद्रित करें छोटा और परीक्षण योग्य। बड़ी कहानियाँ जटिलता को छिपाती हैं। वे अक्सर एक ही इटरेशन में परीक्षण करने के लिए बहुत बड़ी होती हैं। उन्हें छोटे हिस्सों में बांटने से जोखिम कम होता है। यदि कहानी बहुत बड़ी है, तो उसे बांटें। कार्य के आधार पर, उपयोगकर्ता प्रकार के आधार पर या डेटा आयतन के आधार पर बांटें।
स्वीकृति मानदंड लिखना 📝
स्वीकृति मानदंड उपयोगकर्ता कहानी के गार्डरेल्स हैं। वे फीचर की सीमाओं को परिभाषित करते हैं। वे प्रश्न का उत्तर देते हैं: इस कहानी को स्वीकार करने के लिए कौन सी स्थितियां पूरी होनी चाहिए?
उन्हें लिखने के कई तरीके हैं। सबसे आम तरीका स्थितियों का उपयोग करता है। इस दृष्टिकोण में एक विशिष्ट संदर्भ में व्यवहार का वर्णन किया जाता है। इससे सामान्य भाषा से बचा जाता है।
खराब बनाम अच्छे उदाहरण
अस्पष्ट और परीक्षण योग्य भाषा के बीच अंतर देखने के लिए निम्नलिखित उदाहरणों की तुलना करें।
| फीचर | अस्पष्ट (बचें) | परीक्षण योग्य (उपयोग करें) |
|---|---|---|
| खोज | खोज तेज होनी चाहिए। | 100 आइटम के लिए खोज परिणाम 2 सेकंड से कम समय में प्रदर्शित होते हैं। |
| लॉगिन | उपयोगकर्ता लॉगिन कर सकता है। | उपयोगकर्ता मान्य प्रमाण पत्र दर्ज करता है और सबमिट पर क्लिक करता है; डैशबोर्ड लोड होता है। अमान्य प्रमाण पत्र एक त्रुटि संदेश दिखाते हैं। |
| निर्यात | डेटा को PDF में निर्यात करें। | प्रणाली वर्तमान तालिका दृश्य वाला एक PDF फ़ाइल उत्पन्न करती है। अनुरोध पर फ़ाइल स्वचालित रूप से डाउनलोड होती है। |
कॉलम में अंतर का ध्यान दें।परीक्षण योग्य कॉलम में विशिष्ट शर्तों, अपेक्षित परिणामों और मापन योग्य मापदंडों को शामिल किया गया है। शब्द तेज व्यक्तिगत रूप से निर्भर है। 2 सेकंड वस्तुनिष्ठ है।
स्वीकृति मानदंड के प्रकार
अलग-अलग कहानियों को अलग-अलग प्रकार के मानदंडों की आवश्यकता होती है। हर आइटम पर एक ही प्रारूप लागू करने की कोशिश न करें।
- व्यापार नियम: विशिष्ट तर्क या गणनाएं। (उदाहरण के लिए, $50 से अधिक के आदेशों पर कर 10% है)।
- UI व्यवहार: इंटरफेस कैसे प्रतिक्रिया करता है। (उदाहरण के लिए, सफलता पर बटन हरा हो जाता है)।
- प्रदर्शन: गति या लोड सीमाएँ। (उदाहरण के लिए, पृष्ठ 1 सेकंड में लोड होता है)।
- त्रुटि संभाल: जब चीजें गलत हो जाती हैं तो क्या होता है। (उदाहरण के लिए, त्रुटि कोड 404 प्रदर्शित करना)।
- सुरक्षा: पहुँच नियंत्रण की आवश्यकताएँ। (उदाहरण के लिए, केवल प्रशासक ही रिकॉर्ड हटा सकता है)।
Gherkin सिंटैक्स संरचना 📋
जटिल तर्क के लिए, संरचित प्रारूप मदद करता है।Gherkin व्यवहार का वर्णन करने का एक भाषा-अनाड़ी तरीका है। इसमें स्थितियों को परिभाषित करने के लिए साधारण पाठ का उपयोग किया जाता है। इससे तकनीकी रूप से अपरिचित स्टेकहोल्डर्स के लिए इसे पढ़ना आसान हो जाता है।
संरचना तीन मुख्य कीवर्ड्स का पालन करती है:
- दिया गया: प्रारंभिक संदर्भ या स्थिति।
- जब: वह क्रिया या घटना जो होती है।
- तब: अपेक्षित परिणाम या परिणाम।
इस संरचना के कारण लेखक को प्रवाह के बारे में सोचने के लिए मजबूर किया जाता है। यह चरणों को छोड़ने से बचाता है। इसके अलावा यह स्वचालित परीक्षण ढांचों के साथ मेल खाता है।
उदाहरण परिदृश्य
एक पासवर्ड रीसेट के बारे में कहानी की कल्पना करें। यह Gherkin प्रारूप में कैसे दिख सकता है, इसका उदाहरण नीचे दिया गया है:
विशेषता: पासवर्ड रीसेट परिदृश्य: उपयोगकर्ता द्वारा पासवर्ड रीसेट का अनुरोध दिया गया कि उपयोगकर्ता लॉगिन पेज पर है जब उपयोगकर्ता "पासवर्ड भूल गए" लिंक पर क्लिक करता है तब प्रणाली उनके पंजीकृत पते पर रीसेट ईमेल भेजती है परिदृश्य: उपयोगकर्ता एक अमान्य ईमेल दर्ज करता है दिया गया कि उपयोगकर्ता लॉगिन पेज पर है जब उपयोगकर्ता "पासवर्ड भूल गए" लिंक पर क्लिक करता है और एक ईमेल दर्ज करता है जो मौजूद नहीं है तब प्रणाली एक सामान्य सफलता संदेश प्रदर्शित करती है
इस प्रारूप से अस्पष्टता दूर हो जाती है। यह बिल्कुल स्पष्ट करता है कि कौन सा इनपुट किस आउटपुट के लिए जिम्मेदार है। यह एक साथ दस्तावेज़ीकरण और परीक्षण केस के रूप में कार्य करता है।
सहयोग महत्वपूर्ण है 🤝
अकेले कहानी लिखने से अक्सर खामियाँ आती हैं। सर्वश्रेष्ठ कहानियाँ सहयोग से आती हैं। इसमें उत्पाद मालिक, विकासकर्ता और परीक्षकों को एक साथ लाना शामिल होता है।
तीन दोस्त
यह अनौपचारिक शब्द कहानी को बेहतर बनाने में शामिल तीन भूमिकाओं के संदर्भ में आता है। वे विकास शुरू होने से पहले मिलते हैं।
- उत्पाद मालिक: मूल्य और व्यापार नियमों को परिभाषित करता है।
- विकासकर्ता: तकनीकी सीमाओं और कार्यान्वयन विवरणों को पहचानता है।
- परीक्षण कर्मी: सीमा मामलों और संभावित विफलता बिंदुओं को पहचानता है।
इस सत्र के दौरान, वे ड्राफ्ट कहानी की समीक्षा करते हैं। वे प्रश्न पूछते हैं। वे मान्यताओं को चुनौती देते हैं। वे स्वीकृति मानदंडों को एक साथ सुधारते हैं। इस प्रक्रिया को अक्सर कहा जाता हैबैकलॉग सुधार या कहानी गोद लेना.
पूछने योग्य प्रश्न
सुधार के दौरान, छिपी हुई जटिलता को उजागर करने के लिए इन प्रश्नों को पूछें:
- अगर इस क्रिया के दौरान नेटवर्क विफल हो जाए तो क्या होगा?
- यह फीचर मोबाइल उपकरण पर कैसे व्यवहार करता है?
- क्या विचार करने योग्य कोई डेटा गोपनीयता नियम हैं?
- अगर बाहरी सेवा उपलब्ध नहीं है तो फॉलबैक क्या है?
- क्या इस बदलाव का मौजूदा डेटा या रिपोर्ट्स पर प्रभाव पड़ता है?
इन प्रश्नों के जल्दी उत्तर देने से बाद में आश्चर्य होने से बचा जा सकता है। यह साझा समझ के निर्माण में मदद करता है।
बचने योग्य सामान्य गलतियाँ 🕳️
यहां तक कि अनुभवी टीमें भी गलतियां करती हैं। सामान्य जालों के बारे में जागरूकता आपको उनसे दूर रहने में मदद करती है।
1. समाधान कथन
समाधान का वर्णन करने वाली कहानियां न लिखें। एक कहानी में समस्या या आवश्यकता का वर्णन होना चाहिए। समाधान का निर्णय विकास के दौरान टीम द्वारा किया जाता है।
बुरा: “एक बटन जो एक्सेल में निर्यात करे।”
अच्छा: “एक प्रबंधक के रूप में, मुझे अपने डेटा को निर्यात करने की आवश्यकता है ताकि मैं ऑफलाइन विश्लेषण कर सकूं।”
2. कहानियों के रूप में तकनीकी कार्य
रिफैक्टरिंग या इंफ्रास्ट्रक्चर कार्य एक उपयोगकर्ता कहानी नहीं है। यह तकनीकी ऋण या रखरखाव है। हालांकि महत्वपूर्ण है, लेकिन इसी तरह सीधे उपयोगकर्ता मूल्य नहीं देता है। इन्हें अलग से ट्रैक करें।
3. गैर-क्रियात्मक आवश्यकताओं को नजरअंदाज करना
प्रदर्शन, सुरक्षा और एक्सेसिबिलिटी वैकल्पिक नहीं हैं। उन्हें स्वीकृति मानदंडों में शामिल किया जाना चाहिए। न मानें कि सिस्टम डिफॉल्ट रूप से सुरक्षित है।
4. बहुत अधिक स्वीकृति मानदंड
अगर एक कहानी में 50 स्वीकृति मानदंड हैं, तो यह लगभग बहुत बड़ा है। कहानी को बांटें। सबसे पहले मूल मूल्य पर ध्यान केंद्रित करें। इटरेशन में जटिलता जोड़ें।
गुणवत्ता का मापन 📏
आप कैसे जानते हैं कि आपकी कहानियाँ बेहतर हो रही हैं? आपको मापदंडों की आवश्यकता है। समय के साथ इन संकेतकों को ट्रैक करें।
- दोष दर: क्या परीक्षण में पाए जाने वाले बग कम हो रहे हैं? यदि स्वीकृति मानदंड स्पष्ट हैं, तो कम बग छूट जाते हैं।
- अस्वीकृति दर: समीक्षा के दौरान कहानी कितनी बार वापस लौटाई जाती है? उच्च अस्वीकृति स्पष्ट नहीं मानदंडों को इंगित करती है।
- वेग स्थिरता: क्या टीम सही अनुमान लगाती है? स्पष्ट कहानियाँ बेहतर अनुमानों की ओर जाती हैं।
- स्वचालन कवरेज: क्या आप स्वीकृति मानदंडों को स्वचालित कर सकते हैं? उच्च कवरेज परीक्षण योग्य कहानियों को इंगित करती है।
रिट्रोस्पेक्टिव में इन मापदंडों की समीक्षा करें। यह चर्चा करें कि क्या काम कर रहा था और क्या नहीं। अपनी प्रक्रिया को अनुकूलित करें। निरंतर सुधार लक्ष्य है।
वास्तविक दुनिया के परिदृश्य 🌍
आइए देखें कि इसका अन्य संदर्भों में कैसे अनुप्रयोग होता है। सिद्धांत वही रहते हैं, लेकिन विवरण बदलते हैं।
परिदृश्य A: ई-कॉमर्स चेकआउट
यह एक महत्वपूर्ण प्रवाह है। त्रुटियाँ महंगी होती हैं। कहानियों को हर चरण को कवर करना चाहिए।
- कहानी: छूट कोड लागू करें।
- मानदंड:
- प्रणाली कोड के फॉर्मेट की पुष्टि करती है।
- प्रणाली कोड की समाप्ति तिथि की जांच करती है।
- प्रणाली नए कुल मूल्य की गणना करती है।
- यदि कोड अमान्य है, तो प्रणाली त्रुटि प्रदर्शित करती है।
- प्रणाली समाप्त कोड के पुनर्उपयोग को रोकती है।
परिदृश्य B: रिपोर्टिंग डैशबोर्ड
यहाँ डेटा सटीकता सर्वोच्च महत्व की है।
- कहानी: तारीख की सीमा द्वारा रिपोर्ट्स को फ़िल्टर करें।
- मानदंड:
- प्रणाली अंतिम 30 दिनों के लिए डिफ़ॉल्ट होती है।
- प्रणाली कस्टम शुरुआत और समाप्ति तिथियों की अनुमति देती है।
- प्रणाली चयनित सीमा के बाहर के डेटा को बाहर रखती है।
- सिस्टम सप्ताहांत और छुट्टियों को सही तरीके से संभालता है।
परिदृश्य C: उपयोगकर्ता प्रोफ़ाइल प्रबंधन
सुरक्षा और डेटा अखंडता महत्वपूर्ण हैं।
- कहानी:प्रोफ़ाइल छवि अपडेट करें।
- मानदंड:
- सिस्टम JPG और PNG प्रारूप स्वीकार करता है।
- सिस्टम फ़ाइल के आकार को 5MB तक सीमित करता है।
- सिस्टम ग्रिड दृश्य में थंबनेल प्रदर्शित करता है।
- सिस्टम स्टोरेज से पुरानी छवियाँ हटा देता है।
काम पूरा होने की परिभाषा 🛑
स्वीकृति मानदंड विशिष्ट कहानी को परिभाषित करते हैं। दकाम पूरा होने की परिभाषा प्रोजेक्ट की सभी कहानियों पर लागू होती है। यह गुणवत्ता के लिए हमेशा सक्रिय चेकलिस्ट है।
एक कहानी पूरी नहीं होती जब तक कि:
- कोड लिखा गया है।
- कोड की समीक्षा की गई है।
- परीक्षण पास हो रहे हैं।
- दस्तावेज़ीकरण अपडेट किया गया है।
- प्रदर्शन मानदंड पूरे हो गए हैं।
- सुरक्षा स्कैन साफ है।
यह सुनिश्चित करता है कि सुसंगतता बनी रहे। यह तकनीकी देनदारी बढ़ने से रोकता है। यह गारंटी देता है कि हर कहानी जो डिलीवर की जाती है, उपयोगी होती है।
पुनरावृत्तिक सुधार 🔄
कहानियाँ स्थिर नहीं होती हैं। वे विकसित होती हैं। जैसे-जैसे आप सिस्टम के बारे में अधिक जानते हैं, आपको उन्हें अपडेट करने की आवश्यकता हो सकती है। यह विफलता नहीं है; यह प्रक्रिया का हिस्सा है।
बैकलॉग तैयार रखें। कहानियों को नियमित रूप से सुधारें। स्प्रिंट शुरू होने तक प्रश्न पूछने का इंतजार न करें। स्पष्टीकरण करने का सबसे अच्छा समय शुरुआत है। जैसे-जैसे आप कोड के करीब आते हैं, बदलाव की लागत घातीय रूप से बढ़ती है।
सर्वोत्तम प्रथाओं का सारांश ✅
अस्पष्ट से परीक्षण योग्य तक के यात्रा को समाप्त करने के लिए, इन मुख्य बिंदुओं को याद रखें।
- मूल्य पर ध्यान केंद्रित करें: हमेशा उपयोगकर्ता की आवश्यकता से जुड़ें।
- विशिष्ट बनें: संख्याओं और स्पष्ट शर्तों का उपयोग करें।
- सहयोग करें:सुधार में सभी भूमिकाओं को शामिल करें।
- सत्यापित करें:सुनिश्चित करें कि प्रत्येक कहानी का परीक्षण किया जा सके।
- पुनरावृत्ति करें:प्रतिक्रिया के आधार पर कहानियों में सुधार करें।
इस मानसिकता को अपनाने से टीम के काम करने के तरीके में बदलाव आता है। यह विश्वास बनाता है। यह गति में सुधार करता है। यह ऐसे सॉफ्टवेयर के निर्माण को निश्चित करता है जो उपयोग करने वाले लोगों के लिए वास्तव में काम करता है।
