क्या आप मानते हैं कि सॉफ्टवेयर इंजीनियर्स के लिए कुछ समय के लिए क्वालिटी एश्योरेंस इंजीनियर्स के रूप में काम करना एक अच्छा विचार है? [बन्द है]

Question

मेरा मानना ​​है कि यह है। क्यों?

1. मैंने कई सॉफ्टवेयर इंजीनियरों का सामना किया है जो मानते हैं कि वे किसी भी तरह क्यूए इंजीनियरों से बेहतर हैं। मुझे लगता है कि यह इस विश्वास को बुझाने में मदद कर सकता है यदि वे कुछ समय के लिए एक क्यूए इंजीनियर का काम करते हैं, और महसूस करते हैं कि यह अपने आप में एक अनूठा और मूल्यवान कौशल है।

2. एक सॉफ्टवेयर इंजीनियर अपने स्वयं के कार्यक्रमों का परीक्षण करने में बेहतर होता है, बाकी समय सॉफ्टवेयर कोड जीवन-चक्र के माध्यम से अपना रास्ता बनाते समय कम लागत।

3. एक सॉफ्टवेयर इंजीनियर जितना अधिक समय सोचता है कि कोई कार्यक्रम कैसे टूट सकता है, उतना ही वे इन मामलों पर विचार करते हैं क्योंकि वे उन्हें विकसित कर रहे हैं, इस प्रकार अंतिम उत्पाद में कीड़े को कम करते हैं।

4. एक सॉफ्टवेयर इंजीनियर की "पूर्ण" की परिभाषा हमेशा दिलचस्प होती है ... अगर उन्होंने क्यूए इंजीनियर के रूप में समय बिताया है तो शायद यह परिभाषा सॉफ्टवेयर के डिजाइनर से अधिक निकटता से मेल खाएगी।

ध्यान दें, मैं एक छोटे समय-सीमा को ध्यान में रखते हुए सुझाव देता हूं क्योंकि मैं जानता हूं कि कोई व्यक्ति उस स्थिति में काम करता है जो उस स्थिति में नहीं है जिसके लिए वे काम पर रखे गए हैं, निश्चित रूप से उस डेवलपर को खोने का एक नुस्खा है।

आप सब क्या सोचते हैं?

Comments

मेरी पहली नौकरी क्यूए थी। मुझे इससे नफरत थी, लेकिन मैं वास्तव में क्यूए के महत्व को समझता था।

— जॉब

जब तक मैंने ग्लेनफोर्ड मायर्स क्लासिक द आर्ट ऑफ़ सॉफ्टवेयर टेस्टिंग नहीं पढ़ा, तब तक मैंने क्यूए के पीछे की रचनात्मकता की पूरी तरह से सराहना नहीं की ।

— मेकनील

मैं कई सॉफ्टवेयर इंजीनियर्स का मानना है कि वे किसी भी तरह से बेहतर हैं का सामना किया है बाकी सब ग्रह पर ;-)

— स्टीवन ए लोव

बहुत सच्चा स्टीवन।

— मैसी एब्बे

मैं इसके बजाय यह पूछना चाहता हूं कि क्या सॉफ्टवेयर इंजीनियरों के लिए कुछ क्यूए सामान करना एक अच्छा विचार है, बजाय यह सोचने के कि कुछ अज्ञात इकाई उन्हें मजबूर करने जा रही है।

— डेविड थॉर्नले

Answer 1

1. मैंने कई सॉफ्टवेयर इंजीनियरों का सामना किया है जो मानते हैं कि वे किसी भी तरह क्यूए इंजीनियरों से बेहतर हैं। मुझे लगता है कि यह इस विश्वास को बुझाने में मदद कर सकता है यदि वे कुछ समय के लिए एक क्यूए इंजीनियर का काम करते हैं, और महसूस करते हैं कि यह अपने आप में एक अनूठा और मूल्यवान कौशल है।

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

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

2. एक सॉफ्टवेयर इंजीनियर अपने स्वयं के कार्यक्रमों का परीक्षण करने में बेहतर होता है, बाकी समय सॉफ्टवेयर कोड जीवन-चक्र के माध्यम से अपना रास्ता बनाते समय कम लागत।

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

3. जितना अधिक समय एक सॉफ्टवेयर इंजीनियर सोचता है कि कोई प्रोग्राम कैसे टूट सकता है, अधिक बार वे इन मामलों पर विचार करते हैं क्योंकि वे उन्हें विकसित कर रहे हैं, इस प्रकार अंत उत्पाद में कीड़े को कम करते हैं।

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

4. एक सॉफ्टवेयर इंजीनियर की "पूर्ण" की परिभाषा हमेशा दिलचस्प होती है ... अगर उन्होंने क्यूए इंजीनियर के रूप में समय बिताया है तो शायद यह परिभाषा सॉफ्टवेयर के डिजाइनर से अधिक निकटता से मेल खाएगी।

"पूरा" केवल आवश्यकताओं के खिलाफ मापा जा सकता है। या तो आवश्यकताओं को संतुष्ट किया जाता है और परियोजना पूरी होती है, या अपूर्ण आवश्यकताएं होती हैं और परियोजना पूरी नहीं होती है। पूर्ण का कोई अन्य उपाय बेकार है।

Comments

धन्यवाद थॉमस, यह एक बहुत जानकारीपूर्ण और विचारशील जवाब है।

— मैसी एब्बे

Answer 2

प्रोग्रामर को अपने कोड के लिए जवाबदेह बनाना और उन्हें अपने बग को ठीक करने की आवश्यकता होती है। यह बोनस और / या नौकरी का नुकसान है।

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

Comments

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

— मैसी एब्बे

इसके अलावा, इस दृष्टिकोण के लिए नकारात्मक में से एक प्रोग्रामर कुछ समय के लिए खो रहा है, एक सप्ताह ... दो सप्ताह, एक महीने? और मुझे नहीं लगता कि यह एक अच्छा विचार है कि उन्हें ऐसे काम करने हैं जो उनकी वर्तमान नौकरी के साथ बहुत कम हैं ... (शौचालय की सफाई: पी)

— मैसी एब्बे

Answer 3

"... मुझे क्यूए इंजीनियरों के रूप में काम करना है ..."? आप इसे ध्वनि प्रतिकूल या दंड बनाते हैं।

मैं एक सॉफ्टवेयर डेवलपर हूं। मैं इसे अपनी नौकरी का एक हिस्सा QA इंजीनियर भी मानता हूं, भले ही हमारे पास QA विभाग हो। सॉफ़्टवेयर वितरित करना मेरा काम है, जो कुछ चीज़ों को पूरा करता है, और यह करने के लिए कि मुझे यूनिट टेस्ट लिखना होगा और सुनिश्चित करना होगा कि सॉफ्टवेयर उन्हें पास कर दे।

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

मैं सॉफ्टवेयर विकसित करना चुनता हूं, और सॉफ्टवेयर विकसित करना चाहता हूं। अगर कुछ प्रबंधक मेरे पास आए और मुझसे कहा कि मैं ऐसा नहीं कर सकता और मुझे QA करना था, तो मैं उन्हें बताऊंगा कि उन्हें एक नया सॉफ्टवेयर डेवलपर और QA व्यक्ति ढूंढने की आवश्यकता है क्योंकि मैं वहां काम नहीं करूंगा। मैं अपने कोड के साथ हो सकता हूं लेकिन रचनात्मक प्रक्रिया और प्रोग्रामिंग पहेली / चुनौती मेरे लिए बेहद महत्वपूर्ण है। अगर मैं एक कॉरपोरेट माहौल में रचनात्मक होने के कारण के बिना कोड नहीं लिख सकता हूं और जिस तरह से मुझे पूरा किया जा रहा है, उसे चुनौती दी जा सकती है, तो मैं वापस कांटे की ड्राइविंग पर जाऊंगा।

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

Comments

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

— मैसी एब्बे

क्या आपको लगता है कि QA इंजीनियर के रूप में एक नया सॉफ्टवेयर इंजीनियर काम कर रहा है जो आपको अभी उस बिंदु तक पहुंचने में मदद करेगा?

— मैसी एब्बे

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

— टिन मैन

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

— टिन मैन

@ ग्रेग धन्यवाद ग्रेग, जो एक अच्छी रणनीति की तरह लगता है। मुझे विश्वास है कि आपने मुझे आश्वस्त किया है कि अन्य रणनीति का एक मिश्रण मेरे द्वारा शुरू किए गए प्रस्ताव से बेहतर है।

— मैसी एबे

Answer 4

प्रोग्रामर को क्यूए इंजीनियरों के रूप में काम करने के लिए प्राप्त करना आपके सर्वश्रेष्ठ डेवलपर्स को खोने का एक नुस्खा है। प्रोग्रामिंग और क्यूए को अलग-अलग कौशल सेट और विचार प्रक्रियाओं की आवश्यकता होती है।

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

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

Comments

धन्यवाद टॉलेमी, मैं एक छोटे से समय-सीमा को ध्यान में रखते हुए यह सुझाव देता हूं क्योंकि मैं जानता हूं कि कोई व्यक्ति ऐसी स्थिति में काम करता है जो उस स्थिति में नहीं है जिसके लिए वे काम पर रखे गए हैं, निश्चित रूप से उस डेवलपर को खोने का एक नुस्खा है।

— मैसी एब्बे

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

— टिन मैन

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

— डेविड थॉर्नले

एर, यह मानता है कि आप एक ऐसे स्थान पर काम कर रहे हैं जो कुशल क्यूए लोक देवों से कम भुगतान करता है। मुझे पता है कि कुछ स्थान ऐसा करते हैं, लेकिन यह मेरे अनुभव को नहीं दर्शाता है - जब मुझे लोगों के वेतन का पता चला है तो वे आम तौर पर बराबर रहे हैं।

— टेस्टेरैब

एक प्रोग्रामर होने के शुरुआती वर्षों में, आपका वेतन इस बात पर निर्भर करता है कि आपके पास कितने वर्षों का प्रोग्रामिंग अनुभव है। इसलिए 2 वर्ष C # और 1 वर्ष QA आपको 3 वर्ष C # वेतन के बजाय 2 वर्ष C # वेतन पर रखता है।

— माइकल शॉ

Answer 5

जरूरी नहीं - प्रोग्रामर और टेस्टर्स दोनों के लिए अलग-अलग स्किल होना जरूरी है। सिर्फ इसलिए कि आप एक अच्छे प्रोग्रामर हैं इसका मतलब यह नहीं है कि आप एक अच्छे परीक्षक हो सकते हैं (बहुत से लोग यह नहीं समझते हैं, लेकिन एक प्रोग्रामर होने के नाते आप स्वतः ही परीक्षक बनने के योग्य नहीं हैं)।

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

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

इसका मतलब यह नहीं है कि आप एक अनुभवी प्रोग्रामर को ले जाएं और उसे कुछ समय के लिए परीक्षा दें ताकि वह समझ सके कि क्यूए इंजीनियर कितनी मेहनत करते हैं।

Comments

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

— मैसी एब्बे

Answer 6

यहाँ कुछ संभावित समस्याएं हैं जिन्हें मैं आपके प्रस्ताव के साथ देख रहा हूँ:

1) यदि आप सुझाव दे रहे हैं कि आप एक छोटे से कार्यकाल के लिए क्यूए विभाग में नए-टू-द-फील्ड सॉफ़्टवेयर इंजीनियरों को डालेंगे, तो क्या इसका विपरीत प्रभाव नहीं होगा? - वे मान सकते हैं कि क्यूए आप कुछ ऐसा करते हैं जब आप एक नौसिखिया होते हैं और आपको समझ में नहीं आता कि आप क्या कर रहे हैं - आखिरकार, यह उनके लिए कैसे काम किया है।

2) थोड़ी देर के लिए बहुत खराब परीक्षक होने के नाते जरूरी नहीं कि उन्हें कुछ भी मूल्यवान सिखाया जाए। लेकिन यह बाद में उन्हें अप्राप्य बना सकता है, क्योंकि वे मान लेंगे कि वे अब परीक्षण के बारे में सब जानते हैं, क्योंकि उन्होंने एक परीक्षण विभाग में 6 सप्ताह एक समय में बिताए थे।

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

4) यदि आप 1, 2, और 3 से बचना चाहते हैं, तो आप अपने परीक्षण विभाग को कैसे मनाएंगे कि यह किसी को सिखाने में ऊर्जा की जबरदस्त मात्रा में निवेश करने और किसी की निगरानी करने के लायक है जो परीक्षण में रुचि नहीं रखता है? (मैं आपको बता सकता हूं, यह किसी ऐसे व्यक्ति के साथ काम करने के लिए समय और ऊर्जा की एक डरावनी मात्रा लेता है, जो याद रखें, उनके परीक्षण योग्यता के लिए नहीं चुना गया है । आप कुछ हफ्तों के लिए परीक्षण टीम अतिरिक्त संसाधन की पेशकश नहीं कर रहे हैं, आप 'उन्हें कुछ हफ्तों के लिए अपने सबसे अनुभवी लोगों में से एक को खोने के लिए कह रहे हैं, जबकि वे आपकी नौसिखिया शिक्षा देते हैं)।

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

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

Answer 7

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

Comments

यह किस्सा सवाल का कोई जवाब नहीं देता है।

— कोई नहीं

Answer 8

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