मामलों के साथ आवश्यकताओं को कवर करना। सुपरजोब रियलिटीज

हैलो, हब्रोस्क नागरिकों!

मैंने अपने परीक्षकों और विश्लेषकों के बीच बातचीत की प्रक्रिया और सुपरबॉब कंपनी द्वारा इस प्रक्रिया से मिलने वाले बोनस के बारे में एक लेख लिखने का फैसला किया।

आवश्यकताओं वाले परीक्षकों के काम में तीन चरण होते हैं: एफटी रिव्यू, एफटी कवरेज, केस रिव्यू।

एफटी समीक्षा

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



यह सहभागिता Google शीट के माध्यम से संचालित की जाती है, जहाँ है:

• एफटी नाम
• एफटी के लिए लिंक
• एफटी विश्लेषक के लिए जिम्मेदार
• विश्लेषकों से क़ानून
• जिम्मेदार परीक्षक
• परीक्षकों से सांठगांठ

विश्लेषक तालिका के संबंधित पैराग्राफ में "समीक्षा पर" स्थिति डालता है:



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

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

एफटी कवरेज

टेस्ट मामलों को TestRail में लिखा जाता है; परीक्षण मामलों का संग्रहण आर्किटेक्चर आवश्यकताओं के भंडारण आर्किटेक्चर को पूरी तरह से दोहराता है। खोज में आसानी के लिए यह आवश्यक है, और अपनी साइकिल को सुदृढ़ नहीं करने के लिए, इसे एक विश्लेषक पड़ोसी से लेना आसान है।



परीक्षण आवश्यकताओं को कवर करता है - आवश्यकताओं के प्रत्येक आइटम, प्रत्येक प्रस्ताव को कवर किया जाता है।

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



इस तरह से:

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

मामले तीन संस्करणों में लिखे गए हैं:

• प्रमुख मामले (इनमें से अधिकांश)। जब मामले में केवल एक शीर्षक होता है, जो यह स्पष्ट करता है कि क्या करने की आवश्यकता है। वे विस्तृत परीक्षण मामलों की तुलना में लिखने के लिए तेज़ हैं और एक ही समय में पारदर्शी कवरेज:

• परीक्षण के मामले। कदमों के साथ एक विस्तृत परीक्षण मामला जब मामले में बहुत सारी बारीकियां होती हैं और उन सभी को शीर्षक में नहीं रखा जा सकता है;
• मामलों, जाँचकर्ताओं। जब किसी मामले में कार्यक्षमता की कुछ दिशा की जाँच के लिए एक चेकलिस्ट होती है। ऐसे मामलों को उजागर करने के लिए, शीर्ष लेख (मामलों) में उपयोग करें:

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

केस की समीक्षा

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



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

यदि समीक्षा सफल है, तो FT "समाप्त" स्थिति में है।

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

निष्कर्ष

यह हमें क्या दृष्टिकोण देता है?

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

क्या पसंद नहीं है?

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

अभी के लिए बस इतना ही। आपका ध्यान के लिए धन्यवाद!

और आपकी आवश्यकताओं के साथ काम करने की प्रक्रिया कैसी है?