मॉड्यूल 3 · Testing fundamentals

सिस्टम टेस्टिंग

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

System testing वह test level है जो पूरे, integrated system को उसकी तय requirements के सामने जाँचता है। यहाँ test object पूरा product है, जैसा user या कोई दूसरा system उसे इस्तेमाल करता है: front end, back-end services, database, configuration और background में चलने वाले jobs, सब एक साथ deployed और चलते हुए।

उदाहरण: event-ticket website पर एक system test customer के रूप में sign in करता है, दो seats book करता है, payment provider के test mode में pay करता है, और जाँचता है कि booking "My tickets" में दिखती है और e-ticket email से पहुँचता है। यही level यह भी जाँचता है कि system कितनी अच्छी तरह चलता है: load में speed, Arabic और English versions, और कौन-सी booking किसे दिखती है।

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

Component और integration tests दिखाते हैं कि हिस्से काम करते हैं और आपस में बात करते हैं। वे यह नहीं दिखा सकते कि जुड़ा हुआ product वही करता है जो उसकी requirements कहती हैं। कई failures तभी दिखते हैं जब सब कुछ realistic configuration के साथ एक साथ चलता है: दो servers के अलग-अलग time zones की वजह से seats का घंटों hold रहना, या ऐसा customer जो URL में एक number बदलकर किसी और की booking खोल ले। अगर system testing इन्हें नहीं पकड़ती, तो customers पकड़ेंगे।

Tester के लिए यह वह level है जहाँ independent नज़र सबसे ज़्यादा काम आती है: system tests code से नहीं, requirements और risks से बनते हैं, और उनके results ही वह evidence हैं जिससे तय होता है कि build acceptance testing के लिए तैयार है या नहीं।

System testing क्या जाँचती है, और किसके सामने

ISTQB Foundation syllabus (CTFL v4.0) system testing को ऐसी testing बताता है जो पूरे system या product के overall behaviour और capabilities पर focus करती है, जिसमें अक्सर end-to-end tasks की functional testing और quality characteristics की non-functional testing शामिल होती है, और जिसे कोई independent test team कर सकती है। दूसरे systems, जैसे payment provider, के साथ interfaces system integration testing का focus हैं, जो आपने पिछले lesson में देखी।

यहाँ test basis system-level specification है: functional और non-functional requirements, use cases, user stories, business rules, risk analysis और user documentation। Tests system के external interfaces से चलते हैं — user interface, public API, और वे files और messages जो system भेजता-लेता है — internal functions को call करके नहीं। इस level पर आम failures:

  • कई components में फैला कोई rule गलत result देता है, जैसे cart और invoice के बीच discount का दो बार लग जाना।
  • कोई end-to-end task पूरा नहीं होता: booking save हो जाती है, लेकिन confirmation नहीं जाता।
  • Code की बजाय configuration या deployment से होने वाला failure: छूटी हुई setting, गलत time zone, expired certificate।

System level पर functional और non-functional testing

Functional system tests जाँचते हैं कि system क्या करता है: हर requirement, business rule और end-to-end task, invalid input और error handling समेत, सिर्फ़ main flow नहीं। Non-functional system tests जाँचते हैं कि वह यह कितनी अच्छी तरह करता है, performance efficiency, security, compatibility, reliability और usability जैसी quality characteristics के सामने (ISO/IEC 25010:2023 usability को "interaction capability" कहता है)। System testing को दोनों चाहिए।

कुछ characteristics को सिर्फ़ पूरे system पर ही परखा जा सकता है: response time हर layer और उनके बीच के network पर निर्भर है, और इस्तेमाल में आसानी पूरी journey पर। इसीलिए ISTQB कहता है कि कुछ non-functional characteristics को पूरे system पर, representative test environment में टेस्ट करना बेहतर है। इनके लिए measurable requirements भी चाहिए: "seat map तेज़ है" pass या fail नहीं हो सकता, "500 concurrent users के साथ 95% requests में 2 seconds के अंदर load" हो सकता है।

Production जैसा test environment

System test का result उतना ही भरोसेमंद है जितना वह environment जिसमें वह चला: जो test वहाँ pass हो, उसे production में भी pass होना चाहिए, और वहाँ का failure set-up की नहीं, product की ओर इशारा करे। ISTQB representative test environment की बात करता है; teams इसे staging, pre-production या system test environment कहती हैं। Representative का मतलब identical नहीं है: जो कुछ behaviour पर असर डालता है उसे production जैसा रखें, जो फ़र्क टाले नहीं जा सकते उन्हें सोच-समझकर रखें, और हर फ़र्क दर्ज करें।

  • एक जैसा: वही build artefact जो release होगा, उन्हीं scripts से deploy; operating system, runtime और database के versions; feature flags, time zone और scheduled jobs जैसी settings।
  • जानबूझकर अलग, data: synthetic data, या जहाँ policy अनुमति दे वहाँ production data की masked copies, जिनमें names, contact details और बाकी personal data बदल दिए जाते हैं; दोनों में realistic shape और volume हो। असली customers का unmasked personal data कभी नहीं।
  • जानबूझकर अलग, external services: payment, SMS और email providers sandbox या test mode में, या simulated, ताकि न असली पैसा जाए और न किसी असली customer को message मिले। ISTQB कहता है कि इस level पर sub-systems का simulation संभव है।
  • अक्सर अलग, capacity: छोटा environment भी functional defects पकड़ता है, लेकिन उसके performance results सीधे production पर लागू नहीं होते।
  • Accounts: हर role के लिए test account, जैसे customer, organiser और administrator।
Ticket site, release 2.3: system test environment वही build, versions और settings चलाता है जो production में हैं, जबकि data, payment और messaging providers और अक्सर capacity जानबूझकर अलग होते हैं और दर्ज किए जाते हैं।

Production

असली customers, असली payments, असली messages

Build:
Release 2.3, जैसा ship होता है
Versions और settings:
Operating system, runtime, database engine, time zone, feature flags, scheduled jobs
Data:
असली customers, bookings और payments
Payment, email और SMS:
Live providers
Capacity:
Application servers की पूरी संख्या
Accounts:
असली customers, organisers और administrators

System test environmentStaging या pre-production

Production की representative और टेस्ट के लिए सुरक्षित

Build:
वही build artefact, उन्हीं scripts से deploy
Versions और settings:
वही; कोई भी बदलाव दर्ज किया गया फ़र्क है
Data:
Synthetic या masked, realistic shape और volume के साथसावधानी
Payment, email और SMS:
Sandboxes या simulators: न असली पैसा, न असली messagesसावधानी
Capacity:
आधे servers: performance results size के साथ report होते हैंसावधानी
Accounts:
हर role के लिए test account

"सावधानी" का मतलब production से जानबूझकर रखा गया फ़र्क है: स्वीकार्य, लेकिन test report में लिखा जाता है ताकि results सही पढ़े जाएँ।

आज़माएँ: टेस्ट डेटा फ़ैक्टरी आज़माएँ: फ़ेक यूज़र जनरेटर

Worked example: event-ticket site के system tests

Ticket-booking website के release 2.3 में पाँच requirements हैं। FR-1: signed-in customer हर event के लिए 1 से 6 tickets book कर सकता है और उसे email से e-ticket मिलता है। FR-2: बिना payment वाले checkout की seats 10 मिनट hold रहती हैं, फिर release होती हैं। NFR-1: 500 concurrent users के साथ 95% requests में seat map 2 seconds में load होता है। NFR-2: customers सिर्फ़ अपनी bookings देखते हैं। NFR-3: site Arabic और English में काम करती है।

Integration testing pass हो चुकी है, और smoke test, यानी सबसे ज़रूरी functions का एक छोटा run, दिखाता है कि release candidate testable है। Tester requirements से system tests design करता है, हर test एक requirement से traced:

  • ST-01 (FR-1, functional): 2 seats book करें और test mode में pay करें → booking confirmed; 2 seats का e-ticket मिला।
  • ST-02 (FR-1, functional): 7 tickets book करने की कोशिश करें → साफ़ message के साथ reject, कुछ भी reserve नहीं।
  • ST-03 (FR-2, functional): checkout खोलें और pay न करें → 10 मिनट बाद seats फिर से available।
  • ST-04 (NFR-1, performance): load-test tool से simulate किए गए 500 virtual users seat map खोलते हैं → कम से कम 95% loads 2 seconds के अंदर।
  • ST-05 (NFR-2, security): customer A, customer B का booking link खोलता है → access refused, कोई data नहीं दिखता।
  • ST-06 (NFR-3, localisation): दो supported browsers में Arabic में book करें → right-to-left layout और Arabic e-ticket।

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

Results को पढ़ना

ST-03 fail हुआ: seats 3 घंटे 10 मिनट बाद release हुईं। Web server ने hold time Riyadh local time (UTC+3) में बिना time zone के save किया, और release job ने, जो UTC पर set server पर चलता है, उसे UTC समझकर पढ़ा। हर component test pass हुआ था; failure सिर्फ़ deploy हुए पूरे system ने दिखाया। Defect report में build, environment और दोनों servers की settings लिखी हैं।

ST-04 pass हुआ, लेकिन environment में production के आधे servers हैं, इसलिए report यह बात result के साथ लिखती है। फिर system test report हर requirement के results, severity (हर defect का असर कितना गंभीर है) के साथ open defects और environment के फ़र्क दिखाती है: यही वह evidence है जिससे तय होता है कि build acceptance testing में जाए या नहीं।

आम गलतियाँ

  • Demo की तरह सिर्फ़ main flow चलाना और invalid input व error handling छोड़ देना।
  • Performance, security और compatibility को "बाद के लिए" छोड़ देना, जबकि release date बाद का समय नहीं छोड़ती।
  • Production से अलग environment में बिना फ़र्क दर्ज किए टेस्ट करना, या बिना जाँचे हर failure का दोष "environment" पर डालना।
  • Synthetic या masked data की जगह असली customers का personal data test environment में copy करना।
  • ऐसे system tests लिखना जो अपनी cover की गई requirement का नाम नहीं बताते, जिससे कोई नहीं बता पाता कि क्या untested है।

QA का नज़रिया

System testing build आने से पहले शुरू होती है। Tester system requirements को testability के लिए review करता है, उनसे traced system tests design करता है, और developers या DevOps engineers के साथ environment तय करता है: build, configuration, data, sandboxes और accounts। Team entry criteria भी तय करती है, आम तौर पर pass हुई integration testing और सफल smoke test, और test plan में exit criteria भी।

Execution के दौरान हर run का build number, environment और test data दर्ज करें; इनके बिना system-level failures reproduce करना मुश्किल है। जो चीज़ environment cover नहीं कर सकता, जैसे असली payment या production-size load, उसे जल्दी उठाएँ और product owner के साथ तय करें कि उस risk को कैसे संभालना है।

अभ्यास

Online grocery order के लिए system tests plan करें

आपका काम

एक online grocery app system testing के लिए तैयार है। नीचे की हर requirement के लिए कम से कम एक system test उसके expected result के साथ design करें, और तय करें कि system test environment को क्या देना होगा।

सामग्री
R1  Customer 30 items तक order कर सकता है और card या cash on delivery से pay कर सकता है।
R2  Order delivery के लिए निकलने पर customer को SMS मिलता है।
R3  Customer सिर्फ़ अपनी order history देख सकता है।
R4  300 concurrent users पर 95% requests में checkout 3 seconds में respond करता है।
R5  App Arabic और English में उपलब्ध है।
चरण
  1. हर requirement को functional या non-functional में बाँटें।
  2. हर requirement के लिए एक या ज़्यादा system tests लिखें, जिनमें R1 का एक negative test भी हो: ऐसा invalid input जिसे reject होना चाहिए।
  3. लिखें कि environment को क्या देना होगा: build, data, external services और accounts।
  4. Production से एक फ़र्क बताएँ जिसे आप report में दर्ज करेंगे, और कोई भी सवाल जो requirements खुला छोड़ती हैं।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Functional: R1 और R2। Non-functional: R3 (security), R4 (performance efficiency) और R5 (localisation, जिसे कुछ teams functional गिनती हैं)।

Tests: payment sandbox में test card से 3 items का payment → order confirmed, सही total; cash on delivery के साथ 30 items → confirmed; negative: 31वाँ item → साफ़ message के साथ reject; store order को "out for delivery" mark करता है → test phone पर सही order number वाला SMS आता है; customer A, customer B का order खोलता है → access refused; checkout पर 300 virtual users → कम से कम 95% responses 3 seconds में; हर भाषा में एक पूरा order → सारा text translated, Arabic right to left।

Environment: release candidate उसी तरह deployed जैसे production में; synthetic products और customers; test cards और test phone numbers के साथ payment और SMS sandboxes; दो customers और एक store operator के accounts; production जैसी time zone और language settings।

दर्ज करने लायक: environment में production से कम servers हैं, इसलिए R4 का result environment size के साथ report होता है। खुले सवाल: 30 की limit अलग-अलग products गिनती है या units (एक ही पानी की 3 bottles)? SMS किस भाषा में जाता है?

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

System testing कौन करता है?

आम तौर पर testers, अक्सर एक independent test team, क्योंकि यह level product की तुलना उसकी specification से करता है और code से independent नज़र का फ़ायदा उठाता है। Developers, DevOps engineers और business analysts fixes, environments और requirements पर जवाबों से मदद करते हैं। Agile teams में team के testers आम तौर पर sprint के दौरान और release से पहले system tests चलाते हैं।

System testing और acceptance testing में क्या फ़र्क है?

System testing system को उसकी तय requirements के सामने जाँचती है और आम तौर पर delivery team उसे चलाती है; यह मुख्य रूप से verification है। Acceptance testing जाँचती है कि system अपने users और business की ज़रूरतें पूरी करता है या नहीं, अक्सर users या customer representatives उसे चलाते हैं, और उसका नतीजा system को accept करने का फ़ैसला होता है; यह मुख्य रूप से validation है। अगला lesson acceptance testing पढ़ाता है।

क्या system testing और end-to-end testing एक ही हैं?

पूरी तरह नहीं, हालाँकि कुछ teams दोनों terms एक ही चीज़ के लिए इस्तेमाल करती हैं। System testing एक test level है, जिसे उसका test object, यानी एक पूरा system, और उसका test basis, यानी system requirements, परिभाषित करते हैं। End-to-end testing पूरी user journeys को follow करती है, अक्सर कई systems के पार, और system testing, system integration testing या acceptance testing के दौरान हो सकती है। End-to-end testing वाला lesson दोनों की तुलना करता है।

क्या system tests automate हो सकते हैं?

आंशिक रूप से। API या user interface से होने वाले stable checks जो हर release में दोहराए जाते हैं, और performance tests, automation के अच्छे candidates हैं। Exploratory sessions, usability पर फ़ैसले और एक बार के checks आम तौर पर manual होते हैं। ज़्यादातर teams दोनों को मिलाती हैं।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023उत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।
  • 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 मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।

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

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

किसी फ़ीचर के लिए functional, negative, security, usability और compatibility पहलुओं को कवर करने वाले उच्च-स्तरीय टेस्ट सिनेरियो जनरेट करें।

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

टेस्ट डेटा फ़ैक्टरी

सिंथेटिक टेस्ट डेटा की एक ही जगह पर फ़ैक्टरी: users, customers, companies, पते, संख्याएँ, तारीख़ें और स्ट्रिंग — JSON, CSV, SQL या XML में।

टेस्ट डेटा

फ़ेक यूज़र जनरेटर

टेस्ट अकाउंट के लिए फ़ेक यूज़र रिकॉर्ड (नाम, username, ईमेल, पासवर्ड, avatar seed, role) जनरेट करें।

टेस्ट डेटा

और गहराई से

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

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