क्यूए डेवलपर्स के साथ प्रभावी बातचीत का निर्माण करता है। एक संभव तरीका

एक , दूसरे के पूरक, मेरे लेख उन लोगों के लिए कार्रवाई के लिए एक संभावित मार्गदर्शक बन गए, जिन्होंने अभी तक "अपनी शैली" नहीं पाई है और सुनिश्चित नहीं हैं कि कहां से शुरू करें।

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

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

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

परिचय

सबसे पहले, जैसा कि अभ्यास से पता चलता है, अक्सर वे क्यूए जो पेशे से आवश्यकतानुसार विकास में सेंध लगाने का प्रबंधन नहीं करते हैं

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

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

• वे अभी भी 10-20 साल पहले क्यूए के बारे में सोचते हैं, जब वे वास्तव में थे;
• पिछले सभी QAs जिनके साथ उन्होंने ठीक उसी तरह से काम किया और व्यवहार किया, और वे बस यह नहीं जानते कि अन्यथा क्या होता है;
• सिद्धांत रूप में, वे नहीं जानते कि QA अभियंता के काम का सार क्या है, क्योंकि उन्हें बस इसकी आवश्यकता नहीं है - वे अपने कौशल में विकसित होते हैं;
• कोड विकास पहले से ही अच्छी तरह से स्थापित है और इसमें कुछ बदलना सिर्फ आलस्य है।

पहली समस्या से शुरू करते हैं।

क्यूए इंजीनियर! अपने सिर में एक वसंत सफाई करें

अपने पेशे को समझने पर काम करें

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

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

इसलिए, सबसे पहले, क्यूए इंजीनियर के पेशे की परिभाषा, प्रकार, परीक्षण के स्तर और शब्द के बारे में सभी मूलभूत बातों को याद करें। कुख्यात को समझें "मैं कौन हूं?" और "मैं यहाँ क्यों हूँ?"

सवालों के जवाब ढूंढे

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

केवल इस मामले में आप परियोजना पर आत्मविश्वास से बोल पाएंगे। भले ही आप अब तक केवल "क्यों" और "लाभ क्या है" के सवालों के जवाब जानते हों, लेकिन आप "कैसे" नहीं जानते हैं। इस तथ्य से पहले से ही आश्वस्त महसूस करें कि आप कार्य के सामने देखते हैं, कार्य का सही सूत्रीकरण 80% सफलता है।

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

उस अनुभव को गिरा दो जो तुम परिपूर्ण नहीं हो

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

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

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

और मेरी छोटी पसंदीदा चाल हमेशा दूसरों की मदद करना है, जब मैं मजबूत हूं - काम, सलाह, दयालु शब्द से, यह मेरी मदद करने के लिए दूसरों की पारस्परिक इच्छा के साथ वापस आता है।

गलती करने से डरो मत

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

याद रखें, फिल्म "मॉस्को डोंट बिलीव इन टीयर्स" में मुरायेवा की नायिका ने लाइब्रेरी जाने से पहले खुद को स्थापित किया: "यदि आप बाहर विस्फोट करते हैं, तो आत्मविश्वास से बाहर ब्लर करें - फिर इसे एक दृष्टिकोण कहा जाता है"। यह वास्तव में काम करता है।

अपने आप को उन कार्यों पर कॉल करने से डरो मत जिन्हें आप संभाल नहीं सकते हैं। याद रखें, आप एक टीम में काम कर रहे हैं और कह रहे हैं कि कुछ काम नहीं कर रहा है और टीम से मदद मांगना सामान्य है।

और यहां तक ​​कि अगर आपके काम के दौरान आप निष्कर्ष पर आते हैं "आपको ऐसा नहीं करना है", तो यह प्रगति होगी, क्योंकि अगला कदम सबसे अच्छा समाधान खोजना है।

अप्रचलित मानकों को जारी करें, भविष्य को देखें

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

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

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

और यह आपके हाथों में है कि आप अपनी कंपनियों में उन्नत सिद्धांतों को पेश करें, बजाय अतीत के रूढ़ियों के पीछे देखने के।

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

ऐसी टीमें हैं जो QA Engineer की स्थिति के बिना रहती हैं, मुझे पता है। और अगर आप पहले से ही इस परियोजना में खुद को विसर्जित करने का प्रयास करते हैं और डेवलपर्स के साथ ऑटोटेस्ट लिखना सीखते हैं, तो एक दिन आप अपनी दक्षताओं को वहां भी बेच सकते हैं और वहां परीक्षण में एक सॉफ्टवेयर इंजीनियर बन सकते हैं।

क्यूए इंजीनियर! फाइन-ट्यून टीमवर्क

जब अपने आप पर काम खत्म हो जाता है, तो डेवलपर्स के साथ सहयोग स्थापित करने पर काम करने का समय है।

सबसे महत्वपूर्ण बात

• आपकी हरकतें टीम के लिए स्पष्ट और पारदर्शी होनी चाहिए। सबसे सरल और सबसे प्रभावी उनके लिए अपने मिशन को व्यक्त करना है। यदि बिना किसी कारण के, आप उनके पूल में चढ़ने का अनुरोध करने लगते हैं, तो पूछते हैं कि "आपके यहां किस तरह के परीक्षण हैं?", "लेकिन आपको ऐसा परीक्षण लिखना चाहिए", पहली (सुरक्षात्मक) प्रतिक्रिया होगी " आप कहाँ जा रहे हैं? ”,“ आप कौन हैं / मेरे काम की आलोचना करने के लिए? ”। उसने एक हफ्ते के लिए इस ब्रंच को पकाया हो सकता है, अंत में उखाड़ा जा सकता है, और फिर क्यूए को मिल गया। इसलिए, उन्हें पहले से बताएं कि आप क्या करने जा रहे हैं, क्यों और क्या लाभ परियोजना और टीम के लिए हैं। मिट्टी तैयार करें।
• विकास में आपकी भागीदारी को एक प्राथमिकता के रूप में माना जाना चाहिए, क्योंकि कुछ ऐसा जो गुणात्मक रूप से डेवलपर के काम को बेहतर बनाता है। उसके साथी बनें। उदाहरण के लिए, शिक्षित करें - बताएं कि ग्राहकों की कार्यक्षमता का उपयोग करने की संभावना क्या है, कौन से कीड़े पहले ही हो चुके हैं और किन लोगों को इससे बचना चाहिए, जिसका अर्थ है कि एक साथ सोचें कि कौन से परीक्षण और क्यों महत्वपूर्ण हैं। एक अनिवार्य मूड में संवाद न करें। आप मनोवैज्ञानिक ट्रिक का भी सहारा ले सकते हैं - उन लोगों को नोट करने के लिए जिन्होंने प्रारूप में कुछ अंतिम रिपोर्टों में सेल्फ-टेस्ट की कवरेज बढ़ाई थी "हम सब ठीक हैं!" जब आपका काम सराहा जाता है तो यह हमेशा अच्छा होता है। और ऑटो-टेस्ट कवरेज के साथ पारंपरिक क्यूए समीक्षाएं भी एक साथ काम करने के लिए एक प्रेरणा हैं।

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

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

विशिष्ट प्रश्नों के उत्तर

मेरे दूसरे लेख के बाद, जिसने क्यूए और विकास के करीब काम की पेशकश की, दर्शकों ने "हम कोशिश की श्रेणी से समाप्त हो गए, लेकिन डेवलपर्स के टीम लीडर वास्तव में मिलना नहीं चाहते हैं।" व्यावसायिक विकास के अपने मौजूदा स्तर से, मैं केवल निम्नलिखित सलाह दे सकता हूं।

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

एक दिलचस्प सवाल यह भी था कि कैसे हो अगर आप अभी तक नहीं जानते हैं कि डेवलपर कोड को कैसे पढ़ना है, तो आप उनके ऑटोग्राफ का पता नहीं लगा सकते हैं।

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

निष्कर्ष

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

और यदि आप अपनी खुद की प्रेरणा को मजबूत करने के लिए कुछ पढ़ना चाहते हैं, तो दो अद्भुत पुस्तकों से शुरू करें, एक संदर्भ जो मैंने पाठ में दिया है:

1. सॉफ्टवेयर टेस्टिंग की नींव: ISTQB सर्टिफिकेशन
डोरोथी ग्राहम, रेक्स ब्लैक, एरिक वैन वेनेंगल, इसाबेल इवांस द्वारा
2. Google पर परीक्षण कैसे करें
जेम्स व्हिटकर, जेसन अर्बन, जेफ कैरोलो

ध्यान देने के लिए आप सभी का धन्यवाद!