कार्य औचित्य पैटर्न और एंटीपैटर्न

सामग्री

• 1. एंटीपार्टर्न: गरीब तर्क
  
  • 1.1। स्पष्ट रूप से एक ही
  • 1.2। मम्मी की कसम!
  • 1.3। बन्नी नाराज हैं
• 2. अच्छा औचित्य पैटर्न
  
  • 2.1। Pruflink
    
    • आवश्यकताओं के लिए लिंक
    • आवश्यकताएं स्वयं
    • इंटरनेट लिंक
    • ग्राहक पत्र
    • लागत पर लाभ
    • आंकड़े
  • 2.2। वर्दी
  • 2.3। समस्या, या # जीवन पीड़ा
• 3. जब औचित्य की आवश्यकता नहीं है
• 4. सारांश

जब आप कोई कार्य शुरू करते हैं, तो इसे उचित ठहराया जाना चाहिए। आपको डेवलपर को यह समझाना होगा कि:

• यह वास्तव में एक बग है;
• इसे ठीक करने की आवश्यकता है;
• जैसा कि हमने कहा, इसे ठीक करने की आवश्यकता है।

और कभी-कभी आप कीड़े पढ़ते हैं (विशेषकर शुरुआती लोगों के कीड़े) और खुद से पूछें:

- यह बग क्यों है ??

उदाहरण के लिए, यह कहता है: “रिपोर्ट डाउनलोड करें, हमें 57.6 मिलते हैं। और यह होना चाहिए - 57.9 ”।



तर्क लिखने से समस्याओं का समाधान होगा:

• सहकर्मी सवालों से विचलित होते हैं "यह एक बग क्यों है?", इसे संदर्भ से बाहर ले जाना।
• एक महीने बाद, आप खुद को भूल गए, लेकिन वास्तव में, यह एक बग क्यों था ...

यह भी देखें:
बग में औचित्य की आवश्यकता क्यों है - सामान्य रूप में, औचित्य के बारे में अधिक विस्तार से।

सैकड़ों शुरुआती परीक्षक (छात्र) मेरे पास से गुजरे। यह उनके कार्यों पर ठीक था कि मैंने सवाल पूछना शुरू किया "यह एक बग क्यों है?" ... आप लोगों से पूछते हैं, और बदले में आपको "हां, यह स्पष्ट है!"। खैर, किसी तरह बहुत =) नहीं)

कार्यों और सवालों के एक समूह के माध्यम से, "क्यों?" प्रतिक्रियाओं के पैटर्न उभरने लगे। मैंने अच्छे और बुरे पैटर्न पर प्रकाश डाला। मैं उनके बारे में बात करना चाहता हूं।

यह लेख इस प्रकार है:

• शुरुआती परीक्षक - अपनी बात को सही ढंग से समझाने का तरीका जानें;
• परीक्षण प्रबंधकों - अपने Padawans के लिए एक लिंक देने के लिए और फिर अधिक विवरण के बिना एंटीपैटर्न का उल्लेख करें।

1. एंटीपार्टर्न: गरीब तर्क

1.1। स्पष्ट रूप से एक ही

परीक्षक बग में औचित्य क्यों नहीं लिखते हैं? हां, क्योंकि यह उन्हें स्पष्ट लगता है। और वे अपने विचारों को सभी पर प्रोजेक्ट करते हैं। यह मेरे लिए स्पष्ट है = यह सभी के लिए स्पष्ट है कि कुछ क्यों लिखें?

लेकिन वास्तव में ऐसा नहीं है, क्योंकि प्रत्येक व्यक्ति किसी तरह के संदर्भ में है। और जो आपके लिए स्पष्ट है वह किसी ऐसे तथ्य पर नहीं है जो किसी और के लिए स्पष्ट हो।

आइए सरल उदाहरण देखें। नीचे लिखे शब्द पढ़ें - जब आपने इसे पढ़ा तो आपने क्या सोचा था? क्या संघों के दिमाग में आया?

CASTLE

एक दरवाजे का ताला या एक विशाल पत्थर का किला?

शादी

एक शादी या एक टूटी हुई iPhone?
...

हां, ये गृहणियां हैं। लेकिन वे बहुत स्पष्ट रूप से समस्या को दिखाते हैं "यह स्पष्ट है।" आपके लिए यह स्पष्ट है कि महल एक महल है, और मेरे लिए यह महल है।

और अगर आप बग में लिखते हैं:

परिणाम
57.6

अपेक्षित परिणाम
जाहिर है, वहाँ 57.9 होना चाहिए

मेरे सवाल का जवाब नहीं है "क्यों?" "स्पष्ट" का क्या अर्थ है? कृपया मुझे समझाएं। यह मेरे लिए स्पष्ट नहीं है, अन्यथा मैं फिर से नहीं पूछता। लेकिन लेखक स्पष्ट है और वह सोचता है कि हर कोई भी।



यदि हम शुरुआती लोगों के अनुभव के बारे में बात करते हैं, तो मेरे छात्रों में से एक ने इस विचार को सबसे अच्छा रूप दिया:

"मुझे समझ में नहीं आया कि मैं बग को कैसे सही ठहरा सकता हूं, जब तक कि मैं अन्य छात्रों के बग को नहीं पढ़ता"

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

और सिर्फ दूसरे लोगों के कीड़े को पढ़ते हुए, आप सोचने लगते हैं, "हम्म, वह ऐसा क्यों सोचता है? मैंने अलग तरह से सोचा। ” यह तब है कि समझ आती है कि आपका "स्पष्ट" हर किसी के लिए स्पष्ट नहीं है।

एक बार जब मैं बग ट्रैकर में गया और एक छात्र से इस तरह के बग को देखा: “हम श्रीपत नाम दर्ज करते हैं, इसे मर्दाना के रूप में परिभाषित किया गया है। और यह एक महिला की तरह होना चाहिए! " यह एक महिला की तरह क्यों होना चाहिए? मैं इस नाम को देखता हूं - ठीक है, श्रीपत और श्रीपत, एक आदमी की तरह दिखता है। मैं पूछता हूं:

"आपने ऐसा क्यों तय किया?" क्यों महिला?
- हां, क्योंकि मेरी पत्नी तथाकथित है!

और यह कम से कम मुझे पहले से ही समझाता है कि उसने कार्य क्यों शुरू किया। जब हम अनुप्रयोगों का परीक्षण करते हैं, तो हम सबसे पहले सरल डेटा की कोशिश करते हैं, जो चीजें हम जानते हैं। हम अपना नाम, अपनी पत्नी, भाई, बहन का नाम आज़माते हैं ...

उसने अपनी पत्नी का नाम दर्ज करने की कोशिश की और एक बग की खोज की। और अगर उसने अपेक्षित परिणाम में भी लिखा: "लिंग महिला है, तो यह एक महिला का नाम है - मेरा नाम वह है", तो कम से कम सवाल "आपको यह काम क्यों शुरू हुआ?" गायब हो जाएगा।

बेशक, ऐसा औचित्य पर्याप्त नहीं है। Google "असामान्य नाम", क्योंकि हमारे लिए अपने बेटे की बेडसाइड टेबल को नाम देना भी मना नहीं है, लेकिन क्या यह इस शब्द को सही पुरुष नाम मानने लायक है?

इसलिए यहां यह आवश्यक है कि समस्या को स्थानीय बनाने के लिए, रूसी नाम के साथ समस्या - स्थानीय नाम क्या हैं? कजाख? यूक्रेनी? लेकिन क्या सिस्टम उन्हें संसाधित करने में सक्षम होना चाहिए? और इसी तरह। शायद एक बग नहीं ...
और फिर भी, "मेरी पत्नी का नाम ऐसा है" कम से कम लेखक को अपने संदर्भ में हमें पेश करने की अनुमति देता है और बताता है कि उसने कार्य शुरू करने का फैसला क्यों किया।

और याद रखें, सबूत को संदर्भ द्वारा तय किया जा सकता है। आपने सिस्टम के बड़े मॉड्यूल का ध्यानपूर्वक अध्ययन किया है, आप सब कुछ अच्छी तरह से जानते हैं। इसलिए, यह आपके लिए पूरी तरह से स्पष्ट है कि "इस चिप को यहां काम करना चाहिए।" लेकिन अगर आप एक या दो महीने में काम पर लौटते हैं, तो आप पहले से ही एक अन्य मॉड्यूल पर काम कर रहे हैं, और यह याद रखना कि ऐसा क्यों होगा और अधिक कठिन होगा।

यहां तक ​​कि डंबेस्ट पेंसिल सबसे तेज इंटरनेट मेमोरी से तेज है

जब आप बग शुरू करते हैं, और अपेक्षित परिणाम आपको स्पष्ट लगता है, तो रुकें और सोचें: "मुझे ऐसा क्यों लगता है?"। और इस प्रश्न का उत्तर लिखिए।

1.2। मम्मी की कसम!

जब एक छात्र यह महसूस करता है कि कुछ भी नहीं लिखना, "क्योंकि यह स्पष्ट है", तो वह असफल नहीं होता है, वह क्रोध, इनकार और बग के औचित्य के अगले चरण में आगे बढ़ता है, जिसे "आई बाय शपथ माँ" कहा जाता है। ऐसा तब है जब हम सिर्फ इतना ही कहते हैं कि यह सही है, बिना यह बताए कि क्यों।



यह है, तर्क कुछ इस तरह दिखता है:

परिणाम
57.6

अपेक्षित परिणाम
57.9 क्योंकि यह सही है

लेकिन ऐसा तर्क फिर से मेरे सवाल का जवाब नहीं देता है "लेकिन क्यों?"। आपने यह क्यों तय किया कि यह कितना सही है? मैं अभी भी एक वैंग या टेलीपैथ नहीं हूं, और मुझे नहीं पता कि आपको क्यों लगता है कि यह सही है।

वास्तव में, यह स्थिति से बहुत अलग नहीं है "कुछ भी नहीं लिखा, क्योंकि यह स्पष्ट है।" इसलिए, मैं इसे दूसरा चरण कहता हूं - यह इस परिदृश्य में ठीक है कि घटनाएं आमतौर पर विकसित होती हैं, पहले "स्पष्ट रूप से", फिर "हां, तो बिल्कुल सही।" आइए छात्रों के जीवन से एक उदाहरण देखें:

पीटर और भारतीय

हमारी प्रणाली मामलों द्वारा नामों को संक्रमित करने में सक्षम है। एक छात्र पीटर नाम की जाँच करता है। क्या आप जानते हैं कि यह कैसे झुकाव है? नाममात्र मामले में, यह पत्र ई के माध्यम से लिखा गया है, और अन्य सभी में - ई के माध्यम से "पीटर, लेकिन पीटर।"

और इसलिए मैं बग ट्रैकर में जाता हूं और इस तरह के बग को पढ़ता हूं: "पीटर पत्र के माध्यम से मामलों पर झूठ बोलता है, लेकिन ई पर होना चाहिए।"

मैं पूछता हूं:

"आप ऐसा क्यों सोचते हैं?"
- खैर, यह स्पष्ट है कि ई के माध्यम से यह आवश्यक है (पहला चरण)
"आपको क्यों लगता है कि यह स्पष्ट है?"
- लेकिन यह रूसी भाषा के नियमों के अनुसार ऐसा है!
- किस नियम से?
- अच्छा, क्या मुझे रूसी भाषा के नियमों को चलाना चाहिए और उन्हें चलाना चाहिए? (दूसरा चरण - इतना सही है, मेरा विश्वास करो)
- हाँ! हां, यह वही है जो आपको करना चाहिए। क्योंकि यह बग के लिए तर्क होगा। क्योंकि हो सकता है कि आपका डेवलपर भारतीय हो और आप भी भारतीय हों। और आप रूसी भाषा के नियमों को नहीं जानते हैं! इसलिए उन्हें एक लिंक दें, और सभी प्रश्न तुरंत गायब हो जाएंगे।

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

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

लेकिन ठीक है, चलो एक और उदाहरण लेते हैं, रूसी भाषा के नियमों के बारे में नहीं, जो कि "इतना स्पष्ट है।"

Emeyl.rf

मेरे छात्रों को यह काम बहुत पसंद है (लगभग हर धारा इसे खींचती है):

- मैं ईमेल के साथ रजिस्टर करने की कोशिश कर रहा हूँ। यह एक बग है!
- क्यों?
- ऐसा क्यों? हम रूस में रहते हैं, हर किसी के पास ऐसे ईमेल हैं!

मैंने इस मामले को डीयूएमपी सम्मेलन में बताया था, और मेरे पास एक पूर्ण दर्शक कक्ष था। मैंने उन लोगों के हाथ उठाने को कहा जिनके पास ऐसा ईमेल है। 200 लोगों में से, तीन लोगों ने अपने हाथ उठाए।

तथ्य यह है कि हम रूस में रहते हैं इसका मतलब यह नहीं है कि हर किसी के पास ऐसे ईमेल हैं। खैर, हाँ, हाँ ... और भालू भालू और घोंसले के शिकार गुड़िया ...

यहां कोई कारण संबंध नहीं है, बस अपने विचार को छोड़ना मुश्किल है। सब के बाद, यहाँ, मैं एक बग पाया! यह बग कैसे नहीं हो सकता ?? इतना ठंडा। रूस, जाहिर है! नहीं, स्पष्ट नहीं है? ठीक है, सभी एक ही, रूस, निश्चित रूप से कई हैं।

यह औचित्य अधिक पसंद है “मैं बहुत आलसी हूँ, Google पर जाएँ, तथ्यों की तलाश करें। शब्द पर विश्वास करो। " जब हमारे पास तथ्य और सबूत नहीं हैं, तो इसके औचित्य पर पर्दा डालने और "शायद, शायद, निश्चित रूप से ..." लिखने की इच्छा है।



लेकिन ये STOP शब्द हैं! यदि आपको उन्हें लिखने की इच्छा है, तो आपके पास कोई वास्तविक तथ्य नहीं है। तो आप बस इसे खत्म समझो। और हमें परीक्षक की कल्पना के आधार पर एक कार्य करने की आवश्यकता क्यों है? अपना सिद्धांत साबित करो!

और अगर कोई तथ्य नहीं हैं? फिर कार्य शुरू करने लायक भी नहीं है। हां, "आपके अपने मूल" बग को अस्वीकार करना मुश्किल है। लेकिन यह भी, सक्षम होना चाहिए।

Email.ru - तथ्य

क्या तथ्य हो सकते हैं?

सबसे पहले, हम कुछ सरकारी ग्राहकों के लिए अपनी साइट बना सकते हैं, जिन्हें डोमेन में पंजीकृत होना आवश्यक है। कॉर्पोरेट मानक, उनके पास कोई विकल्प नहीं है।

या हमारे पास वास्तव में ऐसे कई ग्राहक हैं, यह आंकड़ों द्वारा दिखाया गया है। उदाहरण के लिए, लॉग में "इस तरह के डोमेन के माध्यम से पंजीकरण करने का प्रयास" में बहुत सारी त्रुटियां हैं। और हो सकता है कि तब यह फीचर बनाने लायक हो। ताकि संभावित ग्राहक न खो सकें।

ऐसे तथ्यों के आधार पर, पीएम (प्रोजेक्ट मैनेजर) यह निर्णय लेता है कि हम कार्य करेंगे या नहीं। और अगर हम करेंगे, तो कब। या वह कह सकता है, "ठीक है, त्रुटियां हैं, और अच्छी तरह से, कुल पंजीकरण का 1% से भी कम है, हम उन्हें नहीं करेंगे"

अमूर्त के बजाय "हाँ, ऐसे लोग निश्चित रूप से मौजूद हैं!" FACTS दे।

और कार्य सेट करते समय, सिद्धांत 5 का उपयोग क्यों करें। जैसा कि आप अपेक्षित परिणाम लिखते हैं, अपने आप से पूछें, "मैं यह क्यों उम्मीद कर रहा हूं?" पहला उत्तर होगा "यह स्पष्ट है", लेकिन फिर से सवाल पूछें "क्यों?"। और अगर आप ध्यान दें कि कोई डेटा नहीं है, तो यह आपको सिर्फ इतना लगता है - तथ्यों की तलाश करें या सहयोगियों के साथ स्थिति पर चर्चा करें।

1.3। बन्नी नाराज हैं

यदि कोई तथ्य नहीं है, लेकिन आप बग से इंकार नहीं करना चाहते हैं, तो छात्र गुस्से, इनकार और बग के औचित्य के अगले चरण में जाते हैं ... भावनाओं पर दबाव:

मैं Cthulhu नाम के साथ पंजीकरण करने का प्रयास करता हूं, लेकिन सिस्टम नहीं करता है। देना चाहिए, अन्यथा ... मैं नाराज था और छोड़ दिया, और तुम! एक ग्राहक खो दिया!

और निश्चित रूप से हर कोई मेरे जैसा ही है, इसलिए आपने सभी ग्राहकों को खो दिया है, और उन्होंने अपमान के लिए मुकदमा भी दायर किया है और सभी पैसे ले लिए हैं!

और अन्य कार ...

बेशक, जब मैं व्यक्तिगत रूप से कुछ पसंद नहीं करता हूं, तो मेरी समस्या को अनदेखा करना बहुत गुस्सा है। इसका क्या मतलब है "सामान्य लोग उस नाम के साथ पंजीकरण नहीं करते हैं?" क्या मैं पागल हूँ!? जैसा कि मैं चाहता हूं, यह कहा जाता है, आप मुझे कुछ कैसे मना कर सकते हैं?

और फिर प्रक्षेपण चालू हो जाता है - अगर मुझे यह पसंद नहीं है, तो अन्य उपयोगकर्ता इसे पसंद नहीं करेंगे! यदि सभी नहीं, तो कम से कम कई। इसलिए, यह निश्चित रूप से एक बग है और इसे ठीक करने की आवश्यकता है। यदि हम छात्रों के बारे में बात कर रहे हैं, तो प्रशिक्षण के ढांचे में कम से कम, या कम से कम स्थापित करें।

हालांकि, नाराज उपयोगकर्ता सबसे खराब औचित्य है जो कभी भी हो सकता है। क्योंकि वे किसी भी बकवास को सही ठहरा सकते हैं:

• क्या मुख्य पर कोई बिल्ली नहीं है? खैर, यह बात है! मैं नाराज था और चला गया! और तुम! एक ग्राहक खो दिया !!
• मैंने पंजीकृत किया और मुझे इसके लिए भुगतान नहीं मिला ?? मैं नाराज था और छोड़ दिया ... और तुम! खैर, आप समझ गए!

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

यह सभी छात्रों में से एक के साथ शुरू हुआ, जिन्होंने सिर्फ यह गुप्त वाक्यांश कहा:
- आह, आप रूसी संघ के डोमेन के माध्यम से पंजीकरण नहीं करना चाहते हैं? और एक उपयोगकर्ता के रूप में मैंने पंजीकरण करने की कोशिश की, मैंने इस प्रमुख स्थिति को देखा, और गया! और तुम! एक ग्राहक खो दिया!

तब मेरे दोस्त ने कहा कि इस तरह के भाषण "बन्नीज़ नाराज थे।" मुझे नहीं पता कि उसे यह उपमा कहां से मिली, लेकिन सभी को पसंद आई।

छात्र ने महसूस किया कि वह उत्तेजित हो रहा था। भावना के बिना औचित्य की तलाश में गया। और हमें एंटीपैटर्न नाम मिला।

एक सरल नियम याद रखें - बग में भावनाएं नहीं होनी चाहिए!

भावनाएँ एक उत्तीर्ण घटना है। अब यह है कि आप धर्मी गुस्से से आग बबूला हो रहे हैं और इसे दुर्भावनापूर्ण टिप्पणियों में व्यक्त करना चाहते हैं जैसे "केवल एक बेवकूफ एक कोड लिख सकता है"। लेकिन किसी भी स्थिति को याद रखें जब आपके बगल में एक बच्चा टोपीदार था, एक बिना टॉय या आइसक्रीम के कारण माँ के लिए एक टेंट्रम की व्यवस्था कर रहा था। क्या आप एक बाहरी पर्यवेक्षक के रूप में इस दृश्य को देखने का आनंद लेते हैं? लेकिन बग ट्रैकर में आपका हिस्टीरिया बिल्कुल एक जैसा दिखता है!

इसलिए, यदि आप वास्तव में चाहते हैं, तो सब कुछ मौखिक रूप से कहें। धूम्रपान कक्ष में डेवलपर के साथ कार्य पर चर्चा करें, अपने पद का बचाव करते हुए। लेकिन जैसे ही हमें कंप्यूटर मिला - हम भावनाओं को दूर करते हैं, हम केवल तथ्यों को लिखते हैं। बिना “यदि हाँ तो” और बिना ”और आप! ग्राहक खो दिया! ”

याद रखें कि वे एक या दो या तीन साल बाद कार्यों पर लौटते हैं। और तब भी आप अपने स्वयं के तंत्र-मंत्र पर ध्यान देंगे। आखिरकार, पिछली कोई भी भावनाएं नहीं हैं, यह हास्यास्पद लगता है। तो मौखिक रूप से अधिकतम भावनाएं - धूम्रपान कक्ष में! और बग में किसी तरह उनके बिना।



और औचित्य में मेगा-नाराज बनी के बारे में नहीं लिखते हैं। कभी-कभी कार्य का ऐसा बचाव हास्यास्पद हो जाता है:

छात्र को उपयोगकर्ता के प्रस्ताव में एक टाइपो मिला। महत्वपूर्ण प्राथमिकता के साथ एक बग रखें। जब उन्हें प्राथमिकता स्पष्ट करने के लिए कहा गया, तो वह बहुत ही आक्रोशित थे:

- सिस्टम ने मुझे धोखा दिया, मैं उस पर भरोसा नहीं कर सकता !!!

वह शायद चिंतित था कि सवाल "यह बग नहीं है," में बदल जाएगा, इसलिए उसने अपनी बग का बचाव करना शुरू कर दिया। लेकिन किसी को भी एतराज नहीं है कि यह एक बग है। लेकिन यह महत्वपूर्ण क्यों है? कौन ऑफर पढ़ता है?

- मैंने पढ़ा! इसलिए, मैं देखता हूं कि सिस्टम खराब है, अगर वहां कोई टाइपो है, तो यह क्या कर सकता है? और अब इस पर विश्वास कैसे किया जाए?!

लेकिन "मैंने पढ़ा" "" हर कोई पढ़ता है। और फिर छात्र ने खुद स्वीकार किया कि वह कभी भी ध्यान से नहीं पढ़ता है कि कार्यक्रम स्थापित करते समय हमें लाइसेंस अनुबंध में पर्ची दी जा रही है। तो एक ही कहानी की पेशकश के साथ। जबकि सब ठीक है, वे इसे नहीं पढ़ते हैं। यदि कुछ सुखद नहीं है, तो पहले से ही नियमों को संबोधित करें।

हालाँकि, "सिस्टम ने मुझे धोखा दिया और मैं अब इस पर विश्वास नहीं कर सकता" पाठ के दसवें पृष्ठ पर एक टाइपो के कारण जिसे बहुत कम लोग पढ़ते हैं ... खैर ... इसे बग में न लिखें, अपने आरएम को न बताएं।

तो, हम बग से भावनाओं को निकालते हैं। और हम वहां क्या छोड़ सकते हैं? बेशक, तथ्य!

भावनाओं पर लिखने के बजाय "बन्नी निश्चित रूप से नाराज हो जाएंगे, वे छोड़ देंगे, और आप ग्राहकों को खो देंगे":

- आंकड़े इकट्ठा;
- श्रम लागत का अनुमान;
- आरओआई की गिनती करें;
- साक्षात्कार उपयोगकर्ताओं;
- प्रतियोगियों के साथ उत्पाद की तुलना करें;

और एक हिस्टेरिकल गिलहरी के बजाय, आप एक शांत परीक्षक बन जाएंगे जो विचारशील बग बनाता है!

2. अच्छा औचित्य पैटर्न

कीड़े को सही ढंग से कैसे औचित्य दें? अपेक्षित परिणाम में क्या लिखा जाना चाहिए ताकि आपका बग तय हो जैसा आपने लिखा है? और उन्होंने 10 बार नहीं पूछा "यह इतना सही क्यों है"?

ऊपर तीन एंटीपेटर्न की चर्चा की गई, आइए बग्स को सही ठहराने के लिए तीन अच्छे पैटर्नों पर चर्चा करें।

2.1। Pruflink

यह हो सकता है:

• आवश्यकताओं के लिए लिंक
• आवश्यकताओं खुद (शब्द फ़ाइल, वर्तमान ...)
• इंटरनेट लिंक
• अनुमानित आरओआई
• ग्राहक पत्र
• आंकड़े

आवश्यकताओं के लिए लिंक

सबसे सरल बग तब है जब कोई TK है और सिस्टम वहां वर्णित के रूप में काम नहीं करता है।

इसलिए हम अपेक्षित परिणाम में लिखते हैं: "57.9, क्योंकि यह काम के बयान में ऐसा है।" हम्म, हम्म ... एक मिनट रुको। ऐसा लगता है "मुझे माँ की कसम" ...

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

• एहसास है कि किस तरह की टीके शामिल है;
• टीके ही खोजें;
• प्रश्न में विशिष्ट स्थान खोजें;
• समझ पाने के लिए ...

क्या केवल अंतिम वस्तु को छोड़ना आसान नहीं है? आखिरकार, डेवलपर 10 अलग-अलग परियोजनाओं पर काम कर सकता है, जिसके प्रलेखन को 10 अलग-अलग स्थानों में वितरित किया जाता है। टीके की खोज में उसे ५-१० मिनट लगेंगे, और आपके लिए एक लिंक जोड़ना दूसरे की बात है। आखिरकार, अब आप टीके पर परीक्षण कर रहे हैं, जिसका अर्थ है कि यह खुला है और आपकी आंखों के सामने है। लिंक कॉपी करें और पेस्ट करें!

सहकर्मियों के समय का सम्मान करें, और वे आपके आभारी रहेंगे।

आवश्यकताएं स्वयं

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



यह संभव है कि आप पुरानी आवश्यकताओं का परीक्षण कर रहे हों। और अगर आप एक प्रत्यक्ष शब्द फ़ाइल संलग्न करते हैं जिसे आप के खिलाफ जांच कर रहे हैं, तो विश्लेषक इसे देख सकता है और कह सकता है कि "ओह, रुको, हमने पहले ही 10 बार सब कुछ बदल दिया है, मैं इसे अपलोड करना भूल गया। पकड़ो! ”

यदि आप नहीं करते हैं, तो डेवलपर के साथ एक तसलीम पर तीन घंटे बिताएं, जो कहेंगे "लेकिन मेरे पास एक अलग है"। आप दौड़ेंगे, उसकी आवश्यकताओं को देखेंगे, फिर आपका, फिर एक विश्लेषक की तलाश करेंगे कि कौन सही है ...

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

इंटरनेट लिंक

जैसा कि हम याद करते हैं, आवश्यकताएं हमेशा से दूर हैं। और उनके बजाय शायद ... इंटरनेट से लिंक करें! हाँ, क्यों नहीं?

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

या अगर आप श्रीपत से एक उदाहरण लेते हैं। फिर, आपको यह कहां से मिला कि यह एक सामान्य महिला का नाम है? हम कज़ाख और अन्य नामों के सभी प्रकारों को गूगल करते हैं, श्रीपत को खोजते हैं, अन्य समान नाम पाते हैं और इस पृष्ठ का लिंक देते हैं।

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



हां, यहां आपको यह समझने की जरूरत है कि हर लिंक उपयोगी और उचित नहीं है, लेकिन यह कम से कम यह दिखाएगा कि आपको क्यों लगता है कि यह वास्तव में एक बग है। यह मेरी "माँ की कसम" नहीं है, बल्कि एक औचित्य के साथ!

ग्राहक पत्र

एक ग्राहक पत्र के लिए भेजने का औचित्य हो सकता है। हमारे पास एक अलग क्षेत्र है, व्यावसायिक औचित्य, जहां हम लिखते हैं कि किस ग्राहक ने इस सुविधा का अनुरोध किया है। और फिर, जब हम अपने बग को पढ़ते हैं, तो हम तुरंत देखते हैं:

- हाँ, व्यवसाय का मामला खाली है। इसका मतलब है कि हम खुद इस समस्या को पा चुके हैं और मानते हैं कि इसे ठीक करने की जरूरत है।

या:

- हाँ, ऐसे ग्राहक ने 1 अगस्त 2015 को समस्या के बारे में शिकायत की

और अगर हमें इस ग्राहक के साथ स्पष्ट करने की आवश्यकता है कि क्या वास्तव में उसके अनुरूप नहीं है, तो हम आसानी से इस पत्र को पा सकते हैं, क्योंकि हमारे पास सभी जानकारी है (जो, कब, क्या पत्र कहा जाता है)। इस जानकारी को जानने के बाद, मैं जाऊंगा और अपने आउटलुक में 5 सेकंड में एक पत्र ढूंढूंगा। यदि यह जानकारी नहीं है, तो मुझे आउटलुक में जाना होगा और 10 अलग-अलग डैडीज़ के बीच खोज करनी होगी - किस ग्राहक ने इसे और किस पत्र में अनुरोध किया था?

इसके अलावा, अगर हम देखते हैं कि इस सुविधा को कई अलग-अलग ग्राहकों द्वारा अनुरोध किया गया था, तो यह तुरंत प्राथमिकता उठाता है। जब से हम समझते हैं:

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



तो जितनी अधिक शिकायतें, उतनी ही प्राथमिकता। चूंकि हम समझते हैं कि यह एक वास्तविक उपयोगकर्ता है जो शिकायत कर रहा है, उन्हें वास्तव में ऐसी समस्याएं हैं। और यहां तक ​​कि अगर हम छह महीने या एक साल बाद बग में लौटते हैं, तो संलग्न पत्र या कम से कम इसके लिंक के लिए धन्यवाद, कार्य के इतिहास को उठाना हमेशा संभव होगा।

ROI

हम ROI - पेबैक अनुपात की गणना करने का प्रयास कर सकते हैं। क्या हमें वास्तव में यह सुविधा बनाने या इस बग को ठीक करने की आवश्यकता है? क्या यह उचित प्रभाव लाएगा?

आधे घंटे के विकास के लिए एक मामूली संपादन करना एक बात है, जो सैकड़ों उपयोगकर्ताओं की मदद करेगा। यह पूरी तरह से अलग है - एक उपयोगकर्ता के हिस्टीरिया के कारण, सिस्टम के काम को फिर से करने के लिए दो सप्ताह, जो हर किसी पर सूट करता है।

यदि हमने ROI की गणना की और देखा कि खेल मोमबत्ती के लायक है, तो हम गणना को कार्य में डालते हैं। लेकिन कभी-कभी गणना के बाद यह पता चलता है कि आपको कार्य करने की आवश्यकता नहीं है। और यह सामान्य है! इसलिए, हमने अनावश्यक सुविधाओं पर चर्चा करने के लिए टीम का समय बचाया।

इसलिए हम तर्क के ऊपर सोचते हैं - क्योंकि कभी-कभी लगता है कि "आह, क्या बग, क्या बग?"

उदाहरण के लिए, हम एक मोबाइल एप्लिकेशन के साथ काम करने के लिए आते हैं, और परीक्षकों के लिए एक डीबग पैनल है जो कुछ इस तरह दिखता है:



वाह, वाह! थोड़ा नीला है, थोड़ा लाल है, पाठ पूरी तरह से दिखाई नहीं दे रहा है, फ़ॉन्ट बिखरे हुए हैं ... एक स्पष्ट बग! यह मेरे सामने कैसे नहीं देखा गया? तत्काल निकासी, refactoring की जरूरत है!

कैसे करें औचित्य? "आपका क्या मतलब है, अगर कोई उपयोगकर्ता इसे देखता है, तो वह तुरंत नाराज हो जाएगा और छोड़ देगा।" बंद करो। . -. , [2]. . , , !

… , ? . , , . ? !

, . . . ? ? , , .

— , !

आंकड़े आंकड़े

इकट्ठा करते हैं और कार्य में निवेश करते हैं:

- लॉग में त्रुटियों की संख्या;
- तकनीकी सहायता में शिकायतों की संख्या;
- बटन पर क्लिक की संख्या;
- ऑर्डर रखने वाले टैब (टैब को बंद) करने वाले उपयोगकर्ताओं की संख्या;
- ...

यही है, अगर आपको लगता है कि ऑनलाइन स्टोर में ऑर्डर देने के लिए मानक फॉर्म "खराब" है और इसे सुधारने की जरूरत है, तो इसे सही ठहराएं। यह बुरा क्यों है? ताकि पता दर्ज करने के लिए आपको अपना सूचकांक जानना और 10 आवश्यक फ़ील्ड भरना होगा? क्या यह वास्तव में बुरा है या केवल आपको परेशान कर रहा है?

ध्यान रखें कि डेवलपर्स अपने सॉफ़्टवेयर में "स्पष्ट" नहीं देख सकते हैं। आखिरकार, उन्होंने इसे विकसित किया, इसका परीक्षण किया ... वे इसे दिन में 100 बार लगातार देखते हैं, वे पहले से ही इंटरफ़ेस के लिए उपयोग किए जाते हैं। तो भले ही यह वास्तव में पुराना हो, आपको तथ्यों की आवश्यकता है।

और तथ्यों को इकट्ठा करना आसान है - हम आपको यह देखने के लिए आंकड़े बनाने के लिए कहते हैं कि उपयोगकर्ता पृष्ठ को कब छोड़ता है। और अगर उसने टोकरी में पिज्जा जोड़ा, और फिर खेतों में भरना शुरू कर दिया और 5-7 स्पैट और छोड़ दिया, तो यह बहुत अच्छा नहीं है। और अगर हर तीसरा ऐसा करता है - तो निश्चित रूप से कुछ सुधारने लायक है!

यदि आप email.ru को याद करते हैं, तो आप लॉग देख सकते हैं - क्या ऐसी कोई त्रुटि है जैसे "इस तरह के ईमेल के लिए पंजीकरण करने का प्रयास अस्वीकार कर दिया गया है"? हो सकता है कि वे बिल्कुल भी मौजूद न हों, लेकिन हम पहले से ही नाराज उपयोगकर्ताओं का एक समूह बना चुके हैं, जिसकी वजह से साइट का शाब्दिक रूप से लाखों का नुकसान हुआ है।

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



मान लीजिए हम लेखांकन सॉफ्टवेयर करते हैं। यह हमें लगता है: "फू, कोई भी माउस के साथ काम नहीं करता है, हमें यह सुनिश्चित करना चाहिए कि सब कुछ कमांड लाइन से काम करता है, ताकि माउस को छूने की आवश्यकता न हो!" हम इस कार्यक्षमता पर बहुत समय बिताते हैं, लेकिन वास्तविक उपयोगकर्ता इसका उपयोग नहीं करते हैं। क्योंकि उन्हें चुनने के लिए एक माउस की आवश्यकता होती है, बड़े बटन पर प्रहार ... लेकिन प्रोग्रामर के लिए क्या सुविधाजनक है, वे आम तौर पर परवाह नहीं करते हैं, क्योंकि वे पूरी तरह से अलग कुछ के साथ सहज हैं।

और अगर आप सभी को यह बताना चाहते हैं कि उपयोगकर्ताओं को क्या चाहिए, तो पहले प्रयोज्य परीक्षण का अध्ययन करें, और फिर कहें कि बन्नी नाराज हैं या नहीं।

हमारे सिस्टम में, हम अनाम आंकड़े एकत्र करते हैं, कौन सी कार्यक्षमता का उपयोग किया जाता है और कौन सा नहीं। वेब फॉर्म पर बहुत सारे फ़िल्टर हैं जिन्हें बनाए रखना मुश्किल है। क्या उनकी जरूरत है? आप इसे उठा सकते हैं और निकाल सकते हैं, यह जाँचने लायक है।

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

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

2.2। वर्दी

यदि कोई प्रूफलिंक नहीं है, तो हम सिस्टम में एकरूपता का उल्लेख कर सकते हैं। क्योंकि अगर सिस्टम हमेशा इस तरह से काम करता है, और फिर यह अचानक अलग तरह से काम करता है - यह बग के लिए अच्छी तरह से तर्क हो सकता है।

उदाहरण के लिए, यदि हमारा सिस्टम एक पंटोसविचर की तरह काम करता है (यह तब है जब मैं रूसी में प्रिंट करता हूं, लेआउट स्विच करना भूल जाता है, और सिस्टम इसे स्वयं स्विच करता है)। मैं "ओल्गा" टाइप कर सकता हूं, या मैं "Jkmuf" टाइप कर सकता हूं, सिस्टम दूसरे विकल्प को पहले एक में बदल देगा।

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

Jkmuf → ओल्गा

ठीक है, लेकिन क्या होगा अगर मैं "जूलिया" नाम लिखने की कोशिश करूं? यह यू अक्षर से शुरू होता है, और यह पत्र रूसी वर्णमाला के अक्षर के अनुरूप नहीं है, लेकिन एक विशेष चरित्र के लिए:

> → यू

और यह पूरी तरह से अलग तुल्यता वर्ग है!

यही है, अगर हम समझते हैं कि सिस्टम एक puntoswitcher की तरह काम करता है, तो हमारे पास कम से कम 2 समतुल्य कक्षाएं हैं: रूसी अक्षर हैं जो लैटिन अक्षरों के अनुरूप हैं, और ऐसे हैं जो एक विशेष चरित्र के अनुरूप हैं।

ये पूरी तरह से अलग-अलग वर्ग हैं, इनकी जाँच होनी चाहिए! और शायद जब हम एक विशेष चरित्र को प्रिंट करते हैं, तो सिस्टम इसे नहीं पहचानता है। और फिर हम एक बग शुरू करते हैं - मैं प्रतीक> टाइप करता हूं, मुझे उम्मीद है कि सिस्टम इसे यू अक्षर में अनुवाद करेगा, लेकिन ऐसा कुछ नहीं होता है। मुझे इसकी उम्मीद क्यों है? क्योंकि सिस्टम ALREADY उसी तरह काम करता है, क्योंकि अगर मैंने Jkmuf में प्रवेश किया, तो सिस्टम समझ जाएगा कि यह ओल्गा है।

हम दिखाते हैं कि सिस्टम पहले से ही इस तरह से काम करता है, और यह एक अच्छा औचित्य है। हम यह नहीं कहते कि "मैं अपनी माँ की कसम खाता हूँ, वह उसी तरह काम करती है", हम इसे ओल्गा पर साबित करते हैं।

2.3। समस्या, या # जीवन पीड़ा

हमें कुछ वास्तविक उपयोगकर्ता समस्या के बारे में बताएं।

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

और कभी-कभी बग को ठीक नहीं किया जाता है क्योंकि "हाँ कोई भी ऐसा नहीं करता है!" और यह सामान्य है। ऊर्जा और संसाधनों की बर्बादी क्यों एक समस्या है जो कभी नहीं उठती है?

यह प्रयोज्य के साथ समस्याओं के लिए विशेष रूप से सच है। जैसा कि हम याद करते हैं, एक आईटी विशेषज्ञ के लिए जो सुविधाजनक है वह एक साधारण उपयोगकर्ता के लिए असुविधाजनक है। और इसके विपरीत! और यह पता चला है कि अगर हम सिर्फ "ठीक है, तो यह असहज है ..." लिखते हैं - यह एक खराब औचित्य है, आप कभी नहीं जानते कि असहज क्या है, सब कुछ बाकी है। लेकिन अगर हम उपयोगकर्ताओं से प्रतिक्रिया एकत्र करते हैं, उनके पत्र संलग्न करते हैं जिसमें वे हमसे शिकायत करते हैं, तो यह तुरंत सुझाव देता है कि ऐसी समस्या वास्तव में मौजूद है। और यह पहले से ही अपनी प्राथमिकता बढ़ाता है।

एक असली ग्राहक की समस्या हमेशा एक परीक्षक से किसी प्रकार के नकारात्मक परीक्षण से बेहतर होती है।



इसका मतलब यह नहीं है कि परीक्षकों को समस्याओं के लिए कभी भी सही नहीं किया जाता है। अगर आपको कोई समस्या है, तो भी शिकायत करें! हो सकता है कि डेवलपर सिर्फ 5 मिनट में आपकी मदद कर सकता है, उसे अभी स्थिति का पता नहीं है।

एक नई सुविधा का परीक्षण करते समय, मैं इसे ऑटोटेस्ट के साथ कवर करता हूं। परीक्षण की रूपरेखा लंबे समय से है, हम इसका उपयोग करते हैं। टेस्ट एक-दूसरे के समान हैं, इसलिए कॉपी-पेस्ट - आखिरकार, हम आमतौर पर एक पैरामीटर बदलते हैं, बाकी को अपरिवर्तित छोड़ देते हैं। यह "1 परीक्षण = 1 परीक्षण" का सिद्धांत है, ताकि परीक्षण में गिरावट तुरंत कारण का संकेत दे।

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

बेशक, जब मैं कॉपी पेस्ट करता हूं, तो मैं कहीं न कहीं गलती करता हूं ... परिणामस्वरूप, मैंने 30 परीक्षण लिखे, उन्हें एक ही बार में चलाया, और सब कुछ एनपीई के साथ गिर गया। मैं बैठता हूं, अपना सिर खुजलाता हूं और सोचता हूं कि "अरे, मैं कहां गलत हूं?"

मैं सारा दिन छांट रहा हूं, एक गलती की तलाश कर रहा हूं, ऑटो-परीक्षण चला रहा हूं ... मैं एक बग या एक जगह खोजने की कोशिश कर रहा हूं जहां मैंने पंगा लिया। परिणामस्वरूप, मुझे पता चलता है और फिर अगली रैली में मुझे शिकायत होती है:

"मैंने कल पूरे दिन इन ऑटो परीक्षणों को लिखा, क्योंकि मैंने पांचवें परीक्षण में गलती की और फिर लंबे समय तक समझने की कोशिश की कि गिरावट का कारण क्या था।" ओह, यह कॉपी-पेस्ट!

और तब डेवलपर कहता है:
"हाँ, वह मेरे पास आएगी; मैं आधे घंटे में आपके लिए सब कुछ ठीक कर दूँगा और इस समस्या को ठीक कर दूँगा।"

और इसलिए यह संभव था !!!

कृपया डरो मत! शायद आप पीड़ित हैं, और डेवलपर को इसके बारे में पता भी नहीं है। और शायद वह आपकी समस्या को जल्दी से यहाँ और अभी ठीक कर सकता है। और शायद इसे ठीक न करें, लेकिन वर्कअराउंड का सुझाव दें।

बेशक, यदि समस्या एक बार की समस्या है, या इसे ठीक करने में बहुत लंबा समय लग रहा है, तो अनुकूलन कार्य अगली रिलीज़ या आगे जाएगा। लेकिन कम से कम "यह कैसे सुधार किया जा सकता है" पर चर्चा करने और एक कार्य निर्धारित करने के लायक है। आखिरकार, अगर कोई काम नहीं है, तो कोई भी कुछ भी नहीं करेगा।

समस्याओं के विभिन्न मामले हैं:

- ग्राहक की समस्या;
- वास्तविक उपयोगकर्ता की समस्या;
- परीक्षक की समस्या;
- टीम के अंदर एक समस्या;

कुछ अधिक प्राथमिकता वाले हैं, अन्य कम। और फिर भी, यदि हम वास्तविक मामले और वास्तविक समस्या का वर्णन करते हैं, तो इस तरह के कार्य में "स्पष्ट रूप से सुधार की संभावना अधिक है, इसलिए सभी बेहतर होंगे।"

हां, आपको यह समझने की आवश्यकता है कि भले ही हम वर्णन करें कि यह वास्तविक उपयोगकर्ताओं के लिए कितना बुरा है, फिर भी यह गारंटी नहीं देता है कि हम बग को ठीक कर देंगे, लेकिन यह जीवन है। किसी भी मामले में, अगर हमने कम से कम समस्या का वर्णन किया है, तो यह कम से कम स्पष्ट होगा कि हमने यह कार्य क्यों निर्धारित किया है। भले ही हम एक, दो या तीन महीने में उसके पास लौट आएं। हम हमेशा यह देखेंगे कि हमने क्यों सोचा कि उपयोगकर्ता इसके साथ काम करने में बुरे और असहज थे।

3. जब औचित्य की आवश्यकता नहीं है

अचानक, ठीक है? =)

फिर भी, एंटीपैटर्न "स्पष्ट रूप से" अपवाद हैं। अगर व्यवस्था है तो हमें वास्तव में तर्क लिखने की आवश्यकता नहीं है:

• लटका हुआ;
• एक अनहोनी त्रुटि के साथ गिर गया;

खासकर अगर उत्पादन में ऐसा हुआ। यदि हमारी साइट है, तो इसे सही ठहराने का कोई कारण नहीं है, आपको गोंग को हराकर डेवलपर को "तत्काल इसे लागू करना होगा!" यह बग के बिना संभव है। और आप एक संक्षिप्त "मुख्य पर त्रुटि 500" के साथ कर सकते हैं, यह पर्याप्त है।

उंगली से बाहर तर्क को मत चूसो, क्योंकि "यह हमेशा आवश्यक है।" "सिस्टम गिरना नहीं चाहिए" लिखने के लिए पाठ की खातिर पाठ है।

लेकिन! आपको निश्चित रूप से अपेक्षित परिणाम लिखने की आवश्यकता है। यहां तक ​​कि अगर यह आपके लिए स्पष्ट लगता है, तो इसे लिखें, यह आपको मिटा नहीं सकता है।

चरणों
Example.com वेबसाइट खोलें

परिणाम
त्रुटि 500

अपेक्षित परिणाम
मुख्य पृष्ठ खुल गया है

यहां सब कुछ सरल लगता है - मुख्य एक खुलता नहीं है, लेकिन यह होना चाहिए। लेकिन अधिक जटिल उदाहरण हैं।

उदाहरण के लिए, डेवलपर ने TK से सूत्र बनाया और कहीं शून्य से विभाजन होता है। यदि आप सिर्फ "गलतियाँ नहीं होनी चाहिए, रिपोर्ट भरी हुई है" लिखते हैं, तो डेवलपर अभी भी आपके पास यह सवाल लेकर आएगा कि "इसे कैसे खोलना चाहिए?" शून्य से विभाजन है! "

आपको इसे सोचने और लिखने की आवश्यकता है "मुझे उम्मीद है कि सूत्र के अनुसार इस तरह के और ऐसे मूल्यों के साथ एक रिपोर्ट खुलेगी" - जबकि आपको लगता है कि वहां क्या होना चाहिए, आप खुद को टीओआर में एक संयुक्त पा सकते हैं। और फिर विश्लेषक के साथ जांच करें कि कैसे सही ढंग से।



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

4. सारांश

हमने 3 एंटीपैटर्न पर चर्चा की। क्रोध, इनकार और बग के औचित्य के तीन चरण:

1. जाहिर है - यह हमारे लिए स्पष्ट है कि हम औचित्य नहीं करते हैं। और फिर हमें "ओह, मैं भूल गया कि मैं क्यों चाहता था" ... यह केवल आपके लिए, केवल यहां और केवल अब स्पष्ट है। छह महीने के बाद, आप खुद भूल जाएंगे कि क्यों। कितनी मूर्खता है, किस तरह के प्रमाण हैं, यह स्पष्ट कीजिए।
2. मैं अपनी माँ की कसम खाता हूँ, यह सही है! - कसम क्यों? किसी कारण से, आपको लगता है कि यह सही है, इसलिए मुझे बताएँ। उदाहरण के लिए, आवश्यकताओं का लिंक दें।
3. बन्नी नाराज थे - "ओह, आपने मुख्य पृष्ठ पर एक बिल्ली नहीं जोड़ी है?" खैर, यह बात है! मैं नाराज था ... और चला गया! और तुम! ग्राहक खो दिया !! ” लेकिन जो आपके लिए असुविधाजनक है, वह दूसरों के लिए सुविधाजनक हो सकता है। इसलिए भावनाओं को दूर करें और तथ्य दें।

इसके बजाय, उन्हें सही तर्क का उपयोग करना चाहिए:

1. प्रूफ़लिंक - टीके, इंटरनेट, ग्राहक पत्र जिसमें उन्होंने इस कार्यक्षमता का अनुरोध किया ...
2. एकरूपता - अगर सिस्टम हमेशा इस तरह से काम करता है, और एक जगह अलग तरीके से, यह तय करने के लायक है!
3. समस्या - आपके या उपयोगकर्ता के लिए उत्पन्न होने वाली समस्या का वर्णन करें (यदि आप ग्राहकों के साथ संवाद कर रहे हैं)। वास्तविक समस्या हमेशा एक नकारात्मक परीक्षा से बेहतर होती है।

यह लिखना सुनिश्चित करें कि हमने यह क्यों तय किया कि यह वास्तव में एक बग है और हम चाहते हैं कि यह ठीक उसी तरह तय हो जैसा हमने यहां लिखा है। हम श्रृंखला "5 क्यों" से खुद से सवाल पूछते हैं

- मुझे क्यों लगता है कि यह स्पष्ट है?
- मुझे क्यों लगता है कि यह सही है?
- मुझे क्यों लगता है कि उपयोगकर्ता परेशान हैं?

हम इंटरनेट पर आवश्यकताओं के लिंक प्रदान करते हैं, एकरूपता का संकेत देते हैं या उपयोगकर्ता की वास्तविक समस्या के बारे में बात करते हैं।

और जब एक साल बाद आप सक्षम कार्यों को फिर से पढ़ेंगे, तब भी आप मुझसे कहेंगे "धन्यवाद!" ツ