मेन्यू

एक परीक्षक के रूप में बुरी आवश्यकताओं से कैसे निपटें

how deal with bad requirements

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

मूक सम्मेलन कक्ष घुट रहा था और इसके अंदर हर कोई भ्रमित था। हम इसे कैसे याद कर सकते हैं , यह सवाल था कि हर किसी का चेहरा प्रतिबिंबित हुआ।

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

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

बुरी आवश्यकताओं

यह तो एक उदाहरण मात्र था।

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

लेकिन जैसा कि वे कहते हैं, इस दुनिया में कुछ भी सही नहीं है और आपको इससे निपटना होगा और ऐसी परियोजनाओं से निपटना होगा जिनकी कोई आवश्यकता नहीं है या खराब आवश्यकताएं एक बुरा सपना है।

मुझे समझाने दो -

आप क्या सीखेंगे:

खराब, खराब और परस्पर विरोधी आवश्यकताएं कैसे परेशानी पैदा करती हैं:

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

  • तुम कैसे मामले की रिपोर्ट करें सिस्टम क्रैश के बारे में जब इस बात की कोई परिभाषा नहीं है कि व्यवहार को कैसे उपलब्ध किया जाना चाहिए?
  • आप कैसे बताएंगे कि प्रदर्शन के लिए कोई प्रासंगिक आवश्यकता नहीं होने पर होम पेज के लिए 100 सेकंड का लोडिंग समय अस्वीकार्य है?

कोई आवश्यकता पर अधिक जानकारी और परीक्षण करते समय स्थिति को कैसे संभालना है यह पहले प्रकाशित लेख में पाया जा सकता है - आवश्यकताओं के बिना किसी एप्लिकेशन का परीक्षण कैसे करें?

# 2) खराब आवश्यकताएं - उद्धरण, किसी चीज को अधूरा जानकर उसे न जानना खतरनाक है , यह बहुत ही सही है जब यह एक गरीब आवश्यकता से निपटने के लिए आता है।

एक खराब आवश्यकता की व्याख्या करना और उसी को लागू करना एक बड़ा जोखिम है।

  • आप यह कैसे पुष्टि करेंगे कि खोज परिणाम दिखाने वाला पॉप-अप मान्य है या नहीं जब केवल उल्लेखित आवश्यकता थी - खोज परिणाम उचित होना चाहिए और आप सुनिश्चित नहीं हैं कि खोज करते समय किन मानदंडों पर विचार किया जाना चाहिए।
  • आप इसकी व्याख्या कैसे करेंगे - भूल गए पासवर्ड को पुनः प्राप्त / रीसेट करने के लिए उपयोगकर्ता की सुविधा के लिए पासवर्ड को लागू किया जाना चाहिए। अज्ञात के बारे में पता चलता है कि ग्राहक किस काम के प्रवाह के लिए पासवर्ड भूल गया है, डेवलपर वह / वह सोचता है कि क्या सबसे अच्छा है और संघर्ष शुरू होता है।

# 3) आवश्यकताओं को पूरा करना - किसी को एक ही समय में दो अलग-अलग काम करने के लिए कहना बस उसे भ्रमित कर रहा है और सिस्टम भी इसका अपवाद नहीं है।

  • आप उल्लिखित आवश्यकताओं के साथ आवेदन का परीक्षण कैसे करेंगे:
    • आवेदन हमेशा होम पेज पर खुलना चाहिए।
    • उपयोगकर्ताओं से एप्लिकेशन तक पहुंचने के लिए साइन इन करने की अपेक्षा की जाती है।
  • आवश्यकता दस्तावेज़ के नीचे होने पर आप प्राथमिकता क्या तय करेंगे:
    • यदि उपयोगकर्ता 1000 स्कोर करता है तो गेमिंग एप्लिकेशन को उपयोगकर्ता को अगले स्तर तक बढ़ावा देना चाहिए।
    • एक बार 1000 स्कोर करने पर उपयोगकर्ता को मुफ्त सदस्यता पृष्ठ पर पुनर्निर्देशित किया जाना चाहिए।

और वह यह है कि, खराब, खराब और परस्पर विरोधी आवश्यकताएं कैसे परेशानी पैदा करती हैं।

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

परीक्षण के दृष्टिकोण से, हालांकि उन अस्पष्ट या अस्पष्ट आवश्यकताओं को संभालना मुश्किल है, यह पूरी तरह से असंभव नहीं है।

आइए देखें संभावित समाधान:

खराब आवश्यकताएं और उन्हें एक परीक्षक के रूप में कैसे संभालें:

विधि # 1)अन्वेषण और जानें:

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

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

विधि # 2)अनुभव का उपयोग करें:

अनुभव का उपयोग करें

डोमेन अनुभव , समग्र परीक्षण अनुभव, अतीत और व्यक्तिगत अंतर्दृष्टि में समस्याओं का सामना करने से भ्रामक स्थितियों और आवश्यकताओं का पता लगाने में मदद मिल सकती है।

विधि # 3)वायरफ्रेम देखें:

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

अधिक पढ़ें => वायरफ्रेम - क्या उन्हें वास्तव में परीक्षण किया जाना चाहिए? और अगर हां, तो कैसे?

विधि # 4)सहकर्मी चर्चा:

Android के लिए सबसे अच्छा एमपी 3 संगीत डाउनलोडर अनुप्रयोग

सहकर्मी चर्चा

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

विधि # 5)ग्राहक से स्पष्टीकरण:

ग्राहक उत्पाद / एप्लिकेशन का स्वामी होता है और आवश्यकताओं की स्पष्टता के बारे में उससे संपर्क करना हमेशा बुद्धिमान होता है। लेकिन याद रखें, ग्राहक को 100 के सवालों के साथ हमला करना उचित नहीं है। ऐसा करने से पहले, कुछ होमवर्क की आवश्यकता होती है।

उपलब्ध सर्वोत्तम प्रथाओं का पता लगाने की कोशिश करें, कार्यान्वयन के लाभों को समझें और फिर प्रश्न और संभव समाधान के साथ ग्राहक से संपर्क करें।

निष्कर्ष

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

लेखक के बारे में: यह प्रेरणादायक पोस्ट एसटीएच टीम के सदस्य भौमिका एम द्वारा लिखी गई है। वह एक प्रोजेक्ट लीड है, जिसमें 10+ साल का सॉफ्टवेयर परीक्षण का अनुभव है।

हैप्पी टेस्टिंग, हमेशा की तरह… .. आपके विचारों, टिप्पणियों और राय का इंतजार।

अनुशंसित पाठ

^