मॉड्यूल 1 · Software और QA की बुनियाद

टेस्टवेयर, टेस्ट बेसिस और टेस्ट ओरेकल

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

Testware वह सब है जो test process testing की planning, design, execution, evaluation और reporting के लिए बनाता है: test plans, test conditions, test cases, test scripts, test data, test logs, defect reports और test reports। इसका ज़्यादातर हिस्सा test basis से निकलता है — वे requirements, user stories, designs और बाकी जानकारी जो बताती है कि system को क्या करना चाहिए — और test object पर इस्तेमाल होता है, यानी वह चीज़ जिसे टेस्ट किया जा रहा है।

दो और terms तस्वीर पूरी करते हैं। Test condition test basis से लिया गया एक testable पहलू है: क्या टेस्ट करना है। Test oracle expected result का वह स्रोत है जिससे test actual result की तुलना करता है। Story "invoice में 15% VAT दिखे" के लिए story test basis है, build 3.8.0 का invoice page test object है, और rule के साथ आपकी अपनी calculation oracle है।

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

Error, defect और failure वाले lesson में failure का मतलब था कि system वह नहीं करता जो उसे करना चाहिए। "करना चाहिए" का कोई स्रोत चाहिए: नाम से तय test basis के बिना testers वही टेस्ट करते हैं जो वे मान लेते हैं; oracle के बिना test इसलिए pass हो जाता है कि screen पर ठीक-ठाक दिखने वाला number है; और test object के exact build के बिना कोई result दोहरा नहीं सकता।

Testware testing को दोहराने लायक और दिखने लायक बनाता है: लिखा हुआ test case fix के बाद और हर regression cycle में फिर चलता है, test logs और reports release decision के पीछे का सबूत हैं, और defect report exact requirement, build और expected value बता सकती है।

Test basis, test object और test oracle

Test basis वह जानकारी है जिसके आधार पर test analysis और test design किए जाते हैं: acceptance criteria के साथ requirements और user stories, business rules, designs, API specifications, risk analyses, regulations, और white-box tests के लिए ख़ुद code।

Test object वह work product है जिसे टेस्ट किया जा रहा है: कोई function, API endpoint, screen, पूरा system या कोई document। इसे सटीक रूप से पहचानें — component, build और environment — क्योंकि result सिर्फ़ उसी पर लागू होता है जो टेस्ट हुआ। कई teams इसे system under test (SUT) कहती हैं; ISTQB glossary में SUT ऐसा test object है जो पूरा system हो। एक ही चीज़ दोनों भूमिकाएँ निभा सकती है: requirements review में requirement test object है; बनी हुई feature को टेस्ट करते समय वही test basis है।

Test oracle वह स्रोत है जिससे expected result तय होता है, ताकि उसे actual result से मिलाया जा सके। अक्सर test basis ही oracle होता है, पर हमेशा नहीं:

  • Specification: कोई acceptance criterion, business rule या API contract result बताता है।
  • हाथ से या spreadsheet में की गई independent calculation — system का अपना output कभी नहीं।
  • पिछला version या दूसरा system: refactoring या data migration के बाद पुराना output expected result होता है।
  • Standards और consistency: WCAG, किसी locale के date formats, cart total जो invoice total के बराबर होना चाहिए।
  • Partial oracle, जब पूरा result पहले से बताया न जा सके, जैसे search ranking: जो जाँच सकते हैं वह जाँचें (हर result में search term हो) और लिखें कि क्या बिना जाँच रह गया। सही result जानने की इस आम कठिनाई को test oracle problem कहा जाता है।

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

Test conditions: क्या टेस्ट करना है, यह तय करना

Test condition किसी component या system का एक testable पहलू है, जिसे testing के आधार के रूप में पहचाना जाता है। यह "क्या टेस्ट करें?" का जवाब देती है और अक्सर उस requirement से छोटी होती है जिससे वह निकली है। ISTQB syllabus acceptance criteria को test conditions के उदाहरण के रूप में गिनाता है; जो criterion कई behaviours कवर करता है, उसे हर behaviour के लिए एक condition में बाँटा जाता है।

Test analysis में आप conditions पहचानते और prioritise करते हैं; test design में हर condition ठोस inputs और expected results वाले एक या ज़्यादा test cases बनती है। दोनों activities के अपने lessons आगे हैं। अच्छी condition:

  • कोई observable result बताती है, "VAT सही काम करे" जैसी इच्छा नहीं।
  • एक ही पहलू कवर करती है और basis के एक item से जुड़ी होती है, जैसे नीचे के worked example में story QA-214 का AC2।
  • Priority रखती है, ताकि सबसे ज़्यादा risk वाली conditions पहले टेस्ट हों।

Testware: हर test activity क्या बनाती है

ISTQB Foundation syllabus v4.0 test process को सात activities के रूप में बताता है: test planning (test objectives और approach तय करना), test monitoring और control (plan के मुकाबले progress पर नज़र रखना और ज़रूरत पड़ने पर बदलाव करना), test analysis और test design (क्या टेस्ट करें और कैसे, जैसा ऊपर आया), test implementation (tests चलाने के लिए scripts, data और environment तैयार करना), test execution (tests चलाना और results log करना) और test completion (काम समेटना और आगे काम आने वाली चीज़ें archive करना)। ये activities हमेशा सख़्त क्रम में नहीं चलतीं, और "टेस्ट प्रोसेस (STLC)" module हर एक को विस्तार से सिखाता है।

ISTQB syllabus testware को उसे बनाने वाली activity के हिसाब से गिनाता है। हर item अलग document नहीं होता: agile teams में इसका बड़ा हिस्सा test management tool में, story पर या code repository में रहता है। कुछ teams इन्हें test artefacts कहती हैं; ISO/IEC/IEEE 29119-3 इनमें से कई documents के templates देता है। Testware code की तरह configuration management में रहता है, ताकि पता रहे कि test का कौन-सा version test object के किस version पर चला।

  • Test planning: test plan, schedule, risk register, entry और exit criteria।
  • Test monitoring और control: test progress reports, control के फ़ैसलों का रिकॉर्ड और risk information।
  • Test analysis: prioritised test conditions, और ख़ुद test basis की defect reports।
  • Test design: prioritised test cases, test charters, coverage items, test data requirements और test environment requirements।
  • Test implementation: test procedures, automated test scripts, test suites, test data, test execution schedule, और stubs व drivers जैसे test environment elements।
  • Test execution: test logs (क्या चला, कब, किस build पर, किस result के साथ) और defect reports।
  • Test completion: test completion report, lessons learned, improvement actions और change requests; जो testware आगे काम आएगा, वह archive होता है या संबंधित teams को सौंपा जाता है।
हर test activity अपना testware छोड़ती है: test plan, test basis से test conditions, oracle से expected results वाले test cases, scripts और data, test logs और defect reports, और completion report।
  1. 1Test planningTest plan, schedule, risk register, entry और exit criteria
  2. 2Test analysisक्या टेस्ट करें? Test basis पढ़ती हैPrioritised test conditions; test basis की defect reports
  3. 3Test designकैसे टेस्ट करें? Oracle expected results देता हैTest cases, test charters, coverage items, test data requirements, test environment requirements
  4. 4Test implementationTest procedures, automated test scripts, test suites, test data, execution schedule, stubs और drivers
  5. 5Test executionTest object पर चलती है: actual बनाम expectedTest logs और defect reports
  6. 6Test completionTest completion report, lessons learned, archived testware

चरण 1–6 के दौरान Test monitoring और test control पूरे समय चलते हैं: test progress reports, control के फ़ैसलों का रिकॉर्ड और risk information।

इसके बाद:अगले cycle में: archived test cases और scripts फिर इस्तेमाल होते हैं, जैसे regression tests के रूप में

तार्किक क्रम, कैलेंडर नहीं: activities overlap होती और दोहराई जाती हैं, और हर item कितनी formality से लिखा जाए, यह team और risk पर निर्भर है।

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

Worked example: एक story, test basis से test log तक

एक web shop अपने invoices में VAT जोड़ रही है। नीचे की story test basis है; test object invoice page है, build 3.8.0, staging environment पर।

  • Test conditions: VAT subtotal का 15% है (AC1); जिस VAT amount का तीसरा decimal 5 हो, वह ऊपर round होता है (AC2); total में rounded VAT जुड़ता है (AC3)।
  • Oracle: AC1 और AC2, साथ में run से पहले की गई हाथ की calculation। 10.30 के subtotal पर: 10.30 × 0.15 = 1.545, इसलिए expected VAT 1.55 और total 11.85। 100.00 के subtotal पर expected VAT 15.00 और total 115.00।
  • Testware: हर condition के लिए इन expected values वाला एक test case, 10.30 और 100.00 subtotal वाला test data, और run का test log।
  • Result: build 3.8.0 पर rounding case fail हुआ, VAT 1.54 दिखा। Defect report AC2, build, और expected बनाम actual बताती है; developer कारण round-half-to-even ("banker’s rounding") तक ट्रेस करता है। Screen पर 1.54 ठीक लग रहा था; failure सिर्फ़ oracle ने पकड़ा।
QA-214  Invoice में VAT दिखे
एक customer के रूप में, मैं चाहता हूँ कि मेरे invoice में VAT दिखे
ताकि मुझे पता रहे कि मैंने कितना tax दिया।

AC1  Invoice में subtotal, 15% की दर से VAT और total दिखते हैं।
AC2  VAT को 2 decimal places तक round किया जाता है, half up।
AC3  Total = subtotal + invoice पर दिखाया गया VAT।

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

आम गलतियाँ

  • Expected result system के मौजूदा output से copy करना: software ख़ुद अपना oracle बन जाता है और defect "expected" behaviour बन जाता है।
  • Test object का build और environment record न करना, जिससे result न दोहराया जा सकता है, न किसी release से जोड़ा जा सकता है।
  • ऐसी मौखिक सहमति से टेस्ट करना जो कभी test basis तक नहीं पहुँची, बजाय जवाब को story या test case में लिखने के।
  • Test basis बदलने पर test cases और test data वैसे ही छोड़ देना, जिससे tests पुराना behaviour जाँचते रहते हैं।
  • जब result पूरी तरह पहले से न बताया जा सके, तो partial oracle की जगह बिना किसी oracle के टेस्ट करना।

QA का नज़रिया

हर story की शुरुआत में तीन सवाल पूछें: test basis क्या है (story का कौन-सा version, कौन-से designs), test object ठीक-ठीक क्या है (कौन-सा build और environment), और हर check का oracle क्या है? जिसका जवाब basis में नहीं, वह product owner के पास जाता है, और जवाब basis में लिखा जाता है, chat में नहीं।

Testware वहाँ रखें जहाँ team उसे ढूँढ सके — test management tool, repository या story — और उसे जोड़ें: condition को acceptance criterion से, test case को condition से, result को build से, defect को test case से। तब "क्या AC2 टेस्ट हुआ?" और "इस बदलाव के बाद क्या दोबारा चलाना है?" का जवाब मिनटों में मिलता है।

अभ्यास

Promo code feature के test session की जाँच करें

आपका काम

Story और वे notes पढ़ें जो एक tester ने पहले session के बाद लिखे। Test basis, test object और oracle बताएँ, test conditions निकालें, मौजूद और गायब testware की सूची बनाएँ, और बताएँ कि क्या गलत हुआ।

सामग्री
Story SHOP-88  Promo codes
AC1  Valid promo code cart subtotal पर 10% की छूट देता है।
AC2  हर customer एक code सिर्फ़ एक बार इस्तेमाल कर सकता है।
AC3  Expired code पर "यह code expire हो चुका है।" दिखता है।

Tester के notes, मंगलवार, staging
1. Code SAVE10, 200.00 का cart: screen पर 180.00 दिखा,
   इसलिए expected result = 180.00। Order place किया। Pass।
2. उसी account से SAVE10 दोबारा लगाया: फिर accept हुआ।
   पक्का नहीं कि यह bug है।
3. Expired code: कोई expired code उपलब्ध नहीं। Skip किया।
चरण
  1. Test basis, test object और oracle पहचानें। Test object पहचानने के लिए क्या कमी है?
  2. कम से कम चार test conditions लिखें, हर एक किसी acceptance criterion से जुड़ी हो।
  3. Session ने जो testware बनाया और जो अभी चाहिए, उसकी सूची बनाएँ।
  4. हर numbered note के लिए बताएँ कि क्या गलत है और tester को क्या करना चाहिए था।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Test basis: story SHOP-88, AC1 से AC3 तक। Test object: staging पर promo-code function, पर notes में कोई build नहीं लिखा, इसलिए result किसी release से नहीं जुड़ सकता। Oracle: criteria और calculation: 200.00 का 10% यानी 20.00, इसलिए expected 180.00।

Test conditions: valid code subtotal पर 10% छूट देता है (AC1); उसी customer का दूसरा इस्तेमाल reject होता है (AC2); दूसरा customer वही code अब भी इस्तेमाल कर सकता है (AC2); expired code ठीक "यह code expire हो चुका है।" message दिखाता है (AC3)। Product owner से पूछें: unknown code पर क्या दिखता है, और छूट VAT से पहले लगती है या बाद में?

बना: notes, यानी एक informal test log। गायब: run से पहले लिखे expected results वाले test cases, test data (एक expired code और दूसरा customer account), build number, और note 2 की defect report।

Note 1 ने expected result screen से लिया; वह oracle से संयोग से मेल खाया, और यह तरीका गलत value भी accept कर लेता। Note 2 AC2 के ख़िलाफ़ failure है, खुला सवाल नहीं: build और expected व actual result के साथ इसे report करें। Note 3 में test data की कमी है: expired code हासिल करें, और test को "not run" log करें, "pass" कभी नहीं।

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

क्या test basis और test oracle एक ही हैं?

हमेशा नहीं। Test basis वह है जिससे आप tests निकालते हैं; oracle किसी ख़ास check के expected result का स्रोत है। अक्सर एक requirement दोनों भूमिकाएँ निभाती है। लेकिन oracle basis के बाहर से भी आ सकता है — पिछला version, कोई मिलता-जुलता product, कोई calculation या कोई standard — और basis के कुछ items, जैसे risk analysis, बताते हैं कि क्या टेस्ट करना है, पर कोई expected result नहीं देते।

क्या agile teams भी testware बनाती हैं?

हाँ, आम तौर पर हल्के रूप में: test conditions की तरह इस्तेमाल होने वाले acceptance criteria, test charters और session notes, repository में automated test scripts, और CI pipeline के test logs और reports। कितना लिखा जाए, यह context, risk और किसी regulation पर निर्भर है; ज़रूरी यह है कि जानकारी मौजूद हो, versioned हो और ढूँढी जा सके।

क्या automated test scripts testware हैं?

हाँ। ISTQB syllabus automated test scripts को test implementation के work products में गिनाता है। इन्हें किसी भी दूसरे code की तरह version control, review और maintenance चाहिए, और इनके runs के logs test logs हैं।

संदर्भ

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

Requirements → टेस्ट केस

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

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

टेस्ट केस जनरेटर

फ़ीचर के विवरण और फ़ील्ड सूची से संरचित टेस्ट केस (id, शीर्षक, पूर्व-शर्तें, स्टेप, अपेक्षित परिणाम, प्राथमिकता) जनरेट करें।

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

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

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

टेस्ट डेटा

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

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

API टेस्टिंग

और गहराई से

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

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