ऑटोनॉमस सॉफ़्टवेयर टेस्टिंग के चार स्तर
1. सहायता-आधारित टेस्ट लेखन। आप बताते हैं कि क्या टेस्ट करना है, कोड वह लिखता है। समय की असली बचत। फ़ैसले अब भी पूरी तरह आपके हैं।
2. जनरेट किया गया कवरेज। स्पेसिफ़िकेशन या चल रहे ऐप से यह खुद सुझाता है कि क्या टेस्ट करना है। प्लान की समीक्षा आप करते हैं। ज़्यादातर प्रोडक्ट सच में यहीं हैं।
3. स्व-रखरखाव। प्रोडक्ट बदलने पर कवरेज खुद ढल जाता है, किसी को उसे सुधारना नहीं पड़ता। इसके लिए जानबूझकर किए गए बदलाव और रिग्रेशन के बीच फ़र्क करना ज़रूरी है।
चौथा है क्लोज़्ड लूप: यह फ़ेल्योर पकड़ता है, सबूत किसी कोडिंग एजेंट को सौंपता है, और फ़िक्स को वेरिफ़ाई करता है। आज यह एक सीमित रूप में मौजूद है — ऐसे बिहेवियरल डिफ़ेक्ट के लिए जिन्हें साफ़ तौर पर दोहराया जा सके — और जहाँ प्रोडक्ट से जुड़ा कोई फ़ैसला लेना हो, वहाँ तक यह नहीं पहुँचता।
हर स्तर आपसे क्या माँगता है
स्तर एक: जानिए कि क्या टेस्ट करना है। पूरा विवेक आपके ही पास रहता है।
स्तर दो: एक प्लान की समीक्षा कीजिए। लिखने से तेज़ है, पर मेहनत शून्य नहीं है, और इसे छोड़ देने पर वैसा कवरेज मिलता है जिसे कोई समझता नहीं।
स्तर तीन: तय कीजिए कि कौन-सा बदलाव जानबूझकर किया गया माना जाएगा। टूल को यह पता नहीं चल सकता कि कोई फ़्लो जानबूझकर नए सिरे से डिज़ाइन किया गया था।
स्तर चार: 'सही' को इतनी सटीकता से परिभाषित कीजिए कि फ़िक्स आपके बिना वेरिफ़ाई हो सके।
ध्यान दीजिए कि ऊपर चढ़ते जाने पर इंसानी काम ख़त्म नहीं होता। वह स्टैक में ऊपर खिसक जाता है — टाइप करने से फ़ैसला लेने की ओर — जो ज़्यादा कीमती भी है और सौंपना ज़्यादा मुश्किल भी।
वह सीमा जिसकी मार्केटिंग कोई नहीं करता
कोई भी स्तर इस ज़रूरत को नहीं मिटाता कि 'सही' का मतलब क्या है, यह तय किया जाए। टूल यह निकाल सकता है कि कोई एंडपॉइंट मौजूद है और कोई फ़ील्ड स्ट्रिंग है। यह नहीं निकाल सकता कि दो डिस्काउंट एक साथ नहीं लगने चाहिए, क्योंकि यह एक बिज़नेस नियम है जो किसी इंसान के लिए गए फ़ैसले में बसा होता है।
जो प्रोडक्ट इससे उलट इशारा करता है, वह असल में स्तर दो का ब्यौरा दे रहा है और उसे स्तर चार बता रहा है।
वे सवाल जो किसी प्रोडक्ट को सीढ़ी पर सही जगह रख देते हैं
वेंडर खुद को उस सबसे ऊँचे पायदान पर बताते हैं जिसका बचाव वे कर सकें, इसलिए ऐसे सवाल तैयार रखना काम आता है जो उन्हें ठीक-ठीक जगह पर रख दें।
क्या टेस्ट होगा, यह कौन तय करता है। अगर जवाब है कि आप, तो टेस्ट चाहे जैसे भी लिखा जाए, यह स्तर एक ही है।
जब इंटरफ़ेस बदलता है पर व्यवहार नहीं, तब क्या होता है। अगर टेस्ट को कोई इंसान सुधारता है, तो यह स्तर दो है। अगर वह टिका रहता है, तो तीन। और अगर वह टिका भी रहे और व्यवहार सचमुच बदलने पर फ़ेल भी हो जाए, तो यह ठीक से किया गया स्तर तीन है, जो ज़्यादा दुर्लभ है।
और फ़ेल्योर के बाद क्या होता है। अगर आउटपुट किसी इंसान के लिए डैशबोर्ड पर चला जाता है, तो बात वहीं रुक जाती है। स्तर चार का मतलब है कि आउटपुट को वही चीज़ इस्तेमाल कर सके जो समस्या ठीक करती है, और फ़िक्स बिना किसी इंसान के बीच में संदेश पहुँचाए वेरिफ़ाई हो जाए। ये तीन सवाल क्रम से पूछने में पाँच मिनट लगते हैं और किसी भी फ़ीचर लिस्ट के मुकाबले कहीं ज़्यादा ईमानदार जगह तय होती है।
शुरुआत कैसे करें
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
अगर आप कुछ भी इंस्टॉल नहीं करना चाहते, तो डैशबोर्ड भी यही काम करता है। कमांड लाइन और जो कुछ कर सकती है, उस सबके लिए देखिए CLI रिपॉज़िटरी।
अगर पाइपलाइन किसी दूसरी टीम की है, तो GitHub App सबसे कम अड़चन वाला रास्ता है: यह एक वेबहुक है, आपकी रिपॉज़िटरी में कुछ नहीं बदलता, और तब चलता है जब आपका बिल्ड नया वर्ज़न लाइव होने की सूचना देता है। अगर आप चाहते हैं कि चेक रिपॉज़िटरी के भीतर ही दिखे, तो GitHub Actions स्टेप यह काम कर देता है।
सीढ़ी पर TestSprite कहाँ खड़ा है
हर जगह स्तर दो, व्यवहार में बदलाव के लिए स्तर तीन, और सीमित रूप में स्तर चार: फ़ेल्योर ऐसी शक्ल में लौटता है जिस पर कोई कोडिंग एजेंट काम कर सके, और फ़िक्स को वही चेक वेरिफ़ाई करता है, न कि वह तर्क जिससे फ़िक्स निकला था।
ठोस रूप में, कवरेज आपके प्रोडक्ट से जनरेट होता है और सादी भाषा में निखारा जाता है, स्टेप्स इरादों के रूप में होते हैं इसलिए ऊपरी-सतही बदलाव उन्हें तोड़ते नहीं, और वेरिफ़िकेशन स्किल उसी कोडिंग एजेंट में इंस्टॉल हो जाती है जिसे आप पहले से इस्तेमाल करते हैं, ताकि लूप वहीं चले जहाँ काम हो रहा है।
आपके पास जो बचा रहता है वह ऊपर बताई गई वही सीमा है: किसी अस्पष्ट नियम के लिए 'सही' का मतलब तय करना। उसके नीचे का सब कुछ आगे बढ़ जाता है, और फ़ायदा यह है कि कवरेज की सीमा अब इस बात से तय नहीं होती कि कोई कितना लिख सकता है।
आज कौन-सा स्तर व्यावहारिक है?
दो — व्यवहार में बदलाव के लिए तीन, और जिन डिफ़ेक्ट को साफ़ तौर पर दोहराया जा सके उनके लिए सीमित रूप में चार।
क्या ऑटोनॉमी का मतलब कम लोग हैं?
इसका मतलब है अलग तरह का काम। मशीनी हिस्सा सिकुड़ता है और विवेक वाला हिस्सा ही असली काम बन जाता है।
हमें कैसे पता चले कि यह सिर्फ़ शोर नहीं पैदा कर रहा?
प्लान पढ़िए, जो मायने नहीं रखता उसे हटाइए, और टेस्ट की गिनती के बजाय बचकर निकल गए डिफ़ेक्ट मापिए।
स्तर तीन पर क्या टूटता है?
जानबूझकर किए गए बदलाव। नए सिरे से डिज़ाइन किया गया फ़्लो बिल्कुल रिग्रेशन जैसा दिखता है, जब तक कोई यह न बताए कि ऐसा नहीं है।
क्या क्लोज़्ड लूप सुरक्षित है?
ऐसे बिहेवियरल डिफ़ेक्ट के लिए जिन्हें साफ़ तौर पर दोहराया जा सके और जिनके लिए आपने पुष्टि कर ली हो कि चेक फ़ेल हो सकता है — हाँ। इससे आगे यह बस उम्मीद है।
एक सीढ़ी, स्विच नहीं।
ऑटोनॉमस सॉफ़्टवेयर टेस्टिंग सहायता-आधारित टेस्ट लेखन से लेकर क्लोज़्ड लूप तक फैली है, और ज़्यादातर प्रोडक्ट जनरेट किए गए कवरेज पर टिके हैं। इंसानी काम ग़ायब नहीं होता, सीढ़ी पर ऊपर चढ़ जाता है, और कोई भी स्तर इस ज़रूरत को नहीं मिटाता कि 'सही' का मतलब क्या है, यह तय किया जाए।