एक अच्छा acceptance criterion किससे बनता है, और आप उन्हें कैसे लिखते हैं?

अच्छा criterion टेस्ट करने लायक, ठोस और implementation की डिटेल से मुक्त होता है। कोई उसे पढ़े और बिना कुछ अपने हिसाब से समझे pass या fail कह सके। negative path उतनी ही सोच समझकर कवर करें जितना happy path: गलत input, permission की कमी, timeout, खाली result। अगर आप बता नहीं सकते कि इसे टेस्ट कैसे करेंगे, तो वह अभी criterion नहीं, एक उम्मीद है।

मेरा टेस्ट यह है कि कोई इसे पढ़कर मुझसे एक भी सवाल पूछे बिना pass या fail कर सके। अगर उसमें कुछ भी अपने हिसाब से समझने को बचा है, तो वह पूरा नहीं हुआ। इसलिए मैं उपयुक्त, यूजर फ्रेंडली और जल्दी जैसे शब्दों से बचता हूं और उनकी जगह ऐसी चीज लिखता हूं जिसे सच में जांचा जा सके। काम का आधा हिस्सा negative path हैं, और ज्यादातर defect वहीं से आते हैं। गलत input पर क्या होता है, बिना permission वाले यूजर को क्या दिखता है, downstream service के timeout होने पर क्या होता है, खाली result कैसा दिखता है। ये ऐसे फैसले हैं जो किसी को लेने ही हैं, और अगर मैं इन्हें बिज़नेस के साथ नहीं लूंगा तो कोई डेवलपर गुरुवार दोपहर जल्दी जल्दी ले लेगा। काम उठाए जाने से पहले मैं criteria एक डेवलपर और एक टेस्टर के साथ चलकर देख भी लेता हूं। इसमें बीस मिनट लगते हैं और हर बार दो तीन ऐसी चीजें निकलती हैं जिन्हें मैंने अधूरा छोड़ा था।