नॉन-डेवलपर सॉफ़्टवेयर टेस्टिंग वह क्या पकड़ती है जो रिव्यू नहीं पकड़ पाता
झूठ
सफलता का मैसेज दिखता है, पर सेव कुछ भी नहीं हुआ। कोड पढ़ने से इरादा पता चलता है, नतीजा नहीं।
उलझन
एक ऐसा फ़्लो जो तकनीकी रूप से काम करता है और जिसे कोई पूरा नहीं कर पाता। यह सिर्फ़ इंसान को दिखता है।
धारणा
जिस अकाउंट ने इसे बनाया उसके लिए चलता है, बाक़ी सबके लिए फ़ेल हो जाता है।
जिसके पास वह पहला अकाउंट है, उसे दिखाई ही नहीं देता।
चार जाँचें जिनके लिए कोड की ज़रूरत नहीं
कोई काम कीजिए, फिर रीलोड कीजिए। यह “स्क्रीन अपडेट हो गई” और “सेव हो गया” के बीच फ़र्क़ कर देता है। इससे ज़्यादा फ़ायदेमंद जाँच कोई नहीं।
वही काम किसी और बनकर कीजिए। दूसरा अकाउंट परमिशन से जुड़ी धारणाओं को तुरंत पकड़ लेता है।
जान-बूझकर ग़लत कीजिए। कोई अमान्य जानकारी सबमिट कीजिए और देखिए कि ऐप चुपचाप फ़ेल होने के बजाय साफ़-साफ़ बताता है या नहीं।
बिना कुछ डाले कीजिए। एम्प्टी स्टेट सबसे आख़िर में बनते हैं और उनकी टेस्टिंग सबसे कम होती है।
ऐसी रिपोर्ट लिखना जो ठीक की जाए
तीन वाक्य, और किसी तकनीकी शब्दावली की ज़रूरत नहीं। आपने क्या किया, क्रम से। आपको क्या उम्मीद थी। उसकी जगह क्या हुआ। “मैंने फ़ॉर्म भरा और सेव दबाया, मुझे उम्मीद थी कि आइटम लिस्ट में दिखेगा, लिस्ट तब तक ख़ाली रही जब तक मैंने रीलोड नहीं किया” — यह सीधे ख़ामी की तरफ़ इशारा करता है और इसे समझाने की कोई ज़रूरत नहीं पड़ती।
यह अपने आप में एक जाँच भी है। एक बार लिख दी जाए, तो यह आगे हर बदलाव के बाद चल सकती है।
जब आपकी रिपोर्ट पर कोई कार्रवाई न हो, तब क्या करें
इस भूमिका में सबसे आम झुँझलाहट यही है — कोई असली दिक़्क़त पकड़ना और फिर उसे यूँ ही पड़े हुए देखते रहना। आमतौर पर समस्या यह नहीं होती कि कोई आप पर यक़ीन नहीं करता, बल्कि यह कि रिपोर्ट में इतना होता ही नहीं कि कोई काम शुरू कर सके।
तीन चीज़ें यह खाई पाट देती हैं। बताइए कि कौन-सा अकाउंट और कौन-सा एनवायरनमेंट था, क्योंकि जो बग सिर्फ़ एक तरह के यूज़र के साथ होता है, वह अलग बग है। बताइए कि यह हर बार होता है या कभी-कभी, क्योंकि रुक-रुक कर होने वाली और लगातार होने वाली दिक़्क़तों की वजहें बिलकुल अलग होती हैं और यह जान लेने भर से एक घंटा बच जाता है। और साफ़-साफ़ बताइए कि आपको क्या उम्मीद थी, क्योंकि आधी बार असहमति कोड को लेकर नहीं, ज़रूरत को लेकर निकलती है, और उसे जल्दी सामने ले आना फ़ायदेमंद है।
इसमें से किसी के लिए भी तकनीकी शब्दावली की ज़रूरत नहीं। यही फ़र्क़ है उस रिपोर्ट में जो सिर्फ़ छाँटकर रख दी जाती है और उस रिपोर्ट में जो ठीक की जाती है।
जाँचों को अपने से ज़्यादा टिकाऊ बनाना
नॉन-डेवलपर टेस्टिंग की सीमा कभी हुनर नहीं रही, सीमा यह है कि एक इंसान एक हद तक ही बार-बार जाँच सकता है। फ़्लो को सीधी-सादी भाषा में लिखकर उसे अपने आप चलवा देना इस छत को हटा देता है, और इसके लिए किसी को कोई फ़्रेमवर्क सीखने की ज़रूरत नहीं पड़ती।
इसमें से किसी के लिए टर्मिनल की ज़रूरत नहीं। TestSprite डैशबोर्ड में एक प्रोजेक्ट बनाइए, जाँच को सीधी भाषा में लिखिए, और उसे अपने ऐप पर लगा दीजिए। आपकी टीम के डेवलपर चाहें तो यही काम कमांड लाइन से भी कर सकते हैं; इसके लिए देखिए CLI रिपॉज़िटरी।
दो रास्ते हैं, और चुनाव असल में इस बात का है कि पाइपलाइन किसके पास है। डैशबोर्ड से GitHub App जोड़ने पर आपकी रिपॉज़िटरी में कोई बदलाव करने की ज़रूरत ही नहीं पड़ती, क्योंकि यह उसी डिप्लॉयमेंट पर प्रतिक्रिया देता है जो आपका बिल्ड पहले से निकालता है। वहीं एक GitHub Actions स्टेप जोड़ने से जाँच रिपॉज़िटरी के भीतर आ जाती है, जहाँ बाक़ी बिल्ड की तरह उसका भी रिव्यू होता है।
TestSprite आपकी जाँचों को स्थायी कैसे बना देता है
आप फ़्लो को वैसे ही लिखते हैं जैसे किसी सहकर्मी को समझाते, और TestSprite उसे ऐप पर चलाकर देखता है। न कोई टेस्ट कोड, न फ़्रेमवर्क, न टर्मिनल। डैशबोर्ड में प्रोजेक्ट बनाइए, उसे अपने प्रोडक्ट पर लगाइए, और वही तीन वाक्य लिखिए: आपने क्या किया, आपको क्या उम्मीद थी, और उसके बाद क्या सही होना चाहिए।
उसके बाद यह हर बदलाव पर चलती है। इस पेज की चारों जाँचें हाथ से दोहराई जाने वाली चीज़ नहीं रहतीं, वे एक ऐसा रिकॉर्ड बन जाती हैं जो आपके किसी और काम में लगे रहने के दौरान भी चलता रहता है।
फ़ायदा बिलकुल ठोस है: क्या होना चाहिए, यह जानकारी सिर्फ़ आपके दिमाग़ में रहना बंद कर देती है — और यही चीज़ आपके योगदान को बाक़ी सबके सामने दिखने लायक़ बनाती है और आपके अगले काम पर चले जाने के बाद भी टिकाऊ रखती है।
क्या मुझे कोडिंग सीखनी पड़ेगी?
नहीं। फ़्लो को सीधी-सादी भाषा में लिख दीजिए। आपकी असली देन यह जानना है कि क्या होना चाहिए, और वह कोडिंग का हुनर नहीं है।
मुझे कैसे पता चलेगा कि मेरी जाँच असली है?
जान-बूझकर उस चीज़ को तोड़िए और पक्का कीजिए कि जाँच फ़ेल होती है। एक मिनट लगता है, और यही इकलौता सबूत है कि वह किसी चीज़ से जुड़ी हुई भी है।
अगर डेवलपर मेरी रिपोर्ट को ख़ारिज कर दें तो?
वही तीन वाक्य इस्तेमाल कीजिए। उम्मीद के साथ दिया गया एक ठोस क्रम “यह टूटा हुआ है” के मुक़ाबले कहीं ज़्यादा मुश्किल से ख़ारिज होता है।
मुझे बदलाव से पहले टेस्ट करना चाहिए या बाद में?
दोनों। जो जाँच पहले से मौजूद थी, वही बताती है कि बदलाव ने कुछ तोड़ा या नहीं, और यही ज़्यादा क़ीमती दिशा है।
जाँचने के लिए सबसे अच्छी एक चीज़ क्या है?
कुछ कीजिए, फिर रीलोड कीजिए। बाक़ी किसी भी जगह से ज़्यादा प्रोडक्ट यहीं फ़ेल होते हैं, और इसमें पाँच सेकंड लगते हैं।
यहाँ कोड न पढ़ पाना एक फ़ायदा है।
नॉन-डेवलपर सॉफ़्टवेयर टेस्टिंग झूठ, उलझन और धारणा — इन तीनों को पकड़ती है, और ये वही तीन चीज़ें हैं जिन्हें कोड रिव्यू संरचनात्मक रूप से देख ही नहीं सकता। रीलोड कीजिए, दूसरा अकाउंट इस्तेमाल कीजिए, जान-बूझकर ग़लत कीजिए, ख़ाली छोड़कर कीजिए, और जाँचों को लिख डालिए ताकि वे उस सेशन के बाद भी टिकी रहें।