मॉड्यूल 7 · Test design techniques

चेकलिस्ट-बेस्ड टेस्टिंग

Mutqan Soft QA टीम द्वारा · · 18 मिनट · मध्यम

Checklist-based testing एक experience-based test technique है: आप checklist के items को cover करने के लिए tests design, implement और execute करते हैं। हर item किसी जाँचने लायक चीज़ का नाम है — कोई requirement, interface की कोई property, कोई quality characteristic या कोई जानी-पहचानी कमज़ोर जगह — और tester तय करता है कि उसे कैसे जाँचना है। उदाहरण के लिए, कोई web form checklist पूछ सकती है "क्या user के submit करने से पहले हर required field marked है?"; नए sign-up form पर tester इस item को कुछ quick checks में बदलता है।

Error guessing वाले lesson में आपने अनुभव से खास failures का अंदाज़ा लगाकर उन पर attack किया था। Checklist अनुभव को agreed test conditions में बदलती है: review की हुई, shared list, जिसके points हर tester cover करता है, चाहे टेस्ट कोई भी करे।

यह क्यों ज़रूरी है

कई changes बिना detailed test cases के टेस्ट होते हैं: specification अधूरी है, change छोटा है या समय कम है। बिना किसी structure के result इस पर निर्भर करता है कि कौन टेस्ट कर रहा है और उसे क्या याद है, और जानी-पहचानी problems फिर से निकल जाती हैं। Checklist ऐसी testing को एक न्यूनतम स्तर और testers के बीच कुछ consistency देती है।

यह एक record भी है: "Scope में 26 items, 24 pass, 2 fail" team को बताता है कि क्या cover हुआ, जो "मैंने form टेस्ट कर लिया" कभी नहीं बताता। क्योंकि list असली defects से बढ़ती है, यह team के सबक नए साथियों तक पहुँचाती है।

Checklist को test basis की तरह इस्तेमाल करना

ISTQB Foundation syllabus v4.0 checklist-based testing को error guessing और exploratory testing के साथ experience-based techniques में रखता है। जब आप checklist से टेस्ट करते हैं, तो वह आपका test basis बनती है: हर item एक test condition है, और आपके tests उन conditions को cover करने के लिए हैं।

Detail का स्तर technique का व्यवहार बदल देता है। "क्या error messages मददगार हैं?" जैसा high-level item judgement की जगह छोड़ता है: दो testers अलग-अलग चीज़ें करेंगे, जिससे coverage बढ़ सकता है लेकिन testing कम repeatable होती है। Detailed item लगभग एक छोटे test case जैसा होता है। Items अनुभव से, users के लिए जो मायने रखता है उससे, और software कैसे fail होता है इसकी जानकारी से बनते हैं:

  • Defect history — ऐसी problems जो users तक पहुँचीं या जिन्हें ठीक करना महँगा पड़ा।
  • Published heuristics और standards — Jakob Nielsen की 10 usability heuristics usability के लिए एक जानी-मानी high-level checklist हैं; accessibility checklists अक्सर WCAG 2.2 के success criteria से बनाई जाती हैं।
  • Team conventions — supported browsers और languages, date और number formats।
  • Quality characteristics — security, performance और compatibility जैसी non-functional testing के लिए याद दिलाने वाले points।

अच्छे checklist items लिखना

Tester को हर item अलग से और सीधे जाँचकर साफ़ result दर्ज कर पाना चाहिए, इसलिए कई teams items को सवालों के रूप में लिखती हैं जिनमें "हाँ" का मतलब pass है। Syllabus यह भी बताता है कि उसमें क्या नहीं होना चाहिए: ऐसे items जो automatically जाँचे जा सकते हैं, ऐसे items जो entry या exit criteria के रूप में बेहतर हैं, और बहुत general items।

  • हर item में एक condition। "Errors दिखते हैं और translated हैं" दो items हैं; अगर सिर्फ़ translation गलत है, तो एक tick यह नहीं बता सकता। कई inputs एक ही condition को टेस्ट कर सकते हैं, जैसे नीचे FRM-07 में; लेकिन दो अलग expected results एक item में नहीं होने चाहिए।
  • Observable और specific। "Form validation काम करता है, यह check करें" कोई दिखने वाला result नहीं बताता; "Submit reject होने के बाद, क्या form password को छोड़कर user का लिखा सब कुछ रखता है?" बताता है।
  • Scoped। बताएँ कि item कहाँ लागू होता है, जैसे हर form, ताकि tester जाने कि "not applicable" कब दर्ज करना है।
  • Tool से जाँचने लायक नहीं। अगर कोई linter (ऐसा program जो code को तय rules पर जाँचता है) या automated test इसे जाँच सकता है, तो इसे tool पर छोड़ें, manual list में न रखें।
  • Criterion नहीं। "Build test environment पर deploy हो गया" एक entry criterion है और उसकी जगह test plan में है।
  • Traceable। हर item को एक id दें और अगर वह किसी defect से आया है तो उस defect की id भी — FRM-07 में DEF-1184 लिखा है — ताकि बाद में पढ़ने वाले जानें कि वह क्यों है।
कमज़ोर item Check that form validation works को FRM-07 के रूप में दोबारा लिखा गया: एक id, एक scope, एक setup, हाँ-या-ना वाला observable check, और वह defect जिससे item आया।

कमज़ोर item

Check that भाग 2:form भाग 4:validation works.

उसकी जगह लिखा गया एक item

भाग 1:FRM-07 भाग 2:[All forms] भाग 3:Required field left empty, then Submit: भाग 4:is an error shown next to that field, naming it? भाग 5:Source: DEF-1184

  1. 1IdResults, defect reports और list के बाद के versions ठीक इसी item की ओर इशारा कर पाते हैं।कमज़ोर item में नहीं
  2. 2ScopeItem कहाँ लागू होता है, ताकि tester जाने कि "not applicable" कब दर्ज करना है। सिर्फ़ form से पता नहीं चलता कि कौन-से forms।
  3. 3Setup: एक conditionवह एक स्थिति जो tester बनाता है। Validation में कई rules आते हैं; यह item सिर्फ़ एक cover करता है।कमज़ोर item में नहीं
  4. 4Check: हाँ-या-ना वाला सवालऐसा कुछ जो tester देख सके; "हाँ" का मतलब pass। works किसी ऐसे result का नाम नहीं लेता जिसे देखा जा सके।
  5. 5Sourceवह defect जिससे item आया: वह क्यों है, और उसे हटाने से पहले क्या देखना है।कमज़ोर item में नहीं

Worked example: checklist से sign-up form टेस्ट करना

एक team के पास web forms की checklist है, जो अब version 7 पर है। नया sign-up form नाम, mobile number, email और password माँगता है, साथ में terms स्वीकार करने का एक box। Checklist feature के अपने tests की जगह नहीं लेती: password rule, 12 से 64 characters, के लिए अब भी boundary value analysis चाहिए।

Build 2.14.0 पर tester तय करता है कि कौन-से items लागू हैं, हर item को कुछ quick checks से cover करता है और result दर्ज करता है:

  • FRM-02 क्या user के submit करने से पहले हर required field marked है? Pass।
  • FRM-05 क्या name fields Arabic और Latin letters, spaces और hyphens स्वीकार करते हैं? Fail: Arabic letters में लिखा नाम reject हुआ; DEF-1302 में exact input दर्ज है।
  • FRM-07 Required field खाली छोड़कर Submit: क्या उसी field के पास उसका नाम लेते हुए error दिखता है? Pass, पाँच quick tests के बाद, हर required field के लिए एक, terms box समेत।
  • FRM-09 Submit reject होने के बाद, क्या password को छोड़कर लिखा हुआ सब कुछ बना रहता है? Fail: जब email पहले से registered था, form ने mobile number भी मिटा दिया; DEF-1303।
  • FRM-16 क्या हर upload की size limit साफ़ message के साथ लागू होती है? Not applicable: कोई upload field नहीं है। N/A दर्ज करना दिखाता है कि item पर विचार किया गया, उसे भुलाया नहीं गया।

आज़माएँ: वैलिडेशन टेस्ट जनरेटर आज़माएँ: नेगेटिव टेस्ट जनरेटर

Checklist को up to date रखना

Syllabus बताता है कि items धीरे-धीरे असर खो देते हैं, क्योंकि developers उन errors से बचना सीख जाते हैं जिन्हें वे निशाना बनाते हैं, और नए मिले high-severity defects (जिनका product या users पर बड़ा असर हो) के लिए नए items की ज़रूरत पड़ सकती है। इसलिए defect analysis के आधार पर checklists को नियमित रूप से अपडेट करें, पर उन्हें बहुत लंबा न होने दें।

Checklist को testware की तरह मानें, जिसका एक owner और version हो: हर test report में version लिखें, change publish करने से पहले पुराना और नया text compare करें, और list को तय समय पर review करें, जैसे हर release की retrospective में।

  • Item जोड़ें जब कोई ऐसा defect production तक पहुँच जाए, या high severity, जैसे Critical या Major, के साथ देर से मिले, जिसे वह item पकड़ सकता था; उस defect की id को item का source दर्ज करें।
  • जिस item को दो testers अलग-अलग समझें, उसे दोबारा लिखें: वह checklist का ही defect है।
  • जिन items को अब कोई automated check cover करता है या जो लंबे समय से fail नहीं हुए, उन्हें हटाएँ — पहले यह पूछकर कि सबक सीख लिया गया है या item को असल में कोई जाँचता ही नहीं।
  • जब पूरी list उपलब्ध समय में न चल पाए, तो testers को जल्दबाज़ी में सरसरी नज़र डालने देने की बजाय list को area के हिसाब से बाँटें, जैसे forms, lists और payments।

आज़माएँ: टेक्स्ट डिफ़

आम गलतियाँ

  • Items इतने general लिखना, जैसे "UI check करें", कि दो testers अलग-अलग चीज़ें करें और कोई न बता सके कि item pass हुआ या नहीं।
  • एक item में कई conditions, जिससे आंशिक fail भी सीधे pass या fail के रूप में दर्ज हो जाता है।
  • Build, data और असल में क्या जाँचा गया यह लिखे बिना items पर tick लगाना।
  • Checklist को पूरा test मान लेना, जबकि feature के अपने rules को अब भी equivalence partitioning और boundary value analysis चाहिए।
  • List को सिर्फ़ बढ़ने देना: न owner, न version, और ऐसे items जिन्हें कोई समझा न सके।

QA का नज़रिया

Checklists वहाँ अपनी जगह बनाती हैं जहाँ मिलती-जुलती चीज़ें बार-बार टेस्ट होती हैं: हर नया form, हर release candidate, हर accessibility review। आम तौर पर list का owner कोई senior tester या test lead होता है, और developers व designers items जोड़ते हैं। Result values पर सहमति बनाएँ — pass, fail, not applicable, not run — और build, checklist version और हर fail हुए item की defect id दर्ज करें।

जब आप किसी और की checklist इस्तेमाल करें, तो पूछें कि हर item कहाँ से आया, क्या वह इस feature पर लागू होता है और pass किसे माना जाएगा। जब आपको ऐसा defect मिले जिसे list पकड़ सकती थी, तो नया item defect report में या retrospective में propose करें।

अभ्यास

कमज़ोर checklist दोबारा लिखें और उससे टेस्ट करें

आपका काम

एक साथी ने online bookshop के search page के लिए नीचे दी गई checklist लिखी है। इसे इस तरह दोबारा लिखें कि हर item specific, observable और अपने आप में जाँचने योग्य हो, जो इसमें नहीं होना चाहिए उसे हटाएँ, और हर item को एक id और scope दें।

फिर अपने दो items के लिए बताएँ कि आप कौन-से concrete checks चलाएँगे।

सामग्री
Search page checklist

1. Search काम करता है।
2. Results सही, तेज़ और ठीक से sorted हैं।
3. Special characters से search check करें।
4. Search service के unit tests pass होते हैं।
5. Console errors नहीं हैं (CI के automated browser tests इन पर पहले से fail होते हैं)।
6. UI अच्छा दिखता है।
चरण
  1. हर item के लिए तय करें: दोबारा लिखना, बाँटना या हटाना, और क्यों।
  2. बचे हुए items को किसी observable चीज़ के बारे में हाँ-या-ना वाले सवालों के रूप में लिखें।
  3. हर item में एक id और scope जोड़ें।
  4. दो items के लिए checks लिखें और यह भी कि आप क्या दर्ज करेंगे।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Item 1 बहुत general है: इसे observable check के रूप में दोबारा लिखें (SRCH-01)। Item 2 को बाँटें: "सही" को SRCH-01 cover करता है, "sorted" SRCH-02 बनता है, और "तेज़" के लिए तय की हुई limit चाहिए या उसे performance testing पर छोड़ दें। Item 3 न characters बताता है न expected result: इसे दोबारा लिखें (SRCH-03)। Item 4 (entry criterion है, test condition नहीं) और item 5 (कोई automated check इसे cover करता है) हटाएँ। Item 6 पसंद-नापसंद की बात है: इसकी जगह SRCH-04 जैसे observable items लिखें।

एक संभव rewrite: SRCH-01 [Search box] क्या catalogue के किसी exact title से search करने पर वह book results के पहले page पर आती है? SRCH-02 [Results] "Price: low to high" चुनने पर, क्या हर price अगली price से कम या बराबर है, pages के पार भी? SRCH-03 [Search box] क्या apostrophe, hyphen या Arabic letters वाले terms बिना error page के matching books लौटाते हैं? SRCH-04 [Results] 200% browser zoom पर, क्या सारे titles और prices पूरे दिखते हैं?

SRCH-02 के checks: कम से कम 25 results वाले search पर "Price: low to high" चुनें, page 1 पर नीचे तक और फिर page 2 पर prices compare करें, और build number के साथ Pass या Fail दर्ज करें। SRCH-03 के लिए: O'Brien, e-book और رواية एक-एक करके search करें, और हर Fail के साथ exact term दर्ज करें।

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

Checklist-based testing और error guessing में क्या फ़र्क है?

Error guessing एक अनुमान से शुरू होती है: हर test किसी खास error, defect या failure को निशाना बनाता है जिसकी आपको आशंका है, अक्सर किसी fault list से लिया हुआ। Checklist-based testing test conditions की एक लिखी हुई, shared list से काम करती है, जिसमें जानी-पहचानी कमज़ोर जगहों के साथ requirements, interface properties और quality characteristics भी हो सकती हैं; item बताता है कि क्या जाँचना है, यह नहीं कि कौन-सी failure अपेक्षित है। जो fault list entries बार-बार defects पकड़ती हैं, वे अक्सर checklist items बन जाती हैं।

क्या checklist और test cases का set एक ही चीज़ है?

नहीं। Test case preconditions, inputs, steps और expected result बताता है। Checklist item जाँचने वाली condition का नाम देता है और exact steps tester पर छोड़ देता है। इसलिए checklists लिखना और maintain करना तेज़ है और testers के बीच ज़्यादा variation रहता है, जो coverage बढ़ा सकता है लेकिन repeatability घटाता है। जहाँ check को हूबहू दोहराना ज़रूरी हो, जैसे किसी high-risk rule के लिए, वहाँ test case लिखें।

Checklist कितनी लंबी होनी चाहिए?

इतनी लंबी कि जिन risks के लिए बनी है उन्हें cover करे, और इतनी छोटी कि उपलब्ध समय में पूरी इस्तेमाल हो सके। कोई standard संख्या तय नहीं करता। अगर testers items पर सरसरी नज़र डालने या उन्हें छोड़ने लगें, तो list को area के हिसाब से बाँटें या वे items हटाएँ जो अब problems नहीं पकड़ते।

क्या मैं AI tool से बनी checklist से शुरुआत कर सकता हूँ?

Draft के रूप में, हाँ: AI QA Checklist Generator किसी feature के लिए items सुझाता है। इस lesson के नियमों पर हर item को review करें — एक condition, observable, scoped, tool से जाँचने लायक नहीं — और टेस्ट करने से पहले general items हटा दें। Checklist की value उसी review और आपकी team की अपनी defect history से आती है।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • 10 Usability Heuristics for User Interface Design (Jakob Nielsen)Nielsen Norman Group · 1994इंटरफ़ेस डिज़ाइन के लिए Jakob Nielsen के दस व्यापक rules of thumb — जैसे system status की दृश्यता और error prevention — जो मूल रूप से heuristic evaluation के लिए बने थे।
  • Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024W3C की Recommendation जो सुलभ वेब कंटेंट के लिए टेस्ट करने योग्य success criteria तय करती है — चार सिद्धांतों और तीन conformance स्तरों (A, AA, AAA) में व्यवस्थित।
टूल्स

Mutqan tools से अभ्यास करें

वैलिडेशन टेस्ट जनरेटर

फ़ॉर्म फ़ील्ड के लिए validation टेस्ट केस बनाएँ: required, फ़ॉर्मेट, लंबाई, रेंज, pattern और cross-field नियम।

टेस्ट डिज़ाइन

नेगेटिव टेस्ट जनरेटर

फ़ॉर्म फ़ील्ड और API के लिए negative टेस्ट केस बनाएँ: खाली, null, ग़लत टाइप, बहुत लंबा, injection, अमान्य फ़ॉर्मेट।

टेस्ट डिज़ाइन

टेक्स्ट डिफ़

दो टेक्स्ट की लाइन-दर-लाइन या शब्द-दर-शब्द तुलना करें और अंतर हाइलाइट करें।

फ़ॉर्मेटिंग

AI QA चेकलिस्ट जनरेटर

Mutqan AI से किसी भी फ़ीचर के लिए अनुकूलित QA चेकलिस्ट (functional, UI, API, security, performance, accessibility, release) बनाएँ।

टेस्ट जनरेशन AI

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा

इस topic से पहले