30 ਦਸੰ 2025·8 ਮਿੰਟ
Claude Code ਨਾਲ ਬੱਗ ਟ੍ਰਾਇਏਜ: ਤੇਜ਼ ਸੁਧਾਰਾਂ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਲੂਪ
Claude Code ਨਾਲ ਬੱਗ ਟ੍ਰਾਇਏਜ ਲਈ ਇਕ ਦੁਹਰਾਉਣਯੋਗ ਲੂਪ: ਰਿਪ੍ਰੋਡਿਊਸ, ਮਿਨੀਮਾਈਜ਼, ਸੰਭਾਵਿਤ ਕਾਰਨ ਨਿਰਧਾਰਿਤ ਕਰੋ, ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਜੋੜੋ, ਅਤੇ ਚੈੱਕ-ਸਹਿਤ ਇੱਕ ਨੈਰੋ ਫਿਕਸ ਸ਼ਿਪ ਕਰੋ।
ਬੱਗ ਟ੍ਰਾਇਏਜ ਕੀ ਹੈ ਅਤੇ ਇਹ ਲੂਪ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
ਜਦੋਂ ਹਰ ਰਿਪੋਰਟ ਇੱਕ ਇਕਲੋਤਾ ਰਹੱਸ ਬਣ ਜਾਂਦੀ ਹੈ ਤਾਂ ਬੱਗੋਂ ਦਾ ਲੱਗਦਾ ਹੈ ਕਿ ਉਹ ਬੇਤਰਤੀਬੀ ਹਨ। ਤੁਸੀਂ ਕੋਡ 'ਤੇ ਝਲਕ ਪਾਉਂਦੇ ਹੋ, ਕੁਝ ਵਿਚਾਰ ਟੈਸਟ ਕਰਦੇ ਹੋ, ਅਤੇ ਉਮੀਦ ਕਰਦੇ ਹੋ ਕਿ ਸਮੱਸਿਆ ਦੂਰ ਹੋ ਜਾਏਗੀ। ਕਈ ਵਾਰੀ ਇਹ ਹੁੰਦਾ ਵੀ ਹੈ, ਪਰ ਤੁਸੀਂ ਬਹੁਤ ਘੱਟ ਸਿਖਦੇ ਹੋ, ਅਤੇ ਉਹੀ ਮੁੱਦਾ ਦੂਜੇ ਰੂਪ ਵਿੱਚ ਮੁੜ ਆ ਜਾਂਦਾ ਹੈ।
ਬੱਗ ਟ੍ਰਾਇਏਜ ਇਸ ਦੇ ਉਲਟ ਹੈ। ਇਹ ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਉਣ ਦਾ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ। ਲਕੜੀ ਸਿੱਧਾ ਹਰ ਚੀਜ਼ ਨੂੰ ਫੌਰਨ ਠੀਕ ਕਰਨਾ ਨਹੀਂ ਹੈ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਇਕ ਧੁੰਦਲੀ ਸ਼ਿਕਾਇਤ ਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ, ਟੈਸਟ ਕਰਨਯੋਗ ਬਿਆਨ ਵਿੱਚ ਬਦਲਣਾ ਹੈ, ਫਿਰ ਸਭ ਤੋਂ ਛੋਟੀ ਚੇਜ਼ ਕਰਨੀ ਜੋ ਉਹ ਬਿਆਨ ਝੂਠਾ ਸਾਬਤ ਕਰ ਦੇਵੇ।
ਇਸ ਲਈ ਲੂਪ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਰਿਪ੍ਰੋਡਿਊਸ ਕਰੋ, ਘੱਟ ਕਰੋ, ਸਬੂਤ-ਆਧਾਰਿਤ ਸੰਭਾਵਿਤ ਕਾਰਨਾਂ ਦੀ ਪਛਾਣ ਕਰੋ, ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਜੋੜੋ, ਇੱਕ ਨੈਰੋ ਫਿਕਸ ਲਾਗੂ ਕਰੋ, ਅਤੇ ਵੈਰੀਫਾਈ ਕਰੋ। ਹਰ ਕਦਮ ਇੱਕ ਖਾਸ ਕਿਸਮ ਦੀ ਅਟਕੇ ਹੋਈ ਸੋਚ-ਧਾਰਾ ਘਟਾਉਂਦਾ ਹੈ। ਕਦਮ ਛੱਡੇ ਜਾ ਜਾਣ ਤਾਂ ਅਕਸਰ ਬਾਅਦ ਵਿੱਚ ਵੱਡੇ ਫਿਕਸ, ਸਾਈਡ-ਇਫੈਕਟ, ਜਾਂ "ਠੀਕ" ਕੀਤੇ ਗਏ ਬੱਗ ਜੋ ਅਸਲ ਵਿੱਚ ਠੀਕ ਨਹੀਂ ਹੋਏ, ਦੇ ਸਾਮ੍ਹਣੇ ਆਉਣੇ ਪੈਂਦੇ ਹਨ।
ਇੱਥੇ ਇੱਕ ਹਕੀਕਤੀ ਨਮੂਨਾ ਹੈ। ਇੱਕ ਯੂਜ਼ਰ ਕਹਿੰਦਾ ਹੈ: “Save ਬਟਨ ਕਦੇ-ਕਦੇ ਕੁਝ ਨਹੀਂ ਕਰਦਾ।” ਬਿਨਾਂ ਲੂਪ ਦੇ ਤੁਸੀਂ UI ਕੋਡ ਵਿੱਚ ਖੋਜ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਟਾਇਮਿੰਗ, ਸਟੇਟ, ਜਾਂ ਨੈਟਵਰਕ ਕਾਲਾਂ ਬਦਲ ਸਕਦੇ ਹੋ। ਲੂਪ ਨਾਲ, ਪਹਿਲਾਂ "ਕਦੇ-ਕਦੇ" ਨੂੰ "ਹਮੇਸ਼ਾ, ਇਹਨਾਂ ਖਾਸ ਸ਼ਰਤਾਂ ਹੇਠ" ਵਿੱਚ ਬਦਲੋ, ਉਦਾਹਰਨ ਵਜੋਂ: “ਟਾਈਟਲ ਐਡਿਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਫਿਰ ਤੇਜ਼ੀ ਨਾਲ ਟੈਬ ਬਦਲਣ ਤੇ, Save ਨਿਰਯਰਕ ਹੋ ਜਾਂਦਾ ਹੈ।” ਉਹ ਇਕ ਵਾਕ ਹੀ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਤਰੱਕੀ ਹੈ।
Claude Code ਸੋਚਣ ਵਾਲਾ ਹਿੱਸਾ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ: ਰਿਪੋਰਟਾਂ ਨੂੰ ਸਹੀ ਅਨੁਮਾਨਾਂ ਵਿੱਚ ਬਦਲਣਾ, ਕਿੱਥੇ ਦੇਖਣਾ ਹੈ ਸੁਝਾਉਣਾ, ਅਤੇ ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਪ੍ਰਸਤਾਵਿਤ ਕਰਨਾ ਜੋ ਫੇਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ ਕੋਡ, ਲੌਗ, ਅਤੇ ਹਾਲੀਆ ਡਿਫਜ਼ ਨੂੰ ਸਕੈਨ ਕਰਕੇ ਤੇਜ਼ੀ ਨਾਲ ਸੰਜਾਣਾ ਕਾਰਨ ਦਿਖਾਉਣ ਲਈ ਮਦਦਗਾਰ ਹੈ।
ਤੁਸੀਂ ਫਿਰ ਵੀ ਉਸਨੂੰ ਸੱਚ ਕਰਕੇ ਜਾਂਚਣਾ ਪਵੇਗਾ ਜੋ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਆਪਣੇ ਵਾਤਾਵਰਨ ਵਿੱਚ ਬੱਗ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਇੱਕ ਚੰਗੀ ਕਹਾਣੀ ਤੋਂ ਜ਼ਿਆਦਾ ਲੌਗ, ਟਰੇਸ, ਫੇਲ ਹੋਏ ਟੈਸਟ ਵਰਗਾ ਸਬੂਤ ਪਸੰਦ ਕਰੋ। ਫਿਕਸ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਰੱਖੋ, ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਨਾਲ ਇਸਨੂੰ ਸਾਬਤ ਕਰੋ, ਅਤੇ ਸਪੱਸ਼ਟ ਚੈੱਕਾਂ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਇੱਕ ਹੋਰ ਬੱਗ ਨਹੀਂ ਲਿਆ ਰਹੇ।
ਨਤੀਜਾ ਇਕ ਛੋਟਾ, ਸੁਰੱਖਿਅਤ ਫਿਕਸ ਹੈ ਜੋ ਤੁਸੀਂ ਵੇਖਾ ਅਤੇ ਬਚਾ ਸਕਦੇ ਹੋ।
ਟ੍ਰਾਇਏਜ ਵਰਕਸਪੇਸ ਸੈਟਅਪ ਕਰੋ (ਕੋਡ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ)
ਚੰਗੇ ਫਿਕਸ ਇੱਕ ਸਾਫ਼ ਵਰਕਸਪੇਸ ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟ ਸਮੱਸਿਆ ਬਿਆਨ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ। Claude ਨੂੰ ਕੁਝ ਪੁੱਛਣ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਰਿਪੋਰਟ ਚੁਣੋ ਅਤੇ ਇਸਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦੁਬਾਰਾ ਲਿਖੋ:
“ਜਦੋਂ ਮੈਂ X ਕਰਦਾ/ਦੀ ਹਾਂ, ਮੈਂ ਉਮੀਦ ਕਰਦਾ/ਦੀ ਹਾਂ Y, ਪਰ ਮੈਨੂੰ Z ਮਿਲਦਾ ਹੈ।”
ਜੇ ਤੁਸੀਂ ਉਹ ਵਾਕ ਨਹੀਂ ਲਿਖ ਸਕਦੇ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਅਜੇ ਬੱਗ ਨਹੀਂ ਹੈ—ਇੱਕ ਰਹੱਸ ਹੈ।
ਆਰੰਭ ਵਿੱਚ ਬੁਨਿਆਦੀ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਮੁੜ ਮੁੜ ਪਿੱਛੇ ਨਾ ਭੱਜੋ। ਇਹ ਵੇਰਵੇ ਸੁਝਾਵਾਂ ਨੂੰ ਟੈਸਟ ਕਰਨਯੋਗ ਬਣਾਉਂਦੇ ਹਨ ਨਾ ਕਿ ਧੁੰਦਲੇ: ਐਪ ਵਰਜ਼ਨ ਜਾਂ ਕਮੇਟ (ਅਤੇ ਇਹ ਲੋਕਲ, ਸਟੇਜਿੰਗ ਜਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਹੈ), ਵਾਤਾਵਰਨ ਵੇਰਵੇ (OS, ਬ੍ਰਾਉਜ਼ਰ/ਡਿਵਾਈਸ, ਫੀਚਰ ਫਲੈਗ, ਖੇਤਰ), ਬਿਲਕੁਲ ਸਹੀ ਇਨਪੁਟ (ਫਾਰਮ ਫੀਲਡ, API ਪੇਲੋਡ, ਯੂਜ਼ਰ ਕਾਰਵਾਈਆਂ), ਕੌਣ ਵੇਖਦਾ ਹੈ (ਸਭ, ਇੱਕ ਰੋਲ, ਇੱਕ ਖਾਤਾ/ਟੇਨੈਂਟ), ਅਤੇ "ਉਮੀਦ ਕੀ ਹੈ" ਦਾ ਮਤਲਬ ਕੀ ਹੈ (ਕਾਪੀ, UI ਸਟੇਟ, ਸਟੇਟਸ ਕੋਡ, ਬਿਜਨਸ ਨਿਯਮ)।
ਫਿਰ ਸਬੂਤ ਸੰਭਾਲੋ ਜਦੋਂ ਉਹ ਤਾਜ਼ਾ ਹੋ। ਇੱਕ ਹੀ ਟਾਇਮਸਟੈਂਪ ਘੰਟਿਆਂ ਬਚਾ ਸਕਦਾ ਹੈ। ਇਵੈਂਟ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਲੌਗਜ਼ ਕੈਪਚਰ ਕਰੋ (ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਜੇ ਸਮਭਵ ਹੋਵੇ), ਸਕਰੀਨਸ਼ਾਟ ਜਾਂ ਛੋਟੇ ਰਿਕਾਰਡਿੰਗ, ਰਿਕਵੈਸਟ ID ਜਾਂ ਟਰੇਸ ID, ਬਿਲਕੁਲ ਟਾਈਮਸਟੈਂਪ (ਟਾਈਮਜ਼ੋਨ ਸਮੇਤ), ਅਤੇ ਉਹ ਸਭ ਤੋਂ ਛੋਟਾ ਡੇਟਾ ਸਨਿੱਪੇਟ ਜੋ ਮੁੱਦਾ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ।
ਉਦਾਹਰਨ: ਇੱਕ Koder.ai-ਜਨਰੇਟਡ React ਐਪ "Payment succeeded" ਦਿਖਾਉਂਦੀ ਹੈ ਪਰ ਆਰਡਰ "Pending" ਰਹਿੰਦਾ ਹੈ। ਯੂਜ਼ਰ ਰੋਲ, ਬਿਲਕੁਲ ਆਰਡਰ ID, API ਰਿਸਪਾਂਸ ਬਾਡੀ, ਅਤੇ ਉਸ ਰਿਕਵੈਸਟ ID ਲਈ ਸਰਵਰ ਲੌਗ ਲਾਈਨਾਂ ਨੋਟ ਕਰੋ। ਹੁਣ ਤੁਸੀਂ Claude ਨੂੰ ਇੱਕ ਫਲੋ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਕਰਨ ਲਈ ਕਹਿ ਸਕਦੇ ਹੋ ਬਦਲੇ ਵਿੱਚ ਹੱਥ ਹਿਲਾਉਣ ਦੇ।
ਅਖੀਰ 'ਚ ਇੱਕ ਰੋਕਣ ਨਿਯਮ ਤੈਅ ਕਰੋ। ਕੋਡ ਲਿਖਣਾ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਕੀ ਗਿਣਿਆ ਜਾਵੇਗਾ ਕਿ ਫਿਕਸ ਹੋ ਗਿਆ: ਇੱਕ ਖਾਸ ਟੈਸਟ ਪਾਸ ਹੋਣਾ, UI ਸਟੇਟ ਦਾ ਬਦਲਣਾ, ਲੌਗ ਵਿੱਚ ਤੇਕ ਕੋਈ ਗਲਤੀ ਹੋਣਾ ਨਾ ਰਹਿਣਾ, ਅਤੇ ਇੱਕ ਛੋਟਾ ਵੈਰੀਫਿਕੇਸ਼ਨ ਚੈੱਕਲਿਸਟ ਜੋ ਤੁਸੀਂ ਹਰ ਵਾਰੀ ਚਲਾਓਗੇ। ਇਹ ਤੁਹਾਨੂੰ ਲੱਛਣ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਥਾਂ ਸਿਰਫ ਲੱਛਣ ਨੂੰ ਠੀਕ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।
Claude ਲਈ ਰਿਪੋਰਟ ਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ ਪ੍ਰਸ਼ਨ ਵਿੱਚ ਬਦਲੋ
ਇੱਕ ਗੰਦੇ ਬੱਗ ਰਿਪੋਰਟ ਅਕਸਰ ਤਥ, ਅਨੁਮਾਨ ਅਤੇ ਨਿਰਾਸ਼ਾ ਮਿਲਾ ਦਿੰਦੀ ਹੈ। ਮਦਦ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਸਨੂੰ ਇੱਕ ਤਿੱਖੇ ਪ੍ਰਸ਼ਨ ਵਿੱਚ ਬਦਲੋ ਜਿਸਦਾ Claude ਸਬੂਤ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕੇ।
ਫੀਚਰ ਅਤੇ ਫੇਲਿਊਰ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੋਈ ਇੱਕ ਇਕ ਵਾਕ ਸੰਖੇਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਚੰਗਾ: “ਡਰਾਫਟ ਸੇਵ ਕਰਦੇ ਸਮੇਂ ਕਦੇ-ਕਦੇ ਮੋਬਾਈਲ 'ਤੇ ਟਾਈਟਲ ਡਿਲੀਟ ਹੋ ਜਾਂਦਾ ਹੈ।” ਬੁਰਾ: “ਡਰਾਫਟ ਟੁੱਟੇ ਹੋਏ ਹਨ।” ਉਹ ਵਾਕ ਪੂਰੇ ਟ੍ਰਾਇਏਜ ਥ੍ਰੈਡ ਲਈ ਐਂਕਰ ਬਣ ਜਾਂਦਾ ਹੈ।
ਫਿਰ ਜੋ ਤੁਸੀਂ ਵੇਖਿਆ ਉਹਨੂੰ ਉਮੀਦ ਤੋਂ ਵੱਖ ਕਰੋ। ਨਿਰਪੱਖ ਅਤੇ ਸਪੱਸ਼ਟ ਰੱਖੋ: ਤੁਸੀਂ ਕਿਹੜਾ ਬਟਨ ਕਲਿਕ ਕੀਤਾ, ਸਕਰੀਨ 'ਤੇ ਕੀ ਸੁਨੇਹਾ ਸੀ, ਲੌਗ ਲਾਈਨ, ਟਾਈਮਸਟੈਂਪ, ਡਿਵਾਈਸ, ਬ੍ਰਾਉਜ਼ਰ, ਬ੍ਰਾਂਚ, ਕਮੇਟ। ਜੇ ਇਹ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹ ਆਖੋ।
ਇੱਕ ਸਧਾਰਣ ਸਟ੍ਰੱਕਚਰ ਜੋ ਤੁਸੀਂ ਪੇਸਟ ਕਰ ਸਕਦੇ ਹੋ:
- Summary (one sentence)
- Observed behavior (what happened, including any error text)
- Expected behavior (what should happen)
- Repro steps (numbered, smallest set you know)
- Environment (app version, device, OS, browser, config flags)
ਜੇ ਵੇਰਵੇ ਗੁੰਦੇ ਹਨ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਹਾਂ/ਨਹੀਂ ਪ੍ਰਸ਼ਨਾਂ ਵਜੋਂ ਪੁੱਛੋ ਤਾਂ ਜੋ ਲੋਕ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕਣ: ਕੀ ਇਹ ਫ੍ਰੈਸ਼ ਖਾਤੇ 'ਤੇ ਹੁੰਦਾ ਹੈ? ਸਿਰਫ ਮੋਬਾਈਲ 'ਤੇ? ਸਿਰਫ ਰੀਫਰੇਸ਼ ਕਰਨ ਤੋਂ ਬਾਅਦ? ਕੀ ਇਹ ਆਖਰੀ ਰਿਲੀਜ਼ ਤੋਂ ਬਾਅਦ ਸ਼ੁਰੂ ਹੋਇਆ? ਕਿ ਤੁਸੀਂ ਇੰਕੋਗਨੀਟੋ 'ਚ ਦੁਹਰਾਉ ਸਕਦੇ ਹੋ?
Claude ਨੂੰ ਇੱਕ “ਰਿਪੋਰਟ ਕਲੀਨਰ” ਵਜੋਂ ਵੀ ਵਰਤੋਂ। ਅਸਲ ਰਿਪੋਰਟ ਪੇਸਟ ਕਰੋ (ਸਕਰੀਨਸ਼ਾਟ ਤੋਂ ਨਕਲ ਕੀਤਾ ਟੈਕਸਟ, ਲੌਗ, ਚੈਟ ਟੁਕੜੇ ਸਮੇਤ), ਫਿਰ ਕਹੋ:
“ਇਸਨੂੰ ਇੱਕ ਸਟ੍ਰੱਕਚਰਡ ਚੈਕਲਿਸਟ ਵਜੋਂ ਦੁਬਾਰਾ ਲਿਖੋ। ਵਿਰੋਧਾਂ ਨੂੰ ਫਲੈਗ ਕਰੋ। 5 ਸੋਂਚੜੇ ਹੋਏ ਘੱਟੋ-ਘੱਟ ਤਥ ਨੂੰ ਹਾਂ/ਨਹੀਂ ਪ੍ਰਸ਼ਨਾਂ ਵਜੋਂ ਲਿਖੋ। ਹੁਣ ਕਾਰਨਾਂ ਬਾਰੇ ਅਨੁਮਾਨ ਨਾ ਲਗਾਓ।”
ਜੇ ਕੋਈ ਟੀਮਮੇਟ ਕਹਿੰਦਾ ਹੈ “ਇਹ ਬੇਤਰਤੀਬੀ ਹੈ,” ਤਾਂ ਇਸਨੂੰ ਟੈਸਟ ਕਰਨਯੋਗ ਚੀਜ਼ ਵੱਲ ਧੱਕੋ: “iPhone 14, iOS 17.2 'ਤੇ 2/10 ਵਾਰੀ ਫੇਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ Save ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਦਬਾਇਆ ਜਾਵੇ।” ਹੁਣ ਤੁਸੀਂ ਇਸਨੂੰ ਮਨਸ਼ਾ-ਪੂਰਵਕ ਦੁਹਰਾਉ ਸਕਦੇ ਹੋ।
ਕਦਮ 1 - ਬੱਗ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਦੁਹਰਾਓ
ਜੇ ਤੁਸੀਂ ਬੱਗ ਨੂੰ ਮੰਗੇ ਉੱਤੇ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਹਰ ਅਗਲਾ ਕਦਮ ਅਨੁਮਾਨ ਹੀ ਹੈ।
ਸਭ ਤੋਂ ਛੋਟੇ ਵਾਤਾਵਰਨ ਵਿੱਚ ਰਿਪ੍ਰੋ ਕਰਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਫਿਰ ਵੀ ਸਮੱਸਿਆ ਦਿਖਾ ਸਕੇ: ਲੋਕਲ ਡੈਵ ਬਿਲਡ, ਇੱਕ ਛੋਟੀ ਸ਼ਾਖਾ, ਇੱਕ ਛੋਟਾ ਡੇਟਾ ਸੈੱਟ, ਅਤੇ ਸੰਭਵਤ: ਘੱਟ ਤੋਂ ਘੱਟ ਸਰਵਿਸز।
ਠੀਕ-ਠਾਕ ਕਦਮ ਲਿਖੋ ਤਾਂ ਜੋ ਕੋਈ ਹੋਰ ਬਿਨਾ ਪੁੱਛੇ ਅਨੁਕਰਨ ਕਰ ਸਕੇ। ਕਾਪੀ-ਪੇਸਟ-ਅਨੁਕੂਲ ਬਣਾਓ: ਕਮਾਂਡ, IDs, ਅਤੇ ਨਮੂਨਾ ਪੇਲੋਡ ਬਿਲਕੁਲ ਜਿਵੇਂ ਵਰਤੇ ਗਏ ਸ਼ਾਮਿਲ ਕਰੋ।
ਇੱਕ ਸਧਾਰਣ ਕੈਪਚਰ ਟੇਮਪਲੇਟ:
- Setup: branch/commit, config flags, database state (empty, seeded, production copy)
- Steps: numbered actions with exact inputs
- Expected vs actual: what you thought would happen, what happened instead
- Evidence: error text, screenshots, timestamps, request IDs
- Frequency: always, sometimes, first run only, only after a refresh
ਫ੍ਰਿਕਵੈਂਸੀ ਤੁਹਾਡੀ ਯੁਕਤਿ ਨੂੰ ਬਦਲਦੀ ਹੈ। “ਹਮੇਸ਼ਾ” ਬੱਗ ਤੇਜ਼ ਇੱਟਰੇਸ਼ਨ ਲਈ ਵਧੀਆ ਹਨ। “ਕਦੇ-ਕਦੇ” ਬੱਗ ਅਕਸਰ ਟਾਇਮਿੰਗ, ਕੈਸ਼ਿੰਗ, ਰੇਸ ਕੰਡੀਸ਼ਨ, ਜਾਂ ਛੁਪੇ ਹੋਏ ਸਟੇਟ ਵੱਲ ਸੰਗੇਤ ਦਿੰਦੇ ਹਨ।
ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਰਿਪ੍ਰੋ ਨੋਟਸ ਹੁੰਦੀਆਂ ਹਨ, Claude ਤੋਂ ਤੁਰੰਤ ਪ੍ਰੋਬਜ਼ ਮੰਗੋ ਜੋ ਐਪ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਤੋਂ ਬਿਨਾਂ ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਉਣ। ਵਧੀਆ ਪ੍ਰੋਬਜ਼ ਛੋਟੇ ਹੁੰਦੇ ਹਨ: ਫੇਲਿੰਗ ਸੀਮਾ 'ਚ ਇੱਕ ਨਿਸ਼ਾਨਦਾਰ ਲੌਗ ਲਾਈਨ (ਇਨਪੁਟ, ਆਉਟਪੁਟ, ਮੁੱਖ ਸਟੇਟ), ਇਕ ਸਿੰਗਲ ਕੰਪੋਨੈਂਟ ਲਈ ਡੀਬੱਗ ਫਲੈਗ, ਤਨੁੱਖੀ ਵਰਿਆਬਲ ਨੂੰ ਡੀਟੈਰਮਿਨਿਸਟਿਕ ਬਣਾਉਣ ਦਾ ਤਰੀਕਾ (ਫਿਕਸ ਰੈਂਡਮ ਸੀਡ, ਫਿਕਸ ਟਾਈਮ), ਇੱਕ ਛੋਟਾ ਸੀਡ ਡੇਟਾ ਜੋ ਮੁੱਦਾ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ, ਜਾਂ ਦੁਹਰਾਉਣ ਲਈ ਇੱਕ ਇਕੱਲਾ ਰਿਕਵੈਸਟ/ਰਿਸਪਾਂਸ ਜੋ ਜੋਧਿਆ ਜਾ ਸਕੇ।
ਉਦਾਹਰਨ: ਸਾਈਨਅੱਪ ਫਲੋ “ਕਦੇ-ਕਦੇ” ਫੇਲ ਹੁੰਦਾ ਹੈ। Claude ਸ਼ਾਇਦ ਸੁਝਾਅ ਦੇਵੇ ਕਿ ਜੇਨਰੇਟ ਕੀਤੀ ਯੂਜ਼ਰ ID, ਈਮੇਲ ਨਾਰਮਲਾਈਜ਼ੇਸ਼ਨ ਨਤੀਜਾ, ਅਤੇ ਯੂਨੀਕ ਕਨਸਟ੍ਰੇਂਟ ਐਰਰ ਵੇਰਵੇ ਲੌਗ ਕਰੋ, ਫਿਰ ਇੱਕੋ ਪੇਲੋਡ 10 ਵਾਰੀ ਚਲਾਓ। ਜੇ ਫੇਲ ਸਿਰਫ ਡਿਪਲੌਇ ਤੋਂ ਬਾਅਦ ਪਹਿਲੀ ਵਾਰੀ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਮਾਈਗ੍ਰੇਸ਼ਨ, ਕੈਸ਼ ਵਾਰਮਅਪ, ਜਾਂ ਗੁੰਮ ਸੀਡ ਡੇਟਾ ਵੱਲ ਸਨਕੇਤ ਦਿੰਦੀ ਹੈ।
ਕਦਮ 2 - ਛੋਟੀ, ਦੁਹਰਾਊ ਟੈਸਟ ਕੇਸ ਲਈ ਘਟਾਓ
ਸਨੈਪਸ਼ਾਟ ਨਾਲ ਸੁਰੱਖਿਅਤ ਡੀਬੱਗਿੰਗ
ਮੁਫ਼ਤ ਤੌਰ 'ਤੇ ਪ੍ਰਯੋਗ ਕਰੋ, ਫਿਰ ਜੇ ਸੁਧਾਰ ਗਲਤ ਹੋਵੇ ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਰੋਲਬੈਕ ਕਰੋ।
ਚੰਗੀ ਰਿਪ੍ਰੋ ਯੂਜ਼ਮਦਾ ਹੈ। ਇੱਕ ਨਿਊਨਤਮ ਰਿਪ੍ਰੋਸ਼ਨ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ। ਇਹ ਬੱਗ ਨੂੰ ਸਮਝਣਾ ਤੇਜ਼ ਕਰਦਾ ਹੈ, ਡੀਬੱਗ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ “ਆਕਸਮਾਤ” ਫਿਕਸ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਜੋ ਲੋੜੀਂਦਾ ਨਹੀਂ ਹੈ ਉਹ ਸਭ ਹਟਾਉ। ਜੇ ਬੱਗ ਲੰਬੇ UI ਫਲੋ ਦੇ ਬਾਅਦ ਆਉਂਦਾ ਹੈ, ਸਭ ਤੋਂ ਛੋਟਾ ਰਸਤਾ ਲੱਭੋ ਜੋ ਵਾਪਸ ਆਉਂਦਾ ਹੈ। ਵਿਕਲਪਿਕ ਸਕ੍ਰੀਨ, ਫੀਚਰ ਫਲੈਗ, ਅਤੇ ਗੈਰ-ਸੰਬੰਧਤ ਇੰਟੀਗਰੇਸ਼ਨਾਂ ਨੂੰ ਹਟਾਓ ਜਦ ਤੱਕ ਬੱਗ ਛੁਪ ਨਾ ਜਾਵੇ (ਤੁਸੀਂ ਕੁਝ ਜ਼ਰੂਰੀ ਹਟਾ ਦਿੱਤਾ) ਜਾਂ ਜਿਵੇਂ ਹੀ ਇਹ ਰਹਿੰਦਾ ਹੈ (ਤੁਸੀਂ ਸ਼ੋਰ ਵਿੱਚੋਂ ਸੱਚਮੁਚ ਦਾ ਪਤਾ ਲਿਆ)।
ਫਿਰ ਡੇਟਾ ਨੂੰ ਘਟਾਓ। ਜੇ ਬੱਗ ਲਈ ਵੱਡਾ ਪੇਲੋਡ ਲੋੜੀਦਾ ਹੈ, ਤਾਂ ਉਹ ਸਭ ਤੋਂ ਛੋਟਾ ਪੇਲੋਡ ਲੱਭੋ ਜੋ ਫੇਲ ਕਰਦਾ ਹੈ। ਜੇ ਇਹ 500 ਆਈਟਮ ਦੀ ਲਿਸਟ ਲੈਂਦਾ, ਵੇਖੋ ਕਿ 5 ਫੇਲ ਕਰਦੇ ਹਨ, ਫਿਰ 2, ਫਿਰ 1। ਫੀਲਡ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਹਟਾਓ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਸਭ ਤੋਂ ਘੱਟ ਮੋਵਿੰਗ ਪਾਰਟਾਂ ਨਾਲ ਬੱਗ ਨੂੰ ਰੋਕਣਾ ਹੈ।
“ਅੱਧਾ ਹਟਾਓ ਅਤੇ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰੋ” ਇਕ ਵਰਤੋਂਯੋਗ ਤਰੀਕਾ ਹੈ:
- ਕਦਮਾਂ ਨੂੰ ਅੱਧਾ ਕਰੋ ਅਤੇ ਦੇਖੋ ਕਿ ਬੱਗ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
- ਜੇ ਹਾਂ, ਬਚੇ ਹੋਏ ਹਿੱਸੇ ਨੂੰ ਰੱਖੋ ਅਤੇ ਫੇਰ ਕੱਟੋ।
- ਜੇ ਨਹੀਂ, ਜੋ ਤੁਸੀਂ ਹਟਾਇਆ ਉਸ ਵਿੱਚੋਂ ਅੱਧਾ ਵਾਪਸ ਲਿਆਓ ਅਤੇ ਫੇਰ ਕੱਟੋ।
- ਜਦ ਤੱਕ ਤੁਸੀਂ ਕੁਝ ਵੀ ਹਟਾਉਣ ਤੋਂ ਬਿਨਾਂ ਬੱਗ ਨਹੀਂ ਗੁੰਮ ਹੁੰਦਾ, ਦੁਹਰਾਓ।
ਉਦਾਹਰਨ: ਇੱਕ ਚੈੱਕਆਊਟ ਪੇਜ “ਕਦੇ-ਕਦੇ” ਕ੍ਰੈਸ਼ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕੂਪਨ ਲਗਾਇਆ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਪਤਾ ਲਗਾਉਂਦੇ ਹੋ ਕਿ ਇਹ ਸਿਰਫ ਤਦੋਂ ਫੇਲ ਹੁੰਦਾ ਹੈ ਜਦ ਕਾਰਟ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਇਕ ਛੂਟ ਵਾਲੀ ਆਈਟਮ ਹੋਵੇ, ਕੂਪਨ ਨੀਵ-ਅੱਖਰਾਂ ਵਿੱਚ ਹੋਵੇ, ਅਤੇ ਸ਼ਿਪਿੰਗ “ਪਿਕਅੱਪ” ਤੇ ਸੈਟ ਹੋਵੇ। ਇਹ ਤੁਹਾਡਾ ਨਿਊਨਤਮ ਕੇਸ ਹੈ: ਇੱਕ ਛੂਟ ਵਾਲੀ ਆਈਟਮ, ਇੱਕ ਨੀਵ-ਅੱਖਰ ਕੂਪਨ, ਇੱਕ ਪਿਕਅੱਪ ਵਿਕਲਪ।
ਜਦ ਨਿਊਨਤਮ ਕੇਸ ਸਪੱਸ਼ਟ ਹੋ, Claude ਨੂੰ ਕਹੋ ਕਿ ਉਹ ਇਸਨੂੰ ਇੱਕ ਛੋਟੇ ਰਿਪ੍ਰੋ ਸਕੈਫੋਲਡ ਵਿੱਚ ਬਦਲੇ: ਇੱਕ ਨਿਊਨਤਮ ਟੈਸਟ ਜੋ ਫੇਲਿੰਗ ਫੰਕਸ਼ਨ ਨੂੰ ਛੋਟੇ ਇਨਪੁੱਟ ਨਾਲ ਕਾਲ ਕਰਦਾ ਹੈ, ਇੱਕ ਛੋਟਾ ਸਕ੍ਰਿਪਟ ਜੋ ਘੱਟ ਪੇਲੋਡ ਨਾਲ ਇੱਕ ਐਂਡਪੌਇੰਟ ਨੂੰ ਹਿੱਟ ਕਰਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਨਾਨੂ UI ਟੈਸਟ ਜੋ ਇੱਕ ਰੂਟ ਵੇਜ਼ਿਟ ਕਰਦਾ ਅਤੇ ਇੱਕ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ।
ਕਦਮ 3 - ਸੰਭਾਵਿਤ ਰੂਟ ਕਾਰਨ ਦੀ ਪਛਾਣ ਕਰੋ (ਸਬੂਤ ਨਾਲ)
ਜਦ ਤੁਸੀਂ ਸਮੱਸਿਆ ਨੂੰ ਦੁਹਰਾਉ ਸਕਦੇ ਹੋ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਕੇਸ ਹੈ, ਤਾਂ ਅਨੁਮਾਨ ਲਾਉਣਾ ਛੱਡ ਦਿਓ। ਤੁਹਾਡਾ ਲਕੜੀ ਉਦੇਸ਼ ਇੱਕ ਛੋਟੀ ਸੂਚੀ 'ਤੇ ਆਉਣਾ ਹੈ ਜੋ ਸੰਭਾਵਿਤ ਕਾਰਨਾਂ ਦੀ ਹੈ, ਫਿਰ ਹਰ ਇੱਕ ਨੂੰ ਸਾਬਤ ਜਾਂ ਖੰਡਿਤ ਕਰੋ।
ਇੱਕ ਕਾਰਗਰ ਨਿਯਮ ਹੈ ਕਿ ਇਸਨੂੰ ਤਿੰਨ ਹਾਇਪੋਥੇਸਿਸ ਤੱਕ ਰੱਖੋ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਇਸ ਤੋਂ ਵੱਧ ਹਨ, ਤਾਂ ਤੁਹਾਡਾ ਟੈਸਟ ਕੇਸ ਸ਼ਾਇਦ ਅਜੇ ਵੀ ਬੜਾ ਹੈ ਜਾਂ ਤੁਹਾਡੇ ਪ੍ਰੇਖਣ ਧੁੰਦਲੇ ਹਨ।
ਲੱਛਣਾਂ ਨੂੰ ਕੰਪੋਨੈਂਟਾਂ ਨਾਲ ਜੋੜੋ
ਜੋ ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ ਉਸਨੂੰ ਇਸ ਗੱਲ ਵਿੱਚ ਬਦਲੋ ਕਿ ਇਹ ਕਿੱਥੇ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ UI ਲੱਛਣ ਹਮੇਸ਼ਾ UI ਬੱਗ ਨਹੀਂ ਹੁੰਦਾ।
ਉਦਾਹਰਨ: ਇੱਕ React ਪੰਨਾ "Saved" ਟੋਸਟ ਦਿਖਾਉਂਦਾ ਹੈ, ਪਰ ਰਿਕਾਰਡ ਬਾਅਦ ਵਿੱਚ ਲਾਪਤਾ ਹੈ। ਇਹ (1) UI ਸਟੇਟ, (2) API ਵਿਵਹਾਰ, ਜਾਂ (3) ਡੇਟਾਬੇਸ ਰਾਈਟ ਪਾਥ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਸਕਦਾ ਹੈ।
ਹਰ ਅਨੁਮਾਨ ਲਈ ਸਬੂਤ ਬਣਾਓ
Claude ਨੂੰ ਪੁੱਛੋ ਕਿ ਸੰਭਾਵਿਤ ਫੇਲ ਮੋਡ ਦਰਸਾਉਂਦਾ ਹੈ ਸਧਾਰਣ ਭਾਸ਼ਾ ਵਿੱਚ, ਫਿਰ ਪੁੱਛੋ ਕਿ ਹਰ ਇੱਕ ਦੀ ਪੁਸ਼ਟੀ ਲਈ ਕੀ ਵੇਖਣਾ ਚਾਹੀਦਾ। ਲਕੜੀ ਦਾ ਉਦੇਸ਼ “ਸ਼ਾਇਦ” ਨੂੰ “ਇਹ ਨਿਰਦਿਸ਼ਟ ਚੀਜ਼ ਚੈੱਕ ਕਰੋ” ਵਿੱਚ ਬਦਲਣਾ ਹੈ।
ਤਿੰਨ ਆਮ ਹਾਇਪੋਥੇਸਿਸ ਅਤੇ ਹਰ ਇੱਕ ਲਈ ਇਕ ਸਬੂਤ:
- UI/state mismatch: ਕਲਾਇੰਟ ਸਰਵਰ ਦੀ ਪੁਸ਼ਟੀ ਤੋਂ ਪਹਿਲਾਂ ਲੋਕਲ ਸਟੇਟ ਅੱਪਡੇਟ ਕਰ ਦਿੰਦਾ ਹੈ। ਸਬੂਤ: ਕਾਰਵਾਈ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਸਟੇਟ ਸਨੈਪਸ਼ਾਟ ਲਵੋ, ਅਤੇ ਇਸਨੂੰ ਅਸਲ API ਰਿਸਪਾਂਸ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
- API edge case: ਹੈਂਡਲਰ 200 ਰਿਟਰਨ ਕਰਦਾ ਹੈ ਪਰ ਚੁੱਪ ਚਾਪ ਕੰਮ ਛੱਡ ਦਿੰਦਾ ਹੈ (ਵੈਧਤਾ, ID ਪਾਰਸਿੰਗ, ਫੀਚਰ ਫਲੈਗ)। ਸਬੂਤ: ਕੋਰਲੇਸ਼ਨ IDs ਵਾਲੇ ਰਿਕਵੈਸਟ/ਰਿਸਪਾਂਸ ਲੌਗ ਜੋੜੋ, ਅਤੇ ਜਾਂਚੋ ਕਿ ਹੈਂਡਲਰ ਲਿਖਾਈ ਕਾਲ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਕਿ ਨਹੀਂ।
- ਡੇਟਾਬੇਸ ਜਾਂ ਟਾਇਮਿੰਗ ਮੁੱਦਾ: ਇੱਕ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਰੋਲਬੈਕ ਹੋ ਜਾਂਦਾ ਹੈ, ਇੱਕ ਕਨਫਲਿਕਟ ਐਰਰ ਹੁੰਦਾ ਹੈ, ਜਾਂ "ਰੀਡ ਆਫਟਰ ਰਾਈਟ" ਕੈਸ਼/ਰੇਪਲਿਕਾ ਤੋਂ ਸਰਵ ਹੁੰਦਾ ਹੈ। ਸਬੂਤ: DB ਕੁਐਰੀ ਅਤੇ ਪ੍ਰਭਾਵਿਤ ਰੋਜ਼ ਦੀ ਜਾਂਚ ਕਰੋ; ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਸੀਮਾਵਾਂ ਅਤੇ ਰੀਟ੍ਰਾਈ ਵਿਵਹਾਰ ਲੌਗ ਕਰੋ।
ਆਪਣੇ ਨੋਟਾਂ ਨੂੰ ਸਖਤ ਰੱਖੋ: ਲੱਛਣ, ਹਾਇਪੋਥੇਸਿਸ, ਸਬੂਤ, ਫੈਸਲਾ। ਜਦ ਇਕ ਅਨੁਮਾਨ ਤੱਥਾਂ ਨਾਲ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਲੌਕ ਕਰਨ ਅਤੇ ਸਿਰਫ਼ ਲੋੜੀਂਦੇ ਚੀਜ਼ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋ।
ਕਦਮ 4 - ਇੱਕ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਜੋ ਸਹੀ ਕਾਰਨ ਲਈ ਫੇਲ ਹੁੰਦਾ ਹੈ ਜੋੜੋ
ਇੱਕ ਚੰਗਾ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਤੁਹਾਡਾ ਸੇਫਟੀ ਬੈਲਟ ਹੈ। ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਬੱਗ ਮੌਜੂਦ ਸੀ, ਅਤੇ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸ ਨੂੰ ਸੱਚਮੁਚ ਠੀਕ ਕੀਤਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਸ਼ੁਰੂ ਕਰੋ ਸਭ ਤੋਂ ਛੋਟੇ ਟੈਸਟ ਨਾਲ ਜੋ ਅਸਲ ਫੇਲ ਨੂੰ ਮਿਲਦਾ ਹੋਵੇ। ਜੇ ਬੱਗ ਸਿਰਫ਼ ਕਈ ਭਾਗਾਂ ਦੇ ਇਕੱਠੇ ਹੋਣ 'ਤੇ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਯੂਨਿਟ ਟੈਸਟ ਉਸਨੂੰ ਨਹੀਂ ਫੜੇਗਾ।
ਟੈਸਟ ਪੱਧਰ ਚੁੱਕੋ ਜੋ ਬੱਗ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ
ਇੱਕ ਫੰਕਸ਼ਨ ਗਲਤ ਮੁੱਲ ਰਿਟਰਨ ਕਰ ਰਿਹਾ ਹੈ ਤਾਂ ਯੂਨਿਟ ਟੈਸਟ ਵਰਤੋਂ। ਜੇ ਬਾਊਂਡਰੀਸ ਸਮੱਸਿਆ ਹੈ (API ਹੈਂਡਲਰ + DB, ਜਾਂ UI + API) ਤਾਂ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਟੈਸਟ ਵਰਤੋਂ। ਸਿਰਫ ਜਦੋਂ ਪੂਰਾ ਯੂਜ਼ਰ ਫਲੋ ਜ਼ਰੂਰੀ ਹੋਵੇ ਤਾਂ ਏ2ਏ।
Claude ਨੂੰ ਕੁਝ ਵੀ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ, ਨਿਊਨਤਮ ਕੇਸ ਨੂੰ ਇੱਕ ਸਖਤ ਉਮੀਦ ਵਜੋਂ ਦੁਹਰਾਉ: ਉਦਾਹਰਨ: “ਜਦ ਯੂਜ਼ਰ ਖਾਲੀ ਟਾਈਟਲ ਸੇਵ ਕਰਦਾ ਹੈ, API ਨੂੰ 400 ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਸੁਨੇਹਾ ‘title required’ ਨਾਲ।” ਹੁਣ ਟੈਸਟ ਦਾ ਇੱਕ ਸਪੱਸ਼ਟ ਨਿਸ਼ਾਨ ਹੈ।
ਫਿਰ Claude ਤੋਂ ਪਹਿਲਾਂ ਫੇਲ ਹੋਣ ਵਾਲਾ ਟੈਸਟ ਡਰਾਫਟ ਕਰਵਾਓ। ਸੈਟਅਪ ਘੱਟੋ-ਘੱਟ ਰੱਖੋ ਅਤੇ ਕੇਵਲ ਉਹ ਡੇਟਾ ਕਾਪੀ ਕਰੋ ਜੋ ਬੱਗ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ। ਟੈਸਟ ਦਾ ਨਾਮ ਉਪਭੋਗਤਾ ਦੇ ਅਨੁਭਵ ਦੇ ਨਾਂ 'ਤੇ ਰੱਖੋ, ਨਾ ਕਿ ਅੰਦਰੂਨੀ ਫੰਕਸ਼ਨ ਤੇ।
ਡਰਾਫਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ (ਅੰਧੇ-ਭਰੋਸੇ ਨਾ ਰੱਖੋ)
ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ ਜਾਂਚ ਕਰੋ:
- ਪੱਕਾ ਕਰੋ ਕਿ ਇਹ ਵਰਤਮਾਨ ਕੋਡ 'ਤੇ ਸਮਰਥਿਤ ਕਾਰਨ ਲਈ ਫੇਲ ਹੁੰਦਾ ਹੈ (ਕੋਈ ਗੁੰਮ ਫਿਕਸਚਰ ਜਾਂ ਗਲਤ ਇੰਪੋਰਟ ਨਾ ਹੋਵੇ)
- ਅਸਰਸ਼ਨ ਸਪਸ਼ਟ ਹਨ (ਠੀਕ ਸਟੇਟਸ ਕੋਡ, ਸੁਨੇਹਾ, ਦਰਸਾਇਆ ਟੈਕਸਟ)
- ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਟੈਸਟ ਇਕ ਹੀ ਬੱਗ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, ਨਾਂ ਕਿ ਅਨੇਕ ਵਿਵਹਾਰਾਂ ਦਾ ਗੁੱਛ
- ਨਾਮ ਉਪਭੋਗਤਾ-ਕੇਂਦਰਤ ਹੋਵੇ, ਜਿਵੇਂ “rejects empty title on save” ਦੀ ਥਾਂ “rejects empty title” ਹੋ ਸਕਦਾ ਹੈ
ਜਦ ਟੈਸਟ ਉਸੇ ਕਾਰਨ ਲਈ ਫੇਲ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਨੈਰੋ ਫਿਕਸ ਲਾਉਣ ਲਈ ਨਿਸ਼ਚਿਤ ਹੋ।
ਕਦਮ 5 - ਇੱਕ ਨੈਰੋ ਫਿਕਸ ਲਾਗੂ ਕਰੋ
ਰਿਪ੍ਰੋ-ਤਿਆਰ ਐਪ ਬਣਾਓ
ਇੱਕ React ਐਪ ਤੁਰੰਤ ਬਣਾਓ ਅਤੇ ਫੇਲ ਹੋਣ ਵਾਲੀਆਂ ਸਥਿਤੀਆਂ 'ਤੇ ਬਿਨਾਂ ਭਾਰੀ ਸੈਟਅਪ ਦੇ ਇੰਟਰਵੇਟ ਕਰੋ।
ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਛੋਟਾ ਰਿਪ੍ਰੋ ਅਤੇ ਇੱਕ ਫੇਲਿੰਗ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਹੋਵੇ, ਤਾਂ "ਸਾਫ਼-ਸੁਥਰਾ ਕਰ ਦਿਓ" ਦੀ ਖ਼ਾਹਸ਼ ਨੂੰ ਰੋਕੋ। هدف ਸਭ ਤੋਂ ਛੋਟੀ ਚੇਜ਼ ਹੈ ਜੋ ਟੈਸਟ ਨੂੰ ਸਹੀ ਕਾਰਨ ਲਈ ਪਾਸ ਕਰਵੇ।
ਇੱਕ ਚੰਗਾ ਨੈਰੋ ਫਿਕਸ ਸਭ ਤੋਂ ਛੋਟੀ ਸਤਹ ਨੂੰ ਬਦਲਦਾ ਹੈ। ਜੇ ਫੇਲ ਇਕ ਫੰਕਸ਼ਨ ਵਿੱਚ ਹੈ, ਓਸ ਫੰਕਸ਼ਨ ਨੂੰ ਠੀਕ ਕਰੋ, ਪੂਰੇ ਮੋਡੀਊਲ ਨੂੰ ਨਹੀਂ। ਜੇ ਬਾਊਂਡਰੀ ਚੈੱਕ ਗਾਇਬ ਸੀ, ਤਾਂ ਬਾਊਂਡਰੀ 'ਤੇ ਚੈੱਕ ਜੋੜੋ, ਕਾਲ ਚੇਨ ਭਰ ਵਿੱਚ ਨਹੀਂ।
ਜੇ ਤੁਸੀਂ Claude ਦੀ ਮਦਦ ਲੈ ਰਹੇ ਹੋ, ਤਾਂ ਦੋ ਫਿਕਸ ਵਿਕਲਪ ਮੰਗੋ, ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਸਕੋਪ ਅਤੇ ਖ਼ਤਰੇ ਲਈ ਤੁਲਨਾ ਕਰੋ। ਉਦਾਹਰਨ: React ਫਾਰਮ ਖਰਾਬ ਹੋ ਕੇ ਖ਼ਾਲੀ ਫੀਲਡ 'ਤੇ ਕ੍ਰੈਸ਼ ਕਰ ਰਹੀ ਹੈ, ਤਦ ਤੁਸੀਂ ਮਿਲ ਸਕਦੇ ਹੋ:
- ਵਿਕਲਪ A: submit ਹੈਂਡਲਰ ਵਿੱਚ ਇੱਕ ਗਾਰਡ ਜੋੜੋ ਜੋ ਖਾਲੀ ਇਨਪੁਟ ਨੂੰ ਰੋਕੇ ਅਤੇ ਇੱਕ ਐਰਰ ਦਿਖਾਏ।
- ਵਿਕਲਪ B: ਸਟੇਟ ਹੈਂਡਲਿੰਗ ਦਾ ਰੀਫੈਕਟਰ ਕਰੋ ਤਾਂ ਕਿ ਫੀਲਡ ਕਦੇ ਵੀ ਖ਼ਾਲੀ ਨਾ ਰਹੇ।
ਆਮ ਤੌਰ 'ਤੇ ਵਿਕਲਪ A ਟ੍ਰਾਇਏਜ ਚੋਣ ਹੁੰਦਾ ਹੈ: ਛੋਟਾ, ਆਸਾਨ ਰਿਵਿਊ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਹੋਰ ਚੀਜ਼ਾਂ ਤੋੜਨ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੁੰਦੀ ਹੈ।
ਨੈਰੋ ਰੱਖਣ ਲਈ ਘੱਟੋ-ਘੱਟ ਫਾਇਲਾਂ ਨੂੰ ਛੂਹੋ, ਲੋਕਲ ਫਿਕਸਾਂ ਨੂੰ ਰਿਫੈਕਟਰ ਵੱਲ ਤਰਜੀਹ ਦਿਓ, ਗਾਰਡ ਅਤੇ ਵੈਧਤਾ ਜੋੜੋ ਜਿੱਥੋਂ ਖਰਾਬ ਮੁੱਲ ਦਾਖਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਵਿਵਹਾਰ ਬਦਲਾਅ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਪਹਿਲਾਂ/ਬਾਅਦ ਨਾਲ ਰੱਖੋ। ਜਦ ਕਿ ਕਾਰਨ obvious ਨਾ ਹੋਵੇ ਤਾਂ ਹੀ ਟਿੱਪਣੀ ਛੱਡੋ।
ਇਕ ਕਨਕ੍ਰੀਟ ਉਦਾਹਰਨ: ਇੱਕ Go API ਐਂਡਪੌਇੰਟ ਪੈਨਿਕ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਵਿਵਕਲਪਿਕ ਕੁਐਰੀ ਪੈਰਾਮ ਮੌਜੂਦ ਨਹੀਂ ਹੁੰਦਾ। ਨੈਰੋ ਫਿਕਸ ਹੈ ਹੈਂਡਲਰ ਬਾਊਂਡਰੀ 'ਤੇ ਖਾਲੀ ਸਟਰਿੰਗ ਨੂੰ ਸੰਭਾਲਣਾ (ਡਿਫਾਲਟ ਨਾਲ ਪਾਰਸ ਕਰੋ, ਜਾਂ 400 ਰਿਟਰਨ ਕਰੋ ਸਪੱਸ਼ਟ ਸੁਨੇਹਾ ਨਾਲ)। ਸਾਂਝੇ ਪਾਰਸਿੰਗ ਯੂਟਿਲਿਟੀ ਨੂੰ ਬਦਲਣ ਤੱਕ ਨਾ ਜਾਓ ਜਦ ਤੱਕ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਸਾਬਿਤ ਨਾ ਕਰੇ ਕਿ ਸਮੱਸਿਆ ਉਸ ਸਾਂਝੇ ਕੋਡ ਵਿੱਚ ਹੈ।
ਚੇਂਜ ਤੋਂ ਬਾਅਦ, ਫੇਲਿੰਗ ਟੈਸਟ ਅਤੇ ਨੇੜਲੇ ਇੱਕ-ਦੋ ਟੈਸਟਾਂ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਓ। ਜੇ ਤੁਹਾਡਾ ਫਿਕਸ ਬੇਹਿਸਾਬ ਅਣ-ਸੰਬੰਧਤ ਟੈਸਟ ਅਪਡੇਟ ਕਰਨ ਲੱਜ਼ਮੀ ਬਣਾਉਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਿਗਨਲ ਹੈ ਕਿ ਚੇਂਜ ਬਹੁਤ ਵਿਆਪਕ ਹੈ।
ਕਦਮ 6 - ਸਪੱਸ਼ਟ ਚੈੱਕਾਂ ਨਾਲ ਫਿਕਸ ਦੀ ਵੈਰੀਫਿਕੇਸ਼ਨ ਕਰੋ
ਵੈਰੀਫਿਕੇਸ਼ਨ ਉਹ ਰੁਕਾਵਟ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਛੋਟੀ, ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਸਕਣ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਫੜਦੇ ਹੋ: ਇੱਕ ਫਿਕਸ ਜੋ ਇੱਕ ਟੈਸਟ ਪਾਸ ਕਰਵਾਉਂਦਾ ਹੈ ਪਰ ਨੇੜੇ ਰਾਹ ਨੂੰ ਤੋੜਦਾ ਹੈ, ਇੱਕ ਐਰਰ ਸੁਨੇਹਾ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਸੁਸਤ ਕੁਐਰੀ ਜੋੜਦਾ ਹੈ।
ਪਹਿਲਾਂ, ਉਹ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਦੁਬਾਰਾ ਚਲਾਓ ਜੋ ਤੁਸੀਂ ਜੋੜਿਆ ਸੀ। ਜੇ ਇਹ ਪਾਸ ਹੋ ਗਿਆ, ਨੇੜਲੇ-ਨੇੜਲੇ ਟੈਸਟ ਚਲਾਓ: ਓਹੇ ਫਾਇਲ, ਓਹੇ ਮੋਡੀਊਲ, ਅਤੇ ਕੋਈ ਵੀ ਟੈਸਟ ਜੋ ਉਹੀ ਇਨਪੁੱਟ ਕਵਰ ਕਰਦਾ ਹੈ। ਬੱਗ ਅਕਸਰ ਸਾਂਝੇ ਹੈਲਪਰਾਂ, ਪਾਰਸਿੰਗ, ਬਾਊਂਡਰੀ ਚੈਕਾਂ, ਜਾਂ ਕੈਸ਼ਿੰਗ ਵਿੱਚ ਛੁਪਦੇ ਹਨ, ਇਸ ਲਈ ਸਭ ਤੋਂ ਸੰਬੰਧਤ ਫੇਲ ਨੇੜੇ ਹੀ ਮੁਲਾਂਕਣ ਵਿੱਚ ਆਉਂਦੇ ਹਨ।
ਫਿਰ ਮੂਲ ਰਿਪੋਰਟ ਦੇ ਉਹੀ ਕਦਮ ਅਨੁਸਾਰ ਇੱਕ ਛੋਟੀ ਮੈਨੁਅਲ ਚੈੱਕ ਕਰੋ। ਛੋਟਾ ਅਤੇ ਨਿਰਧਾਰਿਤ ਰੱਖੋ: ਉਹੀ ਵਾਤਾਵਰਨ, ਉਹੀ ਡੇਟਾ, ਉਹੀ ਕਲਿੱਕ ਜਾਂ API ਕਾਲਾਂ ਕ੍ਰਮ। ਜੇ ਰਿਪੋਰਟ ਧੁੰਦਲੀ ਸੀ, ਤਾਂ ਉਸ ਖਾਸ ਸਥਿਤੀ ਦੀ ਤੁਸੀਂ ਜਿਨ੍ਹਾਂ ਨਾਲ ਰਿਪ੍ਰੋ ਕੀਤਾ ਸੀ ਉਹੀ ਟੈਸਟ ਕਰੋ।
ਇੱਕ ਸਧਾਰਣ ਵੈਰੀਫਿਕੇਸ਼ਨ ਚੈੱਕਲਿਸਟ
- ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਪਾਸ, ਨਾਲ ਹੀ ਨੇੜਲੇ ਟੈਸਟ ਵੀ
- ਮੈਨੁਅਲ ਰਿਪ੍ਰੋ ਸਟੈਪ ਹੁਣ ਬੱਗ ਟ੍ਰਿਗਰ ਨਹੀਂ ਕਰਦੇ
- ਐਰਰ ਹੈਂਡਲਿੰਗ ਅਜੇ ਵੀ منطقی ਹੈ (ਸੁਨੇਹੇ, ਸਟੇਟਸ ਕੋਡ, ਰੀਟ੍ਰਾਈ)
- ਐਜ ਕੇਸ ਠੀਕ ਰਵੱਈਏ ਦਰਸਾਉਂਦੇ ਹਨ (ਖਾਲੀ ਇਨਪੁਟ, ਮੈਕਸ ਸਾਈਜ਼, ਅਜੀਬ ਕਰੈਕਟਰ)
- ਕੋਈ ਸਪੱਸ਼ਟ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਭਾਵ ਨਹੀਂ (ਵਾਧੂ ਲੂਪ, ਵਾਧੂ ਕਾਲ, ਢਿੱਲਾ ਕੁਐਰੀ)
ਜੇ ਤੁਸੀਂ ਧਿਆਨ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, Claude ਨੂੰ ਆਪਣੇ ਚੇਂਜ ਅਤੇ ਫੇਲਿੰਗ ਸਥਿਤੀ 'ਤੇ ਆਧਾਰਿਤ ਛੋਟੀ ਵੈਰੀਫਿਕੇਸ਼ਨ ਯੋਜਨਾ ਮੰਗੋ। ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਫਾਇਲ ਨੂੰ ਬਦਲਿਆ, ਤੁਸੀਂ ਕੀ ਉਮੀਦ ਕੀਤੀ, ਅਤੇ ਕੀ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦਾ ਹੈ। ਵਧੀਆ ਯੋਜਨਾਵਾਂ ਛੋਟੀ ਤੇ ਕਾਰਗਰ ਹੁੰਦੀਆਂ ਹਨ: 5 ਤੋਂ 8 ਚੈੱਕ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਖ਼ਤਮ ਕਰ ਸਕਦੇ ਹੋ, ਹਰੇਕ ਦਾ ਸਪੱਸ਼ਟ ਪਾਸ/ਫੇਲ।
ਅਖੀਰ 'ਚ, ਜੋ ਤੁਸੀਂ ਵੈਰੀਫਾਈ ਕੀਤਾ ਉਸਨੂੰ PR ਜਾਂ ਨੋਟਸ ਵਿੱਚ ਦਰਜ ਕਰੋ: ਕਿਸ ਟੈਸਟ ਚਲਾਏ, ਕਿਹੜੇ ਮਨੁਅਲ ਕਦਮ ਕੀਤੇ, ਅਤੇ ਕੋਈ ਸੀਮਾਵਾਂ (ਉਦਾਹਰਣ ਲਈ, “ਮੋਬਾਈਲ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ”)। ਇਹ ਫਿਕਸ ਨੂੰ ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਅਤੇ ਮੁੜ ਵੇਖਣ ਲਈ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਆਮ ਗਲਤੀਆਂ ਅਤੇ ਫੰਦੇ (ਅਤੇ ਉਹਨਾਂ ਤੋਂ ਕਿਵੇਂ ਬਚੋ)
ਸਰਵਰ-ਸਾਈਡ ਫਿਕਸਾਂ ਦੀ ਟੈਸਟਿੰਗ
Go ਅਤੇ PostgreSQL ਫਲੋਜ਼ ਨੂੰ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰੋ ਅਤੇ API ਐਡਜ ਕੇਸਾਂ ਨੂੰ ਘੱਟ ਰੂਕਾਵਟ ਨਾਲ ਰਿਪ੍ਰੋਡਿਊਸ ਕਰੋ।
ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਸਮਾਂ ਵੈਸਟ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇਕ “ਫਿਕਸ” ਨੂੰ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਬੂਲ ਕਰ ਲਓ ਕਿ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਮੁੱਦੇ ਨੂੰ ਭਰੋਸੇ ਨਾਲ ਦੁਹਰਾਉਣਾ ਨਹੀਂ ਸਿੱਖ ਲੈਂਦੇ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਕਰਨਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣ ਸਕਦੇ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਬਿਹਤਰ ਹੋਇਆ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: ਜਦ ਤੱਕ ਤੁਸੀਂ ਇੱਕ ਦੁਹਰਾਊ ਸੈਟਅਪ (ਠੀਕ ਕਦਮ, ਇਨਪੁਟ, ਵਾਤਾਵਰਨ, ਅਤੇ "ਖਰਾਬ" ਕੀ ਦਿਖਦਾ ਹੈ) ਵੇਰਵਾ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਫਿਕਸ ਮੰਗੋ ਨਹੀਂ। ਜੇ ਰਿਪੋਰਟ ਧੁੰਦਲੀ ਹੈ, ਤਾਂ ਆਪਣੀਆਂ ਪਹਿਲੀਆਂ ਮਿੰਟਾਂ ਨੂੰ ਇਸਨੂੰ ਇੱਕ ਚੈਕਲਿਸਟ ਵਿੱਚ ਬਦਲਣ 'ਤੇ ਖਰਚ ਕਰੋ ਜੋ ਤੁਸੀਂ ਦੋ ਵਾਰ ਚਲਾ ਕੇ ਉਹੀ ਨਤੀਜਾ ਲੈ ਸਕੋ।
ਫੰਦੇ ਜੋ ਤੁਹਾਨੂੰ ਸੁਸਤ ਕਰਦੇ ਹਨ
ਰਿਪ੍ਰੋਡਯੂਸਬਲ ਕੇਸ ਦੇ ਬਿਨਾਂ ਫਿਕਸ ਕਰਨਾ. ਇੱਕ ਨਿਊਨਤਮ "ਹਰ ਵਾਰੀ ਫੇਲ" ਸਕ੍ਰਿਪਟ ਜਾਂ ਕਦਮ ਲੋੜੀਂਦਾ ਕਰੋ। ਜੇ ਇਹ ਸਿਰਫ "ਕਦੇ-ਕਦੇ" ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਟਾਈਮਿੰਗ, ਡੇਟਾ ਸਾਈਜ਼, ਫੀਚਰ ਫਲੈਗ, ਅਤੇ ਲੌਗ ਇਹਨਾ ਤਬ ਤਕ ਇਕੱਠੇ ਕਰੋ ਜਦ ਤੱਕ ਇਹ ਰੈਂਡਮ ਨਾ ਰਹਿ ਜਾਏ।
ਬਹੁਤ ਜਲਦੀ ਘੱਟ ਕਰਨਾ. ਜੇ ਤੁਸੀਂ ਮੂਲ ਫੇਲ ਨੂੰ ਪੁਸ਼ਟੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੇਸ ਨੂੰ ਘਟਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸਿਗਨਲ ਗੁੰਮ ਕਰ ਸਕਦੇ ਹੋ। ਪਹਿਲਾਂ ਬੇਸਲਾਈਨ ਰਿਪ੍ਰੋ ਲੌਕ ਕਰੋ, ਫਿਰ ਇੱਕ-ਇਕ ਕਰਕੇ ਘਟਾਓ।
Claude ਨੂੰ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦਿਓ. Claude ਸੰਭਾਵਿਤ ਕਾਰਨ ਦੱਸ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਹਮੇਸ਼ਾ ਸਬੂਤ ਚਾਹੀਦਾ ਹੈ। 2–3 ਹਾਇਪੋਥੇਸਿਸ ਮੰਗੋ ਅਤੇ ਹਰ ਇੱਕ ਨੂੰ ਪੁਸ਼ਟੀ ਕਰਨ ਵਾਲੀਆਂ ਵਿਸ਼ੇਸ਼ ਨਿਰੀਕਸ਼ਣ ਵਿਖਾਓ (ਇੱਕ ਲੌਗ ਲਾਈਨ, ਇੱਕ ਬਰੇਕਪੋਇੰਟ, ਇੱਕ ਕੁਐਰੀ ਨਤੀਜਾ)।
ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਜੋ ਗਲਤ ਕਾਰਨ ਲਈ ਪਾਸ ਹੁੰਦੇ ਹਨ. ਇੱਕ ਟੈਸਟ “ਪਾਸ” ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕਦੇ ਵੀ ਫੇਲਿੰਗ ਪਾਥ 'ਤੇ ਨਹੀਂ ਜਾਂਦਾ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ ਫਿਕਸ ਤੋਂ ਪਹਿਲਾਂ ਫੇਲ ਹੁੰਦਾ ਸੀ, ਅਤੇ ਇਹ ਉਮੀਦ ਕੀਤੀ ਗਈ ਸੁਨੇਹਾ ਜਾਂ ਅਸਰਸ਼ਨ ਲਈ ਫੇਲ ਹੁੰਦਾ ਹੈ।
ਲੱਛਣਾਂ ਦੀ ਥਾਂ ਟ੍ਰਿਗਰ ਨੂੰ ਇਲਾਜ ਕਰਨਾ. ਜੇ ਤੁਸੀਂ ਨੱਲ ਚੈੱਕ ਜੋੜਦੇ ਹੋ ਪਰ ਅਸਲ ਮੁੱਦਾ ਇਹ ਹੈ ਕਿ "ਇਹ ਮੂਲ ਰੂਪ ਵਿੱਚ ਨੱਲ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ," ਤਾਂ ਤੁਸੀਂ ਗਹਿਰਾ ਬੱਗ ਛੁਪਾਉ ਸਕਦੇ ਹੋ। ਬੁਰਾ ਸਥਿਤੀ ਬਣਾਉਣ ਵਾਲੀ ਹਾਲਤ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਤਰਜੀਹ ਦਿਓ।
ਇੱਕ ਤੇਜ਼ ਧਾਰਮਿਕ ਜਾਂਚ ਕਦਮ-ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਮੁਕੰਮਲ ਕਹੋ
ਨਵਾਂ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਅਤੇ ਮੂਲ ਰਿਪ੍ਰੋ ਸਟੈਪ ਨੂੰ ਆਪਣੀ ਬਦਲ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਚਲਾਓ। ਜੇ ਇੱਕ ਚੈੱਕਆਊਟ ਬੱਗ ਸਿਰਫ਼ ਤਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਪ੍ਰੋਮੋ ਕੋਡ ਸ਼ਿਪਿੰਗ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਲਾਗੂ ਕੀਤਾ ਗਿਆ, ਤਾਂ ਉਸ ਪੂਰੇ ਕ੍ਰਮ ਨੂੰ ਆਪਣੀ “ਸੱਚਾਈ” ਵਜੋਂ ਰੱਖੋ, ਭਾਵੇਂ ਤੁਹਾਡਾ ਘੱਟਾ ਟੈਸਟ ਛੋਟਾ ਹੋ।
ਜੇ ਤੁਹਾਡੀ ਵੈਰੀਫਿਕੇਸ਼ਨ “ਹੁਣ ਵਧੀਆ ਲੱਗਦਾ ਹੈ” 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਇਕ-ਸਪੱਸ਼ਟ ਚੈੱਕ (ਲੌਗ, ਮੈਟ੍ਰਿਕ, ਜਾਂ ਨਿਰਧਾਰਤ ਆਉਟਪੁੱਟ) ਜੋੜੋ ਤਾਂ ਕਿ ਅਗਲਾ ਵਿਅਕਤੀ ਤੇਜ਼ੀ ਨਾਲ ਉਸਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕੇ।
ਇੱਕ ਛੋਟਾ ਚੈਕਲਿਸਟ, ਪ੍ਰਾਂਪਟ ਟੈਮਪਲੇਟ, ਅਤੇ ਅਗਲੇ ਕਦਮ
ਜਦ ਤੁਸੀਂ ਸਮਾਂ ਦਬਾਅ ਵਿੱਚ ਹੋ, ਇੱਕ ਛੋਟਾ, ਦੁਹਰਾਊ ਲੂਪ ਹੀ ਮਹਾਨ ਬਕਾਇਆ ਡੀਬੱਗਿੰਗ ਕਰਦਾ ਹੈ।
ਇਕ-ਪੰਨਾ ਟ੍ਰਾਇਏਜ ਚੈਕਲਿਸਟ
- ਰਿਪ੍ਰੋਡਿਊਸ: ਇੱਕ ਭਰੋਸੇਯੋਗ ਰਿਪ੍ਰੋ ਪ੍ਰਾਪਤ ਕਰੋ ਅਤੇ ਠੀਕ ਇਨਪੁਟ, ਵਾਤਾਵਰਨ, ਅਤੇ ਉਮੀਦਵਾਰ ਵਿਰੁੱਧ ਦਰਜ ਕਰੋ।
- ਮਿਨੀਮਾਈਜ਼: ਸਭ ਤੋਂ ਛੋਟੇ ਕਦਮ ਜਾਂ ਟੈਸਟ ਤੱਕ ਘਟਾਓ ਜੋ ਅਜੇ ਵੀ ਫੇਲ ਕਰਦਾ ਹੈ।
- ਸਮਝਾਓ: 2–3 ਸੰਭਾਵਿਤ ਰੂਟ ਕਾਰਨ ਅਤੇ ਹਰ ਇੱਕ ਲਈ ਲੋੜੀਂਦਾ ਸਬੂਤ ਲਿਖੋ।
- ਲੌਕ ਕਰੋ: ਇੱਕ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਜੋ ਸਹੀ ਕਾਰਨ ਲਈ ਫੇਲ ਕਰਦਾ ਹੈ ਜੋੜੋ।
- ਫਿਕਸ + ਵੈਰੀਫਾਈ: ਸਭ ਤੋਂ ਨੈਰੋ ਚੇਂਜ ਕਰੋ, ਫਿਰ ਛੋਟੀ ਵੈਰੀਫਿਕੇਸ਼ਨ ਚੈਕਲਿਸਟ ਚਲਾਓ।
ਅਖੀਰ ਦਾ ਫੈਸਲਾ ਕੁਝ ਸਤਰਾਂ ਵਿੱਚ ਲਿਖੋ ਤਾਂ ਕਿ ਅਗਲਾ ਵਿਅਕਤੀ (ਅਕਸਰ ਭਵਿੱਖ ਦਾ ਤੁਸੀਂ) ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕੇ। ਇੱਕ ਉਪਯੋਗੀ ਫਾਰਮੈਟ ਹੋ ਸਕਦਾ ਹੈ: “Root cause: X. Trigger: Y. Fix: Z. Why safe: W. What we did not change: Q.”
ਚਿਪਕੀ-ਪੇਸਟ ਕਰਨਯੋਗ ਪ੍ਰਾਂਪਟ ਟੈਮਪਲੇਟ
- “ਇਸ ਬੱਗ ਰਿਪੋਰਟ ਅਤੇ ਲੌਗਜ਼ ਦੇ ਦੇਖਕੇ, ਮੈਨੂੰ ਕੇਵਲ ਉਹ ਹੀ ਗੁੰਮ ਵਿਸਥਾਰ ਪੁੱਛੋ ਜੋ ਰਿਪ੍ਰੋ ਕਰਨ ਲਈ ਲੋੜੀਦਾ ਹੈ।”
- “ਮੈਨੂੰ ਮਿਨੀਮਾਈਜ਼ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੋ: ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਕੇਸ ਪ੍ਰਸਤਾਵਿਤ ਕਰੋ ਅਤੇ ਦੱਸੋ ਪਹਿਲਾਂ ਕੀ ਹਟਾਉਣਾ ਹੈ, ਇੱਕ-ਇੱਕ ਕਰਕੇ।”
- “ਸੰਭਾਵਿਤ ਰੂਟ ਕਾਰਨ ਦਰਜ ਕਰੋ ਅਤੇ ਪ੍ਰਤੀਕ ਦਾਖਲੀਆਂ, ਫਾਇਲਾਂ, ਜਾਂ ਸ਼ਰਤਾਂ ਨੂੰ ਦਰਜ ਕਰਕੇ ਹਰ ਇੱਕ ਦਾ ਤਰਤੀਬ ਦਿਓ।”
- “ਇਸ ਖਾਸ ਸਥਿਤੀ ਲਈ ਇੱਕ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਲਿਖੋ ਜੋ ਸਿਰਫ਼ ਇਸ ਬੱਗ ਕਰਕੇ ਫੇਲ ਹੋਵੇ। ਦੱਸੋ ਕਿਉਂ ਇਹ ਸਹੀ ਕਾਰਨ ਲਈ ਫੇਲ ਹੁੰਦਾ ਹੈ।”
- “ਸਭ ਤੋਂ ਨੈਰੋ ਸੁਧਾਰ ਸੁਝਾਅ ਦਿਓ, ਨਾਲ ਹੀ ਇੱਕ ਵੈਰੀਫਿਕੇਸ਼ਨ ਚੈਕਲਿਸਟ (ਯੂਨਿਟ, ਇੰਟਿਗ੍ਰੇਸ਼ਨ, ਅਤੇ ਮਨੁਅਲ ਚੈੱਕ) ਜੋ ਸਾਬਤ ਕਰੇ ਕਿ ਅਸੀਂ ਨੇੜਲੇ ਵਿਵਹਾਰ ਨਹੀਂ ਤੋੜੇ।”
ਅਗਲੇ ਕਦਮ: ਜੋ ਕੁਝ ਤੁਸੀਂ ਆਟੋਮੇਟ ਕਰ ਸਕਦੇ ਹੋ ਉਹ ਆਟੋਮੇਟ ਕਰੋ (ਇੱਕ ਸੰਭਾਲਿਆ ਰਿਪ੍ਰੋ ਸਕ੍ਰਿਪਟ, ਇੱਕ ਸਟੈਂਡਰਡ ਟੈਸਟ ਕਮਾਂਡ, ਰੂਟ-ਕਾਰਨ ਨੋਟਸ ਲਈ ਇੱਕ ਟੈਮਪਲੇਟ)।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਨਾਲ ਐਪ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ Planning Mode ਤੁਹਾਨੂੰ ਬਦਲਾਅ ਦਾ ਆਉਟਲਾਈਨ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਕੋਡ ਛੂਹੋ, ਅਤੇ ਸਨੇਪਸ਼ਾਟ/ਰੋਲਬੈਕ ਤੁਹਾਨੂੰ ਪ੍ਰਯੋਗ ਦੌਰਾਨ ਸੁਰੱਖਿਅਤ ਅਨੁਭਵ ਕਰਾਉਂਦੇ ਹਨ। ਇੱਕ ਵਾਰ ਫਿਕਸ ਵੈਰੀਫਾਈ ਹੋ ਜਾਣ 'ਤੇ, ਤੁਸੀਂ ਸੋर्स ਕੋਡ ਨਿਰਯਾਤ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਅਪਡੇਟ ਕੀਤੀ ਐਪ ਡਿਪਲੌਇ ਅਤੇ ਹੋਸਟ ਕਰ ਸਕਦੇ ਹੋ, ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ קਸਟਮ ਡੋਮੇਨ ਸਹਿਤ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
What is bug triage, in plain terms?
ਬੱਗ ਟ੍ਰਾਇਏਜ ਉਸ ਆਦਤ ਨੂੰ ਕਹਿੰਦੇ ਹਨ ਜਿਸ ਵਿੱਚ ਇਕ ਅਸਪਸ਼ਟ ਰਿਪੋਰਟ ਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ, ਟੈਸਟ ਕਰਨਯੋਗ ਬਿਆਨ ਵਿੱਚ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਸਭ ਤੋਂ ਛੋਟੀ ਚੇਜ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜੋ ਉਹ ਬਿਆਨ ਬਰਾਬਰ ਨਾ ਰਹਿਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੇ।
ਇਹ "ਸਭ ਕੁਝ ਠੀਕ ਕਰੋ" ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਹੈ, ਸਗੋਂ ਅਣਿਸ਼ਚਿਤਤਾ ਨੂੰ ਕਦਮ-ਦਰ-ਕਦਮ ਘਟਾਉਣਾ ਹੈ: ਰਿਪ੍ਰੋਡਿਊਸ ਕਰੋ, ਘੱਟ ਕਰੋ, ਸਬੂਤ-ਆਧਾਰਿਤ ਜੁਆਬਦਾਰੀਆਂ ਬਣਾਓ, ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਜੋੜੋ, ਨੈਰੋ ਫਿਕਸ ਕਰੋ ਅਤੇ ਵੈਰੀਫਾਈ ਕਰੋ।
Why does the reproduce → minimize → test → fix loop matter so much?
ਕਿਉਂਕਿ ਹਰ ਕਦਮ ਇੱਕ ਵੱਖਰਾ ਅਣਜਾਣ ਪੱਖ ਘਟਾਉਂਦਾ ਹੈ।
- ਰਿਪ੍ਰੋਡਿਊਸ: ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਮੁੱਦਾ ਅਸਲ ਵਿੱਚ ਮੌਜੂਦ ਹੈ ਅਤੇ ਦੁਹਰਾਯੋਗ ਹੈ
- ਮਿਨੀਮਾਈਜ਼: ਸ਼ੋਰ ਹਟਾਉਂਦਾ ਹੈ ਤਾਂ ਤੁਸੀਂ ਬੇਸੁਦੇ ਰਵੱਈਏ ਦੀ ਪਿੱਛੇ ਨਹੀਂ ਭੱਜਦੇ
- ਸਬੂਤ-ਆਧਾਰਿਤ ਅਨੁਮਾਨ: ਤੁਹਾਨੂੰ ਗਲਤ ਚੀਜ਼ ਠੀਕ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ
- ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ: ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਬੱਗ ਮੌਜੂਦ ਸੀ ਅਤੇ ਫਿਰ ਉਸਨੂੰ ਫਿਕਸ ਕੀਤਾ ਗਿਆ
- ਨੈਰੋ ਫਿਕਸ + ਵੈਰਿਫਿਕੇਸ਼ਨ: ਦੂਜੇ ਪਾਸੇ ਪ੍ਰਭਾਵ ਅਤੇ ਮੁੜ-ਟੁੱਟਣ ਘਟਾਉਂਦਾ ਹੈ
How do I turn a messy bug report into something actionable?
ਇਸ ਨੂੰ ਦੁਬਾਰਾ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੋ: “ਜਦੋਂ ਮੈਂ X ਕਰਦਾ/ਦੀ ਹਾਂ, ਮੈਂ ਉਮੀਦ ਕਰਦਾ/ਦੀ ਹਾਂ Y, ਪਰ ਮੈਨੂੰ Z ਮਿਲਦਾ ਹੈ.”
ਫਿਰ ਟੈਸਟ ਕਰਨਯੋਗ ਬਣਾਉਣ ਲਈ ਜ਼ਰੂਰੀ ਸੰਦੇਸ਼ ਇਕੱਠੇ ਕਰੋ:
- ਵਰਜ਼ਨ/ਕਮੇਟ + ਕਿੱਥੇ ਹੋ ਰਿਹਾ ਹੈ (local/staging/prod)
- ਵਾਤਾਵਰਨ (ਡਿਵਾਈਸ, OS, ਬ੍ਰਾਉਜ਼ਰ, ਫੀਚਰ ਫਲੈਗ, ਰੀਜਨ)
- ਬਿਲਕੁਲ ਠੀਕ ਇਨਪੁਟ/ਕਾਰਵਾਈਆਂ
- ਕਿਸਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦਾ ਹੈ (ਸਭ, ਕੋਈ ਰੋਲ, ਇਕ ਖਾਤਾ)
- ਸਬੂਤ (ਟਾਈਮਸਟੈਂਪ, ਐਰਰ ਟੈਕਸਟ, ਰਿਕਵੈਸਟ/ਟਰੇਸ IDs, ਲੌਗ)
What should I do first if I can’t reproduce the bug?
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਉਸ ਸਭ ਤੋਂ ਛੋਟੇ ਵਾਤਾਵਰਨ 'ਚ ਰਿਪ੍ਰੋ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਮੁੱਦਾ ਦਿਖਾਉਂਦਾ ਹੈ (ਅਕਸਰ ਲੋਕਲ ਡੈਵ ਨਾਲ ਇੱਕ ਛੋਟੀ ਡੇਟਾਸੈਟ)।
ਜੇ ਇਹ “ਕਦੇ-ਕਦੇ” ਹੁੰਦਾ ਹੈ, ਤਾਂ ਵੈਰੀਏਬਲਾਂ ਨੂੰ ਕੰਟਰੋਲ ਕਰਕੇ ਇਸਨੂੰ ਡੀਟੈਰਮਿਨਿਸਟਿਕ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ:
- ਇਕੋ ਹੀ ਪੇਲੋਡ ਨੂੰ 10 ਵਾਰੀ ਚਲਾਓ
- ਸਮਾਂ/ਰੈਂਡਮਨੈੱਸ ਨੂੰ ਫਿਕ্স ਕਰੋ ਜੇ ਸੰਭਵ ਹੋਵੇ
- ਕਨਕਰੰਸੀ ਘੱਟ ਕਰੋ (ਅਕੈਲ ਵੀਅਰ/ਥ੍ਰੈਡ)
- ਸਭ ਤੋਂ ਸੰਭਾਵਿਤ ਬਾਊਂਡਰੀ 'ਤੇ ਇੱਕ ਨਿਸ਼ਾਨਦਾਰ ਲੌਗ ਜੋੜੋ
ਜਦ ਤੱਕ ਤੁਸੀਂ ਮੰਗੇ ਤੇ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਇਸਨੂੰ ਫੇਲ ਕਰਨਾ ਨਹੀਂ ਦੇਖਦੇ, ਅੱਗੇ ਨਾ ਵਧੋ।
How do I minimize a bug to a small test case?
ਮਿਨੀਮਾਈਜ਼ੇਸ਼ਨ ਦਾ ਮਤਲਬ ਹੈ ਉਹ ਸਭ ਹਟਾਉਣਾ ਜੋ ਲਾਜ਼ਮੀ ਨਹੀਂ ਹੈ ਪਰ ਬੱਗ ਨੂੰ ਰੱਖਣਾ।
“ਅੱਧਾ ਹਟਾਓ ਅਤੇ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰੋ” ਇੱਕ ਵਰਤੋਂਯੋਗ ਤਰੀਕਾ ਹੈ:
- ਕਦਮ/ਡੇਟਾ ਨੂੰ ਅੱਧਾ ਕਰ ਦਿਓ
- ਜੇ ਫੇਲ ਹੁੰਦਾ ਰਹੇ, ਫਿਰ ਅੱਗੇ ਕੱਟੋ
- ਜੇ ਨਹੀਂ, ਅੱਧਾ ਰੀਸਟੋਰ ਕਰੋ ਅਤੇ ਵੱਖਰਾ ਕਟੋ
ਕਦੋਂ ਤੱਕ ਤੁਸੀਂ ਬੱਗ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਸੰਰਚਨਾ ਵਿੱਚ ਦੁਹਰਾਉ ਸਕਦੇ ਹੋ, ਨਹੀਂ ਰੁਕੋ।
How can Claude Code help without turning into guesswork?
Claude Code ਨੂੰ ਵਿਸ਼ਲੇਸ਼ਣ ਤੇ ਗਤੀ ਲਈ ਵਰਤੋ, ਪਰ ਵੈਰਿਫਿਕੇਸ਼ਨ ਆਪ ਕਰੋ।
ਚੰਗੀਆਂ ਬੇਨਤੀਆਂ ਉਦਾਹਰਨ:
- “ਇਹ ਰਿਪ੍ਰੋ ਸਟੈਪ ਅਤੇ ਲੌਗ ਦੇ ਦਿਓ; 2–3 ਸੰਭਾਵਿਤ ਅਨੁਮਾਨ ਅਤੇ ਹਰ ਇੱਕ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕੀ ਵੇਖਣਾ ਲੋੜੀਦਾ ਹੈ ਲਿਖੋ।”
- “ਇਸ ਡਿਫ ਅਤੇ ਸਟੈਕ ਟਰੇਸ ਦੇਖ ਕੇ ਸਭ ਤੋਂ ਸੰਭਾਵਿਤ ਬਾਊਂਡਰੀਆਂ ਕਿੱਥੇ ਹਨ?”
- “ਇਸ ਖਾਸ ਸਥਿਤੀ ਲਈ ਇੱਕ ਛੋਟਾ ਫੇਲਿੰਗ ਟੈਸਟ ਡਰਾਫਟ ਕਰੋ।”
ਫਿਰ ਤੁਸੀਂ ਲੋਕਲ ਵਿਵਸਥਾ ਤੇ ਦੁਹਰਾਓ, ਲੌਗ/ਟਰੇਸ ਚੈੱਕ ਕਰੋ, ਅਤੇ ਦੇਖੋ ਕਿ ਟੈਸਟ ਠੀਕ ਕਾਰਨ ਲਈ ਫੇਲ ਹੁੰਦਾ ਹੈ।
How many root-cause hypotheses should I consider at once?
ਇੱਕ ਸਮੇਂ 'ਚ ਤਿੰਨ ਰੁੱਖ-ਕਾਰਨ ਅਨੁਮਾਨ ਰੱਖੋ। ਇਸ ਤੋਂ ਜ਼ਿਆਦਾ ਹੋਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡਾ ਰਿਪ੍ਰੋ ਅਜੇ ਵੀ ਬੜਾ ਹੈ ਜਾਂ ਪ੍ਰੇਖਣ ਧੁੰਦਲੇ ਹਨ।
ਹਰ ਅਨੁਮਾਨ ਲਈ ਲਿਖੋ:
- ਲੱਛਣ (ਤੁਸੀਂ ਕੀ ਵੇਖਦੇ ਹੋ)
- ਅਨੁਮਾਨ (ਇਸ ਦਾ ਕਾਰਨ ਕੀ ਹੋ ਸਕਦਾ ਹੈ)
- ਪ੍ਰਮਾਣ ਇਕੱਠੇ ਕਰਨ ਲਈ (ਇੱਕ ਲੌਗ ਲਾਈਨ, ਇੱਕ ਬਰੇਕਪੋਇੰਟ, ਇੱਕ ਕੁਐਰੀ ਨਤੀਜਾ)
- ਫੈਸਲਾ (ਸਮਰਥਿਤ/ਅਸਮਰਥਿਤ)
ਇਸ ਨਾਲ ਤਰੱਕੀ ਹੁੰਦੀ ਹੈ ਅਤੇ ਬੇਅੰਤ “ਸ਼ਾਇਦ ਇਹ X ਹੈ” ਡਿਬੱਗਿੰਗ ਰੁਕਦੀ ਹੈ।
What makes a good regression test for a bug?
ਉਹ ਸਭ ਤੋਂ ਛੋਟਾ ਟੈਸਟ ਪੱਧਰ ਚੁਣੋ ਜੋ ਫੇਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ:
- ਯੂਨਿਟ ਟੈਸਟ: ਇਕ ਫੰਕਸ਼ਨ ਗਲਤ ਮੁੱਲ ਰਿਟਰਨ ਕਰਦਾ ਹੈ
- ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਟੈਸਟ: ਬਾਊਂਡਰੀ ਮੁੱਦੇ (ਹੈਂਡਲਰ + DB, ਕਲਾਇੰਟ + API)
- ਏਂਡ-ਟੂ-ਏਂਡ: ਸਿਰਫ ਜੇ ਪੂਰਾ ਫਲੋ ਲਾਜ਼ਮੀ ਹੋ
ਇੱਕ ਚੰਗਾ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ:
- ਮੌਜੂਦਾ ਕੋਡ 'ਤੇ ਆਪਣੀ ਮੰਨਤੀ ਕਾਰਨ ਫੇਲ ਹੋਵੇ
- ਕਿਸੇ ਨਿਰਧਾਰਤ ਚੀਜ਼ ਨੂੰ ਅਸਰਟ ਕਰੇ (ਸਟੇਟਸ ਕੋਡ, ਸੁਨੇਹਾ, ਦਰਸਾਇਆ ਪਾਠ)
- ਇਕ ਨਾਲ ਸੰਬੰਧਿਤ ਬੁਨਿਆਦੀ ਬਿਹੇਵਿਅਰ ਨੂੰ ਨਹੀਂ ਮਿਲਾ ਕੇਂਦਰਿਤ ਕਰੇ
How do I keep a fix narrow and low-risk?
ਸਭ ਤੋਂ ਛੋਟੀ ਚੇਂਜ ਕਰੋ ਜੋ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਨੂੰ ਸਹੀ ਕਾਰਨ ਲਈ ਪਾਸ ਕਰਵਾ ਦਿੰਦੀ ਹੈ।
ਨਿਯਮ-ਇੱਸਰੇ:
- ਘੱਟ ਤੋਂ ਘੱਟ ਫਾਇਲਾਂ ਨੂੰ ਛੂਹੋ
- ਖ਼ਰਾਬ ਮੁੱਲ ਦੇ ਦਾਖਲ ਹੋਣ ਵਾਲੇ ਬਾਊਂਡਰੀ 'ਤੇ ਫਿਕਸ ਕਰੋ
- ਟ੍ਰਾਇਏਜ ਦੌਰਾਨ ਰਿਫੈਕਟਰ ਕਰਨ ਦੀ ਬਜਾਏ ਗਾਰਡ/ਵੈਧਤਾ ਪਸੰਦ ਕਰੋ
- ਜੇ ਤੁਹਾਡਾ ਸੁਧਾਰ ਬੇਸਬੰਧਤ ਟੈਸਟ ਬਦਲਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਇਹ ਬਹੁਤ ਵਿਆਪਕ ਹੈ
ਇਹ ਤਰੀਕਾ ਜੋਖਮ ਘਟਾਉਂਦਾ ਹੈ।
How do I validate the fix so the bug doesn’t come back?
ਵੈਰੀਫਿਕੇਸ਼ਨ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਛੋਟੀ, ਆਸਾਨ-ਨਜ਼ਰਅੰਦਾਜ਼ ਗਲਤੀਆਂ ਫੜਦੇ ਹੋ: ਇੱਕ ਫਿਕਸ ਜੋ ਇਕ ਟੈਸਟ ਪਾਸ ਕਰਵਾਉਂਦਾ ਹੈ ਪਰ ਨੇੜੇ ਰਾਹ ਨੂੰ ਤੋੜ ਦਿੰਦਾ ਹੈ, ਸੁਨੇਹਾ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਸੁਸਤ ਕਵੈਰੀ ਜੋੜਦਾ ਹੈ।
ਪਹਿਲਾਂ ਆਪਣਾ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਦੁਬਾਰਾ ਚਲਾਓ। ਜੇ ਪਾਸ ਹੋ ਗਿਆ, ਨੇੜਲੇ ਟੈਸਟਾਂ ਨੂੰ ਚਲਾਓ: ਉਹ ਫਾਇਲ, ਮੋਡੀਊਲ ਅਤੇ ਉਹ ਜੋ ਉਹੀ ਇਨਪੁਟ ਕਵਰ ਕਰਦੇ ਹਨ।
ਫਿਰ ਮੂਲ ਰਿਪੋਰਟ ਦੇ ਉਹੀ ਕਦਮ ਤੁਰੰਤ ਮਨੁਅਲ ਚੈੱਕ ਕਰੋ: ਉਹੀ ਵਾਤਾਵਰਨ, ਉਹੀ ਡੇਟਾ, ਉਹੀ ਕਿਰਿਆ-ਸ਼੍ਰੇਣੀ।
ਅਖੀਰ 'ਤੇ PR ਜਾਂ ਨੋਟਸ ਵਿੱਚ ਜੋ ਤੁਸੀਂ ਵੈਰੀਫਾਈ ਕੀਤਾ, ਉਹ ਦਰਜ ਕਰੋ: ਕਿਸ ਟੈਸਟ ਚਲਾਏ, ਕਿਸ ਮਨੁਅਲ ਕਦਮ ਨੂੰ ਕੋਸ਼ਿਸ਼ ਕੀਤਾ, ਅਤੇ ਕੀ ਨਹੀਂ ਚੈੱਕ ਕੀਤਾ ਗਿਆ।