Automated AI testing, पहला मतलब: वह AI जो आपकी टेस्टिंग ऑटोमेट करता है
कवरेज आपके प्रोडक्ट से ही जनरेट होता है, स्टेप्स इरादों के रूप में लिखे जाते हैं ताकि सतही बदलावों से वे टूटें नहीं, और फ़ेलियर ऐसे रूप में लौटते हैं जिन्हें ठीक करने वाला इस्तेमाल कर सके। जिस सॉफ़्टवेयर को टेस्ट किया जा रहा है वह सामान्य और deterministic है; AI टूलिंग में है।
इस श्रेणी के ज़्यादातर प्रोडक्ट यही करते हैं, और ज़्यादातर टीमों को इसी की ज़रूरत होती है।
दूसरा मतलब: ऐसे सिस्टम की टेस्टिंग जिसमें AI मौजूद है
यहाँ प्रोडक्ट ख़ुद non-deterministic है। एक ही इनपुट पर अलग-अलग आउटपुट आता है, इसलिए "expected बराबर actual" वाला तरीक़ा बचता ही नहीं और आपको अलग तरह के assertion की ज़रूरत पड़ती है।
Properties, बराबरी नहीं
यह assert करें कि आउटपुट का स्वरूप सही है, वह स्रोत का हवाला देता है, तय लंबाई के भीतर रहता है, और जिसे मना करना चाहिए उसे मना करता है।
Distributions, अकेले रन नहीं
एक रन से लगभग कुछ पता नहीं चलता। कई बार चलाइए और दर पर नज़र रखिए।
Regression, निरपेक्ष पैमाने नहीं
सवाल यह है कि इस बदलाव ने चीज़ों को बदतर किया या नहीं, यह नहीं कि सब कुछ परफ़ेक्ट है या नहीं।
वह ग़लती जो दोनों में होती है
यह मान लेना कि पास होता हुआ चेक कुछ बता रहा है, बिना कभी यह पुष्टि किए कि वह चेक फ़ेल भी हो सकता है। deterministic मामले में इससे ऐसी सूट बनती हैं जो assertions से भरी होती हैं पर कभी लाल हो ही नहीं सकतीं। non-deterministic मामले में इससे ऐसे evaluation harness बनते हैं जो किसी भी चीज़ को ऊँचा स्कोर दे देते हैं।
जान-बूझकर कुछ तोड़िए। एक मिनट लगता है, और यही अकेला सबूत है कि इनमें से कोई भी चेक सचमुच उसी चीज़ से जुड़ा है जिसे मापने का वह दावा करता है।
मिले-जुले प्रोडक्ट में सीमा-रेखा खींचना
जिन प्रोडक्ट्स में AI होता है, उनका अधिकांश हिस्सा AI नहीं होता, और काम की बात यह है कि आप यह लकीर साफ़-साफ़ खींच दें, बजाय इसके कि non-determinism पूरे प्रोडक्ट में फैलता रहे।
फ़ीचर के इर्द-गिर्द सब कुछ सामान्य सॉफ़्टवेयर है: authentication, स्टोरेज, rate limits, और वह इंटरफ़ेस जो आउटपुट दिखाता है। यह सब परंपरागत तरीक़े से टेस्ट होता है, और सिर्फ़ इसलिए कि एक कंपोनेंट अप्रत्याशित है, पूरे प्रोडक्ट को अप्रत्याशित मान लेने से आप बहुत सारी सस्ती और भरोसेमंद कवरेज गँवा देते हैं।
सीमा के भीतर properties और दरों पर आ जाइए। इनपुट जाता है, आउटपुट हर बार बदलता है, और आप यह assert करते हैं कि उसका स्वरूप सही है, वह किसी असली चीज़ का हवाला देता है, और जिसे मना करना चाहिए उसे मना करता है। यह सीमा कहाँ है, इसे एक बार लिख देना ही टीम को दोनों ख़तरों से बचाता है: deterministic हिस्सों पर सांख्यिकीय तरीक़ों से ज़रूरत से ज़्यादा टेस्टिंग, या AI हिस्से की कम टेस्टिंग क्योंकि सटीक assertions बार-बार फ़ेल होते रहे।
आपके पास इनमें से कौन-सा है
अगर आपका प्रोडक्ट दो बार एक ही जवाब देगा, तो आप पहले मामले में हैं और आपको चलती हुई ऐप के ख़िलाफ़ जनरेट की गई कवरेज चाहिए। अगर नहीं देगा, तो आप दूसरे मामले में हैं और आपको पास-या-फ़ेल की जगह property-based assertions और दरें चाहिए।
बहुत सारे प्रोडक्ट दोनों होते हैं: एक deterministic एप्लिकेशन जिसके अंदर एक AI फ़ीचर है। deterministic हिस्सों को सामान्य तरीक़े से टेस्ट कीजिए और AI फ़ीचर को उसकी अपनी अलग समस्या मानिए, बजाय एक ही तरीक़े को दोनों पर खींचने के।
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
जो लोकल इंस्टॉल नहीं चाहते, उनके लिए डैशबोर्ड वही सब कवर करता है, और पूरे कमांड सरफ़ेस के लिए देखिए CLI repository।
दो रास्ते हैं, और चुनाव दरअसल इस बात का है कि pipeline किसके ज़िम्मे है। डैशबोर्ड से GitHub App जोड़ने पर आपकी रिपॉज़िटरी में कोई बदलाव करने की ज़रूरत ही नहीं पड़ती, क्योंकि वह उसी डिप्लॉयमेंट पर प्रतिक्रिया देता है जो आपका बिल्ड पहले से भेजता है। वहीं एक GitHub Actions स्टेप जोड़ने से यह चेक रिपॉज़िटरी के अंदर आ जाता है, जहाँ बाक़ी बिल्ड की तरह उसका भी रिव्यू होता है।
TestSprite इनमें से कौन-सा मतलब कवर करता है
पहला। यह सामान्य सॉफ़्टवेयर को वेरिफ़ाई करने के लिए AI का इस्तेमाल करता है: कवरेज आपके प्रोडक्ट से जनरेट होता है, स्टेप्स इरादों के रूप में लिखे जाते हैं, एग्ज़ीक्यूशन डिप्लॉय की गई एप्लिकेशन पर होता है, और फ़ेलियर ऐसे रूप में लौटता है जिस पर कोई coding agent काम कर सके।
जिस प्रोडक्ट में AI फ़ीचर है, उसमें यह उस फ़ीचर के इर्द-गिर्द की हर चीज़ कवर करता है, यानी प्रोडक्ट का ज़्यादातर हिस्सा: authentication, स्टोरेज, rate limiting, इंटरफ़ेस, और वे फ़्लो जो यूज़र सचमुच अपनाता है। API की तरफ़ state से जुड़ी दिक़्क़तें Auto-Authentication, Dynamic Variables, Dependency Chains और Auto-Cleanup संभालते हैं।
फ़ीचर ख़ुद property-based assertions और दरें माँगता है, जो एक अलग harness है। उस सीमा को साफ़-साफ़ खींचना ही आपको deterministic बहुसंख्य हिस्से पर सस्ती और भरोसेमंद कवरेज दिलाता है, बजाय इसके कि आप पूरे प्रोडक्ट को अप्रत्याशित मान लें।
TestSprite कौन-सा करता है?
पहला। यह चलते हुए प्रोडक्ट के ख़िलाफ़ एप्लिकेशन के deterministic व्यवहार को वेरिफ़ाई करता है, उन एप्लिकेशन्स समेत जिनमें AI फ़ीचर भी मौजूद हों।
LLM फ़ीचर को हम कैसे टेस्ट करें?
Property-based assertions कई बार चलते हैं और एकल नतीजों के बजाय दरों को ट्रैक करते हैं। जवाब की गुणवत्ता के मुक़ाबले आम तौर पर refusals, फ़ॉर्मैट और हवाले की मौजूदगी जाँचना ज़्यादा आसान होता है।
क्या एक ही suite दोनों को कवर कर सकती है?
deterministic हिस्सों को, हाँ। non-deterministic फ़ीचर को अपना अलग harness चाहिए, जिसमें पास होने की अपनी परिभाषा हो।
AI फ़ीचर के लिए वाजिब pass rate क्या है?
जो भी आपकी पिछली दर थी। benchmarks से उधार लिए गए निरपेक्ष लक्ष्य आपके प्रोडक्ट पर शायद ही कभी लागू होते हैं।
क्या अकेला फ़ेल होता रन बग है?
non-deterministic फ़ीचर के लिए अपने आप में नहीं। संकेत यह है कि दर बदली; अकेला रन तो शोर है।
दो विषय, एक ही नाम।
Automated AI testing का मतलब या तो वह AI है जो आपके सॉफ़्टवेयर को टेस्ट करता है, या ऐसे सॉफ़्टवेयर की टेस्टिंग जिसमें AI मौजूद है। पहले को चलती हुई ऐप के ख़िलाफ़ जनरेट की गई कवरेज चाहिए, दूसरे को properties और दरें। दोनों को ऐसे चेक चाहिए जिनके बारे में आपने पुष्टि कर ली हो कि वे फ़ेल हो सकते हैं।