स्मोक, सैनिटी और रिग्रेशन टेस्टिंग में अंतर

Smoke, sanity और regression एक नज़र में

• सवाल — Smoke: क्या हम यह build टेस्ट कर सकते हैं? Sanity: क्या यह बदलाव सही दिखता है? Regression: क्या इस बदलाव ने कुछ और तोड़ा?
• दायरा — Smoke: चौड़ा और उथला, पूरे प्रोडक्ट के अहम रास्ते। Sanity: संकरा और गहरा, सिर्फ़ बदला हुआ हिस्सा। Regression: चौड़ा और गहरा, जो कुछ भी बदलाव से प्रभावित हो सकता है, पूरे सूट तक।
• कब — Smoke: हर build या डिप्लॉयमेंट के तुरंत बाद। Sanity: fix या छोटे बदलाव के बाद, व्यापक टेस्टिंग से पहले। Regression: किसी भी बदलाव के बाद, रिलीज़ से पहले, और शेड्यूल पर।
• अवधि — Smoke: मिनट। Sanity: मिनटों से एक घंटे तक। Regression: मिनटों (चुना हुआ उपसमूह) से घंटों (पूरा सूट) तक।
• Scripted या नहीं — Smoke: scripted और आदर्श रूप से पूरी तरह ऑटोमेटेड। Sanity: अक्सर आंशिक रूप से unscripted, बदलाव से निर्देशित। Regression: scripted, और ऑटोमेशन का मुख्य लक्ष्य।
• फ़ेल होने का नतीजा — Smoke: build अस्वीकार, आगे टेस्टिंग नहीं। Sanity: बदलाव वापस, व्यापक टेस्टिंग स्थगित। Regression: दोष दर्ज; गेट कहे तो रिलीज़ रुकी।

Smoke testing: क्या build टेस्ट करने लायक है?

Smoke टेस्ट जाँचों का एक छोटा सेट है जो सिस्टम के सबसे अहम फ़ंक्शन को शुरू से अंत तक कवर करता है, हर नए build या डिप्लॉयमेंट पर चलता है, और तय करता है कि build आगे की टेस्टिंग के लिए पर्याप्त स्थिर है या नहीं। नाम हार्डवेयर से आया है: डिवाइस चालू करो और देखो कि धुआँ निकलता है या नहीं। सॉफ़्टवेयर में smoke फ़ेलियर का मतलब है कि कुछ बुनियादी ग़लत है — एप्लिकेशन शुरू नहीं होता, कोई सर्विस अपने डेटाबेस तक नहीं पहुँचती, लॉगिन टूटा है, कोई कॉन्फ़िगरेशन वैल्यू ग़ायब है — और हर बाद का टेस्ट इसी कारण फ़ेल होगा।

अच्छा smoke सूट छोटा, स्थिर और सिर्फ़ critical-path वाला होता है। यह हर बड़े component को एक बार छूता है, बारीक दोष खोजने की कोशिश नहीं करता, और कभी उस डेटा पर निर्भर नहीं होता जिसे दूसरे टेस्ट बदलते हैं। चूँकि यह बहुत बार चलता है, flaky smoke टेस्ट ख़ास तौर पर नुक़सानदेह है; उसे तुरंत ठीक करें या हटाएँ। रिलीज़ के बाद प्रोडक्शन पर चलाया गया यही सूट post-deployment वेरिफ़िकेशन का केंद्र है।

Smoke suite: web shop, build under test on staging (example)

[ ] GET /health returns 200 for web, orders, pricing, payments services
[ ] Home page loads; no console errors; main navigation renders
[ ] Log in with the smoke test account (smoke.user@example.com)
[ ] Search returns results for a known product
[ ] Add a known product to the cart; cart total is shown
[ ] POST /api/v1/orders with a fixed payload returns 201
[ ] Payment sandbox call returns an authorised result
[ ] Invoice endpoint returns 200 with Content-Type application/pdf

Rule: any failure -> build rejected, deeper testing does not start.
Budget: under 5 minutes, fully automated, runs on every deployment.

आज़माएँ: API हेल्थ चेकर

Sanity testing: एक से ज़्यादा अर्थों वाला शब्द

तीनों में sanity testing की परिभाषा सबसे कम सुसंगत है, और इसके उलट दिखावा करने के बजाय यह साफ़ कह देना बेहतर है। सबसे आम इस्तेमाल में इसका मतलब है नए build पर किसी ख़ास बदलाव — बग fix, छोटा फ़ीचर, कॉन्फ़िगरेशन बदलाव — की तेज़, केंद्रित जाँच, ताकि टीम व्यापक टेस्टिंग में समय लगाने से पहले पुष्टि कर सके कि बदलाव समझदारी से व्यवहार करता है। इस अर्थ में यह संकरी और गहरी है जहाँ smoke testing चौड़ी और उथली है, और इसमें अक्सर ठीक हुए दोष का confirmation टेस्ट शामिल होता है।

दूसरी टीमें और कुछ पुरानी glossaries "sanity test" को smoke test का पर्याय मानती हैं। कुछ और लोग इसे किसी भी तेज़ plausibility जाँच के लिए अनौपचारिक रूप से इस्तेमाल करते हैं, जैसे यह देखना कि किसी रिपोर्ट का कुल विश्वसनीय दायरे में है। इनमें से कोई भी अपने संदर्भ में ग़लत नहीं, पर एक ही टीम में इन्हें मिलाने से असली समस्याएँ होती हैं: मैनेजर "sanity पास हुई" सुनकर मान लेता है कि जितना जाँचा गया उससे ज़्यादा जाँचा गया। व्यावहारिक हल है अपनी test strategy या test plan में शब्द को परिभाषित करना — यह क्या कवर करता है, कौन चलाता है, कितना समय लगता है — और उसे सुसंगत रूप से इस्तेमाल करना। अगर शब्द उलझन पैदा करे तो उसकी जगह वर्णनात्मक नाम इस्तेमाल करें, जैसे "fix verification"।

• आम अर्थ: नए build पर बदले हिस्से की केंद्रित जाँच, व्यापक टेस्टिंग से पहले।
• वैकल्पिक अर्थ: smoke testing का दूसरा नाम।
• अनौपचारिक अर्थ: किसी आउटपुट की तेज़ plausibility जाँच।
• सुझाव: अपनी टीम की परिभाषा लिखें और उस पर टिके रहें।

Regression testing: क्या बदलाव ने कुछ और तोड़ा?

Regression testing बदलाव के बाद मौजूदा टेस्ट दोबारा चलाती है ताकि पता चले कि सॉफ़्टवेयर के उन हिस्सों में दोष आए या उजागर हुए जिन्हें बदलना नहीं था। ISTQB फ़ाउंडेशन सिलेबस इसे confirmation testing से अलग करता है: confirmation testing जाँचती है कि रिपोर्ट किया गया दोष सचमुच ठीक हुआ; regression testing जाँचती है कि fix, या कोई और बदलाव, कोई बुरा असर नहीं डाल गया — न बदले गए component में, न दूसरे components में, न जुड़े हुए systems में। हर fix के बाद दोनों ज़रूरी हैं।

Regression testing को ट्रिगर करने वाले बदलावों में नए फ़ीचर, बग fix, refactoring, dependency और framework अपग्रेड, कॉन्फ़िगरेशन बदलाव, इन्फ़्रास्ट्रक्चर और डेटाबेस migrations शामिल हैं। चूँकि regression टेस्ट कई बार दोहराए जाते हैं और उनके अपेक्षित नतीजे ज्ञात होते हैं, वे ऑटोमेशन के स्वाभाविक उम्मीदवार हैं, और ज़्यादातर regression सूट CI pipeline में रहते हैं। किस स्तर पर — यूनिट, API या UI — क्या ऑटोमेट हो, यह test pyramid के अनुसार है और manual बनाम automated testing गाइड में कवर है।

• Confirmation टेस्ट (re-test) — मूल दोष के स्टेप अब पास होते हैं।
• Regression टेस्ट — बदलाव के आसपास और उससे आगे के टेस्ट अब भी पास होते हैं।
• Regression सूट प्रोडक्ट के साथ बढ़ता है; रखरखाव के बिना यह धीमा, दोहराव वाला और flaky हो जाता है।

Regression चयन: क्या चलाएँ

हर बदलाव पर हर टेस्ट चलाना सबसे सुरक्षित विकल्प है और छोटे सूट के लिए सही भी। जब सूट pipeline स्टेज के समय-बजट से बड़ा हो जाता है, टीम को चुनना पड़ता है। चयन जोखिम का फ़ैसला है, इसलिए यह स्पष्ट और समीक्षा-योग्य हो, टेस्टर की इस याद पर आधारित नहीं कि "आमतौर पर क्या टूटता है"।

• Retest all — पूरा सूट चलाएँ। सबसे ज़्यादा भरोसा, सबसे ज़्यादा लागत; nightly runs और release candidates के लिए आम विकल्प।
• Impact-आधारित चयन — जो बदला (फ़ाइलें, modules, APIs, डेटाबेस टेबल, कॉन्फ़िगरेशन) वहाँ से शुरू करें और उन हिस्सों और उनकी सीधी निर्भरताओं को चलाने वाले टेस्ट शामिल करें। Test impact analysis टूल टेस्ट को कोड से जोड़कर, आमतौर पर कवरेज डेटा से, इसे ऑटोमेट करते हैं।
• जोखिम-आधारित चयन — ऊँचे बिज़नेस प्रभाव या दोषों के इतिहास वाले हिस्सों के टेस्ट जोड़ें, भले बदलाव उनसे असंबंधित लगे: पेमेंट, ऑथेंटिकेशन, डेटा एक्सपोर्ट।
• Prioritisation — चुने गए टेस्ट ऐसे क्रम में रखें कि सबसे मूल्यवान पहले चलें: हाल में फ़ेल हुए टेस्ट, बदले कोड के टेस्ट, अहम यात्राएँ। तब फ़ेलियर जल्दी सामने आता है।
• हमेशा शामिल कोर — smoke जाँचें और कुछ अहम end-to-end यात्राएँ चयन से स्वतंत्र हर बदलाव पर चलती हैं।
• सुरक्षा-जाल — हर बदलाव का चयन जो छोड़ता है, उसे scheduled पूरा run कवर करता है, ताकि चयन की ग़लती रिलीज़ पर नहीं, एक दिन के भीतर पकड़ी जाए।

आज़माएँ: रिग्रेशन सिनेरियो जनरेटर आज़माएँ: AI रिग्रेशन टेस्ट जनरेटर आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर

CI/CD pipeline में हर एक कहाँ चलता है

Pipeline में ये तीनों अलग-अलग लोगों द्वारा किए जाने वाले अलग चरण नहीं हैं; ये अलग-अलग triggers से जुड़े सूट हैं। नीचे का ढाँचा आम है और ज़्यादातर वेब प्रोडक्ट्स के लिए काम करता है।

• Pull request — commit-stage जाँचें और यूनिट व API स्तर पर चुना हुआ regression उपसमूह (impact और जोखिम आधारित); अहम E2E यात्राएँ।
• Main में merge — पूरे यूनिट और API regression सूट; E2E सूट पैरलल shards में।
• टेस्ट एनवायरनमेंट में हर डिप्लॉयमेंट — पहले smoke सूट; उसके पास होने तक और कुछ शुरू नहीं होता।
• Fix डिप्लॉय होने के बाद — दोष रिपोर्ट करने वाले टेस्टर द्वारा sanity (fix verification), confirmation टेस्ट समेत।
• Nightly — सभी स्तरों पर पूरा regression सूट, और लंबे non-functional runs।
• Release candidate — पूरा regression हरा, फिर रिलीज़ के तुरंत बाद प्रोडक्शन पर smoke।

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

हल किया गया उदाहरण: VAT rounding fix

उदाहरण के लिए, एक ग्राहक रिपोर्ट करता है कि डिस्काउंट वाले इनवॉइस में VAT एक हलाला ग़लत दिखता है। डेवलपर pricing सर्विस में rounding ठीक करते हैं; यह fix VAT गणना को छूता है, जिसका इस्तेमाल refunds, credit notes और order history भी करते हैं। नीचे का प्लान दिखाता है कि build 5.8.1 पर तीनों तरह की टेस्टिंग काम कैसे बाँटती है।

• Smoke (ऑटोमेटेड, लगभग 3 मिनट): क्या यह build टेस्ट भी किया जा सकता है? web, pricing और invoice सर्विसों का /health 200 लौटाता है; टेस्ट ग्राहक से लॉगिन करके item जोड़ना और checkout तक पहुँचना; API से ऑर्डर बनाने पर 201; invoice PDF endpoint 200 और application/pdf लौटाता है।
• Sanity (केंद्रित, लगभग 20 मिनट): क्या fix ख़ुद सही है? 100.00 SAR पर 10% डिस्काउंट से subtotal 90.00, 15% VAT 13.50 और total 103.50; 3 × 33.33 SAR पर 5% डिस्काउंट के totals spec के rounding नियम के अनुसार; invoice PDF में वही VAT जो order API के response में है; मूल बग रिपोर्ट के स्टेप अब दोष नहीं दोहराते (confirmation टेस्ट)।
• Regression (चुना हुआ): क्या कुछ और टूटा? ज़रूरी: pricing के सभी यूनिट और API सूट, invoice API सूट, checkout की E2E यात्राएँ। चलाने चाहिए: refunds और credit notes, promo codes, order history के totals, क्योंकि ये सब VAT इस्तेमाल करते हैं। छोड़ें: profile, notifications और search, जो pricing पर निर्भर नहीं। बाद में: हर रात की तरह nightly run में पूरा regression सूट।

Change: fix VAT rounding on invoices that have a discount (pricing service, invoice PDF)
Build: 5.8.1 on staging

1. SMOKE (automated, about 3 min): can this build be tested at all?
   [x] /health 200 for web, pricing and invoice services
   [x] log in with the test customer, add an item, reach checkout
   [x] create order via API -> 201
   [x] invoice PDF endpoint -> 200, application/pdf

2. SANITY (focused, about 20 min): is the fix itself right?
   [x] 100.00 SAR, 10% discount -> subtotal 90.00, VAT 15% 13.50, total 103.50
   [x] 3 x 33.33 SAR, 5% discount -> totals follow the rounding rule in the spec
   [x] invoice PDF shows the same VAT as the order API response
   [x] steps of the original bug report no longer reproduce (confirmation test)

3. REGRESSION (selected): did anything else break?
   must    pricing unit + API suites (all), invoice API suite, checkout E2E journeys
   should  refunds and credit notes, promo codes, order-history totals (all use VAT)
   skip    profile, notifications, search (no dependency on pricing)
   later   full regression suite in the nightly run, as every night

आम गलतियाँ

• हरे smoke run को रिलीज़ की मंज़ूरी मान लेना। Smoke बताता है कि build टेस्ट करने लायक है, यह नहीं कि वह सही है।
• Smoke सूट को आधे घंटे तक बढ़ने देना; तब वह हर डिप्लॉयमेंट पर चलना बंद हो जाता है।
• क्या जाँचा यह बताए बिना "sanity पास" रिपोर्ट करना।
• सिर्फ़ confirmation टेस्ट के बाद दोष बंद करना, fix के आसपास कोई regression किए बिना।
• बदलाव और लिखी हुई जोखिम-सूची के बजाय याद से regression टेस्ट चुनना।
• Regression सूट की कभी छँटाई न करना: दोहराए गए टेस्ट, हटाए गए फ़ीचर्स के टेस्ट और स्थायी रूप से skip टेस्ट हर run में समय लेते हैं।
• Scheduled पूरा run छोड़ देना क्योंकि हर बदलाव का चयन "अब तक ठीक रहा है"।

आज़माएँ: AI डुप्लिकेट टेस्ट केस डिटेक्टर

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

संदर्भ

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
• ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
• The Practical Test Pyramid (Ham Vocke)martinfowler.com · 2018ऑटोमेटेड टेस्ट पोर्टफ़ोलियो में unit, integration, contract और UI टेस्ट का संतुलन कैसे रखें — व्यापक रूप से उद्धृत व्याख्या।
• Continuous Integration (Martin Fowler)martinfowler.com · 2024continuous integration का व्यापक रूप से संदर्भित विवरण: बार-बार integrate करें, build को self-testing और तेज़ रखें, टूटा build तुरंत ठीक करें।