मॉड्यूल 6 · टेस्ट सिनेरियो और टेस्ट केस

टेस्ट एनवायरनमेंट

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

Test environment वह सब कुछ है जिस पर कोई test चलता है। ISTQB glossary इसे test करने के लिए ज़रूरी hardware, instrumentation, simulators, software tools और दूसरे support elements के रूप में बताती है। कुछ teams इसे test bed भी कहती हैं।

एक ही build दो environments में अलग व्यवहार कर सकता है: जो refund form staging पर 4 MB की receipt स्वीकार करता है, वह production में उसे reject कर सकता है, जहाँ application के आगे लगा एक server upload size सीमित करता है। इसलिए result का अर्थ उसके environment के साथ ही है: "staging पर build 3.8.0 में pass" evidence है; सिर्फ़ "pass" नहीं।

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

Teams production के बाहर test करती हैं, और इसकी ठोस वजहें हैं: customers को अधूरा काम नहीं दिखना चाहिए, और tests को असली पैसा या असली personal data नहीं छूना चाहिए। लेकिन production से हर फ़र्क ऐसी जगह है जहाँ कोई defect सारे tests pass करके customers तक पहुँच सकता है, या कोई test product से असंबंधित वजहों से fail हो सकता है।

Environment की जानकारी tester को बताती है कि failure product defect है या environment की समस्या, और pass असली evidence है या नहीं। जो tester बता सके कि क्या कहाँ test हुआ और production में क्या अलग है, वह team को बचे हुए risk की सच्ची तस्वीर देता है।

Test environment किन चीज़ों से बनता है

इसे test हो रहे build के चारों ओर layers की तरह सोचें; tests plan करते या defect report करते समय हर layer एक सवाल है जिसका जवाब आपको पता होना चाहिए।

  • Build: test हो रहे हर component का exact version, जैसे web 3.8.0, build 214।
  • Infrastructure: servers या containers, operating system, instances (application की चल रही copies) की संख्या; client की तरफ़ browsers और devices।
  • Configuration: वे settings जो code बदले बिना व्यवहार बदलती हैं, जैसे feature flags, time zone, locale और limits।
  • Dependencies: databases, queues और payment या SMS जैसी third-party services, हर एक या तो असली, provider का sandbox (service का test version, जिसे provider खुद चलाता है), या stub।
  • Data और access: test data का baseline और accounts, साथ में वे logs जिन्हें आप पढ़ सकें।

Dev, test, staging और production

ज़्यादातर teams किसी बदलाव को environments की एक chain से गुज़ारती हैं, जिसमें हर अगला environment पिछले से production के ज़्यादा क़रीब होता है। ये नाम industry का चलन हैं, ISTQB terms नहीं, और बदलते रहते हैं: test environment को QA या SIT, और staging को pre-production या UAT कहा जा सकता है, और छोटी teams के पास अक्सर development और production के बीच एक ही environment होता है।

अच्छी chain में build एक बार बनता है और वही build आगे promote होता है; सिर्फ़ configuration बदलती है। अगर हर environment को अपना अलग build मिले, तो staging का pass production के बारे में कम ही बताता है। कोई fix एक नया build बनाता है, जो फिर से पूरी chain से गुज़रता है।

  • Development: developers की अपनी machines, कभी-कभी एक shared development server भी; mocked dependencies के साथ component (unit) tests; सबसे तेज़ feedback, और production से सबसे दूर।
  • Test (QA): testers का shared environment, reset हो सकने वाले synthetic data पर system और integration testing के लिए; नए builds अक्सर आते हैं।
  • Staging: versions, topology और data volume में जितना हो सके production जैसा; release और acceptance testing और deployment के rehearsal के लिए।
  • Production: असली users, data और पैसा; यहाँ deployment के बाद सिर्फ़ planned, non-destructive checks, test accounts से।
  • कई pipelines हर pull request के लिए एक short-lived environment भी बनाती हैं।
बदलाव development से test और staging होते हुए production तक जाता है; test से आगे एक ही build promote होता है और सिर्फ़ उसकी configuration बदलती है, और हर पड़ाव पिछले से production के ज़्यादा क़रीब है।
  1. 1Developmentlocal, devDevelopers की machines: component (unit) tests, mocked dependencies

    गेट: merge होकर एक बार build

  2. 2Testइसे QA या SIT भी कहते हैंReset हो सकने वाले synthetic data पर system और integration testing3.8.0+214

    गेट: वही build promote होता है; सिर्फ़ configuration बदलती है

  3. 3Stagingइसे pre-production या UAT भी कहते हैंजितना हो सके production जैसा: release और acceptance testing, deployment rehearsal3.8.0+214

    गेट: release decision

  4. 4Productionअसली users, data और पैसा: deployment के बाद सिर्फ़ planned, non-destructive checks3.8.0+214

चरण 1 पर वापस किसी भी पड़ाव पर defect: fix, फिर नया build पूरी chain से गुज़रता है

सबसे तेज़ feedback, production से सबसे दूरअसली इस्तेमाल के सबसे क़रीब, defect मिलने की सबसे महँगी जगह

क्रम से बाहर
  • हर pull request के लिएShort-lived environment, pull request merge या close होने पर हटा दिया जाता है

Environments के नाम और संख्या टीम-दर-टीम अलग होते हैं।

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

Configuration, versions और dependencies

एक ही build चलाने वाले दो environments configuration में, build के आसपास के software के versions में, और उन dependencies में अलग होते हैं जिन्हें वह call करता है। जब कोई चीज़ एक जगह चले और दूसरी जगह नहीं, तो पहले इन्हीं की तुलना करें, और इन्हें environment record या version page में record करें।

ऐसे record की हर line सीमित करती है कि आपके tests क्या साबित करते हैं: अगर staging SMS एक stub को भेजता है, तो आपने साबित किया कि application message भेजने को कहता है, यह नहीं कि customer को वह मिलता है।

ISTQB syllabus test environment को एक configuration item मानता है: configuration management उसके हिस्सों, उनके आपसी संबंधों और उनके versions को दर्ज करता है। Testing के लिए approve होने के बाद यह record एक baseline बन जाता है, जो सिर्फ़ change control से बदलता है, ताकि पिछले results दोबारा reproduce किए जा सकें।

  • Configuration आम तौर पर build के बाहर, environment variables या files में रहती है, इसलिए वह environments के बीच बिना किसी के ध्यान दिए drift कर सकती है।
  • पूरे versions लिखें: PostgreSQL 16 और PostgreSQL 16.4 अलग records हैं।
  • Test करने से पहले deployed build जाँचें: कई applications उसे about page पर या version या health endpoint पर दिखाते हैं।
  • Sandboxes अक्सर असली service से तेज़ और ज़्यादा predictable जवाब देते हैं।

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

Environment parity की समस्याएँ

Environment parity का मतलब है कि environments production से जितना कम हो सके उतना अलग हों, और सिर्फ़ उन बातों में जो आपको पता हों। Continuous integration पर Martin Fowler का लेख production environment के clone में test करने की सलाह देता है; Twelve-Factor App इस लक्ष्य को dev/prod parity कहता है और तीन gaps छोटे रखने को कहता है: समय, लोग और tools।

Gaps दोनों दिशाओं में गलत results देते हैं: false pass (यानी false negative), जब environment किसी defect को छिपा लेता है, और false failure (यानी false positive), जब पुराना build या बंद पड़ा sandbox product defect के रूप में report हो जाता है। पूरी parity शायद ही संभव होती है, इसलिए ज्ञात फ़र्कों का लक्ष्य रखें: हर gap जो बदलाव पर असर डाल सकता है, या तो बंद हो, या किसी और तरीके से test हो, या risk के रूप में record हो।

  • Time zone: 20:00 का cut-off गलत घड़ी पर test होता है।
  • Test में एक instance, production में कई: एक server पर रखी files या sessions ग़ायब हो जाते हैं।
  • कम data: जो report 5,000 rows पर तुरंत खुलती है, वह दस लाख rows पर time out हो जाती है।

आज़माएँ: Timezone कन्वर्टर

Worked example: staging पर pass हुआ receipt upload

Release 3.8.0 में customers refund request के साथ 5 MB तक की receipt attach कर सकते हैं। Staging पर सभी 18 test cases pass हुए। Sign-off से पहले tester दोनों environment records की तुलना करता है।

Build एक ही है, इसलिए जो test हुआ वही ship होगा। इस बदलाव के लिए तीन फ़र्क मायने रखते हैं:

  • 2 MB की proxy limit: production में एक reverse proxy, यानी application के आगे खड़ा एक server, इससे बड़ी requests reject करता है। 2 MB से बड़ी receipts staging पर pass हुईं, लेकिन production उन्हें reject करेगा, आम तौर पर HTTP status 413 (Content Too Large) के साथ, application के अपना message दिखा पाने से पहले ही। इसे अभी DevOps के सामने उठाएँ।
  • Local disk पर files रखने वाला एक instance, बनाम load balancer के पीछे shared object storage इस्तेमाल करने वाले तीन instances; load balancer requests को उनके बीच बाँटता है: production जो storage इस्तेमाल करता है, वह कभी exercise ही नहीं हुआ, और क्योंकि receipt का upload और display अलग-अलग servers पर पहुँच सकते हैं, जो कुछ अब भी एक server की disk पर रखा जाता है वह ग़ायब मिलेगा। Staging पर दो instances और shared storage के साथ एक run माँगें, या deployment के तुरंत बाद check करें।
  • Production में flag off: उसे on करना अपने risk वाला configuration change है। Flag off के साथ भी test करें, और तय करें कि उसे कौन on करेगा।
  • Payment, SMS और data volume भी अलग हैं, लेकिन यह बदलाव उनका इस्तेमाल नहीं करता: उन्हें known differences के रूप में record करें।
Item              staging                  production
----------------  -----------------------  ---------------------------
Build             web 3.8.0+214            web 3.8.0+214
App instances     1                        3, behind a load balancer
Reverse proxy     none                     request body limit 2 MB
File storage      local disk               shared object storage
Database          PostgreSQL 16.4          PostgreSQL 16.4
Time zone         Asia/Riyadh              Asia/Riyadh
refund_receipts   flag on                  flag off until release day
Payment           provider sandbox         live provider
SMS               stub, records messages   live provider
Orders in DB      5,000 synthetic          1.2 million real

आज़माएँ: API रिस्पॉन्स कम्पेरेटर

आम गलतियाँ

  • Build और environment के बिना सिर्फ़ "pass" लिखना।
  • Staging को production-like कहना, जबकि उसकी production से कभी तुलना ही नहीं हुई।
  • पुराने build या बंद पड़े sandbox को product defect के रूप में report करना, या असली defect को "बस environment की बात है" कहकर टाल देना।
  • Test cycle के बीच में shared environment को redeploy करना, उस पर test कर रहे लोगों को बताए बिना।
  • Sandbox या stub के सामने मिले pass को असली integration के काम करने का सबूत मान लेना।
  • Production को test environment की तरह इस्तेमाल करना, असली orders, असली customers या असली personal data के साथ।

QA का नज़रिया

Environments आम तौर पर testers के नहीं, developers या DevOps engineers के होते हैं। Tester बताता है कि tests को क्या चाहिए और test planning में ही पूछता है: कौन-सा environment और कौन-सा build, क्या shared है, टूटने पर कौन ठीक करेगा, और यह production से कैसे अलग है? जैसा test design और test implementation के lessons में देखा, ये ज़रूरतें test environment requirements बनती हैं, और execution से पहले environment build करके verify किया जाता है। ISO/IEC/IEEE 29119-3 test environment requirements का document और test environment readiness report परिभाषित करता है; agile teams यही जवाब test plan या team wiki में रखती हैं।

हर result और defect report में build और environment लिखें (ISTQB syllabus defect report की सामग्री में test object और test environment की पहचान गिनाता है), और जब एक साथ बहुत से tests fail हों तो पहले environment जाँचें। Known differences की list release decision तक ले जाएँ: "staging पर pass; 2 MB से बड़े uploads production proxy के सामने untested" जैसा वाक्य team को खुली आँखों से फ़ैसला करने देता है।

अभ्यास

Delivery slot release में parity gaps खोजें

आपका काम

Release 5.2.0 में customers अगले दिन का delivery slot book कर सकते हैं। Booking रियाद समय के अनुसार 20:00 बजे बंद होती है, हर slot में ज़्यादा से ज़्यादा 40 bookings होती हैं, और confirmation SMS Arabic या English में भेजा जाता है। Test environment में सारे tests pass हुए। नीचे के records में कौन-से फ़र्क production को आपके test किए व्यवहार से अलग बना सकते हैं?

सामग्री
Item              test environment         production
----------------  -----------------------  ---------------------------
Build             web 5.2.0+87             web 5.2.0+87
App instances     1                        2, behind a load balancer
Time zone         UTC                      Asia/Riyadh
Database          PostgreSQL 16.2          PostgreSQL 16.4
delivery_slots    flag on                  flag off until release day
SMS               stub, records messages   live provider
Orders in DB      2,000 synthetic          1.2 million real
चरण
  1. हर वह line लिखें जिसमें दोनों environments अलग हैं।
  2. हर फ़र्क के लिए तय करें कि क्या वह इस release के किसी test result को बदल सकता है।
  3. जो बदल सकते हैं, उनके लिए चुनें: environment को match कराएँ, किसी और तरीके से test करें, या risk record करें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Build एक ही है, यह अच्छा है। छह lines अलग हैं।

Time zone (high risk): cut-off UTC पर test हुआ, जो रियाद से तीन घंटे पीछे है। Environment को Asia/Riyadh पर चलाएँ और tests रियाद समय के 19:59 और 20:00 पर दोबारा चलाएँ।

Instances (high risk): 40 bookings की limit तब भी टिकनी चाहिए जब दो customers आख़िरी जगह अलग-अलग servers से book करें। पूछें कि limit कैसे लागू होती है, और दो instances पर एक साथ bookings test करें।

Feature flag (medium): flag off के साथ checkout test करें, और तय करें कि उसे कौन on करेगा।

SMS stub (medium): delivery साबित नहीं हुई; risk record करें, और release के बाद team के test numbers पर एक Arabic और एक English SMS check करें।

Data volume (medium): पूछें कि available slots की गणना production जितने data पर जाँची गई या नहीं। Database 16.2 बनाम 16.4 (low): उसी major version के अंदर minor release; इसे record करें।

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

क्या हम production में test कर सकते हैं?

कुछ checks जानबूझकर वहीं होते हैं: deployment के तुरंत बाद smoke tests और health checks, monitoring, और canary releases जैसी धीरे-धीरे होने वाली releases। ये planned और non-destructive होते हैं, test accounts इस्तेमाल करते हैं और team की सहमति से होते हैं। Production में testing release से पहले की testing को पूरा करती है, उसकी जगह नहीं लेती, और test तैयार करने के लिए कभी असली customers का data या पैसा इस्तेमाल नहीं करती।

क्या हर team को चारों environments चाहिए?

नहीं। संख्या risk, team size और लागत पर निर्भर है। छोटी team के पास local development, एक shared test environment और production हो सकते हैं; regulated product performance या acceptance testing के लिए अलग environments जोड़ सकता है। हर team को चाहिए एक ऐसी जगह जहाँ build ज़रूरी risks के लिए production के काफ़ी क़रीब हालात में test हो, और फ़र्कों की एक साफ़ list।

Test मेरी machine पर pass और test environment में fail क्यों होता है?

उन्हीं वजहों से जिनसे staging और production अलग होते हैं, बस छोटे पैमाने पर: अलग configuration, versions, data, network access या browser। Defect report करने या वजह environment को मानने से पहले दोनों setups की item-by-item तुलना करें, build version और configuration से शुरू करके।

संदर्भ

  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • Continuous Integration (Martin Fowler)martinfowler.com · 2024continuous integration का व्यापक रूप से संदर्भित विवरण: बार-बार integrate करें, build को self-testing और तेज़ रखें, टूटा build तुरंत ठीक करें।
  • ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021टेस्ट दस्तावेज़ों के टेम्पलेट और सामग्री — test policy, strategy, plan, status व completion रिपोर्ट, incident रिपोर्ट।
टूल्स

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

API रिस्पॉन्स कम्पेरेटर

दो API रिस्पॉन्स (जैसे staging बनाम production) की तुलना करें और हर संरचनात्मक तथा वैल्यू का अंतर देखें।

API टेस्टिंग

JSON डिफ़

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

JSON और डेटा

टेक्स्ट डिफ़

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

फ़ॉर्मेटिंग

API हेल्थ चेकर

एक साथ कई API health endpoint जाँचें और स्टेटस, latency तथा pass/fail सारांश पाएँ।

API टेस्टिंग

Timezone कन्वर्टर

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

यूटिलिटीज़

और गहराई से

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

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

इस topic से पहले