टेस्ट मैच्योरिटी मॉडल: एक परीक्षक किसी परियोजना और योजना प्रक्रियाओं का मूल्यांकन कैसे कर सकता है

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

लेकिन अक्सर मुझे छोटी टीमों में पेश किया गया था, जिसमें 1-2 टेस्टर के लिए 5 डेवलपर्स थे और, एक नियम के रूप में, परियोजना में बहुत गर्मी थी। वास्तव में, मैं आपके साथ साझा करना चाहता हूं कि कैसे समझें कि आप कहां हैं और क्यूए प्रक्रियाओं के निर्माण में आगे कैसे शुरू करें।

सबसे पहले, आपको यह समझना चाहिए कि आप किस प्रोजेक्ट पर हैं।

परियोजनाओं में भाग लेने से अनुभव प्राप्त करने के बाद, मैं उन्हें सशर्त रूप से 3 प्रकारों में विभाजित करूंगा:

• परीक्षण के बिना परियोजनाओं;
• अनुचित परीक्षण वाली परियोजनाएं;
• परीक्षण परियोजनाओं।

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

परिपक्वता मॉडल क्या है

और यहाँ मैं बहुत चतुराई से विकिपीडिया से एक उद्धरण डाल रहा हूँ:

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

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

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

परिपक्वता मॉडल स्तर

ये 5 स्तर हैं, जिनके भीतर उद्यम की कार्य / विश्वसनीयता / स्थिरता का मूल्यांकन किया जाता है।

जहां परिपक्वता मॉडल में परीक्षण किया जाता है

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

पहला स्तर "शुरुआती" है

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

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

परिणामस्वरूप:

• कोई परीक्षण दस्तावेज नहीं;
• उत्पाद अस्थिर है;
• समस्या स्थितियों के दौरान प्रक्रियाओं से इनकार;
• परीक्षण डिबगिंग सहायता से ज्यादा कुछ नहीं है।

दूसरा स्तर - "दोहराने योग्य"

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

मुख्य लक्ष्य यह सुनिश्चित करना है कि उत्पाद निर्दिष्ट आवश्यकताओं को पूरा करता है।

परिणामस्वरूप:

• परीक्षण के मुख्य प्रकार और प्रकार हैं (एकीकरण, मॉड्यूलर, प्रतिगमन, स्वीकृति);
• परीक्षण योजनाओं को लागू किया गया;
• परीक्षण गतिविधियों की निगरानी और नियंत्रण किया जाता है;
• प्रक्रिया प्रलेखित है और दोहराया जा सकता है।

तीसरा स्तर - "परिभाषित"

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

परिणामस्वरूप:

• परीक्षण आवश्यकताओं के चरण से शुरू होता है;
• गतिविधियों को जोड़ा जाता है जो आपको अधिक कुशलता से काम करने की अनुमति देता है (आंतरिक प्रशिक्षण, अतिरिक्त समीक्षा);
• गैर-कार्यात्मक परीक्षण शुरू किया जा रहा है।

चौथा स्तर - "मापने योग्य"

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

परिणामस्वरूप:

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

पांचवां स्तर - "अभिनव"

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

परिणामस्वरूप:

• निरंतर प्रक्रिया में सुधार;
• रोकथाम और अनुकूलन पर ध्यान दें।

इस संरचना का ज्ञान कैसे मदद करता है

केस नंबर 1. अनुचित परीक्षण

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

केस नंबर 2. बिना परीक्षण के

मेरी राय में, इस प्रकार की परियोजनाएँ तीन मामलों में हो सकती हैं:

• परियोजना अभी शुरू हो रही है;
• थोड़ी कार्यक्षमता होने पर परियोजना पर परीक्षक की कोई आवश्यकता नहीं थी;
• पूर्ण-स्टैक टीम ने गुणवत्ता कोड-समीक्षा और देव-परीक्षण के साथ परीक्षकों की कमी को बंद कर दिया।

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

केस नंबर 3. परीक्षण था

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

केस नंबर 4. एक में तीन

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

बहुत कम समय के बाद, मैं सुरक्षित रूप से कह सकता हूं कि हम पहले से ही जानबूझकर तीसरे स्तर पर जा रहे हैं - यहां तक ​​कि व्यावसायिक आवश्यकताओं पर भी जुड़ा हुआ परीक्षण :)

निष्कर्ष

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

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