टेस्ट सॉल्यूशन आर्किटेक्ट: यह कौन है और कब इसकी जरूरत है

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

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

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

संक्षिप्त परियोजना विवरण

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

परियोजना पर कौन सी परीक्षण भूमिकाएँ थीं?

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

• 1 टेस्ट लीडर या टेस्ट लीड
• 40 मैनुअल परीक्षक जिन्होंने स्क्रैम टीमों के साथ काम किया (7 टीम)
• 2 डेवलपर्स (यह अधिक संभावना एक अपवाद है, क्योंकि डेवलपर्स स्वचालन कार्यों पर काम करना पसंद नहीं करते हैं) और 2 परीक्षण स्वचालन
• 2 परीक्षक जिन्होंने तनाव परीक्षण किया
• डेवलपर्स और परीक्षण स्वचालन द्वारा विकसित किए गए उत्पादों के परीक्षण के लिए 1 कार्यात्मक परीक्षक

मैनुअल परीक्षण

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

1. परीक्षण योजनाएं बनाएं।
2. एक परीक्षण रणनीति बनाएं।
3. निर्धारित चरणों (अपेक्षित और वर्तमान परिणाम के साथ) के साथ परीक्षण के मामले बनाएं।
4. परीक्षण-मामलों का प्रदर्शन करें और आवेदन की गुणवत्ता पर निष्कर्ष निकालें।

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

इस स्तर पर, सवाल उठने लगे:

1. यह कैसे निष्कर्ष निकाला जाए कि हमारे सिस्टम ने सही ढंग से काम किया है, यदि समय की शिफ्ट के कारण, हम पुराने सिस्टम में प्राप्त परिणामों से भिन्न होते हैं?
2. क्या हम डेटा उत्पादन से दूर हो सकते हैं और स्थिर डेटा पर काम कर सकते हैं? जोखिम क्या हैं?
3. और अगर हम फिर भी स्थिर डेटा पर आते हैं, तो यह कैसे साबित करें कि हमारा सिस्टम दैनिक अद्यतन डेटा के साथ सही ढंग से काम करेगा?

यह कार्यात्मक / मैनुअल परीक्षण के दौरान परियोजना पर उठे समान प्रश्नों की सूची के हिमशैल का केवल टिप है।

परीक्षण स्वचालन

परीक्षण स्वचालन इंजीनियरों (डेवलपर्स और डेवलपर्स) के पास उन अनुप्रयोगों को लिखने का लक्ष्य था जो स्वचालित रूप से परीक्षण कर सकते हैं और / या कार्यात्मक परीक्षकों के काम को सुविधाजनक बना सकते हैं:

• स्व-परीक्षण जो सीआई / सीडी के साथ एकीकृत होंगे;
• कार्यात्मक परीक्षक परीक्षण करने में मदद करने वाले अनुप्रयोग;
• और अन्य विकास जो परियोजना की आंतरिक आवश्यकताओं के लिए आवश्यक थे।

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

1. ग्राहक के साथ मिलकर कौन अनुप्रयोगों के परीक्षण के लिए गैर-कार्यात्मक आवश्यकताओं को विकसित करेगा? सॉल्यूशन आर्किटेक्ट ने कहा कि यह उनका काम नहीं है, जैसा कि एसएएस उस एप्लिकेशन के साथ काम करते हैं जो ग्राहक द्वारा आदेश दिया गया था।
2. परीक्षण अनुप्रयोगों के लिए कार्यक्षमता आवश्यकताओं का विकास कौन करेगा? स्पष्ट आवश्यकताएं हैं, लेकिन गैर-स्पष्ट हैं। उदाहरण के लिए, क्या हमें अपने अनुप्रयोगों के लॉग को संग्रहीत करने और उनका विश्लेषण करने की आवश्यकता है?
3. कौन ग्राहक के साथ अनुप्रयोगों के लिए पर्यावरण का काम करेगा और इन आवश्यकताओं को ठीक करेगा? उदाहरण के लिए, विशेष रूप से इस परियोजना पर स्पार्क 1.4 पर प्रतिबंध था, और यह एप्लिकेशन बनाने के बाद ही पता चला था।

और यह उन सभी मुद्दों से भी दूर है जो परीक्षण स्वचालन के मामले में परियोजना पर उठते हैं।

टेस्ट लीडर, उर्फ ​​टेस्ट लीड

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

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

हमारे प्रोजेक्ट पर, ये भूमिकाएँ दो लोगों द्वारा निभाई गई थीं, और प्रत्येक शेड्यूल इस तरह देखा गया था:


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

1. ग्राहक (यूएटी) द्वारा स्वीकृति परीक्षण के चरण में प्रवेश करने के लिए ग्राहक के साथ एक योजना का विकास।
2. क्लाइंट के साथ आवश्यकताओं का अध्ययन जब यह माना जाता है कि कार्यक्षमता को यूएटी में स्थानांतरित किया जा सकता है।
3. विभिन्न प्रकार के वातावरण (एक बहुत ही नाजुक बिंदु) पर परीक्षण की मान्यताओं के ग्राहक के साथ अध्ययन करें। चूंकि आमतौर पर परीक्षण वातावरण उत्पादन के अनुरूप नहीं होता है, इसलिए किसी अन्य वातावरण पर परीक्षण से संबंधित सभी प्रश्नों को क्लाइंट के साथ काम करना चाहिए।
4. विभिन्न प्रकार के परीक्षण में मैट्रिक्स की स्वीकार्य विसंगति के ग्राहक के साथ अध्ययन करें। उदाहरण के लिए, प्रदर्शन परीक्षण के दौरान ग्राहक को क्या परिणाम देखने की उम्मीद है? शायद यह उसके लिए पर्याप्त होगा कि सिस्टम कोई बदतर काम नहीं करता है।
5. उदाहरण के लिए, संख्या में सभी संभावित मीट्रिक एकत्र करना, इस तालिका के लिए डेटा विसंगतियां 10% से अधिक नहीं होने की अनुमति है, या स्क्रिप्ट को आठ घंटे से अधिक नहीं चलाना चाहिए।

यहाँ क्या गलत है?

ऊपर दिए गए प्रश्न आमतौर पर टेस्ट लीड के कंधों पर रखे जाते हैं, लेकिन एक त्रुटिपूर्ण दृष्टिकोण है:

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

और टीएसए न होने पर यह सभी समस्याएं हैं जो टेस्ट लीड पर आते हैं।

तो यह टीएसए कौन है और इसकी आवश्यकता क्यों है?

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

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

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

जब टीएसए की जरूरत नहीं है?

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

पहले प्रकार की परियोजना - ग्राहक उस कंपनी के विवेक पर परीक्षण प्रक्रियाओं की सेटिंग देता है जिसे उसने काम पर रखा था।

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

दूसरे प्रकार की परियोजना - ग्राहक के पास परीक्षण, एक स्पष्ट तस्वीर और सुव्यवस्थित प्रक्रियाओं की अपनी समझ है।

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

तीसरे प्रकार की परियोजना - ग्राहक को टीएसए सेवाओं की आवश्यकता नहीं है।

कारण अलग हो सकते हैं:

1. सरल कार्यक्षमता के साथ एक छोटी और अल्पकालिक परियोजना।
2. ग्राहक का अपना TSA है।
3. ग्राहक ने परीक्षण करने से इनकार कर दिया, आदि।

टीएसए कौशल

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

संक्षेप में, मेरी राय में, टीएसए होना चाहिए:

1. तकनीकी ज्ञान के साथ, सामान्य रूप से और डोमेन क्षेत्र में जहां वह काम करता है, इस क्षेत्र की समस्याओं को जानने के लिए, विशिष्ट त्रुटियां, समस्याएं और उनकी जांच करने के तरीके।
2. अच्छा संचार कौशल, परीक्षण के मुद्दों के लिए ग्राहक का ध्यान आकर्षित करने में सक्षम होना चाहिए, परीक्षण आवश्यकताओं, परीक्षण दृष्टिकोण, परीक्षण रिपोर्टिंग और कई संबंधित मुद्दों, जैसे कि परीक्षण पर्यावरण।
3. नेतृत्व कौशल और सक्रिय हो क्योंकि परीक्षण बहुत बाद में छोड़ने की कोशिश करते हैं।
4. सामान्य रूप से परीक्षण का अच्छा ज्ञान, परीक्षण प्रलेखन, परीक्षण प्रक्रिया, परीक्षण रिपोर्टिंग, दृष्टिकोण, आदि;
5. सॉफ्टवेयर विकास नियमों का अच्छा ज्ञान: रिलीज नीतियां, नीतियां बनाना, सीआई / सीडी प्रक्रियाओं को समझना आदि।

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

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

निष्कर्ष

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