31 दिस॰ 2025·8 मिनट
प्रॉम्प्ट से स्वीकृति परीक्षण: फीचर को परिदृश्यों में बदलें
हर फीचर प्रॉम्प्ट को 5–10 स्पष्ट परिदृश्यों में बदलकर हैप्पी पाथ और एज केस कवर करना सीखें — बिना भारी टेस्ट सूइट के।
हर फीचर प्रॉम्प्ट को 5–10 स्पष्ट परिदृश्यों में बदलकर हैप्पी पाथ और एज केस कवर करना सीखें — बिना भारी टेस्ट सूइट के।
चैट-शैली के फीचर प्रॉम्प्ट बातचीत की तरह साफ़ दिखते हैं। पर ये अक्सर चुनौतियाँ, नियम और अपवाद कुछ ही दोस्ताना वाक्यों में समेट लेते हैं। जब तक कोई फीचर असल में उपयोग नहीं करता, ये गैप नजर नहीं आते।
ज़्यादातर प्रॉम्प्ट निश्चय पर भरोसा करते हैं: किसे यह कार्रवाई करने की अनुमति है, किसे “सफलता” माना जाए (सहेजा गया, भेजा गया, प्रकाशित, भुगतान हुआ), जब डेटा गायब हो तो क्या होता है, और कुछ फेल होने पर उपयोगकर्ता को क्या दिखना चाहिए। ये अस्पष्ट मानक भी छुपाते हैं — जैसे "पर्याप्त तेज" या "पर्याप्त सुरक्षित" का क्या मतलब है।
अस्पष्टता अक्सर बाद में बग और रीवर्क के रूप में सामने आती है। एक डेवलपर वही बनाता है जो उसे प्रॉम्प्ट का मतलब लगता है, एक रिव्यूर उसे सही मान लेता है क्योंकि वह ठीक दिखता है, और फिर उपयोगकर्ता अजीब मामलों पर ठोकर खाते हैं: डुप्लीकेट सबमिशन, टाइमज़ोन, आंशिक डेटा, या परमिशन असंगतियाँ। बाद में इन्हें ठीक करने की लागत ज़्यादा होती है क्योंकि यह अक्सर कोड, UI टेक्स्ट, और कभी-कभी डेटा मॉडल को छूता है।
गुणवत्ता के लिए बड़ी टेस्ट सूइट्स ज़रूरी नहीं हैं। इसका मतलब है कि आप सामान्य उपयोग और अनुमानित दबाव में फीचर पर भरोसा कर सकते हैं। कुछ चुने हुए परिदृश्यों का छोटा सेट आपको बिना सैकड़ों टेस्ट के यह भरोसा देता है।
प्रैक्टिकल गुणवत्ता की परिभाषा जब प्रॉम्प्ट से बनाया गया फीचर हो:
यही कारण है कि प्रॉम्प्ट को स्वीकृति परिदृश्यों में बदलना महत्वपूर्ण है: एक अस्पष्ट अनुरोध लें और उसे 5–10 जाँचों में बदल दें जो छुपे नियमों को पहले ही उजागर कर दें। आप सब कुछ परीक्षण करने की कोशिश नहीं कर रहे — आप उन विफलताओं को पकड़ना चाहते हैं जो असल में होती हैं।
यदि आप Koder.ai जैसे वाइब-कोडिंग टूल में एक त्वरित प्रॉम्प्ट से बनाते हैं, तो आउटपुट पूरा दिख सकता है जबकि एज नियम छूट सकते हैं। एक कसा हुआ परिदृश्य सेट उन नियमों को नाम देने को मजबूर करता है जब परिवर्तन अभी सस्ते हों।
एक स्वीकृति परीक्षण परिदृश्य उपयोगकर्ता क्रिया और परिणाम का छोटा, सामान्य-भाषा विवरण है जो उन्हें दिखना चाहिए।
सतह पर बने रहें: उपयोगकर्ता क्या कर सकता है, और प्रोडक्ट क्या दिखाता या बदलता है। आंतरिक विवरण जैसे डेटाबेस टेबल, API कॉल, बैकग्राउंड जॉब्स, या किस फ्रेमवर्क का उपयोग हुआ, इससे बचें। ये विवरण बाद में मायने रख सकते हैं, पर वे परिदृश्यों को नाज़ुक और सहमत होने में मुश्किल बनाते हैं।
एक अच्छा परिदृश्य स्वतंत्र भी होता है। इसे कल साफ़ एनवायरनमेंट पर चलाना आसान होना चाहिए, बिना यह निर्भर किए कि कोई और परिदृश्य पहले चला हो। अगर कोई परिदृश्य पूर्व स्थिति पर निर्भर करता है, तो सेटअप में इसे स्पष्ट रूप से बताइए (उदाहरण: “उपयोगकर्ता के पास पहले से सक्रिय सब्सक्रिप्शन है”)।
कई टीमें Given–When–Then का उपयोग करती हैं क्योंकि यह स्पष्टता पर मजबूर करता है बिना परिदृश्यों को पूरा स्पेसिफ़िकेशन बना दिए।
एक परिदृश्य आमतौर पर “पूरा” माना जाता है जब उसमें एक लक्ष्य हो, एक स्पष्ट शुरुआती स्थिति हो, एक ठोस कार्रवाई हो, और एक दिखाई देने वाला परिणाम हो। यह बाइनरी होना चाहिए: टीम का कोई भी सदस्य इसे चलाकर “पास” या “फेल” कह सके।
उदाहरण: “Given एक साइन-इन किया उपयोगकर्ता जिसके पास कोई सहेजी हुई पेमेंट विधि नहीं है, जब वह Pro चुनता है और भुगतान की पुष्टि करता है, तब वह सफलता संदेश देखता है और उसका अकाउंट में प्लान Pro दिखता है।”
यदि आप Koder.ai जैसे चैट-फर्स्ट बिल्डर में बना रहे हैं, तो वही नियम रखें: जनरेट किए गए ऐप के व्यवहार का परीक्षण करें (उपयोगकर्ता क्या अनुभव करता है), न कि प्लेटफ़ॉर्म ने कैसे कोड बनाया।
सबसे अच्छा फ़ॉर्मैट वही है जिसे लोग लिखेंगे और पढ़ेंगे। अगर आधी टीम लम्बी कथाएँ लिखती है और दूसरी आधी संक्षेप बुलेट्स, तो आपको गैप, डुप्लिकेट और शब्दों पर तर्क मिलेंगे न कि गुणवत्ता पर।
Given–When–Then तब अच्छा है जब फीचर इंटरैक्टिव और स्टेटफुल हो। जब आपके पास इनपुट-आउटपुट नियम और कई समान केस हों, तो एक सरल तालिका स्कैन करने में आसान रहती है।
अगर आपकी टीम बंटी हुई है, तो 30 दिनों के लिए एक फ़ॉर्मैट चुनें और फिर समायोजित करें। अगर रिव्यूअर बार-बार पूछ रहे हैं “सफलता क्या दिखती है?”, तो यह आमतौर पर Given–When–Then की ओर बढ़ने का संकेत है। अगर परिदृश्य शब्दबद्ध हो रहे हैं, तो तालिका बेहतर हो सकती है।
जो कुछ भी आप चुनें, उसे मानकीकृत रखें। वही हेडिंग, वही काल, और वही विवरण स्तर बनाए रखें। यह भी सहमत हों कि क्या शामिल नहीं करना है: पिक्सेल-परफेक्ट UI विवरण, इम्प्लीमेंटेशन, और डेटाबेस चर्चा। परिदृश्य यह बताने चाहिए कि उपयोगकर्ता क्या देखता है और सिस्टम क्या गारंटी देता है।
परिदृश्यों को वहीँ रखें जहाँ काम पहले से होता है और उन्हें फीचर के करीब रखें।
आम विकल्पों में शामिल हैं: उत्पाद कोड के बगल में रखना, टिकटों में “Acceptance scenarios” सेक्शन के अन्तर्गत रखना, या साझा डॉक्स में प्रति-फ़ीचर एक पेज रखना। यदि आप Koder.ai का उपयोग कर रहे हैं, तो आप Planning Mode में भी परिदृश्यों को रख सकते हैं ताकि वे बिल्ड इतिहास के साथ स्नैपशॉट और रोलबैक पॉइंट्स के साथ रहें।
कुंजी यह है कि वे searchable हों, एक स्रोत-ए-ट्रूथ रहे, और विकास शुरू करने से पहले परिदृश्य जरूरी हों।
शुरू करें प्रॉम्प्ट को एक उपयोगकर्ता लक्ष्य और एक स्पष्ट समाप्ति रेखा के रूप में फिर लिखकर। एक वाक्य में लक्ष्य लिखें (कौन क्या चाहता है), फिर 2–4 सफलता मानदंड जो आप बिना बहस के सत्यापित कर सकें। अगर आप दिखाई देने योग्य परिणाम नहीं बता पा रहे, तो वह अभी टेस्ट नहीं है।
अगला, प्रॉम्प्ट को इनपुट, आउटपुट और नियमों में अलग करें। इनपुट वे हैं जो उपयोगकर्ता प्रदान करता/चुनता है। आउटपुट वे हैं जो सिस्टम दिखाता, सहेजता, भेजता, या ब्लॉक करता है। नियम वे “केवल अगर” और “ज़रूरी” बयान हैं जो पंक्तियों के बीच छिपे होते हैं।
फिर जाँचें कि फीचर काम करने से पहले किस पर निर्भर है। यही वह जगह है जहाँ परिदृश्य गैप छिपते हैं: आवश्यक डेटा, उपयोगकर्ता रोल, परमिशन, इंटीग्रेशन, और सिस्टम स्टेट। उदाहरण के लिए, अगर आप Koder.ai में एक ऐप बना रहे हैं, तो यह स्पष्ट करें कि क्या उपयोगकर्ता को लॉग इन होना चाहिए, कोई प्रोजेक्ट पहले से बना होना चाहिए, या कोई प्लान/एक्सेस शर्तें पूरी करनी होंगी।
अब सबसे छोटे सेट परिदृश्यों को लिखें जो यह साबित करते हैं कि फीचर काम करता है: आमतौर पर 1–2 हैप्पी पाथ और फिर 4–8 एज केस। हर परिदृश्य को एक कारण पर फोकस रखें जिसकी वजह से यह असफल हो सकता है।
अच्छे एज केस जो चुनने लायक हैं (केवल वही जो प्रॉम्प्ट से फिट हो): गायब या अमान्य इनपुट, परमिशन असंगति, “पहले ही सबमिट” जैसे स्टेट संघर्ष, बाहरी निर्भरता मुद्दे जैसे टाइमआउट, और रिकवरी व्यवहार (स्पष्ट त्रुटियाँ, सुरक्षित रीट्राय, कोई आंशिक सहेज नहीं)।
अंत में एक त्वरित “क्या गलत हो सकता है?” पास करें। चुप्पी से होने वाली विफलताओं, भ्रमित करने वाले संदेशों, और ऐसे स्थानों की तलाश करें जहाँ सिस्टम गलत डेटा बना सकता है।
हैप्पी पाथ परिदृश्य सबसे छोटा, सामान्य मार्ग है जहाँ सब कुछ सही होता है। अगर आप इसे जानबूझकर उबाऊ रखते हैं, तो यह एक भरोसेमंद बेसलाइन बन जाता है जो बाद में एज केसों को पहचानना आसान कर देता है।
डिफ़ॉल्ट उपयोगकर्ता और डिफ़ॉल्ट डेटा नाम दें। “यूनिवर्सल उपयोगकर्ता” कहने के बजाय वास्तविक भूमिका का उपयोग करें: “साइन-इन किया ग्राहक, सत्यापित ईमेल” या “बिलिंग एडिट करने की अनुमति वाला एडमिन।” फिर सबसे छोटा सैंपल डेटा परिभाषित करें जो समझ में आए: एक प्रोजेक्ट, सूची में एक आइटम, एक सहेजी हुई पेमेंट विधि। इससे परिदृश्य ठोस रहते हैं और छुपी मान्यताएँ कम होती हैं।
पहले सबसे छोटा सफ़ल-पथ लिखें। वैकल्पिक कदम और अन्य मार्ग हटाएँ। अगर फीचर "टास्क बनाएं" है, तो हैप्पी पाथ में फिल्टरिंग, सॉर्टिंग, या बनाने के बाद संपादन शामिल नहीं होना चाहिए।
एक सरल तरीका: पुष्टि करें कि चार चीज़ें हैं:
फिर एक वेरिएंट जोड़ें जो केवल एक चर बदले। सबसे संभव टूटने वाला चर चुनें, जैसे “टाइटल लंबा है” या “उपयोगकर्ता के पास पहले कोई आइटम नहीं है,” और बाकी सब कुछ समान रखें।
उदाहरण: अगर आपका प्रॉम्प्ट कहता है, “स्नैपशॉट सहेजने के बाद ‘Snapshot created’ टोस्ट जोड़ें,” तो हैप्पी पाथ यह होगा: उपयोगकर्ता Create Snapshot पर क्लिक करता है, लोडिंग स्टेट देखता है, “Snapshot created” मिलता है, और स्नैपशॉट सूची में सही टाइमस्टैम्प के साथ दिखाई देता है। एक-वैरिएंट यह हो सकता है कि नाम खाली हो और एक स्पष्ट डिफ़ॉल्ट नामकरण नियम लागू हो।
एज केस वही जगह है जहाँ अधिकांश बग छिपते हैं, और आपको उन्हें पकड़ने के लिए विशाल सूट की ज़रूरत नहीं पड़ती। हर फीचर प्रॉम्प्ट के लिए छोटे सेट चुनें जो वास्तविक व्यवहार और वास्तविक विफलता मोड दर्शाते हों।
आम श्रेणियाँ जिनमें से चुनें:
हर फीचर को हर श्रेणी की ज़रूरत नहीं होती। एक सर्च बॉक्स को इनपुट की ज्यादा चिंता होगी। एक पेमेंट फ्लो को इंटीग्रेशन और डेटा की ज्यादा चिंता होगी।
जो एज केस चुनें वे जोखिम के अनुसार हों: विफलता की उच्च लागत (पैसा, सुरक्षा, गोपनीयता), उच्च आवृत्ति, आसान टूटने वाले फ्लो, पिछले ज्ञात बग, या ऐसे मुद्दे जो बाद में पता लगना मुश्किल हों।
उदाहरण: “यूजर सब्सक्रिप्शन प्लान बदलता है” के लिए अक्सर लाभप्रद परिदृश्य होते हैं: चेकआउट पर सत्र का एक्सपायर होना, “Confirm” पर डबल-क्लिक, और पेमेंट प्रोवाइडर टाइमआउट जो प्लान को अपरिवर्तित छोड़ दे जबकि उपयोगकर्ता को स्पष्ट संदेश दिखे।
उदाहरण फीचर प्रॉम्प्ट (साधारण भाषा):
"जब मैं कुछ तोड़ता हूँ, मैं अपने ऐप को पिछले स्नैपशॉट पर रोलबैक करना चाहता हूँ ताकि आखिरी काम करने वाला वर्शन फिर से लाइव हो सके।"
नीचे एक कॉम्पैक्ट परिदृश्य सेट दिया गया है। हर परिदृश्य छोटा है, पर यह एक परिणाम पिन कर देता है।
S1 [जरूरी] सबसे हालिया स्नैपशॉट पर रोलबैक करें
Given मैं लॉगिन हूँ और मैं ऐप का मालिक हूँ
When मैं “Rollback” चुनता हूँ और पुष्टि करता/करती हूँ
Then ऐप पिछले स्नैपशॉट को तैनात करता है और ऐप स्थिति नए वर्शन को सक्रिय के रूप में दिखाती है
S2 [जरूरी] किसी विशिष्ट स्नैपशॉट पर रोलबैक करें
Given मैं अपने ऐप की स्नैपशॉट सूची देख रहा/रही हूँ
When मैं स्नैपशॉट “A” चुनता/चुनती हूँ और रोलबैक की पुष्टि करता/करती हूँ
Then स्नैपशॉट “A” सक्रिय वर्शन बन जाता है और मैं देख सकता/सकती हूँ कि इसे कब बनाया गया था
S3 [जरूरी] अनुमति नहीं (ऑथ)
Given मैं लॉगिन हूँ पर मुझे इस ऐप की पहुँच नहीं है
When मैं रोलबैक करने की कोशिश करता/करती हूँ
Then मुझे एक एक्सेस त्रुटि दिखती है और कोई रोलबैक शुरू नहीं होता
S4 [जरूरी] स्नैपशॉट नहीं मिला (मान्यकरण)
Given कोई स्नैपशॉट ID मौजूद नहीं है (या हटाया गया था)
When मैं उस पर रोलबैक करने का प्रयास करता/करती हूँ
Then मुझे स्पष्ट “snapshot not found” संदेश मिलता है
S5 [जरूरी] डबल सबमिट (डुप्लीकेट्स)
Given मैं “Confirm rollback” दो बार तेज़ी से क्लिक करता/करती हूँ
When दूसरी रिक्वेस्ट भेजी जाती है
Then केवल एक रोलबैक चलता है और मुझे एक ही परिणाम दिखता है
S6 [जरूरी] डिप्लॉयमेंट विफलता (फेल्यर)
Given रोलबैक शुरू हो चुका है
When डिप्लॉयमेंट फेल हो जाता है
Then वर्तमान सक्रिय वर्शन लाइव रहता है और त्रुटि दिखती है
S7 [अच्छा-होने-योग्य] टाइमआउट या कनेक्शन खोना
Given मेरा कनेक्शन रोलबैक के बीच में कटता है
When मैं पेज रीलोड करता/करती हूँ
Then मैं देख सकता/सकती हूँ कि रोलबैक अभी भी चल रहा है या समाप्त हो चुका है
S8 [अच्छा-होने-योग्य] पहले से वही स्नैपशॉट सक्रिय है
Given स्नैपशॉट “A” पहले से सक्रिय है
When मैं स्नैपशॉट “A” पर रोलबैक करने की कोशिश करता/करती हूँ
Then मुझे बताया जाता है कि कुछ भी नहीं बदला और कोई नया डिप्लॉयमेंट शुरू नहीं होता
हर परिदृश्य तीन सवालों का जवाब देता है: कौन कर रहा है, वे क्या करते हैं, और बाद में क्या सत्य होना चाहिए।
लक्ष्य “सब कुछ टेस्ट करना” नहीं है। लक्ष्य उन जोखिमों को कवर करना है जो उपयोगकर्ताओं को नुकसान पहुंचाएंगे, बिना ऐसे परिदृश्यों के ढेर बनाए जिन्हें कोई नहीं चलाता।
एक व्यावहारिक तरकीब यह है कि परिदृश्यों को लेबल करें कि आप उन्हें कैसे उपयोग करने की उम्मीद रखते हैं:
खुद को एक अलग जोखिम पर एक परिदृश्य तक सीमित रखें। अगर दो परिदृश्य एक ही वजह से फेल होते हैं, तो शायद आपको सिर्फ एक की ज़रूरत है। “अमान्य ईमेल फॉर्मेट” और “गायब ईमेल” अलग जोखिम हैं। पर “स्टेप 1 पर गायब ईमेल” और “स्टेप 2 पर गायब ईमेल” उसी जोखिम के दो उदाहरण हो सकते हैं अगर नियम एक जैसा है।
यह भी टालें कि कई परिदृश्यों में UI कदमों को दोहराया जाए। बार-बार हिस्सों को छोटा रखें और उस पर फोकस करें जो बदलता है। यह खासकर महत्वपूर्ण है जब आप Koder.ai जैसे चैट-आधारित टूल में बना रहे हों, क्योंकि UI बदल सकता है जबकि बिजनेस नियम वही रहता है।
अंत में तय करें कि अब क्या चेक करें बनाम बाद में। कुछ जांचें शुरुआत में मैन्युअल बेहतर होती हैं, फिर फीचर स्थिर होने पर ऑटोमेट की जा सकती हैं:
एक परिदृश्य आपको आश्चर्य से बचाना चाहिए, न कि यह बताना चाहिए कि टीम फीचर कैसे बनाएगी।
सबसे सामान्य गलती है उपयोगकर्ता लक्ष्य को टेक चेकलिस्ट में बदल देना। अगर परिदृश्य कहता है “API 200 रिटर्न करे” या “टेबल X में कॉलम Y हो,” तो यह एक डिज़ाइन लॉक करता है और फिर भी साबित नहीं करता कि उपयोगकर्ता को क्या चाहिए था।
दूसरी समस्या कई लक्ष्यों को एक लम्बे परिदृश्य में जोड़ देना है। यह पूरा जर्नी जैसा लगता है, पर जब यह फेल होता है, तो कोई नहीं जानता क्यों। एक परिदृश्य को एक सवाल का जवाब देना चाहिए।
ऐसे एज केसों से सावधान रहें जो साउंड क्लेवर हैं पर असल में रेअल नहीं। “उपयोगकर्ता के पास 10 मिलियन प्रोजेक्ट हैं” या “नेटवर्क हर 2 सेकंड पर ड्रॉप होता है” आमतौर पर प्रोडक्शन से मेल नहीं खाते और पुन:उत्पादन कठिन होता है। ऐसे एज केस चुनें जिन्हें आप मिनटों में सेट कर सकें।
अस्पष्ट परिणामों से भी बचें जैसे “काम करता है”, “कोई त्रুটি नहीं”, या “सफलता से पूरा हुआ।” ये शब्द बताए बिना छिपे हुए परिणाम होते हैं जिन्हें आप सत्यापित करना चाहिए।
अगर आप Koder.ai की “स्रोत कोड निर्यात करें” जैसी चीज बना रहे हैं, तो एक कमजोर परिदृश्य होगा: “जब उपयोगकर्ता एक्सपोर्ट पर क्लिक करे, सिस्टम रेपो को ज़िप करे और 200 लौटाए।” यह इम्प्लिमेंटेशन का परीक्षण करता है, न कि वादा।
एक बेहतर परिदृश्य होगा: “Given एक प्रोजेक्ट जिसमें दो स्नैपशॉट हों, जब उपयोगकर्ता एक्सपोर्ट करे, तब डाउनलोड में करंट स्नैपशॉट का कोड हो और एक्सपोर्ट लॉग रिकॉर्ड करे कि किसने और कब एक्सपोर्ट किया।”
"नहीं" पाथ मत भूलें: “Given बिना एक्सपोर्ट अनुमति वाला उपयोगकर्ता, जब वे एक्सपोर्ट करने की कोशिश करें, तब विकल्प छुपा हो या ब्लॉक हो, और कोई एक्सपोर्ट रिकॉर्ड न बने।” एक लाइन सुरक्षा और डेटा इंटीग्रिटी दोनों को सुरक्षित कर सकती है।
परिदृश्य सेट को “डन” मानने से पहले, इसे एक सख्त उपयोगकर्ता और डेटाबेस की तरह पढ़ें। अगर आप नहीं बता पा रहे कि टेस्ट से पहले क्या होना चाहिए या “सफलता” कैसा दिखती है, तो यह तैयार नहीं है।
एक अच्छा सेट छोटा पर स्पष्ट होता है। आप इसे किसी ऐसे व्यक्ति को दे सकें जिन्होंने फीचर नहीं लिखा और वही परिणाम पाएं जो लेखक ने सोचा था।
इस त्वरित पास का उपयोग करें परिदृश्यों को मंजूर (या वापस भेजने) के पहले:
यदि आप चैट-आधारित बिल्डर जैसे Koder.ai में परिदृय बना रहे हैं, तो वही मानक लागू करें: "काम की तरह" कोई अस्पष्ट "जैसा अपेक्षित" स्वीकार न करें। दिस्क्राइब किए बिना निरीक्षित आउटपुट और सहेजे गए बदलावों की माँग करें, और केवल वही मंजूर करें जिसे आप सत्यापित कर सकें।
परिदृश्य लेखन को एक सटीक चरण बनाएं, न कि अंत में होने वाला क्लीन-अप टास्क।
कार्यान्वयन शुरू होने से पहले परिदृश्य लिखें, जब फीचर अभी सस्ता बदलने योग्य हो। इससे टीम को शुरुआती मुश्किल सवालों का जवाब देना पड़ता है: “सफलता” का क्या मतलब है, खराब इनपुट पर क्या होता है, और अभी किन चीज़ों का समर्थन नहीं करेंगे।
परिदृश्यों को "किया हुआ" की साझा परिभाषा बनाएं। प्रोडक्ट इरादा मालिक हो, QA जोखिम सोचे, और इंजीनियरिंग व्यवहार्यता देखे। जब तीनों एक ही परिदृश्य सेट पढ़कर सहमत हों, तो आप कुछ ऐसा शिप करने से बच सकते हैं जो "मुकम्मल" दिखे पर स्वीकार्य न हो।
एक वर्कफ़्लो जो अधिकांश टीमों में टिकता है:
यदि आप Koder.ai (Koder.ai) में बना रहे हैं, तो पहले परिदृश्यों का ड्राफ्ट करना और फिर Planning Mode का उपयोग करना मदद कर सकता है कि आप हर परिदृश्य को स्क्रीन, डेटा नियम, और उपयोगकर्ता-देखे जाने वाले परिणामों के साथ मैप कर लें इससे पहले कि आप कोड जनरेट या एडिट करें।
जोखिम भरे बदलावों के लिए, शुरू करने से पहले स्नैपशॉट लें। अगर कोई नया एज केस काम करने वाले फ्लो को तोड़ता है, तो रोलबैक आपको एक दिन के उलझन में नहीं फँसने देगा।
परिदृश्यों को फीचर अनुरोध के पास रखें (या उसी टिकट के अंदर) और उन्हें वर्शन वाले आवश्यकताओं की तरह ट्रीट करें। जब प्रॉम्प्ट विकसित होते हैं, परिदृश्य सेट को भी विकसित करें, वरना आपका "किया हुआ" चुपचाप बदल जाएगा।
पहले एक एक वाक्य लिखकर शुरू करें जो उपयोगकर्ता का लक्ष्य और समाप्ति रेखा बताता हो।
फिर प्रॉम्प्ट को तीन हिस्सों में बाँटें:
अब 1–2 हैप्पी पाथ और 4–8 ऐसे एज केस लिखें जो वास्तविक जोखिमों से मेल खाते हों (परमिशन, डुप्लीकेट, टाइमआउट, गायब डेटा)।
क्योंकि प्रॉम्प्ट धारणा छुपाते हैं। एक प्रॉम्प्ट “सहेजें” कह सकता है, पर यह परिभाषित नहीं करता कि वह ड्राफ्ट बनाना है या प्रकाशित करना है, विफलता पर क्या होता है, या किसे अनुमति है।
परिदृश्य आपको जल्दी नियम नामित करने पर मजबूर करते हैं, ताकि आप डुप्लीकेट सबमिशन, परमिशन असंगतियाँ, या अनियमित परिणाम जैसे बग शिप करने से पहले पकड़ लें।
जब फीचर में राज्य और इंटरैक्शन होता है, तब Given–When–Then अच्छा रहता है।
जब आपके पास बहुत सारी समान इनपुट-आउटपुट जाँचें हों, तो एक सरल तालिका बेहतर होती है।
एक महीने के लिए एक फ़ॉर्मेट चुनें और उसे स्टैंडर्ड बनाएं (एक ही काल, एक ही विवरण स्तर)। सबसे अच्छा फ़ॉर्मेट वही है जिसे आपकी टीम वाकई में उपयोग करेगी।
एक अच्छा परिदृश्य:
यह तब “पूर्ण” माना जाता है जब कोई भी इसे चलाकर नतीजे पर बिना बहस के सहमत हो सके।
व्यवहार्य चीज़ों पर ध्यान दें:
टालें: इम्प्लीमेंटेशन विवरण जैसे डेटाबेस टेबल, API कोड, बैकग्राउंड जॉब्स, या फ्रेमवर्क। ये अक्सर बदलते हैं और उपयोगकर्ता को दिखने वाला परिणाम साबित नहीं करते।
सबसे सामान्य, सबसे बोरिंग नॉर्मल पाथ लिखें जहाँ सब कुछ सही होता है:
फिर चार चीज़ें सत्यापित करें: सही स्क्रीन/स्टेट, स्पष्ट सफलता संदेश, डेटा सहेजा गया, और उपयोगकर्ता आगे बढ़ सके।
पहले उस जोखिम और फ्रीक्वेंसी के आधार पर एज केस चुनें:
लक्ष्य रखें: हर अलग जोखिम के लिए एक परिदृश्य, हर छोटी विविधता के लिए नहीं।
सुरक्षित और स्पष्ट रखें:
एक फेल्यर परिदृश्य यह साबित करे कि सिस्टम डेटा को खराब या उपयोगकर्ता को गुमराह नहीं करता।
Koder.ai के आउटपुट को किसी भी अन्य ऐप की तरह टेस्ट करें: उपयोगकर्ता क्या अनुभव करता है, यह न कि कोड कैसे जनरेट हुआ।
व्यवहारिक तरीका:
उन्हें वहीं रखें जहाँ काम पहले से होता है और एक स्रोत-ए-ट्रूथ बनाए रखें:
अगर आप Koder.ai का उपयोग करते हैं, तो Planning Mode में परिदृश्य रखें ताकि वे बिल्ड इतिहास से जुड़े रहें। सबसे ज़रूरी: विकास शुरू होने से पहले परिदृश्य अनिवार्य करें।