सभी को नमस्कार!

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

स्रोत

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

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

अध्याय 1. पहला जीआईएस परीक्षण परियोजना की शुरुआत

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

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

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

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

कभी-कभी स्थिति 180 डिग्री तक बदल जाती थी। सहमत हूं, जब कोई ट्रेन तेज गति से चलती है, तो परिणामों के बिना दिशाओं को तेजी से बदलना असंभव है।

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

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

नतीजतन, बदलती आवश्यकताओं का नुकसान परीक्षण के लिए नए कार्य के रूप में परीक्षकों के लिए फायदे में बदल गया और परियोजना के अंतिम परिणाम को प्रभावित करने की क्षमता।

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

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

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

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

अध्याय 2. जीआईएस की विशेषताएं। परीक्षक कैसे रहते हैं और उनके साथ काम करते हैं

सबसे पहले, बड़े जीआईएस विश्वसनीयता और भार, सिस्टम ऑपरेशन के लिए बढ़ती आवश्यकताओं के अधीन है - 24/7, सिस्टम की खराबी से डेटा हानि, सिस्टम पुनर्प्राप्ति समय नहीं होना चाहिए - 1 घंटे से अधिक नहीं, प्रतिक्रिया समय - 2 सेकंड से अधिक नहीं और बहुत अधिक।

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

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

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

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

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

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

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

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

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

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

जीआईएस परीक्षण के संचालन में डाल दिया गया था, और फिर औद्योगिक एक में, एक नया कार्य दिखाई दिया - उपयोगकर्ता घटनाओं को संभालना।

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

परीक्षण टीम को पहले इस तरह के कार्य का सामना नहीं करना पड़ा है। नए रिलीज़ चक्र में संसाधित, व्यवस्थित, स्थानीयकृत, सुधारा, सत्यापित और सम्मिलित होने के लिए आवश्यक घटनाओं का प्रवाह।

ऑपरेशन की प्रक्रिया की समझ और परिपक्वता के स्तर में वृद्धि हुई और सुधार हुआ जैसा कि प्रणाली ने खुद को विकसित किया।

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

अध्याय 3. जीआईएस के परीक्षण की समस्याएं और उन्हें हल करने के तरीके। टीमों के प्रबंधकों का परीक्षण करने की सिफारिशें।

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

बहुत सारी कार्यक्षमता होने पर क्या करें?

घबराएं नहीं और कार्यात्मक को ब्लॉक / मॉड्यूल / फ़ंक्शन में तोड़ दें, विश्लेषक को परिणाम के ऑडिट से कनेक्ट करें, सुनिश्चित करें कि कार्यात्मक ब्लॉक की दृष्टि सही है।

हम बनाने की सलाह देते हैं:

.

, , , , production. , .
//.

, , — , ///. , , , - , , , / // , , « » , .

कार्यात्मक आवश्यकताओं के ज्ञान और कवरेज की परिपक्वता के साथ क्या करना है?

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

सबसे महत्वपूर्ण कार्यों / ब्लॉकों / मॉड्यूल को परीक्षण के लिए एक उच्च प्राथमिकता सौंपी जाएगी, कम महत्वपूर्ण वाले को दूसरी प्राथमिकता परीक्षणों द्वारा कवर किया जाएगा, बाकी तीसरा होगा, या यदि "समय सीमाएं" हैं, तो आप एक शांत समय के लिए उनके परीक्षण को स्थगित कर सकते हैं।

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

जब आवश्यकताएं ऐतिहासिकता का समर्थन नहीं करती हैं, तो उलझन में हैं, दोहराए गए हैं, परीक्षक इसके साथ कैसे काम करते हैं?

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

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

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

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

लोड परीक्षण करने के लिए आवश्यक होने पर क्या करना है?

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

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

लोड परीक्षणों को चलाने, लोड परिणाम लेने और डेवलपर्स को बाधाओं को समाप्त करने के लिए इसे पारित करने की प्रक्रिया को लागू करना भी सार्थक है।

लोड की प्रक्रिया को प्रत्येक रिलीज से पहले नियमित रूप से किया जाना चाहिए, समय-समय पर लोड बाधाओं को बदलना चाहिए ताकि नए बाधाओं की पहचान की जा सके।

जब एकीकरण परीक्षण करना आवश्यक हो, जिसमें कोई अनुभव न हो तो क्या करें?

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

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

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

स्रोत

कोड शाखाओं, स्टैंड, तैनाती में भ्रमित न हों और आवश्यक कोड का परीक्षण कैसे करें?

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

जब रिलीज शाखा को उत्पादन के लिए भेजा गया और विकास की अगली पुनरावृत्ति शुरू हुई, तो कुछ बिंदु पर हमने नए कार्यों के विकास को समानांतर बनाने का फैसला किया, ताकि रिलीज के माध्यम से योजनाबद्ध बड़े कार्य को समय पर पूरा किया जा सके। किसी समय, ऐसी 3-4 शाखाएँ थीं। भविष्य के रिलीज के परीक्षण परीक्षण को जल्द से जल्द शुरू करने के लक्ष्य के साथ तीन से अधिक परीक्षण स्टैंड तैनात हैं।

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

हम परीक्षण शुरू करते हैं और समझते हैं कि:

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

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

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

हमने भविष्य में ऐसी ही स्थितियों से बचने के लिए क्या किया:

डेवलपर बुनियादी ढांचे के विशेषज्ञ के लिए निर्देश तैयार करता है, जिसमें संकेत दिया जाता है कि कहां से तैनात करना है, यह निर्देश कार्य के माध्यम से जीरा को दिया जाता है;
बुनियादी ढांचा विशेषज्ञ भ्रमित नहीं है और वह वही करता है जो उसे दिया गया था;
GIT, , jira ;
jira :
Gitflow , , hotfixes develop, .

, , ?

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

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

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

बेशक, इसने सभी कार्यक्षमता का 100% परीक्षण कवरेज नहीं दिया, लेकिन इसने सिस्टम में मुख्य व्यवसाय परिदृश्यों के अनुसार उत्पादन में होने वाले क्रॉस-ब्राउज़र दोषों के जोखिम को काफी कम करने की अनुमति दी।

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

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

हमें क्या मिला:

अनुकूलित परीक्षण लागत, दोनों वित्तीय और समय, समय के एक अंतराल के लिए हमने प्रतिगमन परीक्षण और क्रॉस-ब्राउज़र दोनों की जांच की;
, Severity;
, , .

?

काफी जल्दी, हमारे पास एक एकल रिपॉजिटरी में परीक्षण चलाने के बारे में एक सवाल था, उन्हें अद्यतित रखने और निष्पादन के परिणाम पर अंक के साथ परीक्षण रन चलाने की क्षमता के बारे में।

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

विश्लेषक और परीक्षण टीम के साथ परामर्श करने के बाद, हमने फैसला किया कि इसके समर्थन की लागत के कारण इतने बड़े परीक्षण मॉडल को हमेशा अद्यतित रखना आवश्यक नहीं था।

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

धुआं - परीक्षण मामलों के लिए उपयोग किया जाता है जिसमें धुआं परीक्षण शामिल है ( महत्वपूर्ण कार्यक्षमता के स्पष्ट दोषों का पता लगाने के लिए परीक्षणों का एक न्यूनतम सेट प्रदर्शन );
ऑटो परीक्षण - परीक्षण मामलों के लिए उपयोग किया जाता है जिसके द्वारा ऑटोटेस्ट विकसित किए जाते हैं;
प्राथमिकता 1 - प्राथमिकता 1 लेबल वाले व्यावसायिक कार्यों से संबंधित परीक्षण मामलों के लिए उपयोग किया जाता है।

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

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

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

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

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

यहाँ TestLink में परीक्षण मामलों का एक सेट है:

टेस्टलिंक में मामलों को अद्यतन करने की प्रक्रिया का आविष्कार किया गया था

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

यदि आवश्यक हो, तो मामलों को अपडेट करें:

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

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

प्रत्येक रिलीज़ के बाद, हम अनुमान लगा सकते हैं कि "जोड़ा गया" / "परिवर्तित" लेबल के आधार पर हमारा प्रतिगमन मॉडल कितना बदल गया है।

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

प्रतिगमन परीक्षण मॉडल को कैसे अनुकूलित किया जा सकता है?

हमने एक प्रतिगमन परीक्षण मॉडल के साथ काम करना शुरू कर दिया, प्राथमिकताओं को उजागर करके प्रतिगमन के परीक्षण मामलों को विकसित करने की प्रक्रिया को अनुकूलित किया और प्रतिगमन में केवल "प्राथमिकता 1" मामलों को शामिल किया। इस तथ्य का सामना करना पड़ा कि परीक्षण मॉडल, थोड़ी देर बाद, बड़ा हो गया, इसके मामलों को चलाने की लागत बढ़ गई, और हमने परियोजना पर प्रतिगमन परीक्षण करने के लिए स्वीकार्य समय अंतराल में गिरना बंद कर दिया।

परीक्षण स्वचालन को लागू करने का समय आ गया है, जिसका उद्देश्य था:

प्रतिगमन परीक्षण के मामलों को पूरा करने के लिए समय कम करना;
बाद में जाँच करने के लिए पूर्व शर्त बनाने के लिए ऑटो-परीक्षणों का उपयोग करें, जिससे परीक्षण डेटा बनाने के समय और मानव लागत का अनुकूलन हो;
मैन्युअल परीक्षण के परिणामों पर मानव कारक के प्रभाव को समाप्त करके प्रतिगमन परीक्षण की गुणवत्ता में सुधार करना;
, .

जावा में जीयूआई परीक्षणों को स्वचालित करने के लिए एक रूपरेखा विकसित की गई थी (जीआईटी का उपयोग एक स्रोत नियंत्रण संस्करण प्रणाली के रूप में किया गया था)।

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

कार्यात्मक मैनुअल परीक्षण के हिस्से पर, प्रतिगमन मॉडल को भी अनुकूलित किया गया था।

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

एक जीआईएस प्रोजेक्ट पर इसे "टेस्ट सेशन" कहा जाता था, दूसरे पर इसे "टेस्ट टूर" कहा जाता था। लेकिन सार वही रहा - हमने एंड-टू-एंड (पूरे संशोधन के माध्यम से) प्रमुख व्यावसायिक परिदृश्य के माध्यम से सोचा जो पूरी तरह से लागू संशोधन के व्यापार विचार को कवर करता है (ऐसे कई परिदृश्य हो सकते हैं)।

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

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

उदाहरण के लिए एक परीक्षण दौरा जटिल हो सकता है:

बनाने, संपादित करने और संचय करने के अधिकार दें,
"विशेषज्ञ" की भूमिका के साथ उपयोगकर्ता के "व्यक्तिगत खाते" में एक इकाई बनाएं,
,
,
,
« » «»,
, .

SLA?

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

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

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

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

ठेठ या अक्सर सामना किए गए एसक्यूएल प्रश्नों के साथ परियोजना ज्ञान का आधार बनाए रखना;
बगट्रैक में आने वाले कार्यों को रैंकिंग करने की प्रक्रिया को व्यवस्थित करें ताकि संकेतक पैनल पर परीक्षक तुरंत एक गिरती हुई घटना को देखता है और इसे पहली प्राथमिकता में काम करने के लिए लेता है;
SLA वाले कार्यों के लिए JIRA में उलटी गिनती का समय जोड़ें;
घटनाओं के लिए एक चेतावनी प्रणाली स्थापित करना;
production ( — ), , , , , , production;
« » « ». .

"ज्ञान मैट्रिक्स" के बारे में ऊपर लिखा गया था। "जिम्मेदारी मैट्रिक्स" के रूप में, यह एक तालिका है जिसमें, "ज्ञान मैट्रिक्स" के साथ सादृश्य द्वारा, कार्यात्मक ब्लॉक / मॉड्यूल / उपप्रणाली लिखी जाती हैं और जो परीक्षण समूह के कार्यात्मक के परीक्षण के लिए जिम्मेदार है, एक नियम के रूप में, यह टीम लीड या वरिष्ठ / लीड परीक्षक है। एक समूह में।

क्या होगा अगर एक कार्यात्मक ब्लॉक / मॉड्यूल / सबसिस्टम का परीक्षक परियोजना पर व्यापार प्रक्रिया की पूरी तस्वीर को नहीं समझता है?

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

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

इस स्थिति में, निम्नलिखित कार्य किए गए:

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

Fuh! मैंने उनके खात्मे के लिए मुख्य समस्याओं और सिफारिशों को इकट्ठा करने की कोशिश की, लेकिन यह उन सभी उपयोगी जानकारियों से दूर है जिन्हें मैं साझा करना चाहता हूं।

अध्याय 4. परीक्षण के लिए श्रम लागत का आकलन करने के लिए परियोजना की गुणवत्ता और कार्यप्रणाली का निर्धारण करने के लिए मैट्रिक्स

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

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

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

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

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

पूर्ण परियोजनाओं में से किसी एक पर मैट्रिक्स और लक्ष्य का संग्रह कैसा दिखता है, इसका एक उदाहरण है:

परीक्षण के लिए श्रम लागत का आकलन करने की पद्धति

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

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

परीक्षण लागतों का विस्तृत मूल्यांकन करने के लिए मेट्रिक्स का उपयोग किया जाता है

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

त्रुटि दर्ज करने का समय 10 मिनट (बग ट्रैकर में 1 त्रुटि दर्ज करने का समय) है।
त्रुटि / परिशोधन को मान्य करने का समय 15 मिनट है (1 त्रुटि / शोधन के सुधार की शुद्धता को सत्यापित करने का समय)।
1 टीसी (टेस्ट केस) लिखने का समय - 20 मिनट (टेस्टलिंक सिस्टम में टेस्ट केस विकसित करने का समय)।
1 टीसी पूरा करने का समय - 15 मिनट (टेस्टलिंक सिस्टम में एक परीक्षण मामले पर जांच पूरी करने का समय)।
एक परीक्षण के लिए समय। स्तंभ के लिए चेकलिस्ट में लागत जोड़कर प्राप्त कुल समय "लीड समय, मिनट।"
टेस्ट रिपोर्ट समय - 20 मिनट (टेम्पलेट के अनुसार एक रिपोर्ट लिखने का समय)।
गलतियों के लिए समय । सभी त्रुटियों / स्पष्टीकरणों के पंजीकरण के लिए नियोजित समय, (1 त्रुटि / स्पष्टीकरण के पंजीकरण के लिए समय) त्रुटियों की संभावित संख्या / स्पष्टीकरण (संशोधन के लिए 10 त्रुटियां - प्रति संशोधन की अनुमानित संख्या)।
DV (दोष सत्यापन) पर कुल समय । सभी पाया और सही त्रुटियों / शोधन के सत्यापन का समय (1 त्रुटि / शोधन के सत्यापन के लिए समय * त्रुटियों / शोधन की अनुमानित संख्या)।
परीक्षण डेटा की तैयारी। परीक्षण डेटा तैयार करने के लिए समय की गणना अलग-अलग मापदंडों (टेस्ट विश्लेषक की दृष्टि से कार्य के दायरे, कोड विकास टीम (नई अज्ञात टीम या जिसके लिए काम की गुणवत्ता पर आँकड़े हैं) के लिए योग्यता के आधार पर वर्तमान परियोजना पर समान कार्यों के परीक्षण के अनुभव के आधार पर की जाती है। , विभिन्न मॉड्यूलों के बीच एकीकरण, आदि)।

किसी एक परियोजना की वास्तविक लागतों को मापकर, निम्नलिखित की गणना की गई थी:

विकास के 60 घंटे तक प्रति कार्य 1 घंटे से अधिक नहीं,
विकास के 150 घंटे तक प्रति कार्य 3 घंटे से अधिक नहीं,
विकास के 300 घंटे तक प्रति कार्य 4 घंटे से अधिक नहीं।

विशेष मामलों में, परीक्षण डेटा की तैयारी के लिए नियोजित लागत परीक्षण प्रबंधक के साथ समझौते में बदल सकती है।

टीसी लिखने का समय । टीसी लिखने का समय, जो अनुमान के बाद जांच के लिए तैयार हो जाता है कि परीक्षण के लिए निरीक्षण और प्राथमिकता है। प्रतिगमन परीक्षण के लिए, टीसी को प्रायोरिटी 0 (वरीयता की संख्या 0 * 20 मिनट (1 टीसी के लिए लेखन समय)) के साथ चिह्नित किया गया था।
टीसी के अनुसार वापस पाने का समय। टेस्टलिंक प्रणाली में टीसी के अनुसार प्रतिगमन परीक्षण के एक पुनरावृत्ति को पूरा करने का समय (टीसी की संख्या * 1 टीसी का औसत निष्पादन समय (15 मिनट))।
जोखिम परीक्षण के लिए समय का 15% निर्धारित किया गया है (जोखिम का मतलब है सभी मैनुअल ऑपरेशन, स्टैंड फॉल्स, ब्लॉकिंग समस्याएं, आदि)।
परीक्षण के लिए कुल समय।एक एचएल के लिए परीक्षण की कुल लागत (परीक्षण डेटा + परीक्षण निष्पादन की तैयारी + त्रुटियों / स्पष्टीकरण को पंजीकृत करने के लिए समय + त्रुटियों / परिशोधनों का सत्यापन + समय प्राथमिकता प्राथमिक टीसी 0 + जोखिमों के अनुसार पुन: प्राप्त करने के लिए) में एच / एच।
कार्य के लिए कुल समय। संपूर्ण परीक्षण कार्य के लिए कुल लागत, एच / एच में आंकड़ा (परीक्षण के लिए कुल समय + टीसी लिखने के लिए समय)।

इन सभी मैट्रिक्स का उपयोग परियोजना पर नियोजन, कार्य मूल्यांकन, अस्थायी और वित्तीय दोनों से संबंधित विभिन्न कार्यों को हल करने के लिए किया जाता है। जैसा कि अभ्यास से पता चला है, ऐसा अनुमान न्यूनतम त्रुटि देता है (10% से अधिक नहीं), जो अनुमान की विश्वसनीयता का काफी उच्च संकेतक है।

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

अध्याय 5. एक सफल जीआईएस परीक्षण प्रक्रिया के लिए नुस्खा

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

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

विश्लेषिकी प्रक्रिया से:

तकनीकी आवश्यकताओं को लागू करें टेम्पलेट्स
विश्लेषकों के एक समूह में तकनीकी आवश्यकताओं के विकास के लिए नियमों को लागू करना;
परियोजना टीम की तकनीकी आवश्यकताओं की तत्परता की सूचना पर नियमन विकसित करना।

- ;
;
;
:

○ - ;
○ -;
○ ;
, , , , , ;
, , , , ;
;
;
;
;
(, , ..);
, , ;
अधिक अनुभवी सहकर्मियों की सिफारिशों का उपयोग करें, अन्य परियोजनाओं के विकास, तैयार किए गए चीट शीट , टीम के साथ विचार-विमर्श सत्र का संचालन करें और प्रक्रिया के अनुकूलन और सुधार के लिए नए तरीकों की तलाश करें।

अब मैं नए जीआईएस का परीक्षण करने के लिए तैयार हूं। यह वही है जो मेरे कामकाजी विकी की तरह दिखता है, जो पहले से ही कई बिंदुओं को ध्यान में रखता है जिन्हें हमने करने की सिफारिश की थी:

रोगी पाठकों के लिए आश्चर्य।

यदि आप लेख को अंत तक पढ़ते हैं, तो आप एक उपहार के पात्र हैं। मैं आपके साथ उपयोगी टेम्प्लेट साझा करना चाहता हूं जिन्हें आप अपने काम में उपयोग कर सकते हैं:

चेकलिस्ट टेम्पलेट , जिसमें स्क्रीन रूपों के इंटरफ़ेस तत्वों के परीक्षण के लिए सिफारिशों का न्यूनतम सेट शामिल है (बेशक, चेक के लिए व्यापक विकल्प हैं, यह सिर्फ एक उदाहरण है), गणना पद्धति के स्पष्टीकरण के साथ परीक्षण की लागतों की गणना के लिए सूत्र शामिल हैं;
परीक्षण रिपोर्ट टेम्पलेट ;
मैट्रिक्स टेम्पलेट : प्रोजेक्ट टीम के ब्राउज़रों / प्लेटफार्मों / छुट्टी अनुसूची द्वारा ज्ञान / वितरण;
स्पष्टीकरण के साथ परियोजना के लिए मुख्य मैट्रिक्स की एक सूची ।

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

यदि आप LANIT परीक्षण टीम में शामिल होना चाहते हैं और GIS परीक्षण में भाग लेना चाहते हैं, तो मैं आपको हमारी कंपनी की रिक्तियों को देखने की सलाह देता हूं।

हमारे परीक्षण स्कूलों में आओ!

, , .

मैं आपको सभी दिलचस्प परियोजनाओं और शुभकामनाएं देता हूं!

पुनश्च यह वास्तव में एक छोटा सा सर्वेक्षण करने के लिए भीख माँगता है।

हमने राज्य सूचना प्रणाली के परीक्षण से क्या सीखा