टेस्ट कवरेज

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

Coverage के बिना "हमने feature टेस्ट कर लिया" जाँचा नहीं जा सकता। कोई नहीं बता सकता कि किन acceptance criteria का कोई test नहीं है, कौन-से high risks कभी आज़माए ही नहीं गए, या कौन-सा code किसी test ने चलाया ही नहीं। यही gaps हैं जहाँ से defects production तक पहुँचते हैं।

Tester के लिए coverage मेहनत को ऐसे statement में बदलता है जिसे दूसरे जाँच सकें और जिस पर काम कर सकें: "सभी 14 acceptance criteria के tests pass हैं; 2 medium risks टेस्ट नहीं हुए क्योंकि payment sandbox बंद था"। यही exit criteria को नापने लायक बनाता है और team को एक बड़े number पर झूठे भरोसे से बचाता है।

Coverage किसका? Requirements, risks और code

Coverage number का तब तक कोई मतलब नहीं जब तक आप यह न बताएँ कि गिना क्या गया। तीन तरह की coverage तीन अलग सवालों का जवाब देती हैं, और ज़्यादातर teams को तीनों चाहिए।

• Requirements coverage: किन requirements या acceptance criteria के tests हैं, और किनके passing tests हैं। यहाँ coverage items test basis के criteria हैं, जिन्हें traceability से गिना जाता है: हर test उस criterion से linked हो जिसे वह check करता है।
• Risk coverage: पहचाने गए किन product risks के tests चले, और किनके tests pass हुए, risk level के हिसाब से report किया हुआ। "दोनों high risks टेस्ट हुए और pass हैं, 5 में से 2 medium risks अभी टेस्ट नहीं हुए" release decision में किसी अकेले percentage से बेहतर मदद करता है।
• Code coverage: tests के दौरान code के कौन-से हिस्से चले, जिसे एक tool नापता है। Statement coverage executable statements गिनता है; branch coverage branches गिनता है, यानी code में control के transfers, जिन्हें coverage tools decisions के outcomes के रूप में दिखाते हैं, जैसे किसी if के दोनों रास्ते। Branch coverage ज़्यादा मज़बूत है: 100% branch coverage में 100% statement coverage शामिल है, उल्टा नहीं।

Coverage items और उन्हें कैसे नापें

ISTQB Foundation syllabus v4.0 coverage को coverage items के ज़रिए नापता है: गिनी जा सकने वाली चीज़ें, जो किसी test technique को लागू करके test conditions से निकाली जाती हैं, जैसा test design activity वाले पाठ में देखा। Test design उन्हें पहचानता है; execution उन्हें exercise करता है। Formula कभी नहीं बदलता: coverage = items exercised ÷ items identified × 100%।

Percentage के साथ counts भी बताएँ ("12 में से 9 criteria") और वह build जिस पर यह लागू है। ISTQB की definition में कोई item covered माना जाता है जैसे ही कोई test उसे exercise कर ले, result चाहे जो हो, इसलिए requirements और risks के लिए दो numbers दें: वे items जिनका test उस build पर चला, और वे items जिनके tests pass हुए। सिर्फ़ दूसरा number बताता है कि item काम करता है: fail हुआ test अपने item को खुला छोड़ता है, और blocked या न चला test अभी कुछ exercise नहीं करता। Requirements और risk coverage test management tool या traceability matrix के links से आती है; code coverage एक tool से आती है जो tests चलते समय code को instrument करता है (उसमें counters जोड़ता है जो दर्ज करते हैं कि क्या चला), आम तौर पर CI pipeline में। एक view या technique से दूसरे तक जो बदलता है, वह item है:

• Requirements: acceptance criteria या अलग-अलग requirements।
• Risks: पहचाने गए risks, risk level के हिसाब से grouped।
• Equivalence partitioning: partitions। Boundary value analysis: boundary values।
• Decision tables: वे columns जिनमें conditions के संभव combinations हैं।
• State transitions: states, valid transitions या सभी transitions।
• Code: executable statements, या branches (coverage tools में हर decision का हर outcome)।

आज़माएँ: Requirements → टेस्ट केस आज़माएँ: स्टेट ट्रांज़िशन जनरेटर

Worked example: एक feature के चार coverage numbers

Checkout का एक feature discount code लागू करता है। Acceptance criteria: AC1, valid code total को अपने percentage से घटाता है; AC2, expired code एक साफ़ message के साथ reject होता है; AC3, codes सिर्फ़ 100.00 SAR या उससे ज़्यादा के totals पर लागू होते हैं; AC4, हर order में एक code। Product risks: R1 (high) एक order पर code दो बार लग जाना; R2 (high) expired code स्वीकार हो जाना; R3 (medium) 100.00 की threshold गलत तरफ़ लागू होना।

Developer ने discount function के लिए एक unit test लिखा; tester ने build 57 पर तीन system tests चलाए, जिनमें TC-03 ने 99.99 और 100.00 के totals check किए। Code और reports नीचे हैं। हर number क्या कहता है:

• Statement coverage 100% (4 में से 4): unit test में applyDiscount का हर statement चला, फिर भी किसी unit test ने 100.00 से कम का total नहीं आज़माया।
• Branch coverage 50% (2 में से 1): total >= 100 का false outcome कभी नहीं चला। 99.99 total वाला एक unit test इसे cover कर देगा।
• Acceptance criteria: 4 में से 3 का test है (75%), लेकिन 4 में से सिर्फ़ 2 का passing test है (50%)। TC-02 fail हुआ और AC4 का कोई test नहीं है।
• Risks: 3 में से 2 का test है, लेकिन 3 में से सिर्फ़ 1 का passing test है, और किसी भी high risk का नहीं: R1 का कोई test नहीं और R2 का test fail हुआ। Release decision को यही number चाहिए।
• applyDiscount में "हर order में एक code" को handle करने वाला कुछ नहीं है। अगर AC4 कभी implement ही नहीं हुआ, तो कोई code coverage report इसे नहीं दिखा सकती: tool सिर्फ़ मौजूद code नापता है।

// discount.ts
export function applyDiscount(total: number, percent: number): number {
  let result = total;
  if (total >= 100) {
    result = total - (total * percent) / 100;
  }
  return result;
}

// discount.test.ts (Jest): the only unit test
import { applyDiscount } from './discount';

test('10% off an order of 150', () => {
  expect(applyDiscount(150, 10)).toBe(135);
});

Code coverage (unit tests)   Statements   Branches
discount.ts                  4/4  100%    1/2  50%

Traceability, system tests on build 57
Criterion   Test     Result     Risk
AC1         TC-01    passed     -
AC2         TC-02    failed     R2 (high)
AC3         TC-03    passed     R3 (medium)
AC4         -        no test    R1 (high)

आज़माएँ: Requirements → टेस्ट केस आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर

100% coverage का मतलब bug-free क्यों नहीं

Coverage बताता है कि list का कितना हिस्सा exercise हुआ, यह नहीं कि list पूरी थी, tests ने सही चीज़ें check कीं, या software सही है। Testing के सात principles में से दो यहाँ लागू होते हैं: testing defects की मौजूदगी दिखाती है, उनकी गैरमौजूदगी नहीं, और exhaustive testing असंभव है।

• Denominator में सिर्फ़ वही है जो आपने पहचाना। छूटी हुई requirement या list से बाहर का risk कभी percentage में नहीं दिखता, इसलिए अधूरी list की 100% coverage भी अधूरी ही है।
• Execute करना check करना नहीं है। बिना assertion (result की कोई जाँच नहीं) वाला test जो applyDiscount(150, 10) call करता है, वही 100% statement coverage देता है जो result 135 check करने वाला test देता है।
• Data मायने रखता है। applyDiscount(150, 110) negative total लौटाता है, और पूरी branch coverage भी इसे नहीं पकड़ती। Syllabus का अपना उदाहरण ऐसा division है जो सिर्फ़ तब fail होता है जब divisor zero हो।
• Code coverage omissions नहीं देख सकता: जो code लिखा ही नहीं गया, उसमें छूटने लायक कोई statement नहीं होता।
• Target एक खेल बन सकता है: लोग ऐसे tests जोड़ते हैं जो code चलाते हैं पर कुछ check नहीं करते। Assertions का review, या mutation testing (code में छोटे जान-बूझकर किए गए बदलाव जिन्हें अच्छा test suite पकड़ना ही चाहिए), यह जानने में मदद करते हैं कि covered code सच में check हो रहा है या नहीं।

आज़माएँ: AI टेस्ट कवरेज एनालाइज़र

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

संदर्भ

• 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सॉफ़्टवेयर टेस्टिंग का अंतरराष्ट्रीय मानक: अवधारणाएँ, प्रक्रियाएँ, दस्तावेज़ीकरण और तकनीकें।