मेन्यू

सॉफ्टवेयर परीक्षकों से ग्राहक क्या अपेक्षा करते हैं?

what do clients really expect from software testers

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

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

आईटी सेवाएं सॉफ्टवेयर उद्योग का एक महत्वपूर्ण और अभिन्न अंग हैं और सफल होने के लिए ग्राहकों की संतुष्टि महत्वपूर्ण है। प्रत्येक ग्राहक / संगठन अपनी प्रक्रिया में भिन्न हो सकते हैं, विभिन्न प्रोटोकॉल का पालन कर सकते हैं और विभिन्न प्रकार के व्यवसायों से निपट सकते हैं।

लेकिन, निम्नलिखित कारक सामान्य हैं और सामान्य रूप से सभी के लिए मायने रखते हैं।

सॉफ्टवेयर परीक्षण ग्राहकों

(छवि src )

आप क्या सीखेंगे:

5 चीजें जो क्लाइंट सॉफ्टवेयर टेस्टर से अपेक्षा करती हैं:

ग्राहक की अपेक्षा 1

(1) लागत लाभ

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

कंपनियां और ग्राहक अलग नहीं हैं। लागत लाभ ग्राहक-सेवा संबंधों को बढ़ावा देते हैं और सेवा कंपनियों के लिए प्रतिस्पर्धी बोली कम होने के कारण बोलियां खोना असामान्य नहीं है।

लागत पर लाभ

BIG सवाल अब यह है: हम अपने ग्राहकों को लागत लाभ कैसे दिखा सकते हैं?

ये बिंदु मदद कर सकते हैं:

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

# 2) कार्य की गुणवत्ता

काम की गुणवत्ता और मात्रा दो बहुत अलग चीजें हैं।

वे दिन गए जब उत्पादकता या गुणवत्ता संकेतकों के लिए उपयोग किए गए परीक्षण मामलों की संख्या बनाई गई या दोषों की सूचना दी गई। अब और नहीं।

स्थिति नीचे की छवि की तरह है:

काम की गुणवत्ता

कार्य की गुणवत्ता २

A) पता है कि कब say नहीं ’कहना है

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

ऐसा करते समय, अपनी चिंता को पहले से बढ़ाएं और गुणवत्ता की वकालत करें।

यहाँ एक स्थिति है जो मैं था और यह आपको एक बेहतर विचार दे सकता है कि मैं किस बारे में बात कर रहा हूँ:

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

मैं नॉलेज ट्रांजिशन लीड में गया और उसे स्थिति बताई -

  • बहुत से कार्य आइटम मुझे सौंपे गए थे, जो बदले में गुणवत्ता और सत्रों में 100% पर कब्जा करने की मेरी क्षमता को बाधित करेंगे।
  • नियोजित वस्तुओं में वे क्षेत्र होते हैं जहाँ मेरे कौशल मेल नहीं खाते हैं और चूंकि मैं सही फिट नहीं हूँ, इसलिए मैं संक्रमण के दौरान 100% नहीं समझ सकता।

नेतृत्व समस्या को समझा और केटी योजना को संशोधित किया।

यूनिक्स अनुभवी के लिए साक्षात्कार प्रश्न और उत्तर देता है

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

बी) टेस्ट केस कम्पलीटनेस

आप में से कितने लोग मुझसे सहमत हैं कि अगर हम कोशिश करते हैं हम परीक्षण मामलों को लिखने के तरीके में सुधार करें , यह बेहतर गुणवत्ता की ओर जाता है?

नीचे कुछ सामान्य गलतियाँ हैं जो अधिकांश परीक्षण मामलों में सामान्य हैं:

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

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

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

उदाहरण के लिए: उपयोगकर्ता पंजीकरण उपयोगकर्ता अन्ना या जॉन को पंजीकृत कर सकता है और इससे कोई फर्क नहीं पड़ेगा। लेकिन यह परिभाषित करना कि एक वैध नाम जिसमें सभी वर्ण हैं और लंबाई 4-10 होनी चाहिए, बहुत सारी चीजों को स्पष्ट करने में मदद कर सकता है।
टेस्ट केस आईडी सरलीकृत नामकरण या संख्या सम्मेलन में। कहते हैं, आप एक लॉगिन बटन का परीक्षण कर रहे हैं। अक्सर, आईडी हैं:
TC_1_Login
TC_2_Login		उन्हें अधिक वर्णनात्मक बनाएं:
TC_1_Login_Invalid_User
TC_2_Login_Valid_User
संदर्भ दस्तावेजों असंगत कॉपी-पेस्ट संदर्भ दस्तावेजों से या इससे भी बदतर, एक गलत एक का उपयोग कर।हमेशा सही संस्करण संख्या के साथ सही संदर्भ दस्तावेज़ का उल्लेख करना उचित है, कुछ परीक्षण मामलों के लिए एफआरएस और टेक स्पेक्स दोनों को संदर्भित किया गया होगा, इसलिए संदर्भ अनुभाग में परीक्षण मामले में दोनों का उल्लेख करना चाहिए।
टेस्ट केस स्टेप्स गुम कदम, ज्यादातर परीक्षकों द्वारा जो आवेदन को अच्छी तरह से जानते हैं। वे चीजों को मान सकते हैं और चरणों का उल्लेख करना छोड़ सकते हैं। इससे व्यवसाय, समीक्षकों और नए परीक्षकों को समस्या होती है।उचित कदम और अनुक्रम का उपयोग किया जाना चाहिए।

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

# 3) बिजनेस अंडरस्टैंडिंग

यह सबसे महत्वपूर्ण कारकों में से एक है जो ग्राहक परीक्षकों में देखते हैं। हालांकि, यह दुखद है कि कुछ परीक्षकों का मानना ​​है कि उनका काम एफआरएस के आधार पर परीक्षण मामलों को लिखना है और व्यवसाय को समझने का कोई प्रयास नहीं करना है।

पहले व्यापार को जानने की कोशिश करें और फिर कार्यक्षमता में देखें; आप ऐसा कर सकते हैं अपने ग्राहक की जरूरतों की कल्पना करें अधिक और तदनुसार परीक्षण।

यहाँ एक उदाहरण है- FRS बताता है कि Z XYZ रिपोर्ट को दिनांक, नाम और स्थिति के रूप में 3 कॉलम के साथ जनरेट किया जाना चाहिए ’। जब आप इस आवश्यकता को अपने अंकित मूल्य पर लेते हैं तो निम्नलिखित परीक्षण मामले सामने आएंगे:

  • मान्य रिपोर्ट XYZ उत्पन्न होती है
  • मान्य रिपोर्ट में दिनांक, नाम, स्थिति के रूप में 3 कॉलम हैं
  • डेटा को 3 कॉलम में सत्यापित करें।

लेकिन, जब आप इस रिपोर्ट की व्यावसायिक प्रयोज्यता को ध्यान में रखते हैं, तो आपको परीक्षण करना पड़ सकता है:

  • इस रिपोर्ट का व्यावसायिक उद्देश्य क्या है?
  • क्या यह रिपोर्ट हर दिन उत्पन्न होती है?
  • इस रिपोर्ट को देखने वाले व्यावसायिक उपयोगकर्ता कौन हैं?
  • इस रिपोर्ट के लिए डेटा का स्रोत क्या है?
  • यदि कोई डेटा उपलब्ध नहीं है, तो रिपोर्ट तैयार की जानी चाहिए?

यह सिर्फ एक उदाहरण है, लेकिन मुझे लगता है कि हम सभी सहमत हैं कि व्यावसायिक जागरूकता और विशेषज्ञता प्राप्त करके बेहतर परीक्षण प्राप्त किया जा सकता है।

# 4) उपलब्धता

चाहे आप ग्राहक या टीम का समर्थन करने वाले एकल व्यक्ति हों, आपकी उपलब्धता की हमेशा जाँच होनी चाहिए ( सुधार का दायरा) का है।

उपलब्धता से, इसका मतलब 24/7 समर्थन नहीं है। इसका मतलब है समय के बारे में स्पष्ट और अग्रिम संचार, वैकल्पिक योजनाएं और उपलब्ध होना और MIA नहीं जाना।

नीचे कुछ मॉडल दिए गए हैं जो सेवा उद्योग द्वारा अनुसरण किए जाते हैं:

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

# 5) सुधार की गुंजाइश

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

यह भी पढ़ें=> कैसे अपने परीक्षण कौशल में सुधार और प्रतियोगिता को हराया

चरण # 1: पहचानें

गहन अध्ययन करें और सुधार के लिए क्षेत्रों / दायरे की पहचान करें। कहते हैं, जब आपको एक ही प्रक्रिया का उपयोग करके कई बार एक ही कार्यक्षमता का परीक्षण करने के लिए कहा जाता है, तो एक समय आएगा जब आपको लगेगा कि आप या तो परियोजना से बाहर जाना चाहते हैं या आप जिस तरह से परीक्षण किया गया है उसे बदल देते हैं। जब हम अपने मौजूदा तरीकों से ऊब गए हैं तो सुधार कैसे लाया जाता है; हम बदलने और सुधार करने के बारे में सोचते हैं ।

चरण 2: सुधार में लाओ

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

मैं एक स्थिति उद्धृत करूंगा:

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

चरण 3: सुधार का मूल्यांकन करें

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

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

सबसे अच्छा ईमेल प्रदाता क्या है

निष्कर्ष

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

लेखक के बारे में: यह भयानक लेख STH टीम की सदस्य प्रिया आर द्वारा लिखा गया है। यदि आप हमारे लिए लिखना चाहते हैं और कृपया अपना अनुभव साझा करें हमें यहां बताएं ।

आशा है कि आप इस लेख को पढ़ने का आनंद लेंगे और इसे जानकारीपूर्ण पाएंगे! अगर आपको साझा करने का एक अलग अनुभव है तो हमें बताएं।

अनुशंसित पाठ

^