6 basic skills that every tester should have
सॉफ्टवेयर परीक्षण या क्यूए नए लोगों के लिए आईटी उद्योग में प्रवेश करने के लिए गलत धारणाओं के बावजूद सबसे अच्छा मंच है कि यह कम या अधिक भुगतान वाली नौकरी है।
सबसे महत्वपूर्ण कौशल जो एक परीक्षक की आवश्यकता है कीड़े खोजने की क्षमता । और, यदि आप उस व्यक्ति की तरह हैं जो बग ढूंढना पसंद करता है, तो आप इस क्षेत्र में प्यार करने और बढ़ने वाले हैं।
यह कहने के बाद, कुछ और कौशल हैं जो आपको बग ढूंढने में मदद कर सकते हैं और क्यूए प्रक्रियाओं के साथ बेहतर काम कर सकते हैं।
यह वह लेख है जो क्यूए प्रक्रिया को दिखाएगा क्योंकि यह अधिकांश कंपनियों में पालन किया जाता है और परीक्षण पर नए-परीक्षक स्पष्टीकरण देगा।
निम्नलिखित में से कौन सबसे लोकप्रिय परीक्षण ढांचे में से एक है?
विस्तार से, आप दस्तावेज़ीकरण प्रक्रिया और मानकों को सीखते हैं, परीक्षक के पूर्व काम, आंशिक विकास के दौरान परीक्षण, बाधाओं पर आधारित परीक्षण और अंत में साइन-ऑफ प्रक्रिया।
चलो शुरू करें।
आप क्या सीखेंगे:
- # 1 प्रलेखन
- # २। परीक्षण की तैयारी
- # 3 टेस्ट प्रक्रिया - क्या टेस्ट करें?
- # 4 आंशिक विकास के स्तर पर परीक्षण
- # 5 बग रिपोर्ट दस्तावेज़
- # 6 साइन-ऑफ प्रक्रिया
- निष्कर्ष
- अनुशंसित पाठ
# 1 प्रलेखन
परीक्षण के लिए प्रलेखन आवश्यक है। ज्यादातर कंपनियां इस काम को नए-नए लोगों को सौंपती हैं। सफल होने के लिए, आपके पास होना चाहिए अच्छी शब्दावली क्योंकि बाकी चीजें जैसे प्रलेखन मानक आदि आपके नियंत्रण में नहीं हैं और टीम की और कंपनी की प्रक्रियाओं पर निर्भर करते हैं।
इसके अलावा, सुनिश्चित करें कि आप प्रलेखन प्रक्रिया का मूल्य देखते हैं। फायदे कई हैं - वे आपको आवश्यकता परिवर्तन में मदद करते हैं, अपने परीक्षण चरणों का पता लगाते हैं, अपना काम करते हैं, आदि।
अनुशंसित पढ़ा=> क्यों सॉफ्टवेयर परीक्षण में प्रलेखन महत्वपूर्ण है
# २। परीक्षण की तैयारी
उपलब्ध सभी दस्तावेजों में से, निम्नलिखित को उपेक्षित नहीं किया जा सकता है। इन्हें डिलीवरी योग्य दस्तावेज भी कहा जाता है और ये क्लाइंट, डेवलपर और टेस्टर की समझ को बढ़ाते हैं।
a) टेस्ट प्लान: परीक्षण के प्रवाह को शुरू से अंत तक चार्ट करता है ।
परीक्षण योजना परीक्षण के चरण की गुंजाइश और गतिविधियों को चित्रित करती है। क्यूए लीड द्वारा निर्मित, टीम को परीक्षण योजना में लिखे गए सभी चीजों के बारे में अद्यतन और योगदान करना है।
कुछ टीमों के पास परीक्षण योजनाओं के कई स्तर हैं: मास्टर प्लान और चरण वार योजनाएं।
एक परीक्षण योजना होनी चाहिए:
- प्रोजेक्ट का नाम और संस्करण
- टेस्ट प्लान आइडेंटिफायर्स - क्रिएटर, ड्राफ्ट नं।, डेट क्रिएट, आदि।
- परिचय - परियोजना, उद्देश्य और बाधाओं का अवलोकन
- संदर्भ - इनपुट के रूप में प्रयुक्त संदर्भों की सूची। (सुनिश्चित करें कि आप सटीक और नवीनतम संस्करणों का उपयोग करते हैं)
- टेस्ट आइटम - मॉड्यूल, संस्करण, गुंजाइश, दायरे से बाहर, आदि।
- ओवरऑल टेस्ट एप्रोच / टेस्ट रणनीति - उपकरण का उपयोग करना, ट्रैकिंग प्रक्रिया को दोष देना, प्रदर्शन करने के लिए परीक्षण के स्तर आदि।
- पास / असफल आइटम मानदंड - परीक्षण निष्पादन दिशानिर्देश
- निलंबन और बहाली मानदंड
- टेस्ट डिलिवरेबल्स - टेस्ट केस, टेस्ट रिपोर्ट्स, बग रिपोर्ट, टेस्ट मेट्रिक्स आदि।
- पर्यावरण विवरण का परीक्षण करें
- टीम रोस्टर प्वाइंट-ऑफ-संपर्क जानकारी के साथ। प्रत्येक मॉड्यूल या परीक्षण प्रकार के लिए
- टेस्ट अनुमान - समय और प्रयास। बजट विवरण गोपनीय होते हैं और आप उन्हें यहां नहीं पाएंगे
- जोखिम और शमन योजना
- स्वीकृति
- अन्य दिशा-निर्देश
यह भी पढ़ें=>
ओरेकल एसक्यूएल क्वेरी अनुभवी पीडीएफ के लिए सवाल और जवाब का साक्षात्कार करती है
- स्क्रैच से टेस्ट प्लान डॉक्यूमेंट कैसे लिखें
- टेस्ट प्लान प्रारूप
- वास्तविक परीक्षा योजना उदाहरण (पीडीएफ) (डाउनलोड)
बी) परीक्षण परिदृश्य:
प्रत्येक आवश्यकता के आधार पर to क्या परीक्षण करना है ’पर एक पंक्ति इंगित करता है और आमतौर पर स्प्रेडशीट के माध्यम से दस्तावेज और ट्रैक किया जाता है।
उनमें से अधिकांश में शामिल हैं:
- मॉड्यूल / घटक / फ़ंक्शन नाम (लॉगिन, व्यवस्थापक, पंजीकरण, आदि)
- परिदृश्य आईडी संदर्भ के लिए है (जैसे: TS_Login_001)
- परिदृश्य विवरण - to क्या टेस्ट करना है। उदाहरण: यदि लॉगिन उपयोगकर्ताओं को मान्य क्रेडेंशियल्स के साथ सफलतापूर्वक लॉगिन करने की अनुमति देता है
- परिदृश्य महत्व - अपर्याप्त समय के मामले में प्राथमिकता देने के लिए - उच्च / मध्यम / निम्न
- आवश्यकता आईडी - ट्रेसबिलिटी के लिए
अग्रिम पठन=>
ग) परीक्षण के मामले:
सटीक परीक्षण के मामले सटीक परीक्षा परिणाम देते हैं। स्प्रेडशीट अभी भी टेस्ट केस राइटिंग के लिए लोकप्रिय माध्यम है, खासकर शुरुआती लोगों के लिए, भले ही कुछ कंपनियां टेस्ट मैनेजमेंट टूल्स को अपनाती हैं। टेस्ट केस राइटिंग का आधार SRS / FRD / Req डॉक्यूमेंट है। लेकिन, यह अक्सर पर्याप्त नहीं होता है, इसलिए आपको बीए / देव टीमों के साथ बहुत अधिक धारणा और चर्चा का उपयोग करना होगा।
प्रभावी परीक्षण मामलों को लिखना एक परीक्षक के पास सबसे महत्वपूर्ण योग्यता होनी चाहिए। आमतौर पर, सभी परीक्षण मामलों को सकारात्मक / नकारात्मक के रूप में वर्गीकृत किया जाता है। सकारात्मक परीक्षण मामला मान्य इनपुट दे रहा है और सकारात्मक परिणाम प्राप्त कर रहा है। नकारात्मक परीक्षण मामला अमान्य इनपुट दे रहा है और सटीक त्रुटि संदेश प्राप्त कर रहा है।
इन पर अधिक जानकारी के लिए, जाँच करें:
सभी परीक्षण मामलों में से कुछ सामान्य विशेषताएं हैं:
- परिदृश्य आईडी - परीक्षण परिदृश्य दस्तावेज़ से लिया गया
- टेस्ट केस आईडी - विशिष्ट पहचान और ट्रैकिंग के लिए। जैसे: TC_login_001
- परीक्षण विवरण - परीक्षण की गई स्थिति की संक्षिप्त व्याख्या
- निष्पादित करने के चरण - परीक्षण करने के तरीके के बारे में निर्देश द्वारा विस्तृत कदम
- परीक्षण डेटा - परीक्षण चरणों के लिए आपूर्ति की गई डेटा
- अपेक्षित परिणाम - अपेक्षा के अनुरूप परिणाम
- वास्तविक परिणाम - परीक्षण चलाने पर ऑटो का जवाब
- स्थिति - पास / असफल / कोई रन / अपूर्ण / अवरुद्ध - परीक्षण के परिणाम का वर्णन करता है
- टिप्पणियाँ - अतिरिक्त विवरण के लिए
- द्वारा निष्पादित - परीक्षक का नाम
- निष्पादित तिथि - वह तिथि जिस पर परीक्षण चलाया जाता है
- दोष आईडी - परीक्षण की विफलता के मामले में परीक्षण के मामले में दोष लॉग हुआ
- कॉन्फ़िगरेशन विवरण - OS, ब्राउज़र, प्लेटफ़ॉर्म, डिवाइस जानकारी (वैकल्पिक)
अनुशंसित पढ़ा=>
# 3 टेस्ट प्रक्रिया - क्या टेस्ट करें?
बड़ी संख्या में परीक्षण प्रकार हैं, लेकिन उन सभी को उस ऑटो पर नहीं किया जा सकता है। समय, बजट, व्यवसाय की प्रकृति, अनुप्रयोग की प्रकृति, और ग्राहक की रुचि आवेदन पर क्या परीक्षण करना है, इसके विकल्प में प्रमुख खिलाड़ी हैं।
उदाहरण के लिए: यदि यह एक ऑनलाइन वाणिज्य पोर्टल है, तो तनाव परीक्षण और लोड परीक्षण अनिवार्य है। हालांकि, परीक्षण के कुछ प्रकार जो याद नहीं होने चाहिए, वे हैं:
- ब्लैक बॉक्स परीक्षण
- ग्रे बॉक्स परीक्षण
- इकाई का परीक्षण (यदि लागू हो)
- एकीकरण जांच
- वृद्धिशील एकीकरण परीक्षण
- प्रतिगमन परीक्षण
- क्रियात्मक परीक्षण
- निवृत्त हो रहा है
- स्वच्छता परीक्षण
- धुआँ परीक्षण
- स्वीकृति परीक्षण
- उपयोगिता परीक्षण
- संगतता परीक्षण
- एंड टू एंड टेस्टिंग
- अल्फा परीक्षण
- बीटा परीक्षण
# 4 आंशिक विकास के स्तर पर परीक्षण
आम तौर पर, मध्यम स्तर और स्टार्ट-अप कंपनियों के साथ सीमित समय और संसाधन होते हैं। मॉड्यूल एकीकरण से पहले यहां परीक्षक अपनी परीक्षण प्रक्रिया शुरू कर सकते हैं, जिसका अर्थ है कि हम इकाई और मध्यस्थ एकीकरण परीक्षण कर रहे हैं।
यह ध्यान रखना महत्वपूर्ण है कि इन चरणों के परिणामों को सटीक रूप से नहीं गिना जा सकता है, इसलिए आपको सब कुछ तैयार होने के बाद एक समग्र ब्लैक बॉक्स टेस्ट की योजना बनानी पड़ सकती है। उस भाग को देखना महंगा और परीक्षण, अप्रभावी साबित हो सकता है।
# 5 बग रिपोर्ट दस्तावेज़
हाथों पर, यह सबसे महत्वपूर्ण क्यूए दस्तावेज़ है जो आप कभी भी बना रहे होंगे।
निम्नलिखित फ़ील्ड एक अच्छी बग रिपोर्ट होनी चाहिए:
- दोष आईडी - आमतौर पर एक सीरियल नंबर
- दोष विवरण - समस्या की एक पंक्ति व्याख्या
- स्थान - ऑटो का मॉड्यूल / क्षेत्र जहां समस्या पाई जाती है
- बिल्ड नंबर - वर्जन और कोड बिल्ड नं।
- पुन: उत्पन्न करने के लिए कदम - उन चरणों की सूची जो आपको समस्या की ओर ले जाती हैं
- गंभीरता - समस्या की गंभीरता का वर्णन करने के लिए एक स्तर निर्धारित करें - निम्न, मध्यम, उच्च, अवरोधक, आदि।
- प्राथमिकता - डेवलपर्स द्वारा उस क्रम को निर्धारित करने के लिए सेट करें जिसमें दोष तय किया जाएगा (पी 1, पी 2, पी 3, आदि। पी - 1)
- उस समय के दोष के मालिक - को सौंपा
- द्वारा रिपोर्ट की गई - परीक्षक का नाम
- स्थिति - बग जीवन चक्र चरण का प्रतिनिधित्व करने के लिए अलग स्थिति
- नया - बग पाया जाता है और बस रिपोर्ट किया जाता है
- ओपन - क्यूए लीड द्वारा मान्य
- असाइन किया गया - संबंधित डेवलपर को असाइनमेंट के लिए देव लीड को भेजा गया
- प्रगति / कार्य में प्रगति - देव ने इस पर काम करना शुरू कर दिया
- फिक्स्ड / रिज़ॉल्यूशन - डेवलपर इस पर काम कर रहा है
- सत्यापित / बंद - क्यूए टीम सेवानिवृत्त हो गई है और बग को तय किया गया है
- रीस्टेस्ट - क्यूए टीम देव के संकल्प से सहमत नहीं है और आगे के लिए बग को आगे बढ़ाने के लिए प्रगति कर रही है
- डुप्लिकेट - समान बग पहले से मौजूद है
- आस्थगित - वैध बग लेकिन बाद के रिलीज में तय किया जाएगा
- अमान्य - बग नहीं है या प्रतिलिपि प्रस्तुत करने योग्य नहीं है या पर्याप्त जानकारी नहीं है
अग्रिम पठन=>
- कैसे एक अच्छी बग रिपोर्ट लिखने के लिए
- नमूना बग रिपोर्ट
- कैसे बाजार और अपने कीड़े तय हो जाओ
- क्यों बग रिपोर्टिंग एक कला है
# 6 साइन-ऑफ प्रक्रिया
साइन ऑफ़ और अंतिम दस्तावेज भेजना क्यूए लीड / मैनेजर का काम है। हालांकि, टीम को अंतिम समीक्षा और ऑडिट के लिए उपरोक्त दस्तावेज (टेस्ट परिदृश्य, टेस्ट केस, और दोष लॉग दस्तावेज) जमा करने होंगे।
सुनिश्चित करें, आप उन सभी को प्रूफ़ करते हैं और अंतिम संस्करण भेजते हैं।
यह भी पढ़ें=>
- एक प्रभावी टेस्ट सारांश रिपोर्ट कैसे लिखें
- कैसे करें टेस्ट एक्जामिनेशन की रिपोर्ट स्मार्ट
- नमूना परीक्षण सारांश रिपोर्ट (डाउनलोड)
निष्कर्ष
यह प्रक्रिया है जैसा कि मैंने पहली बार देखा और अनुभव किया है जब मैं एक परीक्षक था और मुझे आशा है कि इसने आपको कुछ उपयोगी संकेत दिए हैं।
अंत में, परीक्षण में एक कैरियर मेरे लिए एक पूर्ण आनंद रहा है और मुझे आशा है कि यह आपके लिए भी है।
Android के लिए शीर्ष 5 एमपी डाउनलोडर
आपके करियर के लिए शुभकामनाएँ!
अनुशंसित पाठ
- सर्वश्रेष्ठ सॉफ्टवेयर परीक्षण उपकरण 2021 (क्यूए टेस्ट स्वचालन उपकरण)
- अल्फा परीक्षण और बीटा परीक्षण (एक पूर्ण गाइड)
- परीक्षण प्राइमर eBook डाउनलोड
- कार्यात्मक परीक्षण बनाम गैर-कार्यात्मक परीक्षण
- अपने सॉफ्टवेयर परीक्षण के बुनियादी ज्ञान की जाँच के लिए 20 सरल प्रश्न (ऑनलाइन क्विज़)
- सही सॉफ्टवेयर परीक्षण फिर से शुरू गाइड (सॉफ्टवेयर परीक्षक पुनरारंभ नमूना के साथ)
- वेरिफिकेशन टेस्टिंग (BVT टेस्टिंग) कम्प्लीट गाइड का निर्माण करें
- बहु-भाषी वेबसाइटों के परीक्षण के लिए 7 मूल सुझाव