डेवलपर परीक्षण बनाम क्यूए टीम परीक्षण - काम का सही विभाजन क्या है?

Question

अधिक डेवलपर परीक्षण की वकालत करने की कोशिश करते समय, मुझे तर्क मिलता है कि "क्या वह क्यूए का काम नहीं है?" बहुत उपयोग किया जाता है। मेरे दिमाग में, क्यूए टीम को सभी परीक्षण जिम्मेदारियों को देने का अर्थ नहीं है, लेकिन साथ ही स्पॉल्स्की और अन्य कहते हैं कि आपको $ 100/घंटा डेवलपर्स का उपयोग नहीं करना चाहिए ताकि कुछ $ 30/घंटा परीक्षक कुछ कर सके । एक समर्पित क्यूए टीम के साथ एक कंपनी में दूसरों के अनुभव क्या हैं? काम का विभाजन कहाँ खींचा जाना चाहिए?

स्पष्टीकरण: मेरा मतलब क्यूए सत्यापन और सत्यापन टीम के रूप में था। देवताओं को सत्यापन (ग्राहक केंद्रित परीक्षण) नहीं करना चाहिए, लेकिन सत्यापन (कार्यात्मक परीक्षण) विभाजन बिंदु कहां है?

Answer 1

यह "ब्लैक बॉक्स" परीक्षण (जहां आप जानते हैं कि कोड क्या करना है, लेकिन यह कैसे काम करता है) के बीच अंतर है, और "व्हाइट बॉक्स" परीक्षण (जहां यह पता चलता है कि यह कैसे काम करता है यह कैसे परीक्षण करता है) । जब आप गुणवत्ता आश्वासन का उल्लेख करते हैं तो अधिकांश लोग "ब्लैक बॉक्स" परीक्षण करते हैं।

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

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

उस प्रकाश में देखा गया है, यह टेस्टर्स के लिए डेवलपर्स का उपयोग करने की बात कम है, यह एक तरह से डिस्कनेक्ट जोड़ी प्रोग्रामिंग है जहां एक डेवलपर की गुणवत्ता को नियंत्रित करने पर जोर दिया जाता है।

दूसरी ओर, बहुत सारे परीक्षण (जैसे बुनियादी यूआई कार्यक्षमता) स्पष्ट रूप से उस तरह के कौशल की आवश्यकता नहीं है। यही वह जगह है जहां जोएल का एक बिंदु है।

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

Answer 2

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

हम उत्पादित कीड़े के लिए दहलीज रखने की कोशिश करते हैं। यदि परीक्षण के दौरान यह दहलीज पार हो जाती है तो डेवलपर इसके लिए उत्तरदायी है। यह तय करने के लिए आप पर निर्भर है कि यह सीमा क्या है (हमारे लिए यह परियोजना से परियोजना में भिन्न हो सकती है)।

इसके अलावा, सभी इकाई परीक्षण डेवलपर्स द्वारा किया जाता है।

Answer 3

मैं केवल एक वर्ष के लिए उद्योग में रहा हूं, लेकिन मेरे अनुभव में देव अपनी सुविधाओं का परीक्षण करने के लिए जिम्मेदार हैं, जबकि क्यूए परिदृश्य परीक्षण के लिए जिम्मेदार है। क्यूए से किसी भी सीमा की स्थिति का परीक्षण करने की उम्मीद की जाएगी।

Answer 4

यहाँ कुछ तरीके कि डेवलपर परीक्षण सबसे कुशल/उच्चतम अदायगी है कर रहे हैं:

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

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

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

Answer 5

मैं अपने आंतरिक मंच पर एक प्रश्न के उत्तर का जवाब दे रहा हूं। यदि आपके पास एक घंटा या तो है .. मैरी पॉपपेन्डेक के Competing on the basis of Speed वीडियो को सुनें। अनुशंसित

नोट (तक परीक्षक - मैं क्यूए टीम को देखें)

डेवलपर/इकाई परीक्षण ________ = _______ प्रयोज्य परीक्षण & खोजपूर्ण परीक्षण

'==== ================================================== ============

Acceptan सीई/ग्राहक परीक्षण ___ = _____ संपत्ति परीक्षण

कल्पना करें कि चार चौकोरों के साथ एक वर्ग बनने की कल्पना करें। :)

बाएं आधा स्वचालित होना चाहिए।

• डेवलपर परीक्षण सत्यापित करते हैं कि कोड कोडर के रूप में काम करता है। उपकरण: NUnit/xUnit/जो भी घर से बना उपकरण
• ग्राहक परीक्षण सत्यापित करते हैं कि कोड काम करता है क्योंकि ग्राहक इसे चाहता था। परीक्षणों को लिखना बहुत आसान होना चाहिए, ग्राहक को .NET/Java सीखने की आवश्यकता नहीं होनी चाहिए। अन्यथा ग्राहक उन परीक्षणों को नहीं लिखेंगे (हालांकि उन्हें डेवलपर की कुछ मदद की आवश्यकता हो सकती है)। उदाहरण के लिए फ़िट HTML टेबल का उपयोग करता है जिसे Word में लिखा जा सकता है। उपकरण: एफआईटी रिग्रेशन उपकरण भी यहां झूठ बोलते हैं। रिकार्ड पुनरावृत्ति।

सही आधा बेहतर समय & अच्छे परीक्षकों के प्रयास का बेहतर उपयोग करता है। जैसेकोई स्वचालित परीक्षण आपको बता सकता है कि एक्स संवाद प्रयोग योग्य है या नहीं। मशीनों की तुलना में मनुष्य बेहतर होते हैं।

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

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

Answer 6

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

आपकी समस्या का हिस्सा $ 100 डॉलर प्रति घंटा डेवलपर्स और $ 30 प्रति घंटा परीक्षकों का उपयोग कर सकता है:}। लेकिन लागत के बावजूद, मुझे लगता है कि विकास चक्र में पहले पाया गया बग अनिवार्य रूप से सस्ता है, आप शायद डेवलपर्स के पास अधिक परीक्षण करके पैसा बचाएंगे। यदि आपके पास अत्यधिक भुगतान करने वाली देव टीम है और टेस्टर्स हैक है, तो आपको शायद बहुत सारे बड़े स्पष्ट मुद्दे मिलेंगे, लेकिन आपको बहुत अधिक अस्पष्ट बग याद आ जाएंगी जो बाद में आपको परेशान करने के लिए वापस आ जाएंगे।

तो, मुझे लगता है कि आपके प्रश्न का उत्तर यह है कि परीक्षकों को जितना चाहें उतना परीक्षण करना चाहिए। आप अपने सभी परीक्षकों को आग लगा सकते हैं और डेवलपर्स को सभी परीक्षण कर सकते हैं, या आप परीक्षकों की एक सेना को किराए पर ले सकते हैं और डेवलपर्स को जो भी चाहें चेक इन कर सकते हैं।

Answer 7

जब उचित हो, गुणवत्ता नियंत्रण टीमों/सुरक्षा, प्रतिगमन, प्रयोज्य, प्रदर्शन, तनाव, स्थापना का संचालन परीक्षण और नहीं डेवलपर्स

अपग्रेड

डेवलपर्स कोड के लिए कोड-कवरेज के साथ इकाई परीक्षण करना चाहिए लिखा जा रहा में सक्षम होना चाहिए एक न्यूनतम लक्ष्य के रूप में।

के बीच में

, वहां अभी भी काफी परीक्षण का एक सा किया जाना

• पूर्ण कोड पथ का परीक्षण
• घटक जांच
• इंटीग्रेशन (घटकों के)
• सिस्टम टेस्टिंग (एकीकरण) परीक्षण है
• आदि

जिम्मेदारी इनके लिए अनुकूलता कुछ समझदार समझौते के आधार पर क्यूए और विकास के बीच मिश्रित होती है जो अधिकतर समझ में आता है। कुछ घटक परीक्षण केवल यूनिट परीक्षण द्वारा किए जा सकते हैं, अन्य एकीकरण परीक्षण आदि के दौरान 'पर्याप्त रूप से' परीक्षण किए जाते हैं

एक-दूसरे से बात करें, यह पता लगाएं कि हर कोई सबसे ज्यादा आरामदायक है। इसमें कुछ समय लगेगा, लेकिन यह इसके लायक है।

Answer 8

परीक्षण जितना संभव हो उतना स्वचालित होना चाहिए, जो टेस्टर्स स्वचालित कोड सूट में जोड़े जाने वाले कोड लिख रहे हैं, जो इसे वापस काम में बदल देता है।

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

Answer 9

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