मेन्यू

क्यूए सॉफ्टवेयर परीक्षण जाँचकर्ता (नमूना जाँचकर्ता शामिल)

qa software testing checklists

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

सॉफ्टवेयर क्यूए परीक्षण जाँच सूची

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

परिभाषा: चेकलिस्ट उन वस्तुओं / कार्यों की एक सूची है जो ट्रैकिंग के लिए रिकॉर्ड किए जाते हैं। इस सूची को या तो अनुक्रम में क्रमबद्ध किया जा सकता है या बेतरतीब किया जा सकता है।

चेकलिस्ट हमारे दैनिक जीवन का एक हिस्सा और पार्सल हैं। हम उन्हें किराने की खरीदारी से लेकर दिन की गतिविधियों के लिए एक टू-डू सूची की विभिन्न स्थितियों में उपयोग करते हैं।

क्यूए सॉफ्टवेयर परीक्षण जाँच सूची

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

क्यूए सॉफ्टवेयर परीक्षण जाँचकर्ताओं का अवलोकन

जैसे ही हम कार्यालय में आते हैं, हम हमेशा उस दिन / सप्ताह के लिए चीजों की एक सूची बनाते हैं, जैसे नीचे:

जैसे ही और जब सूची में कोई आइटम किया जाता है, तो आप इसे बंद कर देते हैं, इसे सूची से हटा देते हैं या आइटम को एक टिक के साथ जांचते हैं - इसके पूरा होने को चिह्नित करने के लिए। क्या यह हम सब से परिचित नहीं है?

हालांकि, यह है कि यह सब के लिए इस्तेमाल किया जा सकता है?

कैसे एक नेटवर्क फ़ायरवॉल सेटअप करने के लिए

क्या हम औपचारिक रूप से (विशेष रूप से QA) अपनी आईटी परियोजनाओं में चेकलिस्ट का उपयोग कर सकते हैं और यदि हाँ, तो कब और कैसे? यह वही है जो नीचे कवर किया जाएगा।

मैं व्यक्तिगत रूप से निम्नलिखित कारणों से चेकलिस्ट के उपयोग की वकालत करता हूं:

  • यह बहुमुखी है - किसी भी चीज के लिए इस्तेमाल किया जा सकता है
  • बनाने / उपयोग / बनाए रखने में आसान
  • परिणामों का विश्लेषण (कार्य प्रगति / पूर्ण स्थिति) सुपर आसान है
  • बहुत लचीला - आप आवश्यकतानुसार आइटम जोड़ या हटा सकते हैं

जैसा कि सामान्य अभ्यास है हम 'क्यों' और 'कैसे' पहलुओं के बारे में बात करेंगे।

  • हमें चेकलिस्ट की आवश्यकता क्यों है? : ट्रैकिंग और पूर्णता (या गैर-पूर्ण) का आकलन करने के लिए। कार्यों को नोट करने के लिए, ताकि कुछ भी अनदेखा न हो।
  • हम चेकलिस्ट कैसे बनाते हैं? : खैर, यह सरल नहीं हो सकता है। बस, सब कुछ बिंदु से नीचे लिखें।

जाँचकर्ता QA प्रक्रियाओं के लिए उदाहरण:

जैसा कि मैंने ऊपर उल्लेख किया है, क्यूए क्षेत्र में कुछ क्षेत्र हैं जहां हम प्रभावी ढंग से काम करने और अच्छे परिणाम प्राप्त करने के लिए चेकलिस्ट अवधारणा डाल सकते हैं। आज हम जिन दो क्षेत्रों को देखेंगे उनमें से दो हैं:

  • टेस्ट तैयारी की समीक्षा
  • जब परीक्षण या निकास मापदंड चेकलिस्ट को रोकना है

(1) टेस्ट तैयारी की समीक्षा

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

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

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

अतिरिक्त जानकारी: टेस्ट तैयारी समीक्षा आम तौर पर बनाई जाती है और समीक्षा क्यूए टीम के प्रतिनिधि द्वारा की जाती है। परिणामों को पीएम और अन्य टीम के सदस्यों के साथ साझा किया जाता है ताकि यह पता लगाया जा सके कि परीक्षण टीम तैयार है या नहीं कि परीक्षण निष्पादन चरण में स्थानांतरित किया जाए या नहीं।

नीचे एक नमूना टेस्ट रेडीनेस रिव्यू चेकलिस्ट का उदाहरण दिया गया है:

टेस्ट रेडीनेस रिव्यू (TRR) मानदंड

स्थिति

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

अब, आप सभी को इस सूची के साथ क्या करना है या नहीं किया गया है।

# 2) मानदंड चेकलिस्ट से बाहर निकलें

जैसा कि नाम इंगित करता है, यह एक चेकलिस्ट है जो निर्णय लेने में सहायता करता है कि परीक्षण चरण / चक्र को रोका जाना चाहिए या जारी रखा जाना चाहिए।

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

मानदंड से बाहर निकलें

स्थिति

100% टेस्ट लिपियों को निष्पादित किया गया कर दी है
टेस्ट लिपियों का 95% पास दर
कोई खुला गंभीर और उच्च गंभीरता दोष नहीं
मध्यम गंभीरता के 95% दोष बंद हो गए हैं
शेष सभी दोष या तो रद्द कर दिए गए हैं या भविष्य के रिलीज़ के लिए परिवर्तन अनुरोध के रूप में प्रलेखित हैं
सभी अपेक्षित और वास्तविक परिणाम कैप्चर किए जाते हैं और परीक्षण स्क्रिप्ट के साथ प्रलेखित होते हैं कर दी है
सभी परीक्षण मैट्रिक्स से रिपोर्ट के आधार पर एकत्र किए जाते हैं एचपी एएलएम
सभी दोष एचपी एएलएम में लॉग इन हैं कर दी है
टेस्ट क्लोजर मेमो पूरा हो गया है और हस्ताक्षर किए गए हैं

जाँच सूची

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

जाँच सूची:

  1. सिस्टम और स्वीकृति टेस्ट बनाएँ ()
  2. स्वीकृति परीक्षण निर्माण शुरू करें ()
  3. टेस्ट टीम की पहचान करें ()
  4. वर्कप्लान बनाएँ ()
  5. परीक्षण दृष्टिकोण बनाएँ ()
  6. स्वीकृति परीक्षण का आधार बनाने के लिए स्वीकृति मानदंड और आवश्यकताएँ लिंक ()
  7. एक्सेपटेंस टेस्ट () की आवश्यकताओं के हिस्से को बनाने के लिए सिस्टम टेस्ट मामलों के सबसेट का उपयोग करें
  8. सिस्टम द्वारा आवश्यकताओं को पूरा करने के लिए ग्राहक द्वारा उपयोग के लिए स्क्रिप्ट बनाएं ()
  9. टेस्ट शेड्यूल बनाएं। लोगों और अन्य सभी संसाधनों को शामिल करें। ()
  10. आचरण परीक्षण ()
  11. सिस्टम टेस्ट निर्माण शुरू करें ()
  12. टेस्ट टीम के सदस्यों की पहचान करें ()
  13. वर्कप्लान बनाएँ ()
  14. संसाधन आवश्यकताएँ निर्धारित करें ()
  15. परीक्षण के लिए उत्पादकता उपकरणों की पहचान करें ()
  16. डेटा आवश्यकताएँ निर्धारित करें ()
  17. डेटा सेंटर के साथ एक समझौते पर पहुँचें ()
  18. परीक्षण दृष्टिकोण बनाएँ ()
  19. जिन भी सुविधाओं की आवश्यकता है उन्हें पहचानें ()
  20. मौजूदा परीक्षण सामग्री प्राप्त करें और उसकी समीक्षा करें ()
  21. परीक्षण वस्तुओं की एक सूची बनाएँ ()
  22. डिजाइन राज्यों, स्थितियों, प्रक्रियाओं और प्रक्रियाओं को पहचानें ()
  23. कोड-आधारित (सफेद बॉक्स) परीक्षण की आवश्यकता का निर्धारण करें। शर्तों को पहचानें। ()
  24. सभी कार्यात्मक आवश्यकताओं को पहचानें ()
  25. अंत सूची निर्माण ()
  26. टेस्ट केस निर्माण शुरू करें ()
  27. टेस्ट आइटम की सूची के आधार पर टेस्ट केस बनाएँ ()
  28. नई प्रणाली के लिए व्यावसायिक कार्य के तार्किक समूहों की पहचान करें ()
  29. आइटम इन्वेंट्री का परीक्षण करने के लिए किए गए कार्यात्मक मामलों में परीक्षण मामलों को विभाजित करें ()
  30. मामलों के परीक्षण के लिए डिज़ाइन डेटा सेट ()
  31. अंत टेस्ट केस निर्माण ()
  32. उपयोगकर्ताओं के साथ व्यावसायिक कार्यों, परीक्षण मामलों और डेटा सेटों की समीक्षा करें ()
  33. प्रोजेक्ट लीडर और QA () से टेस्ट डिज़ाइन पर साइनऑफ़ प्राप्त करें
  34. अंत परीक्षण डिजाइन ()
  35. टेस्ट की तैयारी शुरू करें ()
  36. परीक्षण सहायता संसाधन प्राप्त करें ()
  37. प्रत्येक परीक्षण मामले के लिए अपेक्षित परिणाम की रूपरेखा ()
  38. टेस्ट डेटा प्राप्त करें। परीक्षण के मामलों को वैध और ट्रेस करें ()
  39. प्रत्येक परीक्षण मामले के लिए विस्तृत टेस्ट लिपियों को तैयार करें ()
  40. पर्यावरण सेटअप प्रक्रियाओं को तैयार और दस्तावेज करें। बैक अप और रिकवरी प्लान शामिल करें ()
  41. अंतिम परीक्षण तैयारी चरण ()
  42. आचरण प्रणाली परीक्षण ()
  43. परीक्षा की लिपियों को निष्पादित करें ()
  44. अपेक्षित परिणाम की वास्तविक तुलना करें ()
  45. दस्तावेज़ संबंधी विसंगतियाँ और समस्या रिपोर्ट बनाएँ ()
  46. रखरखाव चरण इनपुट तैयार करें ()
  47. समस्या की मरम्मत के बाद परीक्षण समूह को फिर से निष्पादित करें ()
  48. एक अंतिम परीक्षण रिपोर्ट बनाएं, ज्ञात बग सूची शामिल करें ()
  49. औपचारिक पंजीकरण प्राप्त करें ()

ऑटोमेशन चेकलिस्ट

यदि आप इनमें से किसी भी प्रश्न का उत्तर देते हैं, तो स्वचालन के लिए आपके परीक्षण पर गंभीरता से विचार किया जाना चाहिए।

Q # 1) क्या क्रियाओं के परीक्षण क्रम को परिभाषित किया जा सकता है?

उत्तर: क्या क्रियाओं के अनुक्रम को कई बार दोहराना उपयोगी है? इसके उदाहरण स्वीकार्यता परीक्षण, संगतता परीक्षण, प्रदर्शन परीक्षण और प्रतिगमन परीक्षण होंगे।

Q # 2) क्या कार्यों के अनुक्रम को स्वचालित करना संभव है?

उत्तर: यह निर्धारित कर सकता है कि कार्रवाई के इस क्रम के लिए स्वचालन उपयुक्त नहीं है।

Q # 3) क्या परीक्षण को 'स्वचालित' करना संभव है?

उत्तर: परीक्षण के स्वचालित भागों से परीक्षण निष्पादन समय में तेजी आ सकती है।

Q # 4) क्या परीक्षण के तहत सॉफ्टवेयर का व्यवहार बिना स्वचालन के जैसा है?

उत्तर: यह प्रदर्शन परीक्षण के लिए एक महत्वपूर्ण चिंता का विषय है।

Q # 5) क्या आप प्रोग्राम के गैर-यूआई पहलुओं का परीक्षण कर रहे हैं? उत्तर: लगभग सभी गैर-UI फ़ंक्शन स्वचालित परीक्षण हो सकते हैं और होने चाहिए।

Q # 6) क्या आपको कई हार्डवेयर कॉन्फ़िगरेशन पर समान परीक्षण चलाने की आवश्यकता है?

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

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

सी ++ बाइनरी सर्च ट्री कार्यान्वयन

नोट करने के लिए अंक:

  • उपरोक्त दो उदाहरण हैं चेकलिस्ट के उपयोग को दिखाने के लिए क्यूए प्रक्रियाओं , लेकिन उपयोग इन दो क्षेत्रों तक सीमित नहीं है।
  • प्रत्येक सूची में आइटम भी पाठकों को एक विचार देने के लिए संकेतक हैं कि किस प्रकार की वस्तुओं को शामिल किया जा सकता है और उन्हें ट्रैक किया जा सकता है - हालांकि, सूची का विस्तार किया जा सकता है और / या आवश्यकतानुसार कॉम्पैक्ट किया जा सकता है।

हम वास्तव में आशा करते हैं कि उपरोक्त उदाहरण क्यूए और आईटी प्रक्रियाओं के लिए जाँचकर्ताओं की क्षमता को आगे लाने में सफल रहे हैं।

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

अनुशंसित पाठ

^