मेन्यू

एसआरएस दस्तावेज़ की समीक्षा कैसे करें और परीक्षण परिदृश्य बनाएं - लाइव प्रोजेक्ट पर सॉफ्टवेयर परीक्षण प्रशिक्षण - दिन 2

how review srs document

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

यह हमारे में दूसरा ट्यूटोरियल है 'लाइव परियोजना पर मुफ्त ऑनलाइन सॉफ्टवेयर परीक्षण प्रशिक्षण' श्रृंखला। यदि आप यहां नए हैं तो कृपया पहले परिचय ट्यूटोरियल देखें: एक लाइव प्रोजेक्ट पर एंड टू एंड सॉफ्टवेयर टेस्टिंग ट्रेनिंग।

आइए अब हम इस बात का विस्तृत विश्लेषण करते हैं कि एसआरएस वॉकथ्रू कैसे होता है, इसके लिए हमें इस कदम से पहचान करने की आवश्यकता है कि हमें शुरू करने से पहले क्या कदम उठाने होंगे, हमें किन चुनौतियों का सामना करना पड़ सकता है, आदि। एक विस्तृत तरीके से।

SRS दस्तावेज़ की समीक्षा कैसे करें और परीक्षण परिदृश्य बनाएं_

SDLC का डिज़ाइन चरण:

एसडीएलसी का अगला चरण 'डिज़ाइन' है - यह वह जगह है जहां कार्यात्मक आवश्यकताओं का तकनीकी विवरण में अनुवाद किया जाता है। देव, डिज़ाइन, पर्यावरण और डेटा टीम इस चरण में शामिल हैं। इस कदम का नतीजा आम तौर पर एक तकनीकी डिजाइन दस्तावेज- TDD है।

इनपुट TDD के निर्माण के लिए और QA टीम के लिए परियोजना के QA पहलू पर काम करना शुरू करने के लिए SRS दस्तावेज़ है - जो SRS की समीक्षा करना और परीक्षण उद्देश्य की पहचान करना है।

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

एक एसआरएस की समीक्षा क्या है?

एसआरएस एक दस्तावेज है जो विकास विश्लेषकों द्वारा व्यावसायिक विश्लेषकों और पर्यावरण / डेटा टीमों के सहयोग से बनाया गया है। आमतौर पर, यह दस्तावेज एक बार अंतिम रूप देने के बाद क्यूए टीम के साथ एक बैठक के माध्यम से साझा किया जाएगा, जहां एक विस्तृत वॉकथ्रू की व्यवस्था है।

कभी-कभी, पहले से ही मौजूद एप्लिकेशन के लिए, हमें इस दस्तावेज़ के माध्यम से औपचारिक बैठक और हमें मार्गदर्शन देने वाले व्यक्ति की आवश्यकता नहीं हो सकती है। हमारे पास ऐसा करने के लिए आवश्यक जानकारी हो सकती है।

एसआरएस की समीक्षा कुछ भी नहीं है, लेकिन कार्यात्मक आवश्यकताओं के विनिर्देशन दस्तावेज़ के माध्यम से जा रहा है और यह समझने की कोशिश कर रहा है कि लक्ष्य आवेदन क्या होने वाला है।

पिछले लेख में आप सभी के साथ औपचारिक प्रारूप और एक नमूना साझा किया गया था। यह जरूरी नहीं है कि सभी एसआरएस उस तरह से प्रलेखित होने जा रहे हैं। हमेशा, फ़ॉर्म सामग्री के लिए द्वितीयक है ।

कुछ टीमें सिर्फ बुलेटेड लिस्ट लिखना चाहेंगी, कुछ टीमों में उपयोग के मामले शामिल होंगे, कुछ टीमों में सैंपल स्क्रीनशॉट (जैसे हमारे पास मौजूद डॉक्यूमेंट) और कुछ में पैराग्राफ में विवरण का वर्णन होगा।

सॉफ़्टवेयर आवश्यकताओं के लिए पूर्व-चरण विशिष्टता की समीक्षा

चरण 1) दस्तावेज़ कई संशोधनों से गुजरते हैं, इसलिए सुनिश्चित करें कि हमारे पास संदर्भित दस्तावेज़, SRS का सही संस्करण है।

चरण 2) प्रत्येक टीम के सदस्य से समीक्षा के अंत में क्या अपेक्षित है, इस पर दिशानिर्देश स्थापित करें। दूसरे शब्दों में, इस कदम से क्या डिलिवरेबल्स अपेक्षित हैं, इस पर निर्णय लें - आमतौर पर, इस चरण का आउटपुट परीक्षण परिदृश्यों की पहचान करना है। टेस्ट परिदृश्य कुछ भी नहीं हैं, लेकिन कुछ कार्यक्षमता के लिए test क्या परीक्षण करना है ’के एक बिंदु की ओर इशारा करते हैं।

मेरे राउटर पर नेटवर्क सुरक्षा कुंजी कहां है

चरण 3) इस सुपुर्दगी को कैसे प्रस्तुत किया जाए, इस पर दिशानिर्देश भी स्थापित करें- मेरा मतलब है, टेम्पलेट।

चरण 4) यह तय करें कि टीम का प्रत्येक सदस्य पूरे दस्तावेज पर काम करने वाला है या इसे आपस में बांटते हैं। यह अत्यधिक अनुशंसित है कि हर कोई सब कुछ पढ़ता है क्योंकि यह टीम के कुछ सदस्यों के साथ ज्ञान एकाग्रता को रोक देगा।

लेकिन एक बड़ी परियोजना के मामले में, 1000 पृष्ठों के करीब चलने वाले एसआरएस दस्तावेजों के साथ, दस्तावेज़ मॉड्यूल को तोड़ने और व्यक्तिगत टीम के सदस्यों को सौंपने का दृष्टिकोण सबसे व्यावहारिक है।

चरण # 5) एसआरएस की समीक्षा भी बेहतर समझ में मदद करती है अगर सॉफ्टवेयर के परीक्षण के लिए कोई विशेष आवश्यक शर्तें हैं।

चरण # 6) एक उपोत्पाद के रूप में, प्रश्नों की एक सूची जहां कुछ कार्यक्षमता को समझना मुश्किल है या यदि अधिक जानकारी को कार्यात्मक आवश्यकताओं में शामिल करने की आवश्यकता है या यदि SRS में गलतियां की पहचान की जाती है।

आरंभ करने के लिए हमें क्या करने की आवश्यकता है?

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

यह जानकारी कौन प्रदान करेगा?

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

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

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

क्या टेम्प्लेट परिदृश्यों के लिए टेम्पलेट आवश्यक है?

यदि हम सिर्फ एक सूची बनाते हैं तो परीक्षण परिदृश्यों के लिए एक टेम्प्लेट - क्या यह पर्याप्त नहीं है?

यह निश्चित है। हालाँकि, सॉफ्टवेयर परियोजनाएँ-वन-मैन ’शो नहीं हैं। वे शामिल हैं टीम वर्क ।

4- एक टीम की कल्पना करें यदि उनमें से प्रत्येक ने सॉफ़्टवेयर आवश्यकताओं के विनिर्देश के प्रत्येक मॉड्यूल की समीक्षा करने का निर्णय लिया है। टीम के सदस्य ए ने कागज की एक शीट पर एक सूची बनाई है। टीम के सदस्य 2 ने एक एक्सेल शीट का उपयोग किया। टीम के सदस्य 3 ने एक नोटपैड का उपयोग किया। टीम के सदस्य 4 ने एक शब्द डॉक का उपयोग किया। हम दिन के अंत में परियोजना के लिए किए गए सभी कार्यों को कैसे समेकित करते हैं?

इसके अलावा, हम कैसे तय कर सकते हैं कि कौन सा मानक है और हम कैसे कह सकते हैं कि क्या सही है और क्या नहीं अगर हमने नियम नहीं बनाए हैं, जिसके साथ शुरू करना है?

यह है कि टेम्पलेट क्या है: पूरी टीम के लिए दिशानिर्देशों का एक सेट और एकरूपता और सहमति के लिए एक सहमति प्रारूप।

क्यूए टेस्ट परिदृश्यों के लिए एक टेम्पलेट कैसे बनाएं?

टेम्पलेट्स जटिल या अनम्य नहीं होना चाहिए।

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

परिदृश्यों का परीक्षण करें

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

नीचे दी गई तालिका हमें टेस्ट परिदृश्य बनाने देगी। शामिल स्तंभ हैं:

कॉलम # 1) टेस्ट परिदृश्य आईडी
हमारी परीक्षण प्रक्रिया में प्रत्येक इकाई को विशिष्ट रूप से पहचान योग्य होना चाहिए। इसलिए, प्रत्येक परीक्षण परिदृश्य को एक आईडी सौंपा जाना चाहिए। इस आईडी को निर्दिष्ट करते समय पालन करने के नियमों को परिभाषित किया जाना है।

इस लेख के लिए हम नामकरण सम्मेलन का अनुसरण करने जा रहे हैं टी (उपसर्ग जो टेस्ट परिदृश्य के लिए खड़ा है) ’_’, मॉड्यूल नाम के बाद मुझे (ऑरेंज एचआरएम परियोजना का मेरा जानकारी मॉड्यूल) उसके बाद then _ ’और फिर उपधारा ( उदाहरण के लिए, मुझे मेरी जानकारी के लिए मॉड्यूल, पी तस्वीर के लिए और इतने पर) एक सीरियल नंबर द्वारा पीछा किया। एक उदाहरण होगा: 'TS_MI_MIM_01'।

कॉलम # 2) आवश्यकता
यह मदद करता है कि जब हम एक परीक्षण परिदृश्य बनाते हैं तो हमें इसे एसआरएस दस्तावेज़ के अनुभाग में वापस मैप करने में सक्षम होना चाहिए जहां हमने इसे चुना था। यदि आवश्यकताओं के पास आईडी है तो हम उसका उपयोग कर सकते हैं। यदि खंड संख्या या यहां तक ​​कि एसआरएस दस्तावेज़ के पृष्ठ संख्याएं नहीं हैं जहां से हमने एक परीक्षण योग्य आवश्यकता की पहचान की है।

कॉलम # 3) परीक्षण परिदृश्य विवरण
वन-लाइनर ‘क्या परीक्षण करना है’ निर्दिष्ट करता है। हम इसे परीक्षण के उद्देश्य के रूप में भी संदर्भित करेंगे।

कॉलम # 4) महत्व
यह एक विचार देना है कि ऑटो के लिए कुछ महत्वपूर्ण कार्यक्षमता कितनी महत्वपूर्ण है। उच्च, मध्यम और निम्न जैसे मानों को इस क्षेत्र को सौंपा जा सकता है। आप एक बिंदु प्रणाली भी चुन सकते हैं, जैसे 1-5, 5 सबसे महत्वपूर्ण है, 1 कम महत्वपूर्ण है। इस क्षेत्र में जो भी मूल्य हो सकता है, उसे पहले से तय करना होगा।

कॉलम # 5) टेस्ट मामलों की संख्या
कितने व्यक्तिगत परीक्षण मामलों पर एक मोटा अनुमान है कि हम उस एक परीक्षण परिदृश्य को लिखना समाप्त कर सकते हैं। उदाहरण के लिए, लॉगिन का परीक्षण करने के लिए- हम इन स्थितियों को शामिल करते हैं: सही उपयोगकर्ता नाम और पासवर्ड। सही उपयोगकर्ता नाम और गलत पासवर्ड। सही पासवर्ड और गलत उपयोगकर्ता नाम। तो, लॉगिन कार्यक्षमता को मान्य करने के परिणामस्वरूप 3 परीक्षण मामले होंगे।

sql प्रश्नों के उत्तर पीडीएफ़ के साथ हैं

ध्यान दें: आप इस टेम्प्लेट का विस्तार कर सकते हैं या फ़ील्ड को हटा सकते हैं जैसा कि आप फिट देखते हैं।

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

आइए अब हम अपने ऑरेंज एचआरएम एसआरएस दस्तावेज़ की समीक्षा करें और टेस्ट परिदृश्य बनाएं

प्रो टिप: एसआरएस नमूना में सामग्री की तालिका देखें। हमने 1 ट्यूटोरियल में प्रदान किया है कि किसी भी दस्तावेज को कैसे प्रवाहित किया जा सकता है और इसमें कितना काम शामिल हो सकता है।

खंड 1 दस्तावेज़ का उद्देश्य है। वहां कोई परीक्षण योग्य आवश्यकताएं नहीं।

धारा 2.1 : परियोजना का अवलोकन- श्रोतागण- कोई परीक्षण योग्य आवश्यकताएं भी नहीं।

धारा 2.2 : हार्डवेयर और होस्टिंग- यह खंड इस बारे में बात कर रहा है कि कैसे ऑरेंज एचआरएम साइट होस्ट होने जा रही है। अब, क्या यह जानकारी हमारे लिए महत्वपूर्ण है? इसका उत्तर हां और नहीं हां है, क्योंकि जब हम परीक्षण करते हैं तो हमें एक ऐसा वातावरण होना चाहिए जो वास्तविक समय के पर्यावरण के समान हो।

इससे हमें अंदाजा होता है कि यह कैसा होना चाहिए। नहीं, क्योंकि, यह एक परीक्षण योग्य आवश्यकता नहीं है- परीक्षण होने के लिए एक प्रकार की शर्त।

धारा 3: यहां एक लॉगिन स्क्रीन है और साइट पर प्रवेश करने के लिए हमारे पास किस प्रकार के खाते का विवरण है। यह एक परीक्षण योग्य आवश्यकता है। इसलिए इसे हमारे टेस्ट परिदृश्यों का हिस्सा बनने की जरूरत है।

कृपया परीक्षण परिदृश्य दस्तावेज़ देखें जहां SRS के कुछ वर्गों के लिए परीक्षण परिदृश्य जोड़े गए हैं। अभ्यास के लिए, कृपया बाकी परिदृश्यों को भी इसी तरह से जोड़ें। हालाँकि, मैं दस्तावेज़ के अनुभाग 4 के लिए सही जा रहा हूँ।

धारा 4: सौंदर्यशास्त्र / एचटीएमएल आवश्यकताएँ और दिशानिर्देश- यह खंड सबसे अच्छी तरह से बताता है कि एसआरएस समीक्षा के समय परीक्षण टीम के लिए कुछ आवश्यकताएं कैसे समझ में नहीं आती हैं, लेकिन टीम को सभी के लिए परीक्षण योग्य आवश्यकताओं के रूप में उन पर ध्यान देना चाहिए।

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

OrangeHRM अनुप्रयोग के लिए नमूना परीक्षण परिदृश्य: (छवि विस्तार के लिए क्लिक करें)

परिदृश्यों का परीक्षण करें

=> कृपया देखें और परीक्षण परिदृश्य दस्तावेज़ डाउनलोड करें अधिक जानकारी के लिए।

एसआरएस की समीक्षा के संबंध में कुछ महत्वपूर्ण टिप्पणियां

# 1) किसी भी जानकारी को खुला नहीं छोड़ा जाना है।
#दो) इस बात पर व्यवहार्यता विश्लेषण करें कि क्या एक निश्चित आवश्यकता सही है या नहीं और यह भी परीक्षण किया जा सकता है या नहीं।
# 3) जब तक एक अलग प्रदर्शन / सुरक्षा या परीक्षण टीमों का कोई अन्य रूप मौजूद नहीं है - यह सुनिश्चित करना हमारा काम है कि सभी गैर-जरूरी आवश्यकताओं को ध्यान में रखा जाना चाहिए।
# 4) सभी जानकारी परीक्षकों पर लक्षित नहीं होती है, इसलिए यह समझना महत्वपूर्ण है कि क्या ध्यान दें और क्या नहीं।
# 5) महत्व और नहीं। एक परीक्षण परिदृश्य के लिए परीक्षण मामलों की सटीक जरूरत नहीं है और एक अनुमानित मूल्य के साथ भरा जा सकता है या खाली छोड़ा जा सकता है।

योग करने के लिए, एसआरएस समीक्षा परिणाम:

  • परीक्षण परिदृश्य सूची
  • परिणाम की समीक्षा करें - एसआरएस दस्तावेज़ को वैधानिक रूप से जाने / सत्यापित करने के द्वारा दस्तावेज़ीकरण / आवश्यकता त्रुटियां
  • बेहतर समझ के लिए प्रश्नों की सूची- किसी के मामले में
  • परीक्षण के माहौल को कैसे माना जाता है, इसका प्रारंभिक विचार
  • टेस्ट स्कोप आइडेंटिफिकेशन और एक रफ आइडिया पर कि हम कितने टेस्ट केस खत्म कर सकते हैं-इसलिए हमें डॉक्यूमेंटेशन और आखिरकार निष्पादन के लिए कितना समय चाहिए।

नोट करने के लिए महत्वपूर्ण बिंदु:

# 1) टेस्ट परिदृश्य बाहरी डिलिवरेबल्स नहीं हैं (व्यापार विश्लेषकों या देव टीमों के साथ साझा नहीं किए गए) लेकिन आंतरिक क्यूए खपत के लिए महत्वपूर्ण हैं। वे 100% परीक्षण कवरेज लक्ष्य की दिशा में हमारा पहला कदम हैं। परीक्षण परिदृश्य एक बार एक सहकर्मी की समीक्षा से गुजरते हैं और एक बार जो किया जाता है, वे सभी समेकित होते हैं।

क्यूए दस्तावेजों की समीक्षा कैसे की जाती है, इस बारे में अधिक जानकारी के लिए लेख देखें: 6 सरल चरणों में टेस्ट डॉक्यूमेंटेशन समीक्षा कैसे करें।

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

इस श्रृंखला का अगला चरण वह है - हम परीक्षण मामलों को बनाने और परीक्षण डिजाइनिंग चरण में आगे बढ़ने पर काम करेंगे। इससे पहले, हम भी मिल जाएगा - परीक्षण योजना क्या है?यह पूरी QA परियोजना में कहाँ फिट बैठता है? हमेशा की तरह, बेहतरीन परिणामों के लिए हमारे साथ काम करें।

क्यूए प्रशिक्षण दिवस 3: स्क्रैच से एसआरएस दस्तावेज़ कैसे लिखें।

कृपया अपने सवाल और टिप्पणी आते रहें। हम आपके पाठकों की सराहना करते हैं एक टन!

अनुशंसित पाठ

^