मॉड्यूल 1 · Software और QA की बुनियाद

टेस्टर स्किल्स

Mutqan Soft QA टीम द्वारा · · 18 मिनट · शुरुआती

Tester skills वे क्षमताएँ हैं जिनसे कोई व्यक्ति अच्छी तरह टेस्ट कर पाता है। ISTQB Foundation syllabus v4.0 skill को किसी काम को अच्छी तरह करने की ऐसी क्षमता बताता है जो knowledge, practice और स्वाभाविक योग्यता (aptitude) से आती है, और section 1.5.1 में generic skills के छह groups बताता है जो testers के लिए ख़ास तौर पर अहम हैं: testing knowledge; thoroughness, carefulness, curiosity, attention to detail और methodical तरीके से काम करना; अच्छा communication, active listening और team player होना; analytical thinking, critical thinking और creativity; technical knowledge; और domain knowledge।

Requirement लें: "customer 24 घंटे के अंदर order cancel कर सकता है"। Testing knowledge आपको ठीक उस पल तक ले जाती है जब 24 घंटे पूरे होते हैं। Curiosity आंशिक रूप से ship हो चुके order के बारे में पूछती है। Domain knowledge वह refund जोड़ती है जो paid order को चाहिए। Technical knowledge नया status सिर्फ़ screen पर नहीं, API से भी जाँचती है। Communication आपकी खोज को ऐसी report में बदलता है जिस पर developer काम कर सके।

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

Testing जानकारी पैदा करती है, और उसकी कीमत उसे पैदा करने वाले व्यक्ति पर निर्भर करती है। जो tester techniques जानता है पर लापरवाही से काम करता है, उससे वह defect छूट जाता है जो सिर्फ़ तीसरी कोशिश में दिखता है; जो सावधान tester problem समझा नहीं पाता, उसकी reports गलत समझी जाती हैं या reject होती हैं। Syllabus हर group को एक नतीजे से जोड़ता है: ज़्यादा effective या ज़्यादा efficient testing, मुश्किल से मिलने वाले defects खोजना, users और business को समझना, और defects report व discuss कर पाना।

आपके लिए ये skills आपका career भी हैं। Tools और job titles बदलते रहते हैं, लेकिन अच्छे सवाल पूछने की आदत और problem को सटीक बताने की क्षमता हर product और specialisation में आपके साथ जाती हैं। कौन-सी skill सबसे कमज़ोर है, यह जानना बताता है कि आगे किसका अभ्यास करना है।

छह skill groups और हर एक का काम

Syllabus इन skills को generic कहता है: इनकी ज़रूरत सिर्फ़ testing में नहीं, कई पेशों में होती है, फिर भी ये testers के लिए ख़ास तौर पर अहम हैं। Syllabus यह भी बताता है कि हर group किस काम आता है। दो purposes एक से ज़्यादा बार आते हैं: effective testing ज़रूरी defects खोजती है, और efficient testing यही काम कम समय और मेहनत में करती है।

  • Testing knowledge: test techniques, test process और defect, failure व test basis जैसे terms। यह testing को ज़्यादा effective बनाती है, क्योंकि आप tests आदत से नहीं, सोच-समझकर चुनते हैं।
  • Thoroughness, carefulness, curiosity, attention to detail, methodical होना: आप आख़िरी screen को भी पहली जितनी सावधानी से जाँचते हैं, exact values दर्ज करते हैं और "what if" पूछते रहते हैं। मुश्किल से मिलने वाले defects ऐसे ही मिलते हैं।
  • Communication, active listening, team player होना: आप problem ऐसे समझाते हैं कि दूसरे समझ सकें, जवाब देने से पहले पूरा जवाब सुनते हैं, और हर stakeholder के साथ defects report व discuss करते हैं।
  • Analytical thinking, critical thinking, creativity: आप feature को test conditions में तोड़ते हैं, "इस बदलाव से और कुछ प्रभावित नहीं होगा" जैसे दावों पर सवाल उठाते हैं, और ऐसे इस्तेमाल सोचते हैं जो किसी ने लिखे नहीं। Testing knowledge की तरह यह भी testing को ज़्यादा effective बनाती है।
  • Technical knowledge: system कैसे बना है और उसके अंदर देखने के tools, जैसे browser DevTools, APIs, SQL और logs। यह testing को ज़्यादा efficient बनाती है।
  • Domain knowledge: business, उसके users, rules और regulations, जैसे VAT या refunds कैसे काम करते हैं। इससे आप end users और business representatives को समझ पाते हैं और उनसे उनकी भाषा में बात कर पाते हैं, और इसी से तय कर पाते हैं कि कोई behaviour user के लिए सही है या नहीं।

बुनियाद से specialisation तक

Syllabus छह groups को किसी क्रम के बिना बताता है, लेकिन उन्हें layers के रूप में देखना आपकी learning plan करने में मदद करता है। सबसे नीचे वे आदतें और testing knowledge हैं जो आप हर project में ले जाते हैं। बीच में thinking और communication हैं, जो हर test किए गए feature और हर लिखी गई report के साथ बढ़ते हैं।

सबसे ऊपर technical और domain knowledge हैं, जो product के साथ बदलते हैं: banking app और online shop को अलग domain knowledge चाहिए, web app और mobile app को अलग technical knowledge। Specialisation इन्हीं ऊपरी layers में होता है, और इस roadmap के बाद वाले modules, जैसे API, mobile और performance testing, इन्हें ही बनाते हैं।

ISTQB के छह tester skill groups layers के रूप में: thoroughness और testing knowledge हर project में tester के साथ जाते हैं, जबकि technical और domain knowledge हर product के साथ बदलती हैं और specialisation इन्हीं में होता है। वैचारिक मॉडल

“Domain knowledge” परत पर: Product और specialisation के साथ बदलती है“Thoroughness और curiosity” परत पर: हर project में साथ

  1. 1Domain knowledgeUsers और business को समझनाField के rules, users, regulations और शब्दावली: VAT, refunds, appointment slots

    ऐसे बनाएँ: help pages, regulations, support tickets, users के साथ समय

  2. 2Technical knowledgeज़्यादा efficient testingSystem कैसे बना है और अंदर देखने के tools: DevTools, HTTP और APIs, SQL, logs

    ऐसे बनाएँ: असली काम पर, एक समय में एक layer

  3. 3Communication और teamworkStakeholders के साथ काम, defects report करनासाफ़ reports, active listening, एक ही लक्ष्य वाले साथी

    ऐसे बनाएँ: कोई साथी आपकी मदद के बिना आपकी report reproduce करे

  4. 4Analytical और critical thinking, creativityज़्यादा effective testingFeature को conditions में तोड़ना, दावों पर सवाल, ऐसे इस्तेमाल सोचना जो किसी ने नहीं लिखे

    ऐसे बनाएँ: requirement के हर अस्पष्ट शब्द को सवाल में बदलें

  5. 5Testing knowledgeज़्यादा effective testingTest techniques, test process और field की शब्दावली

    ऐसे बनाएँ: हर नई technique रोज़ के किसी feature पर लागू करें

  6. 6Thoroughness और curiosityमुश्किल से मिलने वाले defects खोजनाCarefulness, attention to detail, methodical तरीका, “what if” पूछना

    ऐसे बनाएँ: build, data और exact results के साथ test notes रखें

वैचारिक मॉडल: syllabus छह groups को बिना क्रम के बताता है; layers दिखाती हैं कि कौन-सी skills आपके साथ चलती हैं और कौन-सी product के साथ बदलती हैं।

हर skill कैसे विकसित करें

Skills असली material पर सोच-समझकर किए गए अभ्यास और उसके बाद मिले feedback से बढ़ती हैं। एक समय में एक skill और उसके लिए एक आदत चुनें:

  • Testing knowledge: इस roadmap की हर नई technique को रोज़ इस्तेमाल होने वाले किसी feature पर लागू करें, जैसे login form।
  • Thoroughness: टेस्ट करते समय notes रखें, जिनमें build, data और हर check का exact result हो।
  • Curiosity और creativity: टेस्ट से पहले तीन "what if" सवाल लिखें, फिर उन्हें किसी scenario generator से मिलाकर देखें कि क्या छूट गया।
  • Analytical और critical thinking: requirement की test conditions और अस्पष्ट शब्द लिखें, और हर अस्पष्ट शब्द को सवाल में बदलें।
  • Communication: किसी साथी से कहें कि आपकी मदद के बिना आपकी कोई defect report reproduce करे; उसका हर सवाल एक कमी दिखाता है।
  • Technical knowledge: किसी असली काम पर एक समय में एक layer सीखें, जैसे कोई page load न हो तो DevTools का Network panel।
  • Domain knowledge: product के help pages, उसके regulations और असली support tickets पढ़ें, और customers से बात करने वाले लोगों से बात करें।

आज़माएँ: टेस्ट सिनेरियो जनरेटर आज़माएँ: Requirements → टेस्ट सिनेरियो आज़माएँ: AI Requirement अस्पष्टता डिटेक्टर

Defects report करने की soft skills: एक worked example

Defect report tester के काम का वह हिस्सा है जिसे ज़्यादातर लोग देखते हैं। Syllabus बताता है कि testers अक्सर बुरी ख़बर लाते हैं, इसलिए communication skills उनके लिए बहुत ज़रूरी हैं, और test results को product और उसके author की आलोचना की तरह सुना जा सकता है; इस कारण defects और failures की जानकारी constructive तरीके से दी जानी चाहिए। लोग ऐसी प्रतिक्रिया क्यों देते हैं, यह testing mindset और psychology वाला lesson समझाता है; यहाँ ध्यान skills पर है।

नीचे एक ही defect दो बार report किया गया है। Version A एक भावना और आरोप बताता है। Version B behaviour बताता है, reproduce करने के लिए ज़रूरी facts देता है, test basis का हवाला देता है, बिना दोष दिए impact बताता है और cause के बारे में अपने अनुमान को अनुमान ही कहता है।

  • व्यक्ति नहीं, behaviour बताएँ: "e-mail English में भेजा जाता है", न कि "आप Arabic भूल गए"।
  • सटीक रहें: exact build, account, data और steps, और हर report में एक ही defect।
  • अनुमान को अनुमान ही कहें: "शायद language browser से ली जा रही है"।
  • Impact user या business की भाषा में बताएँ।
  • जब जवाब "works as designed" हो, तो पूछें कि यह किस decision पर आधारित है; यह असहमति अक्सर अस्पष्ट requirement दिखाती है।
Version A (team chat)
  "Arabic users के लिए password reset फिर से टूटा है। क्या किसी ने इसे टेस्ट किया था?"

Version B (defect report)
  Title:     Account की language Arabic होने पर password reset e-mail English में आता है
  Build:     2.4.0, staging
  Steps:     1. Sign-in page > "Forgot password"
             2. ऐसे account का e-mail डालें जिसकी language Arabic है
             3. Reset e-mail खोलें
  Expected:  Subject और body Arabic में (story ACC-87, acceptance criterion 3)
  Actual:    Subject और body English में; reset link खुद काम करता है
  Evidence:  E-mail का screenshot; 2 अलग accounts से reproduce हुआ
  Impact:    जो users सिर्फ़ Arabic पढ़ते हैं, वे e-mail शायद न समझ पाएँ
  Notes:     Browser की language English थी। शायद e-mail account की setting की जगह
             browser की language लेता है (verify नहीं किया)

आज़माएँ: AI बग टाइटल जनरेटर आज़माएँ: AI बग विवरण जनरेटर

आम गलतियाँ

  • Technical knowledge को ही पूरा काम मान लेना: यह सीखने से पहले tool सीख लेना कि उससे क्या टेस्ट करना है।
  • Thoroughness को ज़्यादा tests चलाना समझना, बजाय हर expected result जाँचने और exact values दर्ज करने के।
  • यह इंतज़ार करना कि domain knowledge अपने-आप आ जाएगी। Business rules के बिना आप नहीं बता सकते कि सही दिखने वाला result सच में सही है या नहीं।
  • ऐसी reports लिखना जो लोगों को judge करें ("लापरवाह", "फिर से") या cause के अनुमान को fact की तरह पेश करें।
  • "works as designed" का जवाब decision पूछने की बजाय और कड़ी राय से देना।
  • सारी skills एक साथ सुधारने की कोशिश करना, बजाय एक skill का असली काम पर feedback के साथ अभ्यास करने के।

QA का नज़रिया

असली team में ये skills छोटे-छोटे पलों में दिखती हैं: refinement में, जब आप पूछते हैं कि payment time out हो जाए तो क्या होगा; daily stand-up में, जब आप एक वाक्य में बताते हैं कि क्या blocked है और क्यों; defect triage में, जब आप defect को facts से support करते हैं और अपना evidence सुने जाने के बाद team का decision मान लेते हैं।

अपनी reports पर मिले feedback का छोटा log रखें: developers ने कौन-से सवाल पूछे, और कौन-सी reports reopen या reject हुईं और क्यों। किसी senior tester से हर हफ़्ते एक report review करवाएँ, और छह groups को अपने development plan की checklist बनाएँ। नए product पर जल्दी business rules और regulations माँगें, और जानें कि rule अस्पष्ट हो तो किससे पूछना है।

अभ्यास

Chat की शिकायत को defect report में बदलें

आपका काम

एक junior tester ने team chat में नीचे वाला message डाला। उसके notes की मदद से इसे defect report (title, environment, steps, expected और actual result, evidence, impact) के रूप में दोबारा लिखें, बिना किसी पर दोष डाले।

फिर product owner के लिए दो सवाल लिखें, और बताएँ कि आपके काम के हर हिस्से में कौन-सा skill group इस्तेमाल हुआ।

सामग्री
Chat message:
  "Coupons फिर से टूटे हुए हैं। यह किसने टेस्ट किया?? Customers नाराज़ होंगे।"

Tester notes:
  - Build 3.8.1, staging, Windows 11 पर Chrome, customer account
  - Story SHOP-212: coupon SAVE10 cart total पर 10% छूट देता है
  - Cart: 3 items, total 180.00 SAR; एक item 60.00 का है
  - SAVE10 लगाया: discount 18.00, total 162.00 (सही)
  - 60.00 वाला item हटाया: discount अब भी 18.00, total 102.00
  - 3 बार किया, हर बार वही result; Firefox में भी वही
  - Payment तक आगे नहीं गया
चरण
  1. वह एक गलत behaviour पहचानें और title में उसे उसकी condition के साथ लिखें।
  2. Notes की exact values के साथ ऐसे steps लिखें जिन्हें कोई अजनबी भी follow कर सके।
  3. Expected result अपनी राय से नहीं, story से लें।
  4. Evidence और impact जोड़ें, फिर हर वह शब्द हटा दें जो किसी व्यक्ति को judge करता है।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Title: "Cart से item हटाने के बाद coupon discount दोबारा calculate नहीं होता"। Environment: build 3.8.1, staging, Windows 11 पर Chrome और Firefox, customer account।

Steps: 1. कुल 180.00 SAR के तीन items जोड़ें, जिनमें से एक 60.00 का हो। 2. SAVE10 लगाएँ (discount 18.00, total 162.00, जैसा अपेक्षित है)। 3. 60.00 वाला item हटाएँ। Expected: discount 12.00, total 108.00 (120.00 का 10%, story SHOP-212)। Actual: discount 18.00 ही रहता है और total 102.00 दिखता है। Evidence: step 2 और 3 के बाद के screenshots; Chrome में 3 में से 3 बार reproduce हुआ, और Firefox में भी। Impact: coupon लगाने के बाद cart बदलने वाले customer को rule से कम total दिखता है; अगर payment यही total इस्तेमाल करता है, तो इस order पर shop को 6.00 SAR कम मिलेंगे। Payment में भी 102.00 ही charge होता है या नहीं, यह अभी जाँचा नहीं गया।

सवाल: क्या cart बदलने पर हर बार discount दोबारा calculate होना चाहिए, या coupon लगाते समय तय हो जाता है? क्या SAVE10 की कोई minimum order value है, और cart उससे नीचे जाए तो क्या coupon हट जाना चाहिए?

Skills: thoroughness (exact values, तीन बार दोहराना, दूसरा browser, यह लिखना कि payment नहीं जाँचा गया); analytical thinking (trigger अलग करना: coupon के बाद item हटाना); testing knowledge (expected result test basis यानी story से लिया गया); domain knowledge (coupons और minimum order value कैसे काम करते हैं); technical knowledge (अगला कदम: API response में cart total जाँचना); communication (facts पर आधारित title, कोई दोष नहीं, impact लिखा हुआ)।

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

Beginner के लिए कौन-सी tester skill सबसे ज़रूरी है?

Syllabus इन्हें कोई rank नहीं देता। Practice में thoroughness और साफ़ communication पहले दिन से फ़ायदा देते हैं, क्योंकि वे हर test और हर report को ज़्यादा उपयोगी बनाते हैं, जबकि technical और domain knowledge उस product के साथ बढ़ती हैं जिस पर आप काम करते हैं।

क्या tester बनने के लिए coding आनी ज़रूरी है?

शुरुआत के लिए नहीं। Technical knowledge छह में से एक skill group है, और बहुत-सी testing code लिखे बिना होती है। HTTP traffic पढ़ना, simple SQL और browser DevTools जैसी basic technical skills आपको तेज़ और ज़्यादा सटीक बनाती हैं, और test automation में जाने पर coding ज़रूरी हो जाती है।

क्या soft skills सच में testing का हिस्सा हैं?

हाँ। Syllabus communication, active listening और team player होने को testers के लिए अहम skills में गिनता है, क्योंकि जो defect मिल तो जाए पर समझा न जाए, या माना न जाए, वह fix नहीं होता।

किसी नई industry में domain knowledge कैसे बनाऊँ?

Product का documentation, user help और जिन मुख्य regulations का वह पालन करता है उन्हें पढ़ें, असली support tickets देखें, और किसी business representative से कहें कि वह आपको एक user का आम दिन समझाए। जो rules सीखें उन्हें लिख लें: वे expected results तय करने और बेहतर सवाल पूछने में मदद करते हैं।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • Lessons Learned in Software Testing: A Context-Driven Approach (Cem Kaner, James Bach, Bret Pettichord)Wiley · 2001बग रिपोर्टिंग, टेस्ट डिज़ाइन, ऑटोमेशन और टेस्टिंग प्रबंधन पर व्यावहारिक सबक — कॉन्टेक्स्ट-ड्रिवन स्कूल।
टूल्स

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

टेस्ट सिनेरियो जनरेटर

किसी फ़ीचर के लिए functional, negative, security, usability और compatibility पहलुओं को कवर करने वाले उच्च-स्तरीय टेस्ट सिनेरियो जनरेट करें।

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

AI Requirement अस्पष्टता डिटेक्टर

requirements में अस्पष्ट, धुँधले या परस्पर विरोधी कथन पकड़ें और Mutqan AI से स्पष्टीकरण के सवाल पाएँ।

आवश्यकता विश्लेषण AI

AI बग टाइटल जनरेटर

Mutqan AI से बिखरे हुए विवरण से स्पष्ट और खोजने में आसान बग टाइटल बनाएँ।

बग विश्लेषण AI

AI बग विवरण जनरेटर

मोटे-मोटे नोट्स को पूरी बग रिपोर्ट में बदलें: reproduce करने के स्टेप, अपेक्षित बनाम वास्तविक, environment, गंभीरता और attachments चेकलिस्ट।

बग विश्लेषण AI

और गहराई से

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

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