मेन्यू

संदर्भ संचालित परीक्षण: एक उदाहरण के साथ 7 मूल सिद्धांत

context driven testing

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

एक उदाहरण के साथ प्रसंग-चालित परीक्षण के 7 मूल सिद्धांत:

qa प्रबंधक साक्षात्कार प्रश्न उत्तर pdf

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

लेकिन, इस पर विचार करें।

क्या होगा अगर मैं गैस पर कम था?

क्या होगा अगर मैं नकदी पर कम था?

मैं अलग विकल्प चुनूंगा। क्यों? प्रसंग।

संदर्भ-चालित परीक्षण क्या है

(छवि श्रेय )

जब आप निर्णय लेते हैं, तो यह एक संदर्भ-चालित निर्णय होता है:

  • शामिल लोग
  • परिस्थिति
  • लक्ष्य
  • उपलब्ध विकल्प
  • भावनाएँ आदि।

तो, संदर्भ-चालित परीक्षण क्या है?

कॉनटेक्स्ट ड्रिव टेस्टिंग एक मानसिकता बदलाव (या स्कूल ऑफ टेस्टिंग) है जिसे Cem Kaner, James Bach & Bret Pettichord द्वारा विकसित किया गया है। इसके बारे में विवरण उनकी प्रसिद्ध पुस्तक में पाया जा सकता है: सॉफ्टवेयर टेस्टिंग में सबक सीखा ।

इसके 7 मूल सिद्धांत हैं। निम्नलिखित सीधे उनकी पुस्तक से उठाए गए हैं:

# 1) किसी भी अभ्यास का मूल्य उसके संदर्भ पर निर्भर करता है।

#दो) संदर्भ में अच्छी प्रथाएं हैं, लेकिन सर्वोत्तम प्रथाएं नहीं हैं।

# 3) लोग, जो एक साथ काम कर रहे हैं, किसी भी परियोजना के संदर्भ का सबसे महत्वपूर्ण हिस्सा हैं।

# 4) परियोजनाएं उन तरीकों से समय के साथ प्रकट होती हैं जो अक्सर अनुमानित नहीं होती हैं।

# 5) उत्पाद एक समाधान है। यदि समस्या हल नहीं हुई है, तो उत्पाद काम नहीं करता है।

# 6) अच्छा सॉफ्टवेयर परीक्षण एक चुनौतीपूर्ण बौद्धिक प्रक्रिया है।

# 7) पूरे प्रोजेक्ट के दौरान केवल निर्णय और कौशल के माध्यम से, सहकारी रूप से अभ्यास किया जाता है, क्या हम अपने उत्पादों का प्रभावी ढंग से परीक्षण करने के लिए सही समय पर सही काम करने में सक्षम हैं।

मैं उनमें से हर एक को समझाने नहीं जा रहा हूं क्योंकि यह हमारे लिए किया गया है विशेषज्ञों ने खुद यहां ।

मैं बस अपने प्रसंग पर एक परिदृश्य आधारित व्याख्या करने जा रहा हूँ जो कि प्रसंग-परीक्षण पर आधारित है।

प्रसंग प्रेरित परीक्षण का एक उदाहरण:

आइए हम कहते हैं कि मैं एक परीक्षण परियोजना शुरू कर रहा हूं - प्रोजेक्ट ए जिसमें वेब आधारित एप्लिकेशन के लिए एंड-टू-एंड परीक्षण शामिल है।

मेरी रणनीति क्या होगी?

मानक प्रक्रियाओं के अनुसार, यह घटनाओं का क्रम होगा:

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

अगर मैं अपने आप से सवाल पूछूं, 'मैंने यह कैसे तय किया कि मुझे क्या करने की आवश्यकता है?' मेरा जवाब होगा, सर्वोत्तम अभ्यास, क्यूए मानक, उद्योग दिशानिर्देश, पिछले अनुभव आधारभूत, आदि, सही?

मैं वही दोहरा रहा हूं जो मुझे करना सिखाया गया था या जो मैंने दूसरों को करते देखा है।

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

संदिग्ध। क्यों?

क्योंकि हर परियोजना के साथ आप विभिन्न परिस्थितियों से निपटने जा रहे हैं:

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

यह सूची संपूर्ण नहीं है और आप जानते हैं कि मैं ऐसा करता हूं कि प्रत्येक परियोजना के कई चर हैं।

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

अब, आइए ये बताएं कि मैं प्रोजेक्ट ए के लिए किसके साथ काम कर रहा हूं:

  • मैं 5- 4 नए लोगों और 1 अनुभवी परीक्षक की टीम के साथ काम कर रहा हूं।
  • मेरी कोई दस्तावेजी आवश्यकताएं नहीं हैं।
  • मेरी टीम भारत में है और विकास टीम अमेरिका में है, इसलिए हम समय क्षेत्र के विपरीत काम करते हैं।
  • ग्राहक एक दैनिक विस्तृत स्थिति रिपोर्ट चाहता है
  • हम एक वेब आधारित बग ट्रैकिंग टूल का उपयोग करते हैं, जैसे कि मंटिस या बुगज़िला और जो हमारे पास है।
  • मुझे परीक्षण प्रलेखन के लिए 3 दिनों के साथ 10 दिनों में परीक्षण के 2 राउंड करने हैं

यहाँ एक मोटा गेम प्लान है:

1) चूंकि बहुत से नए लोग टीम में हैं, इसलिए हमें बहुत सारी सहकर्मी समीक्षाओं की आवश्यकता है।

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

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

4) परीक्षण निष्पादन के दौरान दैनिक स्थिति रिपोर्ट हर दिन ईओडी बनाई और भेजी जा रही है।

5) अधिकांश परीक्षण खोजपूर्ण हैं, इसलिए निष्पादित किए गए प्रत्येक परीक्षण की एक संक्षिप्त रूपरेखा बनाने की कोशिश करने के लिए समय की सलाह दें। इस तरह हम जानते हैं कि परीक्षण क्या है और क्या नहीं है।

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

और इसी तरह।

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

sdlc के चरण क्या हैं

संक्षेप में:

ये है प्रसंग-चालित परीक्षण; आपकी परिस्थितियों (मानकों को नहीं) को प्राथमिक परीक्षण और आपकी परीक्षण रणनीति के लिए प्रभावित करने वाले। यह हमें चारों ओर देखने और अपने आसपास की सभी चीजों को ध्यान में रखने का आग्रह करता है।

व्यक्तिगत रूप से, मुझे इस अवधारणा से प्यार है क्योंकि बहुत बार परीक्षण प्रथाओं को कठोर और नकली-आधारित माना जाता है। किसी ने इसे किया और सफलतापूर्वक किया गया था, इसलिए मैं इसे भी करने जा रहा हूं। यह एक ऐसी छवि है जो लोगों को परीक्षण करियर में प्रयास करने और रहने से डराती है।

लेकिन, रचनात्मक सोच, विश्लेषणात्मक कौशल और निर्णय लेने की बहुत गुंजाइश है। अधिक जानने के लिए, ऊपर दिए गए लिंक में विषय पर पढ़ें-अप करें।

खुश संदर्भ-संचालित-परीक्षण

अनुशंसित पाठ

^