एक लंबा लेख पढ़ना मुश्किल है ... एक जटिल उत्पाद का परीक्षण करना आसान है

आधुनिक आईटी उद्योग में, कई लोग अभी भी आश्चर्यचकित हैं: "हमें एक अलग परीक्षण विभाग की आवश्यकता क्यों है?"

गेय परिचय

पीटर्सबर्ग शरद ऋतु क्या है? बारिश, रोसेनबाम, उदासी ... क्या यह सब है? नहीं, यह अभी भी एक नया शैक्षणिक वर्ष है, जो हमारे देश के कई क्षेत्रों में Diary.ru के साथ ठीक शुरू हुआ। गर्मियों में, हम कुछ सफलताओं को प्राप्त करने में कामयाब रहे: परियोजना के उपयोगकर्ताओं की संख्या 7,000,000 से अधिक हो गई, हम विश्व आर्थिक मंच प्रौद्योगिकी पायनियर्स 2014 की सूची में शामिल एकमात्र रूसी कंपनी बन गए, और उत्तर ओसेशिया-अलानिया गणराज्य पूरी तरह से डायरी से इलेक्ट्रॉनिक पत्रिकाओं में बदल गया। आरयू । इस गीतात्मक परिचय पर हम समाप्त हो जाएंगे और इस पद के सार पर आगे बढ़ेंगे।

विषय का परिचय

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

द्वारा और बड़े रूप से, यह पहिया को फिर से स्थापित करने के लायक नहीं है - इन प्रथाओं को लाखों वेब पृष्ठों पर वर्णित किया गया है और कई निगमों में सफलतापूर्वक उपयोग किया जाता है जिनके अनुभव को अपनाया जा सकता है। हालांकि, एक व्यक्ति को सरल सत्य को नहीं भूलना चाहिए - हर जगह एक विशिष्टता है। उदाहरण के लिए, Diary.ru में ये दृढ़ता से परस्पर जुड़े घटक और CI (कंटीन्यूअस इंटीग्रेशन) हैं, और संबंधित क्षेत्रों के एकीकरण का एक उच्च स्तर है। इस मामले में सबसे अच्छा परीक्षण क्या है?
आइए एक सरल के साथ शुरू करें: कोई भी जानकारी आपके (undeniably, बहुत स्मार्ट) सिर में 100% स्वचालित रूप से "पॉप अप" कभी नहीं हो सकती है। सबसे पहले, क्यूए-शिकोव को परीक्षण परिदृश्यों को याद करने और चलाने की आवश्यकता है, जो कि रिलीज से रिलीज तक जांच की जाती है - "लेकिन कुछ टूट गया है?"। जैसा कि हम सभी जानते हैं - प्रतिगमन परीक्षण। लेकिन यह उस बारे में नहीं है, प्रजातियों के बारे में - विरोध करने के लिए आपका स्वागत है। (एक अच्छा संसाधन, वैसे)।

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

तैयारी का काम

लंबे समय से पहले से ही कई भारी परीक्षण प्रबंधन कार्यक्रम हैं जो आपको परीक्षण प्रक्रिया को पूरी तरह से प्रबंधित करने की अनुमति देते हैं: परीक्षण योजनाओं, परीक्षण चक्र, अपेक्षित, परीक्षण मामलों आदि के साथ काम करते हैं। मैंने विभिन्न उपयोगिताओं के साथ काम किया - भुगतान किया, नि: शुल्क, स्व-लिखित ... कई वर्षों से मुझे यकीन था कि इस मामले में कंजूसी नहीं करना बेहतर है: या तो एक उच्च-गुणवत्ता वाला उपकरण खरीदें, या एक टीम को किराए पर लें और "कंपनी के लिए एक आदर्श उपकरण लिखें, जो उन आवश्यकताओं के साथ हो।" आपको जरूरत है। "
तो, सबसे पहले: यह स्पष्ट हो गया कि मौजूदा चेकलिस्ट परीक्षण की सफलता का सामना नहीं कर सकते। वे पर्याप्त नहीं हैं, उनके पास बहुत कम जानकारी है, वे पारदर्शी नहीं हैं, उन पर परिणाम पेश करना मुश्किल है, उन्हें बनाए रखना मुश्किल है, नए लिखने के लिए पर्याप्त समय नहीं है। दूसरी बात: इस स्थिति में, हमें एक ऐसे उपकरण की आवश्यकता थी, जो समझने में काफी आसान हो, जो हमें प्रभावी रूप से परीक्षण प्रबंधन परिदृश्य का प्रबंधन करने की अनुमति देगा: "आवश्यकताएँ -> परीक्षण के मामले -> समीक्षा -> परीक्षण सूट -> परीक्षण चक्र -> परिणाम।"

उपरोक्त सभी को सारांशित करते हुए, उपकरण की आवश्यकताएं निम्नानुसार थीं:

- सुविधाजनक यूजर इंटरफेस
- स्थापना, कार्यान्वयन और समर्थन में आसानी
- सुविधाजनक लेखन और परीक्षण लिपियों का भंडारण
- JIRA से संपर्क करें
- निम्नलिखित परिदृश्य का प्रभावी प्रबंधन: "आवश्यकताएं -> परीक्षण के मामले -> समीक्षा -> परीक्षण सूट -> परीक्षण चक्र -> परिणाम"
- एक परीक्षण चलाने के लिए विभिन्न क्षेत्रों से परीक्षण मामलों का सुविधाजनक चयन
- परीक्षण सूट के प्रक्षेपण पर पारदर्शी रिपोर्ट प्राप्त करने में आसानी
भविष्य में ऑटो-परीक्षण और लिखित ऑटो-परीक्षण के प्रक्षेपण के साथ एक उपकरण को जोड़ने का अवसर

तो, क्या माना जाता था:

- माइक्रोसॉफ्ट टेस्ट लैब ( रूसी में कैसे )
- जेफायर
- टेस्ट लिंक
- टेस्टिया टारेंटयुला
- टेस्ट रेल

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

मैं कुछ मुख्य बिंदुओं को पूरा करने की कोशिश करूंगा:

माइक्रोसॉफ्ट टेस्ट लैब

"बहुत-बहुत-शांत-में-सब कुछ", है ना? हालांकि, यदि आपने कभी इसकी स्थापना और कार्यान्वयन का सामना नहीं किया है, तो आशावादी पूर्वानुमान आवश्यक नहीं हैं। इसे हल्के ढंग से रखने के लिए, यदि आपके पास अपने निपटान में कुछ महीने हैं - स्वागत है। स्थापित करें, कॉन्फ़िगर करें, एक अच्छा बोनस भी है - रूसी में कैसे पूरा करें। हमारे लिए, मुख्य लाभ ऑटो-टेस्ट के साथ संचार का लाइसेंस और आसान सेटअप था।
कुल: इसे लागू करने और इसका उपयोग करने के लिए सीखने का समय नहीं था।

हलकी हवा

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

परीक्षण लिंक

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

टेस्टिया टारेंटयुला

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

टेस्ट रेल

मेरी राय में - सबसे आसान में से एक, लेकिन एक ही समय में बहुत बड़े पैमाने पर मौजूदा उपकरण। मुख्य प्लस - अनुकूलन लगभग हर चीज में संभव है। डिजाइन से शुरू, तर्क से समाप्त। JIRA के साथ प्रत्यक्ष एकीकरण। प्रभावी रूप से परीक्षण मामलों में प्रवेश करें और उन्हें सही सुइट्स में तोड़ दें। जैसा कि कुछ मंत्रियों ने किया था - हाल ही में, टेस्ट रेल में खराब तरीके से लागू की गई रिपोर्टिंग प्रणाली थी: टेस्ट रन पर खराब परिणाम, रिपोर्ट के अनुकूलन की कमी, आदि। हालाँकि, Gurock & Co ने इस मामले को उठा लिया और टूल के 3rd वर्जन तक लोगों ने बग्स पर काम किया। रिपोर्टिंग ने नए रंगों में खेलना शुरू कर दिया है: यदि आप चाहते हैं - एक मील का पत्थर पर एक रिपोर्ट, यदि आप चाहते हैं - केवल दोषों पर, यदि आप चाहते हैं - हम नियमित रूप से परिभाषित कार्यक्षमता का परीक्षण करने पर एक रिपोर्ट के साथ एक नियमित ई-मेल सेट करेंगे, आदि। शाबाश! निचला रेखा - यह उपकरण मेरी आवश्यकताओं के सभी (!) से मिला, थोड़ा ऊपर सूचीबद्ध।

कुल: हमारी पसंद टेस्ट रेल की शुरूआत है। वास्तव में, टेस्ट रेल क्या है?

• यह परीक्षण मामलों, योजनाओं और परीक्षण चक्रों (परीक्षण स्क्रिप्ट बनाने / संग्रहीत / संपादित करने, परीक्षण योजनाओं का प्रबंधन करने, परीक्षण चक्र शुरू करने, परीक्षा परिणाम रिकॉर्ड करने) का एक प्रभावी प्रबंधन है
• यह परीक्षण की गुणवत्ता में महत्वपूर्ण सुधार है (परीक्षण परिदृश्यों का स्पष्ट विवरण, उनकी समीक्षा, आवश्यकताओं के साथ सहसंबंध, क्षेत्रों में विभाजन - यह सब हमें कार्यात्मक परीक्षणों के साथ कवरेज की पूर्णता दोनों का मूल्यांकन करने की अनुमति देता है और संपूर्ण परियोजना टीम के लिए एक आवश्यक सामग्री है)
• यह वास्तविक समय परीक्षण परिणाम प्राप्त कर रहा है (पूरी तरह से अलग मानदंडों पर रिपोर्ट बना रहा है: दोष सारांश, मामलों की तुलना, परियोजनाओं / घटकों / मील के पत्थर, आदि के लिए परीक्षण के परिणाम)
• यह परीक्षण विभाग के कार्यभार का एक आसान संगठन और सुविधाजनक ट्रैकिंग है (काम करने वाले डैशबोर्ड के पूर्ण अनुकूलन के अवसर, साथ ही क्यूए विभाग का दर्जा प्राप्त करने के लिए सुविधाजनक है)

की शुरूआत

1. हमने MSSQL बेस के साथ Windows Server 2008 R2 वर्चुअल मशीन पर TestRail डाल दिया
2. AD प्रमाणीकरण सेट करें
3. JIRA के साथ पूर्ण कनेक्शन स्थापित करें

सबसे पहले, TestRail के प्रत्येक लॉग-इन उपयोगकर्ता को JIRA के लिए एक सीधा आउटपुट कॉन्फ़िगर करने की आवश्यकता है। ऐसा करने के लिए, हमें कुछ कस्टम चर jira_user + jira_password (स्वागत है: docs.gurock.com/testrail-integration/defects-plugins-variables ) की आवश्यकता है। JIRA_Rest प्लगइन (प्रशासन -> एकीकरण -> JIRA_Rest) में उन्हें बनाने के बाद, निम्नलिखित सेट करें:

[कनेक्शन]
पता = http: // jira / ***
उपयोगकर्ता =% jira_user%
पासवर्ड =% jira_password%

उर। अब प्रत्येक उपयोगकर्ता के पास My Settings में JIRA से लॉगिन / पासवर्ड सेट करने का अवसर है।

अगला, JIRA_Rest में, हम दोनों कनेक्शन को सीधे स्थापित JIRA के साथ पंजीकृत करते हैं, और बाद में सभी मौजूदा JIRA क्षेत्रों के लिंक: चाहे वह मुख्य क्षेत्र या रिवाज हो (आपका स्वागत है: docs.gurock.com/trarail-integration/tools-jira-rest )।

JIRA के साथ सीधा संचार (उदाहरण):
संदर्भ देखें यूआरएल: अपने सर्वर / जीरा / ब्राउज़ /% आईडी%
संदर्भ जोड़ें यूआरएल: अपने सर्वर / जीरा / सुरक्षित / CreateIssue ! Default.jspa

मुख्य क्षेत्रों के लिंक (उदाहरण):
[Push.fields]
सारांश = पर
प्रोजेक्ट = पर
जारी करना = पर जारी करना
घटक = पर
कार्यभार = पर
प्राथमिकता = पर
प्रभावित_विभाजन = पर
fix_version = बंद
अनुमान = बंद
लेबल = बंद
पर्यावरण = बंद
वर्णन = पर

कस्टम फ़ील्ड के लिंक (उदाहरण):
[Push.fields]
customfield_XXXXX = पर

[Push.field.customfield_XXXXX]
लेबल = ग्राहक
आकार = कॉम्पैक्ट
टाइप = ड्रॉपडाउन
आवश्यकता = सत्य

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

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

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

थोड़ा और विस्तार से: हम एक परीक्षण सूट बनाते हैं। फिर इसके अंदर हमारे पास इन वर्गों के अंदर सेक्शन और टेस्ट केस दोनों को जोड़ने का अवसर है। हमारे पास अवसर है, केस के आंतरिक सार पर जाए बिना, केवल सारांश दर्ज करके और दर्ज करने के बाद Enter दबाकर टेम्पलेट्स (= चेकलिस्ट / टेस्ट प्लान) की रचना करने के लिए। यह इस तरह दिखता है:



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



इस क्षेत्र को केवल सही करने के लिए संपादन प्रपत्र में परीक्षण केस लिखकर (नहीं, आपको केवल "केवल शीर्षक" =) पर टिक करने की आवश्यकता है।



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



5. परीक्षण मामले के सभी आंतरिक क्षेत्र भी अनुकूलन योग्य हैं

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

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

- आईडी ऑटो और ऑटो क्षेत्रों को जोड़ा गया । आईडी ऑटो - ऑटो परीक्षण के लिए एक अनूठी आईडी। ऑटो - हां / नहीं चेकबॉक्स, जो दिखाता है कि परीक्षण का मामला स्वचालित है या नहीं।

ऐसा इसलिए किया जाता है ताकि भविष्य में, स्वचालन के लिए टेस्ट रेल स्थापित करते समय, आप आवश्यक ऑटो-टेस्ट चलाने के लिए तुरंत इन मापदंडों का उपयोग कर सकें और उन पर आवश्यक रिपोर्ट उत्पन्न कर सकें (http://www.gurock.com/testrail/tour/5/) - स्वचालित परीक्षण और एपीआई)।

6. किसी भी टेस्ट रन के लिए, आप परीक्षण मामलों के किसी भी सेट को चुन सकते हैं

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



लेकिन, हम कहते हैं, हम नाम से चयन करते हैं, जो "कुछ के बराबर या सम्‍मिलित है":



इस सब के साथ, फुल रन के लिए एक टेस्ट सूट चुना जा सकता है।

7. अनुकूलन रिपोर्टिंग प्रणाली

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

निष्कर्ष

चेकलिस्ट, तदर्थ परीक्षण अच्छे हैं, हालांकि, स्पष्ट प्रक्रियाओं के बिना, अक्सर उत्पाद में कमजोर बिंदु होते हैं जो समय के साथ बढ़ते हैं और कंपनी को नीचे खींचते हैं। परीक्षण मामलों और एक कवरेज मैट्रिक्स (कम से कम घटक-वार) दोनों का एक सेट होने से - इससे बचा जा सकता है।

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

अपना टूल चुनें, परीक्षण करें, प्रक्रिया को नियंत्रित करें! आपके सभी प्रयासों में शुभकामनाएँ!

लेख के लेखक: वसीली पेटुखोव, विश्लेषण और गुणवत्ता प्रबंधन विभाग के प्रमुख Diary.ru