एक कंपनी में परीक्षण विकास के 7 चरण

मैंने यह बताने के लिए परीक्षण के विकास में 7 प्रमुख चरणों की पहचान की है कि कंपनियों में गुणवत्ता आश्वासन के दृष्टिकोण कैसे बदल रहे हैं। लेख पढ़ने के दौरान, आप परीक्षण के विकास का पता लगाने, अपने वर्तमान चरण का निर्धारण करने और यह पता लगाने में सक्षम होंगे कि प्रक्रिया और परीक्षण की गुणवत्ता में सुधार के लिए क्या किया जाना चाहिए।

लेख मूल रूप से सीआईएस पत्रिका के लिए लिखा गया था, लेकिन मुझे लगता है कि यह हबर उपयोगकर्ताओं के लिए भी दिलचस्प होगा।

तो, चरणों।

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

अब प्रत्येक चरण के बारे में अधिक विस्तार से।

स्टेज 1. परीक्षण डेवलपर और / या प्रबंधक द्वारा किया जाता है

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

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

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

स्टेज 2. परीक्षक बहुत अंत में परियोजना की जांच करता है

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

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

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

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

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

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

स्टेज 3. मूल कार्य के साथ परिणाम के अनुपालन के लिए सभी कार्यों की जाँच की जाती है।

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

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

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

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

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

स्टेज 4. परीक्षक परीक्षण डिजाइन में लगे हुए हैं।

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

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

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

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

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

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

स्टेज 5. एक परीक्षण प्रबंधन प्रणाली शुरू की जा रही है

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

ऐसी प्रणाली की अनुमति देता है:

• स्टोर आवश्यकताओं और परीक्षण मामलों;
• परीक्षण मामलों के साथ सहयोगी आवश्यकताएं
• परीक्षण कवरेज का विश्लेषण;
• परीक्षण मामलों के विभिन्न संस्करणों को संग्रहीत करें;
• टेस्ट रन बनाएं
• परीक्षण रन का तुलनात्मक विश्लेषण करना;
• परीक्षण रिपोर्ट रखें;
• कार्यों और संसाधनों को समायोजित करने के लिए टीम कार्यभार ट्रैक करें।

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

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

स्टेज 6. नियमित जांच स्वचालित है

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

विकसित ऑटोटेस्ट्स को निरंतर एकीकरण प्रक्रिया ( CI / CD ) में शामिल किया गया है, जो टीम को कमिट के समय त्रुटियों के बारे में जानने की अनुमति देता है।

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

चरण 7. पदानुक्रम अधिक जटिल हो जाता है, नई भूमिकाएं दिखाई देती हैं

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

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

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

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

निष्कर्ष

हमने एक कंपनी में परीक्षण के विकास में महत्वपूर्ण चरणों की जांच की। सचेत पेशेवर परीक्षण परीक्षण डिजाइन चरण से शुरू होता है। टेस्ट डिजाइन उत्पाद की गुणवत्ता में निरंतर सुधार प्रदान करता है।

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

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