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

सॉफ़्टवेयर टेस्टिंग क्या है?

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

Software testing activities का एक set है जो defects ढूँढता है और software व उससे जुड़े work products, जैसे requirements, designs और code, की quality evaluate करता है। ISTQB glossary testing को software development lifecycle के अंदर चलने वाली वह process बताती है जो किसी component या system और उससे जुड़े work products की quality evaluate करती है। आप जो भी टेस्ट कर रहे हों, एक user story, एक API या पूरी application, उसे test object कहते हैं।

Testing सिर्फ़ software चलाना नहीं है। नए "reset password" feature में tester पहले user story पढ़कर पूछता है कि पहले से इस्तेमाल हो चुके reset link पर क्या होना चाहिए। उसके बाद ही tests design होते हैं, test build पर चलाए जाते हैं और उनके results report होते हैं। उस पहले step में कोई software नहीं चला, फिर भी वह testing ही था।

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

Team testing को कैसे परिभाषित करती है, इसी से तय होता है कि वह कब शुरू होगी और क्या देगी। अगर testing का मतलब सिर्फ़ software execute करना है, तो वह build तैयार होने पर शुरू होती है और सबसे सस्ते में हटने वाले defects, यानी requirements, designs और code के defects, छोड़ देती है। अगर testing और debugging घुल-मिल जाएँ, तो fixes बिना किसी जाँच के close हो जाते हैं।

Tester के रूप में आपके लिए यह definition काम की सीमाएँ तय करती है। Test objectives बताते हैं कि कोई test क्यों है और आपकी report को किस सवाल का जवाब देना है। Testing और debugging के बीच की रेखा बताती है कि काम developer को कहाँ सौंपा जाता है, और fix वापस आने पर आपको team के लिए कौन-से tests चलाने हैं।

Test objectives: test क्यों होता है

Test objective testing का कारण है। ISTQB Foundation syllabus (CTFL v4.0) नीचे दिए typical objectives की list देता है। इनमें से कौन-से अहम हैं, यह context पर निर्भर है: work product, test level (जैसे अलग-अलग components की testing या पूरे system की testing), risks, development lifecycle और time to market जैसे business factors। उदाहरण के लिए, component (unit) testing में, जहाँ developers code के एक हिस्से को अकेले test करते हैं, आम तौर पर failures trigger करना और defects जल्दी ढूँढना पहले आता है; acceptance testing में confidence बनाना और release decision के लिए जानकारी देना।

  • Requirements, user stories, designs और code जैसे work products को evaluate करना।
  • Failures trigger करना और defects ढूँढना।
  • Test object की ज़रूरी coverage सुनिश्चित करना, जैसे हर acceptance criterion के लिए कम से कम एक test।
  • Software की अपर्याप्त quality के risk का level कम करना।
  • Verify करना कि specified requirements पूरी हुई हैं या नहीं।
  • Verify करना कि test object contractual, legal और regulatory requirements का पालन करता है।
  • Stakeholders को जानकारी देना ताकि वे informed decisions ले सकें।
  • Test object की quality में confidence बनाना।
  • Validate करना कि test object पूरा है और stakeholders की उम्मीद के मुताबिक़ काम करता है।

आज़माएँ: Requirements → टेस्ट केस

Static और dynamic testing

दोनों रूप आप verification और validation वाले lesson में देख चुके हैं। Dynamic testing software को execute करती है। Static testing किसी work product को execute किए बिना जाँचती है, या तो review से, जिसमें लोग उसे पढ़कर चर्चा करते हैं, या static analysis से, जिसमें tools उसे rules के हिसाब से जाँचते हैं। ISTQB दोनों को testing मानता है।

असली फ़र्क इसमें है कि हर एक क्या ढूँढती है। Dynamic testing failures trigger करती है, जिन्हें फिर उनके defects तक वापस trace करना पड़ता है। Static testing सीधे defect ढूँढती है, अक्सर उसकी exact location के साथ, और ऐसे work products भी जाँच सकती है जो कभी run नहीं होते, जैसे requirements और test plans। कोई एक दूसरी की जगह नहीं ले सकती: review page load होने की speed नहीं नाप सकता, और ambiguous requirement को tests चलाकर पकड़ने से कहीं आसान उसे पढ़कर पकड़ना है।

  • Review: कोई code लिखे जाने से पहले ही story "Approved expenses monthly report में दिखते हैं" पढ़कर पूछना: "approve कौन करेगा, और महीना कौन-सी date तय करेगी, submission की या approval की?"
  • Static analysis: कोई tool SQL statement में बंद न हुआ parenthesis किसी के चलाने से पहले ही flag कर देता है।
  • Dynamic test: monthly report को known data के साथ चलाना और उसके total की तुलना expected total से करना।

आज़माएँ: SQL क्वेरी वैलिडेटर आज़माएँ: JSON वैलिडेटर

Testing, debugging नहीं है

Testing और debugging अलग-अलग activities हैं। Testing दिखाती है कि कुछ गलत है; debugging उसका कारण ढूँढकर उसे हटाती है। जब कोई dynamic test fail होता है, तो debugging में आम तौर पर तीन steps होते हैं: failure को reproduce करना, उसके कारण का diagnosis करना और उसे fix करना। जब static testing कोई defect ढूँढती है, तो reproduce या diagnose करने को कुछ नहीं होता, क्योंकि defect पहले से सामने है, इसलिए debugging सिर्फ़ fix है।

Fix के बाद testing फिर से शुरू होती है। Confirmation testing, जिसे re-testing भी कहते हैं, जाँचती है कि fix ने मूल समस्या हल कर दी, आम तौर पर fail हुए test को उसी data के साथ दोबारा चलाकर; syllabus के अनुसार बेहतर है कि इसे वही व्यक्ति करे जिसने मूल test चलाया था। फिर regression testing जाँचती है कि change ने कहीं और failures पैदा नहीं किए।

Worked example: expense report में गलत total

Requirement: "Monthly report उस महीने में approve हुए सभी expenses का total दिखाती है।" Tester हुदा build 2.7 पर test case TC-REP-014 चलाती है, सितंबर 2026 में approve हुए तीन expenses के साथ। Expected total 235.75 SAR है; report 195.75 दिखाती है। यही अंतर एक failure है।

हुदा build, data और दोनों totals के साथ इसे report करती है; उसे यह जानने की ज़रूरत नहीं कि code की कौन-सी line गलत है। फिर developer उमर debugging करता है: failure reproduce करता है, एक date filter पाता है जो 30 सितंबर की शुरुआत पर ख़त्म होता है और इसलिए महीने का आख़िरी दिन छोड़ देता है, और उसे fix करता है।

Expense report 235.75 की जगह 195.75 दिखाती है: testing failure पकड़ती है, debugging उसे reproduce करती है और defect का diagnosis करके उसे fix करती है, testing fix की पुष्टि करती है, और review वही defect सीधे पकड़ सकता था।

  1. Dynamic testing: test run एक failure दिखाता है

    Build 2.7 पर TC-REP-014, सितंबर 2026 में approve हुए तीन expenses

    1. 1Test चलानाExpected total: 235.75Testing
    2. 2Failure देखनाReport एक expense छोड़ देती हैtotal 195.75Testingफ़ेल
    3. 3Defect report करनाBuild, data, expected और actual total; कारण का अंदाज़ा नहींTesting
    4. 4ReproduceBuild 2.7 पर वही data: वही गलत totalDebugging
    5. 5DiagnoseDate filter 30 सितंबर की शुरुआत पर रुक जाता हैapproved_at < '2026-09-30'Debugging
    6. 6FixBuild 2.8 मेंapproved_at < '2026-10-01'Debugging
    7. 7Confirmation testBuild 2.8 पर TC-REP-014 दोबारा, वही datatotal 235.75Testingपास
    8. 8Regression testsQuarterly report, CSV export, 31 दिनों वाला महीनाTestingपास

  2. Static testing: review सीधे defect ढूँढता है

    वही defect, report के चलने से पहले ही

    1. 9Query का reviewCode review: कुछ भी execute नहीं होताTesting
    2. 10Defect मिलनाउसकी exact location पहले से पता हैapproved_at < '2026-09-30'Testing
    3. 11Fixन reproduce, न diagnosisapproved_at < '2026-10-01'Debugging

हर card पर testing या debugging का tag है। Static रास्ते में reproduce या diagnose करने को कुछ नहीं होता, इसलिए debugging सिर्फ़ fix है।

  • Confirmation test: build 2.8 पर उसी data के साथ TC-REP-014 से total 235.75 आता है, इसलिए defect close किया जा सकता है।
  • Regression tests: वही filter इस्तेमाल करने वाले quarterly report और CSV export, और 31 दिनों वाला महीना, सभी सही totals देते हैं।
  • Static रास्ता: अगर कोई reviewer query के चलने से पहले ही उसे पढ़ता, तो end date सीधे पकड़ लेता, बिना reproduce और बिना diagnosis के।
पाठ संस्करण
TC-REP-014  Monthly report का total approved expenses के जोड़ के बराबर है
Build 2.7   सितंबर 2026 में approve हुए expenses:
            12 Sep  120.50  |  21 Sep  75.25  |  30 Sep 16:40  40.00
Expected    Total 235.75
Actual      Total 195.75                                     FAILED

Debugging (उमर, developer)
  Reproduce   Build 2.7 पर वही data: total 195.75
  Diagnose    Filter: approved_at < '2026-09-30'  (30 Sep छूट जाता है)
  Fix         Filter: approved_at < '2026-10-01'  -> build 2.8

Confirmation  Build 2.8 पर TC-REP-014, वही data: total 235.75     PASSED
Regression    Quarterly report, CSV export, 31 दिनों वाला महीना    PASSED

आज़माएँ: रिग्रेशन सिनेरियो जनरेटर

आम गलतियाँ

  • यह मानना कि testing तभी शुरू होती है जब चलाने के लिए build हो, और requirements, designs व code के reviews छोड़ देना।
  • बिना तय objective के testing करना, जिससे किसी को नहीं पता कि "done" का मतलब requirements verify होना है, risks cover होना है या release के लिए पर्याप्त confidence।
  • Defect report में कारण का अंदाज़ा लिखना ("SQL गलत है") बजाय failure का सटीक वर्णन करने के: steps, data, expected और actual result।
  • Developer के fixed mark करने पर defect close कर देना, original data के साथ confirmation test चलाए बिना।
  • Fix के बाद सिर्फ़ confirmation test चलाना और change से प्रभावित हो सकने वाले areas के regression tests छोड़ देना।

QA का नज़रिया

असली team में आप तभी से टेस्ट करते हैं जब कोई work product मौजूद हो: stories के sprint में आने से पहले उनका review करते हैं, फिर builds आने पर tests design करके चलाते हैं। Test cycle से पहले product owner या test lead से पूछें कि इस release के लिए कौन-से objectives सबसे अहम हैं; इसी से तय होता है कि आप पहले क्या टेस्ट करेंगे और आपकी report को किस सवाल का जवाब देना है।

जब कोई test fail हो, तो debugging ख़ुद करने के बजाय उसे तेज़ बनाएँ: build, environment, data, steps, expected और actual results लिखें, और screenshot या log attach करें। Fix आने पर उसी data के साथ confirmation test चलाएँ, regression tests चुनने के लिए developer से पूछें कि change और किन चीज़ों को छूता है, और दोनों results defect पर दर्ज करें।

अभ्यास

Defect thread में testing और debugging अलग करें

आपका काम

Material एक food delivery app के defect का thread है, पहली report से fix तक। इसमें testing और debugging को अलग करें, फिर fix के बाद होने वाली testing की योजना बनाएँ।

सामग्री
BUG-311  Order confirmation e-mail में delivery date गलत है
Rule: delivery date = order date + 2 दिन। Store: Riyadh (UTC+3)।

Mon 09:10  सारा (tester): Build 5.3 पर TC-ORD-21 चलाया। Order 6 Oct को Riyadh समय
           01:30 पर दिया। Expected "Delivery: 8 Oct"; e-mail में "Delivery: 7 Oct" है।
           10:00 बजे के orders में date सही है। Screenshot और order number attached।
Mon 11:30  उमर (developer): अपनी machine पर 01:30 वाले order से reproduce हो गया।
Mon 13:05  उमर: कारण मिल गया। E-mail service order date UTC में लेती है, जहाँ
           Riyadh में 6 Oct का 01:30 अभी 5 Oct ही है।
Mon 13:20  उमर: Build 5.4 में fix; अब date store के time zone से बनती है।
           Status: ready for testing।
चरण
  1. हर entry को testing या debugging के रूप में label करें, और हर debugging entry का step बताएँ: reproduce, diagnose या fix।
  2. Build 5.4 के लिए confirmation test लिखें: इसे कौन चलाएगा, किस data के साथ, और expected result क्या है।
  3. Date calculation के change के लिए कम से कम दो regression tests लिखें।
  4. एक static test बताएँ जो कोई भी code चलने से पहले यह defect पकड़ सकता था।
  5. बताएँ कि TC-ORD-21 चलाने से कौन-से test objectives पूरे हुए।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Testing: 09:10 वाली entry, जिसमें सारा ने TC-ORD-21 चलाया, failure देखा और build, data, expected और actual result के साथ report किया। Debugging: 11:30 reproduce है, 13:05 diagnose और 13:20 fix। "Ready for testing" status काम को वापस testing को सौंपता है।

Confirmation test: बेहतर है कि सारा, जिसने मूल test चलाया था, build 5.4 पर उसी order के साथ TC-ORD-21 चलाए, जो 6 October को Riyadh समय 01:30 पर दिया गया था, और "Delivery: 8 Oct" की उम्मीद करे। Pass हो तो defect close किया जा सकता है।

Regression tests: 10:00 बजे का order; Riyadh समय 03:00 से ठीक पहले और ठीक बाद के orders, जो UTC की आधी रात है; Riyadh समय की आधी रात से ठीक पहले और ठीक बाद के orders, जहाँ अब store का दिन बदलता है; महीने के आख़िरी दिन 01:30 पर दिया गया order; और कोई भी दूसरी जगह जो delivery date दिखाती है, जैसे order history page।

Static test: requirement का review, यह पूछते हुए कि "delivery date किस time zone में calculate होती है?", या date calculation का code review, जो दिखा देता कि वह UTC इस्तेमाल करती है।

Objectives: failures trigger करना और defects ढूँढना; एक specified requirement, यानी customer को दिखने वाली delivery date, को verify करना; customers तक गलत dates पहुँचने का risk कम करना; और stakeholders को जानकारी देना। इसके बाद confirmation और regression tests fix में confidence बनाते हैं।

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

क्या debugging tester के काम का हिस्सा है?

नियम के तौर पर नहीं। Testing और debugging अलग activities हैं, और ज़्यादातर teams में debugging developers करते हैं। Tester failure की conditions को सीमित करके (कौन-सा data, कौन-सा browser, कौन-सा build) और उन्हें सटीक report करके मदद करता है। Code पढ़ सकने वाले कुछ testers diagnosis में भी मदद करते हैं; वह काम फिर भी debugging है, testing नहीं।

क्या code review सच में testing है?

हाँ, ISTQB की शब्दावली में। Reviews और static analysis static testing हैं: ये किसी work product को execute किए बिना evaluate करते हैं। ये defects सीधे ढूँढते हैं, अक्सर dynamic testing से पहले और कम rework के साथ, और requirements जैसे कभी run न होने वाले work products को टेस्ट करने का यही एकमात्र तरीका है।

Confirmation testing और regression testing में क्या फ़र्क है?

Confirmation testing जाँचती है कि fix ने मूल समस्या हल की, आम तौर पर fail हुए tests दोबारा चलाकर, कभी-कभी change के लिए नए tests के साथ। Regression testing जाँचती है कि change ने पहले से काम कर रही किसी चीज़ को नहीं तोड़ा। Fix के बाद आम तौर पर दोनों चाहिए।

क्या सभी projects के test objectives एक जैसे होते हैं?

नहीं। Syllabus typical objectives की list देता है, और कौन-से अहम हैं यह context पर निर्भर है: work product, test level, risks, lifecycle और time to market जैसे business factors। Regulated market में payment feature के लिए compliance और risk पहले आते हैं; शुरुआती prototype को मुख्य रूप से stakeholders के लिए जल्दी जानकारी चाहिए हो सकती है।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsISO/IEC/IEEE · 2022सॉफ़्टवेयर टेस्टिंग का अंतरराष्ट्रीय मानक: अवधारणाएँ, प्रक्रियाएँ, दस्तावेज़ीकरण और तकनीकें।
टूल्स

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

Requirements → टेस्ट केस

क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।

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

SQL क्वेरी वैलिडेटर

SQL स्टेटमेंट में सिंटैक्स की समस्याएँ, असंतुलित कोष्ठक, बिना बंद की स्ट्रिंग और जोखिम भरे पैटर्न जाँचें।

डेटाबेस

JSON वैलिडेटर

JSON सिंटैक्स वैलिडेट करें और गलतियों की सटीक जगह के साथ सुधार के उपयोगी सुझाव पाएँ।

JSON और डेटा

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

बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।

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

Timezone कन्वर्टर

तारीख़ और समय को अलग-अलग timezone के बीच बदलें (रियाद, अम्मान, दिल्ली, UTC, न्यूयॉर्क, लंदन…)।

यूटिलिटीज़

और गहराई से

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

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