टेस्टिंग के सात सिद्धांत
सात testing principles ISTQB Foundation Level syllabus की छोटी, सामान्य guidelines हैं जो हर तरह की testing पर लागू होती हैं। ये बताती हैं कि testing कैसे काम करती है: वह क्या साबित कर सकती है, सब कुछ cover क्यों नहीं कर सकती, कब सबसे ज़्यादा फ़ायदा देती है, defects कहाँ छिपते हैं और कोई एक approach हर product पर फ़िट क्यों नहीं होता। ये rules या process steps नहीं हैं; ये tester के रोज़ के फ़ैसलों के पीछे की वजहें हैं।
उदाहरण: एक sprint इस हाल में ख़त्म होता है कि सभी 300 tests pass हैं। Principles बताते हैं कि इसका मतलब क्या है और क्या नहीं: defects अब भी मौजूद हो सकते हैं, ये 300 tests संभव tests में से एक छोटा-सा चुनाव हैं, और अगर ये महीनों से बिना बदले चल रहे हैं तो शायद अब नए defects पकड़ ही न पाएँ।
यह क्यों ज़रूरी है
जो teams इन principles को अनदेखा करती हैं, वे अनुमानित गलतियाँ करती हैं: "bug-free" release का वादा करती हैं, सब कुछ एक ही गहराई से test करती हैं और समय ख़त्म हो जाता है, code पूरा होने के बाद ही testing शुरू करती हैं, और ऐसे regression suite पर भरोसा करती हैं जिसने बहुत पहले कुछ भी पकड़ना बंद कर दिया। जब failure users तक पहुँचता है, तो हर गलती पैसे या भरोसे का नुकसान कराती है।
Tester के रूप में आपके लिए ये principles आपके फ़ैसलों के तर्क हैं: payment module को settings page से ज़्यादा testing क्यों मिलती है, story बनने से पहले आप उसे क्यों देखना चाहते हैं, और "सारे tests pass हुए" पूरी report क्यों नहीं है। जब आप किसी फ़ैसले की वजह बता सकते हैं, तो उसे मानना आसान होता है।
ISTQB CTFL v4.0 के सात principles
ISTQB Foundation Level syllabus v4.0 का section 1.3 ये सात principles इन्हीं नामों से देता है। हर principle कई projects के लंबे अनुभव का निचोड़ है, और हर एक आपके काम में कुछ बदलता है।
- 1. Testing defects की मौजूदगी दिखाती है, गैरमौजूदगी नहीं (Testing shows the presence, not the absence of defects): यह दिखा सकती है कि defects हैं, पर साबित नहीं कर सकती कि कोई defect नहीं है। यह defects के छिपे रह जाने की संभावना घटाती है।
- 2. Exhaustive testing असंभव है (Exhaustive testing is impossible): बहुत सरल मामलों को छोड़कर सब कुछ test करना संभव नहीं, इसलिए test techniques, test case prioritisation और risk-based testing से effort को focus किया जाता है।
- 3. Early testing समय और पैसा बचाती है (Early testing saves time and money): जल्दी हटाया गया defect उस पर बने work products में आगे defects पैदा नहीं करता, और lifecycle में बाद में कम failures होते हैं।
- 4. Defects एक जगह जमा होते हैं (Defects cluster together): आम तौर पर कुछ ही components में ज़्यादातर defects मिलते हैं, या वही operation में ज़्यादातर failures की वजह बनते हैं; यह Pareto principle का एक उदाहरण है।
- 5. Tests घिस जाते हैं (Tests wear out; पुराना नाम pesticide paradox): बिना बदले बार-बार चलने वाले tests धीरे-धीरे नए defects पकड़ना कम कर देते हैं।
- 6. Testing context पर निर्भर है (Testing is context dependent): कोई एक approach हर product पर फ़िट नहीं होता; अलग contexts में testing अलग तरह से होती है।
- 7. Absence-of-defects fallacy (पुराना नाम absence-of-errors fallacy): सिर्फ़ verification से system सफल नहीं हो जाता; उसे अपने users की ज़रूरतें भी पूरी करनी होती हैं, इसलिए validation भी ज़रूरी है।
Testing क्या दावा कर सकती है और क्या नहीं: principles 1, 2 और 7
Principle 1 आपकी reporting बदलता है। एक bank का app सभी 250 regression tests pass करता है; release के एक हफ़्ते बाद customers पाते हैं कि 31 तारीख़ के लिए set standing transfers 31 से कम दिनों वाले महीनों में छूट जाते हैं। किसी test ने वह तारीख़ इस्तेमाल नहीं की थी। जैसा "सॉफ़्टवेयर टेस्टिंग क्यों ज़रूरी है" वाले पाठ में देखा, pass हुआ run जो test हुआ उसका सबूत है, जो test नहीं हुआ उसका बिल्कुल नहीं; इसलिए scope, results, जो test नहीं हुआ वह और बचा हुआ risk report करें, "bug-free" कभी नहीं।
Principle 2 tests चुनने का तरीका बदलता है। नीचे वाले hotel search form में पाँच fields और 1.7 करोड़ से ज़्यादा valid combinations हैं, invalid values, browsers और devices गिनने से पहले ही। इसलिए आप tests को test design techniques से चुनते हैं, जो आप roadmap में आगे सीखेंगे: हर field के equivalence partitions और boundary values, fields के बीच pairwise combinations, और सबसे ज़्यादा गहराई वहाँ जहाँ failure सबसे ज़्यादा नुकसान करे।
Principle 7 बदलता है कि specification के अलावा आप क्या जाँचते हैं। एक university का course registration portal सभी 40 specified rules पूरे करता है और मिला हर defect ठीक हो चुका है, फिर भी students ऐसे courses में register करते रहते हैं जिनके lectures का समय टकराता है, क्योंकि portal कभी timetable नहीं दिखाता। जैसा verification और validation वाले पाठ में देखा: असली users को मुख्य काम करते देखें, acceptance testing में हिस्सा लें, और ऐसे gaps report करें, भले कोई requirement न टूटी हो।
Hotel search: every valid combination
city 50
check-in 365 (dates up to one year ahead)
nights 30 (1..30)
guests 8 (1..8)
room type 4
------------------------------------------------
50 x 365 x 30 x 8 x 4 = 17,520,000 combinations
At one test per second: about 203 days, nonstopEffort कहाँ और कब लगाएँ: principles 3 से 6
Principle 3 बदलता है कि आप कब शुरू करते हैं। "सॉफ़्टवेयर टेस्टिंग क्यों ज़रूरी है" वाले पाठ ने requirement के एक defect को तीन पलों तक follow किया, और हर अगले पल पर उसकी कीमत बढ़ी; यही हर story पर लागू होता है। एक story कहती है: "Users 5 MB तक की profile photo upload कर सकते हैं।" Refinement में आप पूछते हैं: कौन-से formats allowed हैं, 5 MB का मतलब 5,000,000 bytes है या 5,242,880, और file बहुत बड़ी हो तो user को क्या दिखेगा। अभी के तीन जवाब बाद के तीन defects रोक सकते हैं। Stories, acceptance criteria और designs बनते ही उनका review करें, और जैसे ही कुछ चलाने लायक हो, tests चलाएँ।
Principle 4 बदलता है कि आप सबसे ध्यान से कहाँ देखते हैं। एक online shop की पिछली तीन releases में ज़्यादातर logged defects promotions module में थे, जहाँ discount rules आपस में मिलते हैं। उस module को ज़्यादा test cases, एक exploratory session और हर बदलाव की बारीक जाँच मिलती है, और यह cluster risk-based testing का input बनता है। बाकी जगह हल्की testing जारी रखें: कोई नया feature या rewrite नया cluster शुरू कर सकता है।
Principle 5 बदलता है कि आप tests को कैसे maintain करते हैं। एक checkout suite साल भर से वही तीन products और एक ही test card इस्तेमाल कर रहा है; वह green रहता है, जबकि size variants वाले products का एक defect customers तक पहुँच जाता है। Test data बदलते रहें, और नए features, बदले गए code और हर escaped defect के लिए tests जोड़ें। Automated regression tests के लिए दोहराव फिर भी सही है, क्योंकि उनका काम यह दिखाना है कि जो चलता था वह अब भी चलता है।
Principle 6 बदलता है कि आप कितना formal और कितना गहरा जाते हैं। Insulin dose calculator को systematic test design, requirements तक traceability, documented evidence और independent review चाहिए। दो हफ़्ते के marketing landing page को उसके visitors के browsers पर content, links, forms और layout की तेज़ जाँच चाहिए। Approach चुनने से पहले domain, risks, regulations, team के lifecycle और deadline के बारे में पूछें।
आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर आज़माएँ: रिग्रेशन सिनेरियो जनरेटर
Worked example: "क्या आप गुरुवार तक confirm कर सकते हैं कि कोई bug नहीं है?"
एक pharmacy delivery app में prescription upload जुड़ रहा है: customer prescription की photo लेता है और order तैयार होने से पहले pharmacist उसे जाँचता है। सोमवार को delivery manager पूछता है: "क्या आप सब कुछ test करके confirm कर सकते हैं कि गुरुवार की release से पहले कोई bug नहीं है?" Tester हाँ या ना की जगह principles से जवाब देता है और request को एक plan में बदल देता है:
- Principle 1: "मैं confirm नहीं कर सकता कि कोई bug नहीं है। गुरुवार को मैं दिखा सकता हूँ कि मैंने क्या test किया, क्या fail हुआ, क्या test नहीं कर पाया और कितना risk बचा है।"
- Principle 2: "हर phone, file type, photo quality और prescription state एक साथ बहुत ज़्यादा cases हैं, इसलिए मैं सबसे risky combinations चुनूँगा और बाकी को pairwise से cover करूँगा।"
- Principle 4: "पिछली दो releases में हमारे ज़्यादातर defects prescription check में थे, इसलिए उस हिस्से को सबसे गहरी testing मिलेगी।"
- Principle 5: "हमारा regression suite वसंत से नहीं बदला; मैं expired prescriptions और धुंधली photos के cases जोड़ूँगा, जिन्हें उसने कभी cover नहीं किया।"
- Principle 6: "यह health data और prescription वाली दवाओं का मामला है, इसलिए मैं हर requirement से जुड़ा evidence रखूँगा, promotions banner की तुलना में ज़्यादा formal तरीके से।"
- Principle 7: "क्या मंगलवार को कोई pharmacist check screen आज़मा सकता है? वह specification पर खरी उतरकर भी भीड़ वाले counter पर बहुत धीमी हो सकती है।"
- Principle 3: "अगले feature के लिए मुझे refinement में बुलाइए, ताकि कौन-से file types accept होंगे जैसे सवाल coding से पहले हल हो जाएँ।"
| Principle | इस पाठ से उदाहरण | कौन-सा फ़ैसला बदलता है |
|---|---|---|
| 1 · Defects की मौजूदगी, गैरमौजूदगी नहीं | 250 tests pass, फिर भी 31 तारीख़ वाले transfers छूट जाते हैं | Scope, results, untested हिस्से और बचा risk report करें, "bug-free" कभी नहीं |
| 2 · Exhaustive testing असंभव है | Hotel search form: 17,520,000 valid combinations | Partitions, boundaries, pairwise और risk से tests चुनें |
| 3 · Early testing समय और पैसा बचाती है | 5 MB photo rule पर refinement में ही सवाल | Code बनने से पहले stories और criteria का review करें |
| 4 · Defects एक जगह जमा होते हैं | ज़्यादातर logged defects promotions module में | Cluster को सबसे गहराई से test करें; बाकी जगह हल्की testing रखें |
| 5 · Tests घिस जाते हैं | साल भर वही products और card; size variant वाला defect निकल जाता है | Data बदलें और नए tests जोड़ें; automated regression checks बनाए रखें |
| 6 · Testing context पर निर्भर है | Insulin dose calculator बनाम दो हफ़्ते का landing page | Formality और गहराई domain, risk और regulation से तय करें |
| 7 · Absence-of-defects fallacy | सभी 40 rules पूरे, फिर भी students टकराते lectures चुनते हैं | सिर्फ़ specification से नहीं, असली users के साथ validate करें |
Principles के नाम ISTQB CTFL v4.0, section 1.3 के अनुसार। Syllabus के पुराने versions principle 5 को pesticide paradox कहते हैं।
आम गलतियाँ
- Pass हुए run के बाद "पूरा test हो गया" या "कोई bug नहीं" कहना, बजाय tested scope और बचा हुआ risk बताने के।
- "Exhaustive testing असंभव है" का जवाब random या सतही testing से देना, बजाय techniques और risk से tests चुनने के।
- कुछ भी review करने से पहले testable build का इंतज़ार करना, जिससे requirement defects बाद में code defects बनकर सामने आते हैं।
- सिर्फ़ पिछली release के defect cluster पर ध्यान देना, या defect log को पूरी तरह नज़रअंदाज़ करना।
- Test data और scenarios को महीनों तक न बदलना और लंबे green streak को इस बात का सबूत मानना कि कुछ नया गलत नहीं है।
- किसी दूसरे product से test approach copy करना, या "सारी requirements pass" को "users की ज़रूरतें पूरी" के बराबर मानना।
QA का नज़रिया
Principles tester के हफ़्ते में तय पलों पर सामने आते हैं। Refinement में early testing और absence-of-defects fallacy आपको यह पूछने के लिए प्रेरित करते हैं: "हमें कैसे पता चलेगा कि यह काम करता है, और क्या यह सच में user की समस्या हल करता है?" Test planning में exhaustive testing, defect clustering और context तय करते हैं कि किसे गहरी testing मिलेगी और कितनी formality चाहिए; developers और support के साथ साझा किया गया defect log और production incidents clusters के लिए आपका सबूत हैं।
Reporting में principle 1 हर status report का आकार तय करता है: scope, results, open defects, जो test नहीं हुआ, और residual risk। हर release के अंत में पूछें: किन tests ने लंबे समय से कुछ नहीं पकड़ा, और कौन-से defects production तक पहुँचे? Suite को refresh करने का यही समय है। आपने जो गहराई चुनी उसकी वजह भी लिखें, ताकि अगला tester सिर्फ़ tests नहीं, सोच भी देख सके।
अभ्यास
हर कथन के पीछे का principle पहचानें
नीचे के notes एक school के online fee payment portal की release retrospective से हैं। हर कथन सात principles में से किसी एक को अनदेखा करता है। हर कथन के लिए principle का नाम लिखें, और लिखें कि उसकी जगह आप क्या करेंगे या कहेंगे।
हर principle ठीक एक बार आता है।
Release 5.2 retrospective, school fee payment portal
A. "Regression suite आठ महीनों से green है, इसलिए fee module सुरक्षित है।"
B. "Build staging पर आने के बाद QA जुड़ेगा; stories का review business
analyst का काम है।"
C. "हमने 412 test cases चलाए और हर defect ठीक किया, इसलिए parents नए
instalment plan से खुश होंगे।"
D. "Hospital app वाली checklist ही इस्तेमाल करो, वहाँ वह काम आई थी।"
E. "शुक्रवार से पहले 12 grades, 4 payment methods, 1 से 10 instalments और
5 discount types का हर combination test करो।"
F. "Testing pass हो गई, तो school को बता देते हैं कि कोई bug नहीं है।"
G. "Testing बराबर बाँटो: हर module को दो दिन।"- हर कथन पढ़ें और तय करें कि वह testing के बारे में क्या मान रहा है।
- उसे सात principles में से एक से मिलाएँ; हर principle एक ही बार इस्तेमाल करें।
- उसकी जगह आप जो फ़ैसला लेंगे, उसे एक वाक्य में लिखें।
- कथन E के लिए हिसाब लगाएँ कि "हर combination" का मतलब कितने combinations हैं।
मॉडल उत्तर दिखाएँ
A: Tests घिस जाते हैं। आठ green महीने दिखाते हैं कि suite अब भी pass होता है, यह नहीं कि वह अब भी नए defects पकड़ सकता है। उसका review करें, sibling discount और साल के बीच admission जैसा data बदलें, और 5.2 में जो बदला उसके tests जोड़ें।
B: Early testing समय और पैसा बचाती है। Refinement में stories और acceptance criteria का review माँगें; instalments और refunds के सवाल coding से पहले सबसे सस्ते हैं।
C: Absence-of-defects fallacy। Tests pass होना और defects ठीक होना दिखाता है कि portal अपनी specification पर खरा है, यह नहीं कि parents instalment plan इस्तेमाल कर पाएँगे। कुछ parents से इसे आज़माने को कहें, या release के बाद support calls देखें।
D: Testing context पर निर्भर है। Hospital app और school fee portal के users, data, regulations और risks अलग हैं; checklist इसी product के risks से बनाएँ।
E: Exhaustive testing असंभव है। 12 × 4 × 10 × 5 = 2,400 combinations; हर payment में पाँच मिनट लगें तो 200 घंटे। Combinations के लिए pairwise testing, instalments की गिनती के लिए boundary values (0, 1, 10 और 11), और सबसे risky discount rules पर ज़्यादा गहराई इस्तेमाल करें।
F: Testing defects की मौजूदगी दिखाती है, गैरमौजूदगी नहीं। School को बताएँ कि क्या test हुआ, क्या अब भी open है, क्या test नहीं हुआ और कितना risk बचा है।
G: Defects एक जगह जमा होते हैं। Defect log देखें: अगर पिछली releases में fee calculation और refunds में ज़्यादातर defects थे, तो उन्हें ज़्यादा समय दें, और बाकी modules की हल्की जाँच रखें।
अक्सर पूछे जाने वाले सवाल
क्या सात principles ऐसे rules हैं जिन्हें मानना ज़रूरी है?
नहीं। Syllabus इन्हें ऐसी सामान्य guidelines कहता है जो हर testing पर लागू होती हैं; ये steps या obligations नहीं हैं। इन्हें अपने फ़ैसलों का तर्क देने और दूसरों को समझाने के लिए इस्तेमाल करें; आप असल में क्या करते हैं, वह फिर भी context पर निर्भर है, और यही principle 6 है।
क्या "tests wear out" और pesticide paradox एक ही हैं?
हाँ। ISTQB CTFL v4.0 "tests wear out" नाम इस्तेमाल करता है; syllabus के पुराने versions और कई articles इसी विचार को pesticide paradox कहते हैं। Syllabus यह भी बताता है कि कुछ मामलों में वही tests दोहराना फ़ायदेमंद हो सकता है, जैसे automated regression testing में, क्योंकि उसका काम यह दिखाना है कि जो पहले चलता था वह टूटा नहीं।
अगर defects जमा होते हैं, तो क्या सिर्फ़ उसी cluster को test करूँ?
नहीं। Clusters बताते हैं कि अतिरिक्त गहराई कहाँ लगानी है, यह नहीं कि कहाँ रुकना है। नया feature, rewrite या नया integration कहीं और cluster बना सकता है, इसलिए पूरे product में हल्की testing रखें और हर release में clusters की अपनी समझ update करें।
क्या early testing का मतलब code बनने से पहले testing है?
आंशिक रूप से। Static testing, जैसे requirements, designs और code का review, कोई work product बनते ही शुरू हो सकती है, और test analysis व test design test basis से शुरू हो सकते हैं। Dynamic testing तब शुरू होती है जब कुछ चलाने लायक हो, जैसे एक component। मकसद यह है कि हर defect उसके बनने की जगह के जितना हो सके पास पकड़ा जाए।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
- Lessons Learned in Software Testing: A Context-Driven Approach (Cem Kaner, James Bach, Bret Pettichord)बग रिपोर्टिंग, टेस्ट डिज़ाइन, ऑटोमेशन और टेस्टिंग प्रबंधन पर व्यावहारिक सबक — कॉन्टेक्स्ट-ड्रिवन स्कूल।
Mutqan tools से अभ्यास करें
पैरामीटर और उनकी वैल्यू से न्यूनतम pairwise (all-pairs) टेस्ट सेट जनरेट करें।
फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।
बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।
किसी user story से Given/When/Then acceptance criteria और definition-of-done चेकलिस्ट जनरेट करें।
और गहराई से
- रिस्क-आधारित टेस्टिंगरिस्क-आधारित टेस्टिंग कैसे करें: product risk पहचानें, likelihood और impact स्कोर करें, टेस्ट की गहराई तय करें, regression चुनें और residual risk बताएँ।
- स्टैटिक टेस्टिंगडिफ़ेक्ट की जल्दी पहचान और डिफ़ेक्ट की रोकथाम
- स्मोक, सैनिटी और रिग्रेशन टेस्टिंग में अंतरRegression चयन: क्या चलाएँ
- टेस्ट स्ट्रैटेजी: एक व्यावहारिक गाइडApproach कैसे चुनें और मिलाएँ
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।