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

AI टेस्टिंग फ़ंडामेंटल्स

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

AI testing उन systems की testing है जिनका कुछ behaviour किसी AI component से आता है, आम तौर पर एक machine learning (ML) model से। Rule-based software में developer logic खुद लिखता है, जैसे if the ticket contains "refund", route it to Billing। ML system में training algorithm यह logic examples से निकालता है: उसे हज़ारों पुराने tickets दिए जाते हैं जिन पर सही team का label लगा है, और वह ऐसे patterns सीखता है जो नए ticket की team predict करते हैं। नतीजा एक ऐसा model है जिसका behaviour उसके data पर निर्भर है और जो ज़्यादातर बार सही होता है, हर बार नहीं।

इससे expected results तय करने और test result को आँकने का तरीका बदलता है। Basics नहीं बदलते: AI feature अब भी requirements, interfaces, data और users वाले एक system का हिस्सा है, और test levels व non-functional testing के lessons में सीखी हर बात अब भी लागू होती है।

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

AI features code की एक भी गलत line के बिना fail हो सकते हैं। Model हर demo में pass होकर भी उस language में लिखे ज़्यादातर tickets गलत route कर सकता है जो उसके training data में कम थी, किसी अघोषित retraining के बाद अलग जवाब दे सकता है, या customers का behaviour बदलने के साथ धीरे-धीरे खराब हो सकता है। जो test suite सिर्फ़ code paths जाँचता है, वह इस पूरे दौरान green रहता है।

Tester के लिए risk दोनों तरफ़ है: ऐसे evidence पर release approve करना जो दिखने से कम साबित करता है, जैसे कुछ चुने हुए examples या unrepresentative data पर मापा गया score; या यह तय ही न कर पाना कि कोई गलत जवाब defect है या नहीं। क्या अलग है, यह जानकर आप ऐसा evidence जुटा पाते हैं जिस पर team भरोसा करे, और ऐसी defect reports लिख पाते हैं जिन पर data scientist काम कर सके।

Rule-based software और ML systems

Rule-based software में हर behaviour किसी requirement और ऐसे code तक जाता है जिसे किसी इंसान ने लिखा है और जिसे पढ़ा जा सकता है। किसी भी input का expected result आप specification से निकाल सकते हैं, और test fail हो तो defect code, configuration या requirement में होता है।

ML system में model का behaviour सीखा हुआ होता है। Developers training pipeline और model के आसपास का code लिखते हैं, लेकिन कोई वह rule नहीं लिखता जो किसी खास ticket को Billing भेजता है: वह training data के patterns से आता है, जो numeric parameters में store होते हैं और rules की तरह पढ़े नहीं जा सकते। यही data-dependent behaviour है: वही code अलग data पर train हो तो अलग system बन जाता है।

  • Keyword rules: "I was charged twice" वाला ticket Other में जाता है, क्योंकि उसमें "refund" नहीं है, जबकि यह billing की शिकायत है। Defect एक missing rule है, और fix एक नया rule।
  • ML model: वही ticket शायद Billing में जाएगा, क्योंकि training data में ऐसे ही tickets पर Billing का label था। लेकिन किसी नई तरह की शिकायत, जिसके मिलते-जुलते examples नहीं हैं, अब भी गलत route हो सकती है, और उसका fix बेहतर data है, code की नई line नहीं।
  • कई products दोनों को जोड़ते हैं: model सुझाव देता है, और rules तय करते हैं कि आगे क्या होगा, जैसे low-confidence results किसी इंसान को भेजना।

Probabilistic और non-deterministic behaviour

Rule-based code आम तौर पर deterministic होता है: एक ही state में एक ही input हमेशा एक ही output देता है। ML systems दो तरह की अनिश्चितता जोड़ते हैं। वे probabilistic हैं: classifier एक score लौटाता है और inputs के एक हिस्से पर ही सही होता है, इसलिए एक गलत जवाब तब तक expected behaviour हो सकता है जब तक error rate तय limit के अंदर है। वे non-deterministic भी हो सकते हैं: एक ही input अलग-अलग outputs दे सकता है।

Tests के लिए इसका मतलब है: हर result के साथ model version, data version और settings record करें; जब output बदल सकता हो तो case कई बार चलाएँ और pass rate से आँकें; और model को fixed scores लौटाने वाले stub से बदलकर उसके आसपास का code deterministic तरीके से टेस्ट करें। एक ही input के दो outputs में मतलब का फ़र्क है या सिर्फ़ शब्दों का, यह देखने के लिए उन्हें साथ-साथ compare करें, जैसे Text Diff से। Fixed model version एक ही input के लिए आम तौर पर वही scores निकालता है, इसलिए variation इन स्रोतों से आता है:

  • Sampling: LLMs जैसे generative models हर अगला token (शब्द या शब्द का हिस्सा) probability distribution से चुनते हैं, और temperature जैसी settings तय करती हैं कि output कितना बदलेगा।
  • Retraining: training में आम तौर पर random choices होती हैं, जैसे शुरुआती values और data का क्रम, इसलिए उसी data पर दोबारा train हुआ model कुछ inputs का अलग जवाब दे सकता है।
  • ऐसे बदलाव जो आपके नियंत्रण में नहीं: provider hosted model update कर देता है, या self-learning system नए data से सीखते हुए बदलता रहता है।
  • Hardware या library versions के बीच छोटे numeric फ़र्क, जो किसी score को threshold के एक तरफ़ से दूसरी तरफ़ ले जाने के लिए काफ़ी हैं।

आज़माएँ: टेक्स्ट डिफ़

Training data ही behaviour का स्रोत है

ML system में training data वही भूमिका निभाता है जो rule-based software में requirements और code निभाते हैं। उसमें मौजूद हर pattern behaviour बन जाता है, उसकी कमियाँ, गलतियाँ और biases भी। अगर लगभग सारे training tickets English में लिखे थे, तो classifier Arabic tickets को कमज़ोर तरीके से handle करेगा, जबकि code में language का कहीं ज़िक्र नहीं। अगर data पर label लगाने वालों ने delivery की शिकायतें Billing में डाल दीं, तो model भी यही करेगा।

यही बात उस test data पर लागू होती है जिससे model evaluate होता है: score सिर्फ़ उसी population के बारे में बताता है जिसे वह data represent करता है। इसलिए test data को operating environment का representative होना चाहिए, यानी उन inputs और हालात का जो system को production में मिलेंगे: languages और dialects, channels, devices, regions, time periods और rare लेकिन अहम cases, असली अनुपात में। जिस test set का 95% हिस्सा English है, वह उस product के बारे में बहुत कम बताता है जिसके ज़्यादातर customers Arabic में लिखते हैं, score चाहे जितना ऊँचा हो। किसी भी evaluation पर भरोसा करने से पहले पूछें:

  • Data कहाँ और कब इकट्ठा हुआ, और क्या यह उस जगह और समय से मेल खाता है जहाँ system चलेगा?
  • उसमें कौन-से groups हैं, और production की तुलना में किस अनुपात में?
  • Labels किसने लगाए, किस लिखित guideline के अनुसार?
  • क्या test data को training data से अलग रखा गया? अगला lesson दिखाता है कि दोनों का overlap scores को कैसे बढ़ा-चढ़ा देता है।

Testing में क्या अलग है

ISO/IEC TR 29119-11 और ISTQB AI Testing (CT-AI) syllabus ऐसी विशेषताएँ बताते हैं जो AI-based systems को rule-based systems से टेस्ट करना मुश्किल बनाती हैं, और NIST AI Risk Management Framework AI risks और traditional software risks के बीच ऐसे ही फ़र्क गिनाता है। रोज़ के काम में छह चीज़ें बदलती हैं:

  • Expected result अक्सर पता नहीं होता। कई inputs के लिए कोई पहले से सटीक सही output नहीं लिख सकता: यह test oracle problem है। इसलिए testers दूसरे oracles इस्तेमाल करते हैं: किसी test set के लिए लोगों द्वारा तय labels, और partial oracles जो output का सिर्फ़ एक हिस्सा जाँचते हैं, जैसे स्वीकार्य जवाबों की ranges और ऐसे rules जिन्हें output कभी न तोड़े।
  • Acceptance criteria statistical होते हैं। "Representative test set पर कम से कम 90% tickets सही route हों, और हर language में कम से कम 85%" वाला criterion "यह ticket Billing में जाता है" की जगह लेता है। एक pass case बहुत कम साबित करता है, और एक fail case तय error rate के अंदर हो सकता है, जब तक वह ऐसा must-pass case न हो जो कभी fail नहीं होना चाहिए।
  • Defects data और model setup में भी हो सकते हैं: गलत labels, गायब groups, कोई input field जो जवाब पहले ही बता दे, या गलत चुना गया threshold। इन्हें किसी भी defect की तरह report करें, environment में model और dataset versions के साथ।
  • एक fix behaviour को कहीं भी खिसका सकता है। Inputs के एक group को ठीक करने के लिए retraining दूसरों के जवाब बदल सकती है, इसलिए हर नया model version पूरे test set पर चलता है और पिछले version से case-by-case compare होता है।
  • Release के बाद quality बदल सकती है। असली inputs training data से दूर drift करते हैं, इसलिए release के समय criteria पूरे करने वाला model अपने में कोई बदलाव हुए बिना भी खराब हो सकता है, और testing production में monitoring के रूप में जारी रहती है।
  • और quality characteristics मायने रखती हैं: bias, input के छोटे बदलावों के सामने robustness, transparency और explainability। इस module के आगे के lessons इन्हें कवर करते हैं।
Rule-based software लोगों का लिखा logic चलाता है; ML system data से सीखा logic चलाता है, इसलिए उसके expected results, pass criteria और defects को अलग तरह के tests चाहिए।

Rule-based software

Developer हर rule लिखता है, जैसे contains "refund" → Billing

Behaviour कहाँ से आता है:
Requirements से लिखे गए rules
एक ही input दो बार:
वही output, जब तक code time, state या randomness पर निर्भर न हो
Expected result:
Exact, specification से निकला
Pass criterion:
हर test case pass या fail होता है
Defects कहाँ होते हैं:
Code, configuration, requirements
Fix के बाद:
Confirmation testing, फिर regression testing
Release के बाद:
सिर्फ़ नए version से बदलता है

ML system

Model labelled examples से logic सीखता है

Behaviour कहाँ से आता है:
Training data से सीखे patterns: दूसरा data, दूसरा system
एक ही input दो बार:
Fixed version से वही scores; sampling, retraining या update से output बदल सकता है
Expected result:
अक्सर अज्ञात: लोगों द्वारा तय labels, साथ में ranges और rules जैसे partial oracles
Pass criterion:
Representative test set पर एक rate, साथ में must-pass cases
Defects कहाँ होते हैं:
Data, labels, threshold और training setup में भी
Fix के बाद:
Retraining कहीं भी जवाब बदल सकती है: पूरा test set दोबारा चलाएँ
Release के बाद:
असली data drift होने पर खराब हो सकता है: production में monitoring करें

Model के आसपास का code अब भी conventional software है और सामान्य techniques से टेस्ट होता है।

Worked example: ML ticket router को टेस्ट करना

एक support team अपने keyword rules की जगह ऐसा ML classifier लाती है जो हर ticket, Arabic या English में, पढ़कर एक category और 0 से 1 के बीच confidence लौटाता है। 0.70 से कम वाले tickets human triage queue में जाते हैं। Tester plan को दो हिस्सों में बाँटता है: conventional checks, जिनमें model की जगह stub है, और हाल के labelled tickets पर model checks।

Plan का ज़्यादातर हिस्सा सामान्य testing है। C1 threshold पर boundary value analysis है: scores दो decimal places तक हैं, इसलिए यह 0.70 के दोनों तरफ़ की values टेस्ट करता है। C2 से C4 negative, error-handling और edge-case tests हैं, और C5 हर decision को reproducible बनाता है। C4 के लिए mixed-language inputs किसी test data generator से आ सकते हैं; वे code path टेस्ट करते हैं, model की accuracy नहीं, क्योंकि synthetic text असली customers को represent नहीं करता। Test levels अब भी लागू हैं: model को component के रूप में evaluate किया जाता है, help desk से उसका जुड़ाव integration level पर, और पूरा flow system और acceptance level पर, साथ में non-functional testing के performance और security checks।

नया है M1 से M5: एक set पर criteria, हर language के results, एक must-pass group, यह check कि test data अब भी production जैसा है, और एक consistency check। M1 में दो limits हैं, क्योंकि जो model लगभग हर ticket human queue में भेज दे, वह सिर्फ़ accuracy की limit पार कर सकता है। Testing principles भी लागू हैं: ऊँचा score साबित नहीं करता कि router हर customer के लिए काम करता है, क्योंकि testing defects की मौजूदगी दिखाती है, उनकी गैरमौजूदगी नहीं; और free text की exhaustive testing असंभव है, इसीलिए representative test data इतना मायने रखता है।

Feature: route support tickets with an ML classifier (Arabic and English)
Output: category + confidence 0.00..1.00 (2 decimals); below 0.70 -> human triage queue

Conventional checks (model replaced by a stub that returns fixed results)
  C1  stub returns 0.69 -> human queue; stub returns 0.70 -> category queue
  C2  model service gives no answer within 3 s -> human queue, error logged
  C3  empty ticket -> validation error, model not called
  C4  ticket mixing Arabic and English -> routed or queued, never an error
  C5  every decision stores ticket id, model version and confidence

Model checks (labelled test set: 2,000 tickets from the last 3 months)
  M1  >= 90% of auto-routed tickets in the correct category; <= 25% to the human queue
  M2  >= 85% for Arabic tickets and for English tickets, measured separately
  M3  0 of 40 "account locked" tickets routed to Other (must-pass)
  M4  language mix of the test set within 5 points of production
  M5  identical results on two runs of the same model version

आज़माएँ: बाउंड्री वैल्यू जनरेटर आज़माएँ: बहुभाषी टेस्ट डेटा जनरेटर

आम गलतियाँ

  • सिर्फ़ model टेस्ट करना और उसके आसपास के API, user interface, integrations, error handling और performance के conventional tests छोड़ देना।
  • Representative test set पर criteria की बजाय कुछ चुने हुए examples या एक run से model को आँकना।
  • यह पूछे बिना evaluation score मान लेना कि test data कहाँ से आया और क्या वह production के users, languages और हालात से मेल खाता है।
  • बदलते output के लिए एक exact expected output लिखना और हर variation को defect बताना, या उल्टा: "AI non-deterministic है" कहकर कोई भी output मान लेना।
  • Results के साथ model version, data version और settings record न करना, जिससे failure reproduce या compare नहीं हो पाता।
  • यह मान लेना कि release से पहले के results valid रहेंगे, जबकि retraining, provider updates और data drift बाद में behaviour बदल देते हैं।

QA का नज़रिया

असली team में tester AI के काम से उसी मोड़ पर जुड़ता है जहाँ वह कोई भी requirement review करता है। जब team तय करे कि model को क्या करना है, तब पूछें: "काफ़ी अच्छा" कैसे मापा जाएगा, किस data पर, users के किन groups के लिए, और कौन-से cases कभी fail नहीं होने चाहिए? यही जवाब acceptance criteria बनते हैं। Training और evaluation method data scientists के ज़िम्मे होते हैं, और कौन-सी error rates स्वीकार्य हैं यह product owner तय करता है, क्योंकि हर तरह की error की business cost होती है।

रोज़ के काम में दो तरह के tests अलग रखें: exact oracles वाले conventional checks, जहाँ model results बदल सकता हो वहाँ stub के साथ, और statistical criteria वाले model evaluations। हर test report और defect report में model version, dataset version, threshold और settings record करें। Data science team के evaluation को review करने लायक test result मानें, system और acceptance testing का विकल्प नहीं, और पूछें कि release के बाद model की monitoring कैसे होगी।

अभ्यास

ML review-moderation model का test plan review करें

आपका काम

Saudi Arabia की एक online shop ऐसा ML model जोड़ रही है जो तय करता है कि नया product review तुरंत publish होगा या moderator के लिए रोका जाएगा। Model 2024 में इकट्ठा हुए 40,000 English reviews पर train हुआ है; shop को Arabic और English दोनों में reviews मिलते हैं। एक साथी ने नीचे दिया draft test plan लिखा है।

Tester की तरह इसे review करें: हर line की गलती पहचानें, फिर एक बेहतर plan की रूपरेखा लिखें जो conventional checks और model checks को अलग रखे। काग़ज़ और कलम काफ़ी हैं।

सामग्री
Review moderation model v1.3 - draft test plan
T1  Submit "This phone is great, fast delivery" -> published
T2  Submit a review containing an insult -> held for moderation
T3  Run T1 and T2 once on staging; if both pass, the model is ready
T4  Test set: 500 reviews randomly sampled from the training data
T5  No API or UI tests: the data science team already tested the model
चरण
  1. T1 से T5 तक हर line के लिए बताएँ कि वह conventional check है या model check, और उसमें क्या गलत है।
  2. इस model के लिए एक representative test set का वर्णन करें।
  3. Statistical acceptance criteria और कम से कम एक must-pass group of cases लिखें।
  4. Model के आसपास अब भी चलने वाले conventional tests लिखें, और वे सवाल जो आप data scientist से पूछेंगे।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

T1 और T2 exact expected results वाले model checks हैं। Smoke cases के रूप में ये ठीक हैं, लेकिन दो examples ऐसे model के बारे में लगभग कुछ नहीं बताते जो अपने inputs के सिर्फ़ एक हिस्से पर सही होता है, और दोनों English में हैं। T3 भी model check है, लेकिन वह दो cases और एक run को release decision बना देता है; readiness के लिए representative set पर criteria चाहिए, जो recorded model version पर मापे जाएँ।

T4, यानी model checks का test set, सबसे गंभीर समस्या है। Training data से लिए गए reviews model पहले देख चुका है, इसलिए score ज़रूरत से ज़्यादा अच्छा आएगा, और 2024 का सिर्फ़-English set उन Arabic और English reviews को represent नहीं करता जो shop को आज मिलते हैं। Representative test set हाल के असली reviews का अलग sample है, production के language अनुपात में, जिसमें dialects, Arabic-English mix, spelling variants और emoji शामिल हों, और जिस पर labels ऐसे लोग लगाएँ जो एक लिखित guideline मानते हों कि क्या रोका जाना चाहिए।

Product owner के साथ तय किए जाने वाले example criteria: जिन reviews को रोका जाना चाहिए उनमें से कम से कम 90% रोके जाएँ, और स्वीकार्य reviews में से ज़्यादा से ज़्यादा 5% रोके जाएँ, Arabic और English के लिए अलग-अलग मापकर; must-pass group का हर review रोका जाए, जैसे धमकी, phone number या कोई दूसरा personal data वाले reviews। जब भी model retrain हो, पूरा set दोबारा चलाएँ और case-by-case compare करें।

T5 हर conventional check हटा देता है, और यह गलत है: model सिर्फ़ एक component है। फिर भी review form और उसका API टेस्ट करें, model धीमा या unavailable हो तो क्या होता है (reviews बिना check के publish होते हैं या रोके जाते हैं?), moderator queue, permissions, model version और score की logging, performance, और रोके गए Arabic reviews का display। Data scientist से सवाल: क्या training में कोई Arabic data इस्तेमाल हुआ? Labellers ने कौन-सी guideline मानी? Test data को training data से कैसे अलग रखा गया? Launch के बाद model की monitoring कैसे होगी?

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

क्या AI systems टेस्ट करने के लिए मुझे ML models बनाना आना चाहिए?

नहीं। आपको यह समझना है कि model का behaviour data से कैसे आता है, उसे कैसे evaluate किया जाता है और वह आम तौर पर कहाँ fail होता है, ताकि आप सही सवाल पूछ सकें और सही tests design कर सकें। इस module के अगले lessons यही शब्दावली देते हैं। Evaluations को automate करने में programming skills मदद करती हैं, जैसे किसी भी automation में।

क्या हर ML model non-deterministic होता है?

नहीं। किसी classifier का fixed version आम तौर पर एक ही input पर एक ही output देता है। Variation generative models की sampling, retraining, model updates और कभी-कभी environments के बीच छोटे numeric फ़र्क से आता है। Test को कितने runs चाहिए, यह तय करने से पहले पता करें कि इनमें से कौन-सा लागू होता है।

अगर model 95% बार सही है, तो क्या गलत जवाब defect है?

ज़रूरी नहीं। तय error rate के अंदर, ऐसे case में जो must-pass नहीं है, गलत जवाब expected behaviour है; उसे evaluation set में रखें। यह defect तब है जब overall rate या किसी group का rate acceptance criteria से नीचे चला जाए, कोई must-pass case fail हो, या errors किसी pattern में हों, जैसे एक language या एक तरह की request।

क्या AI testing traditional test techniques की जगह ले लेती है?

नहीं। यह उनमें data review और model evaluation जोड़ती है। Model के आसपास का system conventional software है, और equivalence partitioning, boundary value analysis, decision tables और exploratory testing जैसी techniques से ही आप कई tests design करते हैं, model के लिए test data चुनना भी।

संदर्भ

  • Certified Tester AI Testing (CT-AI) v2.0ISTQB · 2026AI-आधारित सिस्टम की टेस्टिंग पर ISTQB का specialist पाठ्यक्रम, machine learning और generative AI सिस्टम सहित।
  • ISO/IEC TR 29119-11:2020 — Software and systems engineering — Software testing — Part 11: Guidelines on the testing of AI-based systemsISO/IEC · 2020AI-आधारित सिस्टम की उन विशेषताओं पर तकनीकी रिपोर्ट जो उन्हें टेस्ट करना कठिन बनाती हैं, और उनके टेस्ट तरीक़ों पर।
  • AI Risk Management Framework (AI RMF 1.0)NIST · 2023पूरे जीवनचक्र में AI जोखिम प्रबंधन के लिए NIST का स्वैच्छिक फ़्रेमवर्क, Govern, Map, Measure और Manage फ़ंक्शन में व्यवस्थित।
  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
टूल्स

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

टेक्स्ट डिफ़

दो टेक्स्ट की लाइन-दर-लाइन या शब्द-दर-शब्द तुलना करें और अंतर हाइलाइट करें।

फ़ॉर्मेटिंग

बहुभाषी टेस्ट डेटा जनरेटर

i18n और RTL/LTR मिश्रण जाँचने के लिए एक ही रिकॉर्ड कई भाषाओं (अंग्रेज़ी, अरबी, हिंदी और अन्य) में जनरेट करें।

टेस्ट डेटा

और गहराई से

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

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