टेस्ट सूट और टेस्ट रन
Test suite test cases, procedures या scripts का ऐसा set है जिसे एक मक़सद के लिए साथ चलाने को चुना गया हो: smoke suite, checkout regression suite, या इस sprint की stories के tests। Test run किसी suite का software के एक तय version पर, एक बताए गए environment में, एक execution है, जिसमें हर test का result दर्ज होता है। ISTQB की भाषा में suite tests का set है, और run उसका test object के एक version पर execution है।
उदाहरण: checkout regression suite में 24 test cases हैं। जब build 2.4.0-rc2 (version 2.4.0 का दूसरा release candidate) staging पर पहुँचता है, tester उसी build के लिए इस suite का एक run बनाता है। हर test not run से शुरू होता है और passed, failed, blocked या skipped पर ख़त्म होता है। जब rc3 आता है, नया run शुरू होता है, और rc2 के results इस बात का record बने रहते हैं कि rc2 ने क्या किया।
यह क्यों ज़रूरी है
Suites के बिना testing का हर दौर इस सवाल से शुरू होता है कि "इस बार क्या चलाएँ?", और जवाब इस पर निर्भर करता है कि किससे पूछा गया। Runs के बिना results builds से अलग हो जाते हैं: सोमवार को दर्ज pass को गुरुवार के build के pass से अलग नहीं पहचाना जा सकता, जिसमें तीन बदलाव और हैं, और टीम ऐसे results के भरोसे release करती है जो किसी दूसरे version के हैं।
Tester के लिए run वह record है जिसे दूसरे पढ़ते हैं: क्या पूरा हुआ, क्या fail हुआ, क्या टेस्ट नहीं हो सका और क्यों। Status reports और release के फ़ैसले इसी पर टिकते हैं, इसलिए लापरवाही से लगाया गया status, जैसे blocked test को failed लिख देना, आगे सबको गुमराह करता है।
Test suites: एक मक़सद के लिए tests का group
Test implementation वाले lesson में procedures को suites में group किया गया। कई test management tools में हर test case repository में एक ही बार रखा जाता है, आम तौर पर feature के हिसाब से folders में, और suite एक मक़सद के लिए ज़रूरी cases चुनता है। तब एक case कई suites में हो सकता है; suite उसे copy नहीं करता, सिर्फ़ reference रखता है, इसलिए उसके steps में किया गया सुधार हर suite तक पहुँचता है।
कुछ tools suite को fixed list से बनाते हैं, कुछ query या tag से, जैसे checkout tag वाले और High priority के सभी cases। Automated suites भी ऐसे ही काम करते हैं: एक folder, file या tag जिसे pipeline साथ चलाती है। आम मक़सद:
- Smoke: कुछ checks जो दिखाते हैं कि नया build आगे की testing के लिए काफ़ी stable है।
- Feature: current sprint या release के नए tests।
- Regression: मौजूदा व्यवहार के tests, जो किसी बदलाव के बाद पूरे या risk-based selection के रूप में चलते हैं।
- Configuration: वही tests किसी एक browser, device या भाषा के लिए, जहाँ results अलग हो सकते हैं।
आज़माएँ: टेस्ट केस जनरेटर आज़माएँ: रिग्रेशन सिनेरियो जनरेटर आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर
Test runs और test cycles
ISTQB Foundation syllabus test execution को ऐसे बताता है: tests को execution schedule के अनुसार, test runs में चलाना, actual और expected results की तुलना करना और नतीजा log करना। Run यही log रखता है: हर test का result, साथ में किसने चलाया, कब और किस build पर।
Suite इस सवाल का जवाब देता है कि "क्या टेस्ट करें?" और महीनों तक दोबारा इस्तेमाल होता है। Run बताता है कि "इस build पर, इस environment में क्या हुआ?" और वह testing ख़त्म होने पर close होता है, इसलिए नया build मतलब नया run, पुराने results पर overwrite नहीं। कई टीमें एक build या test period के runs को एक test cycle में group करती हैं, जैसे "Release 2.4, system test cycle 2", जिसमें हर browser का एक run हो। Run header वह दर्ज करता है जो run को reproducible बनाता है:
Run: Checkout regression / 2.4.0-rc2 / Chrome
Suite: Checkout regression (24 test cases)
Cycle: Release 2.4, system test cycle 2
Build: 2.4.0-rc2
Environment: staging, payment sandbox, data baseline CHK-BASE-3
Configuration: Chrome desktop, English UI
Assigned: Sara CHK-01..12, Omar CHK-13..24
Planned: day 1 to day 2पाँच statuses और हर एक का मतलब
Run में हर test का एक ही current status होता है। पहले run से पहले हर status का मतलब तय करके लिख लें, वरना अलग-अलग testers के लिए counts का अलग मतलब होगा। साझा आधार:
- Not run: run के scope में है पर अभी execute नहीं हुआ; कुछ tools इसे "untested" या "to do" कहते हैं।
- Passed: execute हुआ, और हर actual result अपने expected result से मेल खाया।
- Failed: execute हुआ, और कम से कम एक actual result expected से अलग था। कारण का analysis अभी बाक़ी है: product defect, test की गलती या environment की समस्या।
- Blocked: शुरू या पूरा नहीं हो सका क्योंकि test के बाहर की किसी चीज़ ने रोका, जैसे environment बंद होना, data या access न होना, या पिछले step का कोई defect। कारण लिखें और रोकने वाले issue को link करें।
- Skipped: इस run में दर्ज फ़ैसले से जान-बूझकर execute नहीं हुआ, जैसे feature यहाँ बंद है या test इस configuration पर लागू नहीं होता। Automated test reports code में disabled tests को भी skipped दिखाती हैं, और कुछ frameworks इसे तब भी इस्तेमाल करते हैं जब कोई set-up step fail हुआ हो, जो blocked के ज़्यादा क़रीब है: गिनने से पहले जाँचें कि मामला कौन-सा है।
| # | से | तक | Event या फ़ैसला |
|---|---|---|---|
| 1 | Not runशुरुआत | Passedपास | Execute हुआ: हर actual result अपने expected result से मेल खाता है |
| 2 | Not runशुरुआत | Failedफ़ेल | Execute हुआ: कम से कम एक actual result expected से अलग है |
| 3 | Not runशुरुआत | Blockedसावधानी | शुरू या पूरा नहीं हो सका: environment बंद, data या access नहीं, या पहले का कोई defect रास्ते में; कारण link किया जाता हैवैकल्पिक पथ |
| 4 | Blockedसावधानी | Not runशुरुआत | Blocker हटा: वापस queue में, फिर executeवैकल्पिक पथ |
| 5 | Not runशुरुआत | Skipped | इस run में न चलाने का दर्ज फ़ैसला, कारण के साथवैकल्पिक पथ |
| 6 | Failedफ़ेल | Passedपास | Fix वाले build पर retest pass: नया result; failed result history में रहता हैवैकल्पिक पथ |
Executed = Passed + Failed। Blocked, Skipped और Not run अलग गिने जाते हैं। Tools इन statuses को अलग-अलग नाम देते हैं।
Worked example: एक regression run को track करना
नीचे checkout regression run दिन 1 के अंत में है; passed और not run के अलावा हर status के साथ एक note है।
Executed यानी passed और failed का जोड़: 24 में से 17। Pass rate, यानी passed को executed से भाग देना, 17 में से 15 है, लगभग 88%, पर अकेले यह 3 blocked और 3 not run बाक़ी tests और एक skipped test को छिपा देता है, इसलिए summary पाँचों संख्याएँ दिखाती है। आगे के क़दम:
- Failed, CHK-05 और CHK-06: दोनों एक ही defect, DEF-512, से linked हैं, और fix वाले build पर retest होते हैं (ISTQB की भाषा में confirmation testing); हर एक को नया result मिलता है और उसके साथ वह build दर्ज होता है।
- Blocked, CHK-02 से CHK-04: सब environment issue ENV-77 का इंतज़ार कर रहे हैं, जिसका एक owner है। Sandbox वापस आने पर वे not run में लौटते हैं और execute होते हैं; बिना चलाए passed कभी नहीं।
- Skipped, CHK-07: कारण और फ़ैसला लेने वाले का नाम दर्ज है, इसलिए coverage की कमी report में दिखती है।
- Not run, CHK-22 से CHK-24: दिन 2 के लिए planned; समय कम पड़े तो test lead तय करता है कि उन्हें skip करें या run बढ़ाएँ।
Run: Checkout regression / 2.4.0-rc2 / Chrome end of day 1
ID Test case Status Note
CHK-01 Pay cash on delivery, single item Passed
CHK-02 Pay by card, 3-D Secure challenge Blocked ENV-77 payment sandbox down
CHK-03 Pay by card, declined card Blocked ENV-77
CHK-04 Refund to card after cancellation Blocked ENV-77
CHK-05 Apply promo code SAVE10 Failed DEF-512 discount applied twice
CHK-06 Remove promo code Failed DEF-512 (same cause)
CHK-07 Pay with a digital wallet Skipped wallet off on staging (test lead)
CHK-08 .. CHK-21 (14 tests) Passed
CHK-22 .. CHK-24 (3 tests) Not run planned for day 2
Planned 24 Passed 15 Failed 2 Blocked 3 Skipped 1 Not run 3
Executed (passed + failed) 17 Pass rate 15 / 17 = 88%आम गलतियाँ
- Blocked test को failed mark करना, जिससे developers ऐसी समस्या के पीछे भागते हैं जो उनकी नहीं है।
- Test को passed mark करना क्योंकि वह पिछले build पर pass हुआ था, या क्योंकि जो steps चल सके वे ठीक थे।
- नया run शुरू करने की जगह पिछले build के results पर overwrite करना, जिससे कोई नहीं बता सकता कि कौन-सा result किस build का है।
- समय पर ख़त्म करने के लिए चुपचाप tests skip करना। Skip के लिए कारण और फ़ैसले का ज़िम्मेदार व्यक्ति चाहिए, वरना report ऐसा coverage दिखाती है जो हुआ ही नहीं।
- सिर्फ़ pass rate रिपोर्ट करना, जो blocked या not run tests के बारे में कुछ नहीं बताता।
- Suites को मक़सद की जगह लोगों के इर्द-गिर्द बनाना ("अहमद के tests"), जिससे owner के जाने के बाद कोई नहीं जानता कि suite क्या cover करता है।
QA का नज़रिया
ज़्यादातर टीमों में test lead plan से runs बनाता है: कौन-से suites, builds, environments और configurations, और कौन क्या चलाएगा। Testers दिन भर अपना हिस्सा current रखते हैं, क्योंकि developers, test lead और product owner उसे पढ़कर अपना अगला क़दम तय करते हैं। हर failure को उसके defect से और हर block को उसके कारण से link करें, और stand-up में बताएँ कि क्या blocked है और उसका owner कौन है।
Run शुरू होने से पहले पूछें: ठीक कौन-सा build? कौन-सा environment और configuration? कौन-से suites scope में हैं? और यहाँ आपके statuses का मतलब क्या है? नया build आने पर दोनों runs की status lists की तुलना करें, जैसे text diff से: जो test rc2 पर pass और rc3 पर fail हो, वह संभावित regression है।
अभ्यास
Login suite के run को track करें
Login suite में 10 test cases हैं, LOG-01 से LOG-10, जो build 5.1.0 पर staging में Chrome पर चलते हैं। LOG-01 से LOG-05 अपने expected results से मेल खाते हैं। LOG-06 "Locked account से login" lockout message की जगह dashboard दिखाता है। LOG-07 और LOG-08 को SMS से one-time code चाहिए, और SMS stub बंद है। LOG-09 "SSO से login" (single sign-on) सिर्फ़ enterprise edition पर लागू होता है, जो staging पर नहीं है; test lead इसे न चलाने पर सहमत है। दिन ख़त्म होने तक LOG-10 शुरू नहीं हुआ।
Run के results वैसे ही दर्ज करें जैसे आप test management tool में करते हैं।
- हर test को status दें, और जहाँ ज़रूरी हो note भी।
- हर status गिनें, फिर executed और pass rate।
- जो test pass नहीं हुआ, उसके लिए अगला क़दम लिखें।
मॉडल उत्तर दिखाएँ
Statuses: LOG-01 से LOG-05 passed। LOG-06 failed, नई defect report से linked; login कर सकने वाला locked account एक security control को bypass करता है। LOG-07 और LOG-08 blocked, note: SMS stub बंद, environment issue से linked। LOG-09 skipped, note: enterprise edition staging पर नहीं, test lead का फ़ैसला। LOG-10 not run।
Summary: passed 5, failed 1, blocked 2, skipped 1, not run 1। Executed = 6। Pass rate = 5 / 6, लगभग 83%। अभी execute होने बाक़ी: 3 tests (LOG-07, LOG-08 और LOG-10), और fix के बाद LOG-06 का retest।
आगे: LOG-06 fix वाले build पर retest होगा और नया result पाएगा। Stub वापस आने पर LOG-07 और LOG-08 not run में लौटेंगे और फिर execute होंगे। LOG-09 enterprise edition वाले environment के run में जाएगा, या report में यह कमी बताई जाएगी। LOG-10 अगले दिन सबसे पहले चलेगा।
अक्सर पूछे जाने वाले सवाल
Test suite और test run में क्या फ़र्क़ है?
Suite किसी मक़सद के लिए चुने गए tests का दोबारा इस्तेमाल होने वाला set है, जैसे smoke या checkout regression। Run किसी suite या उसके हिस्से का एक execution है, एक तय build पर और एक तय environment में, हर test के result के साथ। एक suite के अपनी उम्र में आम तौर पर कई runs होते हैं।
क्या blocked test और failed test एक ही हैं?
नहीं। Failed test execute हुआ और expected से अलग result आया। Blocked test execute या पूरा नहीं हो सका, इसलिए वह अभी यह नहीं बताता कि feature काम करता है या नहीं। Blocked tests अलग गिने जाते हैं और उन्हें कारण और blocker का owner चाहिए।
Fix के बाद retest उसी run में जाए या नए run में?
यह टीम के तरीके और उसके tool पर निर्भर है। कई टीमें retest को उसी run में fix वाले build के साथ नए result के रूप में जोड़ती हैं; कुछ नए build के लिए नया run बनाती हैं। दोनों हालात में failed result history में रखें और दर्ज करें कि नया result किस build का है।
Test cycle क्या है?
टीमें "test cycle" शब्द test execution के एक दौर के लिए इस्तेमाल करती हैं, अक्सर एक build या एक test period के सभी runs के लिए, जैसे "system test cycle 2"। Tools run, execution और cycle शब्दों को अलग-अलग तरह इस्तेमाल करते हैं, इसलिए जानें कि आपकी टीम का tool हर शब्द से क्या मतलब लेता है।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
Mutqan tools से अभ्यास करें
फ़ीचर के विवरण और फ़ील्ड सूची से संरचित टेस्ट केस (id, शीर्षक, पूर्व-शर्तें, स्टेप, अपेक्षित परिणाम, प्राथमिकता) जनरेट करें।
बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।
फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।
प्रतिशत, प्रतिशत परिवर्तन, वृद्धि/कमी और X, Y का कितना प्रतिशत है — सब गिनें।
दो टेक्स्ट की लाइन-दर-लाइन या शब्द-दर-शब्द तुलना करें और अंतर हाइलाइट करें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।