31 ਦਸੰ 2025·8 ਮਿੰਟ
ਪ੍ਰੌਂਪਟ ਤੋਂ ਸਵੀਕਾਰਤਾ ਟੈਸਟ: ਫੀਚਰਾਂ ਨੂੰ ਸਕੇਨਾਰੀਓਜ਼ ਵਿੱਚ ਬਦਲੋ
ਹਰ ਫੀਚਰ ਪ੍ਰੌਂਪਟ ਨੂੰ 5-10 ਸਪਸ਼ਟ acceptance ਸਕੇਨਾਰੀਓਜ਼ ਵਿੱਚ ਬਦਲ ਕੇ ਹੈਪੀ ਪਾਥ ਅਤੇ ਏਜ ਕੇਸ ਕਵਰ ਕਰੋ—ਬੇਹਦ ਵੱਡੇ ਟੈਸਟ ਸੂਟਾਂ ਦੀ ਲੋੜ ਨਹੀਂ।
ਕਿਉਂ ਫੀਚਰ ਪ੍ਰੌਂਪਟ ਅਕਸਰ ਲੁਕੇ ਹੋਏ ਨਿਯਮ ਛੱਡ ਦਿੰਦੇ ਹਨ
Chat-ਸਟਾਈਲ ਫੀਚਰ ਪ੍ਰੌਂਪਟ ਗੱਲਬਾਤ ਵਾਂਗ ਲਗਦੇ ਹਨ, ਇਸ ਲਈ ਸਪੱਸ਼ਟ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ। ਪਰ ਉਹ ਅਕਸਰ ਚੋਣਾਂ, ਨਿਯਮ ਅਤੇ ਛੁਟਕਾਰਿਆਂ ਨੂੰ ਕੁਝ ਦੋਸਤਾਨਾ ਵਾਕਾਂ ਵਿੱਚ ਸੰਕੁਚਿਤ ਕਰ ਦਿੰਦੇ ਹਨ। ਜਦ ਤਕ ਕੋਈ ਵਿਅਕਤੀ ਫੀਚਰ ਨੂੰ ਅਸਲ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਵਰਤਦਾ ਨਹੀਂ, ਇਹ ਖਾਮੀਆਂ ਸਾਹਮਣੇ ਨਹੀਂ ਆਉਂਦੀਆਂ।
ਜ਼ਿਆਦਾਤਰ ਪ੍ਰੌਂਪਟ ਚੁਪਕੇ-ਚੁਪਕੇ ਧਾਰਣਾਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ: ਕੌਣ ਇਹ ਕਾਰਵਾਈ ਕਰਨ ਦੀ ਆਗਿਆ ਰੱਖਦਾ ਹੈ, “ਸਫਲਤਾ” ਦੀ ਕੀ ਪਰਿਭਾਸ਼ਾ ਹੈ (ਸੇਵ, ਭੇਜਿਆ, ਪ੍ਰਕਾਸ਼ਿਤ, ਭੁਗਤਾਨ), ਜਦ ਡੇਟਾ ਗਾਇਬ ਹੋਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਜਦ ਕੁਝ ਫੇਲ ਹੁੰਦਾ ਹੈ ਤਾਂ ਉਪਭੋਗੀ ਨੂੰ ਕੀ ਦਿਖਾਈ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਹ ਧੁੰਦਲੇ ਮਾਪਦੰਡ ਵੀ ਛੁਪਾਉਂਦੇ ਹਨ, ਜਿਵੇਂ “ਕਿੰਨਾ ਤੇਜ਼” ਜਾਂ “ਕਿੰਨਾ ਸੁਰੱਖਿਅਤ” ਕਾਫ਼ੀ ਹੈ।
ਅਸਪਸ਼ਟਤਾ ਆਮ ਤੌਰ 'ਤੇ ਬਾਅਦ ਵਿੱਚ ਬਗ ਅਤੇ ਰੀਵਰਕ ਦੇ ਰੂਪ ਵਿੱਚ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ। ਡਿਵੈਲਪਰ ਉਹ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਉਹ ਸੋਚਦਾ ਹੈ ਕਿ ਪ੍ਰੌਂਪਟ ਦਾ ਮਤਲਬ ਹੈ, ਰਿਵਿਊਅਰ ਇਸਨੂੰ ਠੀਕ ਲੱਗਣ 'ਤੇ ਮਨਜ਼ੂਰ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਯੂਜ਼ਰ ਅਜਿਹੇ ਕੇਸਾਂ ਵਿੱਚ ਫਸਦੇ ਹਨ: ਡੁਪਲਿਕੇਟ ਸਬਮਿਸ਼ਨ, ਟਾਈਮ ਜ਼ੋਨ, ਅਧੂਰਾ ਡੇਟਾ, ਜਾਂ ਅਧਿਕਾਰ ਨਾਲ ਮੇਲ ਨਾ ਖਾਣਾ। ਬਾਅਦ ਵਿੱਚ ਠੀਕ ਕਰਨ ਦੀ ਕੀਮਤ ਵੱਧਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਅਕਸਰ ਕੋਡ, UI ਟੈਕਸਟ, ਅਤੇ ਕਈ ਵਾਰੀ ਡੇਟਾ ਮਾਡਲ ਨੂੰ ਛੇੜਦਾ ਹੈ।
ਗੁਣਵੱਤਾ ਵੱਡੇ ਟੈਸਟ ਸੂਟ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦੀ। ਇਸ ਦਾ ਅਰਥ ਹੈ ਕਿ ਤੁਸੀਂ ਆਮ ਵਰਤੋਂ ਅਤੇ ਪ੍ਰਿਡਿਕਟੇਬਲ ਸਟ੍ਰੈਸ ਹੇਠਾਂ ਫੀਚਰ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹੋ। ਕੁਝ ਚੁਣੀ ਹੋਈ ਸਕੇਨਾਰੀਓਜ਼ ਤੁਸੀਂ ਇਹ ਭਰੋਸਾ ਦਿੰਦੇ ਹਨ ਬਿਨਾਂ ਸੈਂਕੜਿਆਂ ਟੈਸਟਾਂ ਦੇ।
ਪ੍ਰੈਕਟਿਕਲ ਗੁਣਵੱਤਾ ਦੀ ਪਰਿਭਾਸ਼ਾ ਜਦ ਪ੍ਰੌਂਪਟ-ਅਧਾਰਿਤ ਫੀਚਰ ਬਣਾਏ ਜਾਂਦੇ ਹਨ:
- ਮੁੱਖ ਉਪਭੋਗੀ ਲਕੜੀ ਅੰਤ ਤੱਕ ਕੰਮ ਕਰਦੀ ਹੈ (ਹੈਪੀ ਪਾਥ)।
- ਮੁੱਖ ਫੇਲ੍ਹ ਮੋਡਾਂ ਨੂੰ ਸਾਫ਼ ਢੰਗ ਨਾਲ ਹੱਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਸਪਸ਼ਟ ਐਰਰ, ਕੋਈ ਚੁਪਚਾਪ ਕਰਪਸ਼ਨ ਨਹੀਂ)।
- ਫੀਚਰ ਸਥਿਰ ਤਰੀਕੇ ਨਾਲ ਵਰਤਦਾ ਹੈ (ਉਹੀ ਇਨਪੁਟ, ਉਹੀ ਨਤੀਜਾ)।
- ਅਕਸਮਾਤ ਘਟਤੀਆਂ ਨਾਲ ਕੁਝ ਖ਼ਤਰਨਾਕ ਨਹੀਂ ਹੁੰਦਾ (ਗਲਤ-ਯੂਜ਼ਰ ਪਹੁੰਚ, ਡੁਪਲਿਕੇਟ ਕਾਰਵਾਈ).
ਇਹੀ ਪ੍ਰੌਂਪਟ ਨੂੰ acceptance scenarios ਵਿੱਚ ਬਦਲਣ ਦਾ ਮਕਸਦ ਹੈ: ਇੱਕ ਧੁੰਦਲੀ ਮੰਗ ਨੂੰ ਲਓ ਅਤੇ ਉਸਨੂੰ 5-10 ਚੇਕਾਂ ਵਿੱਚ ਬਦਲੋ ਜੋ ਲੁਕੀਆਂ ਨਿਯਮਾਂ ਨੂੰ ਅਗੇ ਹੀ ਉਜਾਗਰ ਕਰਨ। ਤੁਸੀਂ ਹਰ ਚੀਜ਼ ਦੀ ਟੈਸਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਹੇ; ਤੁਸੀਂ ਉਹ ਫੇਲ੍ਹ ਕੈਚ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ ਜੋ ਅਸਲ ਵਿੱਚ ਹੋਣ ਗੈ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ vibe-coding ਟੂਲ ਵਿੱਚ ਇੱਕ ਝਟਪਟ ਪ੍ਰੌਂਪਟ ਤੋਂ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਆਉਟਪੁੱਟ ਪੂਰਨ ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਫਿਰ ਵੀ ਏਜ ਰੂਲ ਸਕਿਪ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਟਾਈਟ ਸਕੇਨਾਰੀਓ ਸੈੱਟ ਉਹਨਾਂ ਨਿਯਮਾਂ ਨੂੰ ਨਾਮਿਤ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ ਜਦ ਤਕ ਭਾਅ ਘੱਟ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਵਧੀਆ acceptance test ਸਕੇਨਾਰੀਓ ਕਿੰਝ ਲੱਗਦੀ ਹੈ
ਇੱਕ 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 ਪੁਆਇੰਟਸ ਦੇ ਨਾਲ ਰਹਿਣ।
ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਉਹ ਖੋਜਯੋਗ ਹੋਣ, ਇੱਕ ਸਰੋਤ-ਸਚਾਈ ਹੋਣ, ਅਤੇ ਵਿਕਾਸ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਕੇਨਾਰੀਓਜ਼ ਦੀ ਲੋੜ ਹੋਵੇ।
ਕਦਮ-ਦਰ-ਕਦਮ: ਇੱਕ ਫੀਚਰ ਪ੍ਰੌਂਪਟ ਨੂੰ 5-10 ਸਕੇਨਾਰੀਓ ਵਿੱਚ ਬਦਲਣਾ
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਪ੍ਰੌਂਪਟ ਨੂੰ ਇੱਕ ਉਪਭੋਗੀ ਲਕੜੀ (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.”
ਹੇਠਾਂ ਇੱਕ ਸੰਕੁਚਿਤ ਸਕੇਨਾਰੀਓ ਸੈੱਟ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਹਰ ਸਕੇਨਾਰੀਓ ਛੋਟਾ ਹੈ, ਪਰ ਇੱਕ ਨਤੀਜੇ ਨੂੰ ਪਿੰਨ ਕਰਦਾ ਹੈ।
ਹੈਪੀ ਪਾਥ (2)
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
ਏਜ ਕੇਸ (6)
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
ਹਰ ਸਕੇਨਾਰੀਓ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕੌਣ ਕਰ ਰਿਹਾ ਹੈ, ਉਹ ਕੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਕੀ ਸੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਕਿਵੇਂ ਕਵਰੇਜ ਉੱਚੀ ਤੇ ਸੂਟ ਛੋਟਾ ਰੱਖੀਏ
ਆਤਮਵਿਸ਼ਵਾਸ ਨਾਲ ਸ਼ਿਪ ਕਰੋ
ਆਪਣੀ ਐਪ ਡੀਪਲੋ ਕਰੋ ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਅਸਲ ਵਿਹਾਰ ਤੁਹਾਡੇ acceptance scenarios ਨਾਲ ਮਿਲਦਾ ਹੈ।
ਮਕਸਦ “ਹਰ ਚੀਜ਼ ਦੀ ਟੈਸਟ” ਨਹੀਂ ਹੈ। ਮਕਸਦ ਉਹ ਖਤਰਿਆਂ ਨੂੰ ਕਵਰ ਕਰਨਾ ਹੈ ਜੋ ਉਪਭੋਗੀਆਂ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੇ ਹਨ, ਬਿਨਾਂ ਐਸੇ ਸਕੇਨਾਰੀਓਜ਼ ਬਣਾਉਣ ਜੋ ਕੋਈ ਚਲਾਉਂਦਾ ਨਹੀਂ।
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਚਾਲ ਹੈ ਕਿ ਸਕੇਨਾਰੀਓਜ਼ ਨੂੰ ਲੇਬਲ ਕਰੋ ਕਿ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਕਿਵੇਂ ਵਰਤੋਂਗੇ:
- Smoke: 1-2 ਸਕੇਨਾਰੀਓ ਜੋ ਫੀਚਰ ਦੇ end-to-end ਕੰਮ ਕਰਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ।
- Regression: 2-6 ਸਕੇਨਾਰੀਓਜ਼ ਜ਼ਰੂਰੀ ਨਿਯਮਾਂ ਅਤੇ ਪਿਛਲੇ ਬੱਗਾਂ ਲਈ।
- Exploratory: ਕੁਝ “ਇਸਨੂੰ ਅਜ਼ਮਾਉ” ਚੈੱਕਜ਼ ਅਜਿਹੇ ਕੇਸਾਂ ਲਈ ਜੋ UX ਨਿਰਣੇ ਲੈਂਦੇ ਹਨ।
ਆਪਣੇ ਆਪ ਨੂੰ ਹਰੇਕ ਵੱਖਰੇ ਖਤਰੇ ਲਈ ਇੱਕ ਸਕੇਨਾਰੀਓ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ। ਜੇ ਦੋ ਸਕੇਨਾਰੀਓਜ਼ ਇੱਕੋ ਕਾਰਨ ਨਾਲ ਫੇਲ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਸੰਭਵਤ: ਤੁਹਾਨੂੰ ਇਕ ਹੀ ਚਾਹੀਦਾ। “Invalid email format” ਅਤੇ “missing email” ਵੱਖ-ਵੱਖ ਖਤਰੇ ਹਨ। ਪਰ “Step 1 ਤੇ missing email” ਅਤੇ “Step 2 ਤੇ missing email” ਇੱਕੋ ਜਿਹਾ ਖਤਰਾ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਨਿਯਮ ਇਕੋ ਹੈ।
ਅਨੇਕ ਸਕੇਨਾਰੀਓਜ਼ ਵਿੱਚ UI ਕਦਮਾਂ ਦੀ ਨਕਲ ਕਰਨ ਤੋਂ ਵੀ ਬਚੋ। ਦੁਹਰਾਏ ਹਿੱਸਿਆਂ ਨੂੰ ਛੋਟਾ ਰੱਖੋ ਅਤੇ ਫਿਰ ਜੋ ਬਦਲਦਾ ਹੈ ਉਸ 'ਤੇ ਧਿਆਨ ਦਿਓ। ਇਹ ਚੀਜ਼ Koder.ai ਵਰਗੇ ਚੈਟ-ਅਧਾਰਿਤ ਟੂਲ ਵਿੱਚ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ UI ਜਦੋਂ ਬਦਲ ਸਕਦਾ ਹੈ ਪਰ ਬਿਜਨਸ ਰੂਲ ਇੱਕੋ ਰਹਿੰਦਾ ਹੈ।
ਅਖ਼ੀਰ ਵਿੱਚ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਹੁਣ ਕੀ ਚੈੱਕ ਕਰਨਾ ਹੈ ਤੇ ਬਾਅਦ ਵਿੱਚ ਕੀ। ਕੁਝ ਚੈੱਕ ਪਹਿਲੇ-ਵਾਰ ਮੈਨੂਅਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਫਿਰ ਜੈਸੇ-ਜੈਸੇ ਫੀਚਰ ਸਥਿਰ ਹੋਵੇ ਆਟੋਮੇਟ ਕਰੋ:
- Manual ਹੁਣ: ਵਾਕ, ਲੇਆਊਟ, ਵਿਜ਼ੂਅਲ ਸਟੇਟ, “ਅਜਿਹਾ ਮਹਿਸੂਸ ਹੁੰਦਾ” ਵਾਲੇ ਪਲ।
- ਜਲਦੀ ਆਟੋਮੇਟ ਕਰੋ: ਗਣਨਾਵਾਂ, ਅਧਿਕਾਰ, ਡੇਟਾ ਸਹੀ ਸੇਵ ਹੋਣਾ, ਮਹੱਤਵਪੂਰਨ ਫਲੋ।
- ਬਾਅਦ ਵਿੱਚ ਆਟੋਮੇਟ ਕਰੋ: ਦੁਰਲਭ ਡਿਵਾਈਸ ਖ਼ਾਸियतਾਂ, ਅਜੀਬ ਬ੍ਰਾਊਜ਼ਰ ਟਾਈਮਿੰਗ, ਤੀਸਰੇ-ਪੱਖੀ ਫੇਲਿਊਰ।
ਆਮ ਗਲਤੀਆਂ ਜੋ ਸਕੇਨਾਰੀਓਜ਼ ਨੂੰ ਬੇਕਾਰ ਬਣਾਉਂਦੀਆਂ ਹਨ
ਇੱਕ ਸਕੇਨਾਰੀਓ ਤੁਹਾਨੂੰ ਅਚੰਭੇ ਤੋਂ ਬਚਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਦੱਸਣਾ ਚਾਹੀਦਾ ਕਿ ਟੀਮ ਫੀਚਰ ਨੂੰ ਕਿਵੇਂ ਬਣਾਏਗੀ।
ਸਭ ਤੋਂ ਆਮ ਨੁਕਸ ਇਹ ਹੈ ਕਿ ਉਪਭੋਗੀ ਲਕੜੀ ਨੂੰ ਇੱਕ ਟੈਕ ਚੈਕਲਿਸਟ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਜੇ ਸਕੇਨਾਰੀਓ ਕਹਿੰਦਾ ਹੈ “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.” ਇਕ ਲਾਈਨ ਦੋਨੋ ਸੁਰੱਖਿਆ ਅਤੇ ਡੇਟਾ ਇੰਟਿਗ੍ਰਿਟੀ ਦੀ ਰੱਖਿਆ ਕਰ ਸਕਦੀ ਹੈ।
ਸਕੇਨਾਰੀਓ ਸੈੱਟ ਭੂਗਤਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ ਚੈਕਲਿਸਟ
ਪ੍ਰੌਂਪਟ ਤੋਂ ਬਣਾਓ, ਉਦੇਸ਼ ਨਾਲ ਟੈਸਟ ਕਰੋ
ਇੱਕ ਚੈਟ ਪ੍ਰੌਂਪਟ ਨੂੰ ਕੰਮ ਕਰਨ ਵਾਲੀ ਐਪ ਵਿੱਚ ਬਦਲੋ, ਫਿਰ ਸਪਸ਼ਟ ਪਾਸ/ਫੇਲ ਚੈੱਕ ਨਾਲ ਉਸਦੀ ਜਾਂਚ ਕਰੋ।
ਸਕੇਨਾਰੀਓ ਸੈੱਟ ਨੂੰ “ਚੁੱਕਿਆ” ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਸ ਨੂੰ ਇਕ ਪੱਅਰ-ਪਿਕੀ ਉਪਭੋਗੀ ਅਤੇ ਡੇਟਾਬੇਸ ਜਿਵੇਂ ਦਿੱਖੋ। ਜੇ ਤੁਹਾਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਟੈਸਟ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਸੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ “ਸਫਲਤਾ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਤਾਂ ਇਹ ਤਿਆਰ ਨਹੀਂ।
ਇੱਕ ਵਧੀਆ ਸੈੱਟ ਛੋਟਾ ਪਰ ਵਿਸ਼ੇਸ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਸੀਂ ਕਿਸੇ ਨੂੰ ਦੇ ਸਕੋ ਜੋ ਫੀਚਰ ਨਹੀਂ ਲਿਖਿਆ ਉਸਨੂੰ ਬਾਹਰ ਤੋਂ ਦੇ ਕੇ ਉਹੀ ਨਤੀਜੇ ਮਿਲਣ।
ਇਹ ਤੇਜ਼ ਪਾਸ ਵਰਤੋਂ ਲਈ:
- Each scenario has one clear precondition and one main outcome.
- Expected results include what the user sees and what is saved.
- Permissions are covered when roles matter (at least one allowed and one denied case).
- Important integrations include at least one realistic failure mode.
- The set stays around 5 to 10 scenarios, with no repeats.
ਜੇ ਤੁਸੀਂ chat-based builder ਜਿਵੇਂ Koder.ai ਵਿੱਚ ਸਕੇਨਾਰੀਓ ਜਨਰੇਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਉਸੇ ਮਿਆਰ 'ਤੇ ਰੱਖੋ: ਕੋਈ ਧੁੰਦਲਾ “works as expected” ਨਾਂ ਹੋਵੇ। ਦਿੱਖਣਯੋਗ ਆਉਟਪੁੱਟ ਅਤੇ ਸਟੋਰ ਕੀਤੇ ਗਏ ਬਦਲਾਵਾਂ ਮੰਗੋ, ਫਿਰ ਕੇਵਲ ਉਹੀ ਮਨਜ਼ੂਰ ਕਰੋ ਜੋ ਤੁਸੀਂ ਵੈਰੀਫਾਈ ਕਰ ਸਕਦੇ ਹੋ।
ਅਗਲੇ ਕਦਮ: prompt-to-tests ਨੂੰ ਆਪਣੀ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਬਣਾਉ
ਸਕੇਨਾਰੀਓ ਲਿਖਣਾ ਇਕ ਅਸਲੀ ਕਦਮ ਬਣਾਓ, ਨਾ ਕਿ ਅਖ਼ੀਰ ਵਿੱਚ ਸਾਫ-ਸਫ਼ਾਈ ਦਾ ਕੰਮ।
ਵਿਕਾਸ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਸਕੇਨਾਰੀਓ ਲਿਖੋ, ਜਦ ਫੀਚਰ ਅਜੇ ਵੀ ਸਸਤਾ ਹੈ। ਇਸ ਨਾਲ ਟੀਮ ਨੂੰ ਉਹ ਅਜਿਹੇ ਉਪਦ੍ਰਵ ਵਾਲੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਪੈਂਦੇ ਹਨ: “ਸਫਲਤਾ” ਦਾ ਕੀ ਮਤਲਬ, ਗਲਤ ਇਨਪੁਟ 'ਤੇ ਕੀ ਹੁੰਦਾ, ਅਤੇ ਤੁਸੀਂ ਹੁਣ ਕੀ ਸਹਿਯੋਗ ਨਹੀਂ ਕਰ ਰਹੇ।
ਸਕੇਨਾਰੀਓਜ਼ ਨੂੰ ਆਪਣੇ “Done” ਦੀ ਸੰਯੁਕਤ ਪਰਿਭਾਸ਼ਾ ਵਜੋਂ ਵਰਤੋਂ। Product ਇਰਾਦਾ ਮਾਲਕ ਹੈ, QA ਖਤਰਾ ਸੋਚਦਾ ਹੈ, ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿਵਹਾਰਕਤਾ ਦਾ ਮਾਲਕ ਹੈ। ਜਦ ਤਿੰਨੋ ਇੱਕੋ ਸਕੇਨਾਰੀਓ ਸੈੱਟ ਪੜ੍ਹਕੇ ਸਹਿਮਤ ਹੋ ਜਾਂ, ਤਾਂ ਤੁਸੀਂ ਐਸਾ ਕੁਝ ਭੇਜਣ ਤੋਂ ਬਚ ਜਾਓਗੇ ਜੋ “ਖਤਮ” ਹੈ ਪਰ ਕਬੂਲਯੋਗ ਨਹੀਂ।
ਕਿਸੇ ਵੀ ਟੀਮ ਲਈ ਵਰਕਫਲੋ ਜੋ ਚੱਲਦੀ ਹੈ:
- Turn each feature prompt into 5-10 scenarios, including 1 happy path and a small set of edge cases.
- Review them quickly and resolve open questions in plain language.
- Implement what the scenarios describe, then add a scenario if a new requirement appears during development.
- Use the scenarios as the acceptance checklist in review, not a vague “looks good.”
- Update scenarios when the prompt changes, so tests match reality.
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਿੱਚ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਪਹਿਲਾਂ ਸਕੇਨਾਰੀਓs ਡ੍ਰਾਫਟ ਕਰੋ ਅਤੇ ਫਿਰ Planning Mode ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹਰ ਸਕੇਨਾਰੀਓ ਨੂੰ ਸਕ੍ਰੀਨਾਂ, ਡੇਟਾ ਨਿਯਮਾਂ, ਅਤੇ ਉਪਭੋਗੀ-ਦਿੱਖ ਵਾਲੇ ਨਤੀਜਿਆਂ ਨਾਲ ਮੈਪ ਕਰੋ, ਜਦ ਤੱਕ ਤੁਸੀਂ ਕੋਡ ਜਨਰੇਟ ਜਾਂ ਸੋਧ ਨਹੀਂ ਕਰਦੇ।
ਖਤਰਨਾਕ ਬਦਲਾਵਾਂ ਲਈ, ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਲਵੋ। ਜੇ ਨਵਾਂ ਏਜ ਕੇਸ ਕੰਮ ਕਰਨ ਵਾਲੇ ਫਲੋ ਨੂੰ ਖਰਾਬ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ rollback ਇੱਕ ਦਿਨ ਖੋਣ ਦੀ ਥਾਂ ਤੇ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਚਾ ਸਕਦਾ ਹੈ।
ਸਕੇਨਾਰੀਓਜ਼ ਨੂੰ ਫੀਚਰ ਬੇਨਤੀ ਦੇ ਨੇੜੇ (ਜਾਂ उसी ਟਿਕਟ ਵਿੱਚ) ਰੱਖੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਜ਼ਨਡ ਮੰਗਾਂ ਵਾਂਗ ਸਮਝੋ। ਜਦ ਪ੍ਰੌਂਪਟ ਵਿਕਸਿਤ ਹੋਵੇ, ਤਾਂ ਸਕੇਨਾਰੀਓ ਸੈੱਟ ਵੀ ਵਿਕਸਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਹੀ ਤਾਂ ਤੁਹਾਡਾ “ਡਨ” ਖਾਮੋਸ਼ੀ ਨਾਲ ਭਟਕ ਸਕਦਾ ਹੈ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
How do I turn a feature prompt into acceptance scenarios without writing a full spec?
Start with one sentence that states the user goal and the finish line.
Then break the prompt into:
- Inputs (what the user provides)
- Outputs (what the system shows/saves/sends/blocks)
- Rules (the “only if,” “must,” and exceptions)
From there, write 1–2 happy paths plus 4–8 edge cases that match real risks (permissions, duplicates, timeouts, missing data).
Why do chat-style prompts so often miss requirements?
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.
What scenario format should my team use: Given–When–Then or a table?
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.
What makes an acceptance test scenario “good”?
A good scenario is:
- Binary (clear pass/fail)
- User-visible (what the user does and what they see)
- Independent (runnable on a clean environment)
- Specific (no “works” or “successfully completes”)
It’s “done” when anyone can run it and agree on the outcome without debate.
What should I avoid putting in acceptance scenarios?
Focus on observable behavior:
- what the user clicks/types
- what the system shows (messages, states)
- what changes persist (created/updated/blocked)
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.
How do I write a happy path scenario without overthinking it?
Write the most boring, normal path where everything works:
- name the real user/role (for example, “signed-in customer with verified email”)
- use minimal realistic data (one project, one item)
- keep steps short (no optional flows)
Then verify four things: correct screen/state, clear success message, data is saved, and the user can continue to the next sensible action.
Which edge cases are worth testing first?
Pick edge cases based on risk and frequency:
- Missing/invalid input (empty, too long, wrong format)
- Permission or session issues (no access, expired login)
- State conflicts (already submitted, already active)
- Concurrency (double-click, two tabs)
- Integration failures (timeout, provider unavailable)
Aim for , not every possible variation.
What should the app do when something fails (timeouts, errors, partial data)?
Keep it safe and clear:
- No silent partial saves
- Clear error message (what happened and what to do next)
- Safe retry (retry doesn’t duplicate actions)
- State stays correct (for example, the old version remains active if deployment fails)
A failure scenario should prove the system doesn’t corrupt data or mislead the user.
How does this workflow fit when building in Koder.ai?
Treat Koder.ai output like any other app: test what the user experiences, not how the code was generated.
Practical approach:
- write scenarios in Planning Mode before building
- build the feature
- run the scenarios as the acceptance checklist
- use before risky changes, so you can recover quickly if an edge case breaks a working flow
Where should we store scenarios so they don’t disappear?
Store them where work already happens and keep one source of truth:
- in the ticket under an “Acceptance scenarios” section
- next to the product code
- in a shared doc space with one page per feature
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.