how perform test documentation reviews 6 simple steps qa process
अब तक, हम सभी जानते हैं कि एक परीक्षक के लिए, प्रलेखन उनके दैनिक जीवन का अभिन्न अंग है। परीक्षण कलाकृतियों का एक अधिभार है जो बनाया, समीक्षा, अनुमोदित, उपयोग, रखरखाव और वितरित किया जाता है। हमारे पास हमेशा स्पष्ट-कट प्रक्रियाएं होती हैं कि किसी दस्तावेज़ को कैसे बनाया जाए, इसका उपयोग कैसे किया जाए, इसे किसके पास जाना चाहिए आदि।
इस लेख के माध्यम से, हम छोटे लेकिन महत्वपूर्ण विषय - समीक्षा पर कुछ प्रकाश डालने जा रहे हैं।
समीक्षा करना भी परीक्षण का एक रूप है - V & V के सत्यापन भाग को स्थैतिक परीक्षण भी कहा जाता है।
आप क्या सीखेंगे:
- समीक्षा के प्रकार
- चरण 1: मानदंड को परिभाषित करें
- चरण 2: चेक करें
- चरण 3: अपने परिणाम रिकॉर्ड करें
- चरण 4: साझा करें, चर्चा करें और आवश्यक परिवर्तन लागू करें
- चरण 5: संस्करण नियंत्रण शामिल दस्तावेज
- चरण 6: साइन ऑफ करें और उपयोग किए गए दस्तावेज़ का उपयोग करें
- याद दिलाने के संकेत
- आप के लिए खत्म है
- अनुशंसित पाठ
समीक्षा के प्रकार
- अपने काम की समीक्षा करना - सेल्फ चेकिंग
- सहकर्मी समीक्षा
- सुपरवाइजरी
यदि सत्यापन परीक्षण प्रथाओं का एक-आधा है तो सत्यापन अन्य है, लेकिन अक्सर दिशा-निर्देश अस्पष्ट होते हैं - इसलिए अब इसे बदल दें। क्या यह एसटीएच के लेखों के साथ एक सामान्य अभ्यास है, हम सवालों के साथ शुरू करेंगे, क्या? क्यों? कैसे?
सबसे अच्छा मुफ्त वायरस और मैलवेयर हटाने
हम क्या समीक्षा करें?
बनाई गई हर चीज की समीक्षा करनी होगी। निम्नलिखित कुछ सामान्य कलाकृतियों की समीक्षा की गई है:
- जाँच की योजना
- परीक्षण परिदृश्य
- परीक्षण टेम्पलेट्स
- परीक्षण के मामलों
- परीक्षण डेटा
- रिपोर्ट… आदि
क्यों समीक्षा करें?
बिल्कुल उसी कारण के लिए हम सॉफ्टवेयर का परीक्षण करते हैं, उदाहरण के लिए,
- त्रुटियों को उजागर करने के लिए
- पूर्णता की जांच करने के लिए
- यह सुनिश्चित करने के लिए कि मानकों और दिशानिर्देशों का पालन किया जाता है या नहीं… आदि।
समीक्षा कैसे करें?
निम्नलिखित गतिविधियों की सूची में शामिल हैं:
- मापदंड को परिभाषित करें - क्या देखने के लिए एक चेकलिस्ट है?
- जाँच करें
- अपने परिणाम रिकॉर्ड करें
- आवश्यक परिवर्तन साझा करें, चर्चा करें और उन्हें लागू करें
- संस्करण में शामिल दस्तावेजों को नियंत्रित करता है
- साइन इन करें और इच्छित के रूप में डॉक्टर का उपयोग करें।
अब हम 'कैसे' अनुभाग में प्रत्येक चरण पर चर्चा करेंगे - दूसरे शब्दों में, इसे करने की प्रक्रिया।
(हम में से अधिकांश परीक्षकों को प्रोसेसर शब्द पसंद नहीं है, यह नहीं है; हमारे लिए, इसका अर्थ या तो बहुत अधिक काम है या कुछ उच्च-स्तरीय प्रबंधकीय कार्य हैं, जो हमें नहीं करना है, भले ही हमें करना हो - कुछ अनुपालन के बारे में, जिनके बारे में हमें कोई जानकारी नहीं है। लेकिन, जब आप एक के साथ आते हैं, तो मुझ पर विश्वास करें प्रक्रिया जो काम करती है और हमें यह समझने के लिए पर्याप्त है कि हमें यह क्यों करना है, यह मजेदार हो सकता है! बस मेरे साथ खेलते हैं।)
सहकर्मी समीक्षा और पर्यवेक्षी समीक्षा के लिए प्रक्रिया मेरे अनुसार ही है क्योंकि उच्च पदनाम के बावजूद एक पर्यवेक्षक भी सहकर्मी है।
चरण 1: मानदंड को परिभाषित करें
# 1) आप क्या खोजने की उम्मीद कर रहे हैं? आप इस तरह की चीजों की तलाश कर सकते हैं:
- वर्तनी की गलतियाँ (बहुत मूर्खतापूर्ण लगता है; मुझे ऐसा नहीं लगता, एक बार मैंने अपने लेखों में 'वेब ऑब्जेक्ट' के बजाय 'वेड ऑब्जेक्ट' लिखा था - इसका अर्थ पूरी तरह से बदल जाता है। लगभग यह मूर्खतापूर्ण रूप से गंभीरता से लिया जाता है।)
- प्रारूप / टेम्पलेट का अनुपालन
- कार्यक्षमता कवरेज और शुद्धता
- समझने में आसानी
- मानकों का पालन - नामकरण परंपराओं, लगातार क्रमांकन… आदि।
#दो) एक चेकलिस्ट बनाओ - चेकलिस्ट बहुत बहुमुखी हैं। यह एक समीक्षा सूची के रूप में या किराने की सूची के रूप में सरल रूप में जटिल हो सकता है। इसे बनाने में कुछ समय लगता है और एक बार जब आप ऐसा कर लेते हैं, तो यह ऑन या ऑफ की जाँच करने जितना आसान होता है।
# 3) परिणामों की रिपोर्ट कैसे करें? - जो भी सुविधाजनक हो, चुनें, अधिमानतः एक विधि जिसे रिकॉर्ड और ट्रैक किया जा सकता है।
- कभी-कभी यह परीक्षण के मामलों के साथ एक्सेल शीट में एक अतिरिक्त कॉलम को जोड़ने और लाल रंग में कुछ लिखने के रूप में सरल हो सकता है जब यह नहीं होना चाहिए।
- मुंह का शब्द हो सकता है
- एक ईमेल में एक सूची
चरण 2: चेक करें
# 1) आपके द्वारा पहले की गई चेकलिस्ट का उपयोग करते हुए, दस्तावेज़ को सत्यापित करें और अपनी प्रतिक्रिया दें।
चरण 3: अपने परिणाम रिकॉर्ड करें
# 1) फिर से, चरण 1 में तय की गई विधि का उपयोग करके अपने परिणामों को रिकॉर्ड करें और रिपोर्ट करें।
#दो) परिवर्तन के लिए अपनी टिप्पणियों या सुझावों की रिपोर्टिंग करते समय, इसे दोष की रिपोर्टिंग से अलग नहीं समझें। कुछ भी अनदेखा न करें। विस्तृत हो।
जावा में एक बाइनरी सर्च ट्री बनाना
# 1) किसी को यह बताया जाना पसंद नहीं है कि उनका काम गलत या अधूरा है। इसलिए नकारात्मक प्रतिक्रिया प्रदान करते समय निम्नलिखित दिशा-निर्देशों का ध्यान रखें।
- रचनात्मक आलोचना प्रदान करें - याद रखें कि व्यक्ति की आलोचना न करें बल्कि इस उत्पाद की खामियों को इंगित करें
- प्रतिस्पर्धी मत बनो - सिर्फ इसलिए कि वह आपके परीक्षण मामलों पर 30 समीक्षा टिप्पणियों में बदल गया, इसे हरा करने की कोशिश न करें।
- अपनी टिप्पणियों को वापस करने के लिए कारण दें
#दो) एक साइन-ऑफ प्राप्त करें।
# 3) बदलाव किए हैं
चरण 5: संस्करण नियंत्रण शामिल दस्तावेज
# 1) किसी भी दस्तावेज़ के पुराने संस्करणों को हटाएं नहीं। उन्हें उचित नाम दें और उन्हें एक केंद्रीकृत परियोजना फ़ोल्डर में रखें। आखिरकार, यह हमारे सभी कार्यों का प्रमाण है
चरण 6: साइन ऑफ करें और उपयोग किए गए दस्तावेज़ का उपयोग करें
# 1) एक बार जब सभी परिवर्तन शामिल हो जाते हैं, तो संस्करण सहेजा जाता है, समीक्षा प्रक्रिया को एक साइन-ऑफ दें और इसके लिए दस्तावेज़ का उपयोग करने के लिए आगे बढ़ें।
#दो) एक और सवाल जो सामने आता है वह यह है कि क्या बदलाव किए जाने के बाद हम फिर से जाँच करते हैं? यह प्रक्रिया कितनी बार चल रही है - काम-समीक्षा-फिक्स-और फिर समीक्षा की गई? कब तक?
नहीं, समीक्षा को बार-बार होने की जरूरत नहीं है। यह एक गुणवत्ता नियंत्रण गतिविधि है जो सत्यापित करने पर ध्यान केंद्रित करती है कि परीक्षण सहायक सही बनाए गए हैं या नहीं। हमेशा की तरह, शून्य-दोष दस्तावेज़ असंभव हैं। तो समीक्षा का एक उचित स्तर- एक सहकर्मी द्वारा एक बार स्वीकार्य है।
वहाँ, आप कर रहे हैं। क्या यह प्रक्रिया सरल नहीं है?
याद दिलाने के संकेत
- प्रत्येक परियोजना को समीक्षा के इस औपचारिक तरीके का पालन करने की आवश्यकता नहीं है, लेकिन भले ही उनके पास एक अनौपचारिक विधि हो, ये कदम उम्मीद को स्थापित करने और आपका मार्गदर्शन करने में मदद करेंगे।
- परीक्षण प्रलेखन समय-समय के अनुमान आम तौर पर दस्तावेजों को बनाने और उनकी समीक्षा करने के लिए आवश्यक समय पर आधारित होते हैं- इसलिए इसे तब भी इनबिल्ट किया जाता है, जबकि हम इसे हमेशा नहीं पहचानते।
- समीक्षा एक प्रक्रिया नहीं है जो मैनुअल परीक्षण टीमों तक सीमित है। ऑटोमेशन टीमें कोड वॉकथ्रू, डिज़ाइन समीक्षा आदि भी करती हैं।
अंत में, यह है कि परीक्षण मामलों के लिए एक सामान्य समीक्षा टिप्पणियाँ दस्तावेज़ कैसा दिखता है। टिप्पणियाँ लाल रंग में हैं। जरूरी नहीं कि वास्तविक टिप्पणी हो, लेकिन यह कैसे किया जाए यह दिखाने के लिए कुछ।
नमूना परीक्षण के मामलों की समीक्षा दस्तावेज़: (छवि विस्तार के लिए क्लिक करें)
आप के लिए खत्म है
तो, क्या आपको अभी भी लगता है कि प्रक्रियाएं कठिन हैं? क्या आप अपनी परियोजनाओं में समीक्षा करते हैं? कृपया नीचे दिए गए अपने अनुभवों, चुनौतियों, प्रश्नों और टिप्पणियों को साझा करें।
लेखक के बारे में: ये है स्वाति सीला की एक पोस्ट - 9 साल के उद्योग के अनुभव के साथ मैनुअल और स्वचालन परीक्षण में एक विशेषज्ञ । वह हमारे सॉफ्टवेयर टेस्टिंग ट्रेनिंग कोर्स के लिए प्रशिक्षक भी हैं।
यदि आप विशेषज्ञों से सॉफ़्टवेयर परीक्षण सीखना चाहते हैं, तो हमारे आगामी बैच के लिए शेड्यूल की जांच करें और इस पृष्ठ पर इस पाठ्यक्रम के बारे में अधिक ।
अनुशंसित पाठ
- 4 कदम एजाइल प्रक्रिया के लिए सफल संक्रमण के लिए चुस्त परीक्षण मानसिकता का विकास
- सॉफ्टवेयर उत्पाद परीक्षण कैसे करें - उदाहरणों के साथ विस्तृत प्रक्रिया और तरीके
- बिज़नेस प्रोसेस टेस्टिंग (BPT) - BPT का उपयोग करके टेस्टिंग प्रोसेस को कैसे सरल और गति दें
- अटकलें फ़ीचर फ़ाइलों के लिए अचार के साथ जीवित प्रलेखन उत्पन्न करें
- सॉफ्टवेयर परीक्षण प्रलेखन गाइड (यह क्यों महत्वपूर्ण है)
- QA परीक्षक को रिलीज़ और परिनियोजन प्रबंधन प्रक्रिया के बारे में क्या पता होना चाहिए
- सरल उदाहरणों के साथ यूनिक्स में ग्रीप कमांड
- 6 सबसे महत्वपूर्ण कदम आपके टेस्ट रिपोर्ट को और भी बेहतर बनाते हैं