वेरिफ़िकेशन बनाम वैलिडेशन
Verification और validation किसी product, और उस तक ले जाने वाले work products, के बारे में दो अलग सवाल हैं। Verification पूछता है कि क्या कोई work product अपने specification पर खरा है: requirements, acceptance criteria, design या तय standards। Validation पूछता है कि क्या product अपने intended use और असली environment में users और दूसरे stakeholders की ज़रूरतें पूरी करता है। मशहूर छोटा रूप, जिसका श्रेय आम तौर पर Barry Boehm को दिया जाता है: verification है "क्या हम product सही तरीके से बना रहे हैं?", validation है "क्या हम सही product बना रहे हैं?"
एक उदाहरण: requirement कहती है "हर महीने की 1 तारीख़ को system store manager को पिछले महीने की sales report PDF में email करता है।" Tests पक्का करते हैं कि email 1 तारीख़ को आता है और totals database से मेल खाते हैं, यानी verification pass होता है। लेकिन manager हर रविवार पिछले हफ़्ते की sales देखकर stock order करते हैं, और monthly report मदद के लिए बहुत देर से आती है। Product सही तरीके से बना, लेकिन यह सही product नहीं है।
यह क्यों ज़रूरी है
हर सवाल एक अलग जोखिम से बचाता है। Verification के बिना product तय बातों से भटक जाता है: कोई rule "greater than or equal" की जगह "greater than" से code हो जाता है, कोई error message छूट जाता है। Validation के बिना team ठीक वही deliver कर सकती है जो लिखा गया था और फिर भी release बेकार जाती है, क्योंकि requirement ने गलत चीज़ बताई थी।
Tester के लिए यह फ़र्क़ एक जाल दिखाता है। Test cases आम तौर पर requirements से बनते हैं, इसलिए requirement का defect tests में भी उतर आता है, और वे tests फिर भी pass हो जाते हैं। Green test report specification से मेल दिखाती है, product की उपयोगिता नहीं। कौन-सी activity किस सवाल का जवाब देती है, यह जानकर आप ठीक-ठीक बता सकते हैं कि आपकी testing ने क्या दिखाया और क्या नहीं।
दो सवाल, तुलना के दो आधार
ISTQB Foundation syllabus (CTFL v4.0) बताता है कि testing में दोनों शामिल हैं: verification, यानी यह जाँचना कि system specified requirements पूरी करता है या नहीं, और validation, यानी यह जाँचना कि वह अपने operational environment में users और दूसरे stakeholders की ज़रूरतें पूरी करता है या नहीं। फ़र्क़ इसमें नहीं कि आप क्या करते हैं, बल्कि इसमें है कि आप product की तुलना किससे करते हैं।
- Verification किसी work product की तुलना उसके specification से करता है: code की design से, screen की उसके acceptance criteria से, API response की API contract से, requirement की अच्छी requirement के गुणों (साफ़, consistent, testable) से।
- Validation product की तुलना उसके intended use से करता है: users के लक्ष्य, काम करने का तरीका, devices और data, और वह business नतीजा जो feature को देना है। इसमें से बहुत कुछ कभी लिखा नहीं जाता, इसलिए आपको पूछना और observe करना पड़ता है।
- कुछ teams "validation" शब्द input checks (form जो गलत email reject करता है) या API response के schema checks के लिए भी इस्तेमाल करती हैं। ये software के अपने व्यवहार हैं; specification के ख़िलाफ़ इन्हें टेस्ट करना verification है।
दोनों के static और dynamic रूप होते हैं
Static testing software चलाए बिना किसी work product की जाँच करती है: लोग उसे review करते हैं या tools उसका analysis करते हैं। Dynamic testing software चलाती है। ISTQB syllabus कहता है कि static testing verification और validation दोनों के लिए लागू हो सकती है। Dynamic testing भी दोनों के काम आती है: requirements से बने tests चलाना verification है, जबकि acceptance testing, जिसे syllabus validation पर केंद्रित बताता है, आदर्श रूप से intended users ख़ुद करते हैं। इसलिए लोकप्रिय shortcut "verification यानी reviews, validation यानी tests चलाना" गलत है।
- Static verification: story को साफ़ और testable criteria के लिए review करना; API contract की requirement से तुलना करना; code का static analysis।
- Dynamic verification: acceptance criteria से बने test cases execute करना।
- Static validation: कोई code लिखे जाने से पहले भावी users के साथ story या screen sketches पर walkthrough।
- Dynamic validation: user acceptance testing, असली users के साथ pilot या beta, usability sessions।
Worked example: clinic appointment की booking
एक clinic चाहता है कि मरीज़ उसकी website पर appointment book करें। Story: "एक मरीज़ के रूप में, मैं online appointment book करना चाहता हूँ, ताकि मुझे reception को फ़ोन न करना पड़े।" Acceptance criteria: AC1, 08:00 से 16:00 तक 15 मिनट के slots, रविवार से गुरुवार; AC2, एक patient account में ज़्यादा से ज़्यादा एक future appointment हो सकता है; AC3, booking के 1 मिनट के अंदर confirmation SMS भेजा जाता है। इस story पर चार जाँचें, उसी क्रम में जिसमें वे होती हैं: दोनों static जाँचें refinement में, और दोनों dynamic जाँचें feature बनने के बाद।
- Static verification: story review में tester पूछता है कि 16:00 आख़िरी start time है या closing time। Product owner बताता है कि आख़िरी slot 15:45 पर शुरू होता है, और code लिखे जाने से पहले ही AC1 ठीक कर दिया जाता है।
- Static validation: reception staff story और screen sketches पर walkthrough करते हैं। वे बताते हैं कि माता-पिता एक ही account से अपने बच्चों के लिए booking करते हैं, इसलिए AC2 किसी parent को दो बच्चों के लिए book करने से रोक देगा। Limit बदलकर हर मरीज़ के लिए एक future appointment हो जाती है।
- Dynamic verification: सुधरे हुए criteria के tests 08:00 और 15:45 के slots book करते हैं, पक्का करते हैं कि 16:00 का कोई slot नहीं दिखता, जाँचते हैं कि उसी मरीज़ की दूसरी future booking reject होती है जबकि उसी account से दूसरे बच्चे की booking accept होती है, और SMS का समय नापते हैं। सब pass।
- Dynamic validation: एक हफ़्ते का pilot दिखाता है कि कई मरीज़ visit का कारण बताए बिना पहला खाली slot चुन लेते हैं, जबकि dental cleaning में दो slots लगते हैं। हर criterion पूरा हुआ; requirement एक ज़रूरत चूक गई।
Verification
क्या हम product सही तरीके से बना रहे हैं?
- तुलना किससे:
- Specification: requirements, acceptance criteria, design, contracts, standards
- Static रूप: कुछ नहीं चलता:
- Story review: 16:00 आख़िरी start time है या closing time?
- Dynamic रूप: software चलता है:
- सुधरे हुए AC1 से AC3 के tests: 08:00 और 15:45 book, उसी मरीज़ की दूसरी booking reject, SMS का समय नापा
- चूक कैसी दिखती है:
- Product किसी तय rule को तोड़ता है
Validation
क्या हम सही product बना रहे हैं?
- तुलना किससे:
- असली environment में intended use के लिए users और stakeholders की ज़रूरतें
- Static रूप: कुछ नहीं चलता:
- Reception के साथ sketches पर walkthrough: माता-पिता एक account से बच्चों के लिए book करते हैं
- Dynamic रूप: software चलता है:
- एक हफ़्ते का pilot: मरीज़ visit का कारण बताए बिना book करते हैं
- चूक कैसी दिखती है:
- हर rule पूरा है, फिर भी users अपना काम ठीक से नहीं कर पाते
आज़माएँ: User Story → टेस्ट सिनेरियो आज़माएँ: Requirements → टेस्ट केस
दोनों क्यों ज़रूरी हैं
Validation के बिना verification ऐसा software देता है जो गलत या अधूरे specification के मुताबिक़ है: AC1 से AC3 तक के criteria से बना कोई भी test visit की अवधि वाली समस्या पर fail नहीं हो सकता था। ISTQB syllabus इस जाल को अपने सात testing principles में absence-of-defects fallacy के नाम से गिनाता है: सारी specified requirements टेस्ट करने और मिला हर defect ठीक करने के बाद भी ऐसा system बन सकता है जो users की ज़रूरतें पूरी नहीं करता, इसलिए verification के साथ validation भी ज़रूरी है।
Verification के बिना validation भी उतना ही जोखिम भरा है। Pilot में main path आज़माने वाले मरीज़ शायद ही देखेंगे कि दो लोग एक ही पल में एक ही slot book कर सकते हैं, या कि cancel की गई booking अब भी अपना slot घेरे रहती है; ऐसी failures के लिए सोच-समझकर चुना test data और timing चाहिए। और legal, security और accessibility rules पूरे करने ही होते हैं, users माँगें या न माँगें।
आम गलतियाँ
- "सारे tests pass हो गए" को इस बात का सबूत मानना कि product सही है। Requirements से बने tests उन्हीं requirements को verify करते हैं, यह नहीं कि requirements users की ज़रूरत बताती हैं।
- Verification को reviews के और validation को tests चलाने के बराबर मानना। दोनों के static और dynamic रूप होते हैं।
- Validation को आख़िर के UAT phase पर छोड़ देना, जबकि सबसे सस्ता validation coding से पहले होता है, story को उसके users के साथ review करते समय।
- Input validation या schema validation, यानी software ख़ुद जो checks करता है, उन्हें इस lesson वाले validation से मिला देना।
- चुपचाप अपनी इस सोच के हिसाब से टेस्ट करना कि users को क्या चाहिए। अगर कोई requirement users के लिए गलत लगे, तो expected result ख़ुद बदलने की जगह product owner के सामने उठाएँ।
QA का नज़रिया
असली team में आप पहली refinement meeting से ही दोनों तरह के सवाल पूछते हैं। Verification के सवाल story के बारे में होते हैं: क्या हर criterion साफ़, consistent और testable है? Validation के सवाल उसके मक़सद के बारे में: इसे कौन इस्तेमाल करता है, किस हालात में, किस device पर, और यह कौन-सी समस्या हल करता है? जवाब देना product owner या business analyst की ज़िम्मेदारी है; support staff अक्सर असली workflow सबसे अच्छी तरह जानते हैं।
दोनों तरह की findings अलग रखें। Acceptance criterion के ख़िलाफ़ fail होने वाला test एक defect है, जो उसी criterion से trace होता है। यह शक कि criterion असली इस्तेमाल में फ़िट नहीं बैठता, product owner के लिए सवाल या change request है, आपके सबूत के साथ। Test reports में लिखें कि हर तरह की जाँच ने क्या cover किया: "सभी 14 acceptance criteria verified; validation अब तक सिर्फ़ internal demo तक"।
अभ्यास
Leave request feature की जाँचों को वर्गीकृत करें
एक HR app की requirement नीचे है, और team ने छह activities कीं। हर activity को verification या validation, और static या dynamic के रूप में वर्गीकृत करें। फिर तय करें कि हर finding कहाँ जाए: specification के ख़िलाफ़ defect, या product owner के लिए सवाल या change request।
आख़िर में validation का एक ऐसा सवाल लिखें जिसे requirement खुला छोड़ देती है।
Requirement LV-4
Employee 1 से 30 working days की annual leave request कर सकता है। Request direct
manager के पास जाती है, जिसे 3 working days के अंदर approve या reject करना होता है;
नहीं तो request HR को escalate हो जाती है।
Activities
1. Requirement review: "working days" परिभाषित नहीं (weekends? public holidays?)।
2. Leave endpoint के API contract की LV-4 से तुलना: contract 31 दिन तक allow करता है।
3. एक test 31 दिन की request भेजता है और जाँचता है कि वह reject हो।
4. तीन managers screen sketches देखते हैं: वे meetings के बीच phone से requests
approve करते हैं, पर sketches में सिर्फ़ desktop वाला approval page है।
5. एक department में दो हफ़्ते का pilot: business trips पर गए managers 3 दिन की
window चूक जाते हैं, और कई requests HR को escalate हो जाती हैं।
6. Test build पर usability session: ज़्यादातर employees dates चुनने से पहले अपना बचा
leave balance ढूँढते हैं; form उसे नहीं दिखाता।- बताएँ कि product की तुलना किससे हो रही है: specification से, या असली इस्तेमाल में users की ज़रूरतों से।
- तय करें कि activity के दौरान software चलता है (dynamic) या नहीं (static)।
- तय करें कि finding ऐसा product दिखाती है जो specification तोड़ता है, या ऐसा specification जो ख़ुद गलत हो सकता है।
- Intended use के बारे में एक और सवाल लिखें जिसका जवाब LV-4 नहीं देती।
मॉडल उत्तर दिखाएँ
1: verification, static। Requirement को अच्छी requirement के गुणों के ख़िलाफ़ जाँचा जाता है। Product owner के लिए सवाल उठाएँ: working days कैसे परिभाषित हैं, और क्या उनमें weekends और public holidays शामिल हैं?
2: verification, static। दो work products की आपस में तुलना होती है, और contract LV-4 से टकराता है। अभी defect report करें, इससे पहले कि उस पर code बने।
3: verification, dynamic। अगर 31 दिन की request accept हो जाए, तो यह defect है।
4: validation, static। कुछ नहीं चलता; असली users sketches को अपने काम के तरीके से परखते हैं। Product owner के लिए change request: managers को phone से approve करना है, जो किसी requirement में नहीं लिखा।
5: validation, dynamic। Escalation specification के मुताबिक़ काम करता है, इसलिए verification pass है, लेकिन rule managers के काम करने के तरीके में फ़िट नहीं बैठता: यह change request है (जैसे deputy approver), defect नहीं।
6: validation, dynamic। असली users चलते हुए build पर काम करते हैं और एक ऐसी ज़रूरत सामने आती है जो किसी ने नहीं लिखी। Change request: form पर बचा हुआ balance दिखाएँ।
संभावित खुले सवाल: क्या approve हो चुकी leave cancel हो सकती है? जब manager ख़ुद छुट्टी पर हो तो कौन approve करेगा? क्या employees को आधे दिन की leave चाहिए?
अक्सर पूछे जाने वाले सवाल
क्या user acceptance testing और validation एक ही हैं?
नहीं, लेकिन UAT dynamic validation का एक आम रूप है: users या उनके प्रतिनिधि product स्वीकार करने से पहले जाँचते हैं कि वह उनके काम में मदद करता है। UAT आम तौर पर acceptance criteria भी दोबारा जाँचता है, जो verification है। Validation इससे पहले भी होता है, users के साथ stories और prototypes के review में, और बाद में भी, pilots, beta releases और असली इस्तेमाल के feedback में।
Tester इन दोनों में से क्या करता है?
दोनों। Requirements और acceptance criteria के ख़िलाफ़ रोज़ का ज़्यादातर test execution verification है। Tester validation में योगदान देता है: reviews में users और intended use के बारे में पूछकर, realistic data, devices और workflows के साथ टेस्ट करके, और UAT की तैयारी व support करके। ज़रूरतें पूरी हुईं या नहीं, इसका आख़िरी फ़ैसला users और product owner का होता है।
क्या कोई product verification में pass और validation में fail हो सकता है, या उल्टा?
हाँ। Monthly sales report अपने specification पर खरी थी, पर अपने user के काम नहीं आई। उल्टा उदाहरण: ऐसा product जो demo में users को पसंद आता है लेकिन VAT गलत calculate करता है; वह ऐसी requirement के verification में fail होता है जिसे users जाँचते नहीं, पर business को पूरा करना ही है।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
Mutqan tools से अभ्यास करें
क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।
किसी user story से end-to-end टेस्ट सिनेरियो निकालें, वैकल्पिक और अपवाद flow सहित।
किसी user story से Given/When/Then acceptance criteria और definition-of-done चेकलिस्ट जनरेट करें।
Mutqan AI से छूटी हुई requirements खोजें — error handling, permissions, edge conditions, non-functional ज़रूरतें।
और गहराई से
- स्टैटिक टेस्टिंगStatic टेस्टिंग बनाम Dynamic टेस्टिंग
- Requirements Review कैसे करेंRequirements और user stories का review कैसे करें: 8-बिंदु checklist, चेतावनी वाले शब्द, review comments वाला उदाहरण, और AI टूल कहाँ मदद करते हैं।
- एंड-टू-एंड प्रोडक्ट क्वालिटी एश्योरेंसटेस्ट के स्तर: यूनिट, इंटीग्रेशन, सिस्टम और एक्सेप्टेंस
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।