31 ਦਸੰ 2025·8 ਮਿੰਟ
ਪ੍ਰੌਂਪਟ ਤੋਂ ਸਵੀਕਾਰਤਾ ਟੈਸਟ: ਫੀਚਰਾਂ ਨੂੰ ਸਕੇਨਾਰੀਓਜ਼ ਵਿੱਚ ਬਦਲੋ
ਹਰ ਫੀਚਰ ਪ੍ਰੌਂਪਟ ਨੂੰ 5-10 ਸਪਸ਼ਟ acceptance ਸਕੇਨਾਰੀਓਜ਼ ਵਿੱਚ ਬਦਲ ਕੇ ਹੈਪੀ ਪਾਥ ਅਤੇ ਏਜ ਕੇਸ ਕਵਰ ਕਰੋ—ਬੇਹਦ ਵੱਡੇ ਟੈਸਟ ਸੂਟਾਂ ਦੀ ਲੋੜ ਨਹੀਂ।
ਹਰ ਫੀਚਰ ਪ੍ਰੌਂਪਟ ਨੂੰ 5-10 ਸਪਸ਼ਟ acceptance ਸਕੇਨਾਰੀਓਜ਼ ਵਿੱਚ ਬਦਲ ਕੇ ਹੈਪੀ ਪਾਥ ਅਤੇ ਏਜ ਕੇਸ ਕਵਰ ਕਰੋ—ਬੇਹਦ ਵੱਡੇ ਟੈਸਟ ਸੂਟਾਂ ਦੀ ਲੋੜ ਨਹੀਂ।
Chat-ਸਟਾਈਲ ਫੀਚਰ ਪ੍ਰੌਂਪਟ ਗੱਲਬਾਤ ਵਾਂਗ ਲਗਦੇ ਹਨ, ਇਸ ਲਈ ਸਪੱਸ਼ਟ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ। ਪਰ ਉਹ ਅਕਸਰ ਚੋਣਾਂ, ਨਿਯਮ ਅਤੇ ਛੁਟਕਾਰਿਆਂ ਨੂੰ ਕੁਝ ਦੋਸਤਾਨਾ ਵਾਕਾਂ ਵਿੱਚ ਸੰਕੁਚਿਤ ਕਰ ਦਿੰਦੇ ਹਨ। ਜਦ ਤਕ ਕੋਈ ਵਿਅਕਤੀ ਫੀਚਰ ਨੂੰ ਅਸਲ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਵਰਤਦਾ ਨਹੀਂ, ਇਹ ਖਾਮੀਆਂ ਸਾਹਮਣੇ ਨਹੀਂ ਆਉਂਦੀਆਂ।
ਜ਼ਿਆਦਾਤਰ ਪ੍ਰੌਂਪਟ ਚੁਪਕੇ-ਚੁਪਕੇ ਧਾਰਣਾਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ: ਕੌਣ ਇਹ ਕਾਰਵਾਈ ਕਰਨ ਦੀ ਆਗਿਆ ਰੱਖਦਾ ਹੈ, “ਸਫਲਤਾ” ਦੀ ਕੀ ਪਰਿਭਾਸ਼ਾ ਹੈ (ਸੇਵ, ਭੇਜਿਆ, ਪ੍ਰਕਾਸ਼ਿਤ, ਭੁਗਤਾਨ), ਜਦ ਡੇਟਾ ਗਾਇਬ ਹੋਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਜਦ ਕੁਝ ਫੇਲ ਹੁੰਦਾ ਹੈ ਤਾਂ ਉਪਭੋਗੀ ਨੂੰ ਕੀ ਦਿਖਾਈ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਹ ਧੁੰਦਲੇ ਮਾਪਦੰਡ ਵੀ ਛੁਪਾਉਂਦੇ ਹਨ, ਜਿਵੇਂ “ਕਿੰਨਾ ਤੇਜ਼” ਜਾਂ “ਕਿੰਨਾ ਸੁਰੱਖਿਅਤ” ਕਾਫ਼ੀ ਹੈ।
ਅਸਪਸ਼ਟਤਾ ਆਮ ਤੌਰ 'ਤੇ ਬਾਅਦ ਵਿੱਚ ਬਗ ਅਤੇ ਰੀਵਰਕ ਦੇ ਰੂਪ ਵਿੱਚ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ। ਡਿਵੈਲਪਰ ਉਹ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਉਹ ਸੋਚਦਾ ਹੈ ਕਿ ਪ੍ਰੌਂਪਟ ਦਾ ਮਤਲਬ ਹੈ, ਰਿਵਿਊਅਰ ਇਸਨੂੰ ਠੀਕ ਲੱਗਣ 'ਤੇ ਮਨਜ਼ੂਰ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਯੂਜ਼ਰ ਅਜਿਹੇ ਕੇਸਾਂ ਵਿੱਚ ਫਸਦੇ ਹਨ: ਡੁਪਲਿਕੇਟ ਸਬਮਿਸ਼ਨ, ਟਾਈਮ ਜ਼ੋਨ, ਅਧੂਰਾ ਡੇਟਾ, ਜਾਂ ਅਧਿਕਾਰ ਨਾਲ ਮੇਲ ਨਾ ਖਾਣਾ। ਬਾਅਦ ਵਿੱਚ ਠੀਕ ਕਰਨ ਦੀ ਕੀਮਤ ਵੱਧਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਅਕਸਰ ਕੋਡ, UI ਟੈਕਸਟ, ਅਤੇ ਕਈ ਵਾਰੀ ਡੇਟਾ ਮਾਡਲ ਨੂੰ ਛੇੜਦਾ ਹੈ।
ਗੁਣਵੱਤਾ ਵੱਡੇ ਟੈਸਟ ਸੂਟ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦੀ। ਇਸ ਦਾ ਅਰਥ ਹੈ ਕਿ ਤੁਸੀਂ ਆਮ ਵਰਤੋਂ ਅਤੇ ਪ੍ਰਿਡਿਕਟੇਬਲ ਸਟ੍ਰੈਸ ਹੇਠਾਂ ਫੀਚਰ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹੋ। ਕੁਝ ਚੁਣੀ ਹੋਈ ਸਕੇਨਾਰੀਓਜ਼ ਤੁਸੀਂ ਇਹ ਭਰੋਸਾ ਦਿੰਦੇ ਹਨ ਬਿਨਾਂ ਸੈਂਕੜਿਆਂ ਟੈਸਟਾਂ ਦੇ।
ਪ੍ਰੈਕਟਿਕਲ ਗੁਣਵੱਤਾ ਦੀ ਪਰਿਭਾਸ਼ਾ ਜਦ ਪ੍ਰੌਂਪਟ-ਅਧਾਰਿਤ ਫੀਚਰ ਬਣਾਏ ਜਾਂਦੇ ਹਨ:
ਇਹੀ ਪ੍ਰੌਂਪਟ ਨੂੰ acceptance scenarios ਵਿੱਚ ਬਦਲਣ ਦਾ ਮਕਸਦ ਹੈ: ਇੱਕ ਧੁੰਦਲੀ ਮੰਗ ਨੂੰ ਲਓ ਅਤੇ ਉਸਨੂੰ 5-10 ਚੇਕਾਂ ਵਿੱਚ ਬਦਲੋ ਜੋ ਲੁਕੀਆਂ ਨਿਯਮਾਂ ਨੂੰ ਅਗੇ ਹੀ ਉਜਾਗਰ ਕਰਨ। ਤੁਸੀਂ ਹਰ ਚੀਜ਼ ਦੀ ਟੈਸਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਹੇ; ਤੁਸੀਂ ਉਹ ਫੇਲ੍ਹ ਕੈਚ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ ਜੋ ਅਸਲ ਵਿੱਚ ਹੋਣ ਗੈ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ vibe-coding ਟੂਲ ਵਿੱਚ ਇੱਕ ਝਟਪਟ ਪ੍ਰੌਂਪਟ ਤੋਂ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਆਉਟਪੁੱਟ ਪੂਰਨ ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਫਿਰ ਵੀ ਏਜ ਰੂਲ ਸਕਿਪ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਟਾਈਟ ਸਕੇਨਾਰੀਓ ਸੈੱਟ ਉਹਨਾਂ ਨਿਯਮਾਂ ਨੂੰ ਨਾਮਿਤ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ ਜਦ ਤਕ ਭਾਅ ਘੱਟ ਹੁੰਦਾ ਹੈ।
ਇੱਕ acceptance test ਸਕੇਨਾਰੀਓ ਇੱਕ ਛੋਟੀ, ਸਧਾਰਣ-ਭਾਸ਼ਾ ਵਰਣਨਾ ਹੁੰਦੀ ਹੈ ਇੱਕ ਉਪਭੋਗੀ ਦੀ ਕਾਰਵਾਈ ਅਤੇ ਨਤੀਜੇ ਦੀ ਜੋ ਉਹ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ।
ਸਰਫ਼ ਉਪਭੋਗੀ-ਮੁੱਖ ਗੱਲ 'ਤੇ ਰਹੋ: ਉਪਭੋਗੀ ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਤਪਾਦ ਕੀ ਦਿਖਾਉਂਦਾ ਜਾਂ ਬਦਲਦਾ ਹੈ। ਡੇਟਾਬੇਸ ਟੇਬਲਾਂ, API ਕਾਲਾਂ, ਬੈਕਗ੍ਰਾਊਂਡ ਜ਼ਾਬਸ ਜਾਂ ਕਿਸ ਫਰੇਮਵਰਕ ਦੀ ਵਰਤੋਂ ਹੋ ਰਹੀ ਹੈ ਵਰਗੀ ਅੰਦਰੂਨੀ ਵਿਸਥਾਰੋਂ ਤੋਂ ਬਚੋ। ਉਹ ਵਿਸਥਾਰ ਬਾਅਦ ਵਿੱਚ ਮਾਇਨੇ ਰੱਖ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਸਕੇਨਾਰੀਓਜ਼ ਨੂੰ ਨਾਜ਼ੁਕ ਅਤੇ ਸਹਿਮਤ ਹੋਣ ਦੇ ਕਾਬਿਲ ਨਹੀਂ ਬਨਾਉਂਦੇ।
ਇੱਕ ਵਧੀਆ ਸਕੇਨਾਰੀਓ ਸੁਤੰਤਰ ਵੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਅਗਲੇ ਦਿਨ ਸਾਫ਼ ਪਰੀਬੇਸ਼ 'ਤੇ ਆਸਾਨੀ ਨਾਲ ਚਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਬਿਨਾਂ ਕਿਸੇ ਹੋਰ ਸਕੇਨਾਰੀਓ ਦੇ ਚੱਲਣ 'ਤੇ ਨਿਰਭਰ ਹੋਏ। ਜੇ ਕੋਈ ਸਕੇਨਾਰੀਓ ਪਹਿਲਾਂ ਦੀ ਸਥਿਤੀ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਸੈਟਅਪ ਵਿੱਚ ਸਾਫ਼ ਲਿਖੋ (ਉਦਾਹਰਨ ਲਈ, “ਉਪਭੋਗੀ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ active subscription ਹੈ”)।
ਕਈ ਟੀਮਾਂ Given-When-Then ਵਰਤਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਇਹ ਰੂਪ ਸਪਸ਼ਟਤਾ ਮਜਬੂਰ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਸਕੇਨਾਰੀਓਜ਼ ਨੂੰ ਪੂਰੇ ਸਪੇਕ ਵਿੱਚ ਬਦਲਣ ਦੇ।
ਇੱਕ ਸਕੇਨਾਰੀਓ ਆਮ ਤੌਰ 'ਤੇ “ਖਤਮ” ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਉਸਦਾ ਇੱਕ ਲਕੜੀ ਹੁੰਦਾ ਹੈ, ਇੱਕ ਸਪਸ਼ਟ ਸ਼ੁਰੂਆਤੀ ਸਥਿਤੀ, ਇੱਕ ਠੋਸ ਕਾਰਵਾਈ, ਅਤੇ ਇੱਕ ਦ੍ਰਿਸ਼ਯ ਨਤੀਜਾ। ਇਹ ਬਾਈਨਰੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਟੀਮ ਦਾ ਕੋਈ ਵੀ ਮੈਂਬਰ ਚਲਾ ਕੇ ਕਹਿ ਸਕੇ “ਪਾਸ” ਜਾਂ “ਫੇਲ”।
ਉਦਾਹਰਨ: “Given a signed-in user with no saved payment method, when they choose Pro and confirm payment, then they see a success message and the plan shown as Pro in their account.”
ਜੇ ਤੁਸੀਂ ਕਿਸੇ chat-first builder ਜਿਵੇਂ Koder.ai ਵਿੱਚ ਬਣਾਉਂਦੇ ਹੋ, ਉਹੀ ਨਿਯਮ ਰੱਖੋ: generated app ਦੇ ਵਿਹਾਰ ਨੂੰ ਟੈਸਟ ਕਰੋ (ਉਪਭੋਗੀ ਜੋ ਅਨੁਭਵ ਕਰਦਾ ਹੈ), ਨਾ ਕਿ ਪਲੈਟਫਾਰਮ ਨੇ ਕੋਡ ਕਿਸ ਤਰ੍ਹਾਂ ਪੈਦਾ ਕੀਤਾ।
ਸਭ ਤੋਂ ਵਧੀਆ ਫਾਰਮੈਟ ਉਹ ਹੈ ਜੋ ਲੋਕ ਲਿਖਣ ਅਤੇ ਪੜ੍ਹਨਗੇ। ਜੇ ਟੀਮ ਦਾ ਅੱਧਾ ਭਾਗ ਲੰਬੀਆਂ ਕਹਾਣੀਆਂ ਲਿਖਦਾ ਹੈ ਅਤੇ ਦੂਜਾ ਤਰਫ਼ ਟਰਸ ਬੁਲੇਟ, ਤਾਂ ਤੁਹਾਨੂੰ ਗੈਪ, ਡੁਪਲਿਕੇਟ ਅਤੇ ਸ਼ਬਦਾਵਲੀ ਬਾਰੇ ਵਾਦ-ਵਿਵਾਦ ਮਿਲਣਗੇ ਨਾਂ ਕਿ ਗੁਣਵੱਤਾ।
Given-When-Then ਉਹ ਵੇਲੇ ਚੰਗਾ ਹੁੰਦਾ ਹੈ ਜਦ ਫੀਚਰ ਇੰਟਰਐਕਟਿਵ ਅਤੇ ਸਟੇਟਫੁਲ ਹੋਵੇ। ਇੱਕ ਸਧਾਰਣ ਟੇਬਲ ਵਧੀਆ ਰਹਿੰਦੀ ਹੈ ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਇਨਪੁਟ-ਆਉਟਪੁਟ ਨਿਯਮ ਹਨ ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਸਮਾਨ ਕੇਸ।
ਜੇ ਟੀਮ ਵਿਭਾਜਿਤ ਹੈ, ਇੱਕ ਮਹੀਨੇ ਲਈ ਇਕ ਫਾਰਮੈਟ ਚੁਣੋ ਅਤੇ ਫਿਰ ਢਾਲੋ। ਜੇ ਰਿਵਿਊਅਰ ਲਗਾਤਾਰ ਪੁੱਛਦੇ ਹਨ “ਸਫਲਤਾ ਦਾ ਕੀ ਮਤਲਬ ਹੈ?”, ਤਾਂ ਇਹ ਆਮ ਤੌਰ 'ਤੇ Given-When-Then ਵੱਲ ਜਾਣਾ ਦਰਸਾਉਂਦਾ ਹੈ। ਜੇ ਸਕੇਨਾਰੀਓਜ਼ ਲੰਬੇ ਹੋ ਰਹੇ ਹਨ, ਤਾਂ ਇੱਕ ਟੇਬਲ ਸਕੈਨ ਕਰਨਾ ਆਸਾਨ ਹੋ ਸਕਦਾ ਹੈ।
ਜੋ ਵੀ ਤੁਸੀਂ ਚੁਣੋ, ਇਸਨੂੰ ਨਿਯਮਿਤ ਕਰੋ। ਇਕੋ ਸਿਰਲੇਖ, ਇਕੋ ਕਾਲ, ਅਤੇ ਇਕੋ ਡੀਟੇਲ ਦੀ ਪੱਧਰ ਰੱਖੋ। ਇਹ ਵੀ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਸ਼ਾਮِل ਨਹੀਂ ਕਰਨਾ: ਪਿਕਸਲ-ਪਰਫੈਕਟ UI ਵਿਸਥਾਰ, ਅੰਦਰੂਨੀ ਅਮਲ, ਅਤੇ ਡੇਟਾਬੇਸ ਗੱਲਬਾਤ। ਸਕੇਨਾਰੀਓਜ਼ ਉਹ ਦੱਸਣ ਚਾਹੀਦੇ ਹਨ ਜੋ ਉਪਭੋਗੀ ਦੇਖਦਾ ਹੈ ਅਤੇ ਸਿਸਟਮ ਕੀ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ।
ਸਕੇਨਾਰੀਓਜ਼ ਉਥੇ ਰੱਖੋ ਜਿੱਥੇ ਕੰਮ ਪਹਿਲਾਂ ਹੀ ਹੁੰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਫੀਚਰ ਦੇ ਨੇੜੇ ਰੱਖੋ।
ਆਮ ਵਿਕਲਪਾਂ ਵਿੱਚ ਹਨ: ਉਨ੍ਹਾਂ ਨੂੰ ਪ੍ਰੋਡਕਟ ਕੋਡ ਦੇ ਨੇੜੇ ਰੱਖਣਾ, ਟਿਕਟਾਂ ਵਿੱਚ “Acceptance scenarios” ਸੈਕਸ਼ਨ ਹੇਠਾਂ ਰੱਖਣਾ, ਜਾਂ ਹਰ ਫੀਚਰ ਲਈ ਇੱਕ ਸਾਂਝਾ ਡੌਕ ਸਥਾਨ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਦ ਤੁਸੀਂ Planning Mode ਵਿੱਚ ਵੀ ਸਕੇਨਾਰੀਓ ਰੱਖ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਉਹ ਬਿਲਡ ਇਤਿਹਾਸ, snapshots ਅਤੇ rollback ਪੁਆਇੰਟਸ ਦੇ ਨਾਲ ਰਹਿਣ।
ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਉਹ ਖੋਜਯੋਗ ਹੋਣ, ਇੱਕ ਸਰੋਤ-ਸਚਾਈ ਹੋਣ, ਅਤੇ ਵਿਕਾਸ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਕੇਨਾਰੀਓਜ਼ ਦੀ ਲੋੜ ਹੋਵੇ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਪ੍ਰੌਂਪਟ ਨੂੰ ਇੱਕ ਉਪਭੋਗੀ ਲਕੜੀ (who wants what) ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਫਿਨਿਸ਼ ਲਾਈਨ ਵਜੋਂ ਦੁਬਾਰਾ ਲਿਖੋ। ਇਕ ਵਾਕ ਵਿੱਚ ਲਕੜੀ ਦੱਸੋ, ਫਿਰ 2-4 ਸਫਲਤਾ ਮਾਪਦੰਡ ਜੋ ਤੁਸੀਂ ਬਿਨਾਂ ਬਹਿਸ ਦੇ ਤਹਕੀਕ ਕਰ ਸਕਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਕੋਈ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਨਤੀਜਾ ਨਹੀਂ ਦੱਸ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਹਜੇ ਟੈਸਟ ਨਹੀਂ ਲਿਖਿਆ।
ਅਗਲੇ ਕਦਮ ਵਿੱਚ, ਪ੍ਰੌਂਪਟ ਨੂੰ ਇਨਪੁਟ, ਆਉਟਪੁਟ ਅਤੇ ਨਿਯਮਾਂ ਵਿੱਚ ਵੰਡੋ। ਇਨਪੁਟ ਉਹ ਹੈ ਜੋ ਉਪਭੋਗੀ ਦੇਂਦਾ ਹੈ ਜਾਂ ਚੁਣਦਾ ਹੈ। ਆਉਟਪੁਟ ਉਹ ਹੈ ਜੋ ਸਿਸਟਮ ਦਿਖਾਉਂਦਾ, ਸੇਵ ਕਰਦਾ, ਭੇਜਦਾ ਜਾਂ ਰੋਕਦਾ ਹੈ। ਨਿਯਮ ਉਹ “only if” ਅਤੇ “must” ਬਿਆਨ ਹਨ ਜੋ ਲਾਈਨਾਂ ਵਿਚ ਲੁਕੇ ਹੋਏ ਹੁੰਦੇ ਹਨ।
ਫਿਰ ਜਾਂਚੋ ਕਿ ਫੀਚਰ ਕੰਮ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸ 'ਤੇ ਨਿਰਭਰ ਹੈ। ਇੱਥੇ ਹੀ ਸਕੇਨਾਰੀਓਜ਼ ਦੇ ਗੈਪ ਲੁੱਕੇ ਹੁੰਦੇ ਹਨ: ਲੋੜੀਂਦਾ ਡੇਟਾ, ਯੂਜ਼ਰ ਰੋਲ, ਅਧਿਕਾਰ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਅਤੇ ਸਿਸਟਮ ਸਟੇਟ। ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇ ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਐਪ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਦਰਸਾਓ ਕਿ ਕੀ ਉਪਭੋਗੀ ਨੂੰ ਲੋਗੀਨ ਹੋਣਾ ਜ਼ਰੂਰੀ ਹੈ, ਪ੍ਰੋਜੈਕਟ ਬਣਾਇਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਕਿਸੇ ਯੋਜਨਾ/ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੈ।
ਹੁਣ ਉਹਨਾਂ ਛੋਟੇ ਸਕੇਨਾਰੀਓਜ਼ ਨੂੰ ਲਿਖੋ ਜੋ ਫੀਚਰ ਦੇ ਕੰਮ ਕਰਨ ਦੀ ਸਬੂਤ ਦਿੰਦੇ ਹਨ: ਆਮ ਤੌਰ 'ਤੇ 1-2 ਹੈਪੀ ਪਾਥ, ਫਿਰ 4-8 ਏਜ ਕੇਸ। ਹਰ ਸਕੇਨਾਰੀਓ ਨੂੰ ਇੱਕ ਖ਼ਾਸ ਅਸਫਲ ਹੋਣ ਦੇ ਕਾਰਨ ਉੱਤੇ ਕੇਂਦ੍ਰਿਤ ਰੱਖੋ।
ਚੰਗੇ ਏਜ ਕੇਸ ਜਿਨ੍ਹਾਂ ਨੂੰ ਚੁਣੋ (ਖ਼ਾਲੀ ਜੋ ਪ੍ਰੌਂਪਟ ਵਿੱਚ ਫਿਟ ਹੋਵੇ): ਗੁੰਮ ਜਾਂ ਗਲਤ ਇਨਪੁਟ, ਅਧਿਕਾਰ ਮਿਸਮੇਚ, ਸਥਿਤੀ ਟਕਰਾਅ ਜਿਵੇਂ “ਪਹਿਲਾਂ ਹੀ ਸਬਮਿਟ ਕੀਤਾ ਹੋਇਆ”, ਬਾਹਰੀ ਡਿਪੈਂਡੈਂਸੀ ਸਮੱਸਿਆਵਾਂ ਜਿਵੇਂ ਟਾਈਮਆਊਟ, ਅਤੇ ਰਿਕਵਰੀ ਵਿਹਾਰ (ਸਪਸ਼ਟ ਐਰਰ, ਸੁਰੱਖਿਅਤ ਰੀਟ੍ਰਾਈ, ਕੋਈ ਅਧੂਰਾ ਸੇਵ ਨਹੀਂ)।
ਅੰਤ ਵਿੱਚ ਇੱਕ ਤੇਜ਼ “ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ?” ਪਾਸ ਕਰੋ। ਚੁਪਚਾਪ ਫੇਲ, ਉਲਝਣ ਵਾਲੇ ਸੁਨੇਹੇ, ਅਤੇ ਥਾਵਾਂ ਲਈ ਧਿਆਨ ਰੱਖੋ ਜਿੱਥੇ ਸਿਸਟਮ ਗਲਤ ਡੇਟਾ ਬਣਾ ਸਕਦਾ ਹੈ।
ਹੈਪੀ ਪਾਥ ਇੱਕ ਛੋਟਾ, ਆਮ ਰਾਹ ਹੈ ਜਿੱਥੇ ਹਰ ਚੀਜ਼ ਠੀਕ ਜਾਇਆ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਇਰਾਦਾ ਕਰਕੇ ਨਿਰਸ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਇਹ ਇੱਕ ਭਰੋਸੇਯੋਗ ਬੇਸਲਾਈਨ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ ਬਾਅਦ ਵਿੱਚ ਏਜ ਕੇਸ ਦੇਖਣਾ ਆਸਾਨ ਕਰਦਾ ਹੈ।
ਡਿਫਾਲਟ ਯੂਜ਼ਰ ਅਤੇ ਡੈਫਾਲਟ ਡੇਟਾ ਦਾ ਨਾਮ ਦਿਓ। “User” ਦੀ ਥਾਂ ਇੱਕ ਅਸਲ ਰੋਲ ਵਰਤੋ: “Signed-in customer with a verified email” ਜਾਂ “Admin with permission to edit billing.” ਫਿਰ ਸਭ ਤੋਂ ਘੱਟ ਨਮੂਨਾ ਡੇਟਾ ਦਿਓ: ਇੱਕ ਪ੍ਰੋਜੈਕਟ, ਇੱਕ ਸੂਚੀ ਆਈਟਮ, ਇੱਕ ਸੇਵ ਕੀਤੀ ਪੇਮੈਂਟ ਮੈਥਡ। ਇਹ ਸਕੇਨਾਰੀਓਜ਼ ਨੂੰ konkret ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਛੁਪੀਆਂ ਧਾਰਣਾਂ ਘਟਾਉਂਦਾ ਹੈ।
ਸਫਲਤਾ ਤੱਕ ਸਭ ਤੋਂ ਛੋਟੀ ਰਾਹ ਲਿਖੋ। ਵਿਕਲਪਿਕ ਕਦਮ ਅਤੇ ਬਦਲੀ ਰੂਪ ਹਟਾਓ। ਜੇ ਫੀਚਰ “Create a task” ਹੈ, ਤਾਂ ਹੈਪੀ ਪਾਥ ਵਿੱਚ ਫਿਲਟਰ, ਸੋਰਟਿੰਗ ਜਾਂ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ ਸੋਧ ਸ਼ਾਮਿਲ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।
ਇੱਕ ਸਧਾਰਣ ਤਰੀਕਾ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਚਾਰ ਚੀਜ਼ਾਂ ਪੁਸ਼ਟੀ ਕਰੋ:
ਫਿਰ ਇੱਕ ਬਦਲਵ ਜੋ ਸਿਰਫ ਇੱਕ ਵੇਰੀਅਬਲ ਬਦਲਦਾ ਹੈ ਸ਼ਾਮਿਲ ਕਰੋ। ਉਹ ਵੇਰੀਅਬਲ ਚੁਣੋ ਜੋ ਬਾਅਦ ਵਿੱਚ ਟੁੱਟਣ ਸੰਭਾਵਨਾ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਹੈ, ਜਿਵੇਂ “title ਲੰਮਾ ਹੈ” ਜਾਂ “ਉਪਭੋਗੀ ਕੋਲ ਪਹਿਲਾਂ ਕੋਈ ਆਈਟਮ ਨਹੀਂ ਹੈ।”
ਉਦਾਹਰਨ: ਜੇ ਤੁਹਾਡਾ ਪ੍ਰੌਂਪਟ ਕਹਿੰਦਾ ਹੈ, “Add a ‘Snapshot created’ toast after saving a snapshot,” ਤਾਂ ਹੈਪੀ ਪਾਥ ਇਹ ਹੋਵੇਗਾ: ਉਪਭੋਗੀ Create Snapshot 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ, ਇੱਕ ਲੋਡਿੰਗ ਸਥਿਤੀ ਵੇਖਦਾ ਹੈ, “Snapshot created” ਮਿਲਦਾ ਹੈ, ਅਤੇ snapshot ਸੂਚੀ ਵਿੱਚ ਸਹੀ ਟਾਇਮਸਟੈਂਪ ਨਾਲ ਆ ਜਾਦਾ ਹੈ। ਇੱਕ ਵੇਰੀਅਬਲ ਵੈਰੀਐਂਟ ਹੋ ਸਕਦੀ ਹੈ ਨਾਮ ਖਾਲੀ ਹੋਣ 'ਤੇ ਇੱਕ ਸਪਸ਼ਟ ਡੀਫਾਲਟ ਨਾਮ ਨੀਤੀ।
ਏਜ ਕੇਸ ਉਹ ਹਨ ਜਿੱਥੇ ਬਹੁਤ ਸਾਰੇ ਬਗ ਛੁਪੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਵੱਡੀ ਸੂਟ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਹਰ ਪ੍ਰੌਂਪਟ ਲਈ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਛੋਟਾ ਸਮੂਹ ਚੁਣੋ ਜੋ ਅਸਲ ਵਿਹਾਰ ਅਤੇ ਅਸਲ ਫੇਲੈਰ ਮੋਡਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੋਵੇ।
ਆਮ ਵਰਗ:
ਹਰ ਫੀਚਰ ਨੂੰ ਹਰ ਵਰਗ ਦੀ ਲੋੜ ਨਹੀਂ। ਇੱਕ ਖੋਜ ਬਾਕਸ ਨੂੰ ਇਨਪੁਟ 'ਤੇ ਜ਼ਿਆਦਾ ਧਿਆਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਪੇਮੈਂਟ ਫਲੋ ਨੂੰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਅਤੇ ਡੇਟਾ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇਗਾ।
ਉਹ ਏਜ ਕੇਸ ਚੁਣੋ ਜੋ ਖਤਰੇ ਦੇ ਆਧਾਰ 'ਤੇ ਮਿਲਦੇ ਹਨ: ਨੁਕਸਾਨ ਦੀ ਉੱਚ ਕੀਮਤ (ਪੈਸਾ, ਸੁਰੱਖਿਆ, ਨਿੱਜਤਾ), ਉੱਚ ਫ੍ਰਿਕਵੈਂਸੀ, ਆਸਾਨੀ ਨਾਲ ਟੁੱਟਣ ਵਾਲੇ ਫ਼ਲੋ, ਪਿਛਲੇ ਬਗ ਆਦਿ।
ਉਦਾਹਰਨ: “user changes subscription plan” ਲਈ ਫਾਲੋਅਪ ਸਕੇਨਾਰੀਓ ਜ਼ਿਆਦਾ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦੇ ਹਨ: ਚੈਕਆਉਟ 'ਤੇ ਸੈਸ਼ਨ ਖਤਮ ਹੋ ਜਾਣਾ, “Confirm” 'ਤੇ ਡਬਲ-ਕਲਿੱਕ, ਅਤੇ ਪੇਮੈਂਟ ਪ੍ਰਦਾਤਾ ਟਾਈਮਆਊਟ ਜੋ ਯੋਜਨਾ ਨੂੰ ਅਣਬਦਲ ਰੱਖਦਾ ਹੈ ਪਰ ਸਪਸਟ ਸੁਨੇਹਾ ਦਿਖਾਉਂਦਾ ਹੈ।
ਉਦਾਹਰਨ ਫੀਚਰ ਪ੍ਰੌਂਪਟ (ਸਧਾਰਨ ਭਾਸ਼ਾ):
“When I break something, I want to roll my app back to a previous snapshot so the last working version is live again.”
ਹੇਠਾਂ ਇੱਕ ਸੰਕੁਚਿਤ ਸਕੇਨਾਰੀਓ ਸੈੱਟ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਹਰ ਸਕੇਨਾਰੀਓ ਛੋਟਾ ਹੈ, ਪਰ ਇੱਕ ਨਤੀਜੇ ਨੂੰ ਪਿੰਨ ਕਰਦਾ ਹੈ।
S1 [Must-have] Roll back to the most recent snapshot
Given I am logged in and I own the app
When I choose “Rollback” and confirm
Then the app deploys the previous snapshot and the app status shows the new version as active
S2 [Must-have] Roll back to a specific snapshot
Given I am viewing the snapshot list for my app
When I select snapshot “A” and confirm rollback
Then snapshot “A” becomes the active version and I can see when it was created
S3 [Must-have] Not allowed (auth)
Given I am logged in but I do not have access to this app
When I try to roll back
Then I see an access error and no rollback starts
S4 [Must-have] Snapshot not found (validation)
Given a snapshot ID does not exist (or was deleted)
When I attempt to roll back to it
Then I get a clear “snapshot not found” message
S5 [Must-have] Double submit (duplicates)
Given I click “Confirm rollback” twice quickly
When the second request is sent
Then only one rollback runs and I see a single result
S6 [Must-have] Deployment failure (failures)
Given the rollback starts
When deployment fails
Then the currently active version stays live and the error is shown
S7 [Nice-to-have] Timeout or lost connection
Given my connection drops mid-rollback
When I reload the page
Then I can see whether rollback is still running or finished
S8 [Nice-to-have] Already on that snapshot
Given snapshot “A” is already active
When I try to roll back to snapshot “A”
Then I’m told nothing changed and no new deployment starts
ਹਰ ਸਕੇਨਾਰੀਓ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕੌਣ ਕਰ ਰਿਹਾ ਹੈ, ਉਹ ਕੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਕੀ ਸੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਮਕਸਦ “ਹਰ ਚੀਜ਼ ਦੀ ਟੈਸਟ” ਨਹੀਂ ਹੈ। ਮਕਸਦ ਉਹ ਖਤਰਿਆਂ ਨੂੰ ਕਵਰ ਕਰਨਾ ਹੈ ਜੋ ਉਪਭੋਗੀਆਂ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੇ ਹਨ, ਬਿਨਾਂ ਐਸੇ ਸਕੇਨਾਰੀਓਜ਼ ਬਣਾਉਣ ਜੋ ਕੋਈ ਚਲਾਉਂਦਾ ਨਹੀਂ।
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਚਾਲ ਹੈ ਕਿ ਸਕੇਨਾਰੀਓਜ਼ ਨੂੰ ਲੇਬਲ ਕਰੋ ਕਿ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਕਿਵੇਂ ਵਰਤੋਂਗੇ:
ਆਪਣੇ ਆਪ ਨੂੰ ਹਰੇਕ ਵੱਖਰੇ ਖਤਰੇ ਲਈ ਇੱਕ ਸਕੇਨਾਰੀਓ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ। ਜੇ ਦੋ ਸਕੇਨਾਰੀਓਜ਼ ਇੱਕੋ ਕਾਰਨ ਨਾਲ ਫੇਲ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਸੰਭਵਤ: ਤੁਹਾਨੂੰ ਇਕ ਹੀ ਚਾਹੀਦਾ। “Invalid email format” ਅਤੇ “missing email” ਵੱਖ-ਵੱਖ ਖਤਰੇ ਹਨ। ਪਰ “Step 1 ਤੇ missing email” ਅਤੇ “Step 2 ਤੇ missing email” ਇੱਕੋ ਜਿਹਾ ਖਤਰਾ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਨਿਯਮ ਇਕੋ ਹੈ।
ਅਨੇਕ ਸਕੇਨਾਰੀਓਜ਼ ਵਿੱਚ UI ਕਦਮਾਂ ਦੀ ਨਕਲ ਕਰਨ ਤੋਂ ਵੀ ਬਚੋ। ਦੁਹਰਾਏ ਹਿੱਸਿਆਂ ਨੂੰ ਛੋਟਾ ਰੱਖੋ ਅਤੇ ਫਿਰ ਜੋ ਬਦਲਦਾ ਹੈ ਉਸ 'ਤੇ ਧਿਆਨ ਦਿਓ। ਇਹ ਚੀਜ਼ Koder.ai ਵਰਗੇ ਚੈਟ-ਅਧਾਰਿਤ ਟੂਲ ਵਿੱਚ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ UI ਜਦੋਂ ਬਦਲ ਸਕਦਾ ਹੈ ਪਰ ਬਿਜਨਸ ਰੂਲ ਇੱਕੋ ਰਹਿੰਦਾ ਹੈ।
ਅਖ਼ੀਰ ਵਿੱਚ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਹੁਣ ਕੀ ਚੈੱਕ ਕਰਨਾ ਹੈ ਤੇ ਬਾਅਦ ਵਿੱਚ ਕੀ। ਕੁਝ ਚੈੱਕ ਪਹਿਲੇ-ਵਾਰ ਮੈਨੂਅਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਫਿਰ ਜੈਸੇ-ਜੈਸੇ ਫੀਚਰ ਸਥਿਰ ਹੋਵੇ ਆਟੋਮੇਟ ਕਰੋ:
ਇੱਕ ਸਕੇਨਾਰੀਓ ਤੁਹਾਨੂੰ ਅਚੰਭੇ ਤੋਂ ਬਚਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਦੱਸਣਾ ਚਾਹੀਦਾ ਕਿ ਟੀਮ ਫੀਚਰ ਨੂੰ ਕਿਵੇਂ ਬਣਾਏਗੀ।
ਸਭ ਤੋਂ ਆਮ ਨੁਕਸ ਇਹ ਹੈ ਕਿ ਉਪਭੋਗੀ ਲਕੜੀ ਨੂੰ ਇੱਕ ਟੈਕ ਚੈਕਲਿਸਟ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਜੇ ਸਕੇਨਾਰੀਓ ਕਹਿੰਦਾ ਹੈ “API returns 200” ਜਾਂ “table X has column Y,” ਤਾਂ ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ ਡਿਜ਼ਾਈਨ 'ਤੇ ਲਾਕ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਇਹ ਸਿੱਧਾ ਨਹੀਂ ਕਰਦਾ ਕਿ ਉਪਭੋਗੀ ਨੇ ਜੋ ਲੋੜੀ ਸੀ ਉਹ ਮਿਲੀ।
ਇੱਕ ਹੋਰ ਸਮੱਸਿਆ ਹੈ ਕਿ ਕਈ ਲਕੜੀਆਂ ਨੂੰ ਇਕੱਠਾ ਕਰਕੇ ਇਕ ਲੰਬਾ ਸਕੇਨਾਰੀਓ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਇੱਕ ਯਾਤਰਾ ਵਾਂਗ ਪੜ੍ਹਦਾ ਹੈ, ਪਰ ਜਦ ਇਹ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਕਿਸੇ ਨੂੰ ਵੀ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਕਿਉਂ। ਇੱਕ ਸਕੇਨਾਰੀਓ ਨੂੰ ਇੱਕ ਸਵਾਲ ਦਾ ਉਤਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।
ਉਸ ਤੋਂ ਬਚੋ ਜੋ clever ਲੱਗਦੇ ਏਜ ਕੇਸ ਹੁੰਦੇ ਹਨ ਪਰ ਅਸਲ ਵਿੱਚ ਸਿਰਲੇਖ ਨਹੀਂ। “User has 10 million projects” ਜਾਂ “network drops every 2 seconds” ਅਕਸਰ ਪ੍ਰੋਡਕਸ਼ਨ ਨਾਲ ਮਿਲਦੇ-ਜੁਲਦੇ ਨਹੀਂ ਅਤੇ ਦੁਹਰਾਉਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ। ਉਹ ਏਜ ਕੇਸ ਚੁਣੋ ਜੋ ਮਿੰਟਾਂ ਵਿੱਚ ਸੈਟਅਪ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।
ਅਸਪਸ਼ਟ ਨਤੀਜਿਆਂ ਤੋਂ ਵੀ ਬਚੋ: “works”, “no errors”, ਜਾਂ “successfully completes” ਵਰਗੇ ਸ਼ਬਦ ਉਹ ਨਤੀਜਾ ਲੁਕਾਉਂਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਵੈਰੀਫਾਈ ਕਰਨ ਚਾਹੁੰਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ Koder.ai ਦੀ “export source code” ਵਰਗੀਆਂ ਫੀਚਰ ਬਣਾ ਰਹੇ ਹੋ, ਇੱਕ ਕਮਜ਼ੋਰ ਸਕੇਨਾਰੀਓ ਹੋਵੇਗਾ: “When user clicks export, the system zips the repo and returns 200.” ਇਹ ਇੱਕ ਇੰਪਲਿਮੈਂਟੇਸ਼ਨ ਨੂੰ ਟੈਸਟ ਕਰਦਾ ਹੈ, ਨਾਂ ਕਿ ਵਾਅਦਾ।
ਇੱਕ ਵਧੀਆ ਸਕੇਨਾਰੀਓ ਹੋਵੇਗਾ: “Given a project with two snapshots, when the user exports, then the download contains the current snapshot’s code and the export log records who exported and when.”
“ਨੂੰ ਨਾ ਭੁੱਲੋ” ਪਾਥ: “Given a user without export permission, when they try to export, then the option is hidden or blocked, and no export record is created.” ਇਕ ਲਾਈਨ ਦੋਨੋ ਸੁਰੱਖਿਆ ਅਤੇ ਡੇਟਾ ਇੰਟਿਗ੍ਰਿਟੀ ਦੀ ਰੱਖਿਆ ਕਰ ਸਕਦੀ ਹੈ।
ਸਕੇਨਾਰੀਓ ਸੈੱਟ ਨੂੰ “ਚੁੱਕਿਆ” ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਸ ਨੂੰ ਇਕ ਪੱਅਰ-ਪਿਕੀ ਉਪਭੋਗੀ ਅਤੇ ਡੇਟਾਬੇਸ ਜਿਵੇਂ ਦਿੱਖੋ। ਜੇ ਤੁਹਾਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਟੈਸਟ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਸੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ “ਸਫਲਤਾ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਤਾਂ ਇਹ ਤਿਆਰ ਨਹੀਂ।
ਇੱਕ ਵਧੀਆ ਸੈੱਟ ਛੋਟਾ ਪਰ ਵਿਸ਼ੇਸ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਸੀਂ ਕਿਸੇ ਨੂੰ ਦੇ ਸਕੋ ਜੋ ਫੀਚਰ ਨਹੀਂ ਲਿਖਿਆ ਉਸਨੂੰ ਬਾਹਰ ਤੋਂ ਦੇ ਕੇ ਉਹੀ ਨਤੀਜੇ ਮਿਲਣ।
ਇਹ ਤੇਜ਼ ਪਾਸ ਵਰਤੋਂ ਲਈ:
ਜੇ ਤੁਸੀਂ chat-based builder ਜਿਵੇਂ Koder.ai ਵਿੱਚ ਸਕੇਨਾਰੀਓ ਜਨਰੇਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਉਸੇ ਮਿਆਰ 'ਤੇ ਰੱਖੋ: ਕੋਈ ਧੁੰਦਲਾ “works as expected” ਨਾਂ ਹੋਵੇ। ਦਿੱਖਣਯੋਗ ਆਉਟਪੁੱਟ ਅਤੇ ਸਟੋਰ ਕੀਤੇ ਗਏ ਬਦਲਾਵਾਂ ਮੰਗੋ, ਫਿਰ ਕੇਵਲ ਉਹੀ ਮਨਜ਼ੂਰ ਕਰੋ ਜੋ ਤੁਸੀਂ ਵੈਰੀਫਾਈ ਕਰ ਸਕਦੇ ਹੋ।
ਸਕੇਨਾਰੀਓ ਲਿਖਣਾ ਇਕ ਅਸਲੀ ਕਦਮ ਬਣਾਓ, ਨਾ ਕਿ ਅਖ਼ੀਰ ਵਿੱਚ ਸਾਫ-ਸਫ਼ਾਈ ਦਾ ਕੰਮ।
ਵਿਕਾਸ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਸਕੇਨਾਰੀਓ ਲਿਖੋ, ਜਦ ਫੀਚਰ ਅਜੇ ਵੀ ਸਸਤਾ ਹੈ। ਇਸ ਨਾਲ ਟੀਮ ਨੂੰ ਉਹ ਅਜਿਹੇ ਉਪਦ੍ਰਵ ਵਾਲੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਪੈਂਦੇ ਹਨ: “ਸਫਲਤਾ” ਦਾ ਕੀ ਮਤਲਬ, ਗਲਤ ਇਨਪੁਟ 'ਤੇ ਕੀ ਹੁੰਦਾ, ਅਤੇ ਤੁਸੀਂ ਹੁਣ ਕੀ ਸਹਿਯੋਗ ਨਹੀਂ ਕਰ ਰਹੇ।
ਸਕੇਨਾਰੀਓਜ਼ ਨੂੰ ਆਪਣੇ “Done” ਦੀ ਸੰਯੁਕਤ ਪਰਿਭਾਸ਼ਾ ਵਜੋਂ ਵਰਤੋਂ। Product ਇਰਾਦਾ ਮਾਲਕ ਹੈ, QA ਖਤਰਾ ਸੋਚਦਾ ਹੈ, ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿਵਹਾਰਕਤਾ ਦਾ ਮਾਲਕ ਹੈ। ਜਦ ਤਿੰਨੋ ਇੱਕੋ ਸਕੇਨਾਰੀਓ ਸੈੱਟ ਪੜ੍ਹਕੇ ਸਹਿਮਤ ਹੋ ਜਾਂ, ਤਾਂ ਤੁਸੀਂ ਐਸਾ ਕੁਝ ਭੇਜਣ ਤੋਂ ਬਚ ਜਾਓਗੇ ਜੋ “ਖਤਮ” ਹੈ ਪਰ ਕਬੂਲਯੋਗ ਨਹੀਂ।
ਕਿਸੇ ਵੀ ਟੀਮ ਲਈ ਵਰਕਫਲੋ ਜੋ ਚੱਲਦੀ ਹੈ:
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਿੱਚ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਪਹਿਲਾਂ ਸਕੇਨਾਰੀਓs ਡ੍ਰਾਫਟ ਕਰੋ ਅਤੇ ਫਿਰ Planning Mode ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹਰ ਸਕੇਨਾਰੀਓ ਨੂੰ ਸਕ੍ਰੀਨਾਂ, ਡੇਟਾ ਨਿਯਮਾਂ, ਅਤੇ ਉਪਭੋਗੀ-ਦਿੱਖ ਵਾਲੇ ਨਤੀਜਿਆਂ ਨਾਲ ਮੈਪ ਕਰੋ, ਜਦ ਤੱਕ ਤੁਸੀਂ ਕੋਡ ਜਨਰੇਟ ਜਾਂ ਸੋਧ ਨਹੀਂ ਕਰਦੇ।
ਖਤਰਨਾਕ ਬਦਲਾਵਾਂ ਲਈ, ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਲਵੋ। ਜੇ ਨਵਾਂ ਏਜ ਕੇਸ ਕੰਮ ਕਰਨ ਵਾਲੇ ਫਲੋ ਨੂੰ ਖਰਾਬ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ rollback ਇੱਕ ਦਿਨ ਖੋਣ ਦੀ ਥਾਂ ਤੇ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਚਾ ਸਕਦਾ ਹੈ।
ਸਕੇਨਾਰੀਓਜ਼ ਨੂੰ ਫੀਚਰ ਬੇਨਤੀ ਦੇ ਨੇੜੇ (ਜਾਂ उसी ਟਿਕਟ ਵਿੱਚ) ਰੱਖੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਜ਼ਨਡ ਮੰਗਾਂ ਵਾਂਗ ਸਮਝੋ। ਜਦ ਪ੍ਰੌਂਪਟ ਵਿਕਸਿਤ ਹੋਵੇ, ਤਾਂ ਸਕੇਨਾਰੀਓ ਸੈੱਟ ਵੀ ਵਿਕਸਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਹੀ ਤਾਂ ਤੁਹਾਡਾ “ਡਨ” ਖਾਮੋਸ਼ੀ ਨਾਲ ਭਟਕ ਸਕਦਾ ਹੈ।
Start with one sentence that states the user goal and the finish line.
Then break the prompt into:
From there, write 1–2 happy paths plus 4–8 edge cases that match real risks (permissions, duplicates, timeouts, missing data).
Because prompts hide assumptions. A prompt might say “save,” but not define whether that means drafted vs published, what happens on failure, or who is allowed to do it.
Scenarios force you to name the rules early, before you ship bugs like duplicate submissions, permission mismatches, or inconsistent results.
Use Given–When–Then when the feature has state and user interaction.
Use a simple input/output table when you have lots of similar rule checks.
Pick one format for a month and standardize it (same tense, same level of detail). The best format is the one your team will actually keep using.
A good scenario is:
It’s “done” when anyone can run it and agree on the outcome without debate.
Focus on observable behavior:
Avoid implementation details like database tables, API response codes, background jobs, or frameworks. Those details change often and don’t prove the user got the outcome they need.
Write the most boring, normal path where everything works:
Then verify four things: correct screen/state, clear success message, data is saved, and the user can continue to the next sensible action.
Pick edge cases based on risk and frequency:
Aim for , not every possible variation.
Keep it safe and clear:
A failure scenario should prove the system doesn’t corrupt data or mislead the user.
Treat Koder.ai output like any other app: test what the user experiences, not how the code was generated.
Practical approach:
Store them where work already happens and keep one source of truth:
If you use Koder.ai, keep scenarios in Planning Mode so they stay tied to build history. Most importantly: require scenarios before development is considered started.