एक टीम ने कभी बोर्डों को “कार्यात्मक परीक्षण पास” स्टाम्प के साथ भेजा क्योंकि बूटलोडर ने एक मैत्रीपूर्ण UART बैनर प्रिंट किया। स्ट्रिंग मेल खाती थी, फिक्स्चर हरा जल उठा, और शेड्यूल कम भयावह दिख रहा था। फिर जल्दी यूनिट्स रैंडम रीसेट के साथ वापस आने लगे—पहले कुछ हजार में लगभग 6% प्रारंभिक जीवन की विफलताएँ—ठीक तभी जब उत्पाद को विश्वसनीयता की आवश्यकता थी। बेंच पर, बोर्ड ठीक लग रहे थे जब तक कि असली गतिविधि नहीं हुई: एक BLE ट्रांसमिट बर्स्ट ने पावर सिस्टम को खींचा और 1.8 V रेल सैग स्पष्ट रूप से एक स्कोप ट्रेस पर दिखाई दी। मूल कारण रहस्यमय फर्मवेयर व्यवहार नहीं था। यह एक असेंबली वास्तविकता थी: एक प्रतिस्थापित इंडक्टर जिसकी टॉप-मार्क समान थी लेकिन संतृप्ति व्यवहार अलग था, साथ ही एक परीक्षण जिसने कभी भी रेल को तनाव नहीं दिया।
वह बचाव केवल एक तकनीकी चूक नहीं है; यह एक सामाजिक विफलता है जो तकनीकी वेशभूषा पहनता है। एक बार रिपोर्ट कहती है “कार्यात्मक पास,” अन्य लोग सुनते हैं “विशेषताएँ मान्य हैं,” और संगठन झूठे मानचित्र के साथ शिप निर्णय लेने लगते हैं।
कार्यात्मक का अर्थ “यह कुछ प्रिंट करता है” नहीं है।
स्कोप फर्स्ट: एक परीक्षण जो दुर्घटनावश झूठ बोलता है, फिर भी झूठ ही रहता है
जब फर्मवेयर देर से या अस्थिर होता है, तो प्रारंभिक परीक्षणों को वैसे ही व्यवहार करना चाहिए जैसे वे हैं: असेंबली दोष डिटेक्टर और हार्डवेयर बेसलाइन। उन्हें “कार्यात्मक” कहने का मतलब है कि टीमें अनजाने में ऐसा व्यवहार प्रमाणित कर देती हैं जिसे उन्होंने कभी अभ्यास नहीं किया।
यहाँ “कार्यात्मक परीक्षण” लेबल जाल है। कोई कहता है, “हमें फर्मवेयर के बिना एक कार्यात्मक परीक्षण चाहिए,” और आमतौर पर उनका मतलब होता है “हमें लाइन को चलते रहने का तरीका चाहिए बिना मैन्युफैक्चरिंग को फर्मवेयर लैब में बदले।” ये अलग लक्ष्य हैं। पहली वाक्यांश एक ढीला पास/फेल स्टाम्प आमंत्रित करता है। दूसरी एक स्कोप्ड परीक्षण को आमंत्रित करता है जिसमें स्पष्ट दावे और स्पष्ट गैर-दावे होते हैं, जो बिल्ड समीक्षाओं में तर्कों को लूप में आने से रोकता है। यह नेतृत्व से पास दरें पूछने पर डैशबोर्ड को ईमानदार भी रखता है और कोई स्वचालन को गुणवत्ता के साथ समानता करने की कोशिश करता है।
स्कोप ड्रिफ्ट को रोकने के लिए, हर प्रारंभिक परीक्षण योजना को लिखित में दो प्रश्नों का उत्तर देना अनिवार्य करें: यह कौन से दोष पकड़ता है, और यह कौन से उत्पाद व्यवहारों को प्रमाणित करता है। नहीं कुछ टीमें इसे DVT से PVT हैंडऑफ़ के दौरान दो-कॉलम साइनऑफ़ आर्टिफैक्ट के रूप में औपचारिक बनाती हैं, क्योंकि स्मृति शेड्यूल दबाव को सहन नहीं करती।
| श्रेणी | यह परीक्षण दावा कर सकता है | यह परीक्षण इसे दावा नहीं करना चाहिए |
|---|---|---|
| प्रारंभिक असेंबली स्क्रीनिंग | परिभाषित मापदंडों (रेल/क्लॉक/रीसेट/सततता/एक या दो एनालॉग सच्चाइयों) के साथ असेंबली दोषों का पता लगाता है | ग्राहक-दृश्य विशेषताएँ, विभिन्न परिस्थितियों में प्रदर्शन, सुरक्षा/अनुपालन, या व्यापक अर्थ में “काम करता है” को प्रमाणित करता है |
| बाद में फर्मवेयर-सहायता प्राप्त | एक संस्करणित, पुनरुत्पादनीय परीक्षण छवि और आवश्यकताओं के ट्रेस के साथ जुड़े विशिष्ट व्यवहारों को मान्य करता है | सामग्री को सक्षम फीचर फ़्लैग के बाहर या परीक्षण स्थितियों के बाहर कवर करने का संकेत देता है |
एक पेशेवर दर्शक को यहाँ JTAG, SWD, UART, I2C, या SPI की परिभाषा की आवश्यकता नहीं है। उपयोगी कार्य यह तय करना है कि आज क्या मापा जा सकता है, और उन मापों को कैसे नामित किया जाए और आगे ले जाया जाए ताकि कोई भी ग्रीन लाइट का हथियार न बना सके।
मापन-प्रथम बेसलाइन: रेलें, फिर घड़ियां/रीसेट्स, फिर एक एनालॉग सच्चाई
बेसलाइन का पहला प्राथमिकता पावर रेल है, क्योंकि यदि रेल गलत हैं, तो हर अन्य लक्षण झूठा है। इसका अर्थ है कि “यह बूट करता है इसलिए पावर ठीक है” से अधिक मापना। इसका अर्थ है रेल के नाममात्र वोल्टेज, सक्षम करने और रीसेट के सापेक्ष अनुक्रमण, रRipple/शोर ज्ञात बैंडविड्थ और उचित प्रोब तकनीक के साथ, और एक जानबूझकर तनाव जो सबसे खराब स्थिति ट्रांजिएंट के करीब हो। एक Tektronix MDO3000 श्रृंखला का स्कोप और एक Bench सप्लाई जैसे कि Keysight E36313A इनमें से बहुत कुछ बिना समारोह के कर सकते हैं, और एक कैलिब्रेटेड DMM जैसे कि Fluke 87V जल्दी से बोरिंग झूठ पकड़ लेता है।
“क्वार्टर का खर्चा वाला पास स्टाम्प” कहानी ट्रांजिएंट लोड प्रतिक्रिया को गैर-वैकल्पिक के रूप में मानने का अच्छा कारण है। एक UART बैनर तुलना एक सीमा रेखा पर पास कर सकती है क्योंकि बूट एक कम तनाव वाला घटना है, जो रेडियो, मोटर, या सेंसर द्वारा वर्तमान खींचने की तुलना में। 10 सेकंड का स्क्रिप्टेड लोड स्टेप, या कोई भी दोहराने योग्य कदम जो एक वास्तविक करंट ट्रांजिएंट के करीब हो, एक सस्ता तरीका है कि बदली गई इंडक्टर्स, गलत मान वाले कैपेसिटर, या एक रेगुलेटर जो मुश्किल से स्थिर है, को बाहर निकाला जाए। बिना उस तनाव के, परीक्षण केवल यह जांचता है कि बोर्ड शांत है, न कि यह स्वस्थ है।
बेसलाइन की पहली प्राथमिकता पावर रेल है, क्योंकि यदि रेल गलत हैं, तो हर अन्य लक्षण झूठा है। इसका अर्थ है कि “यह बूट करता है इसलिए पावर ठीक है” से अधिक मापना। इसका अर्थ है रेल के नाममात्र वोल्टेज, सक्षम करने और रीसेट के सापेक्ष अनुक्रमण, रRipple/शोर ज्ञात बैंडविड्थ और उचित प्रोब तकनीक के साथ, और एक जानबूझकर तनाव जो सबसे खराब स्थिति ट्रांजिएंट के करीब हो। एक Tektronix MDO3000 श्रृंखला का स्कोप और एक Bench सप्लाई जैसे कि Keysight E36313A इनमें से बहुत कुछ बिना समारोह के कर सकते हैं, और एक कैलिब्रेटेड DMM जैसे कि Fluke 87V जल्दी से बोरिंग झूठ पकड़ लेता है।
“पास स्टाम्प जो एक चौथाई का खर्चा करता है” कहानी ट्रांजिएंट लोड प्रतिक्रिया को गैर-वैकल्पिक के रूप में मानने का अच्छा कारण है। एक UART बैनर तुलना एक सीमा रेखा पर पास कर सकती है क्योंकि बूट एक कम तनाव वाला घटना है, जो रेडियो, मोटर, या सेंसर द्वारा वर्तमान खींचने की तुलना में। 10 सेकंड का स्क्रिप्टेड लोड स्टेप, या कोई भी दोहराने योग्य कदम जो एक वास्तविक करंट ट्रांजिएंट के करीब हो, एक सस्ता तरीका है कि बदली गई इंडक्टर्स, गलत मान वाले कैपेसिटर, या एक रेगुलेटर जो मुश्किल से स्थिर है, को बाहर निकाला जाए। बिना उस तनाव के, परीक्षण केवल यह जांचता है कि बोर्ड शांत है, न कि यह स्वस्थ है।
इस बिंदु पर I2C स्कैन जाल आमतौर पर दिखाई देता है: “हमारा I2C स्कैन उपकरण दिखाता है कि डिवाइस अच्छा है।” एक गणना अभी भी गलत पुल-अप मान, एक सीमा रेखा को खिलाने वाला एक सीमांत रेल, वाइब्रेशन के तहत खुलने वाला एक ठंडा जॉइंट, या एक क्लॉक जो धीरे-धीरे शुरू होता है ताकि टाइमिंग को गड़बड़ कर सके, के साथ पास हो सकता है। यह तब भी पास हो सकता है जब एनालॉग संदर्भ ग्रेड से बाहर हो, क्योंकि डिजिटल संचार सही रहता है जब तक कि माप क्षेत्र में नहीं खिसकते। एक I2C स्कैन एक उपयोगी स्मोक चेक है, लेकिन यह स्थिर पावर और टाइमिंग आधारशिला का सबूत नहीं है।
एक बेसलाइन जो फर्मवेयर परिवर्तन के साथ जीवित रहने के लिए है, कम से कम एक ठोस सीमा उदाहरण की आवश्यकता है, क्योंकि अस्पष्टता ही “माप” को वाइब्स में बदल देती है। एक उदाहरण, न कि एक सार्वभौमिक नियम: 1.8 V रेल को ±5% स्थिर अवस्था के भीतर रहना पड़ सकता है, और एक परिभाषित लोड स्टेप (जैसे कि अपेक्षित रेडियो बर्स्ट का अनुमान लगाना) के तहत, ड्रॉप <100 mV तक सीमित हो सकता है और रिकवरी एक छोटे समय में हो सकती है। वह समय सीमा उप-मिलिसेकंड या कई मिलिसेकंड हो सकती है, निर्भर करता है रेगुलेटर, लोड प्रोफ़ाइल, और डाउनस्ट्रीम आईसी क्या सहन कर सकते हैं। यहाँ अनिश्चितता सीमा का महत्व है: रRipple और ड्रॉप थ्रेशोल्ड विशिष्ट रेगुलेटर अनुकूली, प्रोब बैंडविड्थ, प्रोब का भौतिक लूप क्षेत्र, और वास्तविक ट्रांजिएंट आकार पर निर्भर करते हैं। थ्रेशोल्ड को ईमानदार बनाने का तरीका इसे एक सुनहरे यूनिट पर मान्य करना और फिर एक ज्ञात-खराब यूनिट (या एक प्रेरित दोष) पर परीक्षण करना है ताकि यह सुनिश्चित किया जा सके कि माप “स्वस्थ” और “RMA कतार बनाने के करीब” के बीच भेद कर सकता है।
बेसलाइन में मिश्रित-सिग्नल बोर्डों पर एक छोटी एनालॉग सैनीटी सेट भी शामिल होना चाहिए, क्योंकि एनालॉग को छोड़ना टीमों को “मेरे बेंच पर काम करता है” आपदाओं को भेजने का तरीका है। क्लासिक विफलता सूक्ष्म और महंगी होती है: डिजिटल इंटरफ़ेस परफेक्ट है, मान कमरे के तापमान पर उचित दिखते हैं, और फिर क्षेत्र पढ़ाई तापमान या आपूर्ति परिवर्तन के साथ भटक जाती है। एक सेंसर प्रोग्राम में, कारण एक कमी-प्रेरित प्रतिस्थापन था: एक 2.048 V संदर्भ गलत सहिष्णुता ग्रेड के साथ भरा हुआ था, भाग संख्या में एक अक्षर का अंतर था। फर्मवेयर ने ड्रिफ्ट को मुआवजा तालिकाओं के साथ कागज़ पर लाने की कोशिश की जब तक किसी ने संदर्भ पिन को मापा और ADC कोड वितरण को एक निश्चित इनपुट के साथ नहीं देखा। समाधान BOM नियंत्रण और प्रारंभिक परीक्षण में एकल संदर्भ माप था, जिसमें प्रतिस्थापन पकड़ने के लिए पर्याप्त कड़ा सीमा थी। कैलिब्रेशन स्वैप किए गए घटक परिवार को ठीक नहीं कर सकता; यह केवल विफलता को सजाने का काम कर सकता है जब तक कि वह भाग न जाए।
घड़ियाँ और रीसेट उसी कारण से बेसलाइन स्थान के हकदार हैं जैसे रेलें हैं: यदि वे सीमांत हैं तो वे झूठ बनाते हैं। एक सरल आदत—रीसेट डीअसर्टेशन टाइमिंग और ऑस्सीलेटर स्टार्टअप को दर्जनों पावर साइकिलों में कैप्चर करना—“रैंडम हैंग” को एक पुनरुत्पादनीय प्रणाली में बदल देता है। यह क्रॉस-टाइम-ज़ोन टीमों को हर अस्थायी को स्लैक तर्क में बदलने से भी रोकता है कि रातभर में किसने क्या तोड़ा।
फिक्स्चर को दोष देने से पहले प्रमाणित करें (गोल्डन-फर्स्ट अनुशासन)
अस्थायी विफलताओं का अक्सर यांत्रिक मूल होता है, और एक उत्पादन फिक्स्चर एक यांत्रिक प्रणाली है जिसमें विद्युत पक्ष प्रभाव होते हैं। फिक्स्चर परिणामों को आधार सत्य मानना बिना यह साबित किए कि फिक्स्चर है, टीमों को दिन बर्बाद करने का कारण बनता है जो कभी मदद करने का मौका नहीं था।
एक नाखूनों का बिस्तर फिक्स्चर ने कभी-कभी बोर्डों को फेल करना शुरू कर दिया था जो पहले बेंच पर सफलतापूर्वक शुरू हो चुके थे। लक्षण असंगत थे, जिससे “फर्मवेयर अस्थिरता” एक आसान scapegoat बन गया। तेज़ कदम था कि ज्ञात-ठीक सोने का बोर्ड फिक्स्चर से चलाया जाए और संपर्क प्रतिरोध की तुलना पोगो पिनों के बीच की जाए। सोने का बोर्ड भी फेल हो गया। इससे तुरंत डिजाइन से दोष हटा कर परीक्षण अवसंरचना की ओर स्थानांतरित हो गया। दोषी कोई सूक्ष्म नहीं था: फिक्स्चर पर एक कनेक्टर हाउसिंग मानक से बाहर था, जिससे संरेखण बदल गया और दो पोगो पिनें मुश्किल से छू गईं। कनेक्टर को बदलें, और विफलता का पैटर्न गायब हो जाएगा। उसके बाद, एक फिक्स्चर सेल्फ-टेस्ट कदम अनिवार्य हो गया।
अधिकांश प्रारंभिक अराजकता को रोकने के लिए इस निर्णय वृक्ष का उपयोग करें:
- यदि सोने का यूनिट फिक्स्चर पर फेल हो जाता है: DUTs को छूना बंद करें। बोर्ड-स्तर डिबग से पहले पोगो पिन संपर्क प्रतिरोध, कनेक्टर संरेखण, उपकरण कैलिब्रेशन स्थिति, और फिक्स्चर वायरिंग की जांच करें।
- यदि सोने का यूनिट पास कर जाता है लेकिन DUT फेल हो जाता है: बोर्ड निदान के साथ बेसलाइन माप का उपयोग करके आगे बढ़ें। विफलता की तुलना करने के लिए सीरियल नंबर, बोर्ड संशोधन, फिक्स्चर आईडी, और परिवेशीय परिस्थितियों को लॉग करें, न कि स्मृति से पुनः उत्पन्न करें।
वाक्यांश “फिक्स्चर पर रैंडम विफलताएँ” को फिक्स्चर को साबित करने का अनुरोध माना जाना चाहिए, न कि अधिक फर्मवेयर लॉग का अनुरोध। यह एकल आदत देर रात क्रॉस-साइट डिबगिंग का स्वर बदल देती है क्योंकि यह खोज स्थान को तुरंत संकीर्ण कर देती है।
दोष-वर्ग कवरेज: एक छोटी दोष-मॉडल सीढ़ी “पूर्ण परीक्षण सूट” थिएटर को मात देती है
एक उत्पादक प्रारंभिक परीक्षण रणनीति सबसे लंबी चेकलिस्ट वाली नहीं है। यह वह है जो सबसे संभावित दोष वर्गों को सबसे सस्ते विश्वसनीय मापों के साथ पकड़ लेती है, जबकि विलंब को स्पष्ट बनाती है ताकि उन्हें हरे स्टाम्प में स्मगल न किया जा सके।
एक दोष-मॉडल सीढ़ी उन दोष वर्गों को सूचीबद्ध करके शुरू होती है जो वास्तव में अनुबंध निर्माण में दिखाई देते हैं: ओपन, शॉर्ट, गलत भाग, गलत अभिविन्यास, भाग की अनुपस्थिति, सोल्डर ब्रिज, और यांत्रिक असामंजस्य। फिर यह प्रत्येक वर्ग को एक पता लगाने के तरीके से मैप करता है जो स्थिर एप्लिकेशन फर्मवेयर की आवश्यकता नहीं है: AOI मोटे स्थान और पोलरिटी गलतियों के लिए, निरंतरता जांच जहां पहुंच है, प्रतिस्थापन और अनुपस्थित पासिव के लिए रेल हस्ताक्षर और लोड प्रतिक्रिया, और सीमा-स्कैन जहां श्रृंखलाएं और पहुंच वास्तविक हैं। सीढ़ी का मूल्य सैद्धांतिक कवरेज नहीं है, बल्कि यह कहने की क्षमता है, जोर से और लिखित में, “यह परीक्षण इन नेट्स पर ओपन/शॉर्ट को पकड़ता है, लेकिन यह फीचर X को मान्य नहीं करता।”
यह भी “अब उत्पादन परीक्षणों को पूरी तरह से स्वचालित करें” दबाव को संबोधित करता है। स्वचालन प्रगति नहीं है यदि यह शोर को स्वचालित करता है। फिक्स्चर की पुनरावृत्ति को साबित करना, अपरिवर्तनीयताओं को परिभाषित करना, और दोष वर्ग परीक्षण चुनना जो अगले सप्ताह भी वही अर्थ रखेंगे, प्रगति है। बाकी सब डैशबोर्ड थिएटर है।
विलंब को एक रक्षा रेखा की आवश्यकता है क्योंकि लोग “परीक्षण नहीं किया गया” को लापरवाही के साथ जोड़ते हैं। बेहतर फ्रेमिंग यह है कि विलंब जानबूझकर जोखिम निर्णय हैं: क्योंकि पहुंच गायब है, क्योंकि फर्मवेयर बहुत अस्थिर है, या क्योंकि दोष वर्ग वर्तमान अनुसूची और निर्माण संदर्भ की तुलना में दुर्लभ है। बिंदु यह है कि इन विलंबों को implied दावों में बदलने से रोकें।
बाउंड्री-स्कैन: जब हार्डवेयर इसकी अनुमति देता है, तब निर्धारक साक्ष्य
सीमा-स्कैन इस स्थिति में सबसे कम ग्लैमरस, उच्च-प्रभाव उपकरण है, क्योंकि यह एप्लिकेशन फर्मवेयर की आवश्यकता के बिना सूक्ष्म-पिच भागों पर ओपन और शॉर्ट के लिए निर्धारक कवरेज प्रदान कर सकता है। यह बहसों को भी समाप्त कर देता है। यदि श्रृंखला इंटरकनेक्ट परीक्षण चला सकती है और एक नेट ओपन दिखाता है, तो यह नहीं कि फर्मवेयर टाइमिंग ट्यूनिंग इसे ठीक करेगा, इस पर कोई बहस नहीं है।
एक मामले में जिसमें बस की विफलताएँ आवृत्त थीं, एक सस्ता लॉजिक एनालाइज़र ने बस को “अधिकांश ठीक” दिखाया, जिससे दोष फर्मवेयर टाइमिंग पर ही केंद्रित रहा। सीमा-स्कैन इंटरकनेक्ट परीक्षणों ने एक BGA पते के पिन पर एक खुला स्थान अलग किया—संभवतः एक ठंडा जॉइंट—बिना अधिक लॉग या कोड का इंतजार किए। इससे महंगे एक्स-रे पुनः कार्य लूप से बचा गया और पुनः कार्य को एक लक्षित कार्रवाई में बदला गया जिसमें मात्रात्मक सत्यापन था। एवरट और पेनांग में एक सीएम टीम के बीच समन्वय सरल हो गया क्योंकि सबूत निर्णायक थे।
वास्तविकता जांच महत्वपूर्ण है: सीमा-स्कैन तभी काम करता है जब पहुंच वास्तविक हो। चेन निरंतरता को डिज़ाइन में शामिल करना चाहिए, BSDL का उपयोग करने योग्य होना चाहिए, पुल-अप और स्ट्रैपिंग सही होनी चाहिए, और सुरक्षा सेटिंग्स “बाद में समस्याएँ” नहीं हैं—फ्यूज़्ड डिबग एक्सेस एक कठोर प्रतिबंध है। सामान्य इच्छुक अनुरोध है “क्या सीमा-स्कैन सब कुछ परीक्षण कर सकता है,” अक्सर “कोई परीक्षण पैड नहीं लेकिन फिर भी किया जा सकता है” के साथ जोड़ा जाता है। ईमानदार उत्तर यह है कि संभवता चेन पहुंच, BSDL गुणवत्ता, और लॉक-डाउन स्थिति पर निर्भर करती है; इन तथ्यों के बिना कवरेज प्रतिशत का वादा करना परीक्षण योजनाओं को कल्पना में बदल देता है।
एक व्यावहारिक समझौता जो टीमों को घूमने से रोकता है, वह है एक बोर्ड पर सीमा-स्कैन का पायलट करना जिसमें इच्छित फिक्स्चर पहुंच और टूलचेन हो (Corelis/Asset/Keysight-क्लास सूट फैक्ट्रियों में सामान्य हैं)। यदि यह काम करता है, तो यह हर भविष्य की विफलता विश्लेषण में दिनों की बहस को बदल सकता है। यदि नहीं, तो योजना तुरंत रीलों, घड़ियों, रीसेट और एक छोटे एनालॉग सिग्नेचर सेट पर वापस मुड़नी चाहिए—ऐसी चीजें जो उपलब्ध कनेक्टर और पैड के माध्यम से अभी भी मापी जा सकती हैं।
जो हिट रहता है: अभी न्यूनतम, बाद में गहरा
प्रारंभिक परीक्षण अक्सर मर जाते हैं क्योंकि वे भंगुर, अभिलेखित नहीं होते, या एक व्यक्ति की टूल प्राथमिकताओं से बंधे होते हैं। एक न्यूनतम हार्नेस जो जीवित रहता है, वह डिज़ाइन में उबाऊ है: एक रनर, एक बोर्ड-विशिष्ट पिन मानचित्र, एक थ्रेशोल्ड सेट, और लॉगिंग जो पुनः चलाने की तुलना करने योग्य बनाती है।
एक पैटर्न जो कई फर्मवेयर पुनर्लेखनों के माध्यम से टिक गया है, वह है तीन-स्तरीय हार्नेस: प्रेरणा/माप अवसंरचना (इंस्ट्रुमेंट ड्राइवर जैसे pyvisa या DAQ लेयर के माध्यम से), एक बोर्ड मानचित्र (अक्सर YAML पिन मानचित्र पर्याप्त होता है), और परीक्षण मामले जो निर्णायक रहते हैं। सीरियल नंबर द्वारा की गई CSV में लॉगिंग बहुत पहले हो सकती है, जब तक मेटाडेटा अनुशासित हो: बोर्ड संशोधन, फिक्स्चर आईडी, परिवेशीय स्थितियां, और जब फर्मवेयर शामिल हो तो परीक्षण छवि संस्करण। भाषा का चयन (Python बनाम LabVIEW बनाम विक्रेता पर्यावरण) कम महत्वपूर्ण है बनाम मॉड्यूलर सीमा। एक मोनोलिथिक LabVIEW VI जिसे केवल एक व्यक्ति संपादित कर सकता है, वह एक स्टाफिंग जोखिम बन जाता है बजाय एक परीक्षण रणनीति के।
एक सूक्ष्म अनिश्चितता भी है जो हार्नेस बातचीत में शामिल है: वर्तमान-प्रोफ़ाइल हस्ताक्षर। जब फर्मवेयर स्थितियां स्थिर होती हैं, तो वे शक्तिशाली होते हैं। जब फर्मवेयर रोजाना बदलता है, तो वर्तमान सीमा को प्रवृत्ति/असामान्यता का पता लगाने के रूप में माना जाना चाहिए, न कि कठोर पास/फेल, जब तक कि टीम नियंत्रित विशेषता झंडों और पुनरुत्पादन के साथ एक संस्करणित परीक्षण छवि को लॉक करने में सक्षम न हो।
हस्तांतरण बिंदु सीधा है: प्रारंभिक परीक्षण अपने दावों का विस्तार कर सकते हैं जैसे ही फर्मवेयर परिपक्व होता है, लेकिन केवल यदि हार्नेस मापन पर भरोसा बनाए रखता है और नामकरण ईमानदार रहता है। प्रारंभिक स्क्रीनिंग असेंबली से बच निकलने को कम करती है। यह उत्पाद व्यवहार का प्रमाणन नहीं करता।
