एरर गेसिंग

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 18 मिनट · मध्यम

Error guessing एक experience-based test technique है: आप अनुमान लगाते हैं कि किसी feature को बनाते समय लोग कौन-सी errors कर सकते हैं, वे errors कौन-से defects छोड़ती हैं और वे कौन-से failures पैदा करते हैं, और फिर सीधे उन्हीं पर निशाना साधने वाले tests design करते हैं। ISTQB Foundation syllabus (CTFL v4.0) इसे exploratory testing और checklist-based testing के साथ गिनता है।

एक उदाहरण: कोई requirement "Place order" पर double click का ज़िक्र नहीं करती, लेकिन कई forms button जल्दी दबाने पर वही request दो बार भेज देते हैं। तो आप उस पर double-click करते हैं। अगर दो orders बन जाएँ, तो इस अनुमान ने ऐसा defect पकड़ा है जिसकी तरफ़ कोई partition या decision table इशारा नहीं करती थी।

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

Specification-based techniques वही test करती हैं जो requirement कहती है। लेकिन कई महँगे defects उसमें छिपे होते हैं जो requirement नहीं कहती: double submit, payment के बीच expire होता session, नए user की खाली list। Experience-based techniques black-box और white-box techniques की पूरक हैं, क्योंकि वे ऐसे defects पकड़ सकती हैं जो उन techniques से छूट जाते हैं।

Tester के लिए error guessing team की defect history को काम में लाती है। लेकिन बेतरतीब ढंग से की जाए तो यह एक व्यक्ति की याददाश्त पर टिकी रहती है और कोई नहीं बता सकता कि क्या cover हुआ; यह पाठ इसे दोहराने लायक बनाता है।

आप किसका अनुमान लगाते हैं: errors, defects और failures

Error, defect और failure वाले पाठ की chain के साथ सोचें: developer भूल जाता है कि किसी customer का कोई order न हो (error), code में खाली list के लिए कोई branch नहीं होती (defect), और नए customer के लिए order history crash हो जाती है (failure)। Test सस्ता है: बिल्कुल नए customer के रूप में order history खोलें।

यहाँ test basis tester का ज्ञान है, कोई specification नहीं, इसलिए coverage मापना मुश्किल है। कुछ teams किसी भी बिना योजना की clicking को "error guessing" कह देती हैं; यहाँ इसका मतलब है ऐसे tests जो इस साफ़ अनुमान से निकले हों कि क्या fail हो सकता है। Syllabus इस ज्ञान के तीन स्रोत बताता है:

Application पहले कैसे चली है: उसकी defect history और कमज़ोर modules।
Developers आम तौर पर कौन-सी errors करते हैं: >= की जगह >, छूटा हुआ null check, code की एक copy में लगाया गया fix जो दूसरी में नहीं लगा।
मिलती-जुलती applications के failures: sign-up forms, checkouts और file imports जाने-पहचाने तरीकों से fail होते हैं।

आम errors की एक list

Syllabus errors, defects और failures को छह areas में बाँटता है। इन्हें अपनी list के headings बनाइए; हर bullet में पहले syllabus के उदाहरण हैं, फिर आज़माने के ideas।

Input: सही input स्वीकार न होना, parameters गलत या missing। आज़माएँ: O'Brien, शुरुआत में spaces, या ऐसा API request जिसमें वह field न हो जो app हमेशा भेजता है।
Output: गलत format, गलत result। आज़माएँ: rounding माँगने वाली amounts, PDF में Arabic text, और ऐसी screens जो null दिखा सकती हैं।
Logic: छूटे हुए cases, गलत operator। आज़माएँ: वह case जिसे किसी ने list नहीं किया, जैसे ऐसा order जिस पर discount भी है और partial refund भी।
Computation: गलत operand, गलत calculation। आज़माएँ: discount के बाद की price पर tax, और ऐसे count से भाग जो शून्य हो सकता है।
Interfaces: parameter mismatch, incompatible types। आज़माएँ: string के रूप में भेजा गया number, और systems के बीच दूसरे format में जाती date।
Data: गलत initialisation, गलत type। आज़माएँ: बिना history वाला नया user, और अपने column से बड़ी value।

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

Fault attacks: list से अनुमान लगाना

Fault attack error guessing को लागू करने का methodical तरीका है: संभावित errors, defects और failures की list बनाएँ या हासिल करें, फिर ऐसे tests design करें जो उन defects को उजागर करें या उन failures को पैदा करें। ISTQB glossary attack को specific failures होने पर मजबूर करने की directed और focused कोशिश बताता है। यह security attack नहीं है: आप इसे अपने ही product पर, test environment में चलाते हैं।

अनुभव, defect data या software क्यों fail होता है इसकी आम जानकारी से बनी हर entry एक hypothesis है कि product कहाँ कमज़ोर है। Attack उसे concrete data और expected result वाले test में बदल देता है:

ID          FL-07
Area        Logic (छूटा हुआ case)
Hypothesis  Form दो बार submit हो तो दो records बनते हैं
Evidence    हमारी defect history में दो बार मिला: DEF-112, DEF-240
Attack      "Pay" पर double-click; Enter दो बार; Back जाकर फिर submit
Expected    एक order और एक charge; दूसरा submit ignore होता है
Applies to  हर form जो कुछ बनाता है, किसी चीज़ का भुगतान करता है या कुछ भेजता है

Worked example: CSV से employee import

Requirement: "HR admins employee_id, full_name, email और hire_date (DD/MM/YYYY) columns वाली CSV file से employees import कर सकते हैं। Valid rows import होती हैं; invalid rows अपने row number के साथ error report में दिखती हैं। एक summary बताती है कि कितनी rows import हुईं और कितनी reject हुईं।"

Specification-based tests पहले से मौजूद हैं। अब हर area के लिए एक attack लिखें, expected result के साथ, या जहाँ requirement चुप हो वहाँ एक सवाल।

CSV employee import पर fault attacks, हर ISTQB error area के लिए एक: संभावित error, concrete attack और expected result, जबकि duplicate ID वाला case product owner के लिए सवाल के रूप में छोड़ा गया है।

Error area	संभावित error	Import पर attack	Expected result
Inputसही input स्वीकार नहीं; parameters गलत या missing	Parser को BOM या quotes के अंदर comma की उम्मीद नहीं	`employee_id` से पहले BOM; `"Al-Harbi, Sara"`	Header पहचाना गया; नाम पूरा store हुआ
Outputगलत format, गलत result	Header गिने बिना rows की numbering	Reject होने वाली rows वाली file	Row numbers file से मेल खाते हैं; header row 1 है
Logicछूटे cases, गलत operator	Duplicate IDs पर सोचा ही नहीं गया	वही `employee_id` दो बार; पहले से मौजूद ID	Requirement चुप: reject, update या skip?
Computationगलत operand, गलत calculation	Header row totals में गिनी गई	100 data rows, जिनमें 3 invalid	97 imported, 3 rejected
Interfacesparameter mismatch, incompatible types	Screen और database के बीच कहीं date month-first पढ़ी गई	Hire date `03/04/2026`	API response और database में 3 अप्रैल 2026
Dataगलत initialisation, गलत type	खाली file या आख़िरी खाली line handle नहीं	सिर्फ़ header वाली file; खाली line पर ख़त्म होने वाली file	0 imported, कोई crash नहीं; खाली line report नहीं

Requirement चुप है: product owner के लिए सवाल, expected result नहीं

Input: employee_id से पहले byte order mark (BOM), जैसे कुछ spreadsheet programs save करते हैं, और quotes वाला नाम "Al-Harbi, Sara" → header पहचाना जाए, नाम पूरा store हो।
Output: reject हुई rows → error report के row numbers file से मेल खाएँ, जहाँ header row 1 है।
Logic: वही employee_id दो बार, या पहले से मौजूद ID → requirement चुप है: reject, update या skip? Product owner से पूछें।
Computation: 100 data rows, जिनमें 3 invalid → 97 imported, 3 rejected; header नहीं गिना जाता।
Interfaces: hire date 03/04/2026 → 3 अप्रैल 2026, 4 मार्च नहीं, API response और database में, सिर्फ़ screen पर नहीं।
Data: सिर्फ़ header वाली file → "0 imported" और कोई crash नहीं; खाली line पर ख़त्म होने वाली file → खाली line invalid row के रूप में report नहीं होती।

आज़माएँ: CSV डेटासेट जनरेटर आज़माएँ: Unicode डेटासेट जनरेटर

Error guessing को systematic कैसे बनाएँ

जब list लिखी जाए, evidence से भरी जाए और maintain की जाए, तब error guessing एक व्यक्ति का हुनर नहीं, team का तरीका बन जाती है:

Evidence जुटाएँ: testing और production के defects के root causes, support tickets, बदलाव को लेकर developers की चिंताएँ।
एक shared fault list रखें, छह areas में बँटी हुई; हर entry में hypothesis, evidence और एक sample attack हो।
बदलाव पर लागू होने वाली entries चुनें, सबसे संभावित और सबसे नुकसानदेह पहले; जो छोड़ें वह लिखें।
Time-box में attack करें; entry, data और result record करें, ताकि attack report हो सके और दोहराया जा सके।
List update करें: नए patterns जोड़ें, कभी कुछ न पकड़ने वाली entries हटाएँ, और लगातार defects पकड़ने वाले attacks को regression tests या checklist items बनाएँ (अगला पाठ)।

Team cycle के रूप में error guessing: evidence एक shared fault list को भरता है, हर बदलाव के लिए entries चुनी जाती हैं, time-box में attack और record होती हैं, और results list को update करते हैं। वैचारिक मॉडल

1Evidence जुटाएँTesting और production के root causes, support tickets, developers की चिंताएँ
2Fault list रखेंछह areas में बँटी; हर entry अपने evidence के साथ एक hypothesis
3बदलाव के लिए चुनेंसबसे संभावित और नुकसानदेह पहले; जो छोड़ें वह लिखें
4Attack करेंConcrete data और expected result, time-box में
5Record करेंEntry, data, result और मिला हुआ कोई भी defect
6List update करेंनए patterns जोड़ें, बेकार entries हटाएँ, लगातार defects पकड़ने वाले attacks को regression tests या checklists बनाएँ

चरण 2 पर वापस Update हुई list अगले बदलाव के काम आती है

Technique चलाने का एक practical तरीका; ISTQB syllabus ये steps तय नहीं करता।

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

आम गलतियाँ

कुछ भी लिखे बिना अनुमान लगाना, जिससे न report हो सकता है, न fix के बाद दोहराया जा सकता है, न उससे सीखा जा सकता है।
Specification-based techniques की जगह error guessing इस्तेमाल करना; यह उनकी पूरक है, विकल्प नहीं।
कोई generic list copy करना और उसे product की अपनी defect history के हिसाब से कभी न ढालना।
"यहाँ कुछ टूट सकता है" पर रुक जाना, बिना concrete data और expected result के।
"Error guessing से test किया" ऐसे report करना जैसे यह मापी गई coverage हो, बजाय attack की गई entries बताने के।

QA का नज़रिया

Team में error guessing तीन मौकों पर होती है। Refinement में list की entries सवाल बनती हैं: "अगर वही file दो बार import हो तो?" Test design में आप specification-based cases के साथ targeted attacks जोड़ते हैं, हर एक पर उसकी list entry का label लगाकर। Release के बाद production तक पहुँचे defects वापस list में जाते हैं।

Developers से पूछें कि बदलाव के किस हिस्से पर उन्हें सबसे कम भरोसा है। Bug report में attack और उसका evidence लिखें, ताकि fix पूरे pattern को cover करे, जैसे हर वह form जो दो बार submit होता है। Test summary में attack की गई और छोड़ी गई entries बताएँ, ताकि product owner बचा हुआ risk देख सके।

अभ्यास

Profile photo upload के लिए fault list बनाएँ

आपका काम

एक social app कहता है: "Users profile photo upload कर सकते हैं (JPG या PNG, अधिकतम 5 MB)। Photo square में crop होकर page header में और user के comments के बगल में दिखती है।"

हर area के लिए fault list की एक entry लिखें: संभावित error, एक concrete attack, और expected result या एक सवाल। फिर सबसे पहले चलाने के लिए तीन attacks चुनें और वजह बताएँ। सिर्फ़ उसी test environment पर attack करें जिसकी आपको अनुमति है।

चरण

लिखें कि requirement क्या नहीं कहती।
हर area के लिए एक hypothesis लिखें।
हर hypothesis को concrete data वाले attack में बदलें।
Attacks को likelihood और नुकसान के हिसाब से rank करें।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

Requirement यह नहीं बताती: image का minimum size, photo के processing में रहते या upload fail होने पर user क्या देखता है, और rotation metadata वाली phone photos कैसे दिखेंगी। नीचे का जो expected result requirement में नहीं है, उसे product owner से confirm करें।

Input. संभावित error: file का type सिर्फ़ extension से तय होता है, और तुलना case-sensitive होती है। Attack: photo.PNG, और photo.jpg नाम दी गई PDF → पहली स्वीकार, दूसरी reject, क्योंकि extension नहीं, content जाँचा जाता है।

Output. संभावित error: phone photo के metadata में stored rotation को नज़रअंदाज़ करना। Attack: ऐसी photo upload करें → सीधी दिखे, करवट लेटी हुई नहीं।

Logic. संभावित error: एक साथ चल रहे uploads का क्रम तय नहीं। Attack: पिछली photo अभी processing में हो तब नई photo upload करें → नई photo ही दिखे, भले पुरानी की processing बाद में पूरी हो; कभी टूटी image नहीं।

Computation. संभावित error: crop मानकर चलता है कि image लगभग square है। Attack: 4000 × 300 pixels की panorama और 1 × 1 pixel की image → बीच से square crop, खिंची हुई नहीं; minimum size के बारे में पूछें।

Interfaces. संभावित error: storage service की error या timeout handle नहीं होता। Attack: test environment में storage failure या timeout simulate करें → साफ़ message, और पुरानी photo बनी रहे।

Data. संभावित error: बिना photo वाले users के लिए कोई default नहीं, या cache में पड़ी पुरानी copy। Attack: बिना photo वाला user, और comment करने के बाद बदली गई photo → placeholder; पुराने comments पर नई photo, cache वाली पुरानी नहीं।

सबसे पहले: content check (security risk भी), storage failure (users बिना photo के) और rotation (बहुत-सी profile photos phones से आती हैं)। अगर likelihood और impact से justify हो तो अलग ranking भी ठीक है।

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

क्या error guessing और exploratory testing एक ही हैं?

नहीं, हालाँकि दोनों अक्सर साथ इस्तेमाल होती हैं। Error guessing संभावित errors, defects और failures के अनुमान से tests design करती है। Exploratory testing में product के बारे में सीखते हुए tests एक साथ design, execute और evaluate होते हैं, और explorer अक्सर अगला क्या आज़माना है यह चुनने के लिए error guessing इस्तेमाल करता है। ISTQB syllabus में दोनों experience-based techniques हैं।

क्या कम अनुभव वाला beginner error guessing कर सकता है?

हाँ, अनुभव उधार लेकर। इस पाठ के छह areas से शुरू करें, अपनी team की defect history और मिलते-जुलते features की bug reports पढ़ें, और developers से पूछें कि उन्हें किस बात की चिंता है। आपको मिलने वाले हर defect के साथ आपकी list बढ़ती है।

Fault list और checklist में क्या फ़र्क़ है?

दोनों में overlap है। Fault list संभावित failures के इर्द-गिर्द बनी होती है और attacks design करने में काम आती है। Checklist उन test conditions की list है जिन्हें cover करना है, और वह भी उसी अनुभव पर आधारित हो सकती है। व्यवहार में, लगातार defects पकड़ने वाले attacks अक्सर checklist items बन जाते हैं; checklist-based testing अगला पाठ है।

Error guessing की coverage कैसे report करूँ?

इसकी coverage मापना मुश्किल है, क्योंकि list कभी पूरी नहीं होती, इसलिए बताएँ कि आपने क्या किया: किन entries पर attack किया, किस data से, किनसे defects मिले, और कौन-सी छोड़ीं और क्यों। इससे team को बचे हुए risk की ईमानदार तस्वीर मिलती है।

संदर्भ

ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।

एरर गेसिंग

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

आप किसका अनुमान लगाते हैं: errors, defects और failures

आम errors की एक list

Fault attacks: list से अनुमान लगाना

Worked example: CSV से employee import

Error guessing को systematic कैसे बनाएँ

आम गलतियाँ

QA का नज़रिया

अभ्यास

Profile photo upload के लिए fault list बनाएँ

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

संदर्भ

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

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

एज केस जनरेटर

स्पेशल कैरेक्टर डेटासेट जनरेटर

Unicode डेटासेट जनरेटर

CSV डेटासेट जनरेटर

और गहराई से

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

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

आप किसका अनुमान लगाते हैं: errors, defects और failures

आम errors की एक list

Fault attacks: list से अनुमान लगाना

Worked example: CSV से employee import

Error guessing को systematic कैसे बनाएँ

आम गलतियाँ

QA का नज़रिया

अभ्यास

Profile photo upload के लिए fault list बनाएँ

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

संदर्भ

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

और गहराई से

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

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics