how create requirements traceability matrix
सॉफ्टवेयर टेस्टिंग में रिक्वायरमेंट्स ट्रेसेबिलिटी मैट्रिक्स (RTM) क्या है: उदाहरण और सैंपल टेम्प्लेट के साथ ट्रेकेबिलिटी मैट्रिक्स बनाने के लिए चरण-दर-चरण गाइड
आज का ट्यूटोरियल एक महत्वपूर्ण QC उपकरण के बारे में है, जो या तो अति-सरलीकृत (अनदेखी की गई है) या अति-जोर दिया गया है - अर्थात ट्रैसेबिलिटी मैट्रिक्स (TM)।
सबसे अधिक बार, ट्रेसबिलिटी मैट्रिक्स का निर्माण, समीक्षा या साझा करना प्राथमिक क्यूए प्रक्रिया डिलिवरेबल्स में से एक नहीं है - इसलिए यह प्रमुख रूप से केंद्रित नहीं है, इस प्रकार अंडर-जोर दिया जाता है। इसके विपरीत, कुछ ग्राहक अपने उत्पाद (परीक्षण के तहत) के बारे में पृथ्वी-टूटने वाले पहलुओं को प्रकट करने के लिए एक टीएम की उम्मीद करते हैं और निराश होते हैं।
'जब सही इस्तेमाल किया जाता है, तो एक ट्रैसेबिलिटी मैट्रिक्स आपकी क्यूए यात्रा के लिए आपका जीपीएस हो सकता है'।
जैसा कि एक सामान्य अभ्यास है एसटीएच , हम इस लेख में एक TM के 'क्या' और 'कैसे' पहलुओं को देखेंगे।
आप क्या सीखेंगे:
- आवश्यकता ट्रेसबिलिटी मैट्रिक्स क्या है?
- टेस्ट कवरेज और आवश्यकता ट्रेसबिलिटी
- कैसे एक आवश्यकताएँ Traceability मैट्रिक्स बनाने के लिए
आवश्यकता ट्रेसबिलिटी मैट्रिक्स क्या है?
रिक्वायरमेंट ट्रैसेबिलिटी मैट्रिक्स या आरटीएम में, हम क्लाइंट द्वारा निर्मित सिस्टम के लिए प्रस्तावित उपयोगकर्ता आवश्यकताओं के बीच लिंक को दस्तावेज करने की एक प्रक्रिया स्थापित करते हैं। संक्षेप में, यह सुनिश्चित करने के लिए परीक्षण के मामलों के साथ उपयोगकर्ता की आवश्यकताओं को मैप और ट्रेस करने के लिए एक उच्च-स्तरीय दस्तावेज़ है कि प्रत्येक और हर आवश्यकता के लिए परीक्षण के पर्याप्त स्तर को प्राप्त किया जा रहा है।
किसी भी आवश्यकता के लिए परिभाषित किए जाने वाले सभी परीक्षण मामलों की समीक्षा करने की प्रक्रिया को ट्रैसेबिलिटी कहा जाता है। ट्रेसबिलिटी हमें यह निर्धारित करने में सक्षम बनाता है कि परीक्षण प्रक्रिया के दौरान किन आवश्यकताओं ने दोषों की सबसे अधिक संख्या को जन्म दिया।
किसी भी परीक्षण सगाई का फोकस अधिकतम परीक्षण कवरेज होना चाहिए। कवरेज से, इसका सीधा सा मतलब है कि हमें हर चीज को परखना होगा। किसी भी परीक्षण परियोजना का उद्देश्य 100% परीक्षण कवरेज होना चाहिए।
आवश्यकताएँ Traceability मैट्रिक्स यह सुनिश्चित करने के लिए एक तरीका स्थापित करता है कि हम कवरेज पहलू पर जांच करते हैं। यह कवरेज अंतराल की पहचान करने के लिए एक स्नैपशॉट बनाने में मदद करता है। संक्षेप में, इसे उन मेट्रिक्स के रूप में भी संदर्भित किया जा सकता है जो हर आवश्यकता के लिए टेस्ट केस रन, पास, असफल या अवरुद्ध आदि की संख्या निर्धारित करते हैं।
आवश्यकता ट्रेसबिलिटी की आवश्यकता क्यों है?
आवश्यकता ट्रैसबिलिटी मैट्रिक्स आवश्यकताओं को जोड़ने में मदद करता है, परीक्षण के मामलों , और दोष सटीक रूप से। आवेदन की संपूर्ण आवश्यकता का पता लगाने के लिए परीक्षण किया जाता है ( एंड टू एंड टेस्टिंग एक आवेदन हासिल की है)।
सबसे अच्छा मुफ्त विंडोज 10 सिस्टम अनुकूलक
आवश्यकता ट्रेसबिलिटी आवेदन की अच्छी 'गुणवत्ता' का आश्वासन देती है क्योंकि सभी विशेषताओं का परीक्षण किया जाता है। गुणवत्ता नियंत्रण सॉफ्टवेयर को प्राप्त किया जा सकता है क्योंकि कम से कम दोषों के साथ अप्रत्याशित परिदृश्यों के लिए सॉफ्टवेयर का परीक्षण किया जाता है और सभी कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं को संतुष्ट किया जाता है।
आवश्यकता ट्रेसबिलिटी मैट्रिक्स सॉफ्टवेयर सॉफ़्टवेयर अनुप्रयोग के लिए निर्धारित समय अवधि में परीक्षण किया जा रहा है, परियोजना का दायरा अच्छी तरह से निर्धारित किया गया है और इसका कार्यान्वयन ग्राहकों की आवश्यकताओं और आवश्यकताओं के अनुसार प्राप्त किया गया है और परियोजना की लागत को अच्छी तरह से नियंत्रित किया गया है।
दोष रिसाव को रोका जाता है, क्योंकि इसकी आवश्यकताओं के लिए पूरे आवेदन का परीक्षण किया जाता है।
ट्रैसेबिलिटी मैट्रिक्स के प्रकार
फॉरवर्ड ट्रैसेबिलिटी
टेस्ट मामलों में Test फॉरवर्ड ट्रैसेबिलिटी ’आवश्यकताएँ। यह सुनिश्चित करता है कि परियोजना वांछित दिशा के अनुसार आगे बढ़ती है और हर आवश्यकता का पूरी तरह से परीक्षण किया जाता है।
बैकवर्ड ट्रैसेबिलिटी
टेस्ट मामलों को 'बैकवर्ड ट्रैसेबिलिटी' में आवश्यकताओं के साथ मैप किया जाता है। इसका मुख्य उद्देश्य यह सुनिश्चित करना है कि वर्तमान में विकसित किया जा रहा उत्पाद सही रास्ते पर है। यह यह निर्धारित करने में भी मदद करता है कि कोई अतिरिक्त अनिर्दिष्ट कार्यात्मकता नहीं जोड़ी गई है और इस प्रकार परियोजना का दायरा प्रभावित हुआ है।
द्वि-दिशात्मक ट्रैसेबिलिटी
(फॉरवर्ड + बैकवर्ड): एक अच्छे ट्रैसेबिलिटी मैट्रिक्स में परीक्षण मामलों से लेकर आवश्यकताओं तक और इसके विपरीत (मामलों का परीक्षण करने की आवश्यकताएं) के संदर्भ होते हैं। इसे 'द्वि-दिशात्मक' ट्रैसेबिलिटी के रूप में जाना जाता है। यह सुनिश्चित करता है कि सभी परीक्षण मामलों को आवश्यकताओं के बारे में पता लगाया जा सकता है और निर्दिष्ट प्रत्येक आवश्यकता उनके लिए सटीक और वैध परीक्षण मामले हैं।
आरटीएम के उदाहरण हैं
(1) व्यापार की आवश्यकता
BR1 : लेखन ईमेल विकल्प उपलब्ध होना चाहिए।
BR1 के लिए परीक्षण परिदृश्य (तकनीकी विनिर्देश)
TS1 : मेल विकल्प प्रदान किया जाता है।
परीक्षण के मामलों:
टेस्ट केस 1 (TS1.TC1) : लिखें मेल विकल्प सक्षम है और सफलतापूर्वक काम करता है।
टेस्ट केस 2 (TS1.TC2) : लिखें मेल विकल्प अक्षम है।
# 2) दोष
परीक्षण मामलों को निष्पादित करने के बाद यदि कोई दोष पाया जाता है, तो उसे व्यावसायिक आवश्यकताओं, परीक्षण परिदृश्यों और परीक्षण मामलों के साथ सूचीबद्ध और मैप किया जा सकता है।
उदाहरण के लिए, यदि TS1.TC1 विफल हो जाता है यानी मेल विकल्प लिखें हालांकि सक्षम ठीक से काम नहीं करता है तो एक दोष को लॉग इन किया जा सकता है। मान लीजिए कि दोषपूर्ण आईडी ऑटो-जनरेट या मैन्युअल रूप से असाइन किया गया नंबर D01 है, तो इसे BR1, TS1 और TS1.TC1 नंबर के साथ मैप किया जा सकता है।
इस प्रकार सभी आवश्यकताओं को एक तालिका प्रारूप में दर्शाया जा सकता है।
| व्यवसाय की आवश्यकता # | परीक्षण परिदृश्य # | परीक्षण मामला # | दोष के # |
|---|---|---|---|
| BR1 | TS1 | TS1.TC1 TS1.TC2 | D01 |
| BR2 | TS2 | TS2.TC1 टीएस 2, टीसी 2 TS2.TC3 | D02 D03 |
| BR3 | TS3 | TS1.TC1 TS2.TC1 TS3.TC1 TS3.TC2 | शून्य |
टेस्ट कवरेज और आवश्यकता ट्रेसबिलिटी
टेस्ट कवरेज क्या है?
परीक्षण कवरेज में कहा गया है कि परीक्षण चरण शुरू होने पर ग्राहकों की आवश्यकताओं को सत्यापित किया जाना चाहिए। टेस्ट कवरेज एक शब्द है जो यह निर्धारित करता है कि क्या परीक्षण के मामलों को पूरी तरह से सॉफ़्टवेयर एप्लिकेशन का परीक्षण करने के लिए लिखा और निष्पादित किया जाता है, इस तरह से न्यूनतम या एनआईएल दोषों की सूचना दी जाती है।
टेस्ट कवरेज कैसे प्राप्त करें?
अधिकतम टेस्ट कवरेज अच्छे Tra रिक्वायरमेंट ट्रैसेबिलिटी ’की स्थापना के द्वारा प्राप्त किया जा सकता है।
- डिज़ाइन किए गए परीक्षण मामलों में सभी आंतरिक दोषों का मानचित्रण
- भविष्य के प्रतिगमन परीक्षण सूट के लिए सभी ग्राहक रिपोर्ट किए गए दोषों (सीआरडी) को व्यक्तिगत परीक्षण मामलों में मैप करना
आवश्यकता विनिर्देशों के प्रकार
(1) व्यावसायिक आवश्यकताएँ
वास्तविक ग्राहकों की आवश्यकताओं को एक दस्तावेज के रूप में सूचीबद्ध किया जाता है व्यावसायिक आवश्यकताएँ दस्तावेज़ (BRS) । यह बीआरएस ग्राहक के साथ एक संक्षिप्त बातचीत के बाद, न्यूनतम स्तर की उच्च आवश्यकता सूची है।
यह आमतौर पर Anal बिजनेस एनालिस्ट्स ’या प्रोजेक्ट (आर्किटेक्ट’ (संगठन या प्रोजेक्ट संरचना के आधार पर) द्वारा तैयार किया जाता है। Document सॉफ्टवेयर रिक्वायरमेंट स्पेसिफिकेशंस ’(एसआरएस) दस्तावेज बीआरएस से लिया गया है।
# 2) सॉफ्टवेयर आवश्यकताएँ विशिष्टता दस्तावेज़ (एसआरएस)
यह एक विस्तृत दस्तावेज है जिसमें सभी कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं के सभी सावधानीपूर्वक विवरण शामिल हैं। यह एसआरएस सॉफ्टवेयर अनुप्रयोगों के डिजाइन और विकास के लिए आधार रेखा है।
# 3) परियोजना की आवश्यकता के दस्तावेज (PRD)
पीआरडी एक परियोजना में सभी टीम के सदस्यों के लिए एक संदर्भ दस्तावेज है जो उन्हें बताता है कि किसी उत्पाद को क्या करना चाहिए। इसे उत्पाद के प्रयोजन, उत्पाद सुविधाएँ, रिलीज़ मानदंड और बजट और परियोजना की अनुसूची जैसे वर्गों में विभाजित किया जा सकता है।
# 4) केस डॉक्यूमेंट का उपयोग करें
यह दस्तावेज है जो व्यवसाय की जरूरतों के अनुसार सॉफ्टवेयर को डिजाइन और कार्यान्वित करने में मदद करता है। यह एक अभिनेता और एक घटना के बीच बातचीत को एक भूमिका के साथ मैप करता है जिसे एक लक्ष्य प्राप्त करने के लिए प्रदर्शन करने की आवश्यकता होती है। यह एक विस्तृत चरण-दर-चरण वर्णन है कि किसी कार्य को कैसे किया जाना चाहिए।
उदाहरण के लिए,
अभिनेता: ग्राहक
भूमिका: गेम डाउनलोड करो
गेम डाउनलोड सफल है।
उपयोग मामले संगठन की कार्य प्रक्रिया के अनुसार SRS दस्तावेज़ में शामिल एक हिस्सा भी हो सकते हैं।
# 5) दोष सत्यापन दस्तावेज
यह प्रलेखित है जिसमें दोषों से संबंधित सभी विवरण हैं। टीम दोषों को ठीक करने और पुनर्प्राप्त करने के लिए Ver दोष सत्यापन ’दस्तावेज़ को बनाए रख सकती है। परीक्षक Ver दोष सत्यापन ’दस्तावेज का उल्लेख कर सकते हैं, जब वे यह सत्यापित करना चाहते हैं कि क्या दोष ठीक हैं या नहीं, विभिन्न ओएस, डिवाइस, अलग-अलग सिस्टम कॉन्फ़िगरेशन आदि पर पुन: दोष।
When दोष सत्यापन ’दस्तावेज़ एक महत्वपूर्ण दोष निवारण और सत्यापन चरण होने पर आसान और महत्वपूर्ण है।
# 6) उपयोगकर्ता कहानियां
एंड-यूज़र के नज़रिए से एक सॉफ्टवेयर फ़ीचर का वर्णन करने के लिए यूज़र स्टोरी का इस्तेमाल मुख्य रूप से ile एजाइल ’डेवलपमेंट में किया जाता है। उपयोगकर्ता कहानियां उपयोगकर्ताओं के प्रकारों को परिभाषित करती हैं कि वे किस तरह और क्यों एक निश्चित सुविधा चाहते हैं। उपयोगकर्ता कहानियां बनाकर आवश्यकता को सरल बनाया गया है।
वर्तमान में, सभी सॉफ्टवेयर उद्योग आवश्यकताओं की रिकॉर्डिंग के लिए यूजर स्टोरीज और एजाइल डेवलपमेंट और संबंधित सॉफ्टवेयर टूल्स के उपयोग की ओर बढ़ रहे हैं।
आवश्यकता संग्रह के लिए चुनौतियाँ
# 1) एकत्र की गई आवश्यकताओं को विस्तृत, स्पष्ट, सटीक और अच्छी तरह से निर्दिष्ट किया जाना चाहिए। लेकिन यहां ऐसा न करें इन विवरणों की गणना के लिए उपयुक्त उपाय, अस्पष्टता, सटीकता और अच्छी तरह से परिभाषित विनिर्देश जो आवश्यकता संग्रह के लिए आवश्यक हैं।
#दो) Anal बिजनेस एनालिस्ट ’या ner प्रोडक्ट ओनर’ की व्याख्या जो भी आवश्यकताओं की जानकारी प्रदान करता है वह महत्वपूर्ण है। इसी प्रकार, जानकारी प्राप्त करने वाली टीम को हितधारकों की अपेक्षाओं को समझने के लिए उचित स्पष्टीकरण जुटाना पड़ता है।
समझ व्यापार की जरूरतों और आवेदन कार्यान्वयन के लिए आवश्यक वास्तविक प्रयासों दोनों के साथ तालमेल होना चाहिए।
# 3) जानकारी को अंतिम-उपयोगकर्ता के दृष्टिकोण से भी प्राप्त किया जाना चाहिए।
# 4) अलग-अलग समय पर हितधारकों के राज्य के परस्पर विरोधी या विरोधाभासी आवश्यकताएं।
# 5) एंड-यूज़र पॉइंट-ऑफ-व्यू को कई कारणों के कारण नहीं माना जाता है और आगे के हितधारकों को लगता है कि वे 'पूरी तरह से' समझते हैं कि किसी उत्पाद के लिए क्या आवश्यक है, जो आम तौर पर ऐसा नहीं होता है।
# 6) विकसित अनुप्रयोग के लिए कौशल की कमी है।
# 7) मॉड्यूल के लिए बार-बार 'स्कोप' के परिवर्तन या प्राथमिकता में परिवर्तन।
# 8) छूटी हुई, निहित या अघोषित आवश्यकताएं।
# 9) ग्राहकों द्वारा निर्धारित असंगत या अस्पष्ट आवश्यकताएं।
# 10) उपरोक्त सभी कारकों का निष्कर्ष यह है कि किसी परियोजना का 'सफलता' या 'विफलता' एक आवश्यकता पर काफी निर्भर करता है।
कैसे आवश्यकता Traceability मदद कर सकते हैं
# 1) एक आवश्यकता कहां लागू की गई है?
उदाहरण के लिए,
आवश्यकता: मेल एप्लिकेशन में ’कंपोज़ मेल’ फंक्शनलिटी लागू करें।
कार्यान्वयन: जहां मुख्य पृष्ठ पर ’कंपोज मेल’ बटन को रखा और पहुँचा जा सकता है।
# 2) क्या एक आवश्यकता आवश्यक है?
उदाहरण के लिए,
आवश्यकता: केवल कुछ उपयोगकर्ताओं के लिए एक मेल अनुप्रयोग में 'मेल लिखें' कार्यक्षमता लागू करें।
कार्यान्वयन: यदि उपयोगकर्ता इनबॉक्स ई-मेल केवल 'रीड-ओनली' है, तो उपयोगकर्ता पहुँच अधिकार के अनुसार, इस मामले में 'मेल लिखें' बटन की आवश्यकता नहीं है।
# 3) मैं एक आवश्यकता की व्याख्या कैसे करूं?
उदाहरण के लिए,
आवश्यकता: फोंट और अटैचमेंट के साथ मेल एप्लिकेशन में with मेल लिखें ’की कार्यक्षमता।
कार्यान्वयन: जब 'मेल लिखें' पर क्लिक किया जाता है, तो सभी सुविधाएँ क्या प्रदान की जानी चाहिए?
- टेक्स्ट बॉडी को ईमेल लिखने और अलग-अलग फ़ॉन्ट प्रकारों में संपादित करने और बोल्ड, इटैलिक्स, उन्हें रेखांकित करने के लिए
- संलग्नक के प्रकार (चित्र, दस्तावेज, अन्य ईमेल, आदि)
- अनुलग्नकों का आकार (अधिकतम आकार अनुमत)
इस प्रकार आवश्यकताएँ उप-आवश्यकताओं के लिए टूट जाती हैं।
# ४) आवश्यकता के कार्यान्वयन के लिए कौन से डिज़ाइन निर्णय प्रभावित होते हैं?
उदाहरण के लिए,
आवश्यकता: सभी तत्व elements इनबॉक्स ’, mail भेजे गए मेल’,, ड्राफ्ट ’,‘ स्पैम ’, etc. कचरा’ आदि स्पष्ट रूप से दिखाई देने चाहिए।
कार्यान्वयन: दिखाई देने वाले तत्वों को format ट्री ’प्रारूप या format टैब’ प्रारूप में प्रदर्शित किया जाना चाहिए।
# 5) क्या सभी आवश्यकताएँ आवंटित की गई हैं?
उदाहरण के लिए,
आवश्यकता: ‘ट्रैश’ मेल विकल्प प्रदान किया जाता है।
कार्यान्वयन: यदि then ट्रैश ’मेल विकल्प प्रदान किया गया है, तो m डिलीट’ मेल विकल्प (आवश्यकता) को शुरू में लागू किया जाना चाहिए और सही तरीके से काम करना चाहिए। यदि only हटाएं ’मेल विकल्प ठीक से काम कर रहा है, तो केवल हटाए गए ईमेल ash ट्रैश’ में एकत्र किए जाएंगे और option ट्रैश ’मेल विकल्प (आवश्यकता) को लागू करने से समझ में आएगा (उपयोगी होगा)।
आरटीएम और टेस्ट कवरेज के लाभ
# 1) विकसित और परीक्षण किए गए निर्माण में आवश्यक कार्यक्षमता है जो / ग्राहकों की / needs उपयोगकर्ताओं की आवश्यकताओं और अपेक्षाओं को पूरा करती है। ग्राहक को वह मिलना चाहिए जो वह चाहता है। ग्राहक को ऐसे एप्लिकेशन के साथ आश्चर्यचकित करना जो वह नहीं करता है जो वह करने की उम्मीद करता है, वह किसी के लिए भी संतोषजनक अनुभव नहीं है।
#दो) अंतिम उत्पाद (सॉफ़्टवेयर एप्लिकेशन) जो ग्राहक को विकसित और वितरित किया गया है, उसे केवल उस कार्यक्षमता को शामिल करना चाहिए जो आवश्यक और अपेक्षित है। सॉफ़्टवेयर एप्लिकेशन में प्रदान की गई अतिरिक्त विशेषताएं प्रारंभ में आकर्षक लग सकती हैं, जब तक कि समय, धन, और इसे विकसित करने के प्रयास की अधिकता न हो।
अतिरिक्त सुविधा भी दोषों का एक स्रोत बन सकती है, जो स्थापना के बाद ग्राहक के लिए समस्या पैदा कर सकती है।
# 3) डेवलपर के शुरुआती कार्य को स्पष्ट रूप से परिभाषित किया गया है क्योंकि वे आवश्यकताओं को लागू करने पर पहले काम करते हैं, जो ग्राहक की आवश्यकता के अनुसार उच्च प्राथमिकता वाले हैं। यदि ग्राहक की उच्च प्राथमिकता आवश्यकताओं को स्पष्ट रूप से निर्दिष्ट किया गया है, तो उन कोड घटकों को पहली प्राथमिकता पर विकसित और कार्यान्वित किया जा सकता है।
devops में निरंतर तैनाती के लिए उपकरण
इस प्रकार यह सुनिश्चित किया जाता है कि अंतिम उत्पाद को ग्राहक को भेजे जाने की संभावना सबसे अधिक आवश्यकताओं के अनुसार है और समय पर है।
# 4) डेवलपर्स पहले सबसे महत्वपूर्ण कार्यक्षमता को सत्यापित करते हैं जो डेवलपर्स द्वारा कार्यान्वित किए जाते हैं। प्राथमिकता सॉफ्टवेयर घटक के सत्यापन (परीक्षण) के रूप में पहले यह निर्धारित करने में मदद करता है कि सिस्टम के पहले संस्करण कब और क्यों जारी होने के लिए तैयार हैं।
# 5) सटीक परीक्षण योजनाएं, परीक्षण मामले लिखे और निष्पादित किए जाते हैं जो यह सत्यापित करते हैं कि सभी आवेदन आवश्यकताओं को सही तरीके से लागू किया गया है। आवश्यकताओं के साथ मानचित्रण का परीक्षण करने से यह सुनिश्चित करने में मदद मिलती है कि कोई बड़ा दोष छूट न जाए। यह ग्राहकों की अपेक्षाओं के अनुसार गुणवत्ता वाले उत्पाद को लागू करने में मदद करता है।
# 6) यदि ग्राहक से Request चेंज रिक्वेस्ट ’है, तो परिवर्तन अनुरोध से प्रभावित होने वाले सभी एप्लिकेशन घटक संशोधित हो जाते हैं और कुछ भी अनदेखा नहीं किया जाता है। यह मूल्यांकन में और बढ़ाता है, एक परिवर्तन अनुरोध सॉफ्टवेयर अनुप्रयोग पर प्रभाव डालता है।
# 7) एक प्रतीत होता है कि साधारण परिवर्तन अनुरोध में संशोधन हो सकता है जो कि आवेदन के कई हिस्सों में किया जाना चाहिए। यह निष्कर्ष निकालना बेहतर है कि परिवर्तन करने के लिए सहमत होने से पहले कितना प्रयास करना होगा।
टेस्ट कवरेज में चुनौतियां
(1) अच्छा संचार चैनल
यदि कोई बदलाव है जो द्वारा सुझाए गए हैं हितधारकों , विकास के पहले चरण में विकास और परीक्षण टीमों को सूचित किया जाना चाहिए। इसके बिना समय पर विकास, आवेदन का परीक्षण और दोषों को पकड़ना / ठीक करना सुनिश्चित नहीं किया जा सकता है।
# 2) टेस्ट परिदृश्य को प्राथमिकता देना महत्वपूर्ण है
उच्च प्राथमिकता वाले, जटिल और महत्वपूर्ण परीक्षण परिदृश्यों की पहचान करना एक मुश्किल काम है। सभी का परीक्षण करने की कोशिश कर रहा है परीक्षण परिदृश्य लगभग एक अस्वीकार्य कार्य है। परिदृश्यों के परीक्षण का लक्ष्य व्यवसाय और अंतिम-उपयोगकर्ता के दृष्टिकोण से बहुत स्पष्ट होना चाहिए।
# 3) प्रक्रिया कार्यान्वयन
परीक्षण प्रक्रिया को तकनीकी बुनियादी ढांचे और कार्यान्वयन, टीम कौशल, पिछले अनुभवों, संगठनात्मक संरचनाओं और प्रक्रियाओं का पालन करने, लागत, समय और संसाधनों से संबंधित परियोजना अनुमान और समय क्षेत्र के अनुसार टीम के स्थान जैसे कारकों को देखते हुए स्पष्ट रूप से परिभाषित किया जाना चाहिए।
उल्लिखित कारकों पर विचार करते हुए एक समान प्रक्रिया कार्यान्वयन परियोजना से संबंधित प्रत्येक व्यक्ति को एक ही पृष्ठ पर सुनिश्चित करता है। यह अनुप्रयोग विकास से संबंधित सभी प्रक्रियाओं के सुचारू प्रवाह में मदद करता है।
# 4) संसाधनों की उपलब्धता
संसाधन दो प्रकार के होते हैं, कुशल-डोमेन विशिष्ट परीक्षक और परीक्षक द्वारा उपयोग किए जाने वाले परीक्षण उपकरण। यदि परीक्षकों के पास डोमेन का उचित ज्ञान है तो वे प्रभावी परीक्षण परिदृश्यों और लिपियों को लिख और लागू कर सकते हैं। इन परिदृश्यों और लिपियों को लागू करने के लिए परीक्षकों को उपयुक्त scenarios परीक्षण उपकरण ’से सुसज्जित होना चाहिए।
ग्राहक के लिए आवेदन का अच्छा कार्यान्वयन और समय पर वितरण केवल कुशल परीक्षक और उचित परीक्षण उपकरण द्वारा सुनिश्चित किया जा सकता है।
# 5) प्रभावी परीक्षण रणनीति कार्यान्वयन
' टेस्ट रणनीति 'अपने आप में एक बड़ा और चर्चा का एक अलग विषय है। लेकिन यहां 'टेस्ट कवरेज' के लिए एक प्रभावी परीक्षण रणनीति कार्यान्वयन सुनिश्चित करता है कि ‘ गुणवत्ता ' आवेदन का है अच्छा न और यह है बनाए रखा समय की अवधि में हर जगह।
एक प्रभावी ahead टेस्ट रणनीति ’सभी प्रकार की महत्वपूर्ण चुनौतियों के लिए आगे की योजना बनाने में एक प्रमुख भूमिका निभाता है, जो आगे एक बेहतर अनुप्रयोग विकसित करने में मदद करता है।
कैसे एक आवश्यकताएँ Traceability मैट्रिक्स बनाने के लिए
हमारे साथ होने के लिए वास्तव में यह जानना आवश्यक है कि ऐसा क्या है जिसे ट्रैक करने या पता लगाने की आवश्यकता है।
परीक्षक अपने परीक्षण परिदृश्यों / उद्देश्यों को लिखना शुरू करते हैं और अंततः कुछ इनपुट दस्तावेजों के आधार पर परीक्षण के मामले - व्यावसायिक आवश्यकताओं के दस्तावेज़, कार्यात्मक विनिर्देशों दस्तावेज़ और तकनीकी डिजाइन दस्तावेज़ (वैकल्पिक)।
मान लें कि, हमारी व्यावसायिक आवश्यकताएँ दस्तावेज़ (BRD) निम्नलिखित हैं: ( इस नमूने BRD को एक्सेल प्रारूप में डाउनलोड करें )
(किसी भी छवि को बड़ा करने के लिए उस पर क्लिक करें)
नीचे व्यावसायिक आवश्यकताओं दस्तावेज़ (BRD) की व्याख्या और कंप्यूटर अनुप्रयोगों के लिए इसके अनुकूलन के आधार पर हमारे कार्यात्मक विनिर्देश दस्तावेज़ (FSD) है। आदर्श रूप से, एफएसडी के सभी पहलुओं को बीआरडी में संबोधित करने की आवश्यकता है। लेकिन सादगी के लिए, मैंने केवल 1 और 2 अंक का उपयोग किया है।
बीआरडी से ऊपर का नमूना एफएसडी: ( इस नमूना FSD को एक्सेल प्रारूप में डाउनलोड करें )
ध्यान दें : बीआरडी और एफएसडी क्यूए टीमों द्वारा प्रलेखित नहीं हैं। हम केवल अन्य प्रोजेक्ट टीमों के साथ दस्तावेजों के उपभोक्ता हैं।
उपरोक्त दो इनपुट दस्तावेजों के आधार पर, क्यूए टीम के रूप में, हम परीक्षण करने के लिए उच्च-स्तरीय परिदृश्यों की सूची के साथ आए।
उपरोक्त बीआरडी और एफएसडी से नमूना परीक्षण परिदृश्य: ( यह नमूना परीक्षण परिदृश्य फ़ाइल डाउनलोड करें )
एक बार जब हम यहां पहुंच जाते हैं, तो अब आवश्यकताएँ ट्रैसबिलिटी मैट्रिक्स बनाने के लिए एक अच्छा समय होगा।
मैं व्यक्तिगत रूप से प्रत्येक दस्तावेज़ के कॉलम के साथ एक बहुत ही सरल एक्सेल शीट पसंद करता हूं जिसे हम ट्रैक करना चाहते हैं। चूंकि व्यावसायिक आवश्यकताओं और कार्यात्मक आवश्यकताओं को विशिष्ट रूप से गिना नहीं जाता है इसलिए हम ट्रैक करने के लिए दस्तावेज़ में अनुभाग संख्याओं का उपयोग करने जा रहे हैं।
(आप विशेष रूप से अपने मामले के लिए सबसे अधिक समझ में आता है के आधार पर लाइन नंबर या बुलेट-पॉइंट नंबर आदि के आधार पर ट्रैक करना चुन सकते हैं।)
यहाँ एक सरल ट्रेसबिलिटी मैट्रिक्स हमारे उदाहरण के लिए कैसा दिखेगा:
उपरोक्त दस्तावेज़, बीआरडी से एफएसडी और अंततः परीक्षण परिदृश्यों के बीच एक ट्रेस स्थापित करता है। इस तरह से एक दस्तावेज बनाकर, हम यह सुनिश्चित कर सकते हैं कि परीक्षण की टीम द्वारा उनके परीक्षण सूट बनाने के लिए प्रारंभिक आवश्यकताओं के हर पहलू को ध्यान में रखा गया है।
आप इसे इस तरह छोड़ सकते हैं। हालांकि, इसे और अधिक पठनीय बनाने के लिए, मैं अनुभाग नामों को शामिल करना पसंद करता हूं। जब ग्राहक या किसी अन्य टीम के साथ यह दस्तावेज़ साझा किया जाता है तो यह समझ में वृद्धि करेगा।
परिणाम निम्नानुसार है:
फिर से, पूर्व प्रारूप या बाद में उपयोग करने का विकल्प आपका है।
यह आपके TM का प्रारंभिक संस्करण है, लेकिन आम तौर पर, जब आप यहां रुकते हैं तो इसका उद्देश्य पूरा नहीं होता है। अधिकतम लाभ इससे लिया जा सकता है जब आप इसे दोषों के लिए सभी तरह से एक्सट्रपलेशन करते हैं।
आइए देखते हैं कैसे।
आपके द्वारा लिए गए प्रत्येक परीक्षण परिदृश्य के लिए, आपके पास कम से कम 1 या अधिक परीक्षण मामले होने वाले हैं। इसलिए, जब आप वहां पहुंचें तो एक और कॉलम शामिल करें और नीचे दिखाए गए अनुसार टेस्ट केस आईडी लिखें:
इस स्तर पर, ट्रेकबिलिटी मैट्रिक्स का उपयोग अंतराल खोजने के लिए किया जा सकता है। उदाहरण के लिए, उपरोक्त ट्रैसेबिलिटी मैट्रिक्स में, आप देखते हैं कि एफएसडी सेक्शन 1.2 के लिए कोई परीक्षण मामले नहीं लिखे गए हैं।
एक सामान्य नियम के रूप में, ट्रैसेबिलिटी मैट्रिक्स में कोई भी रिक्त स्थान जांच के लिए संभावित क्षेत्र हैं। तो इस तरह एक अंतर दो चीजों में से एक हो सकता है:
- परीक्षण टीम किसी भी तरह 'मौजूदा उपयोगकर्ता' कार्यक्षमता पर विचार करने से चूक गई है।
- 'मौजूदा उपयोगकर्ता' कार्यक्षमता को बाद में या एप्लिकेशन की कार्यक्षमता आवश्यकताओं से हटा दिया गया है। इस स्थिति में, TM FSD या BRD में एक असंगति दिखाता है - जिसका अर्थ है कि FSD और / या BRD दस्तावेजों पर एक अद्यतन किया जाना चाहिए।
यदि यह परिदृश्य 1 है, तो यह उन स्थानों को इंगित करेगा जहां परीक्षण टीम को 100% कवरेज सुनिश्चित करने के लिए कुछ और काम करने की आवश्यकता है।
चुस्त कार्यप्रणाली के लिए परीक्षण रणनीति दस्तावेज़ टेम्पलेट
परिदृश्य 2 में, टीएम न केवल अंतराल को दिखाता है यह गलत प्रलेखन की ओर इशारा करता है जिसे तत्काल सुधार की आवश्यकता है।
आइए अब हम टेस्ट केस निष्पादन स्थिति और दोषों को शामिल करने के लिए टीएम का विस्तार करते हैं।
ट्रैसेबिलिटी मैट्रिक्स के नीचे का संस्करण आम तौर पर परीक्षण निष्पादन के दौरान या बाद में तैयार किया जाता है:
डाउनलोड आवश्यकताएँ Traceability मैट्रिक्स टेम्पलेट:
=> एक्सेल फॉर्मेट में ट्रेसेबिलिटी मैट्रिक्स टेम्प्लेट
नोट करने के लिए महत्वपूर्ण बिंदु
ट्रेससैबिलिटी मैट्रिक्स के इस संस्करण के बारे में ध्यान देने के लिए निम्नलिखित महत्वपूर्ण बिंदु हैं:
# 1) निष्पादन की स्थिति भी प्रदर्शित की जाती है। निष्पादन के दौरान, यह एक समेकित स्नैपशॉट देता है कि काम कैसे प्रगति कर रहा है।
# 2) दोष: जब इस स्तंभ का उपयोग पिछड़े ट्रैसेबिलिटी को स्थापित करने के लिए किया जाता है, तो हम बता सकते हैं कि 'नया उपयोगकर्ता' कार्यक्षमता सबसे त्रुटिपूर्ण है। यह रिपोर्ट करने के बजाय कि ऐसा करने और परीक्षण के मामले विफल हो गए, TM व्यवसाय की आवश्यकता को वापस पारदर्शिता प्रदान करता है जिसमें अधिकांश दोष हैं जो कि ग्राहक की इच्छाओं के संदर्भ में गुणवत्ता को प्रदर्शित करता है।
# 3) एक और कदम के रूप में, आप उनके राज्यों का प्रतिनिधित्व करने के लिए दोष आईडी कोड कर सकते हैं। उदाहरण के लिए, लाल रंग में दोष आईडी का मतलब यह अभी भी खुला है, एक हरे रंग में इसका मतलब यह बंद हो सकता है। जब यह किया जाता है, टीएम एक स्वास्थ्य जांच रिपोर्ट के रूप में कार्य करता है जो एक निश्चित बीआरडी या एफएसडी कार्यक्षमता के अनुरूप दोषों की स्थिति प्रदर्शित करता है, तो खुला या बंद किया जा रहा है।
# 4) यदि कोई तकनीकी डिज़ाइन दस्तावेज़ है या आप ऐसे मामलों या किसी अन्य कलाकृतियों का उपयोग करते हैं, जिन्हें आप ट्रैक करना चाहते हैं, तो आप अतिरिक्त कॉलम जोड़कर अपनी आवश्यकताओं के अनुरूप उपर्युक्त दस्तावेज़ का विस्तार कर सकते हैं।
योग करने के लिए, RTM इसमें मदद करता है:
- 100% परीक्षण कवरेज सुनिश्चित करना
- आवश्यकता / दस्तावेज की विसंगतियों को दर्शाना
- व्यावसायिक आवश्यकताओं पर ध्यान देने के साथ समग्र दोष / निष्पादन स्थिति प्रदर्शित करना।
- यदि एक निश्चित व्यवसाय और / या कार्यात्मक आवश्यकता को बदलना था, तो एक TM परीक्षण के मामलों पर पुनर्मूल्यांकन / काम करने के संदर्भ में QA टीम के काम पर प्रभाव का अनुमान लगाने या उसका विश्लेषण करने में मदद करता है।
इसके अतिरिक्त,
- एक Traceability मैट्रिक्स एक मैनुअल परीक्षण विशिष्ट उपकरण नहीं है, इसका उपयोग स्वचालन परियोजनाओं के लिए भी किया जा सकता है। एक स्वचालन परियोजना के लिए, टेस्ट केस आईडी ऑटोमेशन टेस्ट स्क्रिप्ट नाम का संकेत दे सकता है।
- यह भी एक उपकरण नहीं है जिसका उपयोग सिर्फ क्यूएएस द्वारा किया जा सकता है। विकास टीम बीआरडी / एफएसडी आवश्यकताओं को ब्लॉक / इकाइयों / कोड की शर्तों को मैप करने के लिए समान का उपयोग कर सकती है ताकि यह सुनिश्चित किया जा सके कि सभी आवश्यकताएं विकसित की गई हैं।
- टेस्ट प्रबंधन उपकरण जैसे एचपी एएलएम इनबिल्ट ट्रैसेबिलिटी फीचर के साथ आते हैं।
एक महत्वपूर्ण बात यह है कि ध्यान देंआपके ट्रेसबिलिटी मैट्रिक्स को बनाए रखने और अपडेट करने के तरीके से इसके उपयोग की प्रभावशीलता निर्धारित होती है। यदि अक्सर अपडेट नहीं किया जाता है या गलत तरीके से अपडेट किया जाता है, तो टूल मदद करने के बजाय एक बोझ है और यह धारणा बनाता है कि उपकरण अपने आप उपयोग करने के योग्य नहीं है।
निष्कर्ष
आवश्यकता Traceability मैट्रिक्स के लिए साधन है नक्शा और ट्रेस परीक्षण मामलों और खोजे गए दोषों के साथ ग्राहक की सभी आवश्यकताओं को पूरा करता है। यह है एक एकल दस्तावेज़ यह मुख्य उद्देश्य है कि कोई भी परीक्षण के मामले छूट नहीं जाते हैं और इस प्रकार आवेदन की प्रत्येक कार्यक्षमता को कवर और परीक्षण किया जाता है।
गुड time टेस्ट कवरेज ’जो समय से पहले योजनाबद्ध है, परीक्षण चरणों और दोष रिसाव में दोहराव वाले कार्यों को रोकता है। एक उच्च दोष गिनती इंगित करती है कि परीक्षण अच्छी तरह से किया गया है और इस प्रकार आवेदन की 'गुणवत्ता' ऊपर जा रही है। इसी तरह, एक बहुत ही कम दोष गणना इंगित करती है कि परीक्षण निशान तक नहीं किया गया है और यह नकारात्मक तरीके से एप्लिकेशन की 'गुणवत्ता' को बाधित करता है।
यदि टेस्ट कवरेज पूरी तरह से किया जाता है, तो कम दोष गणना को उचित ठहराया जा सकता है और इस दोष गणना को सहायक आंकड़े माना जा सकता है और प्राथमिक नहीं। किसी अनुप्रयोग की गुणवत्ता को ’गुड’ या ’सैटिस्फाइंग’ के रूप में कहा जाता है, जब टेस्ट कवरेज को अधिकतम किया जाता है और दोष की गणना कम से कम की जाती है।
लेखक के बारे में: STH टीम के सदस्य उर्मिला पी। के साथ एक अनुभवी QA प्रोफेशनल हैं उच्च गुणवत्ता परीक्षण और ट्रैकिंग कौशल जारी करना।
क्या आपने अपनी परियोजनाओं में रिक्वायरमेंट ट्रैसेबिलिटी मैट्रिक्स बनाया है? इस लेख में हमने जो बनाया है, उससे कितना अलग या अलग है? कृपया इस लेख पर अपने अनुभवों, टिप्पणियों, विचारों और प्रतिक्रिया को अपनी टिप्पणियों के माध्यम से साझा करें।
अनुशंसित पाठ
- प्रारूप और सामग्री के साथ नमूना सॉफ्टवेयर टेस्ट प्लान टेम्पलेट
- एक प्रभावी टेस्ट सारांश रिपोर्ट कैसे लिखें (नमूना रिपोर्ट डाउनलोड)
- टेस्ट केस के उदाहरणों के साथ सैंपल टेस्ट केस टेम्प्लेट (डाउनलोड)
- उदाहरणों के साथ स्वीकृति परीक्षण रिपोर्ट के लिए नमूना टेम्पलेट
- टेस्ट स्ट्रेटेजी डॉक्यूमेंट कैसे लिखें (सैंपल टेस्ट स्ट्रेटेजी टेम्पलेट के साथ)
- सॉफ़्टवेयर आवश्यकताएँ विशिष्टता (SRS) का परीक्षण कैसे करें?
- शीर्ष 20+ सर्वश्रेष्ठ आवश्यकताएँ प्रबंधन उपकरण (पूरी सूची)
- क्यूए सॉफ्टवेयर परीक्षण जाँचकर्ता (नमूना जाँचकर्ता शामिल)