टेस्टिंग क्या है? | What is Testing?

टेस्टिंग एक प्रक्रिया है जिसका मुख्य उद्देश्य होता है यह सुनिश्चित करना कि कोई चीज या सॉफ़्टवेयर ठीक से काम कर रहा है या नहीं। यह सुनिश्चित करने के लिए किया जाता है कि एक वस्तु या प्रोडक्ट अपने डिज़ाइन और उपयोग में सही तरह से काम कर रहा है या नहीं।

अगर हमें यह समझना है कि कोई सॉफ़्टवेयर सही से काम कर रहा है या नहीं, तो हम उसे टेस्ट करते हैं। इसमें हम विभिन्न प्रकार के परीक्षण क्रियाएं करते हैं ताकि हम सुनिश्चित हो सकें कि सॉफ़्टवेयर में कोई बग या समस्या नहीं है।

सोचिए इसे एक जाँच के रूप में – जैसे कि जब आप नए खेल को खेलते हैं, तो आप देखते हैं कि क्या सब कुछ सही से काम कर रहा है या कहीं कोई गड़बड़ तो नहीं है। उसी तरह, सॉफ़्टवेयर टेस्टिंग में भी हम देखते हैं कि क्या सब कुछ सही से चल रहा है या नहीं।

टेस्टिंग से हम सुनिश्चित होते हैं कि एक चीज या सॉफ़्टवेयर अपने उपयोग के लिए तैयार है और लोग उसे बिना किसी परेशानी के इस्तेमाल कर सकते हैं।

Software Testing क्या है?

सॉफ़्टवेयर परीक्षण यह जाँचने की एक गतिविधि है कि वास्तविक परिणाम अपेक्षित परिणाम से मेल खाते हैं या नहीं और यह सुनिश्चित करने के लिए कि सॉफ़्टवेयर सिस्टम (defect free) है।

सॉफ़्टवेयर परीक्षण वास्तविक आवश्यकताओं में त्रुटियों, अंतरालों या अनुपलब्ध आवश्यकताओं की पहचान करने में भी मदद करता है।

सॉफ़्टवेयर परीक्षण या तो मैन्युअल रूप से या स्वचालित टूल का उपयोग करके किया जा सकता है।

Software testing की आवश्यकता

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

सॉफ्टवेयर विकास जीवनचक्र | Software Development Lifecycle in hindi

सॉफ़्टवेयर विकास जीवनचक्र सॉफ़्टवेयर उद्योग द्वारा उच्च गुणवत्ता वाले सॉफ़्टवेयर को डिज़ाइन, विकसित और परीक्षण करने के लिए उपयोग की जाने वाली एक प्रक्रिया है।

एसडीएलसी का लक्ष्य उच्च गुणवत्ता वाला सोफ टेनारे तैयार करना है जो ग्राहकों की अपेक्षाओं को पूरा करता हो।

SDLC में छह चरण हैं:

1. Requirements (आवश्यकताएँ)
2. Design (डिज़ाइन)
3. Coding (कोडिंग)
4. Testing (परिक्षण)
5. Installation (इंस्टालेशन)
6. Maintaince (रखरखाव)

1) Requirments (आवश्यकताएँ) –

• आवश्यकता विश्लेषण सबसे महत्वपूर्ण चरण है। एसडीएलएस में
• यह बीए (Business Analytics) द्वारा किया जाता है
• बीए (Business Analytics) ग्राहक (customer) से इनपुट लेता है और इस इनपुट के आधार पर प्रोजेक्ट प्लानिंग करता है। कर दिया है।
• बीए (Business Analytics) -> बीआरएस (Business Requirement Specification) ->समय (time)-> लागत (cost).
• एक बार आवश्यकता विश्लेषण पूरा हो जाने के बाद अगला कदम उत्पाद आवश्यकताओं को स्पष्ट रूप से परिभाषित करना और उनका दस्तावेजीकरण करना और उन्हें ग्राहकों से अनुमोदित कराना है। यह बीआरएस (बिजनेस रिक्वायरमेंट स्पेसिफिकेशन) के माध्यम से किया जाता है।

2) Design (डिज़ाइन) –

• Font end : client side (क्लाइंट साइड).
• Back end : Database (बैकएंड).
• फ्रंट एंड (Font end) – यह एचएलडी (हाई लेवल डिज़ाइन) है। यहां हमने मॉड्यूल और को सूचीबद्ध किया है उनके बीच अंतर्संबंध उदाहरण फेसबुक मॉड्यूल एक खाता लॉगिन बनाते हैं.अधिसूचना (notification).
• बैक एंड (Back end) – यह एक एलएलडी (LLD)(लो लेवल डिज़ाइन) है। प्रस्तावित प्रणाली के सभी मॉड्यूल के आंतरिक डिज़ाइन को स्पष्ट रूप से परिभाषित किया जाना चाहिए।

3) Coding (कोडिंग) –

• एसडीएलसी (SDLC) के इस चरण में वास्तविक विकास शुरू होता है और उत्पाद का निर्माण होता है।
• इस चरण के दौरान डिज़ाइन दस्तावेज़ विशिष्टता (डीडीएस) के अनुसार प्रोग्रामिंग कोड तैयार किया जाता है।
• डेवलपर्स को संगठन द्वारा परिभाषित कोडिंग दिशानिर्देशों का पालन करना होगा।

4) Testing (परिक्षण) –

• परीक्षक (Tester) ने यह सुनिश्चित करने के लिए सॉफ़्टवेयर का परीक्षण किया कि यह किसी भी स्थिति में कार्यान्वित होने के लिए तैयार है। परीक्षण गतिविधियाँ अधिकतर SDLC के सभी चरणों में शामिल होती हैं.

5) Installation (इंस्टालेशन) –

• सॉफ़्टवेयर इंस्टॉल करने के लिए तैयार होने के बाद – क्लाइंट साइड पर सॉफ़्टवेयर इंस्टॉल करने के लिए इसे इंस्टॉलेशन टीम को दिया जाता है।

6) Maintaince (रखरखाव) –

• रखरखाव चरण में, हम सॉफ़्टवेयर के उन्नयन के बाद त्रुटि का समाधान करते हैं।

बग क्या हैं? | What are bugs?

सॉफ़्टवेयर या हार्डवेयर में कोई त्रुटि या दोष जिसके कारण प्रोग्राम ख़राब हो जाता है। सॉफ़्टवेयर बग एक कंप्यूटर प्रोग्राम में एक त्रुटि, दोष, गलती, विफलता, गलती या “undocumented feature” है जो इसे इच्छित व्यवहार करने से रोकती है (उदाहरण के लिए, गलत परिणाम उत्पन्न करना)। अधिकांश बग किसी प्रोग्राम के स्रोत कोड या उसके डिज़ाइन में लोगों द्वारा की गई गलतियों और त्रुटियों से उत्पन्न होते हैं।

Bug Life Cycle

सॉफ़्टवेयर विकास प्रक्रिया में, बग का एक जीवन चक्र होता है। बंद होने के लिए बग को जीवन चक्र से गुजरना चाहिए। एक विशिष्ट जीवन चक्र यह सुनिश्चित करता है कि प्रक्रिया मानकीकृत है। बग जीवन चक्र में विभिन्न अवस्थाएँ प्राप्त करता है। बग के जीवन चक्र को आरेखीय रूप से निम्नानुसार दिखाया जा सकता है:

बग की विभिन्न स्थितियों को इस प्रकार संक्षेप में प्रस्तुत किया जा सकता है:

1. New
2. Open
3. Assign
4. Test
5. Verified
6. Deferred
7. Reopened
8. Duplicate
9. Rejected
10. Closed

विभिन्न चरणों का विवरण:

1. नया (New): जब बग पहली बार पोस्ट किया जाएगा, तो उसकी स्थिति “नई” होगी। इसका मतलब है कि बग अभी तक स्वीकृत नहीं है.
2. खुला (open): एक परीक्षक द्वारा बग पोस्ट करने के बाद, परीक्षक का नेतृत्व अनुमोदन करता है कि बग वास्तविक है और वह स्थिति को “ओपन” के रूप में बदल देता है।
3. असाइन करें (Assign): एक बार जब लीड स्थिति को “ओपन” के रूप में बदल देता है, तो वह बग को संबंधित डेवलपर या डेवलपर टीम को सौंप देता है। बग की स्थिति अब “ASSIGN” में बदल गई है।
4. परीक्षण (Test): एक बार जब डेवलपर बग को ठीक कर लेता है, तो उसे परीक्षण के अगले दौर के लिए परीक्षण टीम को बग सौंपना होगा। बग ठीक करके सॉफ़्टवेयर जारी करने से पहले, वह बग की स्थिति को “TEST” में बदल देता है। यह निर्दिष्ट करता है कि बग को ठीक कर दिया गया है और परीक्षण टीम को जारी कर दिया गया है।
5. आस्थगित (Verified): बग को आस्थगित स्थिति में बदलने का मतलब है कि बग को अगले रिलीज में ठीक किए जाने की उम्मीद है। बग को इस स्थिति में बदलने के कारणों में कई कारक हैं। उनमें से कुछ हैं बग की प्राथमिकता कम हो सकती है, रिलीज़ के लिए समय की कमी हो सकती है या बग का सॉफ़्टवेयर पर बड़ा प्रभाव नहीं हो सकता है।
6. अस्वीकृत (Deferred): यदि डेवलपर को लगता है कि बग वास्तविक नहीं है, तो वह बग को अस्वीकार कर देता है। फिर बग की स्थिति को “अस्वीकृत” में बदल दिया जाता है।
7. डुप्लिकेट(Duplicate): यदि बग दो बार दोहराया जाता है या दोनों बग बग की एक ही अवधारणा का उल्लेख करते हैं, तो एक बग स्थिति को “डुप्लिकेट” में बदल दिया जाता है।
8. सत्यापित: एक बार जब बग ठीक हो जाता है और स्थिति “परीक्षण” में बदल जाती है, तो परीक्षक बग का परीक्षण करता है। यदि सॉफ़्टवेयर में बग मौजूद नहीं है, तो वह स्वीकार करता है कि बग ठीक हो गया है और स्थिति को “सत्यापित” में बदल देता है।
9. पुनः खोला गया (Reopened): यदि डेवलपर द्वारा बग ठीक करने के बाद भी बग मौजूद है, तो परीक्षक स्थिति को “फिर से खोला गया” में बदल देता है। बग एक बार फिर जीवन चक्र पार करता है।
10. बंद (Closed) : एक बार बग ठीक हो जाने पर, परीक्षक द्वारा इसका परीक्षण किया जाता है। यदि परीक्षक को लगता है कि सॉफ़्टवेयर में बग अब मौजूद नहीं है, तो वह बग की स्थिति को “बंद” में बदल देता है। इस स्थिति का मतलब है कि बग को ठीक कर दिया गया है, परीक्षण किया गया है और अनुमोदित किया गया है।

Software Testing के प्रकार 

1) Unit Testing (यूनिट टेस्टिंग)

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

Unit Testing के सबसे आम दृष्टिकोण के लिए ड्राइवरों और स्टब्स को लिखने की आवश्यकता होती है। ड्राइवर एक कॉलिंग यूनिट का अनुकरण करता है और स्टब एक कॉल की गई यूनिट का अनुकरण करता है।

2) Integration testing (इंटीग्रेशन टेस्टिंग)

Integration testing इकाई testing का तार्किक विस्तार है। इसके सरलतम रूप में, पहले से ही testing की जा चुकी दो इकाइयों को एक घटक में जोड़ दिया जाता है और उनके बीच के इंटरफ़ेस का testing किया जाता है।

इस अर्थ में एक घटक, एक से अधिक इकाइयों के एकीकृत समुच्चय को संदर्भित करता है। यथार्थवादी परिदृश्य में, कई इकाइयों को घटकों में जोड़ दिया जाता है, जो बदले में कार्यक्रम के और भी बड़े हिस्सों में एकत्रित हो जाते हैं।

विचार यह है कि टुकड़ों के संयोजन का testing किया जाए और अंततः अन्य समूहों के मॉड्यूल के साथ अपने मॉड्यूल का परीक्षण करने के लिए प्रक्रिया का विस्तार किया जाए। अंततः एक प्रक्रिया बनाने वाले सभी मॉड्यूल का एक साथ testing किया जाता है। इसके अलावा, यदि प्रोग्राम एक से अधिक प्रक्रियाओं से बना है, तो उन्हें एक साथ करने के बजाय जोड़े में testing किया जाना चाहिए। Integration testing उन समस्याओं की पहचान करता है जो इकाइयों के संयुक्त होने पर उत्पन्न होती हैं।

3) Alpha Testing (अल्फा टेस्टिंग)

एल्फा टेस्टिंग वह प्रक्रिया है जिसमें सॉफ़्टवेयर का पहला पूर्णता परीक्षण किया जाता है, जिसमें विकसित सॉफ़्टवेयर को टेस्ट करने के लिए विशेषज्ञ टीम को शामिल किया जाता है। इसमें सॉफ़्टवेयर के सभी पहलुओं को जाँचा जाता है ताकि किसी भी समस्या को पहले ही ठीक किया जा सके और उपयोगकर्ताओं को एक उच्च-गुणवत्ता वाले सॉफ़्टवेयर का अनुभव हो।

4) Beta Testing (बीटा टेस्टिंग)

सॉफ़्टवेयर डिज़ाइन का बीटा चरण एक नए उत्पाद को उजागर करता है, जो अभी-अभी इन-हाउस (अल्फ़ा) परीक्षण से बड़ी संख्या में वास्तविक लोगों, वास्तविक हार्डवेयर और वास्तविक उपयोग के लिए सामने आया है।

बीटा परीक्षण दीर्घकालिक मुफ़्त सॉफ़्टवेयर प्राप्त करने का एक तरीका नहीं है, क्योंकि सॉफ़्टवेयर परीक्षण अवधि के तुरंत बाद समाप्त हो जाता है। बीटा परीक्षण के उद्देश्य में शामिल हैं:

• किसी अन्य से पहले नई सुविधाओं पर नज़र डालना।
• बिना सोचे-समझे बग ढूँढ़ने का आनंद।
• उन बगों का पता लगाने के परिणामस्वरूप हमारे (यानी, आपके!) सॉफ़्टवेयर को बेहतर बनाना।
• संभवतः आपके सुझावों के माध्यम से हमारी भावी विकास की दिशा प्रभावित हो रही है।

5) Stress Testing (स्ट्रेस टेस्टिंग) –

स्ट्रेस टेस्टिंग एक प्रक्रिया है जिसमें सॉफ़्टवेयर को उच्च या अधिक लोड पर डालकर देखा जाता है कि वह कैसे से निपटता है और क्या यह सही तरीके से काम करता है। इसमें टेस्टर्स विभिन्न यातायात और उपयोग की स्थितियों को मॉडल करते हैं ताकि स्ट्रेस और भार के अधिकतम स्तरों पर सॉफ़्टवेयर की प्रतिस्पर्धा को मापा जा सके। यह सुनिश्चित करने में मदद करता है कि सॉफ़्टवेयर अधिक उपयोगकर्ताओं या भारी योजनाओं के साथ सही तरीके से काम कर सकता है या नहीं।

6) Recovery testing (रिकवरी टेस्टिंग) –

रिकवरी टेस्टिंग एक प्रक्रिया है जिसमें देखा जाता है कि अगर कोई आपातकालीन स्थिति होती है, तो सॉफ़्टवेयर या सिस्टम कैसे ठीक होकर वापस लौटता है। इसमें टेस्ट किया जाता है कि किस प्रकार सॉफ़्टवेयर उपयोगकर्ताओं को नुकसान से बचाने के लिए त्वरित रूप से पुनर्स्थापित हो सकता है और सॉफ़्टवेयर की सामरिक स्थिति को बचाने का क्षमता होती है।

7) Security Testing (सुरक्षा टेस्टिंग) –

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

8) Smoke testing (स्मोक टेस्टिंग ) –

स्मोक टेस्टिंग एक छोटी सी परीक्षण प्रक्रिया है जो सॉफ़्टवेयर की स्थिति को जानने के लिए की जाती है। इसमें पहले ही स्मोक (धूम) की तरह टेस्टिंग की जाती है, और अगर सब कुछ ठीक है, तो हम आगे के टेस्टिंग की ओर बढ़ते हैं। इसमें मुख्यत: सॉफ़्टवेयर के मुख्य और महत्वपूर्ण कार्यों को जाँचा जाता है, ताकि हम सुनिश्चित हो सकें कि सॉफ़्टवेयर का आधुनिक संस्करण सही तरीके से काम करता है। यह एक प्रारंभिक चरण है, जिसमें हम सॉफ़्टवेयर की बुनियादी स्थिति को जानते हैं और अगर वह ठीक है, तो हम विस्तृत टेस्टिंग के लिए आगे बढ़ सकते हैं।

9) Regression testing (रीग्रेशन टेस्टिंग) –

रीग्रेशन टेस्टिंग एक प्रक्रिया है जिसमें सॉफ़्टवेयर में किए गए किसी भी परिवर्तन के बाद यह देखा जाता है कि सॉफ़्टवेयर के पूरे सिस्टम में कोई नई समस्या उत्पन्न नहीं हुई है। इसमें हम पिछले टेस्ट केस को पुनरावलोकन करते हैं ताकि सुनिश्चित हो सके कि नए बदलाव ने किसी पूर्व में काम कर रहे हिस्से को कैसे प्रभावित किया है और कहीं कोई नयी समस्या तो नहीं उत्पन्न हुई है। यह सुनिश्चित करने में मदद करता है कि सॉफ़्टवेयर का हर अंश पूर्व संस्करण की तुलना में ठीक तरीके से काम कर रहा है और नए बदलाव से कोई नया प्रॉब्लम नहीं उत्पन्न हुआ है।

10) adhoc testing in hindi

एडहॉक टेस्टिंग एक आकस्मिक और बिना पूर्व योजना के किए जाने वाले परीक्षण का प्रकार है। इसमें टेस्टर्स बिना नियमित प्रक्रिया के अनुसार, स्वयं सोचकर और बिना स्क्रिप्ट के कुछ विशिष्ट टेस्ट केस को प्रदर्शित करते हैं। इस प्रकार की टेस्टिंग में उद्दीपक यह है कि टेस्टर्स विभिन्न स्थितियों को मॉडल करके और नई समस्याओं की जाँच करके सॉफ़्टवेयर की स्थिति को अच्छी तरह से समझ सकें। इससे अनुप्रयोगिता और असाधारित स्थितियों में सॉफ़्टवेयर का व्यापक परीक्षण किया जा सकता है।

ब्लैक बॉक्स टेस्टिंग | black box testing in hindi

ब्लैक बॉक्स testing रणनीति को लागू करने के लिए, tester को सिस्टम की आवश्यकता विशिष्टताओं के साथ पूरी तरह से परिचित होना चाहिए और एक उपयोगकर्ता के रूप में, यह जानना चाहिए कि system को विशेष कार्रवाई के जवाब में कैसे व्यवहार करना चाहिए।

ब्लैक बॉक्स testing रणनीति के अंतर्गत आने वाले विभिन्न परीक्षण प्रकार हैं: functional testing, stress testing,recovery testing, volume testing, user acceptance testing (UAT के रूप में भी जाना जाता है), system testing, sanity or smoke testing, load testing, usability testing, exploratory testing। ad-hoc testing,अल्फा परीक्षण, बीटा परीक्षण आदि।

व्हाइट बॉक्स टेस्टिंग | white box testing in hindi

व्हाइट बॉक्स testing रणनीति कोड के आंतरिक तर्क और संरचना से संबंधित है। व्हाइट बॉक्स testing को ग्लास, स्ट्रक्चरल, ओपन बॉक्स या क्लीयर बॉक्स testing भी कहा जाता है। व्हाइट बॉक्स testing रणनीति के आधार पर लिखे गए परीक्षणों में लिखे गए कोड, शाखाओं, पथों, कथनों और कोड के आंतरिक तर्क आदि का कवरेज शामिल होता है।

व्हाइट बॉक्स testing मानता है कि परीक्षक एप्लिकेशन ब्लॉक के लिए कोड पर एक नज़र डाल सकता है और ऐसे testing मामले बना सकता है जो किसी भी संभावित विफलता परिदृश्य की तलाश करते हैं।

व्हाइट बॉक्स testing के दौरान, परीक्षक एप्लिकेशन ब्लॉक के कोड का विश्लेषण करता है और कार्यक्षमता के testing के लिए testing मामले तैयार करता है ताकि यह सुनिश्चित किया जा सके कि वर्ग विशिष्टताओं के अनुसार व्यवहार कर रहा है और मजबूती के लिए testing कर रहा है।

व्हाइट बॉक्स परीक्षण के लिए निम्नलिखित इनपुट आवश्यक है:

• Requirements -आवश्यकताएं
• Functional specifications – कार्यात्मक विशिष्टताएँ
• High-level design documents – उच्च स्तरीय डिज़ाइन दस्तावेज़
• Detailed design documents – विस्तृत डिज़ाइन दस्तावेज़
• Application block source code – एप्लिकेशन ब्लॉक स्रोत कोड

उदाहरण के लिए: white box testing का विवरण कवरेज।

टेस्ट केस डॉक्यूमेंट क्या है।

A test case document एक डेसीमेंट है जो परीक्षकों को किसी विशेष परीक्षण परिदृश्य के लिए परीक्षण मामलों को विकसित करने की अनुमति देता है ताकि यह सत्यापित किया जा सके कि किसी एप्लिकेशन की विशेषताएं अपेक्षित रूप से काम कर रही हैं या नहीं।

परीक्षण मामले सकारात्मक और नकारात्मक का समूह हैं। testing परिदृश्य के निष्पादन योग्य चरण जिसमें पूर्व-शर्तें, परीक्षण डेटा, अपेक्षित परिणाम का एक सेट होता है। I/P डेटा, परीक्षण उद्देश्य।

ब्लैक बॉक्स और व्हाइट बॉक्स टेस्टिंग के बीच अंतर