आपसे ऐसा feature टेस्ट करने को कहा गया है जिसकी कोई लिखित requirement नहीं है। आप कैसे आगे बढ़ते हैं?

किसी के आने का इंतजार करने की जगह टेस्ट करते करते specification खुद बनाइए। जिसने यह मांगा उससे मंशा जानिए, तौर तरीकों के लिए मिलते जुलते मौजूदा features देखिए, feature को खंगालकर उसका असली behavior नक्शे पर लाइए, और जो मिले उसे टेस्ट किए जा सकने वाले वाक्यों में लिखिए। फिर उन्हें product owner से पक्का करवाइए, ताकि उलझनें release के बाद विवादित bugs की जगह पहले सवालों की तरह सामने आएं।

मैं न किसी दस्तावेज का इंतजार करता हूं और न बस अंदाजा लगाता हूं, क्योंकि अंदाजा लगाने का मतलब है कि हर खोज इस बहस में बदल जाएगी कि यह bug है या नहीं। मैं मंशा वहीं से ढूंढना शुरू करता हूं जहां वह मौजूद हो: ticket, design mock, कोई chat की लड़ी, pull request का ब्योरा, और जिसने feature मांगा उसके साथ दस मिनट की बातचीत, जिसमें मैं इस सवाल से शुरू करता हूं कि यह user की कौन सी समस्या हल करता है। फिर मैं उसी product के मिलते जुलते features देखता हूं, क्योंकि एकरूपता खुद एक requirement है और ऐसी नई screen जो बाकी हर screen से अलग तरीके से validate करती है, defect है चाहे कोई दस्तावेज कुछ भी कहे। फिर मैं feature खंगालता हूं और लिखता हूं कि वह असल में क्या करता है, टेस्ट किए जा सकने वाले वाक्यों में। वह एक छोटी specification बन जाती है, आम तौर पर करीब एक पन्ना, और मैं उसे उलझनें चिह्नित करके वापस भेजता हूं: जब मात्रा stock से ज्यादा हो जाए, तो यह रोकता है या चेतावनी देता है? दस में नौ बार product owner एक घंटे के भीतर जवाब देता है, और अब हमारे पास release से पहले सही की एक साझा परिभाषा है, बाद का विवाद नहीं। इससे अगले tester के लिए भी कुछ बच जाता है जिससे वह शुरू कर सके।