2.4 टेस्टिंग रणनीति

अवलोकन और प्रेरणा

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

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

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

मुख्य सिद्धांत

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

सिफारिशें

टेस्ट पिरामिड को डिफ़ॉल्ट के रूप में उपयोग करें, और इसकी आलोचनाओं को जानें

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

जहाँ मदद करें वहाँ TDD, BDD, और स्पेसिफ़िकेशन-चालित विकास अपनाएँ

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

उच्च-मूल्य कोड के लिए उन्नत तकनीकों को नियोजित करें

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

परीक्षण डेटा प्रबंधित करें और सिंथेटिक डेटा का उपयोग करें

नियंत्रित, पृथक परीक्षण डेटा के साथ परीक्षणों को नियतात्मक बनाएँ, और साझा परिवर्तनशील फ़िक्सचर से बचें जो परीक्षणों को एक साथ जोड़ते हैं। ऐसा सिंथेटिक डेटा उत्पन्न करें जो वास्तविक व्यक्तिगत जानकारी को उजागर किए बिना उत्पादन विशेषताओं को दर्शाता है, जो वहाँ आवश्यक है जहाँ गोपनीयता नियम परीक्षण वातावरण में उत्पादन डेटा का उपयोग करने से मना करते हैं। फ़ैक्ट्री या बिल्डर प्रदान करें ताकि हर परीक्षण ठीक वही डेटा बना सके जिसकी उसे आवश्यकता है।

अस्थिर परीक्षणों को दोष के रूप में मानें

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

कवरेज को संकेत के रूप में उपयोग करें, और गैर-कार्यात्मक टेस्टिंग जोड़ें

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

व्यापार-संतुलन: फायदे और नुकसान

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

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

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

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

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

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

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

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

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

क्षेत्रीय दृष्टिकोण

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

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

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

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

उदाहरण

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

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

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

बिज़नेस केस: प्रेरणाएँ, ROI, और TCO

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

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

एंटी-पैटर्न और नुकसान

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

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

• स्तर 1, आरंभ: टेस्टिंग मैनुअल और प्रतिक्रियात्मक है; स्वचालित कवरेज न्यूनतम है; रिग्रेशन बार-बार होते हैं और देर से पकड़े जाते हैं, अक्सर सूट की बजाय उपयोगकर्ताओं द्वारा।
• स्तर 2, विकसित: स्वचालित यूनिट और कुछ इंटीग्रेशन परीक्षण मौजूद हैं, लेकिन सूट धीमा या अस्थिर है, विश्वास कम है, और अभ्यास एक टीम से दूसरी टीम में व्यापक रूप से भिन्न होता है।
• स्तर 3, मानकीकृत: एक संतुलित, तेज़, विश्वसनीय सूट हर परिवर्तन को गेट करता है; एक दस्तावेज़ीकृत पिरामिड डिफ़ॉल्ट, एक अस्थिर-परीक्षण नीति, और गैर-कार्यात्मक टेस्टिंग (एक्सेसिबिलिटी, प्रदर्शन, सुरक्षा) टीमों में लगातार लागू होती है।
• स्तर 4, प्रबंधित: सूट स्वास्थ्य को बेसलाइन के विरुद्ध मापा और नियंत्रित किया जाता है; अस्थिरता दर, CI वॉल-क्लॉक समय, उच्च-मूल्य मॉड्यूल पर म्यूटेशन स्कोर, और बच निकले-दोष दर को ट्रैक और समीक्षित किया जाता है; कवरेज कई संकेतों में से एक है, और गेट राय की बजाय सबूत पर ट्रिगर होते हैं।
• स्तर 5, ऑर्केस्ट्रेट: उन्नत तकनीकें (प्रॉपर्टी-आधारित, म्यूटेशन, फ़ज़) उच्च-मूल्य कोड को लक्षित करती हैं; टेस्टिंग को परिनियोजन आवृत्ति, परिवर्तन-विफलता दर, और पुनर्प्राप्ति के औसत समय जैसे डिलीवरी मेट्रिक्स के साथ एकीकृत किया जाता है; संगठन लगातार सूट को अपने आर्किटेक्चर और जोखिम के अनुसार फिर से आकार देता है, अनावश्यक परीक्षणों को रिटायर करता है और वहाँ निवेश करता है जहाँ सबूत दिखाते हैं कि दोष अभी भी बच निकलते हैं।

चर्चा के लिए विचार

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

मुख्य निष्कर्ष

• बदलाव का विश्वास पाने के लिए परीक्षण करें; गति और लागत की प्रति इकाई विश्वास को अनुकूलित करें।
• पिरामिड को डिफ़ॉल्ट के रूप में उपयोग करें लेकिन टेस्टिंग को अपने आर्किटेक्चर के अनुसार आकार दें।
• अस्थिर परीक्षणों को दोष के रूप में और कवरेज को एक संकेत के रूप में मानें, कोई लक्ष्य नहीं।
• जहाँ मूल्य लागत को उचित ठहराए वहाँ उन्नत तकनीकें लागू करें।
• रणनीति में एक्सेसिबिलिटी, प्रदर्शन, और सुरक्षा टेस्टिंग शामिल करें, और गोपनीयता की रक्षा के लिए सिंथेटिक डेटा का उपयोग करें।

संदर्भ और आगे पठन

• Kent Beck, Test-Driven Development: By Example
• Lisa Crispin and Janet Gregory, Agile Testing: A Practical Guide for Testers and Agile Teams
• Gerard Meszaros, xUnit Test Patterns: Refactoring Test Code
• Michael Feathers, Working Effectively with Legacy Code
• Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: The Science of Lean Software and DevOps
• Martin Fowler, articles on the Test Pyramid and test-related patterns