मॉड्यूल 3 · Testing fundamentals

टेस्ट लेवल्स

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

Test level, test activities का एक समूह है जिसे एक साथ organise और manage किया जाता है, और जो development के किसी खास stage के software को जाँचता है: एक अकेले component से लेकर दूसरे systems के साथ काम करते पूरे system तक। ISTQB Foundation syllabus (CTFL v4.0) पाँच levels बताता है: component testing, component integration testing, system testing, system integration testing और acceptance testing।

Food delivery app में developer delivery fee वाला function जाँचता है (component), order और restaurant services साथ में टेस्ट होती हैं (component integration), testers test environment में पूरे orders चलाते हैं (system), फिर payment provider के sandbox, यानी उसके test environment, के साथ (system integration), और business पक्का करता है कि app restaurants और customers के असली काम करने के तरीके में फ़िट है (acceptance)।

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

सब कुछ आख़िर में user interface से टेस्ट करना defects को देर से पकड़ता है और उनकी जगह ढूँढना मुश्किल बनाता है: checkout पर गलत total किसी rounding function, services के बीच interface, configuration या external provider से आ सकता है। हर level एक तय object को अपने test basis से देखता है, इसलिए failure छोटे हिस्से की ओर इशारा करता है और कई defects पहले, अपनी वजह के करीब मिलते हैं — यही early testing principle का व्यवहार में रूप है।

Levels gaps और duplication भी दिखाते हैं: अगर system integration testing किसी की ज़िम्मेदारी नहीं, तो payment interface सबसे पहले customers टेस्ट करते हैं। Tester के लिए levels बताते हैं कि कौन-से documents माँगने हैं, कौन-सा environment चाहिए और किन defects की उम्मीद करनी है।

Test level क्या है

V-model वाले lesson में हर development level के सामने एक test level था। ISTQB हर test level को test process का एक instance मानता है: planning से completion तक की test activities हर level पर होती हैं। Sequential models में एक level के exit criteria अक्सर अगले level के entry criteria का हिस्सा होते हैं। कुछ iterative models में यह शायद लागू न हो: development activities कई levels तक फैल सकती हैं, levels समय में overlap कर सकते हैं, और एक sprint में हर level का काम हो सकता है।

Levels, test types नहीं हैं। Test type, test activities को इस आधार पर group करता है कि वे क्या जाँचती हैं या tests कैसे बनते हैं: functional और non-functional testing अलग-अलग quality characteristics देखती हैं, जबकि black-box testing tests को specification से और white-box testing internal structure से बनाती है। ज़्यादातर types हर level पर किए जा सकते हैं: performance test एक database query भी नाप सकता है और पूरा checkout भी। ISTQB levels को इन attributes से अलग करता है:

  • Test object: क्या टेस्ट होता है, एक function से लेकर दूसरे system के interface तक।
  • Test objectives: level को क्या दिखाना है।
  • Test basis: tests किससे बनते हैं, जैसे design या user stories।
  • Defects और failures: यह level सबसे अच्छी तरह क्या पकड़ता है।
  • Approach और responsibilities: techniques, environment और काम कौन करता है।

CTFL v4.0 के पाँच test levels

CTFL v4.0 पाँच levels और ऊपर के attributes तय करता है; नीचे दिए test basis और defects आम उदाहरण हैं, जैसे पिछले (2018) syllabus में दिए गए थे और practice में दिखते हैं, और असली basis आपके project के documents तय करते हैं। ISTQB component testing को unit testing और component integration testing को unit integration testing भी कहता है।

  • Component testing: एक function, class या module को अलग से, अक्सर unit test framework के साथ; उसे अलग करने के लिए जिन हिस्सों पर वह निर्भर है उन्हें test doubles से बदला जा सकता है, यानी stubs और mocks जैसे सरल stand-ins। Basis: detailed design, code। आम defects: गलत logic या calculations।
  • Component integration testing: components के बीच interfaces और interactions, integration strategy के हिसाब से: bottom-up (सबसे निचले components पहले), top-down (ऊपर से शुरू, अधूरे हिस्सों के लिए stubs के साथ) या big-bang (सब कुछ एक साथ)। Basis: software design, API specifications। आम defects: interface mismatch, missing या गलत encoded data, components के बीच भेजे गए data की units के बारे में गलत assumptions।
  • System testing: पूरे system का behaviour, end-to-end tasks और non-functional characteristics समेत, representative test environment में। Basis: requirements, user stories, use cases। आम defects: requirements के उलट behaviour, पूरे न हो पाने वाले tasks, धीमे responses।
  • System integration testing: payment gateway या SMS provider जैसे external systems और services से interfaces, production जैसे environment में। Basis: interface agreements, external API documentation। आम defects: inconsistent messages, handle न हुए timeouts, exchange होने वाले data के बारे में गलत assumptions।
  • Acceptance testing: validation कि system users की business needs पूरी करता है और deployment के लिए तैयार है। मुख्य रूप: user acceptance testing (UAT), operational acceptance testing, contractual और regulatory acceptance testing, alpha testing और beta testing। Basis: business processes, acceptance criteria, contracts, regulations। आम defects: business में फ़िट न होने वाले workflows, गलत business rules, पूरी न हुई contractual या regulatory requirements।
ISTQB के पाँच test levels, अलग से टेस्ट होने वाले एक component से लेकर intended users के acceptance तक, हर एक के test object, test basis, आम defects और आम तौर पर करने वाले के साथ।

“Acceptance testing” परत पर: सबसे बड़ा scope: business context में पूरा system“Component testing” परत पर: सबसे छोटा scope: अकेला एक component

  1. 1Acceptance testingIntended users, product owner और operations staffObject: users की business needs के सामने system। Basis: business processes, acceptance criteria, contracts, regulations

    पकड़ता है: business में फ़िट न होने वाले workflows, गलत business rules, पूरी न हुई contract या regulation की शर्तें

  2. 2System integration testingTesters, दूसरे systems के owners के साथObject: external systems और services से interfaces। Basis: interface agreements, external API documentation

    पकड़ता है: inconsistent messages, handle न हुए timeouts, exchange होने वाले data के बारे में गलत assumptions

  3. 3System testingTesters, अक्सर independent teamObject: representative test environment में पूरा system। Basis: requirements, user stories, use cases

    पकड़ता है: requirements के उलट behaviour, पूरे न हो पाने वाले tasks, धीमे responses

  4. 4Component integration testingआम तौर पर developersObject: components के बीच interfaces और interactions। Basis: software design, API specifications

    पकड़ता है: interface mismatch, missing या गलत encoded data, data की गलत units

  5. 5Component testingआम तौर पर developersObject: अलग से एक function, class या module। Basis: detailed design, code

    पकड़ता है: गलत logic या calculations

बताए गए owners आम हैं, पक्के नियम नहीं। Iterative development में levels समय में overlap करते हैं, और कौन-से levels इस्तेमाल होंगे यह test plan बताता है।

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

हर level आम तौर पर कौन करता है

ये आम responsibilities हैं, पक्के नियम नहीं; agile teams में testers और developers अक्सर काम बाँटते हैं। लेकिन ownership नहीं खोनी चाहिए: test plan के हर level का एक नामित owner हो, और tester उन levels को भी review करता है जिनका वह owner नहीं, जैसे यह पूछकर कि integration tests किन चीज़ों को stubs से बदलते हैं।

  • Component और component integration testing: आम तौर पर developers, अपने environment और continuous integration (CI) में automated।
  • System testing: testers, अक्सर independent test team या delivery team के testers।
  • System integration testing: आम तौर पर testers, दूसरे systems के owners के साथ।
  • Acceptance testing: आदर्श रूप से intended users — business users, customers, product owner, या operational acceptance के लिए operations staff। Testers अक्सर तैयारी करते हैं और results दर्ज करते हैं; फ़ैसला business करता है।

आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर

Worked example: promo codes पाँचों levels पर

सऊदी अरब का एक online store promo codes जोड़ता है। Cart service promotions service को call करती है, और payment एक external gateway से होता है। हर bullet एक level लेता है: उस level का एक test और वह defect जो वह सबसे पहले पकड़ता है। ध्यान दें कि halalas और riyals वाला defect दोनों तरफ़ के component tests को नहीं दिखता, और acceptance वाला gap story से बने किसी भी test को नहीं दिखता।

  • Component: 199.99 SAR पर 10% की छूट 20.00 होनी चाहिए, लेकिन function 19.999 को round करने की बजाय काटकर 19.99 कर देता है।
  • Component integration: cart 19999 (halalas) भेजता है जबकि promotions service 199.99 (riyals) की उम्मीद करती है; दोनों अपने-अपने tests में pass थे।
  • System: पूरे checkout में VAT छूट से पहले लगता है, इसलिए customer ज़्यादा भुगतान करता है।
  • System integration: gateway के sandbox से टेस्ट करने पर gateway को original amount मिलता है, और timeout होने पर order बिना किसी message के "pending" में रह जाता है।
  • Acceptance: marketing team पाती है कि customer एक ही code बार-बार इस्तेमाल कर सकता है। Story में "हर customer के लिए एक बार" लिखा ही नहीं था, इसलिए सभी levels pass हुए — यह validation की finding है, जैसा verification और validation वाले lesson में देखा।
Story PROMO-12: Checkout पर promo codes
Customer के रूप में, मैं promo code डालना चाहता हूँ ताकि कम भुगतान करूँ।

AC1  Valid code items subtotal पर 10% की छूट देता है।
AC2  VAT (15%) छूट के बाद वाले subtotal पर लगता है।
AC3  Delivery fee पर छूट नहीं मिलती।
AC4  Amounts 2 decimal places तक round होते हैं (nearest halala)।
AC5  Expired या unknown code पर "यह code valid नहीं है" दिखता है।

आज़माएँ: Requirements → टेस्ट केस आज़माएँ: User Story → टेस्ट सिनेरियो

आम गलतियाँ

  • Performance या regression testing को test level कहना: performance testing एक test type है, regression testing किसी change के side effects जाँचती है, और दोनों किसी भी level पर हो सकती हैं।
  • सब कुछ system level पर user interface से टेस्ट करना, जहाँ feedback धीमा है और failures की जगह ढूँढना मुश्किल।
  • यह मान लेना कि हर component pass है तो system काम करेगा; stubs interface defects छिपा देते हैं।
  • External services को सिर्फ़ mocks से टेस्ट करना और system integration testing छोड़ देना।
  • Acceptance को intended users के साथ validation की बजाय उन्हीं testers का system testing दोहराना मान लेना।
  • System tests requirements की बजाय code से या developer के समझाए तरीके से लिखना।

QA का नज़रिया

Levels सबसे पहले test strategy और test plan में दिखते हैं, जो हर level के लिए objectives, test basis, environment, entry और exit criteria और owner तय करते हैं। किसी project से जुड़ते समय पूछें कि कौन-से levels हैं, हर एक का owner कौन है, हर level कहाँ चलता है और किन चीज़ों को stubs से बदलता है; जवाब gaps दिखाते हैं।

रोज़ के काम में हर bug report में वह level और environment लिखें जहाँ failure दिखा, और defect triage में, जहाँ नए defects review करके उनकी priority तय की जाती है, पूछें: "इसे किस level को पकड़ना चाहिए था?" System testing में बार-बार interface defects मिलने का मतलब है कि component integration testing कमज़ोर है, और user interface से मिला business rule का defect component test सुझाने की वजह है।

अभ्यास

Findings को सही test level पर रखें

आपका काम

एक clinic app appointments book करता है। Booking service एक internal scheduling component इस्तेमाल करती है, confirmations एक external SMS gateway से जाते हैं, और reception staff पूरे दिन app इस्तेमाल करता है।

नीचे की हर finding के लिए वह सबसे निचला test level बताएँ जिसे इसे पकड़ना चाहिए, वह test basis जिससे यह सामने आता, और वह level आम तौर पर कौन करता है।

सामग्री
Clinic booking: findings

1. toMinutes("09:30") 570 की जगह 560 लौटाता है।
2. Booking service तारीख 2026-03-04 भेजती है; scheduling component उसे
   4 मार्च की जगह 3 अप्रैल पढ़ता है।
3. दो patients एक ही slot दो phones से एक ही पल में book करते हैं और
   दोनों को confirmation मिलता है। (R3: हर slot में एक patient।)
4. SMS gateway 70 characters से लंबे Arabic messages reject करता है;
   app "Booked" दिखाता है और कोई SMS नहीं जाता।
5. Reception को cancel हुए slots के लिए waiting list चाहिए; किसी
   requirement में इसका ज़िक्र नहीं।
6. 200 users एक साथ book करें तो confirmation में 9 seconds लगते हैं।
   (R7: 200 concurrent users के साथ booking 3 seconds में confirm हो।)
चरण
  1. तय करें कि क्या टेस्ट हो रहा था: एक component, components के बीच interface, पूरा system, कोई external service, या business की ज़रूरत।
  2. वह सबसे निचला level चुनें जो defect देख सकता है।
  3. Test basis लिखें और यह भी कि वह level आम तौर पर कौन करता है।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

1 — Component testing; basis: function का design (09:30 = 570 minutes); developers।

2 — Component integration testing; basis: interface specification, जिसमें एक date format तय होना चाहिए, जैसे ISO 8601 YYYY-MM-DD; आम तौर पर developers।

3 — System testing; basis: requirement R3; testers, एक साथ दो devices से। वजह पता चलने के बाद developers एक component integration test जोड़ सकते हैं जो एक ही slot को parallel में दो बार book करे।

4 — System integration testing; basis: SMS provider का API documentation, error responses समेत; testers, integration owner के साथ। यह भी report करें कि भेजना fail होने पर app ने success दिखाया।

5 — Acceptance testing (UAT); basis: clinic का business process; reception staff और clinic manager। यह product owner के लिए requirements gap है, R1–R7 के against failure नहीं।

6 — System testing, non-functional (performance); basis: requirement R7; production जैसे environment में testers या performance specialists।

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

क्या unit testing और component testing एक ही हैं?

हाँ। ISTQB मुख्य term के रूप में component testing इस्तेमाल करता है, और उसकी glossary unit testing और module testing को इसके synonyms बताती है। "Unit" क्या है — function, class या module — यह team और programming language के हिसाब से बदलता है, इसलिए test strategy में इसे तय कर लें।

क्या end-to-end testing एक test level है?

CTFL v4.0 के पाँच levels में नहीं। Syllabus end-to-end tasks को system testing के अंदर रखता है, और teams अक्सर "end-to-end" उन journeys के लिए कहती हैं जो external systems से भी गुज़रती हैं, जिससे system integration testing भी जुड़ जाता है। इस module में आगे end-to-end testing का lesson इसे cover करता है।

क्या हर project को पाँचों levels चाहिए, इसी क्रम में?

नहीं। कौन-से levels इस्तेमाल होंगे यह product और उसके risks पर निर्भर है: बिना external services वाले standalone app में system integration level पर टेस्ट करने को कम होता है, जबकि खरीदे गए components से बना product integration और acceptance पर ध्यान दे सकता है। Iterative development में levels overlap करते हैं, और एक story एक ही sprint में कई levels से गुज़र सकती है। कौन-से levels लागू हैं, यह test plan बताता है।

SIT और UAT का क्या मतलब है?

SIT, system integration testing का आम abbreviation है; UAT का मतलब user acceptance testing है, जो acceptance testing का एक रूप है। कुछ organisations "SIT" किसी भी shared integration environment में होने वाली testing के लिए कहती हैं, इसलिए plan बनाने से पहले पता कर लें कि आपकी team इसका क्या मतलब लेती है।

संदर्भ

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

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

Requirements → टेस्ट केस

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

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

API कॉन्ट्रैक्ट वैलिडेटर

जाँचें कि कोई API रिक्वेस्ट/रिस्पॉन्स जोड़ा अपने OpenAPI कॉन्ट्रैक्ट का पालन करता है या नहीं: path, method, पैरामीटर, बॉडी और रिस्पॉन्स स्कीमा।

वैलिडेशन

और गहराई से

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

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