एजेंटिक टेस्टिंग - E2E टेस्ट स्टैक में एजेंट्स की भूमिका

 (slack.engineering)
6 पॉइंट द्वारा GN⁺ 3 시간 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • Slack इंजीनियरिंग टीम ने यह जांचने के लिए 200 से अधिक agentic workflows चलाए कि क्या agent-based E2E(End-to-End) testing पारंपरिक deterministic tests की जगह ले सकती है
  • जहाँ पारंपरिक E2E tests तय UI path को enforce करते हैं, वहीं agents goal हासिल हुआ या नहीं इसकी पुष्टि करते हैं और एक ही नतीजे तक अलग-अलग रास्तों से पहुँचते हैं
  • Agent execution में प्रति रन $15–30 और 10 मिनट से अधिक लगते हैं, लेकिन reliability के लिहाज़ से इनके स्पष्ट उपयोग-मामले हैं
  • Playwright MCP ने CLI और code-generation तरीकों की तुलना में कम failure rate और कम token usage दर्ज किया, जिससे पता चलता है कि execution environment की stability नतीजों को तय करती है
  • Agentic testing मौजूदा tests को replace नहीं करती, बल्कि test pyramid के सबसे ऊपर exploration, debugging और complex behavior validation की एक नई layer जोड़ती है

Journeys से Goals तक (From Journeys to Goals)

  • पारंपरिक E2E tests UI को follow करने वाली एक खास journey को validate करते हैं → click → click → input → assert
  • Agent-based tests "thread message भेजो" जैसी instruction के रूप में दिए गए goal को हासिल किया जा सकता है या नहीं यह validate करते हैं → goal → agent adapts → result validation
    • मुख्य अंतर: "tests journey को force करते हैं, agents goal को validate करते हैं"
  • पूरा workflow (login → search → result → reset) स्थिर रहा, लेकिन वास्तविक action order हर बार बदल गया
    • अलग input methods (search suggestion पर click बनाम Enter दबाना)
    • अलग navigation patterns (search दोबारा चलाना बनाम existing state reuse करना)
    • कुछ steps जुड़ना या छूट जाना (extra clicks, snapshots, intermediate actions)
  • इस flexibility के साथ reliability, cost और execution time के trade-offs आते हैं

  • मुख्य सवाल

    • क्या प्रति रन $15–30 और 10 मिनट से अधिक लेने वाला तरीका आधुनिक testing workflow का हिस्सा बन सकता है?
    • 200 से अधिक runs के नतीजों ने दिखाया कि यह पारंपरिक tests से मूल रूप से अलग है, फिर भी इसकी reliability ऊँची है और इसके उपयोग-मामले स्पष्ट हैं
    • Code लिखने, failures debug करने और UI को सीधे manipulate करने में सक्षम large language models (LLMs) की प्रगति ने इस नए execution model को संभव बनाया है

प्रयोग की संरचना (Our Experiment)

  • Reliability, execution speed और cost मापने के लिए कई configurations में 200 से अधिक automated runs किए गए

  • Execution models (तीन तरीके)

    • Agent + Playwright MCP: agent browser के साथ predefined browser actions (element click, input, DOM state read आदि) के जरिए interact करता है और persistent context (DOM snapshots, logs) बनाए रखता है
    • Agent + Playwright CLI: shell में Playwright CLI commands चलाकर एक बार में एक step process किया जाता है, और updated UI state देखकर अगला action तय किया जाता है
    • Generated Playwright Tests: AI agent natural language description से deterministic Playwright code बनाता है, उसे standard E2E test की तरह चलाता है और pass होने तक बार-बार सुधारता है

  • प्रयोग का environment

    • MCP और CLI agent model: Claude Sonnet 4.5
    • Generated Playwright test model: Claude Opus 4.6
    • Execution: non-interactive Claude Code (claude -p)
    • Browser tools: Playwright MCP, Playwright CLI
    • Environment: Slack Dev API MCP, और पूरे experiment non-production data वाले test workspace में किए गए

  • Test flows (complexity के दो स्तर)

    • Thread Reply (सरल): channel बनाना, message भेजना, thread reply करना और thread state validate करना शामिल लगभग 15–20 step workflow
    • Search Discovery (मध्यम जटिलता): search term input, results explore करना, views के बीच जाना (search, channel, thread), और expected result validate करना शामिल लगभग 25–30 step workflow

  • Input formats

    • Natural language (NL): workflow और expected result को step-by-step list में लिखी गई human-readable instructions
    • Structured YAML: वही workflow steps, actions, targets और expected results के साथ structured format में
      • अंतर detail level का नहीं बल्कि expression style का था — natural language को agent को interpret और map करना पड़ता है, जबकि YAML mapping को अधिक स्पष्ट बनाता है

  • Experiment matrix

    • हर configuration को 20 बार चलाया गया; कुल 5 experiments (MCP-NL, MCP-YAML, CLI-NL, CLI-YAML, generated test-NL) को Thread Reply और Search Discovery, दोनों flows पर लागू किया गया

देखे गए नतीजे (What We Observed)

  • Result summary

    • Agent (Playwright MCP): failure rate 0%(thread reply) / लगभग 12%(search discovery), औसत 5–8 मिनट
    • Agent (Playwright CLI): failure rate लगभग 12% / लगभग 20%, औसत 9–11 मिनट
    • Generated Playwright Tests: failure rate लगभग 8% / लगभग 48%, औसत 3 मिनट

  • Reliability

    • Flow जितना complex हुआ, reliability में बदलाव उतना ही स्पष्ट दिखा
    • Playwright MCP सबसे स्थिर रहा — simple scenarios में failure rate लगभग 0%, और complex flows में भी 0–12%
    • Playwright CLI में failure rate ज्यादा रहा (लगभग 12–20%), और ज्यादातर failures model reasoning से नहीं बल्कि authentication handling, navigation timing और session instability जैसी execution समस्याओं से आए
    • Generated tests simple flows में ठीक रहे (लगभग 8%), लेकिन complex workflows में काफी खराब हुए (लगभग 48%)
      • ये पूरी तरह गलत नहीं थे; आम तौर पर flow के 70–80% तक पहुँचने के बाद आख़िरी interaction या assertion पर fail हुए
      • Failure के कारण थे UI state variability और abstraction mismatch — loosely specified natural language flows से generation होना और existing page-object abstractions का reuse, जिससे precise element targeting बाधित हुई
    • Complexity बढ़ने पर reliability gap भी बढ़ा, और MCP जैसे agent-native execution models ज्यादा स्थिर साबित हुए
      • MCP app का real-time, stable view बनाए रखता है, जबकि CLI हर step पर snapshot से state reconstruct करता है → flow लंबा होने पर mismatch जमा होता जाता है
      • ऐसा लगा कि MCP session के भीतर पिछले successful interactions को reuse करता है, जबकि CLI हर step पर जैसे शुरुआत से शुरू करता है (हालाँकि इसे explicitly मापा नहीं गया)

  • Speed

    • Generated tests लगातार सबसे तेज़ रहे (लगभग 3 मिनट), MCP लगभग 5–8 मिनट, CLI लगभग 9–11 मिनट
    • Generated test numbers में test generation + execution शामिल थे; हर test को एक बार generate करने के बाद 5 बार चलाकर औसत निकाला गया
      • असल pure execution इससे कहीं तेज़ था — thread reply लगभग 32 सेकंड, search discovery लगभग 45 सेकंड
      • बार-बार चलने वाले CI environments में one-time generation cost लगभग नगण्य हो जाती है, इसलिए deterministic tests efficient तरीके से scale कर सकते हैं
    • Agent workflows में हर execution पर फिर से cost लगती है — हर step में UI state observe करना, अगला action infer करना, action execute करना और result validate करना शामिल है

  • Adaptability

    • बिल्कुल वही action order follow करने वाले runs केवल लगभग 20% थे; ज़्यादातर runs ने उसी goal तक पहुँचने के अलग-अलग valid UI paths खोजे
      • Menu अलग क्रम में खोलना
      • थोड़ा अलग UI elements चुनना
      • Alternative navigation flow इस्तेमाल करना
    • इसे मापने के लिए runs के बीच action signatures की तुलना की गई — agent द्वारा किए गए tool calls और UI actions की ordered list
      • तुलना से पहले normalization किया गया: parameters, wait/snapshot actions और equivalent tool variants (fill बनाम type) को merge किया गया ताकि सिर्फ meaningful differences गिने जाएँ
    • Final result सही होने पर भी ज़्यादातर action order अलग थे — पारंपरिक E2E एक deterministic journey को force करता है, जबकि agents interface explore करके goal state तक पहुँचना validate करते हैं

  • Cost और उसका स्रोत (Cost and Where It Comes From)

    • Agent runs आम तौर पर प्रति रन $15–30 के थे, जो पारंपरिक tests से कहीं ज्यादा महंगे हैं
    • उसी search discovery flow के token usage analysis में
      • MCP (Opus 4.6) लगभग 3.8M, MCP (Sonnet 4.5) लगभग 3.5M, MCP (Haiku 4.5) लगभग 5.7M
      • CLI (Opus 4.6) लगभग 6M, Code Gen (Opus 4.6) लगभग 7M
    • कौन-सा model इस्तेमाल हुआ उससे ज्यादा अहम यह था कि execution कैसे हुआ — Haiku ने ज्यादा tokens इस्तेमाल किए, लेकिन सभी MCP approaches ने CLI और Code Gen से कम token usage दिखाया
    • Claude Code के session execution model के analysis से पता चला कि underlying API stateless है, इसलिए हर turn पर पूरा system prompt और पूरी conversation history फिर से भेजी जाती है
      • Cost model output से नहीं बल्कि context accumulation की गति और turns की संख्या से तय होती है
    • Turns की संख्या: MCP (Opus/Sonnet) लगभग 40, MCP (Haiku) लगभग 60, CLI (Opus) लगभग 85, Code Gen (Opus) लगभग 70
      • CLI में हर browser interaction action, wait, snapshot, read और element lookup जैसे कई commands में टूट जाता है, इसलिए औसतन 85 turns लगते हैं
      • MCP interaction और state return को एक ही round-trip में जोड़ देता है
      • हर extra turn पर पूरे system prompt की cost और पुरानी conversation context दोबारा भेजने का overhead जुड़ता है
    • Context भरने वाले मुख्य factors
      • MCP और CLI: browser snapshots मुख्य payload थे — Playwright MCP द्वारा लौटाया गया accessibility tree snapshot बाद के सभी turns में accumulate होता गया
      • Code Gen: हर retry के साथ पूरा error trace, assertion failure और DOM state वाला test runner output accumulate होता गया
    • Cost का बड़ा हिस्सा पहले से देखी जा चुकी चीज़ों को दोबारा भेजने में जाता है; हर turn में नई जानकारी बहुत कम होती है
    • Token usage अभी optimized नहीं था — कमी लाने के लिए prompt caching, context compaction और snapshot frequency कम करना जैसे तरीके सुझाए गए
    • Cost की वजह से फिलहाल यह high-frequency CI execution से ज्यादा targeted debugging और exploratory testing के लिए उपयुक्त है, हालाँकि आगे models और tools के साथ यह सुधर सकता है

  • Infrastructure का महत्व (MCP vs CLI)

    • सिर्फ model ही नहीं, execution environment भी reliability को बहुत प्रभावित करता है — MCP 0–12%, CLI 12–20% failure rate
    • CLI के ज्यादातर failures authentication और navigation issues (login errors, timeouts, session instability) से आए; ये agent reasoning नहीं बल्कि execution layer की समस्याएँ थीं
    • Playwright MCP structured browser primitives और agent tool-calling workflow के साथ गहरा integration देता है, जबकि CLI agent और browser के बीच एक extra layer जोड़ता है
    • Parallelization का अंतर: MCP में concurrent execution आसान है, CLI में parallelization मुश्किल होने से अधिकतर runs sequential रहे
    • Reliability, speed और cost केवल model से नहीं बल्कि execution environment की stability और design से तय होते हैं

  • Execution capability की सीमाएँ (Execution Capability Boundaries)

    • यह experiment single-session UI workflows पर केंद्रित था
    • Cross-workspace flows या कई browser windows खोलने वाले workflows में execution model का चुनाव agent जितना ही अहम हो जाता है, और नई चुनौतियाँ लाता है
      • MCP में लंबे flows के साथ observation loop बढ़ने से cost issue हो सकता है
      • CLI में multiple browser sessions manage करने पर coordination complexity और token usage बढ़ सकता है
    • दोनों approaches इन्हें support कर सकती हैं, लेकिन trade-offs अलग हैं — इस experiment में इन्हें नहीं परखा गया, पर evaluation teams के लिए यह अहम विचारणीय बिंदु है

Test pyramid में agentic testing की जगह

  • Agentic testing मौजूदा तरीकों को replace नहीं करती, बल्कि उनके ऊपर नई capabilities जोड़ती है

  • Deterministic E2E tests

    • CI में तेज़ और repeatable regression checks के लिए सबसे उपयुक्त
      • इंसानों द्वारा लिखे गए या AI द्वारा generated
      • तेज़, repeatable और CI-friendly
      • कम operational cost
      • खास UI journeys को enforce करते हैं

  • Agentic testing

    • तय script चलाने के बजाय goal से शुरुआत करती है — UI observe करना, current state reason करना, और desired result तक पहुँचने का तरीका तय करना
      • Complex UI behaviors explore करना
      • Flaky workflows debug करना
      • Production bugs reproduce करना

  • Agentic layer के साथ test pyramid

    • System perspective से agentic testing, E2E की ही तरह UI के जरिए real user workflows validate करती है; फर्क workflow के execute होने के तरीके में है
    • भविष्य की सबसे असरदार testing strategy दोनों को मिलाकर बनेगी — deterministic tests CI की stable foundation देंगे, और agentic testing pyramid के सबसे ऊपर exploration, debugging और complex behavior validation संभालेगी

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.