अपने AI से बने app को कैसे टेस्ट करें, जब आपने पहले कभी software टेस्ट नहीं किया

आपने AI से एक app बनाया। यह happy path पर काम करता है — आप अपना नाम टाइप करते हैं, बटन क्लिक करते हैं, success screen देखते हैं। अब क्या? क्या यह आपके तीन beta users को भेजने लायक है? आपकी team को? आपके customers को?

अगर आपके पास कोई software background नहीं है, तो testing उन चीज़ों में से एक लगती है जो “असली developers” करते हैं — frameworks, assertions, और CI pipelines के साथ। अच्छी ख़बर: ज़्यादातर testing असल में वो नहीं है। ज़्यादातर testing, ख़ास तौर पर जब आप कुछ छोटा और नया शिप कर रहे हों, बस एक इंसान का इरादे के साथ इधर-उधर क्लिक करना है। आप यह कर सकते हैं। यह post उसे जान-बूझकर करने के बारे में है, ताकि आप bugs अपने users से पहले ढूंढ लें।

मक़सद अपने AI से बने app को किसी प्रो की तरह टेस्ट करना नहीं है। मक़सद इसे एक शक्की दोस्त की तरह टेस्ट करना है जो सचमुच चाहता है कि यह काम करे।

दो-सूची वाली तरकीब

कुछ भी क्लिक करने से पहले, एक खाली doc के साथ दस मिनट बैठें और दो सूचियां लिखें।

सूची A — happy paths. वो तीन-चार चीज़ें क्या हैं जो एक user को इस app के साथ करनी चाहिए? एक आम SaaS के लिए वो हो सकती हैं: sign up करना, अपना पहला project बनाना, एक teammate को invite करना, एक result export करना। एक directory-जैसे app के लिए: search करना, filter करना, एक listing पर क्लिक करना, उसे save करना। तीन-चार असली flows, आसान भाषा में।

सूची B — unhappy paths. क्या हो अगर user कुछ लगभग सही करे पर बिल्कुल सही नहीं? अपना email टाइपो के साथ टाइप करता है। flow के बीच में back बटन दबाता है। दो tabs खोलकर दोनों में एक ही चीज़ edit करता है। एक खाली form submit करता है। किसी Word doc का content—formatting समेत—एक text field में पेस्ट करता है। laptop बंद करके दस मिनट बाद दोबारा खोलता है। एक ऐसे email address से teammate को invite करने की कोशिश करता है जो पहले से system में मौजूद है।

happy-path सूची वो है जिसके लिए आपके AI app builder ने optimize किया। यही वो है जिसे AI ने कोड लिखते वक़्त मन ही मन टेस्ट किया। unhappy-path सूची वो है जहां bugs रहते हैं, क्योंकि लगभग किसी ने—न AI ने, न आपने जब आप prompt कर रहे थे—उन हालात के बारे में नहीं सोचा था।

जब आप सचमुच टेस्ट करें, तो पहले सूची A से गुज़रें ताकि बुनियादी चीज़ें काम करना पक्का हो जाए। फिर अपना ज़्यादातर वक़्त सूची B पर लगाएं। सूची B ही वो है जहां असल कीमत है। सूची B ही वो है जहां आपको पता चलता है कि जब चीज़ें टेढ़ी हो जाएं तो आप असल में चाहते क्या हैं कि app करे, जो अक्सर AI builder के साथ एक साफ़-सफ़ाई वाली बातचीत मजबूर करता है (“जब form आधा-भरा हो, तो उसे चेताना चाहिए या autosave करना चाहिए?”)।

तीन चीज़ें जो जान-बूझकर तोड़ें

जब आपकी सूचियां तैयार हों, तो यहां तीन श्रेणियां हैं जो AI से बने apps में ज़्यादातर असली bugs पकड़ती हैं।

खाली और अजीब inputs. form को बिना कुछ भरे submit करें। एक ही field भरकर submit करें। 500 characters लंबा एक नाम submit करें। emoji वाला एक नाम submit करें। नाम की उम्मीद करने वाले field में एक URL पेस्ट करें। email field को “test” से आज़माएं, “test@” से, “test@example” से, “a@b.co” address से — क्या यह जायज़ छोटे emails स्वीकार करता है? AI app builders अक्सर validation जोड़ देते हैं, पर validation दोनों दिशाओं में गलत हो सकती है — हद से ज़्यादा सख़्त (असली users को नकार दे) या हद से ज़्यादा ढीली (कचरा स्वीकार कर ले)।

पीछे और बग़ल में जाना. ज़्यादातर apps ठीक चलते हैं अगर आप उनमें से किसी आज्ञाकारी पर्यटक दल की तरह गुज़रें। वो उसी पल टूट जाते हैं जब कोई खोजबीन करता है। back बटन क्लिक करें। फिर forward क्लिक करें। flow के बीच में page refresh करें। एक ही page दो tabs में खोलें और दोनों पर edit करें। logout करके दोबारा login करें। अगर आपके पास “undo” बटन है, तो उसे लगातार तीन बार क्लिक करें। ये edge cases नहीं हैं। यही वो तरीका है जिससे असली लोग software इस्तेमाल करते हैं।

बाद का data. वो चीज़ बनाएं जो आपका app बनाता है। एक project, एक post, एक record, जो भी हो। फिर कल वापस आएं। क्या वो अब भी वहां है? क्या formatting बची? अगर आप उसे edit करते हैं, तो क्या edit save होता है? अगर आप उसे delete करते हैं, तो क्या वो सचमुच गया, या refresh करने पर वापस आ जाता है? AI app builders अक्सर “create” flow को पक्का कर देते हैं और भूल जाते हैं कि जो भी आप बनाते हैं उसे टिकना और बाद में edit होने लायक होना ज़रूरी है।

“काफ़ी अच्छा” कैसा दिखता है

आप अपने AI से बने app को परफ़ेक्शन तक कभी टेस्ट नहीं कर पाएंगे। Software बहुत उलझा हुआ है और आपका वक़्त बहुत कीमती। सवाल “क्या यह परफ़ेक्ट है” नहीं है — सवाल है “क्या यह अगले समूह के लिए काफ़ी अच्छा है जिसके सामने मैं इसे रखने जा रहा हूं।”

यह रहा एक मोटा-मोटा क्रम जो आप उधार ले सकते हैं।

Demo के लिए काफ़ी अच्छा: happy path बिना crash हुए काम करता है। बटन वहीं जाते हैं जहां जाने चाहिए। आप बिना कुछ काटे एक screen recording दिखा सकते हैं।

दोस्ताना users के लिए काफ़ी अच्छा: unhappy paths data नहीं खोते। Forms आपको बताते हैं कि क्या गलत है, चुपचाप नाकाम होने के बजाय। page refresh करने से चीज़ें नहीं टूटतीं। तीन दोस्त इसे आपको message किए बिना इस्तेमाल कर सकते हैं।

Paying users के लिए काफ़ी अच्छा: app उन users को संभालता है जिनसे आप कभी मिले नहीं। उनके browsers, उनका data, उनकी आदतें। आपके पास यह देखने का कोई तरीका है कि चीज़ें कब टूटती हैं (बुनियादी error tracking काफ़ी है — आपको किसी फ़ैंसी dashboard की ज़रूरत नहीं)। आप पहले से इस्तेमाल कर रहे लोगों को तोड़े बिना fix करके redeploy कर सकते हैं।

ज़्यादातर builders “दोस्ताना users” वाले स्तर पर शिप करते हैं और फिर जैसे-जैसे feedback आता है, upgrade करते हैं। यह सही है। गलती है बीच वाले कदम के बिना “demo के लिए काफ़ी अच्छा” से सीधे “paying users के लिए काफ़ी अच्छा” तक कूदने की कोशिश करना। दोस्ताना users वो चीज़ें ढूंढ लेते हैं जो असली users ढूंढते — पर वो उन पर गुस्सा नहीं होते। उस अंतर का फ़ायदा उठाएं।

AI से अपने लिए कब टेस्ट करवाएं

आपका AI app builder testing में मदद कर सकता है, पर आपको यह बताने में ख़ास होना पड़ेगा कि आप क्या चाहते हैं। “Add tests” एक खराब prompt है। यह ऐसा कोड बना देगा जो tests जैसा दिखता है और शायद पास भी हो जाए, बिना उस चीज़ को सचमुच जांचे जिसकी आपको परवाह है। उन autogenerated tests में से ज़्यादातर बस यह पक्का करते हैं कि 1+1 अब भी 2 है।

एक बेहतर prompt: “मैंने अभी signup form को खाली email field के साथ submit करने की कोशिश की और यह crash हो गया। ढूंढो कि वो कहां संभाला जाता है और एक check जोड़ो जो उसके बजाय एक दोस्ताना error दिखाए।” ख़ास bug, ख़ास fix, ख़ास नतीजा। AI इसमें अच्छा है। यह “पक्का करो कि मेरा app bug-free है” में खराब है क्योंकि वो कोई task नहीं है — वो एक ख़्वाहिश है।

दूसरी चीज़ जिसमें AI builders अच्छे हैं वो है आपके bug को दोहराना। अगर आप बताएं कि आपने क्या किया, क्या उम्मीद की, और क्या हुआ, तो builder आमतौर पर कोड में से रास्ता ढूंढकर एक fix सुझा सकता है। जो अनुशासन आपको चाहिए वो है उन तीन चीज़ों को साफ़-साफ़ लिखने का अनुशासन। ज़्यादातर शुरुआती bug reports किसी न किसी रूप में “यह काम नहीं करता” होते हैं। ज़्यादातर ठीक होने लायक bug reports “मैंने X क्लिक किया, Y की उम्मीद की, Z मिला” होते हैं।

Testing पढ़ना है, सिर्फ़ क्लिक करना नहीं

एक आख़िरी बात। आपको अपने AI से बने app की हर लाइन कोड समझने की ज़रूरत नहीं ताकि आप उसे अच्छे से टेस्ट कर सकें। पर आपको कम से कम सरसरी तौर पर देखना चाहिए। वो file खोलें जो AI ने अभी बदली। उसने जो function जोड़ा उसे पढ़ें। आपको यह जानने की ज़रूरत नहीं कि हर keyword का क्या मतलब है — आपको यह जानना है कि function वो कर रहा लग रहा है या नहीं जो आपने मांगा था।

AI से बने बहुत-से bugs “कोड टूटा है” नहीं होते। वो “कोड वो करता है जो आप चाहते थे उससे थोड़ा अलग है” होते हैं। एक field गलत जगह save होती है। एक बटन एक चीज़ अपडेट करता है पर जुड़ी हुई चीज़ नहीं। एक “delete” बटन delete करने के बजाय छिपा देता है। आप इन्हें पकड़ नहीं सकते जब तक आप यह न पढ़ें कि असल में क्या बना।

कोड को कुछ ऐसा मानें जिसका आप audit कर सकते हैं, कुछ ऐसा नहीं जिसे आपको लिखना पड़े। यही उस AI से बने app के बीच का फ़र्क है जिस पर आप भरोसा करते हैं और उस वाले के बीच जिसके बस काम करने की उम्मीद करते हैं।

आसान वाला version

अगर आपको और कुछ याद न रहे: दो सूचियां लिखें, चीज़ें जान-बूझकर तोड़ें, और तय करें कि आप किस “काफ़ी अच्छा” स्तर पर शिप कर रहे हैं। AI से बने app में ज़्यादातर bugs बारीक नहीं होते। वो उसी unhappy-path सूची पर बैठे हैं जिसे लिखने की ज़हमत किसी ने नहीं उठाई।

अगर आपको एक छोटा homework चाहिए: एक app चुनें जो आपने बनाया है और चार चीज़ें आज़माएं — एक खाली form submit करें, flow के बीच में refresh दबाएं, एक record edit करके कल जांचें, और एक दोस्त से कहें कि वो इसे आपके देखे बिना इस्तेमाल करे। जो भी टूटे, वही आपकी असली bug सूची है। बाकी सब टालमटोल है।