देवों, परीक्षकों और व्यावसायिक उपयोगकर्ताओं के पास एक एकीकृत परीक्षण स्क्रिप्ट होनी चाहिए?

11

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

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

क्या यह शुरू से परीक्षण स्क्रिप्ट को मजबूत करने के लायक है? इस प्रकार एक एकीकृत परीक्षण स्क्रिप्ट का उपयोग करना, या क्या इस अपफ्रंट को करना मुश्किल है?

testing test-management

— कार्लोस जैमे सी। डी। लियोन
स्रोत

19

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

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

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

संपादित करें: QA का मूल प्रश्न संदर्भ हटा दिया गया है, इसलिए यह उत्तर अब OT दिखाई देता है।

— mattnz
स्रोत

2

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

— दाऊद इब्न करीम

"क्यूए टेस्ट नहीं है"। मैं इसे पर्याप्त रूप से वोट नहीं दे सकता।

— बर्नहार्ड हॉफमैन

2

हम शुरू से ही यूएटी का उपयोग करते हैं।

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

शुरुआत से यूएटी करने का एक अतिरिक्त लाभ भी है। यह वास्तव में ग्राहक की उम्मीदों और अपने स्वयं के बीच किसी भी अस्पष्टता को साफ करता है।

— Permas
स्रोत

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

— कार्लोस जैमे सी। डी। लियोन

@ CarlosJaimeC.DeLeon, हाँ, यह व्यापार उपयोगकर्ता से आता है। हम पाते हैं कि यह अच्छी तरह से काम करता है क्योंकि अधिकांश ग्राहकों को इस बात का फ़र्ज़ी अंदाज़ा होता है कि वे क्या चाहते हैं और इससे उन्हें बाहर निकलने के साथ-साथ देवों और परीक्षकों के लिए एक मार्गदर्शिका प्रदान करने में मदद मिलती है। इसके अलावा, जब हमने यूएटी के अनुसार कहा, तो वे अधिक समझ रखते हैं जब हम समय मांगते हैं यदि वे बदलाव चाहते हैं: पी

— पर्मास

1

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

— HLGEM
स्रोत

1

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

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

— के 3 बी
स्रोत

1

संपूर्ण विश्व में देवों के पास इकाई परीक्षण (xUnit), परीक्षक - स्वचालित एकीकरण परीक्षण (सेलेनियम) और व्यावसायिक उपयोगकर्ता - स्वीकृति परीक्षण (FIT) होने चाहिए। वे एक दूसरे के परीक्षण के लिए उपयोग कर सकते हैं।

— निकोले फ़ोमिनाह
स्रोत

1

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

— ASG
स्रोत