मॉड्यूल 26 · AI और LLM टेस्टिंग

AI की मदद से QA

Mutqan Soft QA टीम द्वारा · · 19 मिनट · उन्नत

AI-assisted QA का मतलब है किसी AI model, आम तौर पर large language model (LLM), को अपने testing काम में सहायक की तरह इस्तेमाल करना: user story से test cases का draft बनाना, edge cases सुझाना, अस्पष्ट requirement पर सवालों की list बनाना या bug report को structure देना। Product under test में AI होना ज़रूरी नहीं। यह इस module के बाकी हिस्से से उल्टी दिशा है, जहाँ AI system test object था।

उदाहरण: एक AI test case generator discount codes वाली user story को कुछ ही seconds में छह साफ़-सुथरे test cases में बदल देता है। उनमें से एक ऐसा error message expect करता है जिसका requirement में कहीं ज़िक्र नहीं, एक इतना vague है कि execute ही नहीं हो सकता, और "हर customer एक बार" वाले rule का कोई test ही नहीं है। क्या रखना है, product owner से क्या पूछना है और क्या जोड़ना है, यह आपका review तय करता है।

यह क्यों ज़रूरी है

Language model fluent और भरोसेमंद लगने वाला text बनाता है। उसने आपका product नहीं देखा, वह आपके users या risks नहीं जानता, और गढ़ी हुई detail को भी उतने ही भरोसे से बता सकता है जितना सही detail को: यही hallucination है जिसे आपने इसी module में test किया, और जिसे NIST Generative AI Profile (NIST AI 600-1) confabulation कहता है। गढ़े हुए expected result वाला test case न होने से भी बुरा है: वह गलत behaviour पर pass और सही behaviour पर fail हो सकता है।

दूसरा risk भी है: online AI tool में आप जो कुछ भी paste करते हैं, वह आपकी machine से बाहर जाता है, चाहे bug note में customer का phone number हो या request log में access token। Review और साफ़ input के साथ AI drafting का असली समय बचाता है; इनके बिना वह defects और data leaks जोड़ देता है।

Drafts का सहायक, judgement का विकल्प नहीं

AI tool को एक तेज़, बहुत पढ़े-लिखे साथी की तरह समझें जिसने आपका product कभी इस्तेमाल नहीं किया और जिसे किसी बात के लिए ज़िम्मेदार नहीं ठहराया जा सकता। वह test oracle नहीं है: expected results test basis (requirements, acceptance criteria, designs) से या product owner से आते हैं, model के अंदाज़े से कभी नहीं। Generative AI के साथ testing पर ISTQB का syllabus (CT-GenAI) AI के इस इस्तेमाल को एक अलग विषय मानता है, और fundamentals वही रहते हैं: risk के आधार पर क्या test करना है यह आप चुनते हैं, test design techniques लगाते हैं, असली product को observe करते हैं और result की ज़िम्मेदारी लेते हैं।

  • अच्छे इस्तेमाल: test ideas और edge cases, साफ़ story से test cases के पहले drafts, requirements review के लिए ambiguity वाले सवाल, अपने ही notes से bug report को structure देना, अनजान error message समझना।
  • कमज़ोर इस्तेमाल: scope या priority तय करना, ऐसे expected results लिखना जो test basis में नहीं हैं, business impact जाने बिना severity तय करना, असली product के exploration की जगह लेना।
  • स्वीकार्य नहीं: ऐसा defect report करना जिसे आपने ख़ुद reproduce नहीं किया, या release की सिफ़ारिश सिर्फ़ इसलिए करना कि AI summary के मुताबिक़ results ठीक दिखते हैं।

Privacy: paste करने से पहले तय करें कि क्या paste करना है

ज़्यादातर AI tools एक online service के रूप में चलते हैं: जवाब बनाने के लिए आपका input provider को भेजा जाता है। कुछ भी paste करने से पहले अपनी organisation की policy देखें कि कौन-से AI tools approved हैं और उनमें कौन-सा data डाला जा सकता है। Test artefact में मौजूद personal data भी personal data ही है; उदाहरण के लिए Saudi Arabia में उसकी processing Personal Data Protection Law (PDPL) के दायरे में आती है। Model को problem की structure चाहिए, असली values नहीं, इसलिए पहले input साफ़ करें।

  • Personal data (नाम, phone numbers, e-mail addresses, national IDs, card numbers): इसकी जगह test data generator से synthetic values लें।
  • Secrets (passwords, API keys, access tokens, session cookies, Authorization headers): इनकी जगह <redacted> लिखें।
  • Internal details (hostnames, IP addresses, customers के नाम, unreleased features): जब तक policy अनुमति न दे, इन्हें शामिल न करें।
  • गलती से paste हुए असली secret की ख़बर उसके owner को देनी चाहिए और उसे revoke करवाना चाहिए; message delete करना काफ़ी नहीं।
साफ़ करने से पहले: इसे paste न करें
POST https://orders.int.example-shop.local/v2/checkout
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0NDIxIn0.Xk2...
{"customer": "Sara Al-Harbi", "phone": "+966 55 012 3456", "code": "SAVE20"}
-> 500 Internal Server Error

साफ़ करने के बाद: AI की मदद के लिए इतना काफ़ी है
POST /v2/checkout
Authorization: Bearer <redacted>
{"customer": "Test User 01", "phone": "+966 50 000 0001", "code": "SAVE20"}
-> 500 Internal Server Error

आज़माएँ: टेस्ट डेटा फ़ैक्टरी

हर draft को इस्तेमाल से पहले verify करें

AI output को किसी भी ऐसे work product की तरह मानें जिसका review नहीं हुआ। Fluent wording सही होने का सबूत नहीं है, और वही request अगली बार अलग draft दे सकती है, इसलिए उसी version का review करें जिसे आप सच में इस्तेमाल करेंगे, और एक तय क्रम में।

  • Trace: हर item को test basis से जोड़ें। जो item trace न हो, वह या तो requirement का gap है (product owner के लिए सवाल) या गढ़ी हुई बात (उसे हटा दें)।
  • Facts जाँचें: limits, error messages, status codes, field names और standards को requirement, API contract या product से मिलाएँ।
  • Executable है या नहीं: concrete data और observable expected result चाहिए। "जाँचें कि feature सही काम करता है" कोई test नहीं है।
  • छूटा हुआ खोजें: अपनी techniques लगाएँ (partitions, हर boundary के दोनों तरफ़, decision rules, risks) और एक ही partition के duplicates हटाएँ।
  • Generated code: उसे चलाएँ, देखें कि हर check तब fail होता है जब उसे होना चाहिए, और हर selector व assertion पढ़ें। उसी tool से पूछना कि उसका output सही है या नहीं, verification नहीं है।
  • Record: artefact को AI-assisted mark करें और reviewer का नाम लिखें।
QA में AI का इस्तेमाल पाँच steps में: बिना personal data या secrets वाला input तैयार करें, AI से draft बनाएँ, हर item trace और check करें, draft में छूटा हुआ जोड़ें, फिर नामित reviewer के साथ इस्तेमाल करें। वैचारिक मॉडल
  1. 1Input तैयार करेंTest basis, limits और roles; personal data, secrets या internal names नहीं

    गेट: सिर्फ़ वही जो policy allow करे

  2. 2AI से draft बनाएँTest ideas, test cases, review questions या bug wording: draft, result नहींAI tool
  3. 3Trace करें, facts जाँचेंहर item test basis से; limits और messages requirement या product से

    शाखा: गढ़ा हुआ या बिना आधार: सुधारें, product owner से पूछें या हटाएँ

  4. 4छूटा हुआ जोड़ेंआपके अपने partitions, boundaries, rules और risks
  5. 5नामित reviewer के साथ इस्तेमाल करेंSuite, bug report या review में, AI-assisted mark करके

चरण 3–4 के दौरान Tester का review

इस lesson से एक illustrative workflow; कोई standard ठीक यही steps तय नहीं करता।

Worked example: discount code के AI draft का review

Checkout story के acceptance criteria: (1) SAVE20 200.00 SAR या उससे ज़्यादा के orders पर 20% छूट देता है; (2) हर customer एक code एक ही बार इस्तेमाल कर सकता है; (3) expired code "इस code की validity ख़त्म हो चुकी है" message के साथ reject होता है। SAVE20 Riyadh time के अनुसार 31 दिसंबर 2026 को 23:59 तक valid है। एक AI tool ने नीचे वाला draft दिया; इसका item by item review करें।

  • TC-01: रखें; यह criterion 1 से trace होता है, और 250.00 में से 20% घटाने पर 200.00 बचता है।
  • TC-02: input रखें और expected result "कोई discount नहीं" रखें, लेकिन message गढ़ा हुआ है: criterion 1 नहीं बताता कि 200.00 SAR से कम पर code reject होता है या नहीं, और customer को क्या दिखता है। Product owner से पूछें।
  • TC-03: concrete data के साथ रखें: Riyadh time के अनुसार 1 जनवरी 2027 को 00:00 बजे SAVE20, ऐसे test environment में जिसकी clock आप set कर सकें।
  • TC-04: draft ने मान लिया कि codes case-sensitive नहीं हैं; requirement इस पर चुप है, इसलिए यह सवाल है।
  • TC-05 और TC-06: हटा दें। TC-05 में न data है न expected result; TC-06 उसी partition में है जिसमें TC-01 है।
  • जोड़ें: 199.99 SAR (कोई discount नहीं), 200.00 SAR (total 160.00), उसी customer का दूसरा इस्तेमाल (reject), दूसरे customer का पहला इस्तेमाल (accept) और 31 दिसंबर को 23:59 बजे SAVE20 (accept)। Draft criterion 2 को पूरी तरह भूल गया था।
  • Result: दो रखे, दो सवाल, दो हटाए, पाँच जोड़े। AI ने typing बचाई; rules की coverage review से आई।
TC-01  250.00 SAR के order पर SAVE20 लगाएँ
       Expected: total 200.00 SAR
TC-02  150.00 SAR के order पर SAVE20 लगाएँ
       Expected: message "Minimum order 200 SAR है"
TC-03  Expired code लगाएँ
       Expected: message "इस code की validity ख़त्म हो चुकी है"
TC-04  "save20" lower case में लगाएँ
       Expected: code accept होता है
TC-05  SAVE20 लगाएँ और जाँचें कि discount सही काम करता है
TC-06  300.00 SAR के order पर SAVE20 लगाएँ
       Expected: 20% discount लगता है

आज़माएँ: बाउंड्री वैल्यू एनालिसिस

Mutqan AI tools का ज़िम्मेदारी से इस्तेमाल

Mutqan के AI QA tools test generation, requirement analysis, bug analysis और test optimisation को cover करते हैं: जैसे user story से test cases, ambiguity detection, bug descriptions और severity के सुझाव। इनके लिए free account चाहिए और ये daily allowance में गिने जाते हैं। इनके privacy note के अनुसार आपका input Mutqan AI service को भेजा जाता है और prompts व results store नहीं होते; फिर भी input आपके device से बाहर जाता है, इसलिए paste करने के नियम पूरी तरह लागू होते हैं।

  • जहाँ technique के rules तय हों, वहाँ boundary value analysis जैसा बिना AI वाला Mutqan tool चुनें: वह आपके browser में चलता है और sign-in नहीं माँगता।
  • पहले ख़ुद analysis करें, फिर AI tool को second opinion की तरह इस्तेमाल करें और दोनों की तुलना करें।
  • Precise input दें: story, उसके acceptance criteria, field limits और user roles।
  • सुझाई गई severity या priority को triage का input मानें, decision नहीं।

आज़माएँ: AI टेस्ट केस जनरेटर आज़माएँ: AI Requirement अस्पष्टता डिटेक्टर आज़माएँ: AI बग विवरण जनरेटर आज़माएँ: User Story → टेस्ट केस

आम गलतियाँ

  • AI से बने test cases को, हर एक को test basis से trace किए बिना, suite में copy कर देना।
  • AI के लिखे expected results, error messages या limits को facts मान लेना।
  • असली customer data, credentials या confidential code AI tool में paste करना, या ऐसा tool इस्तेमाल करना जिसे आपकी organisation ने approve नहीं किया।
  • AI की suggested severity या priority को ही decision मान लेना।
  • Draft को पूरा मान लेना, बजाय अपनी techniques लगाकर उसमें छूटी चीज़ें ढूँढने के।
  • उसी tool से उसके output की जाँच करवाना और उसकी सहमति को verification मान लेना।

QA का नज़रिया

असली team में पहले ground rules तय करें: कौन-से AI tools approved हैं, उनमें कौन-सा data जा सकता है और AI-assisted काम को कैसे mark किया जाएगा। अगर किसी ने अभी तय नहीं किया, तो अपने lead से बात करें। फिर AI वहाँ इस्तेमाल करें जहाँ उसका फ़ायदा हो: refinement में ambiguity वाले सवाल, test cases के पहले drafts, exploratory session से पहले edge-case ideas, और failure reproduce करने के बाद bug report की wording।

जो tester AI draft अपनाता है, वह उसका उतना ही ज़िम्मेदार है जितना अपने लिखे काम का। Test case या ticket में record करें कि वह AI-assisted है, किस tool से बना और review किसने किया, और उससे उठी कोई नई बात product owner के पास finding नहीं, सवाल के रूप में ले जाएँ। NIST Generative AI Profile generative AI पर ज़रूरत से ज़्यादा निर्भरता (over-reliance) को अपने risks में गिनता है (human-AI configuration के अंतर्गत), इसलिए techniques की practice करते रहें: अगर आप tool के बिना tests design नहीं कर सकते, तो उसके output को judge भी नहीं कर सकते।

अभ्यास

AI draft का review करें और bug note साफ़ करें

आपका काम

एक साथी ने ticket booking के एक rule के लिए AI tool से test cases का draft बनाया है, और report में मदद के लिए production bug note को AI tool में paste करना चाहता है। Material नीचे है; customer data काल्पनिक है, लेकिन उसे असली मानकर चलें।

इस lesson में बताए तरीके से draft का review करें, फिर तय करें कि bug note को कहीं भी paste करने से पहले उसमें क्या बदलना ज़रूरी है।

सामग्री
Requirement: एक customer एक order में 1 से 6 tickets book कर सकता है।
Event शुरू होने से 2 घंटे पहले booking बंद हो जाती है।

AI draft:
TC-1  3 tickets book करें
      Expected: booking confirm होती है
TC-2  0 tickets book करें
      Expected: message "कम से कम 1 ticket चुनें"
TC-3  7 tickets book करें
      Expected: message "एक order में अधिकतम 6 tickets"
TC-4  10 tickets book करें
      Expected: message "एक order में अधिकतम 6 tickets"
TC-5  Event शुरू होने से 1 घंटा पहले book करें
      Expected: booking reject होती है
TC-6  Tickets book करें और जाँचें कि सब कुछ काम करता है

Bug note:
Customer: Noura Al-Qahtani, noura.q@example.com, +966 55 987 6543
POST https://booking.int.tickets.local/v2/orders
Cookie: session=7f3a9c2e41b84d0f
Response: 500 Internal Server Error, 14 अक्टूबर को 19:42 बजे
चरण
  1. Draft के हर case को requirement से trace करें और कारण के साथ उसे रखें, सुधारें, सवाल या हटाएँ में से एक mark करें।
  2. Equivalence partitioning और boundary value analysis से छूटे cases ढूँढें।
  3. Bug note में से जो paste नहीं होना चाहिए उसकी list बनाएँ और साफ़ किया हुआ version लिखें।
  4. लिखें कि AI की मदद के बारे में आप क्या record करेंगे।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

TC-1 (typical valid value) और TC-5 (concrete times के साथ) रखें। TC-2 और TC-3: inputs रखें, क्योंकि ये boundaries के invalid पड़ोसी हैं, लेकिन messages गढ़े हुए हैं; expected result "reject" रखें और wording के लिए product owner से पूछें। TC-4 (TC-3 वाला ही partition) और TC-6 (न data, न expected result) हटा दें।

छूटा हुआ: 1 और 6 tickets (accept), यानी valid boundary values जिन्हें draft ने कभी test नहीं किया। Booking window के लिए, एक मिनट के step से: start से 2 घंटे 1 मिनट पहले (accept), ठीक 2 घंटे पहले (product owner के लिए खुला सवाल) और 1 घंटा 59 मिनट पहले (reject)। यह भी पूछें कि start time किस time zone से तय होता है।

Bug note: नाम, e-mail address और phone number (personal data), session cookie (credential; उस session को invalidate करवाने को कहें) और internal hostname हटाएँ, और method, path, status व time रखें। साफ़ किया हुआ note: "एक customer को tickets book करते समय 14 अक्टूबर को 19:42 बजे 500 Internal Server Error मिला; POST /v2/orders; session cookie redacted।" इसे सिर्फ़ ऐसे tool में paste करें जिसे आपकी organisation approve करती है; इससे भी बेहतर: पहले test account से failure reproduce करें।

Record: final cases को AI-assisted mark करें, tool का नाम और reviewer के रूप में अपना नाम लिखें, और खुले सवालों को cases से link करें।

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

क्या AI testers की जगह ले लेगा?

ये tools कुछ कामों का तरीका बदलते हैं, ज़्यादातर drafting और summarising का। वे आपका product, users या risks नहीं जानते, असली system पर failure reproduce नहीं कर सकते और release decision के लिए ज़िम्मेदार नहीं ठहराए जा सकते। जो काम बचता है (क्या मायने रखता है यह तय करना, output को judge करना और result की ज़िम्मेदारी लेना), वही testing का मूल है।

क्या stack trace या log को AI tool में paste करना सुरक्षित है?

सिर्फ़ ऐसे tool में जिसे आपकी organisation approve करती है, और सिर्फ़ personal data, tokens, cookies, internal hostnames और वह सब हटाने के बाद जिसे आपकी policy confidential मानती है। Stack traces और logs में अक्सर user IDs, file paths और query parameters होते हैं, इसलिए paste करने से पहले पूरा text पढ़ें।

जब AI tool मौजूद है, तो बिना AI वाला test design tool क्यों इस्तेमाल करें?

बिना AI वाला tool, जैसे boundary value analysis tool, एक तय technique लगाता है, बिना sign-in के आपके browser में चलता है और किसी server को कुछ नहीं भेजता। जहाँ technique के rules तय हों, वहाँ इसे इस्तेमाल करें। जहाँ खुली मदद काम आए, जैसे ambiguities ढूँढना या edge cases पर brainstorming, वहाँ AI tool इस्तेमाल करें और जो वह लौटाए उसका review करें।

क्या मुझे बताना चाहिए कि test case या bug report AI की मदद से लिखा गया?

हाँ। इसे उसी तरह record करें जैसे आपकी team तय करे, reviewer के नाम के साथ। इससे अगला पढ़ने वाला जानता है कि artefact कैसे बना और किसने check किया, और team को दिखता है कि AI की मदद कहाँ समय बचाती है और कहाँ दोबारा काम करवाती है।

संदर्भ

  • Certified Tester Specialist Level – Testing with Generative AI (CT-GenAI)ISTQBपूरी टेस्ट प्रक्रिया में बड़े भाषा मॉडल के उपयोग पर ISTQB का पाठ्यक्रम — AI सिस्टम को टेस्ट करने की उलटी दिशा।
  • Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)NIST · 2024AI RMF का generative-AI प्रोफ़ाइल: generative मॉडल के विशेष जोखिम, जैसे confabulation और सूचना की अखंडता, और उन्हें संभालने के सुझाए क़दम।
  • Personal Data Protection Law (English translation)सऊदी डेटा एवं AI प्राधिकरण (SDAIA) · 2023व्यक्तिगत डेटा पर सऊदी कानून — टेस्ट वातावरण में असली ग्राहक रिकॉर्ड की प्रतियों के बजाय सिंथेटिक डेटा क्यों इस्तेमाल करना चाहिए।
  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
टूल्स

Mutqan tools से अभ्यास करें

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

Mutqan AI की मदद से किसी user story को पेशेवर, संरचित टेस्ट केस (ID, शीर्षक, प्रकार, प्राथमिकता, पूर्व-शर्तें, डेटा, स्टेप, अपेक्षित परिणाम) में बदलें।

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

AI Requirement अस्पष्टता डिटेक्टर

requirements में अस्पष्ट, धुँधले या परस्पर विरोधी कथन पकड़ें और Mutqan AI से स्पष्टीकरण के सवाल पाएँ।

आवश्यकता विश्लेषण AI

AI बग विवरण जनरेटर

मोटे-मोटे नोट्स को पूरी बग रिपोर्ट में बदलें: reproduce करने के स्टेप, अपेक्षित बनाम वास्तविक, environment, गंभीरता और attachments चेकलिस्ट।

बग विश्लेषण AI

User Story → टेस्ट केस

किसी user story (As a / I want / So that) को टेम्पलेट और heuristics की मदद से संरचित टेस्ट केस में बदलें।

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

टेस्ट डेटा फ़ैक्टरी

सिंथेटिक टेस्ट डेटा की एक ही जगह पर फ़ैक्टरी: users, customers, companies, पते, संख्याएँ, तारीख़ें और स्ट्रिंग — JSON, CSV, SQL या XML में।

टेस्ट डेटा

और गहराई से

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

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

अगले topics