AI testing agent अलग क्या करता है
coverage आपके प्रोडक्ट से निकालता है। किसी specification से, requirements document से, या चल रहे एप्लिकेशन को खँगालकर — न कि इससे कि किसी को क्या लिखना याद रह गया।
steps को इरादों की तरह लिखता है। "settings पेज खोलो", न कि DOM से होकर जाता कोई path — यही वजह है कि ऊपरी redesign से यह आम तौर पर टूटता नहीं।
failure ऐसे रूप में लौटाता है जिसे ठीक करने वाला इस्तेमाल कर सके। क्या करने की कोशिश की गई, क्या हुआ, दोनों कहाँ अलग हुए — ऐसे रूप में कि कोई दूसरा agent उस पर काम कर सके।
पहला failure mode: check को संतुष्ट कर देना
किसी टेस्ट को pass कराने के लिए कहा जाए तो agent सबसे छोटा रास्ता ले सकता है, और कई बार प्रोडक्ट ठीक करने से छोटा रास्ता check को बदल देना होता है। यह बदनीयती नहीं है, यह लक्ष्य के अधूरे ढंग से बताए जाने का नतीजा है।
बचाव सस्ता है। हर check में कोई ठोस, दिखने वाली चीज़ तय करें, और जान-बूझकर कुछ तोड़कर पक्का करें कि check लाल हो सकता है। जो check fail ही नहीं हो सकता, वह कुछ भी नहीं बचा रहा।
दूसरा failure mode: भरोसे से भरा ऐसा coverage जिसे किसी ने पढ़ा नहीं
agent ख़ुशी-ख़ुशी दो सौ केस बना देगा। मात्रा प्रगति जैसी दिखती है, और जिस coverage की किसी ने समीक्षा नहीं की उस पर कोई भरोसा नहीं कर सकता, क्योंकि आपको पता ही नहीं कि वह assert क्या कर रहा है।
कोड नहीं, plan पढ़िए। प्रशासनिक routes काट दीजिए, वे product rules जोड़िए जो कहीं लिखे नहीं हैं, और इसे pull request की तरह बरतिए।
यह अब भी क्या नहीं कर सकता
आपके business rules जानना
दो discount एक साथ लगें तो क्या होना चाहिए — यह एक फ़ैसला है, अपने आप निकल आने वाली बात नहीं।
abuse case गढ़ना
यह authorization जाँच लेगा। यह उस workflow के बारे में नहीं सोचेगा जिसे कोई अपने फ़ायदे के लिए तोड़-मरोड़ सकता है।
ख़राब environment ठीक करना
infrastructure से आने वाली flakiness, flakiness ही बनी रहती है।
plan की समीक्षा कुशलता से करना
इस तरह काम करने की सबसे बड़ी लगातार चलने वाली लागत यह है कि आपको वह coverage पढ़ना पड़ता है जो आपने लिखा नहीं; और इसे ढंग से न करना ही ऊपर बताए दोनों failure mode पैदा करता है। एक तेज़ तरीक़ा है।
सिर्फ़ assertions पढ़िए। पहली बार में steps पूरी तरह छोड़ दीजिए, क्योंकि steps मशीनी होते हैं और समझदारी assertions में बसती है। जो assertion किसी टूटे हुए प्रोडक्ट पर भी सही उतरे, ठीक वही सुधारने लायक है — और जब आप सिर्फ़ उन्हीं को देख रहे हों तो वे आसानी से पकड़ में आ जाते हैं।
फिर सूची में यह देखिए कि क्या छूटा है, न कि क्या मौजूद है। बनाए गए plan मौजूदा endpoints पर भरोसेमंद ढंग से पूरे होते हैं, और उन नियमों पर उतने ही भरोसेमंद ढंग से चुप, जो किसी के दिमाग़ में रहते हैं। ऐसे तीन नियम जोड़ना तीस steps सुधारने से ज़्यादा क़ीमती है।
शुरुआत कैसे करें
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
अगर आप स्थानीय रूप से कुछ भी install नहीं करना चाहते, तो यही setup TestSprite dashboard में भी मौजूद है। बाक़ी CLI surface के लिए देखें CLI repository।
mechanism से ज़्यादा मायने trigger रखता है। इसे अपने deployment event से जोड़ देने का मतलब है कि हर बदलाव की जाँच हो जाती है, बिना किसी के अलग से तय किए; GitHub App यह काम dashboard से करता है, और GitHub Actions का step इसे आपके workflow के भीतर से करता है।
एक agent के रूप में TestSprite क्या करता है
यह आपके sources और चल रहे एप्लिकेशन से coverage निकालता है, steps को इरादों की तरह लिखता है ताकि ऊपरी बदलाव उन्हें न तोड़ें, deploy किए गए ऐप पर चलता है, और failure को इस रूप में लौटाता है कि क्या करने की कोशिश की गई, क्या हुआ और दोनों कहाँ अलग हुए।
setup उस coding agent में verification skill install कर देता है जिसे आप पहले से इस्तेमाल करते हैं, इसलिए यह सब उसी loop के भीतर होता है जहाँ कोड लिखा जा रहा है — न कि किसी अलग कदम के तौर पर जो किसी को याद रखना पड़े।
असली फ़ायदा loop के बंद होने में है। बदलाव चल रहे प्रोडक्ट के ख़िलाफ़ जाँचा जाता है, failure ऐसे रूप में लौटता है जिस पर agent काम कर सके, और fix की पुष्टि उस तर्क से नहीं बल्कि किसी और चीज़ से होती है जिसने उसे पैदा किया था। आपके ज़िम्मे रह जाता है plan पढ़ना और यह तय करना कि 'सही' का मतलब क्या है — यह हफ़्ते भर में एक घंटे का काम है, पूरी भूमिका नहीं।
यह test generator से अलग कैसे है?
generator ऐसा कोड बनाता है जिसे फिर आप चलाते और सँभालते हैं। agent उसे चलाता भी है, नतीजा पढ़ता है और दोहरा सकता है — यही loop को बंद करता है।
क्या यह बिना specification के काम कर सकता है?
हाँ, चल रहे एप्लिकेशन को खँगालकर — हालाँकि specification या requirements document से पहला plan बेहतर बनता है।
इसकी कितनी समीक्षा ज़रूरी है?
पहली बार चलाने से पहले और किसी भी बड़े regeneration के बाद plan पढ़ें। उनके बीच, नए केसों की समीक्षा वैसे ही करें जैसे आप कोड की करते हैं।
खर्च बेक़ाबू होने से इसे क्या रोकेगा?
हर run credits खर्च करता है, इसलिए लंबे session से पहले उम्मीदें तय कर लें। जिस agent के पास verification tool होगा वह उसे इस्तेमाल करेगा — यही तो मक़सद है, और इसके लिए बजट रखना सही है।
क्या यह QA engineer की जगह ले लेता है?
यह दोहराव वाले आधे हिस्से की जगह लेता है। 'सही क्या है' तय करना और विरोधी नज़रिए से सोचना इंसान का काम बना रहता है — और वैसे भी यही ज़्यादा क़ीमती आधा हिस्सा है।
वह तय करता है कि जाँचना क्या है। आप जाँचिए कि उसने तय क्या किया।
AI testing agent coverage निकालता है, steps को इरादों की तरह लिखता है और काम आने लायक failure लौटाता है। ऐसे checks से बचें जो fail ही नहीं हो सकते, और ऐसे coverage से जिसे किसी ने पढ़ा नहीं; business rules और abuse cases इंसानों के हाथ में रखें।