छह तरीकों से परीक्षकों को फायदा हो सकता है (कार्यात्मक परीक्षण के अलावा)

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

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

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

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

1. सभी संदेशों की जांच करें

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

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

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

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

2. एक UX समीक्षा करें

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

उत्पाद को स्थिर करने की प्रक्रिया में, किसी भी यूएक्स विसंगतियों से छुटकारा पाने पर ध्यान केंद्रित करें। संपूर्ण एप्लिकेशन की UX समीक्षा करें। आइकन, पाठ, कार्यों, कार्यों और मुख्य थ्रेड्स के साथ प्रारंभ करें। पूर्ण यूएक्स समीक्षा के लिए पात्रों और मंथन का उपयोग करें। उपयोगकर्ताओं के लिए टचपॉइंट के बारे में भी सोचें। आप उनके साथ कैसे व्यवहार करते हैं? क्या आपके आवेदन में कुछ भ्रामक है? Https://cantunsee.space पर ऐसे अभ्यास हैं जो आपके UI कौशल का परीक्षण करने में आपकी सहायता करेंगे।

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

3. प्रतियोगी विश्लेषण का संचालन करना

यह अफ़सोस की बात है कि कई परीक्षक अलगाव में काम करते हैं और अन्य कंपनियों के उत्पादों के बारे में कोई विचार नहीं है। विज्ञापन जानकारी, वेबिनार, डेमो, मीडिया और ब्लॉग में समाचार के साथ अपने प्रतिद्वंद्वियों की जांच करें, और फिर सुविधाओं को लिखें और अपने उत्पाद की शक्तियों और कमजोरियों का विश्लेषण करें।

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

4. उपकरण का अन्वेषण करें

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

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

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

5. उन जोखिमों के बारे में सोचें जो "बुरे सपने" बन सकते हैं

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

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

6. ग्राहक सहायता के साथ समय बिताएं

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

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

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

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