एक परियोजना प्रबंधक को परीक्षण के बारे में क्या पता होना चाहिए

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

यदि आप औसत आरएम से एक साधारण प्रश्न पूछते हैं: "इस परियोजना पर परीक्षण क्यों किया जा रहा है?", तो उत्तर सबसे अधिक बार होगा "आप एक परीक्षण प्रबंधक हैं, आपको इस प्रश्न का उत्तर देना होगा।"

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

इस लेख में मैं एक विक्रेता की भूमिका निभाने की कोशिश करूंगा जो ग्राहक को दिखाता है: "क्या होता है?" बहुत सी चीजों का वर्णन किया जाएगा, शायद बहुत विस्तृत, बहुत सरल ... गुस्सा मत हो, मैं वास्तव में समझना चाहता हूं :)

परीक्षण से कोई उम्मीदें क्यों बनाई जाती हैं?

Camon! यदि बटन स्वचालित हो तो परीक्षण सभी प्रकार के बटन प्रेस करता है। और इसलिए यह स्पष्ट है कि क्या लक्ष्य हैं! आपको बग ढूंढने की ज़रूरत है, और उतना ही बेहतर। अन्य परीक्षण लक्ष्य क्या हो सकते हैं?

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

कुछ बताता है मुझे नहीं। फिर उन दुर्लभ मामलों में क्या अंतर हैं जब "परीक्षण के साथ सब कुछ ठीक है" और भारी बहुमत?

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

परीक्षण से क्या उम्मीद की जा सकती है?

उत्पाद की गुणवत्ता में सुधार के लिए परीक्षण आवश्यक है। खैर यह स्पष्ट है!

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

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

फिर क्या परीक्षण प्रदान कर सकता है?

हमारे सभी परिणाम, हमारे सभी काम चार चर के एक सूत्र द्वारा वर्णित हैं: परीक्षण कवरेज, सूचना प्रदान, गति और बजट।

आइए पहले इन बिंदुओं को देखें, और फिर स्वयं सूत्र पर आगे बढ़ें।

1. परीक्षण कवरेज

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

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

कवरेज को मापा जा सकता है और मापा जाना चाहिए: ट्रेसबिलिटी मैट्रिक्स, कोड कवरेज, छूटे हुए दोषों का% और आपकी सहायता के लिए अन्य मैट्रिक्स का होस्ट।

2. दी गई जानकारी

सालों तक, एक परीक्षक के बारे में एक ज्ञापन रहता है, उसकी आँखों में एक घबराहट के साथ "कुछ भी नहीं काम करता है!" और अगर आप मुझे और अधिक विस्तार से समझाने के लिए कहते हैं, तो वह जवाब देता है: "ठीक है, बिल्कुल कुछ भी नहीं!"। शायद उन्होंने अच्छा परीक्षण कवरेज प्रदान किया, लेकिन, अफसोस, पर्याप्त जानकारी नहीं दी। परीक्षण से किसी परियोजना को क्या जानकारी मिल सकती है?

• बग ट्रैकर में गुणात्मक रूप से वर्णित कीड़े
• रिलीज के पूर्वानुमान और प्रक्रियाओं के बारे में निर्णय लेने के लिए उत्पाद आँकड़े
• रिलीज के फैसले के लिए गुणवत्ता मैट्रिक्स
• खुद परीक्षण का आकलन: क्या कवरेज, क्या जाँच की है, कितना परीक्षण पर्याप्त है, आदि।

यदि परीक्षण समूह उत्पाद और परियोजना के बारे में स्पष्ट जानकारी नहीं देता है (और यह इसका मुख्य कार्य है!), तो निर्णय लेना बहुत मुश्किल है।

3. परीक्षण की गति

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

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

आमतौर पर यह अदृश्य है, और ऐसा लगता है कि कीड़े सभी परेशानियों का स्रोत हैं ... लेकिन कभी-कभी उन्हें पहले से ढूंढना = पूरे विकास चक्र के लिए लागत कम करना!

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

4. बजट

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

तो आगे क्या है?

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

हमें सटीक संकेतक चाहिए। क्यों? परिवर्तनों का मूल्यांकन करने के लिए। यह निगरानी करने के लिए कि क्या वे वास्तव में संपूर्ण के रूप में पूरे प्रोजेक्ट के प्रदर्शन को प्रभावित करते हैं (चलो ईमानदार हो, आपको अपने आप में कवरेज की आवश्यकता नहीं है)। प्रक्रिया को नियंत्रित करने के लिए।

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

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