मैनुअल एप्लीकेशन टेस्टिंग गाइड: लाभ, चरण और तरीके

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



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

याद रखें कि किसी भी पाठक ने जो हेबेर प्रोमो शब्द का इस्तेमाल किया है, अपने पसंदीदा पाठ्यक्रम के लिए 10,000 रूबल की छूट प्राप्त कर सकता है, जबकि सबसे मेहनती और चौकस अगरिमा एजेंसी के साथ संयुक्त रूप से तैयार की गई सामग्रियों से पहेली को हल करके 25,000 रूबल की छूट ले सकता है।

• पहली बार AppStore में कैसे जाएं: एक कदम-दर-चरण गाइड ;
• मोबाइल एप्लिकेशन इंटरफ़ेस विकसित करने की प्रक्रिया के 8 चरण ;
• ए / बी परीक्षण काम नहीं करते हैं। जांचें कि आप क्या गलत कर रहे हैं ।

दक्षता, लचीलापन, आशुरचना की संभावना और अन्य फायदे

आज कई परीक्षण ढांचे हैं जो लगभग सभी मौजूदा भाषाओं का समर्थन करते हैं। ऐसा लगता है - आप ले सकते हैं और स्वचालित कर सकते हैं। लेकिन अब भी, मैन्युअल परीक्षण महत्वपूर्ण हैं।

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

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

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

इसके अलावा, आवेदन विकास के शुरुआती चरणों में, स्वचालन काफी महंगा हो सकता है। आपको विशिष्ट योग्यता वाले विशेषज्ञ (और संभवतः एक से अधिक) की आवश्यकता होगी। लगातार परीक्षणों को बनाए रखने के लिए संसाधनों को जारी करने की आवश्यकता होती है। और एक ऑटोटेस्ट को चाटने के लिए समर्पित निष्क्रियता के महीने टीम की प्रेरणा को प्रभावित करेंगे।

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

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

ऑटोटेस्ट्स आपको यह जांचने की अनुमति नहीं देता है कि क्या एप्लिकेशन की नई सुविधाओं का उपयोग करना सुविधाजनक है - प्रयोज्य परीक्षण हमेशा मैन्युअल रूप से किया जाता है।

स्किलबॉक्स की सिफारिश: फुलस्टैक ऑनलाइन पाठ्यक्रम एक मोबाइल डेवलपर है ।

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

नए मामले भी सामने आते हैं क्योंकि परीक्षक लगातार खुद से सवाल पूछता है "क्या होगा?"। इसलिए वह आवेदन के साथ बातचीत करने के मूल तरीके ढूंढता है - भले ही वे आधार परिदृश्य में न हों।

मैनुअल परीक्षण की समस्याएं और उनके समाधान

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

दो परीक्षक अलग-अलग तरीकों से एक ही परिदृश्य का परीक्षण कर सकते हैं। इसके बारे में क्या करना है? यह महत्वपूर्ण है कि हर अप्रत्याशित या अलग परिणाम एक मामले के रूप में दर्ज होने की उम्मीद है। ताकि कोई भी परीक्षक उसी तरह की क्रिया करके इसका परीक्षण कर सके। लेकिन यह पर्याप्त नहीं हो सकता है - अगर मामला पर्याप्त विस्तृत नहीं है, और परीक्षक विवरण को नहीं समझता है। बेशक, मानव कारक के पूर्ण बहिष्कार की गारंटी देना असंभव है - लेकिन आप उन समस्याओं की संभावना को कम करने की कोशिश कर सकते हैं जो आपको पैदा करते हैं।

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

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

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

उसी समय, कुछ चीजों को नहीं भूलना चाहिए:

• मामले बनाना और ऑटोटेस्ट लिखने में समय लगेगा - इसे स्प्रिंट में रखना;
• सुनिश्चित करें कि ऑटोटेस्ट केस अच्छी तरह से लिखा और विस्तृत है और इसकी संपूर्णता में संभावित समस्या या मौजूदा परिदृश्य का वर्णन करता है;
• जांचें कि क्या ऑटोटेस्ट सही तरीके से काम करता है और क्या यह वास्तव में जांचता है कि क्या जरूरत है और क्या यह गुणात्मक रूप से करता है।

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

परीक्षण चरण: क्या, कब और कैसे

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

परीक्षक प्रारंभिक चरणों में आवेदन बनाने की प्रक्रिया में दिखाई देता है। यहां ग्राहक के पास एक निश्चित विचार है, व्यापार विश्लेषक इस आवश्यकता से एकत्र करते हैं - और इस क्षण पहले से ही परीक्षक इन आवश्यकताओं की जांच करना शुरू कर देते हैं।

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

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

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

Skillbox सिफारिश करता है: ऑनलाइन पाठ्यक्रम मोबाइल ऐप डिजाइन

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



परीक्षण का पहला चरण स्वयं धुआँ परीक्षण है: एक आकलन कि आवेदन या उसका नया हिस्सा आम तौर पर सत्यापन के लिए तैयार है। एक धूम्रपान परीक्षण एक परीक्षण है कि क्या एक आवेदन या एक विशिष्ट फ़ंक्शन को सिद्धांत रूप में लॉन्च किया गया है।

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

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

अगला चरण प्रतिगमन परीक्षण आयोजित कर रहा है। मैन्युअल या स्वचालित मोड में, परीक्षणों की मुख्य पूर्व नियोजित सरणी को पूरा किया जाता है।

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

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

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

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

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

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

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

रिबस समय: इसका अनुमान लगाएं और किसी भी स्किलबॉक्स कोर्स पर दस प्रतिशत की छूट अभी आपका इंतजार कर रही है या दृढ़ता दिखाएं और सभी विद्रोहियों को जवाब दें - ये छूट एक-दूसरे को जोड़ते हैं (लेकिन स्किलबॉक्स पाठ्यक्रमों पर कोई अन्य छूट नहीं)।

हालाँकि, आपको बहुत अधिक विलंब नहीं करना चाहिए - 30 अगस्त, 2018 तक प्रचार कार्य जारी रहेगा। याद रखें कि पहेली का विषय एक मोबाइल है, और अंग्रेजी शब्द यहां रूसी के साथ हस्तक्षेप कर सकते हैं, इसलिए सावधान रहें! पाठ्यक्रम के लिए एक आवेदन जमा करें, और जब प्रबंधक आपसे संपर्क करता है, तो उसे एक संदेश दें, एक रिबस में एन्क्रिप्टेड (या कुछ!)।

परीक्षण की औपचारिकता: परीक्षण योजना, बग रिपोर्ट का प्रारूप, रिपोर्टिंग

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

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

अंतिम आगे बढ़ता है, यह दर्शाता है कि उत्पाद तैयार है, स्थिति है "सभी आवश्यकताओं को मामलों द्वारा कवर किया जाता है, सभी मामलों को सफलतापूर्वक पूरा किया जाता है।"

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

परीक्षक का कार्य सभी टीम के सदस्यों को उत्पाद की गुणवत्ता के बारे में सबसे संपूर्ण जानकारी प्रदान करना है।

आपको परीक्षक बनने के लिए क्या जानने और सक्षम होने की आवश्यकता है

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

एक मैनुअल टेस्ट विशेषज्ञ को कोड लिखने और वास्तुकला की गहरी समझ रखने में सक्षम होने की आवश्यकता नहीं है। यह उसे अनुप्रयोग स्तर पर एप्लिकेशन और सर्वर के बीच बातचीत के सिद्धांतों को समझने और कार्यक्षमता को समझने से नहीं रोकता है।

स्वचालित परीक्षण में एक विशेषज्ञ एक अलग पेशा है, जिसमें पूरी तरह से ज्ञान का एक अलग सेट है। — , , , , , , . “ ”. , , .



, , . , — -. — , , — , . -. - . , .

( , ) , , . — , -.

- — , , , .

-, , — — . , .

— -. , , — , , .

- — -. , , , , , DevOps, , .

— , “Fullstack- ”. , . !



स्किलबॉक्स अनुशंसा करता है:

• digital- ;
• ;
• UX- .