क्या automate करें और क्या नहीं
क्या automate करना है, यह तय करने का मतलब है हर check के लिए चुनना कि उसे script चलाएगी या इंसान। लगभग हर चीज़ automate हो सकती है, इसलिए असली सवाल यह है कि automation अपनी लागत वसूल करेगा या नहीं। किसी web shop में cart के price और VAT के 40 combinations हर release पर दोबारा check होते हैं, हर एक का expected total exact है और वे शायद ही बदलते हैं: ये script के लायक हैं। Home page का promo banner, जिसे marketing हर महीने redesign करती है, लायक नहीं है।
यह lesson test automation के फ़ायदों और risks को ऐसे फ़ैसले में बदलता है जिसका आप बचाव कर सकें: हर check के लिए तीन हिस्सों वाला नियम, और return on investment (ROI) का ऐसा हिसाब जिसमें वे लागतें भी हों जिन्हें teams अक्सर छोड़ देती हैं।
यह क्यों ज़रूरी है
गलत checks automate करने से product को दोहरा नुकसान होता है: ऐसे checks की scripts लिखने और ठीक करने में समय जाता है जो कम चलते हैं या बार-बार बदलते हैं, और ज़रूरी checks manual रह जाते हैं क्योंकि budget ख़त्म हो चुका होता है। CTFL v4.0 test automation के risks में ये दोनों कारण गिनाता है: जहाँ manual testing ज़्यादा उचित हो वहाँ tool इस्तेमाल करना, और test scripts के maintenance की मेहनत का ग़लत अंदाज़ा लगाना।
Tester जानता है कि कौन-से checks हर release पर दोहराए जाते हैं, किनमें judgement चाहिए और कौन-से features अभी बदल रहे हैं, इसलिए यह फ़ैसला उसके काम का हिस्सा है। साफ़ नियम और ईमानदार numbers के साथ आप बता सकते हैं कि पहले क्या automate हो, और उस exploratory testing का समय बचा सकते हैं जो कोई script नहीं करती।
क्या automate करने लायक है
अच्छा candidate वह check है जिसे वरना कोई इंसान एक ही steps और exact expected result के साथ बार-बार दोहराता। आम candidates:
- Regression checks जिन्हें हर release पर pass होना है: sign-in, checkout और उनके पीछे के business rules।
- हर deployment के बाद smoke checks, जो पुष्टि करते हैं कि build टेस्ट करने लायक है भी या नहीं।
- Specification के मुक़ाबले API और contract checks: आम तौर पर UI से वही check करने से तेज़ और ज़्यादा stable।
- Data-driven checks: boundary values, currencies, locales, roles या browsers की कई rows पर वही steps।
- ऐसा काम जो कोई इंसान हाथ से नहीं कर सकता, जैसे सैकड़ों concurrent users का load बनाना।
- बार-बार की तैयारी: test data बनाना और environments reset करना, जिससे manual testers का समय भी बचता है।
आज़माएँ: रिग्रेशन सिनेरियो जनरेटर आज़माएँ: OpenAPI → टेस्ट केस
क्या automate न करें, या अभी नहीं
ये checks आम तौर पर इंसान बेहतर करता है। इनमें से कुछ "कभी नहीं" नहीं, "अभी नहीं" हैं: जो feature स्थिर हो जाए, या जिस dependency का stub बन जाए (एक सरल नक़ली component जो असली service की जगह लेकर तय जवाब लौटाता है), वह बाद में candidate बन जाता है।
- Exploratory testing और नए feature पर पहला pass, जब तक expected behaviour अभी खोजा जा रहा हो। Script सिर्फ़ वही check करती है जिसका किसी ने पहले से अनुमान लगाया था।
- Judgement: wording साफ़ है या नहीं, Arabic screen right-to-left स्वाभाविक रूप से पढ़ी जाती है या नहीं, कोई flow उलझाने वाला है या नहीं। Tools colour contrast जैसे हिस्से माप सकते हैं; फ़ैसला इंसान का रहता है।
- एक बार वाले checks, जैसे पिछले weekend के data migration की जाँच: इसे एक बार हाथ से या एक throwaway query से करें।
- हर sprint में बदलने वाले features: redesign हो रही screen, A/B experiment, prototype।
- जिस पर test का नियंत्रण नहीं: CAPTCHA, जो automation रोकने के लिए ही बना है, या असली phone पर पहुँचने वाला असली SMS। Test configuration या stub माँगें, और असली चीज़ समय-समय पर हाथ से check करें।
नियम: frequency, determinism, stability
हर candidate से इसी क्रम में तीन सवाल पूछें, और automate तभी करें जब तीनों के जवाब हाँ हों।
Frequency: अपनी उपयोगी ज़िंदगी में check कितनी बार चलेगा? Releases को data rows, browsers और languages से गुणा करें: साल में 26 releases पर 40 rows यानी 1,040 executions। जो check एक बार चलता है, वह automated test बनाने और उसके upkeep की लागत वसूल नहीं करता; अगर वह हाथ से करने के लिए बहुत बड़ा है, तो एक throwaway query या script काफ़ी है।
Determinism: क्या script ख़ुद pass या fail तय कर सकती है, और क्या एक ही input हर run में एक ही result देता है? "Total 115.00 SAR है" एक तय expected result है; "page अच्छा दिखता है" नहीं। जो result घड़ी, random data, shared account या live third-party service पर निर्भर हो, वह अभी repeatable नहीं है: समय को control करें, test को अपना data ख़ुद बनाने दें या service का stub लगाएँ, फिर automate करें। Martin Fowler का non-determinism वाला article बताता है कि इसे छोड़ने की क़ीमत क्या है: जब tests बिना वजह fail होते हैं, तो team failures को नज़रअंदाज़ करना सीख जाती है।
Stability: क्या behaviour, और check जिस interface का इस्तेमाल करता है, अगले कुछ महीनों तक वैसे ही रहेंगे? Business rules layouts से कम बदलते हैं। अगर नहीं, तो अभी हाथ से टेस्ट करें और इसे candidate list में रखें।
- तीन हाँ से candidate बनता है, आदेश नहीं: candidates को risk के हिसाब से क्रम दें, जैसे risk-based testing में।
- उस सबसे निचले level पर automate करें जहाँ check व्यक्त हो सके, जैसे price rule को UI की बजाय API से। Test automation pyramid वाला lesson इसे आगे बढ़ाता है।
- फिर हिसाब लगाएँ: जिस check का हर run का upkeep उसकी manual लागत के क़रीब हो, वह कभी लागत वसूल नहीं करता।
उत्तर: नहीं
परिणाम: Manual रखें: एक बार का checkइसे एक बार हाथ से या throwaway query से चलाएँ।उत्तर: हाँ
प्रश्न 2: क्या script इंसानी judgement के बिना pass या fail तय कर सकती है?Determinism: तय expected resultउत्तर: नहीं
परिणाम: Manual रखें: judgement चाहिएWording, layout, usability; सिर्फ़ मापने लायक हिस्से automate करें।उत्तर: हाँ
प्रश्न 3: क्या एक ही input हर run में एक ही result देता है?Determinism: घड़ी, random data या live services पर निर्भरता नहींउत्तर: नहीं
परिणाम: पहले इसे deterministic बनाएँघड़ी control करें, test को उसका अपना data दें, service का stub लगाएँ; फिर दोबारा पूछें।उत्तर: हाँ
प्रश्न 4: क्या behaviour और interface महीनों तक वैसे ही रहेंगे?Stability: business rules layouts से कम बदलते हैंउत्तर: नहीं
परिणाम: अभी नहीं: हाथ से टेस्ट करेंइसे candidate list में रखें; feature स्थिर होने पर दोबारा देखें।उत्तर: हाँ
प्रश्न 5: क्या check हटने से पहले यह अपनी लागत वसूल करता है?ईमानदार ROI: build और upkeep बनाम वे manual runs जो सच में होतेउत्तर: नहीं
परिणाम: Manual रखें: लागत वसूल नहींहर run का upkeep manual run के क़रीब है, या screen पहले ही बदल जाएगी।उत्तर: हाँ
परिणाम: Automate करेंसबसे निचले level पर जहाँ यह व्यक्त हो सके, risk के क्रम में।
आज का "नहीं" बाद में "हाँ" बन सकता है: feature स्थिर होने पर या test environment में stub आने पर दोबारा पूछें।
Automation ROI, ईमानदारी से
ROI एक ही अवधि में automation की बचत की तुलना उसकी लागत से करता है। Regression check में मापी जा सकने वाली बचत वह manual execution time है जो अब ख़र्च नहीं होता; लागत वह सब कुछ है जो automated check ख़र्च करता है, सिर्फ़ उसे लिखना नहीं।
- सिर्फ़ वही manual runs गिनें जो सच में होते। अगर regression हर release पर एक बार हाथ से चलता है, तो baseline वही है, भले script हर commit पर चले।
- बाक़ी फ़ायदे उनकी अपनी units में बताएँ: commit के कुछ मिनटों में feedback, consistent results, exploratory work के लिए खाली testers। इन्हें गढ़े हुए घंटों में न बदलें।
- पहले दिन से upkeep जोड़ें: product का हर बदलाव जो check को छूता है, हर failed run जिसे किसी को पढ़ना है, हर flaky test जिसे किसी को ठीक करना है।
- Break-even की तुलना check की अनुमानित उम्र से करें: अगर screen चार महीने में redesign होगी, तो छह महीने वाला break-even कभी नहीं आएगा।
- अपनी assumptions लिखें, और कुछ महीनों बाद estimates की जगह असली घंटे रखें।
Period: one year. Run: one regression cycle, for example one release.
Manual cost = manual hours per run x runs a person would really do
Automation cost = build hours (write, review, test data, setup)
+ upkeep hours per run x runs
upkeep = fixes after product changes, reading failed runs,
fixing flaky tests, CI time and licences in hours
ROI = (manual cost - automation cost) / automation cost
Break-even = build hours / (manual hours per run - upkeep hours per run)
no break-even when upkeep per run >= manual hours per runWorked example: एक web shop के तीन checks
एक web shop हर दो हफ़्ते में release करती है और हर release से पहले अपनी manual regression list चलाती है: साल में 26 runs। Team ने तीन candidates का अनुमान लगाया; upkeep में maintenance और failed runs पढ़ना शामिल है।
- A तीनों सवाल पास करता है: इसे API से automate करें। यह हर commit पर भी चलेगा; वह तेज़ feedback असली फ़ायदा है, पर 52 घंटों में शामिल नहीं। दूसरे साल से, build की लागत के बिना, यह हर साल 39 घंटे बचाता है।
- B stability में fail होता है, और numbers भी यही कहते हैं: हर release का upkeep manual check का चार गुना है। यह manual release checklist में रहता है।
- C determinism में fail हुआ था क्योंकि code असली phone पर आता था। Developers ने test environment में SMS stub जोड़ा, जो production में बंद है, और अब check तीनों सवाल पास करता है। फिर भी हर production release के बाद एक tester असली phone से sign in करता है, क्योंकि stub यह साबित नहीं कर सकता कि असली SMS delivery काम करती है; यह check manual release checklist में रहता है और उन 25 घंटों में शामिल नहीं जिनकी जगह script लेती है।
Release every 2 weeks: 26 manual regression runs a year
A Cart price and VAT rules, 40 data rows, checked through the API
Manual 2.0 h x 26 = 52 h a year
Automated 16 h build + 0.5 h x 26 = 29 h in year 1
Break-even 16 / (2.0 - 0.5) = 10.7 -> release 11, about 5 months
ROI year 1 (52 - 29) / 29 = 79 %
B Home page promo banner, redesigned every month, checked in the UI
Manual 0.25 h x 26 = 6.5 h a year
Automated 6 h build + 1.0 h x 26 = 32 h in year 1
Break-even none: upkeep 1.0 h per run > manual 0.25 h per run
C Sign-in with an SMS one-time code, using an SMS stub in the test environment;
today checked by hand after each of ~100 staging deploys a year
Manual 0.25 h x 100 = 25 h a year
Automated 10 h build + 0.05 h x 100 = 15 h in year 1
Break-even 10 / (0.25 - 0.05) = 50 -> deploy 50, about 6 months
ROI year 1 (25 - 15) / 15 = 67 %आम गलतियाँ
- Checks को frequency, risk और stability की बजाय इस आधार पर चुनना कि उनकी script लिखना कितना आसान है।
- अस्पष्ट या गलत test case automate करना: script उस बुरे check को और तेज़ी से दोहराती है।
- ऐसा feature automate करना जो अब भी हर sprint में बदलता है, और फिर हर sprint scripts ठीक करने में बिताना।
- ऐसा ROI जो वे manual runs गिनता है जो कोई करता ही नहीं, और upkeep, failed runs का analysis और infrastructure छोड़ देता है।
- Non-deterministic test को suite में रखना और उसे तब तक दोबारा चलाना जब तक वह green न हो जाए।
- "Automated नहीं" को "टेस्ट नहीं हुआ" मान लेना: manual checks और exploratory sessions को भी plan में समय चाहिए।
QA का नज़रिया
यह फ़ैसला बार-बार आता है: refinement में, जब आप पूछते हैं कि क्या story के rules controlled data के साथ API से check हो सकते हैं; जब कोई feature stable होता है; और जब regression list plan होती है। एक candidate list रखें जिसमें check, तीनों जवाब, build और upkeep का अनुमान, risk, फ़ैसला और दोबारा देखने की तारीख़ हो। Automation engineers build का अनुमान देते हैं; product owner जानता है कि feature कितने समय तक वैसा ही रहेगा।
Testability जल्दी माँगें: एक stub, test hook या controllable clock अक्सर determinism के "नहीं" को "हाँ" में बदल देता है। हर तिमाही उन checks को हटाएँ जो अब अपना upkeep नहीं कमाते, और ROI पहले estimate से नहीं, असली घंटों से report करें।
अभ्यास
तय करें कौन-से regression checks automate हों
एक clinic booking web app हर दो हफ़्ते में release होता है, यानी साल में 26 releases। नीचे के चार checks पर frequency, determinism और stability का नियम लगाएँ और हर एक के लिए तय करें: automate करें, किसी बदलाव के बाद automate करें, अभी manual रखें, या manual रखें। फिर जिस check को आप सबसे पहले automate करेंगे, उसका break-even और पहले साल का ROI निकालें।
1. Booking rules: doctor, दिन, time slot और patient type के 30 combinations
(double booking नहीं, slots सिर्फ़ opening hours में)। Booking API से हाथ से
check होते हैं: हर release पर 1.5 घंटे। Rules एक साल से नहीं बदले।
अनुमान: build 12 घंटे, upkeep हर release 0.25 घंटे।
2. Appointment से 24 घंटे पहले reminder, जो patient के in-app inbox में दिखता है।
आज tester असली समय बीतने का इंतज़ार करता है या database में appointment
की तारीख़ बदलता है।
3. नई "family accounts" screen, अगले sprint में release; उसका design अभी
users के साथ परखा जा रहा है।
4. एक बार की जाँच: पिछले weekend दो branches merge होने पर 8,000 appointments
सही तरह move हुए या नहीं।- हर check के लिए तीनों सवालों के जवाब दें और लिखें कि कौन-सा fail होता है।
- जो check determinism में fail हो, उसके लिए वह बदलाव बताएँ जो उसे ठीक करेगा।
- Check 1 के लिए manual लागत, automation लागत, break-even और पहले साल का ROI निकालें।
- हर check का फ़ैसला और उसे दोबारा कब देखना है, लिखें।
मॉडल उत्तर दिखाएँ
Check 1: frequent (हर release पर 30 combinations), deterministic (हर combination का rules में तय result है) और stable। इसे API से automate करें। Manual लागत 1.5 × 26 = 39 घंटे; automation लागत 12 + 0.25 × 26 = 18.5 घंटे। Break-even 12 / (1.5 − 0.25) = 9.6, यानी release 10 पर, लगभग पाँच महीने में। पहले साल का ROI (39 − 18.5) / 18.5 ≈ 111 %; दूसरे साल, build के बिना, यह 32.5 घंटे बचाता है। हर तिमाही असली upkeep घंटों के साथ इसे दोबारा देखें, या booking rules बदलें तो उससे पहले।
Check 2: frequent और stable, पर deterministic नहीं, क्योंकि यह असली घड़ी पर निर्भर है। Test environment में controllable clock माँगें, या चुने हुए समय के लिए reminder job चलाने का तरीक़ा, फिर इसे automate करें। तब तक इसे हाथ से check करें, और बदलाव मिलने पर दोबारा देखें।
Check 3: stability में fail; expected behaviour अभी खोजा जा रहा है। अभी इसे हाथ से explore करें और release के बाद design स्थिर होने पर दोबारा देखें।
Check 4: frequency में fail, क्योंकि यह एक बार चलता है। इसे हाथ से check करें, counts और records के एक sample की तुलना के लिए throwaway query के साथ, और इसे regression suite में न जोड़ें।
अक्सर पूछे जाने वाले सवाल
क्या हर regression test automate होना चाहिए?
हर वह regression check जो हर release पर चलता है, तीनों सवाल पास करता है और अपने build और upkeep की लागत वसूल करता है, risk के क्रम में automate करने लायक है। जिन checks में judgement चाहिए, जो अक्सर बदलते हैं या control नहीं हो सकते, वे एक छोटी manual checklist में रहते हैं। कोई सही percentage नहीं है; बँटवारा product के हिसाब से होता है।
क्या ROI के लिए exact numbers चाहिए?
नहीं। Estimates इस्तेमाल करें, पर assumptions लिखें: execution records से हर run के manual मिनट, script लिखने वाले से build का अनुमान, और upkeep का ऐसा आँकड़ा जिसमें failed runs पढ़ना शामिल हो। Best case और worst case एक number से ज़्यादा ईमानदार हैं। कुछ महीनों बाद estimates की जगह असली घंटे रखें।
अगर check ज़रूरी है पर deterministic नहीं, तो?
पहले उसे deterministic बनाएँ: घड़ी control करें, test को उसका अपना data दें, external services के stubs लगाएँ। अगर यह संभव न हो, तो उसे manual रखें या सिर्फ़ वह हिस्सा automate करें जिसका result तय है। Release को gate करने वाली suite में randomly fail होने वाला test न छोड़ें।
क्या हर release पर एक बार चलने वाला check काफ़ी frequent है?
यह उसकी लागत पर निर्भर है। साल के 26 runs कम upkeep वाले लंबे manual check की लागत वसूल कर देते हैं, जैसे API से 40 data rows, लेकिन पाँच मिनट के उस check की नहीं जिसकी screen के बदलाव हर महीने script तोड़ देते हैं। Break-even formula हर case में इसका जवाब देता है।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0टेस्ट ऑटोमेशन समाधान और उनकी आर्किटेक्चर के डिज़ाइन, कार्यान्वयन और रखरखाव पर ISTQB का advanced पाठ्यक्रम।
- Eradicating Non-Determinism in Tests (Martin Fowler)flaky टेस्ट सूट का मूल्य क्यों नष्ट करते हैं, उनके आम कारण (isolation, asynchrony, remote services, समय, resource leak) और जवाब के रूप में quarantine।
- The Practical Test Pyramid (Ham Vocke)ऑटोमेटेड टेस्ट पोर्टफ़ोलियो में unit, integration, contract और UI टेस्ट का संतुलन कैसे रखें — व्यापक रूप से उद्धृत व्याख्या।
Mutqan tools से अभ्यास करें
बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।
OpenAPI / Swagger स्पेसिफ़िकेशन से संरचित टेस्ट-केस मैट्रिक्स (positive, negative, auth, boundary) बनाएँ।
फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।
प्रतिशत, प्रतिशत परिवर्तन, वृद्धि/कमी और X, Y का कितना प्रतिशत है — सब गिनें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।