मैं एक अर्ध-आकार की कंपनी (150-कर्मचारियों, ~ 10 आकार की इंजीनियरिंग टीम) में काम करता हूं, और मेरी अधिकांश परियोजनाओं में अर्ध-स्वचालित परीक्षण अनुप्रयोगों के उद्देश्य के लिए लैब उपकरण (ऑसिलोस्कोप, ऑप्टिकल स्पेक्ट्रम विश्लेषक, आदि) के साथ इंटरफेसिंग शामिल है। मैंने कुछ अलग परिदृश्यों में भाग लिया है जहाँ मैं कुशलता से नए कोड का निवारण या परीक्षण करने में असमर्थ हूँ क्योंकि मेरे पास अब हार्डवेयर सेटअप उपलब्ध नहीं था या कभी नहीं था।
उदाहरण 1: एक सेटअप जहां 10-20 "बर्न-इन" प्रक्रियाओं को स्वतंत्र रूप से एक बेंच टॉप टाइप सेंसर का उपयोग करके चलाया जाता है - मैं परीक्षण के लिए इस तरह के एक सेंसर को प्राप्त करने में सक्षम था और कभी-कभी इंटरफेसिंग के सभी पहलुओं के अनुकरण के लिए एक सेकंड की चोरी कर सकता था। कई डिवाइस (खोज, कनेक्ट, स्ट्रीमिंग, आदि)।
आखिरकार एक बग दिखा (और अंत में डिवाइस फर्मवेयर और ड्राइवरों में होने के नाते) समाप्त हो गया, जो केवल एक इकाई के साथ सटीक रूप से पुन: पेश करना बहुत मुश्किल था, लेकिन "शो स्टॉपर" के स्तर के पास मारा गया जब इनमें से 10-20 उपकरण एक साथ उपयोग में थे। यह अभी भी अनसुलझा है और जारी है।
उदाहरण 2: एक परीक्षण के लिए एक महंगे ऑप्टिकल स्पेक्ट्रम विश्लेषक की आवश्यकता होती है। डिवाइस बहुत पुरानी है, निर्माता के अनुसार विरासत जो एक बड़ी कंपनी द्वारा अधिग्रहित की गई थी और मूल रूप से भंग कर दी गई थी, और इसका एकमात्र दस्तावेज एक लंबा घुमावदार (और अनइंफॉर्मेटिव) दस्तावेज था जो खराब अनुवादित लगता है। प्रारंभिक विकास के दौरान मैं अपने डेस्क पर डिवाइस को रखने में सक्षम था, लेकिन अब इसके 24/7 बहु-सप्ताह के परीक्षणों के दौरान शारीरिक रूप से और अनुसूची में बंधा हुआ है।
जब बग डिवाइस से संबंधित या असंबंधित दिखाई देते हैं, तो मुझे अक्सर एप्लिकेशन को बाहरी परीक्षण कोड की परेशानी से गुजरना पड़ता है और इसे फिटिंग करने या कोड लिखने के लिए आँख बंद करके और बीच में कुछ परीक्षण समय में निचोड़ने का प्रयास करना पड़ता है। कार्यक्रम तर्क के लिए OSA और बाकी परीक्षण हार्डवेयर की आवश्यकता होती है।
मुझे लगता है कि मेरा सवाल यह है कि मुझे यह कैसे करना चाहिए? मैं संभवतः डिवाइस सिमुलेटरों को विकसित करने में समय बिता सकता हूं, लेकिन यह अनुमान लगाते हुए कि विकास के अनुमान में यह अधिक से अधिक गुब्बारा होगा, शायद अधिक सराहना करेगा। हो सकता है कि यह सभी मुद्दों को सटीक रूप से पुन: पेश न करे, और यहां समान उपकरण का उपयोग दो बार देखने के लिए बहुत दुर्लभ है। मैं यूनिट परीक्षण में बेहतर हो सकता है ... आदि ... मैं भी इस मुद्दे के बारे में जोर से बोल सकता हूं और दूसरों को समझ सकता हूं कि अस्थायी देरी की आवश्यकता होगी, अनुसंधान और विकास के लिए सिरदर्द से ज्यादा नहीं, लेकिन आमतौर पर एक मजाक के रूप में माना जाता है जब निर्माण के लिए तैयार है।