टेस्ट एनालिसिस
Test analysis वह test activity है जो सवाल "क्या टेस्ट करें?" का जवाब देती है। Tester test basis पढ़ता है — user stories, acceptance criteria, business rules, designs, API contracts — और उसे test conditions में बदलता है। ISTQB के अनुसार test condition किसी component या system का ऐसा testable पहलू है जिसे testing के आधार के रूप में पहचाना गया हो। हर condition अपने source से जुड़ी होती है और उसे एक priority दी जाती है।
उदाहरण: "Expired promo code पर error दिखे और total न बदले" से दो conditions मिलती हैं: expired code reject होता है, और total वही रहता है। इससे एक सवाल भी उठता है जिसका जवाब story में नहीं है: क्या code अपनी expiry date वाले दिन भी valid है, और किस time zone के हिसाब से? यह कमी ढूँढना भी analysis का हिस्सा है।
यह क्यों ज़रूरी है
बाद में design किया गया हर test सिर्फ़ वही cover करता है जो आपने टेस्ट करने का फ़ैसला किया था। जो rule कभी test condition नहीं बनता, उसका कोई test case नहीं बनता, और यह कमी तब तक किसी को नहीं दिखती जब तक कोई customer उसे न पकड़ ले। Analysis testing के scope को तब दिखाता है जब वह अभी एक छोटी सूची है जिसे टीम review कर सकती है।
यह defects पकड़ने के सबसे शुरुआती मौक़ों में से भी एक है। विरोधाभासी या अधूरी requirement अभी मिल जाए तो एक वाक्य बदलकर ठीक हो जाती है; coding के बाद मिले तो code change और retest चाहिए, या वह पहले customers तक पहुँच जाती है। Tester के लिए analysis वह जगह है जहाँ वह product सीखता है और वे सवाल पूछकर टीम का भरोसा जीतता है जो किसी और ने नहीं पूछे।
क्या टेस्ट करें, कैसे नहीं
ISTQB test process में test analysis, test planning के बाद और test design से पहले आता है। पिछले पाठ का test plan scope, approach और risk levels तय करता है; analysis उसी scope के अंदर ठीक-ठीक तय करता है कि क्या टेस्ट करना है। फिर अगले पाठ का विषय test design हर condition को test cases में बदलकर "कैसे टेस्ट करें?" का जवाब देता है।
ये तार्किक activities हैं, सख़्त phases नहीं। STLC model इस काम को requirement analysis कहता है, और कई टीमें story के refinement के लिए तैयार होते ही इसे शुरू कर देती हैं।
- Input: scope वाले features का test basis, साथ में test plan से risks और approach।
- Output: priority वाली test conditions, हर एक अपने source से जुड़ी। अच्छे acceptance criteria सीधे test conditions का काम कर सकते हैं।
- Output: ख़ुद test basis के बारे में defect reports, जब defect उसी समय ठीक न हो।
- अभी नहीं: steps, ठोस data और expected screens; ये test design का काम हैं।
- 1Test basisTest plan से scope और risk levelsUser stories, acceptance criteria, business rules, designs, API contracts
- 2Basis का मूल्यांकनAmbiguity, omission, contradiction, untestable wording
शाखा: Basis में defect → product owner को सवाल या defect report
- 3Test conditions पहचानेंहर condition में एक testable पहलू, id और source के साथ
- 4Risk के हिसाब से priorityLikelihood × impact → High, Medium या Low, वजह के साथ
- 5Priority वाली test conditions"क्या टेस्ट करें?" का जवाबOutput
चरण 1 पर वापस हर जवाब basis को update करता है; जो बदला उसका फिर से analysis करें
इसके बाद:Test design में: हर condition को कैसे टेस्ट करें
सरल रूप: practice में steps एक-दूसरे पर चढ़ते हैं, और analysis हर story और basis के हर बदलाव पर दोहराया जाता है।
Test basis का मूल्यांकन करें और उसके defects report करें
कुछ भी निकालने से पहले test basis को आलोचनात्मक नज़र से पढ़ें: ISTQB testers से उसे defects और testability के लिए जाँचने को कहता है। Requirement भी code की तरह एक work product है, इसलिए लिखने वाले की errors requirement में defects बनती हैं, और अगर कोई उन्हें न पकड़े तो आगे चलकर product में failures बन सकती हैं।
हर finding वहाँ दर्ज करें जहाँ टीम उस पर काम करेगी: story पर comment, refinement में सवाल, या defect report। जवाब का चुपचाप अंदाज़ा न लगाएँ; अंदाज़ा ऐसा expected result बन जाता है जिस पर किसी ने सहमति नहीं दी। आम defects:
- Ambiguity: "आपके order पर 10% छूट" — सिर्फ़ items पर, या delivery fee पर भी?
- Omission: story expired code को cover करती है, पर unknown या गलत टाइप किए गए code को नहीं।
- Contradiction: एक criterion हर order पर एक code की इजाज़त देता है; एक pricing rule loyalty members को दूसरा code जोड़ने देता है।
- Untestable wording: "साफ़ तौर पर दिखे", "fast", "user-friendly", "ज़रूरत के अनुसार" — result को किसी चीज़ से compare नहीं किया जा सकता।
आज़माएँ: AI Requirement अस्पष्टता डिटेक्टर आज़माएँ: AI Requirement गैप एनालाइज़र
Test conditions पहचानें
Test condition एक testable पहलू का नाम है: कोई rule, व्यवहार, state, error path या quality characteristic। Steps नहीं, वह लिखें जो सच होना चाहिए: "discount VAT से पहले calculate होता है" एक condition है; "SAVE10 टाइप करें और Apply दबाएँ" एक test step है जो design में आता है। कुछ टीमें conditions को test ideas या एक लाइन के test scenarios की तरह लिखती हैं, हालाँकि एक scenario में अक्सर कई conditions जुड़ी होती हैं। Basis को व्यवस्थित ढंग से पढ़ें ताकि आप happy path पर न रुक जाएँ:
- हर acceptance criterion और business rule: कम से कम एक condition, अक्सर एक positive और एक negative।
- हर input, state और role: valid और invalid values, success और failure, कौन action ले सकता है और कौन नहीं।
- Implicit ज़रूरतें: error messages, Arabic और right-to-left layouts, accessibility, performance।
- हर condition का एक id और source (AC2, BR-9 या "implicit"), ताकि बाद में coverage trace हो सके।
आज़माएँ: User Story → टेस्ट सिनेरियो आज़माएँ: Requirements → टेस्ट सिनेरियो
Conditions को risk के हिसाब से prioritise करें
हर condition एक जितनी मेहनत की हक़दार नहीं होती, और ISTQB test conditions को उनके risk levels के साथ prioritise करने का काम test analysis में ही रखता है। आसान शुरुआत likelihood × impact है: complexity और हाल के बदलावों को देखते हुए यहाँ defect की कितनी संभावना है, और failure users या business के लिए कितना बुरा होगा? हर condition को High, Medium या Low दें, एक लाइन की वजह के साथ।
Priority design और execution का क्रम और testing की गहराई तय करती है: High priority वाली price calculation को कई techniques मिलती हैं, Low priority वाले label check को एक test। Low-priority conditions को सूची में रखें, भले ही आप उन्हें टेस्ट न करने का फ़ैसला करें: दिखने वाला फ़ैसला टीम का स्वीकार किया हुआ risk है, न दिखने वाला एक gap।
Worked example: promo code वाली story
एक online shop अगले sprint में story US-214 लाने वाली है, और test plan checkout pricing को high risk मानता है। नीचे का block test basis और analysis का नतीजा दिखाता है: कोई test बनने से पहले product owner को भेजे गए चार सवाल, और priority वाली आठ conditions।
C1 से C5 तक की conditions High हैं क्योंकि वे तय करती हैं कि customer कितना भुगतान करेगा, जिसे test plan high risk मानता है: वहाँ का defect customers से गलत रकम वसूलता है। C4, C5 और C7 तब तक design नहीं हो सकतीं जब तक product owner जवाब न दे, और ठीक इसी वजह से सवाल अभी उठाए गए हैं।
US-214 Checkout पर promo code लगाना
AC1 Valid code order के subtotal को अपने percentage से घटाता है।
AC2 Expired code पर error दिखता है और total नहीं बदलता।
AC3 हर order पर सिर्फ़ एक code इस्तेमाल हो सकता है।
AC4 Discount order summary पर साफ़ तौर पर दिखता है।
BR-9 Discount VAT से पहले के subtotal पर लगता है।
पहले से sale वाले items पर और discount नहीं मिलता।
Loyalty members promo code के साथ अपना member code जोड़ सकते हैं।
Product owner के लिए सवाल (US-214 पर comments)
Q1 Contradiction AC3: हर order पर एक code; BR-9: loyalty members दूसरा जोड़ सकते हैं।
Q2 Untestable AC4 "साफ़ तौर पर": summary में ठीक-ठीक क्या दिखना चाहिए?
Q3 Ambiguity AC2: क्या code expiry date वाले दिन valid है, और किस time zone में?
Q4 Omission BR-9: sale और regular दोनों items वाले cart का क्या होगा?
Test conditions
C1 AC1 High Valid code subtotal को अपने percentage से घटाता है।
C2 BR-9 High Discount VAT से पहले calculate होता है।
C3 AC2 High Expired code reject होता है और total नहीं बदलता।
C4 AC3, BR-9 High उसी order पर दूसरा code (Q1 के जवाब तक blocked)।
C5 BR-9 High Sale items पर discount नहीं, mixed cart में भी (Q4 का इंतज़ार)।
C6 implicit Medium Unknown या गलत टाइप किया code error दिखाता है।
C7 AC4 Medium Summary code और discount की राशि दिखाता है (Q2 के बाद)।
C8 implicit Medium Code field और summary Arabic interface में ठीक काम करते हैं।आम गलतियाँ
- सीधे steps और data वाले test cases पर कूद जाना, जिससे किसी को नहीं दिखता कि क्या छूट गया।
- Test basis को सही मान लेना और अस्पष्ट requirement का मतलब चुपचाप अंदाज़े से तय कर लेना।
- सिर्फ़ happy path से conditions निकालना और error paths, roles और implicit ज़रूरतें भूल जाना।
- बहुत अस्पष्ट ("promo codes टेस्ट करें"), बहुत विस्तृत, या बिना source वाली conditions लिखना।
- हर condition को एक जैसी priority देना, या वजह दर्ज किए बिना prioritise करना।
- Findings को chat में या अपने दिमाग़ में रखना, जिससे जवाब कभी story तक नहीं पहुँचते।
QA का नज़रिया
असली टीम में test analysis तब शुरू होता है जब story refinement के लिए तैयार होती है, तब नहीं जब build आता है। कई टीमें इसका एक हिस्सा product owner, एक developer और एक tester की छोटी बातचीत में करती हैं, जिसे कभी-कभी "three amigos" कहा जाता है। Draft conditions और सवाल साथ लाएँ: "जब… हो तो क्या होगा?", "दो rules टकराएँ तो कौन-सा लागू होगा?", "हमें कैसे पता चलेगा कि काम पूरा हुआ?"
Conditions को source और priority के साथ वहाँ दर्ज करें जहाँ टीम काम करती है: test management tool, story या shared sheet। जवाब आने पर पक्का करें कि वह story में लिखा जाए, क्योंकि अब वह test basis का हिस्सा है। मेहनत risk के अनुपात में रखें: pricing change पूरी सूची का हक़दार है, label change के लिए तीन लाइनें काफ़ी हैं।
अभ्यास
Clinic booking की story का analysis करें
एक clinic अपने patient app में online booking जोड़ रहा है। नीचे की story test basis है, और test plan double booking और patient privacy को high risk मानता है। सिर्फ़ test analysis करें, test cases नहीं: product owner के लिए अपने सवाल और sources के साथ prioritised test conditions लिखें।
US-57 Clinic appointment online बुक करना
Patient के रूप में मैं doctor के साथ appointment online बुक करना चाहता हूँ
ताकि मुझे clinic को फ़ोन न करना पड़े।
AC1 Patient एक doctor, एक तारीख़ और 20 मिनट का एक ख़ाली slot चुनता है।
AC2 Appointments अधिकतम 30 दिन पहले तक बुक किए जा सकते हैं।
AC3 एक patient के एक ही समय पर दो appointments नहीं हो सकते।
AC4 Patient को जल्दी confirmation मिलता है।
AC5 Appointment शुरू होने से 24 घंटे पहले तक cancel किया जा सकता है।- जो अस्पष्ट, अधूरा, विरोधाभासी या untestable हो उसे चिह्नित करें, और हर finding को product owner के लिए सवाल में बदलें।
- Conditions उनके sources के साथ लिखें: हर criterion के लिए कम से कम एक, और implicit conditions भी।
- हर condition को High, Medium या Low दें, एक लाइन की वजह के साथ।
मॉडल उत्तर दिखाएँ
सवाल: AC4 का "जल्दी" untestable है: कितने मिनट में, किस channel से, किस भाषा में? AC2: 30 दिन आज से गिने जाएँगे या इसी पल से, और क्या 30वाँ दिन शामिल है? AC5: आख़िरी 24 घंटों में cancel करने पर क्या होगा? और अगर दो patients एक ही पल में एक ही slot चुनें तो?
Conditions: C1 (AC1) ख़ाली slot बुक हो सकता है; C2 (AC1) भरा हुआ slot बुक नहीं हो सकता, तब भी जब दो patients उसे एक साथ चुनें; C3 (AC2) 30 दिन की limit लागू है; C4 (AC3) उसी समय दूसरा appointment reject होता है, दूसरे doctor के साथ भी; C5 (AC4) confirmation भेजा जाता है; C6 (AC5) जल्दी किया गया cancellation slot ख़ाली कर देता है; C7 (AC5) देर से किया गया cancellation मिले हुए जवाब के अनुसार चलता है; C8 (implicit) patient दूसरे patient का appointment न देख सकता है, न cancel कर सकता है; C9 (implicit) pages Arabic में ठीक काम करते हैं।
Priorities: C1, C2, C4 और C8 के लिए High, क्योंकि वहाँ failure booking रोकता है, doctor या patient की double booking करता है, या patient data उजागर करता है; बाक़ी के लिए Medium, क्योंकि वहाँ failure परेशानी तो देता है पर इनमें से कुछ नहीं करता, और C5 व C7 जवाबों का इंतज़ार भी कर रही हैं। ख़ुद जाँचें: हर condition का source है, हर अस्पष्ट बात सवाल बनी, और सूची में अभी कोई steps या ठोस तारीख़ें नहीं हैं।
अक्सर पूछे जाने वाले सवाल
Test condition और test case में क्या फ़र्क़ है?
Test condition बताती है कि क्या टेस्ट करना है: "expired code reject होता है"। Test case बताता है कैसे: preconditions, inputs जैसे कल expire हुआ code, steps और expected result। Test design में एक condition से आम तौर पर कई test cases बनते हैं, और एक test case एक से ज़्यादा conditions cover कर सकता है।
क्या test analysis और STLC का requirement analysis एक ही हैं?
काफ़ी हद तक हाँ, बस क्रम अलग है। STLC model अपने पहले चरण को requirement analysis कहता है और उसे test planning से पहले रखता है; ISTQB test process उसी काम को test analysis कहता है, उसे planning के बाद रखता है और बताता है कि उसकी activities अक्सर iterative या parallel तरीके से चलती हैं। ISO/IEC/IEEE 29119-2 इसे अपने test design और implementation process के पहले steps में रखता है: feature sets पहचानना और test conditions derive करना। Practice में planning और analysis एक-दूसरे को जानकारी देते हैं, और analysis हर story, release और test level के लिए, और जब भी basis बदले, दोहराया जाता है।
क्या requirement की समस्या को defect के रूप में report करें?
यह एक work product का defect है, और ISTQB test basis के defects की reports को test analysis के work products में गिनता है, जब defect सीधे ठीक न किया जाए। कई टीमें इसकी जगह story पर सवाल या comment दर्ज करती हैं। Format से ज़्यादा नतीजा मायने रखता है: वह दिखे, उसका कोई owner हो, और जवाब basis में वापस लिखा जाए।
अगर लिखित requirements न हों तो?
तब test basis वह सब है जो आपको मिल सके: बातचीत, मौजूदा system का व्यवहार, user documentation, मिलते-जुलते products, support tickets। जो conditions आप निकालें और जिन assumptions पर वे टिकी हैं, उन्हें लिखें और product owner से confirm कराएँ। अक्सर आपकी सूची ही feature के बारे में पहला लिखित record होती है।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
- ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesटेस्ट प्रक्रिया मॉडल: संगठनात्मक, टेस्ट प्रबंधन और dynamic टेस्ट प्रक्रियाएँ, उनकी गतिविधियों और परिणामों के साथ।
Mutqan tools से अभ्यास करें
coverage मैपिंग के साथ functional आवश्यकताओं से टेस्ट सिनेरियो निकालें।
किसी user story से end-to-end टेस्ट सिनेरियो निकालें, वैकल्पिक और अपवाद flow सहित।
फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।
requirements में अस्पष्ट, धुँधले या परस्पर विरोधी कथन पकड़ें और Mutqan AI से स्पष्टीकरण के सवाल पाएँ।
Mutqan AI से छूटी हुई requirements खोजें — error handling, permissions, edge conditions, non-functional ज़रूरतें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।