टेस्ट डिज़ाइन

टेस्ट प्लान कैसे लिखें

Mutqan Soft की QA टीम द्वारा · · 10 मिनट पढ़ने का समय

इसका हिस्सा: टेस्ट स्ट्रैटेजी: एक व्यावहारिक गाइड

Test plan प्रोजेक्ट या रिलीज़ स्तर का दस्तावेज़ है जो बताता है कि क्या टेस्ट होगा, कैसे, कौन करेगा, कब, किन environment में और किन मानदंडों पर टेस्टिंग शुरू और बंद होगी। यह संगठन की test strategy को एक scope पर लागू करता है और उससे जुड़ा हर फ़ैसला दर्ज करता है: कौन-से फ़ीचर शामिल हैं और कौन-से बाहर, हर एक कितनी गहराई से टेस्ट होगा, schedule किस पर निर्भर है, और कौन-से जोखिम ख़ुद टेस्टिंग को पटरी से उतार सकते हैं।

यह गाइड पूरे plan की सामग्री बताती है, उसे नियंत्रित करने वाले चार तरह के मानदंड समझाती है, prioritisation, scheduling और resource planning कवर करती है, और एक कॉपी-रेडी टेम्पलेट, agile टीमों के लिए हल्का एक-पेज रूप और एक काल्पनिक रिलीज़ का उदाहरण अंश देती है।

Test plan किसलिए होता है

Plan उन सवालों का जवाब देता है जो stakeholder टेस्टिंग से पहले और दौरान पूछते हैं: हम ठीक-ठीक क्या टेस्ट कर रहे हैं, जान-बूझकर क्या टेस्ट नहीं कर रहे, रिलीज़ के लिए पर्याप्त जानकारी कब होगी, आपको हमसे क्या चाहिए, और आपको क्या रोक सकता है। अगर ये जवाब सिर्फ़ QA lead के दिमाग़ में हैं, तो plan मौजूद ही नहीं है, दस्तावेज़ चाहे जो कहे।

क्लासिक आउटलाइन IEEE 829 से आती है, जिसके test plan सेक्शन (test items, टेस्ट होने और न होने वाले फ़ीचर, approach, pass/fail मानदंड, suspension और resumption, deliverables, environment, ज़िम्मेदारियाँ, schedule, जोखिम, approvals) आज भी ज़्यादातर टेम्पलेट में पहचाने जा सकते हैं। IEEE 829-2008 की जगह अब ISO/IEC/IEEE 29119 सीरीज़ ने ले ली है; इसका भाग 3, ISO/IEC/IEEE 29119-3, अब test documentation का अंतरराष्ट्रीय संदर्भ है और प्रोजेक्ट के लिए चुनी गई test strategy को test plan का हिस्सा मानता है। ISTQB CTFL v4.0 syllabus test plan की सामान्य सामग्री इसी तरह बताता है: टेस्टिंग का संदर्भ, मान्यताएँ और सीमाएँ, stakeholder, communication, risk register, test approach, और बजट व schedule।

Plan एक जीवित दस्तावेज़ है। यह test design शुरू होने से पहले लिखा जाता है, development, product और operations के साथ review होता है, approve होता है, और फिर scope, तारीख़ या जोखिम बदलने पर अपडेट होता है — version नंबर के साथ ताकि सबको पता हो कि वे कौन-सा पढ़ रहे हैं।

Test plan में क्या होता है

  • Scope — रिलीज़ या प्रोजेक्ट, test items (build, service, ऐप, version) और टेस्ट होने वाले सिस्टम की सीमाएँ।
  • Test objectives — इस राउंड की टेस्टिंग को क्या ढूँढना या दिखाना है, जैसे "पेमेंट में कोई Critical डिफ़ेक्ट नहीं" या "रिलीज़ 4.0 का हर acceptance criterion verify"।
  • टेस्ट होने वाले फ़ीचर — requirement या story ID के साथ और risk level के साथ, ताकि हर फ़ीचर की टेस्टिंग की गहराई दिखे।
  • टेस्ट न होने वाले फ़ीचर — कारण के साथ (बदला नहीं, रिलीज़ से बाहर, vendor का और vendor द्वारा टेस्ट)। यह सेक्शन सबसे महँगी ग़लतफ़हमियाँ रोकता है।
  • Approach — test level और type, हर फ़ीचर के लिए design तकनीकें, क्या automate है और कहाँ चलता है, regression scope, non-functional testing, और strategy से कोई विचलन उसके औचित्य के साथ।
  • Entry, exit, suspension और resumption मानदंड — अगला सेक्शन देखें।
  • Environments — कौन-से environment, version, integration और sandbox, डिवाइस और ब्राउज़र, और access कौन देता है।
  • Test data — कहाँ से आता है (synthetic, जनरेट किया), मात्रा, कैसे reset होता है, और privacy सीमाएँ।
  • Schedule और milestones — तारीख़ों के साथ टेस्ट गतिविधियाँ और development, design व operations milestones पर उनकी निर्भरता।
  • Resources, भूमिकाएँ और ज़िम्मेदारियाँ — कौन design, execute, automate, triage, report और sign-off करता है; allocation और ज़रूरी training।
  • जोखिम और mitigation — ख़ुद टेस्टिंग के लिए project risks (देर से build, अस्थिर environment, कौशल की कमी), हर एक का owner। Product risks उस risk analysis में आते हैं जो टेस्ट की गहराई तय करता है।
  • मान्यताएँ और dependencies — plan क्या मानकर चलता है और टेस्टिंग को दूसरी टीमों से क्या, कब तक चाहिए।
  • Deliverables — test cases, automated tests, status reports, defect reports, test completion report।
  • Approvals — plan कौन approve करता है और, अलग से, रिलीज़ का फ़ैसला कौन लेता है।

आज़माएँ: Requirements → टेस्ट केस आज़माएँ: AI टेस्ट कवरेज एनालाइज़र

Entry, exit, suspension और resumption मानदंड

मानदंड बहस को जाँच में बदलते हैं। Entry criteria तय करते हैं कि कोई टेस्ट गतिविधि कब शुरू हो सकती है; exit criteria तय करते हैं कि वह कब पूरी मानी जाए। Suspension criteria बताते हैं कि टेस्टिंग कब रोकनी चाहिए क्योंकि जारी रखना मेहनत बर्बाद करेगा, और resumption criteria बताते हैं कि दोबारा शुरू करने से पहले क्या ठीक होना चाहिए। End-to-end quality assurance गाइड बताती है कि entry और exit criteria रिलीज़ गेट की तरह कैसे काम करते हैं; plan का काम उन्हें अपने scope के लिए खास और मापने योग्य बनाना है।

हर तरह का मानदंड टेस्ट गतिविधि के एक कदम की रखवाली करता है: entry उसे शुरू करता है, suspension रोकता है, resumption दोबारा शुरू करता है, exit पूरा करता है; रिलीज़ का फ़ैसला अलग है।
ट्रांज़िशन
#सेतकमानदंड
1शुरू नहीं हुईशुरुआतटेस्टिंग जारीEntry criteria पूरे, जैसे build टेस्ट environment पर deploy, smoke suite हरा
2टेस्टिंग जारीरुकी हुईSuspension criterion लागू: नए build पर smoke फ़ेल, मुख्य environment या sandbox तय समय से ज़्यादा उपलब्ध नहीं, या एक डिफ़ेक्ट टेस्ट के बड़े हिस्से को block करे
3रुकी हुईटेस्टिंग जारीResumption criteria पूरे: ठीक किया build smoke पास करे, environment बहाल हो, या blocking डिफ़ेक्ट ठीक होने की पुष्टि हो
4टेस्टिंग जारीपूरीअंतExit criteria पूरे, जैसे नियोजित टेस्ट execute, कोई open Blocker या Critical डिफ़ेक्ट नहीं

पूरी होने का मतलब रिलीज़ नहीं है: रिलीज़ का फ़ैसला exit criteria पर आधारित एक अलग approval है। हर मानदंड ऐसे लिखें कि दो लोग एक ही हाँ/ना पर पहुँचें।

  • Entry — build टेस्ट environment पर deploy, smoke suite हरा, acceptance criteria review हो चुके, test data लोड, ज़रूरी integration उपलब्ध।
  • Exit — नियोजित टेस्ट execute (जैसे सभी High-risk टेस्ट और बाक़ी का कम से कम तय प्रतिशत), कोई open Blocker या Critical डिफ़ेक्ट नहीं, बचे डिफ़ेक्ट product owner द्वारा स्वीकार, regression suite हरा, non-functional लक्ष्य पूरे।
  • Suspension — नए build पर smoke टेस्ट फ़ेल, कोई मुख्य environment या sandbox तय समय से ज़्यादा उपलब्ध नहीं, या एक ही डिफ़ेक्ट नियोजित टेस्ट के बड़े हिस्से को block करे।
  • Resumption — ठीक किया build smoke टेस्ट पास करे, environment बहाल हो, या blocking डिफ़ेक्ट ठीक होने की पुष्टि हो।
  • हर मानदंड ऐसे लिखें कि दो लोग एक ही हाँ/ना पर पहुँचें; "पर्याप्त रूप से टेस्ट किया" कोई मानदंड नहीं है।

Prioritisation, schedule और resources

टेस्ट के काम को पहले जोखिम से क्रम दें: जिन फ़ीचर के फ़ेल होने की संभावना और असर सबसे ज़्यादा है, उनके टेस्ट पहले design और execute हों, ताकि समय ख़त्म हो तो जो बिना टेस्ट बचे वह सबसे कम ख़तरनाक हो। इस क्रम के भीतर dependencies का ध्यान रखें — build और डेटा के बिना फ़ीचर टेस्ट नहीं हो सकता — और उस चीज़ को जल्दी टेस्ट करें जो redesign करवा सकती है, जैसे पेमेंट या identity providers से integration। Coverage-based और requirements-based क्रम उपयोगी द्वितीयक नियम हैं।

Schedule को रिलीज़ के फ़ैसले से उल्टा बनाएँ। डिफ़ेक्ट ठीक करने और re-test के लिए, आख़िरी regression run के लिए, और स्थिर build चाहने वाले non-functional टेस्ट के लिए साफ़ समय छोड़ें। Resource planning सिर्फ़ headcount नहीं है: दर्ज करें कि हर गतिविधि के लिए ज़रूरी domain ज्ञान, डिवाइस access और automation कौशल किसके पास है, और वह व्यक्ति उपलब्ध न हो तो क्या होगा। मेहनत के आँकड़े ख़ुद estimate से आते हैं, जिसे test estimation गाइड कवर करती है।

  • सबसे जोखिम भरी और सबसे ज़्यादा निर्भरता वाली टेस्टिंग पहले schedule करें, सबसे आसान नहीं।
  • कम से कम एक fix-and-retest चक्र की योजना बनाएँ; जिन plans में यह नहीं होता वे मानते हैं कि कोई डिफ़ेक्ट नहीं होगा।
  • हर अहम कौशल के लिए नामित backup रखें: पेमेंट domain, मोबाइल डिवाइस, performance tooling।
  • Milestones को सिर्फ़ तारीख़ों से नहीं, घटनाओं से जोड़ें: "cycle 1 तब शुरू होगा जब entry criteria पूरे हों", साथ में लक्ष्य तारीख़।

आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर आज़माएँ: AI रिस्क-बेस्ड टेस्ट जनरेटर

Test plan टेम्पलेट

नीचे की आउटलाइन कॉपी करें और जो आपके संदर्भ में ज़रूरी नहीं उसे हटा दें। जो सेक्शन ख़ाली रहे, उसमें कारण लिखें ("कोई performance testing नहीं: इस रिलीज़ में server-side बदलाव नहीं") बजाय उसे ग़ायब करने के, क्योंकि उसकी अनुपस्थिति भी एक फ़ैसला है।

TEST PLAN - <product> <release or project>        ID: TP-<nnn>   Version: <x.y>
Status: Draft | In review | Approved     Owner: <QA lead>      Date: <yyyy-mm-dd>
Strategy reference: <link to test strategy and its version>

1.  Introduction and context
    Purpose, release summary, links to requirements, designs and the risk register
2.  Scope
    2.1 Test items                builds, services, apps, platforms and versions under test
    2.2 Features to be tested     <ID> <feature> - risk level - depth of testing
    2.3 Features not to be tested <feature> - reason
3.  Test objectives               what this round of testing must find or show
4.  Approach
    Levels and types; design techniques per feature; automation (what runs where);
    regression scope; non-functional testing; deviations from the strategy and why
5.  Criteria
    5.1 Entry   5.2 Exit   5.3 Suspension   5.4 Resumption
6.  Test environments             environments, versions, sandboxes, devices, browsers, access
7.  Test data                     sources (synthetic), volumes, reset procedure, privacy rules
8.  Schedule and milestones       activities, target dates, dependencies
9.  Resources and responsibilities  roles, people, allocation, backups, training needs
10. Estimates                     effort ranges and the assumptions behind them
11. Risks and mitigations         project risk - likelihood/impact - mitigation - owner
12. Assumptions and constraints
13. Dependencies                  what testing needs from whom, by when
14. Deliverables                  test cases, automated tests, status reports,
                                  defect reports, test completion report
15. Communication and reporting   cadence, channel, audience, escalation path
16. Approvals                     name - role - decision - date

आज़माएँ: टेस्ट प्लान जनरेटर आज़माएँ: AI QA चेकलिस्ट जनरेटर

Agile टीमों के लिए हल्का test plan

Scrum और मिलते-जुलते frameworks में लंबे समय के फ़ैसले strategy और Definition of Done में रहते हैं, और plan का बड़ा हिस्सा backlog में रहता है: हर story के साथ उसके acceptance criteria होते हैं और टीम sprint planning में टेस्टिंग tasks की योजना बनाती है। हर स्प्रिंट या रिलीज़ के लिए जो लिखने लायक बचता है वह छोटा है: लक्ष्य, क्या शामिल और क्या बाहर, सबसे बड़े जोखिम और वे कैसे टेस्ट होंगे, कौन-सा regression चलेगा, environment और डेटा किस पर निर्भर हैं, और Definition of Done में कोई जोड़। टीम wiki में रखा और sprint board से जुड़ा एक पन्ना काफ़ी है।

SPRINT TEST PLAN - Bustan Market, sprint 42 (fictional)      one page, team wiki

Goal:      Customers can pay with Apple Pay on iOS and web; saved-card flow unchanged
In scope:  BUS-812 Apple Pay (iOS app, Safari), BUS-815 order confirmation email (ar/en)
Out:       Android wallet payments (planned for sprint 44), seller portal
Top risks: R1 payment captured but order not created (L4 x I5)
              -> idempotency and retry tests at API level, automated in CI
           R2 Arabic email totals misaligned (L3 x I3) -> RTL rendering check
Approach:  API tests for the new payment endpoint; one exploratory session per story;
           regression = automated checkout suite + manual saved-card check on 2 devices
Env/data:  staging + payment provider sandbox; synthetic customers only
DoD adds:  acceptance criteria pass; 0 open Blocker/Critical; regression green; demo done
Who:       Sara (QA, iOS), Omar (QA, web/API); developers own unit and API tests
If blocked: sandbox outage -> use mocked gateway responses; raise in daily stand-up

उदाहरण: एक रिलीज़ test plan का अंश

उदाहरण के लिए, नीचे का अंश Bustan Market की रिलीज़ 4.0 के plan से है — वही काल्पनिक सऊदी marketplace जो test strategy गाइड में इस्तेमाल हुआ है। यह वे सेक्शन दिखाता है जिन्हें लोग अक्सर अस्पष्ट छोड़ देते हैं: जोखिम और गहराई के साथ फ़ीचर, कारण के साथ न टेस्ट होने वाले फ़ीचर, मापने योग्य मानदंड, fix-and-retest चक्र वाला schedule, और owner वाले project risks।

  • उदाहरण के entry मानदंड: 4.0.0-rc staging पर deploy, smoke हरा, acceptance criteria review हो चुके, payment sandbox उपलब्ध, और synthetic data set v7 लोड।
  • Exit मानदंड: सभी High-risk टेस्ट execute होकर pass (या product owner की लिखित छूट), सभी नियोजित टेस्ट में से कम से कम 95% execute, कोई open Blocker या Critical डिफ़ेक्ट नहीं, ज़्यादा से ज़्यादा 3 open Major डिफ़ेक्ट और हर एक की fix तारीख़ तय, लगातार दो रात regression हरा, और सामान्य peak के 3 गुना load पर checkout API का p95 800 ms से कम।
  • Suspension मानदंड: नए build पर smoke फ़ेल, sandbox 4 working hours से ज़्यादा बंद, या एक ही डिफ़ेक्ट से 30% से ज़्यादा नियोजित टेस्ट blocked।
  • Resumption मानदंड: ठीक किया build smoke पास करे, sandbox बहाल हो, या blocking डिफ़ेक्ट ठीक होने की पुष्टि हो — हर suspension कारण के लिए वापसी की एक मेल खाती शर्त।
TEST PLAN TP-040 - Bustan Market 4.0 "One-page checkout" (fictional excerpt)  v1.1

2.2 Features to be tested                                   Risk    Depth
    CHK-01 One-page checkout, web + apps (ar/en)            High    boundaries, negative,
                                                                    exploratory, auto regression
    CHK-02 Coupon and promotion stacking rules              High    decision table (14 rules),
                                                                    automated API tests
    CHK-03 Cash-on-delivery limit (max 2,000 SAR)           Medium  1,999.99 / 2,000.00 / 2,000.01
    CHK-04 Delivery slot picker (Hijri/Gregorian display)   Medium  both calendars, ar/en, RTL
    CHK-05 Order confirmation SMS and email                 Low     content check ar/en, one pass

2.3 Features not to be tested
    Seller portal - unchanged in 4.0; covered by the nightly regression suite only
    Courier tracking internals - partner-owned; our webhook handling IS in scope

5.  Criteria
    Entry:   4.0.0-rc deployed to staging; smoke green; acceptance criteria reviewed;
             payment sandbox reachable; synthetic data set v7 loaded
    Exit:    all High-risk tests executed and passed (or waived in writing by the PO);
             >= 95% of all planned tests executed; 0 open Blocker/Critical;
             <= 3 open Major defects, each with a fix date; regression green two nights
             running; p95 checkout API < 800 ms at 3x normal peak
    Suspend: smoke fails on a new build; sandbox down > 4 working hours;
             > 30% of planned tests blocked by one defect
    Resume:  fixed build passes smoke; sandbox restored; blocking defect verified

8.  Schedule (working days)
    D1-D3   design + data setup        D4-D11  execution, cycle 1 (High risk first)
    D12-D13 fix verification + full regression    D14 load test    D15 go/no-go

11. Project risks                         Mitigation                          Owner
    Payment sandbox instability           mocked gateway for negative paths   QA lead
    Late delivery of CHK-02 promotions    API-level tests first, UI last      Dev lead
    One tester on leave D8-D10            developer pairs on regression runs  Eng. manager

आज़माएँ: रिग्रेशन सिनेरियो जनरेटर

Test plan की आम गलतियाँ

  • ऐसा plan जो strategy दोहराता है और इस रिलीज़ के बारे में कुछ नहीं कहता।
  • "टेस्ट न होने वाले फ़ीचर" सेक्शन ही नहीं — फिर हर कोई मान लेता है कि उसका फ़ीचर कवर है।
  • ऐसे exit criteria जो मापे नहीं जा सकते ("पर्याप्त coverage", "स्थिर build")।
  • Fix और re-test के लिए समय नहीं, या ऐसा schedule जो रिलीज़ की तारीख़ पर ख़त्म होता है और go/no-go फ़ैसले के लिए कोई buffer नहीं।
  • Product risks (यूज़र के लिए क्या फ़ेल हो सकता है) और project risks (टेस्टिंग को क्या रोक सकता है) को एक ही बिना-भेद सूची में मिलाना।
  • Approval के लिए एक बार लिखा और फिर कभी अपडेट नहीं; रिलीज़ के बीच तक यह किसी और प्रोजेक्ट का वर्णन करता है।
  • ऐसे लोगों से approval जिन्होंने इसे कभी पढ़ा नहीं — इसके बजाय scope, मानदंड और जोखिम उनके साथ मीटिंग में review करें।

अक्सर पूछे जाने वाले सवाल

Test plan और test strategy में क्या फ़र्क़ है?

Strategy संगठन या प्रोडक्ट स्तर का लंबे समय तक चलने वाला विवरण है कि टेस्टिंग कैसे होती है। Test plan इसे एक प्रोजेक्ट या रिलीज़ पर लागू करता है: यह scope, ये मानदंड, यह schedule, ये लोग, ये जोखिम।

Test plan के मुख्य सेक्शन कौन-से हैं?

Scope और test items, objectives, टेस्ट होने और न होने वाले फ़ीचर, approach, entry/exit/suspension/resumption मानदंड, environments, test data, schedule, resources और ज़िम्मेदारियाँ, जोखिम और mitigation, मान्यताएँ और dependencies, deliverables और approvals।

क्या agile टीमों को test plan चाहिए?

उन्हें वे फ़ैसले चाहिए जो plan दर्ज करता है, ज़रूरी नहीं कि लंबा दस्तावेज़। लक्ष्य, scope, बड़े जोखिम, approach, regression, environment और Definition of Done के जोड़ वाला एक-पेज स्प्रिंट या रिलीज़ test plan आम तौर पर काफ़ी है; बाक़ी backlog और strategy में रहता है।

Test plan कौन लिखता और approve करता है?

आम तौर पर QA lead या test manager टीम के इनपुट के साथ लिखता है। Product owner या project manager, development lead और ज़रूरत हो तो operations उसे approve करते हैं। रिलीज़ का फ़ैसला ख़ुद exit criteria पर आधारित एक अलग approval है।

Suspension और resumption criteria क्या हैं?

Suspension criteria बताते हैं कि टेस्टिंग कब रोकनी चाहिए क्योंकि जारी रखना मेहनत बर्बाद करेगा — smoke टेस्ट फ़ेल, environment उपलब्ध नहीं, या एक डिफ़ेक्ट कई टेस्ट block करे। Resumption criteria बताते हैं कि दोबारा शुरू करने के लिए क्या सच होना चाहिए, जैसे ठीक किया build smoke टेस्ट पास करे।

क्या test plan के लिए IEEE 829 अब भी इस्तेमाल होता है?

इसकी आउटलाइन अब भी जानी-पहचानी है और कई टेम्पलेट इसी पर आधारित हैं, लेकिन IEEE 829-2008 की जगह ISO/IEC/IEEE 29119 सीरीज़ ने ले ली है, और ISO/IEC/IEEE 29119-3 अब test documentation का अंतरराष्ट्रीय मानक है। दोनों को सामग्री की checklist की तरह इस्तेमाल करें, भरने वाले फ़ॉर्म की तरह नहीं।

संदर्भ

अभ्यास

Banking app रिलीज़ के कमज़ोर test plan को सुधारें

आपका काम

टीम के एक नए सदस्य ने एक बैंक (काल्पनिक) के mobile app की रिलीज़ 6.1 के test plan का पहला draft लिखा है। Release brief और draft नीचे दिए गए हैं। Go/no-go मीटिंग plan के 12वें working day (D12) पर है, और product owner इसी हफ़्ते plan approve करना चाहता है।

Draft को इस कसौटी पर review करें कि test plan में क्या होना चाहिए, कम से कम छह समस्याएँ लिखें, फिर वे सेक्शन दोबारा लिखें जो सबसे ज़्यादा फ़ैसले तय करते हैं: टेस्ट होने और न होने वाले फ़ीचर, चारों तरह के मानदंड, schedule और जोखिम। Brief से बाहर कोई नया तथ्य न गढ़ें; जहाँ brief चुप है, वहाँ वह सवाल लिखें जो आप पूछेंगे। प्रतिशत और घंटों जैसी सीमाएँ आपके फ़ैसले हैं: उन्हें ऐसे लिखें कि जाँची जा सकें।

सामग्री
RELEASE BRIEF - एक retail bank का mobile banking app 6.1 (काल्पनिक)
दिन:        working days; D1 इस plan का पहला दिन है
नया:        Scheduled transfers - भविष्य की किसी तारीख़ पर एक बार, या चुने गए दिन पर
            हर महीने; अपने accounts के बीच और saved local beneficiaries को। जिस महीने
            में चुना गया दिन नहीं होता, उसमें मासिक transfer आख़िरी दिन चलता है।
            Customer scheduled transfer को चलने से पहले edit या cancel कर सकता है।
बदला:       Beneficiary सूची का redesign - search, nicknames, नई selection screen
बिना बदलाव: Login, card freeze, statement download (6.1 में code नहीं बदला)
6.1 में नहीं: International transfers (6.3 के लिए planned)
Platforms:  iOS और Android apps, Arabic और English
Build:      6.1.0-rc1 D3 पर staging में आएगा; go/no-go मीटिंग D12 पर
Staging:    Core banking sandbox दूसरी टीम के साथ shared है; पिछले महीने यह कई बार
            बंद रहा। Due transfers चलाने वाला scheduler रात में एक बार चलता है।
Team:       हुदा (QA, payment flows की जानकार; D6-D7 छुट्टी पर)
            फ़ैसल (QA, automation, test devices की देखरेख)
Automation: Nightly regression suite login, card freeze और statements कवर करता है

DRAFT TEST PLAN TP-061 v0.1
Scope:      ऐप टेस्ट करना।
Features:   Scheduled transfers, beneficiary सूची, login, card freeze, statements,
            Arabic और English।
Approach:   सभी फ़ीचर की manual testing। समय मिले तो automation।
Entry:      Build तैयार है।
Exit:       टेस्टिंग पूरी, ऐप स्थिर और coverage पर्याप्त।
Schedule:   D1-D12 टेस्टिंग, go/no-go D12 पर।
Risks:      पैसा दो बार जाना; transfer ग़लत दिन चलना; sandbox बंद; हुदा छुट्टी पर;
            Arabic amounts ग़लत दिखना।
Team:       हुदा, फ़ैसल।
Approval:   QA lead।
चरण
  1. Brief और draft पढ़ें। हर वह वाक्य चिह्नित करें जिसका जवाब दो लोग अलग-अलग दे सकते हैं, और गाइड की सामग्री-सूची का हर वह सेक्शन जो draft में नहीं है।
  2. Scope दोबारा लिखें: टेस्ट होने वाला हर फ़ीचर ID, risk level और टेस्टिंग की गहराई के साथ; टेस्ट न होने वाला हर फ़ीचर कारण के साथ।
  3. Entry, exit, suspension और resumption मानदंड ऐसे लिखें कि हर एक का जवाब हाँ या ना में मिले।
  4. Schedule को D12 के go/no-go से उल्टा बनाएँ: build आने से पहले test design, एक fix-and-retest चक्र, आख़िरी regression run, और टेस्टर की छुट्टी का ध्यान।
  5. जोखिमों की सूची को product risks और project risks में बाँटें, और हर project risk को mitigation और owner दें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Draft की समस्याएँ (इनमें से छह या ज़्यादा ढूँढना पहले हिस्से के लिए काफ़ी है): (1) Scope में न test items हैं न सीमाएँ — न app version, न platforms, न यह कि क्या बाहर है। (2) फ़ीचर सूची नए, बदले हुए और बिना बदलाव वाले फ़ीचर बिना risk level या गहराई के मिलाती है, और "टेस्ट न होने वाले फ़ीचर" सेक्शन नहीं है, इसलिए किसी को नहीं दिखता कि login, card freeze और statements सिर्फ़ regression suite से कवर होंगे। (3) "सभी फ़ीचर की manual testing" और "समय मिले तो automation" कोई approach नहीं है: न test levels, न techniques, न regression scope, न automation का फ़ैसला। (4) Entry मानदंड ("build तैयार है") और exit मानदंड ("पूरी", "स्थिर", "पर्याप्त") मापे नहीं जा सकते; दो लोग इनका जवाब अलग-अलग देंगे।

(5) Suspension या resumption मानदंड नहीं हैं, जबकि sandbox का बंद होना पहले से पता है। (6) Schedule D1 से टेस्टिंग शुरू करता है जबकि build D3 पर आता है; इसमें test design का समय, fix-and-retest चक्र, आख़िरी regression run और go/no-go से पहले buffer नहीं है, और यह हुदा की छुट्टी को अनदेखा करता है। (7) जोखिम सूची product risks (पैसा दो बार जाना, ग़लत दिन, Arabic amounts) को project risks (sandbox, छुट्टी) के साथ मिलाती है और न likelihood, न impact, न mitigation, न owner देती है। (8) Team लाइन में न भूमिकाएँ हैं न backup, और approval सिर्फ़ QA lead का है: product owner और development lead को भी plan approve करना चाहिए, और रिलीज़ का फ़ैसला एक अलग approval है। (9) Environments, test data, test objectives, deliverables और nightly scheduler पर निर्भरता ग़ायब हैं।

टेस्ट होने वाले फ़ीचर (आपके ID और शब्द अलग हो सकते हैं): STR-01 एक बार का scheduled transfer — High — अनुमत तारीख़ों की boundary values, due date पर ठीक एक बार execute होना, execution से पहले edit और cancel करना, और negative cases जैसे उस दिन balance कम होना या execution से पहले beneficiary delete होना। STR-02 मासिक scheduled transfer — High — चुने गए दिन 28 से 31, leap और non-leap साल की फ़रवरी में और 30 दिन वाले महीनों में (महीने के आख़िरी दिन वाला नियम), हर महीने ठीक एक debit, series को edit और cancel करना, साथ में API level पर automated checks कि scheduler दोबारा चलने पर वही transfer दो बार debit नहीं होता। BEN-01 beneficiary सूची — High — पैसा उसी beneficiary को जाए जो चुना गया और confirmation screen पर दिखा, Arabic और Latin नामों से search, मिलते-जुलते या एक जैसे nicknames। LOC-01 नई screens पर Arabic और English — Medium — दोनों भाषाओं में amounts, तारीख़ें और right-to-left layout, iOS और Android पर। हर फ़ीचर के लिए एक exploratory session भी जोड़ें।

टेस्ट न होने वाले फ़ीचर: login, card freeze और statement download — 6.1 में code नहीं बदला, सिर्फ़ nightly regression suite से कवर (smoke टेस्ट फिर भी login करता है); international transfers — 6.1 में नहीं, 6.3 के लिए planned; ख़ुद core banking system — एक अलग system जिसे app shared sandbox के ज़रिए call करता है, इस plan का test item नहीं (उसके owners से पक्का करें कि उसे कौन टेस्ट करता है), जबकि app की उसे भेजी calls और उसके responses की handling scope में हैं।

Cycle 1 के entry मानदंड: 6.1.0-rc1 staging पर deploy और iOS व Android test devices पर install; smoke टेस्ट pass (login, accounts देखना, अपने accounts के बीच एक तुरंत transfer); STR-01, STR-02 और BEN-01 के acceptance criteria review हो चुके; synthetic customers, accounts और beneficiaries लोड; core banking sandbox उपलब्ध; staging में scheduler को ज़रूरत पर चलाया जा सके।

Exit मानदंड: सभी High-risk टेस्ट execute होकर pass, या हर fail टेस्ट के लिए product owner की लिखित छूट; सभी नियोजित टेस्ट में से कम से कम 95% execute; कोई open Blocker या Critical डिफ़ेक्ट नहीं; ज़्यादा से ज़्यादा 2 open Major डिफ़ेक्ट, हर एक product owner द्वारा target fix version के साथ स्वीकार; final release candidate पर nightly regression suite हरा; 6.1 का हर acceptance criterion कम से कम एक execute हुए टेस्ट से जुड़ा। Suspension मानदंड: नए build पर smoke टेस्ट fail; sandbox 4 working hours से ज़्यादा उपलब्ध नहीं; या एक ही डिफ़ेक्ट 30% से ज़्यादा नियोजित टेस्ट block करे (जैसे कोई भी scheduled transfer save न हो)। Resumption मानदंड: नया build smoke टेस्ट पास करे; sandbox बहाल हो और एक test transfer पूरा हो; या blocking डिफ़ेक्ट ठीक हो और उसका confirmation test pass हो।

Go/no-go से उल्टा बना schedule: D1–D2 test design, data setup और acceptance criteria का review (build की ज़रूरत नहीं); D3 rc1 पर entry check — cycle 1 तब शुरू होगा जब entry मानदंड पूरे हों, लक्ष्य D3; D3–D5 हुदा scheduled-transfer टेस्ट चलाती हैं, पहले High risk; D3 पर फ़ैसल उनके साथ pair करते हैं और D4–D5 में beneficiary सूची के टेस्ट चलाते हैं; D6–D7 हुदा की छुट्टी में फ़ैसल दोनों platforms पर Arabic व English checks चलाते हैं और scheduler checks automate करते हैं; D8–D9 अगले candidate पर fix verification (confirmation testing) और प्रभावित टेस्ट दोबारा; D10 final candidate पर पूरा regression; D11 देर से आए fix और test completion report के लिए buffer; D12 exit मानदंडों के आधार पर go/no-go।

Product risks risk analysis में जाते हैं, जहाँ वे ऊपर वाली गहराई तय करते हैं: scheduled transfer का दो बार execute होना (High), transfer का ग़लत दिन execute होना (High), redesign के बाद पैसा ग़लत beneficiary को जाना (High), Arabic में amounts या तारीख़ें ग़लत दिखना (Medium)। Project risks, हर एक mitigation और owner के साथ: shared sandbox बंद हो — दूसरी टीम से तय test windows पर सहमति और negative paths के लिए core banking के mocked responses, owner QA lead; payments की अकेली जानकार हुदा D6–D7 में छुट्टी पर — उनके टेस्ट छुट्टी से पहले schedule, फ़ैसल के साथ pairing, और test cases इतने विस्तार से कि दूसरे चला सकें, owner QA lead; scheduler सिर्फ़ रात को चलता है — developers D3 से पहले on-demand trigger जोड़ें, owner development lead।

यह भी जोड़ें: test items (6.1.0-rc builds और टेस्ट होने वाले iOS व Android versions), test objectives (scheduled transfers ठीक एक बार, सही तारीख़ पर, चुने गए beneficiary को execute हों; नए flows में कोई Blocker या Critical डिफ़ेक्ट नहीं), approach (दोनों platforms पर नए और बदले फ़ीचर की system testing और core banking sandbox के साथ system integration testing, ऊपर बताई techniques से; API level पर automated scheduler checks; regression = nightly suite और D10 का पूरा run), environments और test data (staging, sandbox, devices, सिर्फ़ synthetic customers जो हर cycle से पहले reset हों), dependencies (development टीम D3 से पहले scheduler का on-demand trigger और D8 तक अगला release candidate दे), deliverables (test cases, automated scheduler checks, रोज़ की status report, defect reports, test completion report), और product owner व development lead का approval, जबकि go/no-go एक अलग फ़ैसला रहे। Plan का version 0.2 करें और दर्ज करें कि क्या बदला।

टीम के लिए सवाल, क्योंकि brief इन पर चुप है: क्या staging में scheduler को ज़रूरत पर चलाया जा सकता है या system date आगे की जा सकती है? Execution के दिन balance कम हो तो क्या होना चाहिए, और क्या customer को सूचना मिलती है? एक बार वाले transfer के लिए कौन-सी भविष्य की तारीख़ें अनुमत हैं? क्या एक जैसे nicknames की अनुमति है?

अपना काम जाँचें: 95%, 4 घंटे या 2 Major डिफ़ेक्ट जैसी सीमाएँ टीम के फ़ैसले हैं और आपकी अलग हो सकती हैं। ज़रूरी यह है कि हर मानदंड दो पढ़ने वालों को एक ही हाँ/ना दे, हर बाहर रखे फ़ीचर का कारण हो, हर project risk का owner हो, और schedule में execution D3 से पहले शुरू न हो, उसमें fix-and-retest चक्र और regression run हो, और वह go/no-go से पहले ख़त्म हो।

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा

टूल्स

इस गाइड में बताए गए टूल्स

टेस्ट प्लान जनरेटर

टेम्पलेट से टेस्ट प्लान बनाएँ: वेबसाइट, मोबाइल ऐप, API, agile sprint या रिलीज़ चुनें, जो पता है वह भरें और edit करने लायक पूरा Markdown प्लान पाएँ।

टेस्ट डिज़ाइन नया

रिस्क-बेस्ड टेस्ट जनरेटर

फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।

टेस्ट डिज़ाइन

AI रिस्क-बेस्ड टेस्ट जनरेटर

Mutqan AI से किसी फ़ीचर या रिलीज़ के जोखिम पहचानें और प्राथमिकता-क्रम में risk-based टेस्ट प्लान बनाएँ।

टेस्ट जनरेशन AI

Requirements → टेस्ट केस

क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।

टेस्ट डिज़ाइन

AI QA चेकलिस्ट जनरेटर

Mutqan AI से किसी भी फ़ीचर के लिए अनुकूलित QA चेकलिस्ट (functional, UI, API, security, performance, accessibility, release) बनाएँ।

टेस्ट जनरेशन AI

रिग्रेशन सिनेरियो जनरेटर

बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।

टेस्ट डिज़ाइन

AI टेस्ट कवरेज एनालाइज़र

Mutqan AI से requirements या किसी user story की तुलना मौजूदा टेस्ट केस से करके अनटेस्टेड हिस्से खोजें।

टेस्ट ऑप्टिमाइज़ेशन AI
Mutqan Soft

Mutqan Soft कैसे मदद कर सकता है

Mutqan Soft की एक सेवाक्वालिटी सिस्टम निर्माणलिखित, काम करने वाली टेस्ट कार्यप्रणाली: एंट्री और एग्ज़िट मानदंड, रिलीज़ गेट और मापने योग्य गुणवत्ता संकेतक।
गाइड

और गाइड

और गाइड
टेस्ट डिज़ाइन

टेस्ट स्ट्रैटेजी: एक व्यावहारिक गाइड

टेस्ट स्ट्रैटेजी क्या है, यह test plan से कैसे अलग है, इसमें क्या होता है, मुख्य टेस्ट दृष्टिकोण, उन्हें कैसे चुनें, और एक उदाहरण आउटलाइन।

12 मिनट पढ़ने का समय टेस्ट डिज़ाइन

टेस्ट एस्टिमेशन तकनीकें

Testing effort का अनुमान कैसे लगाएँ: estimate क्यों फ़ेल होते हैं, असर डालने वाले कारक, ratio, extrapolation, Delphi, three-point और WBS, एक उदाहरण के साथ।

11 मिनट पढ़ने का समय टेस्ट डिज़ाइन

सॉफ़्टवेयर टेस्टिंग लाइफ़ साइकल (STLC)

STLC चरण-दर-चरण — analysis, planning, design, environment, execution और closure — ISTQB test process से मैप, हर चरण के entry और exit criteria के साथ।

15 मिनट पढ़ने का समय टेस्ट डिज़ाइन

एंड-टू-एंड प्रोडक्ट क्वालिटी एश्योरेंस

एंड-टू-एंड QA में क्या आता है — आवश्यकता समीक्षा, टेस्ट डिज़ाइन, फ़ंक्शनल, API, परफ़ॉर्मेंस और सुरक्षा टेस्टिंग, रिलीज़ गेट और मेट्रिक्स — और इसे कैसे चलाएँ।

11 मिनट पढ़ने का समय टेस्ट डिज़ाइन

रिस्क-आधारित टेस्टिंग

रिस्क-आधारित टेस्टिंग कैसे करें: product risk पहचानें, likelihood और impact स्कोर करें, टेस्ट की गहराई तय करें, regression चुनें और residual risk बताएँ।

13 मिनट पढ़ने का समय टेस्ट डिज़ाइन

इन-हाउस QA टीम बनाम आउटसोर्स्ड QA

इन-हाउस, आउटसोर्स्ड, ऑगमेंटेड और हाइब्रिड QA की लागत, रैंप-अप, उत्पाद ज्ञान, नियंत्रण, डेटा सुरक्षा और ज्ञान-संरक्षण पर तुलना, चेकलिस्ट के साथ।

7 मिनट पढ़ने का समय