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

गुणवत्ता परीक्षण। इसके लिए कौन जिम्मेदार है? कई वर्षों तक, इस प्रश्न का एकमात्र उत्तर मेरे सिर में था। बेशक, एक क्यूए इंजीनियर! आखिरकार, मैं खुद QA- इंजीनियरों से संबंधित हूं।

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

क्या डेवलपर्स को अपने कोड का परीक्षण करना चाहिए?

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

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

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

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

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

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

हम बग से चूक गए। क्या परीक्षक दोष देने हैं?

हाँ और नहीं। हर बार एक त्रुटि का पता चलता है, विशेष रूप से उत्पादन में, आपको और आपकी टीम को चर्चा के लिए कुछ करना होगा। इस चरण में त्रुटि दिखाई देने के कई कारण हैं:

1. जिस स्थान पर त्रुटि दिखाई दी वह परीक्षकों के लिए प्राथमिकता नहीं थी। बहुत बार, उत्पादन पर दिखाई देने वाली त्रुटि के बारे में किसी ने नहीं सोचा। यह डेवलपर्स और परीक्षकों के बीच संचार की कमी का परिणाम है। एक क्षेत्र की जाँच करना कितना महत्वपूर्ण है, इस मुद्दे पर आपसी समझ नहीं बन पाई। इस लापरवाही के क्लासिक उदाहरण प्रदर्शन और सुरक्षा मुद्दे हैं। यदि आप जानते हैं कि ये क्षेत्र आपके आवेदन के लिए महत्वपूर्ण हैं, तो टीम को बताएं।
2. क्यूए को परीक्षण क्षेत्र में आवश्यक ज्ञान नहीं है। यह भी एक आम समस्या है। डेवलपर्स ने फ़ंक्शन लिखा और स्वचालित रूप से मान लिया कि क्यूए समझता है कि यह कैसे और से काम करता है। वैसे, किसी गंभीर परियोजना की गुणवत्ता के विश्लेषण के लिए धारणा बनाना कभी अच्छी रणनीति नहीं रही है। यदि आप कुछ महत्वपूर्ण पहलू देखते हैं, तो सुनिश्चित करें कि मुख्य क्यूए इंजीनियर और उनकी टीम भी उसे देखती और समझती है। इस कदम के आसपास कोई रास्ता नहीं है।
3. डेवलपर्स वास्तव में परवाह नहीं है। हम सब इंसान हैं। और हम सभी के काम के बाहर एक जीवन है। कुछ डेवलपर्स उच्च-गुणवत्ता वाले उत्पाद बनाने के लिए कड़ी मेहनत करते हैं, वे परीक्षकों के साथ बात करते हैं, उन्हें संभावित समस्याओं और पसंद के बारे में सूचित करते हैं। और ऐसे डेवलपर हैं जो परवाह नहीं करते हैं। वे हर दिन इस उत्पाद का उपयोग नहीं करते हैं और इसके महत्व को नहीं समझते हैं। उनके लिए, यह केवल एक पक्ष कार्य है जिसे पूरा करने और इसके बारे में भूल जाने की आवश्यकता है। सीधे शब्दों में कहें, तो उन्हें इस बात की परवाह नहीं है कि अंतिम उत्पाद अपर्याप्त गुणवत्ता का होगा।
4. क्यूए इंजीनियरों परवाह नहीं है यहाँ सिक्के का दूसरा पहलू है। सभी परीक्षकों को परियोजना की परवाह नहीं है। कुछ को बस परीक्षण खत्म करने, एक सुंदर रिपोर्ट बनाने और इसके बारे में भूलने की जरूरत है। उच्च-गुणवत्ता वाले परीक्षण कवरेज उन्हें परेशान नहीं करते हैं, वे डेवलपर्स के साथ संवाद नहीं करना चाहते हैं। आप बग पर चर्चा कर सकते हैं, लेकिन ऐसे परीक्षक केवल उन्हें महत्वपूर्ण या पंजीकृत नहीं कर सकते हैं।
5. परीक्षक पर्याप्त योग्य नहीं हैं। एक और समस्या इस तथ्य में हो सकती है कि परीक्षक आपके आवेदन का परीक्षण करने के लिए पर्याप्त रूप से योग्य नहीं हैं। उदाहरण के लिए, आपको प्रवेश परीक्षण आयोजित करने की आवश्यकता है, और जो आपके निपटान में है वह सभी परीक्षकों की एक टीम है जो केवल मैनुअल परीक्षण कर सकते हैं। इस मामले में, उन्हें बस यह नहीं पता होगा कि उससे कैसे संपर्क किया जाए। यहां आपको या तो डेवलपर्स पर भरोसा करने की जरूरत है, या अधिक का चयन करें
   योग्य क्यूए इंजीनियर जो इस विशेष क्षेत्र का परीक्षण करने का तरीका जानते हैं।
6. उपयोगकर्ता अनुसंधान का अभाव। डेवलपर्स जानते हैं कि एक एप्लिकेशन कैसे बनाया जाए, और क्यूए इंजीनियर इसे कैसे तोड़ सकते हैं। उपयोगकर्ताओं के बारे में क्या? उपयोगकर्ता वास्तविक लोग हैं जो वास्तविक दुनिया में आपके आवेदन का उपयोग करेंगे। वे इसे तोड़ने वाले नहीं हैं। यह सिर्फ इतना है कि वे सभी अलग हैं और अलग-अलग लक्ष्य हैं, लेकिन वे सभी आपके आवेदन का उपयोग करके उन्हें प्राप्त करना चाहते हैं। क्यूए इंजीनियरों को त्रुटि के लिए इस्तेमाल किया जा सकता है और यह महसूस किया जा सकता है कि यह अक्सर होता है, इसलिए, यह ज्यादा मायने नहीं रखता है। उपयोगकर्ता इसे बर्दाश्त नहीं करेगा। यदि आपका एप्लिकेशन क्रैश हो जाता है, तो अगला चरण इसे हटाने के लिए है, और फिर एक विकल्प की तलाश करें। यही वास्तविकता है। एक उपयोगकर्ता ऑडियंस पर शोध करना और / या एक परीक्षण उपयोगकर्ता समूह होना दो रणनीतिक रूप से महत्वपूर्ण चीजें हैं।
7. संचार प्रक्रिया का खराब संगठन। आदर्श रूप से, आपको बग को सॉर्ट करने के लिए एक सरल प्रक्रिया की आवश्यकता है जो आपको क्यूए (या कम से कम उन्हें सही ढंग से रैंक करने) से त्रुटियों का मूल्यांकन करने और उन्हें डेवलपर्स पर पारित करने की अनुमति देगा ताकि वे अपने कार्यभार को समझें। जब कोई गलतफहमी होती है, तो परीक्षक और डेवलपर को हमेशा एक दूसरे से संपर्क करने और कुछ मिनटों या घंटों के भीतर इस समस्या को हल करने में सक्षम होना चाहिए। यदि यह प्रक्रिया स्थापित नहीं हुई है और दोनों पक्ष गलतफहमी के कारण की तलाश में नहीं हैं, तो इससे अच्छा कुछ नहीं होगा। दोनों पक्ष गतिविधियों का अनुकरण करेंगे, लेकिन वास्तव में वे दोनों एक मृत अंत में होंगे और किसी और की प्रतीक्षा करेंगे जो आकर जादुई स्थिति का समाधान कर सकते हैं। यह मूल रूप से गलत दृष्टिकोण है।
8. पर्याप्त परीक्षक नहीं। एक आवेदन जटिल हो सकता है और कई प्लेटफार्मों और ब्राउज़रों पर परीक्षण की आवश्यकता हो सकती है। इस कार्य के लिए बस कुछ क्यूए इंजीनियर पर्याप्त नहीं हो सकते हैं। अधिक लोगों को काम पर रखने पर विचार करें या आपके पास संसाधनों को इस तरह से पुनर्वितरित करें जैसे कि परीक्षण पर जोर बढ़ाना।
9. डेवलपर्स ओवरलोडेड हैं। आपके आसपास आदर्श और उच्च योग्य विशेषज्ञ हो सकते हैं, लेकिन वे निरंतर तनाव में काम करते हैं और कोई भी उनकी मदद नहीं कर सकता है। हां, वे दबाव में हैं, और उनके पास QA टीम से बात करने का समय नहीं है। यह एक बहुत ही आम समस्या है और यह एक मुख्य कारण है कि सॉफ्टवेयर खराब गुणवत्ता का है।
10. गुणवत्ता सुर्खियों में नहीं है। इस परिदृश्य पर भी विचार करें। यहाँ और वहाँ मामूली कीड़े थे। उनमें से कोई भी महत्वपूर्ण नहीं है। हालांकि, उपयोगकर्ताओं को आवेदन पसंद नहीं है। समीक्षाएँ खराब हैं। UX औसत से नीचे है। और क्यों? हां, क्योंकि गुणवत्ता उत्पाद बनाने के बारे में किसी ने नहीं सोचा था। डेवलपर्स ने अपना काम किया, परीक्षकों ने अपना किया, लेकिन किसी ने भी गुणवत्ता नियंत्रण प्रक्रिया का पालन नहीं किया। अनुप्रयोग विकास को टीमों को संयोजित करना चाहिए, जिससे वे एक पूरे हो जाएं। यदि सामूहिक में ऐसा मूड नहीं है, तो कोई भी गुणवत्ता की परवाह नहीं करता है।

निष्कर्ष

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

एकमात्र सवाल यह होना चाहिए: "क्या हम वास्तव में अच्छा उत्पाद बना रहे हैं?" । अगर इस सवाल का जवाब हां है, तो इसमें कोई संदेह नहीं होना चाहिए कि सभी टीमें एक बड़ा काम कर रही हैं।

किसी को दोष नहीं देना होगा और सभी लोग खुश होंगे, क्योंकि गुणवत्ता आश्वासन एक सामान्य कार्य है!