>
मेन्यू

प्रैक्टिकल सॉफ्टवेयर टेस्टिंग क्यूए प्रक्रिया प्रवाह (रिलीज करने की आवश्यकताएं)

practical software testing qa process flow

एंड-टू-एंड क्यूए सॉफ्टवेयर टेस्टिंग प्रोसेस फ्लो का पूरा अवलोकन:

नोट - हम इस उपयोगी पोस्ट को अद्यतन सामग्री के साथ फिर से प्रकाशित कर रहे हैं।

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

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

एक परीक्षण इंजीनियर की भूमिका बहुत पहले शुरू होती है। और परियोजना की अवधारणा से सही, परीक्षक उत्पाद के मालिक, परियोजना प्रबंधक और विभिन्न हितधारकों के साथ चर्चा में शामिल होते हैं।

आवश्यकताएँ जारी करने के लिए

'सॉफ्टवेयर टेस्टिंग प्रोसेस फ्लो' पर यह ट्यूटोरियल आपको STLC में विभिन्न चरणों के साथ-साथ शामिल चुनौतियों और आसानी से समझने योग्य तरीके से उन चुनौतियों को दूर करने के लिए सर्वोत्तम अभ्यासों का पूरा अवलोकन देता है।

आप क्या सीखेंगे:

रिलीज की आवश्यकता - एक संपूर्ण अवलोकन

सॉफ्टवेयर परीक्षण जीवन चक्र

रिक्वायरमेंट से राइट टू रिलीज, प्रत्येक चरण को स्पष्ट रूप से समझाया गया है। आइए उनके बारे में विस्तार से देखें।

(१) आवश्यकता

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

सोच रहा हूँ क्यों? यह है क्योंकि आप खरोंच से बनाने में एक परियोजना देख रहे हैं। हालाँकि शुरुआत से ही गर्व है, यह कुछ जिम्मेदारियों और चुनौतियों के साथ आता है।

चुनौतियों

एक ही बैठक में इकट्ठा होने के लिए सभी आवश्यकताओं की कल्पना नहीं की जा सकती है। पर्याप्त धैर्य रखें।

बहुत सारी चर्चाएँ होंगी, जिनमें से कुछ आपकी परियोजना के लिए अप्रासंगिक हो सकती हैं, लेकिन फिर भी उनमें आपकी परियोजना के लिए कुछ महत्वपूर्ण जानकारी हो सकती है। कभी-कभी चर्चाओं की गति आपकी लोभी क्षमताओं से अधिक हो सकती है या आप उत्पाद स्वामी पर ध्यान नहीं देंगे।

नीचे दी गई तस्वीर में आवश्यकता को शामिल करने वाले महत्वपूर्ण चरणों पर प्रकाश डाला गया है:

आवश्यकताएँ जीवन चक्र

छूटी हुई जानकारी का हर टुकड़ा परियोजना की समग्र समझ और परीक्षण पर भारी प्रभाव डालता है। इसे दूर करने के लिए, यहां कुछ सर्वोत्तम प्रथाएं हैं जिनका इस चरण के दौरान पालन किया जाना चाहिए।

सर्वोत्तम प्रथाएं

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

हालाँकि हर चरण के लिए अलग-अलग दीवार नहीं होती है, फिर भी विकास बहुत देर से होता है। इसलिए, विचार यह है कि अधिकांश आवश्यकता को पकड़ लिया जाए और इसे ठीक से प्रलेखित किया जाए।

एक बार जब यह सभी आवश्यक बिंदुओं के साथ प्रलेखित हो जाता है, तो सभी हितधारकों को वितरित और चर्चा करें ताकि कोई भी सुझाव या परिवर्तन जल्दी पकड़ा जाए और आगे बढ़ने से पहले, सभी एक ही पृष्ठ पर हों।

# 2) टेस्ट की रणनीति

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

टेस्ट की रणनीति

चुनौतियों

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

टेस्ट की रणनीति कुछ ऐसी है जिसे आप हर दूसरे दिन नहीं बदलेंगे। कुछ मामलों में, आपको ग्राहकों के साथ अपनी परीक्षण रणनीतियों पर भी चर्चा करने की आवश्यकता है। तो इस भाग को उच्च महत्व के साथ निपटाया जाना चाहिए।

सर्वोत्तम प्रथाएं

  • यहाँ कुछ सर्वोत्तम अभ्यास दिए गए हैं, जिनका पालन करने पर आपको बहुत राहत मिल सकती है और इसका परिणाम सहज परीक्षण हो सकता है।
  • एक बार फिर आवश्यकता दस्तावेज़ के माध्यम से जाओ। लक्ष्य सॉफ़्टवेयर के वातावरण के संबंध में आयात बिंदुओं को हाइलाइट करें।
  • उन वातावरणों की एक सूची बनाएं जहां सॉफ्टवेयर वास्तव में तैनात किया जाएगा।
  • वातावरण को एक प्रकार के ऑपरेटिंग सिस्टम या मोबाइल डिवाइस के रूप में समझा जा सकता है।
  • यदि विंडोज ऑपरेटिंग सिस्टम है, तो खिड़की के सभी संस्करणों को नीचे सूचीबद्ध करें जहां आप अपने सॉफ़्टवेयर का परीक्षण करेंगे। यदि संस्करण। विंडोज 7, विंडोज 10 या विंडोज सर्वर (एस) अभी भी आवश्यकता दस्तावेज़ में परिभाषित नहीं हैं, तो यह उच्च समय है जब इन पर चर्चा की जानी चाहिए।
  • इसी तरह के एक नोट पर, लक्ष्य ब्राउज़रों को चर्चा किए गए संस्करणों के साथ प्राप्त करें और दस्तावेज करें कि क्या ऑटो एक वेब-आधारित प्रणाली है।
  • सभी तृतीय-पक्ष सॉफ़्टवेयर की एक सूची बनाएं, जिसके लिए आवेदन की आवश्यकता होगी (यदि आवश्यक / समर्थित)। इनमें Adobe Acrobat, Microsoft Office, कोई भी ऐड-ऑन आदि शामिल हो सकते हैं।

यहाँ पीछे विचार यह है कि हर आवश्यक और आवश्यक प्लेटफ़ॉर्म, डिवाइस और सॉफ़्टवेयर को रखा जाए, ताकि हमारे आवेदन को हमारे सामने कार्य करना होगा ताकि एक व्यापक रणनीति तैयार की जा सके।

यदि आप एक चुस्त परियोजना पर काम कर रहे हैं, तो आंकड़ा नीचे आपको टेस्ट रणनीति की रूपरेखा को समझने में मदद करेगा:

परीक्षण की रणनीति

# 3) टेस्ट प्लानिंग

परीक्षकों को ऑटो के संबंध में सभी जानकारी से लैस करने के बाद, योजना का चरण वह जगह है जहां रणनीति को लागू किया जाता है।

परीक्षण रणनीति की तरह, परीक्षण योजना भी एक महत्वपूर्ण चरण है।

जाँच की योजना

चुनौतियों

चूंकि ऑटो की सफलता (या विफलता) काफी हद तक इस बात पर निर्भर करती है कि परीक्षण कैसे किए गए थे, इसलिए यह चरण पूरे परीक्षण जीवन चक्र का एक महत्वपूर्ण पहलू बन जाता है। क्यों? क्योंकि इस चरण में परीक्षण का एक हिस्सा परिभाषित किया गया है।

कुछ चुनौतियों को पार करने के लिए, ये सर्वोत्तम अभ्यास वास्तव में सहायक हो सकते हैं।

सर्वोत्तम प्रथाएं

c ++ नियमित अभिव्यक्ति उदाहरण
  • हमेशा ध्यान रखें, जब आपके आवेदन का परीक्षण करने की बात आती है, तो कोई कसर नहीं छोड़ना चाहिए।
  • परीक्षण रणनीति तैयार करने का समय आ गया है
  • वातावरण का एक मैट्रिक्स बनाएं ताकि सॉफ्टवेयर सभी प्लेटफार्मों पर परीक्षण किया जाए।
  • जैसे, विंडोज 10 + इंटरनेट एक्सप्लोरर 11+ विंडोज ऑफिस 2010+।
  • जैसे Android 4.2.2+ क्रोम ब्राउज़र।
  • यदि आपका एप्लिकेशन कई डेटाबेस के साथ काम करता है (यदि प्रलेखित है), तो परीक्षण मैट्रिक्स में डेटाबेस (MySQL, Oracle, SQLServer) को इस तरह से रखें कि वे कुछ परीक्षणों के साथ भी एकीकृत हों।
  • तदनुसार परीक्षण मशीनों को कॉन्फ़िगर करें और उन्हें SetUp1, SetUp2, आदि के रूप में नाम दें।
  • SetUp1 में विंडोज 7+ IE 10+ ऑफिस 2007+ होगा।
  • SetUp2 में विंडोज 10+ IE एज + ऑफिस 2013+ हो सकता है।
  • SetUp3 में आपके .apk फ़ाइल के साथ एक Android फ़ोन हो सकता है।
  • बधाई हो! आपका परीक्षण सेटअप तैयार है और आपने प्लेटफार्मों के हर संभव संयोजन को भी शामिल किया है जो आपके आवेदन पर काम करेगा।

# 4) परीक्षण

कीड़े का पता लगाना

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

नीचे दिए गए आरेख में विभिन्न परीक्षण प्रकारों के वर्गीकरण को दर्शाया गया है:

परीक्षण के प्रकार

चुनौतियों

परीक्षण एक बोझिल प्रक्रिया है जो स्वयं त्रुटि-प्रवण है! किसी एप्लिकेशन का परीक्षण करते समय कई चुनौतियां मिलती हैं। नीचे दिए गए बचाव के लिए कुछ सर्वोत्तम अभ्यास हैं।

सर्वोत्तम प्रथाएं

खुश हो जाओ! आप कोड में दोष खोजने की कोशिश कर रहे हैं। आपको सॉफ्टवेयर के समग्र कामकाज पर ध्यान देने की आवश्यकता है।

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

# 5) रिलीज़ से पहले

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

चुनौतियों

सॉफ्टवेयर को इसके कई मापदंडों के लिए कठोरता से जांचना होगा।

मापदंडों को सीमित नहीं किया जा सकता है:

  • कार्यशीलता / व्यवहार।
  • प्रदर्शन।
  • स्केलेबिलिटी।
  • उक्त प्लेटफार्मों के साथ संगत।

चुनौती एक आवेदन की सफलता दर का अनुमान लगाने के लिए भी है जो परीक्षण के कई पुनरावृत्तियों पर निर्भर करता है।

सर्वोत्तम प्रथाएं

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

नीचे दी गई तस्वीर सॉफ्टवेयर रिलीज जीवनचक्र मानचित्र दिखाती है:

रिलीज से पहले

# 6) रिलीज

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

चुनौतियों

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

सर्वोत्तम प्रथाएं

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

एक असली परियोजना पर क्यूए परीक्षण प्रक्रिया - झरना विधि

मुझे एक पाठक से एक दिलचस्प सवाल मिला, एक कंपनी में परीक्षण कैसे किया जाता है यानी एक व्यावहारिक वातावरण में?

जो लोग सिर्फ कॉलेज से बाहर निकलते हैं और नौकरियों की खोज शुरू करते हैं, उनमें यह जिज्ञासा होती है - किसी कंपनी में वास्तविक कामकाजी माहौल कैसा होगा?

यहां मैंने वास्तविक कार्य प्रक्रिया पर ध्यान केंद्रित किया है कंपनियों में सॉफ्टवेयर परीक्षण ।

कंपनियों में वास्तविक परीक्षण प्रक्रिया

जब भी हमें कोई नई परियोजना मिलती है तो एक प्रारंभिक परियोजना परिचित बैठक होती है। इस बैठक में, हम मूल रूप से चर्चा करते हैं कि ग्राहक कौन है? प्रोजेक्ट की अवधि क्या है और इसकी डिलीवरी कब होती है? परियोजना में सभी कौन शामिल हैं यानी प्रबंधक, टेक लीड, क्यूए लीड, डेवलपर्स, परीक्षक आदि?

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

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

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

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

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

एसआरएस के अनुसार लोड और तनाव परीक्षण भी किया जाता है। अंत में, सिस्टम परीक्षण एक वर्चुअल क्लाइंट वातावरण बनाकर किया जाता है। एक बार सभी परीक्षण मामलों को निष्पादित करने के बाद, एक परीक्षण रिपोर्ट तैयार की जाती है और उत्पाद को जारी करने का निर्णय लिया जाता है!

आवश्यकताओं को जारी करने के लिए कदम

नीचे दिए गए प्रत्येक परीक्षण चरण का विवरण दिया गया है जो प्रत्येक सॉफ़्टवेयर गुणवत्ता और परीक्षण जीवन चक्र द्वारा किया गया है IEEE और ISO मानक।

# 1) एसआरएस की समीक्षा : सॉफ्टवेयर आवश्यकता विनिर्देशों की समीक्षा।

# 2) उद्देश्य मेजर रिलीज के लिए तैयार हैं।

# 3) लक्ष्य तिथि विज्ञप्ति के लिए योजना बनाई।

# 4) विस्तृत परियोजना योजना बनाया गया है। इसमें डिजाइन विनिर्देशों पर निर्णय शामिल है।

# 5) टेस्ट प्लान विकसित करें डिजाइन विनिर्देशों पर आधारित है।

# 6) टेस्ट प्लान: इसमें उद्देश्य शामिल हैं, परीक्षण करते समय अपनाई गई कार्यप्रणाली, परीक्षण की जाने वाली विशेषताएं और परीक्षण नहीं किया जाना, जोखिम मानदंड, परीक्षण अनुसूची, बहु-मंच समर्थन और परीक्षण के लिए संसाधन आवंटन।

# 7) परीक्षण विनिर्देशों: इस दस्तावेज़ में परीक्षण से पहले आवश्यक तकनीकी विवरण (सॉफ़्टवेयर आवश्यकताएँ) शामिल हैं।

# 8) टेस्ट मामलों का लेखन

# 9) विकास: एक-एक करके मॉड्यूल विकसित किए जाते हैं।

# 10) इंस्टॉलर्स बाइंडिंग: अलग-अलग उत्पाद के आसपास इंस्टॉलर बनाए जाते हैं।

#ग्यारह) प्रक्रिया का निर्माण : एक बिल्ड में उपलब्ध उत्पादों के इंस्टालर शामिल हैं - कई प्लेटफ़ॉर्म।

# 12) परीक्षण: स्मोक टेस्ट (बीवीटी): आगे के परीक्षण पर निर्णय लेने के लिए मूल आवेदन परीक्षण।

  • नई सुविधाओं का परीक्षण
  • क्रॉस ब्राउज़र और क्रॉस-प्लेटफ़ॉर्म परीक्षण
  • तनाव परीक्षण और स्मृति रिसाव परीक्षण।

# 13) टेस्ट सारांश रिपोर्ट

कैसे जावा में स्ट्रिंग सरणी बनाने के लिए

# 14) कोड ठंड

  • इस बिंदु पर कोई और नई सुविधाएँ नहीं जोड़ी गई हैं।

# 15) परीक्षण: निर्माण और प्रतिगमन परीक्षण।

# 16) उत्पाद जारी करने का निर्णय।

# 17) रिलीज के बाद का परिदृश्य आगे के उद्देश्यों के लिए।

यह कंपनी के वातावरण में एक वास्तविक परीक्षण प्रक्रिया का सारांश था।

निष्कर्ष

एक सॉफ्टवेयर परीक्षक का काम चुनौतियों से भरा है, फिर भी एक सुखद है। यह किसी के लिए समान रूप से भावुक, प्रेरित और उत्साह से भरा हुआ है। किसी में दोष ढूंढना हमेशा एक आसान काम नहीं है! इसके लिए बहुत सारे कौशल और दोषों के लिए एक बैल की आंख की आवश्यकता होती है।

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

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

क्या आप उपरोक्त किसी भी चरण का हिस्सा रहे हैं? नीचे अपने अनुभव साझा करने के लिए स्वतंत्र महसूस करें।

अनुशंसित पाठ

^