7 step practical implementation manual testing before production release
मैन्युअल परीक्षण के आसपास इस श्रृंखला के पिछले पोस्ट में, मैंने मैनुअल परीक्षण की मूल बातें पर जितना संभव हो उतना प्रकाश फेंकने की कोशिश की।
यदि आप इसे याद किया, आप इसे यहां पढ़ सकते हैं ।
मुझे आशा है कि आप जिन उत्तरों की तलाश कर रहे थे, उन्हें जितना संभव हो उतना करीब ले जाने में सफल रहा।
उस मामले में, क्या आप मैन्युअल परीक्षण के व्यावहारिक कार्यान्वयन के बारे में अधिक जानना पसंद नहीं करेंगे, इससे कैसे परिचित हों और वास्तव में इसमें करियर कैसे शुरू करें?
यह लेख इन सभी पहलुओं पर प्रकाश डालेगा।
चलो शुरू करते हैं।
आप क्या सीखेंगे:
- मैनुअल परीक्षण चक्र
- उत्पादन रिलीज से पहले 7 व्यावहारिक मैनुअल परीक्षण कदम
- (1) आवश्यकता सभा
- # 2) आवश्यकता चर्चा / साझा करना
- # 3) डिजाइनिंग
- # 4) टेस्ट परिदृश्य / टेस्ट केस डिजाइनिंग
- # 5) विकास चरण
- # 6) परीक्षण चरण
- # 7) व्यापार विश्लेषक (बीए) की समीक्षा
- # 8) शिपमेंट / रिलीज
- मैनुअल के प्रकार (मानव पढ़ें) परीक्षण
- अनुशंसित पाठ
मैनुअल परीक्षण चक्र
समझ में मैनुअल परीक्षण चक्र या सॉफ्टवेयर टेस्ट लाइफ साइकिल (एसटीएलसी), सबसे पहले, हमें सॉफ्टवेयर डेवलपमेंट लाइफ साइकिल (एसडीएलसी) को समझने की जरूरत है, जो मुझे यकीन है कि आपको पहले से ही समझ है।
लोग उन्हें अलग से संदर्भित करते हैं लेकिन यह सुनिश्चित नहीं करते हैं कि क्या वे वास्तव में सह-अस्तित्व में हो सकते हैं। वे एक दूसरे के साथ कसकर एकीकृत हैं। खैर, यहां तक कि इन चक्रों के भी बहुत सारे संस्करण हैं जो इंटरनेट स्पेस में निर्मित और तैरते हैं, वे अलग-अलग होते हैं, जिस पर विकास मॉडल का चयन किया जाता है।
अधिकांश के रूप में दुनिया चपल हो रही है इन दिनों, मैं एजाइल के आसपास अपने सामान को सरल बनाए रखूंगा।
उत्पादन रिलीज से पहले 7 व्यावहारिक मैनुअल परीक्षण कदम
लो मैं चला।
याद रखें मैं SDLC और STLC दोनों के बारे में बात कर रहा हूँ।
(1) आवश्यकता सभा
बिजनेस एनालिस्ट (पर्सन / टीम रिक्वायरमेंट फॉर रिक्वायरमेंट गैदरिंग) आवश्यकताओं का दस्तावेज बनाता है। वे आवश्यकताओं का दस्तावेज है, इस पर प्रकाश डाला गया है, आप केवल उसी पर ध्यान केंद्रित रख सकते हैं। जहां यह प्रलेखित मामलों से कम है।
लोग इनका दस्तावेजीकरण करने के लिए कुछ भी इस्तेमाल करते हैं जो उन पर सूट करता है, लेकिन पारंपरिक शब्दों जैसे कि एमएस वर्ड डॉक, जीरा / रैली जैसे आधुनिक प्लेटफॉर्म और ट्रेलो जैसे नए युग के टूल तक सीमित नहीं है।
# 2) आवश्यकता चर्चा / साझा करना
बिजनेस एनालिस्ट को तब डॉक्यूमेंटेड रिक्वायरमेंट्स को डेवलपमेंट टीम, टेस्टिंग टीम और यूएक्स टीम (यदि आवश्यक हो) के साथ साझा करना चाहिए। यह आमतौर पर एक औपचारिक बैठक के माध्यम से होता है जहां एसपीओसी (संपर्क के एक बिंदु या एक पूरी टीम, यह निर्भर करता है) तीनों कार्यों से मिलता है और पूरी आवश्यकता को समझता है।
एक स्वस्थ कार्य संस्कृति में, आवश्यकताओं को हर कोण से चर्चा मिलती है और बैठक के प्रत्येक सदस्य प्रश्न और संदेह पूछ सकते हैं। एक बार जब सभी प्रश्नों का उत्तर दिया जाता है और आवश्यकता में संशोधन किया जाता है, तो इस चरण को पूर्ण माना जा सकता है। फिर क्या कोई इस विशेष बैठक / कदम को बुलाता है और इसका प्रलेखन कंपनी के लिए अलग-अलग है।
अग्रिम पठन=> SRS दस्तावेज़ की समीक्षा कैसे करें
एक बार सभी सवालों के जवाब देने और आवश्यकता में संशोधन करने के बाद, इस चरण को माना जा सकता है किया हुआ ।
फिर क्या कोई इस विशेष बैठक / कदम को बुलाता है और इसका प्रलेखन कंपनी के लिए अलग-अलग है।
उदाहरण के लिए, प्रलेखन को SRS (सिस्टम रिक्वायरमेंट स्पेसिफिकेशन), रिक्वायरमेंट डॉक्यूमेंट, एपिक, यूजर स्टोरी, स्टोरी पॉइंट (संभवतः, सबसे छोटी आवश्यकता यूनिट), आदि के रूप में कहा जाता है। इसी तरह की तर्ज पर, इस मीटिंग को जिसमें आवश्यकता साझा की जाती है, कहा जाता है। आवश्यकता चर्चा बैठक, सौंदर्य, होल-पंच बैठक, आदि, मुझे आशा है कि आपको मेरी बात मिल जाएगी?
इन शब्दावली पर दबाव डालना ताकि आप हमेशा विभिन्न नामों के बावजूद मुख्य विचार को याद रखें।
इस बैठक के बाद दो चरणों को एक ही समय में ट्रिगर किया जाता है, किसी विशेष क्रम में, अगले दो चरणों को देखें।
# 3) डिजाइनिंग
विकास टीम आवश्यकताओं की चर्चा करते ही और जब कोई बड़ी लंबित बात नहीं होती है तो उनकी तकनीकी डिजाइनिंग के साथ शुरू होती है। इस चरण में क्या किया जाता है फिर से कंपनी के लिए कंपनी में अंतर होता है।
यह चरण शामिल हो सकता है लेकिन निम्नलिखित कार्यों तक सीमित नहीं है:
- विकास के दृष्टिकोण को तय करना
- डिजाइन दस्तावेज तैयार करना
- प्रवाह चार्टों को डिज़ाइन करना
- प्रयासों का अनुमान
- किसी भी मौजूदा कार्यक्षमता पर इस नई आवश्यकता के प्रभाव का पता लगाना
- मौजूदा डेटा को पैच करने की आवश्यकता है, आदि।
UX टीम इस चरण में शामिल हो सकती है जब UI परिवर्तन होता है या नई स्क्रीन विकसित करनी होती है। UX टीम विकास टीम और परीक्षण टीम को चर्चा में कार्यक्षमता / सुविधा के लिए UI प्रोटोटाइप के साथ मदद करती है। यह एक फ़ोटोशॉप दस्तावेज़, सरल छवि, पावरपॉइंट प्रस्तुति या कुछ और हो सकता है जो विकास टीम को यह समझाएगा कि स्क्रीन कैसे विकसित की जानी चाहिए।
ध्यान दें: आदर्श रूप में ये स्क्रीन या कम से कम उनके ड्राफ्ट संस्करण, केवल आवश्यकता समझ सत्र में दिखाए जाते हैं ताकि टीम को बेहतर समझ बनाने में मदद मिल सके। इसे मूल आवश्यकता के लिए टैग किया जाता है ताकि इसे किसी भी समय संदर्भित किया जा सके।
# 4) टेस्ट परिदृश्य / टेस्ट केस डिजाइनिंग
डिजाइनिंग चरण के समानांतर, परीक्षण टीम चर्चा की आवश्यकताओं के आधार पर टेस्ट परिदृश्यों और / या टेस्ट मामलों के निर्माण के साथ शुरू होती है। क्या टेस्ट परिदृश्य हमेशा पहले लिखे जाते हैं और फिर टेस्ट के मामलों में टूटते हैं, जो फिर से स्थिर नहीं है।
मेरी राय में, आप टेस्ट परिदृश्यों का दस्तावेजीकरण करते हैं या नहीं, वे हमेशा टेस्ट मामलों से पहले होते हैं। टेस्ट परिदृश्य आपकी बुलेट बिंदु है जिसे आप कह सकते हैं, वे आपको चीजों को और नीचे लाने के लिए मार्गदर्शन करते हैं। एक बार टेस्ट केस राइटिंग खत्म हो जाने के बाद, इसे डेवलपमेंट टीम के साथ साझा किया जा सकता है ताकि उन्हें टेस्टिंग स्कोप का अंदाजा हो सके और वे यह भी सुनिश्चित कर सकें कि जो विकास हुआ है या हुआ है वह लिखित टेस्ट के मामलों को संतुष्ट कर रहा है।
एक बार टेस्ट केस राइटिंग खत्म हो जाने के बाद, इसे डेवलपमेंट टीम के साथ साझा किया जा सकता है ताकि उन्हें टेस्टिंग स्कोप का अंदाजा हो सके और वे यह भी सुनिश्चित कर सकें कि जो विकास हुआ है या हुआ है वह लिखित टेस्ट के मामलों को संतुष्ट कर रहा है।
एक बार लिखे गए टेस्ट मामलों को आदर्श रूप से टेस्ट लीड या सहकर्मी द्वारा कई कोणों से समीक्षा की जाती है:
- आवश्यकता कवरेज
- वर्तनी व्याकरण
- टेस्ट केस लिखने के मानक (कुछ भी नहीं है लेकिन एक टीम जिसे कंपनी / कंपनी अनुसरण करती है)
- अनिच्छुक अनुकूलता
- मंच की अनुकूलता
- डेटा संदर्भ का परीक्षण करें
- लक्षित परीक्षण के प्रकार, आदि।
अग्रिम पठन=> एसआरएस दस्तावेज़ से परीक्षण मामलों को लिखना
आदर्श रूप से, केवल समीक्षा और संशोधन की आवश्यकता के बाद, उन्हें विकास टीम में पारित किया जाता है।
जब मैंने कहा कि I एक बार टेस्ट केस लेखन समाप्त हो गया है ’, मेरा मतलब था कि एक बार test सभी टेस्ट केस दिए गए आवश्यकता के पूर्ण ज्ञान और उस विशेष समय तक खुला परीक्षण परिदृश्यों के आधार पर लिखे जाते हैं’। पहली बार में 100% टेस्ट केस कवरेज होना असंभव है।
दोष होंगे जो आपको यादृच्छिक (लेकिन इच्छित) कार्यों में, विशुद्ध रूप से यादृच्छिक कार्यों (बंदर परीक्षण) और कुछ दुर्लभ परिदृश्यों में मिलेंगे। संभावना है कि आप इनमें से कुछ पर चूक जाएंगे। और किसी समय आप बहुत बुनियादी लोगों को याद कर सकते हैं, आखिरकार, आप मानव हैं। लेकिन यहां, कम से कम एक अच्छा टेस्ट केस रिव्यू और टेस्ट केस राइटिंग का संरचित तरीका आपको बचा सकता है।
अधिक बार नहीं, एक परीक्षक या परीक्षण टीम मौजूदा चंक को अधिक से अधिक परीक्षण मामलों को जोड़कर रखती है क्योंकि वे सच्चाई को उजागर करते हैं या आवश्यकताओं के बारे में अधिक सोचते हैं।
खैर, अब तक आप में से कुछ सॉफ्टवेयर टेस्टिंग के मेरे ज्ञान पर संदेह कर रहे होंगे क्योंकि कुछ शब्द (जो सॉफ्टवेयर टेस्टिंग में एक आदर्श बन गया है) अभी तक मेरे द्वारा उपयोग नहीं किया गया है। टेस्ट प्लान सही है?
मुझे इस पर कुछ कहना है। मुझे विश्वास है कि टेस्ट प्लान में वर्णित अधिकांश सूचनाओं की आवश्यकता है, लेकिन उन सभी को एक ही स्थान पर प्रलेखित करना और इसे पूर्ण अनिवार्य बनाना कुछ ऐसा है जो मुझे विवादस्पद लगता है।
वैसे भी, चर्चा के लिए एक अलग विषय है। इस पर सभी 'जानकारी साझा करना मुश्किल है, लेकिन मुझे प्रयास करने दें।
या तो आप, आप अपने टेस्ट लीड के साथ या अपने टेस्ट लीड के लिए टेस्ट प्लान तैयार करते हैं या आप विभिन्न स्थानों पर आवश्यक जानकारी का दस्तावेजीकरण करते हैं।
अग्रिम पठन=> टेस्ट प्लान डॉक्यूमेंट कैसे लिखें
सूचना जो इस स्तर पर बिल्कुल जमी होनी चाहिए:
- परीक्षण का दायरा: आवश्यकता, पिछड़ी संगतता, प्लेटफ़ॉर्म, उपकरण, आदि
- व्यक्ति / टीम जो परीक्षण करने जा रही है
- परीक्षण के प्रयास का अनुमान
- सीमाएं: अग्रिम में स्वीकार की गई कोई भी धारणा या सीमाएँ।
- लोग अतिरिक्त रूप से दस्तावेज़ प्रविष्टि मानदंड, निकास मापदंड, जोखिम, आदि जो मुझे लगता है कि वास्तव में अलग उल्लेख की आवश्यकता नहीं है क्योंकि यह एक सामान्य समझ होनी चाहिए।
- प्रवेश मानदंड (जब परीक्षण शुरू करने के लिए): कुछ परीक्षण के लिए उपलब्ध कार्यक्षमता का परीक्षण योग्य हिस्सा है जब शुरू करते हैं। पूरी कार्यक्षमता के परीक्षण योग्य होने की प्रतीक्षा करें। एक बार जब मूल प्रवाह काम करने लगता है, तो परीक्षण शुरू हो जाता है।
- मानदंड से बाहर निकलें (कब बंद करें): जब कोई अवरोधक नहीं होता है, तो महत्वपूर्ण और प्रमुख (प्रभाव के अधीन) खुले चरण के परीक्षण में दोषों को रोका जा सकता है। या मध्य-मार्ग में, जब रास्ते में बहुत सारे दोष होते हैं, तो परीक्षण को उचित हितधारकों द्वारा रोका जा सकता है।
- जोखिम : व्यवसायिक जोखिम या कार्यात्मक जोखिम अगर परीक्षण दस्तावेज योजना के अनुसार नहीं होता है।
# 5) विकास चरण
चरण डिजाइन करने के बाद विकास टीम वास्तविक विकास और इकाई परीक्षण के साथ शुरू होती है जब और उन्हें परीक्षण योग्य आवश्यकता के विकास के साथ किया जाता है। जब यह कार्यान्वित किया जाता है या वे एक ही बार में पूरी कार्यक्षमता पास कर सकते हैं, तो वे विखंडू में परीक्षण के लिए कार्यक्षमता पर पारित कर सकते हैं।
एक आदर्श परिदृश्य में, औपचारिक कोड समीक्षा और परीक्षण के लिए विकसित कार्यक्षमता पर पारित होने से पहले सफेद बॉक्स परीक्षण होता है। आदर्श रूप से, विकास टीम को परीक्षण टीम द्वारा प्रदान किए गए परीक्षण मामलों को आवश्यकताओं और डिज़ाइन दस्तावेजों के अतिरिक्त भी संदर्भित करना चाहिए।
# 6) परीक्षण चरण
जैसा कि पहले उल्लेख किया गया है, इस चरण की शुरुआत कंपनी से कंपनी, टीम से टीम में भिन्न होती है।
परीक्षण टीम या तो तब परीक्षण शुरू करती है जब परीक्षण योग्य (किसी चीज का स्वतंत्र रूप से परीक्षण किया जा सकता है) संपूर्ण आवश्यकता का हिस्सा विकसित हो जाता है या जब पूरी आवश्यकता विकसित हो जाती है।
.swf फ़ाइल क्या है?
मुझे इस चरण में आगे बढ़ने और महत्वपूर्ण कार्यों के बारे में बात करने दें:
- परीक्षक / परीक्षण टीम परीक्षण दौर (खोजपूर्ण परीक्षण और लिखित परीक्षा मामलों के निष्पादन) और लॉगिंग दोषों के साथ शुरू होती है
- विकास दल उन्हें प्राथमिकता के अनुसार हल करता है।
- नया बिल्ड (कोड) पर्यावरण पर लिया गया है जिस पर परीक्षण हो रहा है
- हल किए गए दोषों को तब परीक्षक / परीक्षण टीम द्वारा सत्यापित किया जाता है और फिक्स्ड के रूप में चिह्नित किया जाता है
- यह चक्र तब तक जारी रहता है जब तक कि बाहर निकलने का मापदंड नहीं हो जाता।
- कृपया ध्यान दें कि आवश्यकतानुसार, दोषों को अमान्य, डुप्लिकेट के रूप में भी चिह्नित किया जाता है और संवर्द्धन के रूप में भी वर्गीकृत किया जा सकता है।
एक और बात जो कंपनी को कंपनी से अलग करती है वह है परीक्षण के कितने दौर। जैसे कुछ मामलों में, परीक्षण का पहला दौर छोटे फीचर भागों पर होता है क्योंकि वे तैयार होते हैं, इसके बाद दूसरे पर्यावरण पर एंड-टू-एंड परीक्षण दौर होता है जब सभी आवश्यकताओं का विकास हो जाता है। लेकिन फिर से, मैंने लोगों को तीन उचित पूर्ण परीक्षण दौर और चौथे के रूप में पवित्रता / धूम्रपान दौर के बारे में सुना है।
कई परीक्षण राउंड करने के पीछे पहला एजेंडा विभिन्न परिवेशों पर कार्यक्षमता का परीक्षण कर रहा है और दूसरा सभी कहानी बिंदुओं के विकसित होने के बाद एंड-टू-एंड परीक्षण करने के लिए। एक रिलीज में सभी कहानियों को विकसित करने और स्वतंत्र रूप से परीक्षण किए जाने के बाद सनिटी राउंड आमतौर पर त्वरित आत्मविश्वास हासिल करने के लिए होता है।
विस्तृत कदम पढ़ें=> परीक्षण निष्पादन चरण
# 7) व्यापार विश्लेषक (बीए) की समीक्षा
व्यावसायिक विश्लेषक परीक्षा परिणाम के संदर्भ में या परीक्षण परिणाम के संदर्भ में या साथ ही वास्तविक अनुभव प्राप्त करने के लिए आवेदन के साथ खेलने के संदर्भ में पूछी गई कार्यक्षमता की समीक्षा करता है। यह कदम फिर से कंपनियों के विभिन्न कार्यों के अधीन है।
बीए एक बार में या विखंडू में संपूर्ण रिलीज के दायरे की समीक्षा कर सकता है। उसी के आधार पर, यह चरण अंतिम विवेक परीक्षण से पहले या परीक्षण टीम द्वारा अंतिम पवित्रता परीक्षण दौर के बाद आ सकता है।
7 से ऊपर चरण सभी उपयोगकर्ता कहानियों / आवश्यकताओं के लिए होता है जो विशेष रूप से रिलीज़ (शिपमेंट) में पूरी की जाती हैं। एक बार जब ये सभी चरण सभी आवश्यकताओं के लिए पूरे हो जाते हैं, तो रिलीज को शिपमेंट के लिए तैयार होना कहा जाता है।
# 8) शिपमेंट / रिलीज
रिलीज को व्यावसायिक विश्लेषक द्वारा रेडी फॉर शिपमेंट पोस्ट सफल समीक्षा के रूप में चिह्नित किया गया है।
अनुशंसित पढ़ा=> परीक्षण की रिलीज प्रक्रिया
मैनुअल के प्रकार (मानव पढ़ें) परीक्षण
खैर अगर हमें संख्याओं में समग्र प्रकार के परीक्षण के बारे में बात करनी है तो कहीं न कहीं मैंने पाया है विभिन्न नामों के साथ 100 प्रकार के परीक्षण । सच कहूं तो मैं उन सभी प्रकारों के बीच अंतर को समझने के लिए पर्याप्त स्मार्ट नहीं हूं (जैसे कि इरादा)।
यह सीधा और सरल है: मानव प्रयासों और बुद्धि के साथ दिए गए आवश्यकता के खिलाफ आवेदन की कार्यक्षमता का परीक्षण करना। यह आगे चलकर परीक्षण के दायरे और कार्यसूची के आधार पर कुछ प्रकारों में विभाजित हो जाता है। अगले पैरा में सूचीबद्ध प्रकार।
यह आगे चलकर परीक्षण के दायरे और कार्यसूची के आधार पर कुछ प्रकारों में विभाजित हो जाता है। अगले पैरा में सूचीबद्ध प्रकार।
यदि मुझे अनुमति दी जाती है, तो मुझे मानव परीक्षण की कुछ पंक्तियाँ बोलने दें (जो कि मैं प्रत्येक परीक्षक को केवल मैनुअल कार्यात्मक परीक्षण करने के लिए प्रोत्साहित करता हूं)। अब भ्रमित मत होइए, मेरे विचार में मैनुअल कार्यात्मक परीक्षण मानव परीक्षण का सबसेट है। क्योंकि ऐसी बहुत सी चीजें हैं जो केवल ह्यूमन माइंड ही कर सकता है।
नीचे कुछ लोकप्रिय और महत्वपूर्ण परीक्षण प्रकारों के साथ सूची दी गई है जिन्हें मानव परीक्षण में वर्गीकृत किया जा सकता है:
- मैनुअल कार्यात्मक परीक्षण : मानव प्रयासों और बुद्धि के साथ दिए गए आवश्यकता के खिलाफ आवेदन की कार्यक्षमता का परीक्षण करना। आगे और परीक्षण के कार्यक्षेत्र के आधार पर काफी कुछ प्रकारों में विभाजित हो जाता है, जैसे सिस्टम टेस्टिंग, यूनिट टेस्टिंग, स्मोक टेस्टिंग, स्वच्छता परीक्षण, एकीकरण परीक्षण, प्रतिगमन परीक्षण, यूआई परीक्षण इत्यादि।
- प्रदर्शन का परीक्षण : इसे NonFunctional परीक्षण में वर्गीकृत किया गया है? लेकिन फिर से यह मानव है जो इसे लागू करता है, हालांकि निष्पादन मानव या उपकरण द्वारा किया जाता है। परीक्षक को कम से कम प्रतिक्रिया समय (यह देखने के लिए कि क्या यह स्वीकार्य है) के संदर्भ में यह परीक्षण करना चाहिए, यदि वह लोड परीक्षण और सभी के लिए किसी उपकरण का उपयोग करने के लिए नहीं है।
- ब्राउज़र / प्लेटफॉर्म संगतता परीक्षण: परीक्षण के तहत आवेदन को अपेक्षा के अनुसार देखना चाहिए और काम करना चाहिए (जाहिर है कि ब्राउज़र इंजन के आधार पर एक मामूली अंतर हो सकता है) और प्लेटफार्मों (या यदि यह एक मोबाइल एप्लिकेशन है तो डिवाइस)।
- उपयोगिता परीक्षण : मुझे सबसे पहले सहमत होना चाहिए कि यह अपने आप में एक बहुत बड़ा विषय है और आमतौर पर प्रयोज्य परीक्षण के विशेषज्ञों के स्वामित्व में है। मेरा अब भी मानना है कि एक परीक्षक के रूप में हमें कम से कम रिपोर्ट या हाइलाइट करना चाहिए अगर हमें कुछ कम उपयोग योग्य लगता है, या हमें अपना दृष्टिकोण साझा करना चाहिए।
- सुरक्षा परीक्षण : फिर बहुत विशाल परीक्षण प्रकार और पाठ्यक्रम के व्यावहारिक ज्ञान की बहुत आवश्यकता है। परीक्षक को उपलब्ध ज्ञान और जहां भी लागू हो, उसके आधार पर कम से कम बुनियादी परीक्षणों जैसे URL छेड़छाड़, क्रॉस-साइट स्क्रिप्टिंग, SQL इंजेक्शन, सत्र अपहरण, आदि को सीखने और निष्पादित करने का प्रयास करना चाहिए।
- बहु-किरायेदारी परीक्षण: यदि आपका एप्लिकेशन मल्टी-टेनेंट है, अर्थात एक से अधिक क्लाइंट का डेटा रखने का उदाहरण है, तो यह परीक्षण एक आवश्यक है। आवश्यकताओं में स्पष्ट उल्लेख के बावजूद यह किया जाना चाहिए। एक ग्राहक का डेटा दूसरे को दिखाया जाना एक तरह का विकास और परीक्षण अपराध है।
ध्यान दें: उपरोक्त विचार मेरे निजी विचार हैं। मैं आपको अपने ज्ञान के लिए परीक्षण प्रकारों की व्यापक सूची पर एक नज़र डालने की सलाह देता हूं और यदि आवश्यक हो तो उनका अनुसरण / उपयोग करें। वर्षों से मैंने समझा है कि आप कुछ का उपयोग करते हैं या नहीं, आप किसी चीज पर विश्वास करते हैं या नहीं, आपको अभी भी अपने क्षेत्र में व्यापक रूप से उपयोग की जाने वाली अवधारणाओं का कुछ ज्ञान होना चाहिए।
इस भाग के लिए बस इतना ही पढ़ने के लिए धन्यवाद। टिप्पणियों में अपने विचार / प्रतिक्रिया साझा करें।
इसके अगले और अंतिम भाग में मैनुअल परीक्षण ट्यूटोरियल की श्रृंखला , मैं आप सभी की मदद करने की कोशिश करूंगा यदि आप परीक्षण क्षेत्र में उतरना चाह रहे हैं और वहां पहुंचने के संभावित तरीके क्या हैं, तो आपको क्या तैयारी करनी चाहिए।
अनुशंसित पाठ
- सर्वश्रेष्ठ सॉफ्टवेयर परीक्षण उपकरण 2021 (क्यूए टेस्ट स्वचालन उपकरण)
- मैनुअल टेस्टिंग हेल्प ईबुक - फ्री डाउनलोड इनसाइड!
- परीक्षण प्राइमर eBook डाउनलोड
- मैनुअल और स्वचालन परीक्षण चुनौतियां
- एचपी लोडरनर ट्यूटोरियल के साथ लोड परीक्षण
- क्या आप मैनुअल या ऑटोमेशन टेस्टिंग एक्सपर्ट हैं? हमारे लिए काम का समय!
- प्रैक्टिकल सॉफ्टवेयर टेस्टिंग - नया मुफ़्त ई-पुस्तक (डाउनलोड)
- डेस्कटॉप, क्लाइंट सर्वर परीक्षण और वेब परीक्षण के बीच अंतर