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

एरर, डिफ़ेक्ट, फ़ेल्योर और रूट कॉज़

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

Error (या mistake) इंसान का ऐसा काम है जिससे गलत नतीजा निकलता है। Defect (जिसे fault या bug भी कहते हैं) वह कमी है जो error किसी work product में छोड़ जाता है, जैसे requirement, code या test script में। Failure वह है जो आप तब देखते हैं जब चलता हुआ system वह नहीं करता जो उसे करना चाहिए, या वह करता है जो नहीं करना चाहिए। Root cause वह गहरी वजह है जिससे error हुआ।

उदाहरण: एक developer सिर्फ़ English वाले पुराने form से name check copy कर लेता है (error), इसलिए sign-up code सिर्फ़ Latin letters स्वीकार करता है (defect)। जो customer अपना नाम Arabic script में लिखती है, उसका नाम reject हो जाता है (failure)। Acceptance criteria और shared test data में सिर्फ़ English नाम थे, इसलिए किसी का ध्यान इस कमी पर नहीं गया (root cause)।

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

सही शब्द तय करता है कि आगे क्या होगा। Failure ऐसा सबूत है जिसे आप दिखा सकते हैं; defect वह है जिसे developer को ढूँढना है; root cause वह है जिसे team को बदलना है ताकि अगला मिलता-जुलता defect न बने। जो report failure को सटीक बताती है — input, expected result, actual result — वह developer को आपके अंदाज़े के पीछे भागने की बजाय असली defect तक पहुँचाती है।

ये फ़र्क़ आपके फ़ैसले को भी बचाते हैं। Pass हुआ test यह साबित नहीं करता कि code सही है, क्योंकि हर defect failure पैदा नहीं करता। और fail हुआ test यह साबित नहीं करता कि product गलत है, क्योंकि गड़बड़ environment, test data या खुद test में हो सकती है।

Error से defect, defect से failure

ISTQB Foundation syllabus एक chain बताता है: लोग errors करते हैं, errors से defects बनते हैं, और defects से failures हो सकते हैं। Error किसी के दिमाग़ या हाथ में होता है। Defect किसी work product में तब तक रहता है जब तक कोई उसे हटा न दे। Failure run time पर होता है, जब defect वाला हिस्सा ऐसी conditions में चलता है जो उसे सामने ला दें।

Defects सिर्फ़ code में नहीं होते। किसी दूसरी requirement से टकराती requirement, गलत field जाँचने वाली test script और पुरानी library pack करने वाली build file भी defects हैं। किसी शुरुआती work product में छूटा defect अक्सर आगे और defects पैदा करता है: गलत requirement से गलत code बनता है, और ऐसे tests भी जो उससे सहमत हों।

  • Error (mistake): requirement गलत समझना, >= की जगह > लिखना, कोई case भूल जाना।
  • Defect (fault, bug): कुछ चलाए बिना review से भी मिल सकता है।
  • Failure: सिर्फ़ system के चलते समय देखा जा सकता है।
  • कुछ teams defect और failure दोनों को "bug" कहती हैं, और log के message को "error"। Reports में साफ़ लिखें कि आपका मतलब किससे है।

Failure के बिना defect, defect के बिना failure

Syllabus साफ़ कहता है: कुछ defects हर बार code चलने पर failure देते हैं, कुछ सिर्फ़ ख़ास हालात में, और कुछ कभी नहीं। Defect latent (छिपा) रहता है जब उसका code कभी चलता ही नहीं, या उस data के साथ नहीं चलता जो उसे trigger करे। इसलिए pass हुआ test सबूत है, प्रमाण नहीं।

Failures की वजह सिर्फ़ errors और defects नहीं होते। Syllabus environmental conditions का ज़िक्र करता है, जैसे radiation या electromagnetic fields जो firmware पर असर डालें। रोज़ की testing में test हो रहे code से बाहर की वजहें इससे कहीं ज़्यादा आम होती हैं: बंद पड़ा test server, time out होता third-party sandbox, expire हो चुका certificate। इनमें से कुछ कहीं और हुई इंसानी error तक जाते हैं — deployment configuration में गलत value उस file का defect है — लेकिन उसका owner और fix अलग होते हैं।

  • सिर्फ़ ख़ास हालात में: date calculation जो सिर्फ़ 29 फ़रवरी को टूटती है।
  • Latent: ऐसी currency में rounding defect जिसे shop ने अभी enable नहीं किया।
  • Masked: checkout के step 3 का defect तब तक नहीं दिख सकता जब तक कोई दूसरा defect step 2 को हर बार fail करता है। ISTQB glossary इसे defect masking कहता है।
  • Environment: form submit करने पर 503 Service Unavailable आता है, क्योंकि test environment की e-mail service redeploy हो रही है।

आज़माएँ: AI एरर मैसेज एनालाइज़र

Root cause: error क्यों हुआ

Root cause किसी समस्या के होने की बुनियादी वजह है, अक्सर कोई ऐसी स्थिति जिससे error हुआ। Syllabus लोगों के errors करने की आम वजहें गिनाता है: time pressure, work products, processes, infrastructure या interactions की जटिलता, थकान और training की कमी। Defect ठीक करने से एक समस्या हटती है; root cause दूर करने से मिलते-जुलते defects रुक सकते हैं या कम हो सकते हैं।

Root cause analysis आम तौर पर तब शुरू होता है जब failure हो या defect मिले, और "क्यों?" तब तक पूछता है जब तक जवाब ऐसा न हो जिसे team बदल सके। मान लीजिए एक sprint में तीन defects ने समय गलत time zone में दिखाया। हर fix एक defect हटाता है, लेकिन root cause — समय store करने और दिखाने का कोई तय नियम न होना, और अलग time zones का test data न होना — तब तक नए defects बनाता रहेगा जब तक team उसे नहीं बदलती।

False positive और false negative

Tests भी गलत हो सकते हैं। ISTQB glossary उस test result को false-positive result कहता है जो ऐसा defect बताए जो है ही नहीं, और उसे false-negative result जो मौजूद defect को पकड़ न पाए। यहाँ "positive" का मतलब है "test ने कहा कि समस्या है"। Glossary इन्हें false-fail result और false-pass result भी कहता है।

  • False positive: checkout test fail होता है क्योंकि उसके test data में पिछले हफ़्ते expire हुआ coupon है; product उसे सही तरीके से reject करता है। इसकी कीमत जाँच में लगा समय है।
  • False negative: price test pass होता है क्योंकि वह सिर्फ़ यह जाँचता है कि कोई total दिख रहा है, यह नहीं कि total सही है। कुछ गलत नहीं दिखता, जबकि defect users तक पहुँच जाता है।
  • Failure report करने से पहले test को परखें: उसे दोबारा चलाएँ, data, environment और expected result जाँचें, और expected व actual output को साथ-साथ रखकर मिलाएँ। Pass पर भरोसा करने से पहले पढ़ें कि test असल में क्या जाँचता है।

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

Worked example: sign-up पर reject हुआ Arabic नाम

Requirement R-07: "Full name field Arabic और English letters और spaces स्वीकार करता है, 2 से 60 characters।" एक tester Sara Alqahtani नाम से sign up करती है और account बन जाता है। वही नाम Arabic script में लिखने पर form कहता है "Name contains invalid characters"। यही failure है।

Tester input, expected result और actual result report करती है, और developer debugging से नीचे दिखाया गया defect ढूँढता है। Session के दौरान एक submission पर 503 Service Unavailable आया, तो tester ने environment ठीक होने पर test दोबारा चलाया और sign-up defect दर्ज करने की बजाय environment owner को बताया।

  • Defect: pattern सिर्फ़ Latin letters और spaces स्वीकार करता है।
  • Error: developer ने इसे सिर्फ़ English वाले पुराने newsletter form से copy किया और R-07 दोबारा नहीं देखी।
  • Root cause: acceptance criteria और shared test data में सिर्फ़ English नाम थे।
  • रास्ते में मिला false negative: एक API test हफ़्तों से Arabic नाम भेज रहा था, पर सिर्फ़ status 200 जाँचता था; response body में invalid_name लिखा था।
  • Fix के बाद: दोनों नामों के साथ confirmation testing, और acceptance criteria व test data में Arabic examples जोड़े गए।
// signup/validate.js
const NAME_PATTERN = /^[A-Za-z ]{2,60}$/;  // Latin letters and spaces only

NAME_PATTERN.test('Sara Alqahtani');  // true  -> account created
NAME_PATTERN.test('سارة القحطاني');   // false -> "Name contains invalid characters"
Sign-up उदाहरण: सिर्फ़ English examples (root cause) से developer English-only pattern copy करता है (error), जिससे Latin-only check बनता है (defect) जो चलते समय Arabic नाम reject करता है (failure)।
  1. 1Root causeerror के पीछे की स्थितिAcceptance criteria और shared test data में सिर्फ़ English नाम

    गेट: इससे होता है

  2. 2Error (mistake)इंसान का कामDeveloper सिर्फ़ English वाले पुराने form का name pattern copy करता है

    गेट: इससे बनता है

  3. 3Defect (fault, bug)एक work product में: codeSign-up check सिर्फ़ Latin letters और spaces स्वीकार करता है/^[A-Za-z ]{2,60}$/

    शाखा: Arabic नाम के साथ कभी नहीं चला: defect latent रहता है, कोई failure नहीं

    गेट: Arabic script वाले नाम के साथ चला

  4. 4Failuresystem चलते समय दिखता हैसही नाम reject होता है: "Name contains invalid characters"फ़ेल

चरण 1 पर वापस Root cause analysis failure से शुरू होकर "क्यों?" पूछता रहता है

क्रम से बाहर
  • Sign-up code में defect के बिना failure503 Service Unavailable जब test environment की e-mail service redeploy हो रही है

आज़माएँ: Regex टेस्टर आज़माएँ: AI बग विवरण जनरेटर

आम गलतियाँ

  • Failure देखने पर report में लिखना "validation function में error है"। Screen पर दिखा message failure का हिस्सा है, गलत code defect है, और error किसी इंसान का काम था: जो देखा वह report करें और defect की जगह ढूँढना debugging पर छोड़ दें।
  • Pass हुए test को इस बात का प्रमाण मानना कि कोई defect नहीं है।
  • हर fail हुए test को environment, test data और खुद test को जाँचे बिना product defect के रूप में report करना।
  • Defect ठीक कर देना पर यह कभी न पूछना कि वह हुआ क्यों, जिससे उसी तरह का defect फिर लौट आता है।
  • किसी व्यक्ति को root cause बताना। "लापरवाह developer" कहने से कुछ नहीं बदलता; अस्पष्ट requirements, छूटे examples या time pressure बदले जा सकते हैं।

QA का नज़रिया

Team में आम तौर पर testers failures सबसे पहले देखते और report करते हैं; developers debugging से defect ढूँढते हैं; और team सबसे अहम defects का root cause खोजती है: गंभीर defects, production तक पहुँचे defects और बार-बार लौटने वाले defects। आपकी report हर step को जानकारी देती है, इसलिए build, environment, data, steps, expected और actual result, और screenshot या log line जैसा सबूत दर्ज करें।

Report करने से पहले पूछें: क्या यह healthy environment पर भी दोहराया जा सकता है, क्या expected result अब भी वही है जो requirement कहती है, और क्या test सही चीज़ जाँच रहा है? Fix के बाद original data से दोबारा test करें और सुझाएँ कि कौन-सा बदलाव इस defect को रोक सकता था: ज़्यादा साफ़ acceptance criterion, review checklist का कोई item या बेहतर test data। Reviews में आप defects सीधे ढूँढते हैं, किसी failure के होने से पहले ही।

अभ्यास

एक test session के सात notes classify करें

आपका काम

एक online pharmacy के checkout के एक test session में ये सात notes लिखे गए। हर note को error, defect, failure, root cause, environment से हुआ failure, false positive या false negative में से एक label दें, फिर बताएँ कि आप आगे क्या करेंगे।

सामग्री
1. Cart में 25 items होने पर order total में सिर्फ़ पहले 20 items जुड़ते हैं।
2. Cart prices जोड़ने वाला loop ज़्यादा से ज़्यादा 20 बार चलता है।
3. Developer ने 20 items की cart limit एक पुराने design note से ली।
4. Product owner ने limit हटाई, तब design note update नहीं हुआ।
5. एक test "connection refused" के साथ fail होता है: database container start नहीं हुआ था।
6. 25 items वाला test pass होता है; वह सिर्फ़ यह जाँचता है कि कोई total दिख रहा है।
7. एक test 15 SAR delivery fee expect करता है; product 10 SAR दिखाता है, जो पिछले हफ़्ते तय fee है।
चरण
  1. हर note को एक label दें।
  2. Notes 1 से 4 को होने के क्रम में एक chain के रूप में लिखें।
  3. Notes 5 से 7 के लिए लिखें कि कुछ भी report करने से पहले आप क्या जाँचेंगे और क्या करेंगे।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

1 failure है: दिखा हुआ total गलत है। 2 code में defect है। 3 error है, यानी वह इंसानी काम जिससे defect बना। 4 root cause है: process की वह कमी जिसने requirement बदलने के बाद भी पुराने note को बचे रहने दिया।

होने का क्रम: 4 → 3 → 2 → 1। Report 1 को बताती है (exact cart, expected total और actual total के साथ); developer debugging से 2 ढूँढता है; team 4 को ठीक करती है, ताकि कोई requirement बदलने पर design notes का review हो।

5 environment से हुआ failure है, checkout code से नहीं। Checkout test के result के रूप में यह false positive भी है, क्योंकि यह ऐसे defect की ओर इशारा करता है जो checkout code में है ही नहीं, इसलिए यह label भी सही माना जा सकता है। दोनों हालात में checkout defect दर्ज न करें: database container चालू करें, test दोबारा चलाएँ और environment owner को बताएँ।

6 false negative है: defect होते हुए भी test pass होता है, क्योंकि वह सिर्फ़ यह जाँचता है कि कोई total दिखे। Exact expected total की check जोड़ें।

7 false positive है: test fail होता है पर product सही है। Product owner से बदलाव की पुष्टि करें, फिर expected result को नई fee पर update करें।

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

क्या bug और defect एक ही हैं?

ISTQB terms में हाँ: bug और fault, defect के synonyms हैं। रोज़ की बोलचाल में लोग देखे गए failure को भी "bug" कहते हैं। Report में वह failure लिखें जो आपने देखा, और defect की जगह ढूँढना debugging पर छोड़ दें।

Root cause कौन ढूँढता है, tester या developer?

आम तौर पर पूरी team मिलकर। Developer debugging से defect ढूँढता है, लेकिन root cause अक्सर requirements, process या communication में होता है, इसलिए analysis में product, development और testing तीनों चाहिए। Tester तथ्य लाता है: defect कहाँ और कैसे मिला, और किन tests से छूट गया।

अगर environment बंद होने से test fail हो, तो क्या वह failure है?

हाँ: system ने expected व्यवहार नहीं किया। लेकिन इसकी वजह test हो रहे code का defect नहीं है, इसलिए इसे product defect के रूप में दर्ज न करें। Environment owner को बताएँ और environment ठीक होने पर test दोबारा चलाएँ।

क्या false positive हमेशा test script की गलती होता है?

नहीं। परिभाषा के हिसाब से product में गड़बड़ नहीं है, लेकिन वजह script, पुराना expected result, test data या environment हो सकती है। पता करें कि कौन-सी, उसे ठीक करें, और note लिख लें ताकि वही झूठा alarm फिर समय न खाए।

संदर्भ

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

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

Regex टेस्टर

रेगुलर एक्सप्रेशन को लाइव टेस्ट करें — मैच हाइलाइटिंग, कैप्चर ग्रुप और रिप्लेस प्रीव्यू के साथ।

यूटिलिटीज़

टेक्स्ट डिफ़

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

फ़ॉर्मेटिंग

JSON डिफ़

दो JSON डॉक्यूमेंट की सिमैंटिक तुलना करें और जोड़ी गई, हटाई गई तथा बदली गई वैल्यू हाइलाइट करें।

JSON और डेटा

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

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

बग विश्लेषण AI

AI एरर मैसेज एनालाइज़र

Mutqan AI से stack trace और एरर मैसेज समझें, संभावित मूल कारण पहचानें और डिबगिंग के अगले क़दम जानें।

बग विश्लेषण AI

और गहराई से

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

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