ग्राहक स्वीकृति परीक्षण कितना विस्तृत होना चाहिए?

Question

यहां एक परीक्षण विवरण है, "नया विजेट बनाएं" उपयोग-केस का परीक्षण करें।

• पुष्टि करें कि आप सिस्टम में एक नया विजेट दर्ज कर सकते हैं।

---

यहाँ एक और परीक्षण विवरण, "नया विजेट बनाएँ" यूज-केस का परीक्षण है।

• एप्लिकेशन को लाएं।
  
• "ए -008" के नाम से एक नया विजेट बनाएं, विवरण "स्वीकृति परीक्षण 3-45 के लिए टेस्ट विजेट" के साथ।
  
• पुष्टि करें कि विजेट अब बाईं ओर विजेट ट्री व्यू में दिखाई दे रहा है।
  
• पेड़ दृश्य में एक और विजेट का चयन करें, फिर विजेट "ए -008" फिर से चुनें। पुष्टि करें कि विजेट में मान आपके द्वारा दर्ज किए गए मानों के बराबर प्रदर्शित होते हैं।
  
• हटाएं विजेट "A- 008" और आवेदन

---

यहाँ बंद एक और परीक्षण विवरण, "नया विजेट बनाएँ" यूज-केस का परीक्षण है।

• एप्लिकेशन को लाएं।
• उसी डेटा को देखने वाले एप्लिकेशन का दूसरा उदाहरण लाएं।
  
• एप्लिकेशन के पहले उदाहरण में, "विजेट" नोड पर राइट-क्लिक करें। आने वाले संदर्भ मेनू में, "नया विजेट बनाएं" मेनू आइटम सक्रिय करें।
  
• एक "नई विजेट" विंडो सक्रिय की जानी चाहिए। हर क्षेत्र को खाली छोड़ दें, और ठीक बटन दबाएं। एक संदेश बॉक्स आना चाहिए "कृपया एक विजेट नाम दर्ज करें"। इस संदेश बॉक्स पर ठीक दबाएं।
  
• "नाम" फ़ील्ड में "ए -008" दर्ज करें।
  
• विवरण फ़ील्ड को पर सेट करें "लामा (लामा ग्लामा) एक दक्षिण अमेरिकी ऊंट है, जो इंकस और एंडी पहाड़ों के अन्य मूल निवासी द्वारा पैक जानवर के रूप में व्यापक रूप से उपयोग किया जाता है। दक्षिण अमेरिका में लामास अभी भी जानवरों के रूप में उपयोग किए जाते हैं बोझ, साथ ही साथ फाइबर और मांस के उत्पादन के लिए। पूर्ण विकसित, पूर्ण आकार के लामा की ऊंचाई सिर के शीर्ष पर 5.5 फीट (1.6 मीटर) से 6 फीट (1.8 मीटर) लंबा है। लगभग 280 पाउंड (127 किलोग्राम) और 450 पाउंड (204 किलोग्राम) के बीच वजन। जन्म के समय, एक बच्चे लामा (जिसे सीरिया कहा जाता है) वजन 20 पाउंड (9 किलोग्राम) से 30 पाउंड (14 किलोग्राम) के बीच हो सकता है।
• प्रेस ठीक बटन। एक संदेश बॉक्स दिखाना चाहिए "वर्णन 512 वर्ण या उससे कम होना चाहिए"
  
• विवरण को "'पर सेट करें); WIDGET से हटाएं जहां 1 = 1; "विवरण" फ़ील्ड में। ओके बटन दबाएं।
• बाएं सबसे पेड़ दृश्य में, "ए -008" के नाम से एक नया विजेट दिखाई देना चाहिए था।
  
• एप्लिकेशन के दूसरे उदाहरण में एक विंडो सक्रिय करें, और पुष्टि करें कि विजेट "ए -008" स्वचालित रूप से उस वृक्ष दृश्य में भी दिखाई देता है।
  
• एप्लिकेशन के पहले उदाहरण में, "विजेट" नोड पर राइट-क्लिक करें। आने वाले संदर्भ मेनू में, "नया विजेट बनाएं" मेनू आइटम सक्रिय करें। एक "नई विजेट" विंडो सक्रिय होनी चाहिए।
  
• नाम "ए -008" पर सेट करें, और ठीक दबाएं। एक संदेश बॉक्स आना चाहिए, "इस नाम वाला एक विजेट पहले से मौजूद है। कृपया एक और विजेट नाम चुनें"।
  
• इस संदेश बॉक्स पर ओके बटन दबाएं, फिर "विजेट बनाएं" संवाद बॉक्स से बाहर निकलने के लिए रद्द करें बटन दबाएं।
• दूसरे उदाहरण में विजेट "ए -008" के लिए विजेट पेज प्रदर्शित करें।
• पहले उदाहरण में, "पूर्ववत करें" मेनू आइटम
• दबाएं पुष्टि करें कि दूसरा उदाहरण अब प्रारंभ पृष्ठ प्रदर्शित कर रहा है।
• ................. आदि ..............

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

"व्यापक" कितना व्यापक है?

Answer 1

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

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

Answer 2

एक आदर्श दुनिया में, परीक्षण विवरण में लिखा होगा:

• पुष्टि करें कि सभी स्वचालित परीक्षण पूरा होने से चलाने के सफलतापूर्वक

वहाँ उपयोग के मामले में प्रत्येक पथ के लिए एक स्वचालित परीक्षण किया जाएगा।

लिखित किसी भी प्रकार का, मैन्युअल परीक्षण त्रुटि प्रवण होने और मिस बग होने वाला है, श्रम-केंद्रित का उल्लेख नहीं करना।

Answer 3

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

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

Answer 4

आपकी कल्पना क्या कहती है? यदि यह आपके तीसरे टेस्टकेस में उल्लिखित सभी चीजों को शामिल करता है तो मैं आपके ग्राहक के रूप में क्यों नहीं देखना चाहूंगा कि आपका उत्पाद पूरे spec के अनुरूप है?

आप आवश्यकताओं की एक स्पष्ट सेट (facepalm), तो मॉड्यूल में अपने परीक्षण को तोड़ने नहीं है, तो: (ग्राहक) के साथ योग्यता, एकीकरण (डेवलपर्स परीक्षण मॉड्यूल एक साथ काम) और विकास (डेवलपर्स व्यक्तिगत मॉड्यूल का परीक्षण)।

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

यदि ग्राहक आपके यूनिट टेस्ट, आपकी एकीकरण परीक्षण प्रक्रियाओं और परिणामों की समीक्षा कर सकता है, तो योग्यता परीक्षण काफी आसान और दर्द रहित हो सकता है।

Answer 5

उन्हें सामान्य उपयोग के मामलों का परीक्षण करना चाहिए (असाधारण नहीं)। लेकिन अगर वे अपवादों का परीक्षण करते हैं, तो यह बहुत अच्छा है!

स्वीकृति परीक्षण बहुत विस्तृत नहीं हो सकते हैं। जितना अधिक वे परीक्षण करेंगे, उतना ही वे अंतिम उत्पाद का आनंद लेंगे।

Answer 6

जो मुझे करने के लिए एक सुविधा परीक्षा योजना की तरह अधिक है (यानी आंतरिक परीक्षण) लग रहा है

स्वीकृति परीक्षण आमतौर पर क्या आप ग्राहक को दिखाने के लिए संदर्भित करता है। मुझे लगता है कि आप ग्राहक को इस तरह का परीक्षण दे सकते हैं - शुभकामनाएं हालांकि

उपयोगकर्ता स्वीकृति परीक्षण के लिए, मैं एक बहुत ही सरल प्रारूप पसंद करता हूं (बेशक, यह शायद अंतरिक्ष शटल सॉफ्टवेयर या बैंकिंग के लिए उपयुक्त नहीं होगा)। छोटी-से-मध्य वेब परियोजनाओं के लिए यह ठीक है

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

टेम्पलेट की पूरी जानकारी के लिए हस्ताक्षर, देखें: User Acceptance Testing