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

टेस्टिंग माइंडसेट और साइकोलॉजी

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

Testing mindset वह नज़रिया है जिससे tester product को देखता है: curiosity के साथ, professional pessimism के साथ (यह मानना कि ऐसे defects हैं जो अभी किसी को नहीं मिले), और एक critical eye के साथ जो हर दावे पर सवाल उठाती है, अपने दावों पर भी। बनाने वाला पूछता है "इसे काम कैसे कराऊँ?"; tester पूछता है "यह कैसे fail हो सकता है, और किसके लिए?"।

Testing की psychology काम का इंसानी पहलू है: वे biases जिनकी वजह से सब लोग, testers भी, वही देखते हैं जिसकी उन्हें उम्मीद होती है, और यह कि लोग अपने काम के बारे में बुरी ख़बर पर कैसे react करते हैं।

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

Defect users तक तब पहुँचता है जब किसी ने वहाँ देखा ही नहीं जहाँ वह था, या किसी ने उसे पाया और उस finding पर बहस हुई या उसे नज़रअंदाज़ किया गया। Mindset तय करता है कि आप कहाँ देखते हैं; ख़बर देने का तरीका तय करता है कि finding fix बनेगी या नहीं। जिस tester की findings factual और निष्पक्ष होती हैं, उस पर भरोसा होता है, और वह release से पहले कोई असहज risk बिना झगड़े के उठा सकता है।

Tester का mindset: curiosity, professional pessimism, critical eye

Developer का मुख्य लक्ष्य solution बनाना है, इसलिए बनाते समय स्वाभाविक सवाल होता है "इसे काम कैसे कराऊँ?"। Testing mindset पूछता है "यह कैसे fail हो सकता है, किसके लिए, और हमें पता कैसे चलेगा?"। ये mindsets हैं, job titles नहीं: सहकर्मी के code का review करता developer testing mindset इस्तेमाल कर रहा है।

Password reset link में building mindset जाँचता है कि user link माँग सके, खोल सके और नया password set कर सके। Testing mindset link को दो बार खोलता है, expire होने के बाद, password बदलने के बाद, और forward किए गए e-mail से।

  • Curiosity: "अगर ऐसा हो तो क्या होगा…?" पूछना, भले कोई test case यह न पूछे।
  • Professional pessimism: यह उम्मीद रखना कि defects बाकी हैं, क्योंकि pass होते tests यह साबित नहीं कर सकते कि कोई defect नहीं है; इसका निशाना software है, लोग कभी नहीं।
  • Critical eye: "यह काम करता है" का मतलब सिर्फ़ इतना है कि "जिन cases को हमने आज़माया, उनमें काम किया"।
एक password reset link पर building और testing mindset: एक पूछता है इसे काम कैसे कराएँ, दूसरा यह कैसे fail हो सकता है, और दोनों को confirmation bias से सावधान रहना है। वैचारिक मॉडल

बिल्डिंग माइंडसेटआम तौर पर developers का

"इसे काम कैसे कराऊँ?"

फ़ोकस:
Solution design करना और बनाना
Reset link के पहले tests:
Link माँगना, खोलना, नया password set करना
किस confirmation bias से सावधान रहें:
बनाया गया path, दिमाग वाले data से टेस्ट करना, और pass को सबूत मान लेना
क्या योगदान देता है:
काम करता हुआ solution

टेस्टिंग माइंडसेटआम तौर पर testers का

"यह कैसे fail हो सकता है, किसके लिए, और हमें पता कैसे चलेगा?"

फ़ोकस:
Solution में, और उसके पीछे की requirement में, क्या गलत हो सकता है
Reset link के पहले tests:
दो बार खोलना, expire होने के बाद, password बदलने के बाद, forward किए गए e-mail से
किस confirmation bias से सावधान रहें:
Fix को सिर्फ़ ticket वाले input से retest करना, या एक बार के failure को "environment" कह देना
क्या योगदान देता है:
यह जानकारी कि वह कहाँ fail होता है और कितना risk बचा है

ये mindsets हैं, job titles नहीं: सहकर्मी के code का review करता developer testing mindset इस्तेमाल करता है, और tester को समझना पड़ता है कि चीज़ कैसे बनी है।

आज़माएँ: पॉज़िटिव टेस्ट जनरेटर आज़माएँ: नेगेटिव टेस्ट जनरेटर

Confirmation bias: हम वही देखते हैं जिसकी उम्मीद होती है

Confirmation bias वह प्रवृत्ति है जिसमें हम ऐसी information खोजते, समझते और याद रखते हैं जो हमारी पहले से बनी धारणा की पुष्टि करे। Authors अक्सर वही path टेस्ट करते हैं जो उन्होंने बनाया, उसी data से जो उनके दिमाग में था, और pass को सबूत मान लेते हैं। यह लापरवाही नहीं, ध्यान के काम करने का तरीका है।

Testers भी इससे बचे नहीं हैं: fix को सिर्फ़ ticket वाले input से retest करना, या एक बार हुए failure को "environment की वजह" कहकर टाल देना, testing नहीं, confirming है। बचाव के उपाय:

  • Test चलाने से पहले expected result test basis से लिखें।
  • हर confirming test के साथ एक ऐसा test रखें जो उल्टा साबित करने की कोशिश करे: invalid input, double click।
  • पूछें "कौन-सा result मुझे गलत साबित करेगा?", और किसी सहकर्मी से अपने test ideas review कराएँ।

आज़माएँ: एज केस जनरेटर

Independence of testing: फ़ायदे और नुकसान

ISTQB glossary independence of testing को ज़िम्मेदारियों के ऐसे बँटवारे के रूप में परिभाषित करती है जो objective testing को बढ़ावा देता है। CTFL v4.0 इसके दर्जे बताता है: author ख़ुद टेस्ट करे (कोई independence नहीं), उसी team के peers (कुछ), किसी दूसरी team के testers (high), या organisation के बाहर के testers (very high)। ज़्यादातर projects कई दर्जे मिलाते हैं: जैसे developers अपने components टेस्ट करते हैं, एक test team पूरा system टेस्ट करती है, और business representatives acceptance testing करते हैं। Independence familiarity की जगह नहीं लेती: developers अपने code में कई defects कुशलता से पकड़ लेते हैं।

  • फ़ायदा: अलग background, नज़रिया और biases होने से independent testers अलग तरह के failures पहचानते हैं, और specification व implementation के दौरान बनी assumptions को चुनौती देते हैं।
  • नुकसान: अलगाव से कमज़ोर collaboration, communication की समस्याएँ या विरोधी रिश्ता बन सकता है, developers quality की अपनी ज़िम्मेदारी का एहसास खो सकते हैं, और testers को bottleneck समझा जा सकता है या देरी का दोष दिया जा सकता है।

लोग बुरी ख़बर कैसे लेते हैं, और उसे कैसे दें

Testers अक्सर बुरी ख़बर लाते हैं, और ख़बर लाने वाले को दोष देना एक आम reaction है। Defect report product और उसके author की आलोचना जैसी सुनाई दे सकती है, confirmation bias अनचाही information को स्वीकार करना कठिन बनाता है, और कुछ लोग testing को विनाशकारी काम मानते हैं। इसलिए ISTQB syllabus testers से कहता है कि defects और failures की जानकारी constructive तरीके से दें।

Tester skills वाले lesson में report लिखना आया था; उसे देना पढ़ने वाले के बारे में है। Google की code review guide नियम सीधे शब्दों में कहती है: code पर comment करें, developer पर नहीं।

  • जल्दी बताएँ: blocking failure confirm होते ही, release meeting में नहीं।
  • साझा लक्ष्य से शुरू करें: "customers से दो बार पैसे कट जाएँगे", न कि "तुम्हारा code दो बार पैसे काटता है"।
  • शुरुआती defensive reaction की उम्मीद रखें और evidence से जवाब दें, ज़ोर देकर नहीं; पक्का न हों तो फ़ैसला सुनाने की जगह पूछें।
  • दोनों तरफ़ से समझ जाँचें: पढ़ने वाले से failure और उसका असर अपने शब्दों में दोहराने को कहें, और जवाब देने से पहले उसका जवाब ख़ुद दोहराएँ।

Worked example: fix का retest और विरोध को सँभालना

Lina ने report किया कि store app का search कुछ नहीं लौटाता जब query के आख़िर में space हो। Omar ने ticket इस comment के साथ resolve किया: "Fix और test कर दिया: coffee search किया, results OK"। वह test fail हो ही नहीं सकता था, क्योंकि बिना space वाला coffee हमेशा काम करता था।

Lina अपना confirmation test defect और requirement से design करती है। आख़िरी space fix है, पर शुरुआती space, जैसे chat से paste किए गए product नाम में, अब भी fail होता है। जब Omar इसे edge case कहता है, तो वह बहस नहीं करती: वह fact से सहमत होती है, जो देखा वह जोड़ती है, और खुला सवाल product owner को सौंप देती है।

SEARCH-212  Query के आख़िर में space होने पर search 0 results देता है

Omar:  Fix और test कर दिया: "coffee" search किया, results OK. Resolved.

Lina, build 5.2.1 पर confirmation test, staging, account test01
  "coffee"          24 results    regression check
  "coffee "         24 results    report किया गया case: fixed
  " coffee"          0 results    नया: शब्द से पहले space
  "coffee  beans"    6 results    "coffee beans" जैसा ही
  "   "             "Enter a search term"
  नतीजा: SEARCH-212 का fix confirm; शुरुआती space SEARCH-219 में log किया

Omar:  शुरुआती space edge case है, कोई उसे टाइप नहीं करता।
Lina:  सही, लोग उसे शायद ही टाइप करते हैं। पर chat या e-mail से product का
       नाम paste करने पर यह आ जाता है। क्या शुरुआती spaces भी आख़िरी spaces
       की तरह ignore होने चाहिए? मैंने SEARCH-219 पर product owner से पूछा है।

आज़माएँ: एज केस जनरेटर

आम गलतियाँ

  • Professional pessimism को लोगों पर लागू करना: product पर शक करना काम है, सहकर्मी पर शक करना नहीं।
  • यह मानना कि confirmation bias सिर्फ़ developers में होता है, और फिर fix को सिर्फ़ ticket वाले input से retest करना।
  • "कोई defect नहीं मिला" को "कोई defect नहीं है" बताना।
  • Reject हुए defect के लिए इज़्ज़त बचाने को लड़ना, बजाय evidence जोड़ने या फ़ैसला मानने के।
  • Independence को दूरी समझना: अलग-थलग testing करना और developers को विरोधी मानना।

QA का नज़रिया

यह mindset code बनने से पहले सबसे ज़्यादा काम आता है: refinement (जहाँ team आने वाली stories पर चर्चा करती है) और reviews में "यह कैसे fail हो सकता है?" सवाल की कीमत बस एक वाक्य है। Testing के दौरान अपने bias पर नज़र रखें: expected results test basis से लें, और confirmation tests fix के comment से नहीं, defect से design करें।

Team के साथ तय करें कि findings कैसे उठाई जाएँगी, और किस तरह की testing को independence का कौन-सा दर्जा मिलेगा। जब किसी finding का विरोध हो, तो fact को decision से अलग रखें: आप evidence और risk साफ़ करते हैं; fix करना, टालना या स्वीकार करना ज़िम्मेदार लोग तय करते हैं, अक्सर defect triage में।

अभ्यास

Bias पहचानें और constructive जवाब दें

आपका काम

नीचे हर स्थिति में इस lesson का कोई bias या इंसानी reaction काम कर रहा है। उसका नाम बताएँ, फिर लिखें कि उसकी जगह आप क्या कहेंगे या करेंगे।

सामग्री
1. दो दिन किसी feature को टेस्ट करने के बाद भी कोई defect नहीं मिला, और आप status
   report में लिखने वाले हैं: "कोई defect नहीं, release के लिए तैयार।"
2. आपका defect "Rejected: cannot reproduce" होकर लौटता है। आपके जवाब का पहला
   draft: "मेरे साथ तो हर बार fail होता है, फिर से देखो।"
3. Testers हर build sprint के आख़िर में ही देखते हैं। जब किसी change के unit tests
   नहीं होते, developers पहले से ज़्यादा कहने लगे हैं: "QA पकड़ लेगा।"
4. Stand-up में team lead कहता है: "Testing फिर से release रोक रही है।"
चरण
  1. तय करें कि bias या reaction किसका है: आपका, पढ़ने वाले का या team का।
  2. इस lesson के terms से उस असर का नाम बताएँ।
  3. Product या process के बारे में एक verify हो सकने वाला वाक्य या कदम लिखें, किसी व्यक्ति के बारे में नहीं।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

1. आपका अपना confirmation bias: pass होते tests यह नहीं दिखाते कि defects नहीं हैं। कुछ ऐसे tests जोड़ने के बाद जो feature को तोड़ने की कोशिश करें, लिखें: "(टेस्ट हुए areas) में कोई defect नहीं मिला। टेस्ट नहीं हुआ: (list)। बचा हुआ risk: (एक line)"।

2. पढ़ने वाले का reaction और आपका भी: "cannot reproduce" का मतलब अक्सर build, data या environment का फ़र्क होता है, और draft fact का जवाब भावना से देता है। Facts से जवाब दें: "Staging पर build 4.1.2, account test07, step 2 वाला data; recording attached है। क्या हम साथ में देख लें?"

3. Team का: independence का एक नुकसान। अलग-थलग testers safety net बन जाते हैं, और developers quality के लिए कम ज़िम्मेदार महसूस करते हैं। सुझाव दें कि testers refinement में शामिल हों और हर build आते ही टेस्ट करें, और developers अपने changes के unit tests लिखें।

4. Team का reaction: बुरी ख़बर लाने वाले को दोष देना, और testers को bottleneck समझना। बचाव नहीं, facts दें: "Refunds को छोड़कर सब टेस्ट हो चुका है, refunds कल आए। दो खुले defects card payments रोक रहे हैं; उनके साथ release करना product owner का फ़ैसला है।"

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

क्या professional pessimism का मतलब negative होना है?

नहीं। यह product के बारे में एक working assumption है: उसमें ऐसे defects हैं जो अभी नहीं मिले, इसलिए आप तब तक खोजते रहते हैं जब तक बचा हुआ risk पता न चल जाए। यह product बनाने वालों के बारे में कुछ नहीं कहता, और अच्छा tester जो काम करता है उसे भी उतनी ही स्पष्टता से report करता है जितना जो fail होता है।

क्या developers को अपना code ख़ुद टेस्ट करना चाहिए?

हाँ। Developers अपने code में कई defects कुशलता से पकड़ लेते हैं, और ISTQB syllabus कहता है कि independence familiarity की जगह नहीं लेती। Independent testing इसके ऊपर जोड़ी जाती है, जहाँ अलग नज़र और अलग biases अपनी कीमत के लायक हों, जैसे system और acceptance level पर या high-risk features के लिए।

मैं अपना confirmation bias कैसे पहचानूँ?

संकेत देखें: आपने screen देखने के बाद expected result लिखा, fix को सिर्फ़ ticket वाले input से retest किया, हर test pass हुआ और किसी ने ऐसा input नहीं आज़माया जो reject होना चाहिए, या किसी failure को जाँचे बिना टाल दिया। आपके test ideas review करने वाला सहकर्मी, या pair में testing, वह पकड़ लेता है जो आप ख़ुद नहीं देख पाते।

संदर्भ

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

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

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

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

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

पॉज़िटिव टेस्ट जनरेटर

positive (happy-path) टेस्ट केस बनाएँ जो पुष्टि करें कि हर आवश्यकता और हर वैध इनपुट संयोजन काम करता है।

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

एज केस जनरेटर

फ़ील्ड परिभाषा से strings, संख्याओं, तारीख़ों, फ़ाइलों, lists और concurrency के edge case जनरेट करें।

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

और गहराई से

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

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

इस topic से पहले