परीक्षक, यह जानना चाहते हैं कि प्रबंधकों को सकारात्मक रूप से कैसे प्रभावित किया जाए?

पिछले नोट में प्रोग्रामर को सकारात्मक रूप से प्रभावित करने के लिए परीक्षकों के सुझावों की एक सूची थी।



और यहां सिफारिशें दी गई हैं कि कैसे परीक्षक प्रबंधकों पर सकारात्मक प्रभाव डाल सकते हैं।

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

लेखक के बारे में



माइकल बोल्टन संदर्भ-उन्मुख परीक्षण के स्कूल के सबसे सक्रिय इंजील में से एक है। उन्हें परीक्षण में 20 से अधिक वर्षों का अनुभव है। माइकल नियमित रूप से सम्मेलनों में बोलते हैं, प्रशिक्षण और सेमिनार आयोजित करते हैं, 2005 के बाद से वह बेहतर सॉफ्टवेयर परीक्षण के क्षेत्र में सबसे लोकप्रिय पत्रिकाओं में से एक के एक नियमित स्तंभकार हैं और www.developsense.com/blog.shtml परीक्षण के बारे में एक अद्भुत ब्लॉग है



17-18 नवंबर को, माइकल बोल्टन, जेम्स बाक के साथ संयुक्त रूप से विकसित, सेंट पीटर्सबर्ग में दो दिवसीय प्रशिक्षण सत्र "रैपिड सॉफ्टवेयर टेस्टिंग" का आयोजन करेगा। यहाँ विवरण: habrahabr.ru/blogs/testing/105133