क्या एक और बुरे व्यवहार की गुणवत्ता आश्वासन (क्यूए) के लिए पूरी तरह से डुप्लिकेट प्रणाली बना रहा है?

Question

काम में हमारे पास काफी जटिल प्रणाली है। इस प्रणाली को, System_A कहते हैं। हमारी QA टीम ने एक और सिस्टम बनाया है, System_A का परीक्षण करने के लिए इस सिस्टम को System_B कहा जाता है।

System_B का उपयोग करने का तरीका इस प्रकार है। हम इनपुट उत्पन्न करते हैं (System_B ही का उपयोग करके), IN, ऐसे इनपुट को System_B के माध्यम से वापस प्रोसेस करते हैं और आउटपुट, O_B उत्पन्न करते हैं। तो प्रक्रिया इस प्रकार है:

System_B(IN) -> O_B।

हम तब System_A के लिए स्वयं के आउटपुट उत्पन्न करने के लिए O_A करते हैं:

System_A(IN) -> O_A।

किसी भी समय, यह माना जाता है कि O_B अपेक्षित आउटपुट है, और O_A मनाया / वास्तविक आउटपुट है। आरोप लगाया गया है कि O_B "गोल्ड" स्रोत (सच्चाई) है। हालाँकि, हम समस्याओं के संयोजन में भाग चुके हैं।

• O_A गलत है, O_B सही है
• O_A सही है, O_B सही है
• O_A गलत है, O_B गलत है
• O_A सही है, O_B गलत है

कौन निर्धारित करता है कि O_B हमेशा सही माना जाता है (या क्या अपेक्षित है) क्या सही है? खैर, यह पता चला है कि मानव निरीक्षण और विश्लेषण के साथ O_B कभी-कभी (या अक्सर) गलत है। इस प्रक्रिया का उपयोग करके चीजें QA से गुजरेंगी, और वास्तविक उपयोगकर्ता शिकायत करेंगे, और हम यह पता लगाने के लिए वापस जाते हैं कि O_B आखिर गलत था।

सवाल यह है कि क्या वास्तविक प्रणाली का परीक्षण करने के लिए "परीक्षण प्रणाली" बनाना एक बुरा व्यवहार है?

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

इस मुद्दे पर किसी भी मार्गदर्शन की सराहना की है।

Comments

आप सिस्टम C को भूल गए : वह जो यह तय करता है कि कौन सही है, यदि A और B असहमत हैं।

— रॉबर्ट हार्वे

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

— रॉबर्ट हार्वे

आप एक बात जानते हैं, जो यह है कि जब भी System_A और System_B एक दूसरे से असहमत होते हैं, उनमें से एक के पास बग होता है। जो आपको दोनों सिस्टम में कुछ बग ढूंढने में मदद करेगा। यदि System_A एकमात्र "महत्वपूर्ण" है, तो इससे आपको System_A में कुछ बग ढूंढने में मदद मिली, बस उन सभी में नहीं। यह औपचारिक सत्यापन के पीछे एक ही विचार की तरह है।

— user253751

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

— kdgregory

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

— kdgregory

Answer 1

• O_A गलत है, O_B सही है

A को ठीक करें

• O_A सही है, O_B गलत है

फिक्स बी

• O_A सही है, O_B सही है

उम्मीद है, वे भी सहमत हैं।

• O_A गलत है, O_B गलत है

उम्मीद है, वे सहमत नहीं हैं ताकि आप इसके बारे में कुछ करने के लिए पता चल जाएगा।

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

यह अलग-अलग कीड़े होने के बाधाओं को भड़काने के लिए अलग-अलग लोग होने चाहिए। मैं सिस्टम A से मुकाबला करके B को सिस्टम B बनाने की सलाह नहीं देता। यह सब आपको एक रीग्रेशन टेस्ट देता है। आप नई चीज़ों की तुलना करने के लिए O_A की पुरानी प्रतियों को सहेजकर बस एक ही चीज़ प्राप्त कर सकते हैं।

सवाल यह है कि क्या वास्तविक प्रणाली का परीक्षण करने के लिए "परीक्षण प्रणाली" बनाना एक बुरा व्यवहार है?

यदि यह है, तो सभी परीक्षण खराब है।

• फिसलन ढलान के बारे में क्या? फिर, क्या हम यह तर्क नहीं दे सकते कि हमें "परीक्षण प्रणाली" का परीक्षण करने के लिए एक और प्रणाली की आवश्यकता है?

हाँ, हम यह तर्क दे सकते हैं। हम इसे 3rd सिस्टम, system_A कहेंगे। : पी

• लागत निश्चित रूप से निषेधात्मक है, क्योंकि अब डेवलपर्स को कम से कम 2 कोड बेस सीखने की जरूरत है, शायद System_B की तुलना में System_B की जटिलता बड़ी है। हम संगठन के लिए System_B के आसपास कितना अच्छा या बुरा है, इसकी मात्रा कैसे तय करेंगे?

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

• System_B बनाने के मूल "सम्मोहक" कारणों में से एक परीक्षण "स्वचालित" करना था। अब हमें बहुत गर्व है कि हम पूरी तरह से स्वचालित हैं (क्योंकि System_B इनपुट उत्पन्न करने के लिए इनपुट का उत्पादन करने के लिए खुद को उपयोग करने की प्रक्रिया भी उत्पन्न करता है)। लेकिन मुझे लगता है कि हमने अधिक नुकसान पहुंचाया है और अधिक जटिलता का परिचय दिया है, एक बिना रास्ते के। क्या QA का काम पूरी तरह से स्वचालित है? क्या यह कारण एक समानांतर व्यवस्था बनाने के लिए औचित्य के लिए पर्याप्त है?

System_B की जटिलता System_A से अद्भुत रूप से अलग है। System_A में सुविधाएँ जोड़ना कोई कठिन नहीं है क्योंकि System_B मौजूद है। यह आसान है क्योंकि System_B उन्हें तेजी से जाने का विश्वास देता है।

• मेरी असली चिंता यह है, भले ही हम सभी जानते हैं कि System_B गलत है (अक्सर)। यदि System_B इनपुट को संसाधित करने में बहुत अच्छा है और इसका आउटपुट स्वर्ण स्रोत है, तो System_A को System_B से क्यों न बदला जाए? उस पर, कोई भी कार्य संतोषजनक प्रतिक्रिया देने में सक्षम नहीं है।

क्या यह एक टाइपो है? System_B काफी गलत है, इसलिए यह स्वर्ण मानक है जिसका उपयोग आप System_A को बदलने के लिए करना चाहते हैं?

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

Answer 2

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

यह दोगुना हो जाता है इसलिए यदि आपका सिस्टम महत्वपूर्ण है और 24/7 उपलब्ध होना आवश्यक है। आप तब QA सिस्टम नहीं होने के लिए विलासिता को प्रभावित नहीं कर सकते, क्योंकि आपको उत्पादन प्रणाली पर डाउनटाइम को बिल्कुल कम करना चाहिए। और अगर यह 24/7 प्रणाली है, तो उत्पादन प्रणाली की सटीक प्रतिकृति एक बहुत, बहुत मजबूत सिफारिश है।

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

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

Answer 3

जब भी आप किसी सिस्टम का परीक्षण करते हैं, तो आपको यह जानना होगा कि आपका अपेक्षित परिणाम क्या है।

एक प्रणाली के साथ समस्या यह अपेक्षित परिणाम उत्पन्न करती है, जाहिर है 'मैं उस प्रणाली का परीक्षण कैसे करूं'

यहां तक ​​कि आम तौर पर लोगों को अपेक्षित परिणामों के सेट उत्पन्न करने के लिए उदाहरण के लिए स्प्रेडशीट का उपयोग देखने के लिए नहीं।

दिन के अंत में हालांकि आपको सिस्टम की आवश्यकताओं की व्याख्या करने के लिए वास्तव में मानव की आवश्यकता होती है और मैन्युअल रूप से अपेक्षित परिणाम उत्पन्न करते हैं। यदि आपके पास एक सिस्टम है और केवल अंतरों की जांच करें तो आप अपने परीक्षण को छोड़ रहे हैं।