ऑटोमेशन का स्वीकृति परीक्षण कैसे तैयार करें?

काम करने का दावा साझा मानदंड मांगता है

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

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

प्रतिनिधि डेटा चुनें

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

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

अपेक्षित परिणाम लिखें

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

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

त्रुटियां और रुकावटें शामिल करें

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

बहाली की योजना भी ठोस हो। गलत आउटपुट बने तो मूल डेटा सुरक्षित है? पिछला परिणाम संग्रहित हो सकता है? कौन से चरण वापस हो सकते हैं? अपरिवर्तनीय कार्रवाई को स्वचालित करने से पहले मानव मंजूरी या अलग जांच-बिंदु रखें। परीक्षण रिकॉर्ड स्पष्ट रूप से उदाहरण चिह्नित हों। असली ग्राहकों को प्रयोग के संदेश भेजना या वास्तविक भुगतान शुरू करना परीक्षण का उचित छोटा रास्ता नहीं है।

अधिकार और उपयोगकर्ता का रास्ता साथ जांचें

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

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

डिलीवरी रिपोर्ट को निर्णय का आधार बनाएं

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

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

ध्यान दें: प्रदर्शन और स्वीकृति अलग हैं

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

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

अक्सर पूछे जाने वाले सवाल

पहला कदम क्या है?

एक वास्तविक काम और प्रतिनिधि उदाहरण चुनें, फिर अपेक्षित परिणाम स्पष्ट करें।

जांच कौन करे?

प्रक्रिया का जिम्मेदार व्यक्ति और ऐप इस्तेमाल करने वाला कर्मचारी मिलकर जांच करें।

अपडेट कब करें?

प्रक्रिया या ऐप बदलने पर प्रभावित चरणों की दोबारा जांच करें।