30 ਦਸੰ 2025·8 ਮਿੰਟ
Claude Code ਨਾਲ ਬੱਗ ਟ੍ਰਾਇਏਜ: ਤੇਜ਼ ਸੁਧਾਰਾਂ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਲੂਪ
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 ਨੂੰ ਇੱਕ “ਰਿਪੋਰਟ ਕਲੀਨਰ” ਵਜੋਂ ਵੀ ਵਰਤੋਂ। ਅਸਲ ਰਿਪੋਰਟ ਪੇਸਟ ਕਰੋ (ਸਕਰੀਨਸ਼ਾਟ ਤੋਂ ਨਕਲ ਕੀਤਾ ਟੈਕਸਟ, ਲੌਗ, ਚੈਟ ਟੁਕੜੇ ਸਮੇਤ), ਫਿਰ ਕਹੋ:
“ਇਸਨੂੰ ਇੱਕ ਸਟ੍ਰੱਕਚਰਡ ਚੈਕਲਿਸਟ ਵਜੋਂ ਦੁਬਾਰਾ ਲਿਖੋ। ਵਿਰੋਧਾਂ ਨੂੰ ਫਲੈਗ ਕਰੋ। 5 ਸੋਂਚੜੇ ਹੋਏ ਘੱਟੋ-ਘੱਟ ਤਥ ਨੂੰ ਹਾਂ/ਨਹੀਂ ਪ੍ਰਸ਼ਨਾਂ ਵਜੋਂ ਲਿਖੋ। ਹੁਣ ਕਾਰਨਾਂ ਬਾਰੇ ਅਨੁਮਾਨ ਨਾ ਲਗਾਓ।”
ਜੇ ਕੋਈ ਟੀਮਮੇਟ ਕਹਿੰਦਾ ਹੈ “ਇਹ ਬੇਤਰਤੀਬੀ ਹੈ,” ਤਾਂ ਇਸਨੂੰ ਟੈਸਟ ਕਰਨਯੋਗ ਚੀਜ਼ ਵੱਲ ਧੱਕੋ: “iPhone 14, iOS 17.2 'ਤੇ 2/10 ਵਾਰੀ ਫੇਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ Save ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਦਬਾਇਆ ਜਾਵੇ।” ਹੁਣ ਤੁਸੀਂ ਇਸਨੂੰ ਮਨਸ਼ਾ-ਪੂਰਵਕ ਦੁਹਰਾਉ ਸਕਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਬੱਗ ਨੂੰ ਮੰਗੇ ਉੱਤੇ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਹਰ ਅਗਲਾ ਕਦਮ ਅਨੁਮਾਨ ਹੀ ਹੈ।
ਸਭ ਤੋਂ ਛੋਟੇ ਵਾਤਾਵਰਨ ਵਿੱਚ ਰਿਪ੍ਰੋ ਕਰਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਫਿਰ ਵੀ ਸਮੱਸਿਆ ਦਿਖਾ ਸਕੇ: ਲੋਕਲ ਡੈਵ ਬਿਲਡ, ਇੱਕ ਛੋਟੀ ਸ਼ਾਖਾ, ਇੱਕ ਛੋਟਾ ਡੇਟਾ ਸੈੱਟ, ਅਤੇ ਸੰਭਵਤ: ਘੱਟ ਤੋਂ ਘੱਟ ਸਰਵਿਸز।
ਠੀਕ-ਠਾਕ ਕਦਮ ਲਿਖੋ ਤਾਂ ਜੋ ਕੋਈ ਹੋਰ ਬਿਨਾ ਪੁੱਛੇ ਅਨੁਕਰਨ ਕਰ ਸਕੇ। ਕਾਪੀ-ਪੇਸਟ-ਅਨੁਕੂਲ ਬਣਾਓ: ਕਮਾਂਡ, IDs, ਅਤੇ ਨਮੂਨਾ ਪੇਲੋਡ ਬਿਲਕੁਲ ਜਿਵੇਂ ਵਰਤੇ ਗਏ ਸ਼ਾਮਿਲ ਕਰੋ।
ਇੱਕ ਸਧਾਰਣ ਕੈਪਚਰ ਟੇਮਪਲੇਟ:
ਫ੍ਰਿਕਵੈਂਸੀ ਤੁਹਾਡੀ ਯੁਕਤਿ ਨੂੰ ਬਦਲਦੀ ਹੈ। “ਹਮੇਸ਼ਾ” ਬੱਗ ਤੇਜ਼ ਇੱਟਰੇਸ਼ਨ ਲਈ ਵਧੀਆ ਹਨ। “ਕਦੇ-ਕਦੇ” ਬੱਗ ਅਕਸਰ ਟਾਇਮਿੰਗ, ਕੈਸ਼ਿੰਗ, ਰੇਸ ਕੰਡੀਸ਼ਨ, ਜਾਂ ਛੁਪੇ ਹੋਏ ਸਟੇਟ ਵੱਲ ਸੰਗੇਤ ਦਿੰਦੇ ਹਨ।
ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਰਿਪ੍ਰੋ ਨੋਟਸ ਹੁੰਦੀਆਂ ਹਨ, Claude ਤੋਂ ਤੁਰੰਤ ਪ੍ਰੋਬਜ਼ ਮੰਗੋ ਜੋ ਐਪ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਤੋਂ ਬਿਨਾਂ ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਉਣ। ਵਧੀਆ ਪ੍ਰੋਬਜ਼ ਛੋਟੇ ਹੁੰਦੇ ਹਨ: ਫੇਲਿੰਗ ਸੀਮਾ 'ਚ ਇੱਕ ਨਿਸ਼ਾਨਦਾਰ ਲੌਗ ਲਾਈਨ (ਇਨਪੁਟ, ਆਉਟਪੁਟ, ਮੁੱਖ ਸਟੇਟ), ਇਕ ਸਿੰਗਲ ਕੰਪੋਨੈਂਟ ਲਈ ਡੀਬੱਗ ਫਲੈਗ, ਤਨੁੱਖੀ ਵਰਿਆਬਲ ਨੂੰ ਡੀਟੈਰਮਿਨਿਸਟਿਕ ਬਣਾਉਣ ਦਾ ਤਰੀਕਾ (ਫਿਕਸ ਰੈਂਡਮ ਸੀਡ, ਫਿਕਸ ਟਾਈਮ), ਇੱਕ ਛੋਟਾ ਸੀਡ ਡੇਟਾ ਜੋ ਮੁੱਦਾ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ, ਜਾਂ ਦੁਹਰਾਉਣ ਲਈ ਇੱਕ ਇਕੱਲਾ ਰਿਕਵੈਸਟ/ਰਿਸਪਾਂਸ ਜੋ ਜੋਧਿਆ ਜਾ ਸਕੇ।
ਉਦਾਹਰਨ: ਸਾਈਨਅੱਪ ਫਲੋ “ਕਦੇ-ਕਦੇ” ਫੇਲ ਹੁੰਦਾ ਹੈ। Claude ਸ਼ਾਇਦ ਸੁਝਾਅ ਦੇਵੇ ਕਿ ਜੇਨਰੇਟ ਕੀਤੀ ਯੂਜ਼ਰ ID, ਈਮੇਲ ਨਾਰਮਲਾਈਜ਼ੇਸ਼ਨ ਨਤੀਜਾ, ਅਤੇ ਯੂਨੀਕ ਕਨਸਟ੍ਰੇਂਟ ਐਰਰ ਵੇਰਵੇ ਲੌਗ ਕਰੋ, ਫਿਰ ਇੱਕੋ ਪੇਲੋਡ 10 ਵਾਰੀ ਚਲਾਓ। ਜੇ ਫੇਲ ਸਿਰਫ ਡਿਪਲੌਇ ਤੋਂ ਬਾਅਦ ਪਹਿਲੀ ਵਾਰੀ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਮਾਈਗ੍ਰੇਸ਼ਨ, ਕੈਸ਼ ਵਾਰਮਅਪ, ਜਾਂ ਗੁੰਮ ਸੀਡ ਡੇਟਾ ਵੱਲ ਸਨਕੇਤ ਦਿੰਦੀ ਹੈ।
ਚੰਗੀ ਰਿਪ੍ਰੋ ਯੂਜ਼ਮਦਾ ਹੈ। ਇੱਕ ਨਿਊਨਤਮ ਰਿਪ੍ਰੋਸ਼ਨ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ। ਇਹ ਬੱਗ ਨੂੰ ਸਮਝਣਾ ਤੇਜ਼ ਕਰਦਾ ਹੈ, ਡੀਬੱਗ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ “ਆਕਸਮਾਤ” ਫਿਕਸ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਜੋ ਲੋੜੀਂਦਾ ਨਹੀਂ ਹੈ ਉਹ ਸਭ ਹਟਾਉ। ਜੇ ਬੱਗ ਲੰਬੇ UI ਫਲੋ ਦੇ ਬਾਅਦ ਆਉਂਦਾ ਹੈ, ਸਭ ਤੋਂ ਛੋਟਾ ਰਸਤਾ ਲੱਭੋ ਜੋ ਵਾਪਸ ਆਉਂਦਾ ਹੈ। ਵਿਕਲਪਿਕ ਸਕ੍ਰੀਨ, ਫੀਚਰ ਫਲੈਗ, ਅਤੇ ਗੈਰ-ਸੰਬੰਧਤ ਇੰਟੀਗਰੇਸ਼ਨਾਂ ਨੂੰ ਹਟਾਓ ਜਦ ਤੱਕ ਬੱਗ ਛੁਪ ਨਾ ਜਾਵੇ (ਤੁਸੀਂ ਕੁਝ ਜ਼ਰੂਰੀ ਹਟਾ ਦਿੱਤਾ) ਜਾਂ ਜਿਵੇਂ ਹੀ ਇਹ ਰਹਿੰਦਾ ਹੈ (ਤੁਸੀਂ ਸ਼ੋਰ ਵਿੱਚੋਂ ਸੱਚਮੁਚ ਦਾ ਪਤਾ ਲਿਆ)।
ਫਿਰ ਡੇਟਾ ਨੂੰ ਘਟਾਓ। ਜੇ ਬੱਗ ਲਈ ਵੱਡਾ ਪੇਲੋਡ ਲੋੜੀਦਾ ਹੈ, ਤਾਂ ਉਹ ਸਭ ਤੋਂ ਛੋਟਾ ਪੇਲੋਡ ਲੱਭੋ ਜੋ ਫੇਲ ਕਰਦਾ ਹੈ। ਜੇ ਇਹ 500 ਆਈਟਮ ਦੀ ਲਿਸਟ ਲੈਂਦਾ, ਵੇਖੋ ਕਿ 5 ਫੇਲ ਕਰਦੇ ਹਨ, ਫਿਰ 2, ਫਿਰ 1। ਫੀਲਡ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਹਟਾਓ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਸਭ ਤੋਂ ਘੱਟ ਮੋਵਿੰਗ ਪਾਰਟਾਂ ਨਾਲ ਬੱਗ ਨੂੰ ਰੋਕਣਾ ਹੈ।
“ਅੱਧਾ ਹਟਾਓ ਅਤੇ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰੋ” ਇਕ ਵਰਤੋਂਯੋਗ ਤਰੀਕਾ ਹੈ:
ਉਦਾਹਰਨ: ਇੱਕ ਚੈੱਕਆਊਟ ਪੇਜ “ਕਦੇ-ਕਦੇ” ਕ੍ਰੈਸ਼ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕੂਪਨ ਲਗਾਇਆ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਪਤਾ ਲਗਾਉਂਦੇ ਹੋ ਕਿ ਇਹ ਸਿਰਫ ਤਦੋਂ ਫੇਲ ਹੁੰਦਾ ਹੈ ਜਦ ਕਾਰਟ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਇਕ ਛੂਟ ਵਾਲੀ ਆਈਟਮ ਹੋਵੇ, ਕੂਪਨ ਨੀਵ-ਅੱਖਰਾਂ ਵਿੱਚ ਹੋਵੇ, ਅਤੇ ਸ਼ਿਪਿੰਗ “ਪਿਕਅੱਪ” ਤੇ ਸੈਟ ਹੋਵੇ। ਇਹ ਤੁਹਾਡਾ ਨਿਊਨਤਮ ਕੇਸ ਹੈ: ਇੱਕ ਛੂਟ ਵਾਲੀ ਆਈਟਮ, ਇੱਕ ਨੀਵ-ਅੱਖਰ ਕੂਪਨ, ਇੱਕ ਪਿਕਅੱਪ ਵਿਕਲਪ।
ਜਦ ਨਿਊਨਤਮ ਕੇਸ ਸਪੱਸ਼ਟ ਹੋ, Claude ਨੂੰ ਕਹੋ ਕਿ ਉਹ ਇਸਨੂੰ ਇੱਕ ਛੋਟੇ ਰਿਪ੍ਰੋ ਸਕੈਫੋਲਡ ਵਿੱਚ ਬਦਲੇ: ਇੱਕ ਨਿਊਨਤਮ ਟੈਸਟ ਜੋ ਫੇਲਿੰਗ ਫੰਕਸ਼ਨ ਨੂੰ ਛੋਟੇ ਇਨਪੁੱਟ ਨਾਲ ਕਾਲ ਕਰਦਾ ਹੈ, ਇੱਕ ਛੋਟਾ ਸਕ੍ਰਿਪਟ ਜੋ ਘੱਟ ਪੇਲੋਡ ਨਾਲ ਇੱਕ ਐਂਡਪੌਇੰਟ ਨੂੰ ਹਿੱਟ ਕਰਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਨਾਨੂ UI ਟੈਸਟ ਜੋ ਇੱਕ ਰੂਟ ਵੇਜ਼ਿਟ ਕਰਦਾ ਅਤੇ ਇੱਕ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ।
ਜਦ ਤੁਸੀਂ ਸਮੱਸਿਆ ਨੂੰ ਦੁਹਰਾਉ ਸਕਦੇ ਹੋ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਕੇਸ ਹੈ, ਤਾਂ ਅਨੁਮਾਨ ਲਾਉਣਾ ਛੱਡ ਦਿਓ। ਤੁਹਾਡਾ ਲਕੜੀ ਉਦੇਸ਼ ਇੱਕ ਛੋਟੀ ਸੂਚੀ 'ਤੇ ਆਉਣਾ ਹੈ ਜੋ ਸੰਭਾਵਿਤ ਕਾਰਨਾਂ ਦੀ ਹੈ, ਫਿਰ ਹਰ ਇੱਕ ਨੂੰ ਸਾਬਤ ਜਾਂ ਖੰਡਿਤ ਕਰੋ।
ਇੱਕ ਕਾਰਗਰ ਨਿਯਮ ਹੈ ਕਿ ਇਸਨੂੰ ਤਿੰਨ ਹਾਇਪੋਥੇਸਿਸ ਤੱਕ ਰੱਖੋ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਇਸ ਤੋਂ ਵੱਧ ਹਨ, ਤਾਂ ਤੁਹਾਡਾ ਟੈਸਟ ਕੇਸ ਸ਼ਾਇਦ ਅਜੇ ਵੀ ਬੜਾ ਹੈ ਜਾਂ ਤੁਹਾਡੇ ਪ੍ਰੇਖਣ ਧੁੰਦਲੇ ਹਨ।
ਜੋ ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ ਉਸਨੂੰ ਇਸ ਗੱਲ ਵਿੱਚ ਬਦਲੋ ਕਿ ਇਹ ਕਿੱਥੇ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ UI ਲੱਛਣ ਹਮੇਸ਼ਾ UI ਬੱਗ ਨਹੀਂ ਹੁੰਦਾ।
ਉਦਾਹਰਨ: ਇੱਕ React ਪੰਨਾ "Saved" ਟੋਸਟ ਦਿਖਾਉਂਦਾ ਹੈ, ਪਰ ਰਿਕਾਰਡ ਬਾਅਦ ਵਿੱਚ ਲਾਪਤਾ ਹੈ। ਇਹ (1) UI ਸਟੇਟ, (2) API ਵਿਵਹਾਰ, ਜਾਂ (3) ਡੇਟਾਬੇਸ ਰਾਈਟ ਪਾਥ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਸਕਦਾ ਹੈ।
Claude ਨੂੰ ਪੁੱਛੋ ਕਿ ਸੰਭਾਵਿਤ ਫੇਲ ਮੋਡ ਦਰਸਾਉਂਦਾ ਹੈ ਸਧਾਰਣ ਭਾਸ਼ਾ ਵਿੱਚ, ਫਿਰ ਪੁੱਛੋ ਕਿ ਹਰ ਇੱਕ ਦੀ ਪੁਸ਼ਟੀ ਲਈ ਕੀ ਵੇਖਣਾ ਚਾਹੀਦਾ। ਲਕੜੀ ਦਾ ਉਦੇਸ਼ “ਸ਼ਾਇਦ” ਨੂੰ “ਇਹ ਨਿਰਦਿਸ਼ਟ ਚੀਜ਼ ਚੈੱਕ ਕਰੋ” ਵਿੱਚ ਬਦਲਣਾ ਹੈ।
ਤਿੰਨ ਆਮ ਹਾਇਪੋਥੇਸਿਸ ਅਤੇ ਹਰ ਇੱਕ ਲਈ ਇਕ ਸਬੂਤ:
ਆਪਣੇ ਨੋਟਾਂ ਨੂੰ ਸਖਤ ਰੱਖੋ: ਲੱਛਣ, ਹਾਇਪੋਥੇਸਿਸ, ਸਬੂਤ, ਫੈਸਲਾ। ਜਦ ਇਕ ਅਨੁਮਾਨ ਤੱਥਾਂ ਨਾਲ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਲੌਕ ਕਰਨ ਅਤੇ ਸਿਰਫ਼ ਲੋੜੀਂਦੇ ਚੀਜ਼ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋ।
ਇੱਕ ਚੰਗਾ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਤੁਹਾਡਾ ਸੇਫਟੀ ਬੈਲਟ ਹੈ। ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਬੱਗ ਮੌਜੂਦ ਸੀ, ਅਤੇ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸ ਨੂੰ ਸੱਚਮੁਚ ਠੀਕ ਕੀਤਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਸ਼ੁਰੂ ਕਰੋ ਸਭ ਤੋਂ ਛੋਟੇ ਟੈਸਟ ਨਾਲ ਜੋ ਅਸਲ ਫੇਲ ਨੂੰ ਮਿਲਦਾ ਹੋਵੇ। ਜੇ ਬੱਗ ਸਿਰਫ਼ ਕਈ ਭਾਗਾਂ ਦੇ ਇਕੱਠੇ ਹੋਣ 'ਤੇ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਯੂਨਿਟ ਟੈਸਟ ਉਸਨੂੰ ਨਹੀਂ ਫੜੇਗਾ।
ਇੱਕ ਫੰਕਸ਼ਨ ਗਲਤ ਮੁੱਲ ਰਿਟਰਨ ਕਰ ਰਿਹਾ ਹੈ ਤਾਂ ਯੂਨਿਟ ਟੈਸਟ ਵਰਤੋਂ। ਜੇ ਬਾਊਂਡਰੀਸ ਸਮੱਸਿਆ ਹੈ (API ਹੈਂਡਲਰ + DB, ਜਾਂ UI + API) ਤਾਂ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਟੈਸਟ ਵਰਤੋਂ। ਸਿਰਫ ਜਦੋਂ ਪੂਰਾ ਯੂਜ਼ਰ ਫਲੋ ਜ਼ਰੂਰੀ ਹੋਵੇ ਤਾਂ ਏ2ਏ।
Claude ਨੂੰ ਕੁਝ ਵੀ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ, ਨਿਊਨਤਮ ਕੇਸ ਨੂੰ ਇੱਕ ਸਖਤ ਉਮੀਦ ਵਜੋਂ ਦੁਹਰਾਉ: ਉਦਾਹਰਨ: “ਜਦ ਯੂਜ਼ਰ ਖਾਲੀ ਟਾਈਟਲ ਸੇਵ ਕਰਦਾ ਹੈ, API ਨੂੰ 400 ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਸੁਨੇਹਾ ‘title required’ ਨਾਲ।” ਹੁਣ ਟੈਸਟ ਦਾ ਇੱਕ ਸਪੱਸ਼ਟ ਨਿਸ਼ਾਨ ਹੈ।
ਫਿਰ Claude ਤੋਂ ਪਹਿਲਾਂ ਫੇਲ ਹੋਣ ਵਾਲਾ ਟੈਸਟ ਡਰਾਫਟ ਕਰਵਾਓ। ਸੈਟਅਪ ਘੱਟੋ-ਘੱਟ ਰੱਖੋ ਅਤੇ ਕੇਵਲ ਉਹ ਡੇਟਾ ਕਾਪੀ ਕਰੋ ਜੋ ਬੱਗ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ। ਟੈਸਟ ਦਾ ਨਾਮ ਉਪਭੋਗਤਾ ਦੇ ਅਨੁਭਵ ਦੇ ਨਾਂ 'ਤੇ ਰੱਖੋ, ਨਾ ਕਿ ਅੰਦਰੂਨੀ ਫੰਕਸ਼ਨ ਤੇ।
ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ ਜਾਂਚ ਕਰੋ:
ਜਦ ਟੈਸਟ ਉਸੇ ਕਾਰਨ ਲਈ ਫੇਲ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਨੈਰੋ ਫਿਕਸ ਲਾਉਣ ਲਈ ਨਿਸ਼ਚਿਤ ਹੋ।
ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਛੋਟਾ ਰਿਪ੍ਰੋ ਅਤੇ ਇੱਕ ਫੇਲਿੰਗ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਹੋਵੇ, ਤਾਂ "ਸਾਫ਼-ਸੁਥਰਾ ਕਰ ਦਿਓ" ਦੀ ਖ਼ਾਹਸ਼ ਨੂੰ ਰੋਕੋ। هدف ਸਭ ਤੋਂ ਛੋਟੀ ਚੇਜ਼ ਹੈ ਜੋ ਟੈਸਟ ਨੂੰ ਸਹੀ ਕਾਰਨ ਲਈ ਪਾਸ ਕਰਵੇ।
ਇੱਕ ਚੰਗਾ ਨੈਰੋ ਫਿਕਸ ਸਭ ਤੋਂ ਛੋਟੀ ਸਤਹ ਨੂੰ ਬਦਲਦਾ ਹੈ। ਜੇ ਫੇਲ ਇਕ ਫੰਕਸ਼ਨ ਵਿੱਚ ਹੈ, ਓਸ ਫੰਕਸ਼ਨ ਨੂੰ ਠੀਕ ਕਰੋ, ਪੂਰੇ ਮੋਡੀਊਲ ਨੂੰ ਨਹੀਂ। ਜੇ ਬਾਊਂਡਰੀ ਚੈੱਕ ਗਾਇਬ ਸੀ, ਤਾਂ ਬਾਊਂਡਰੀ 'ਤੇ ਚੈੱਕ ਜੋੜੋ, ਕਾਲ ਚੇਨ ਭਰ ਵਿੱਚ ਨਹੀਂ।
ਜੇ ਤੁਸੀਂ Claude ਦੀ ਮਦਦ ਲੈ ਰਹੇ ਹੋ, ਤਾਂ ਦੋ ਫਿਕਸ ਵਿਕਲਪ ਮੰਗੋ, ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਸਕੋਪ ਅਤੇ ਖ਼ਤਰੇ ਲਈ ਤੁਲਨਾ ਕਰੋ। ਉਦਾਹਰਨ: React ਫਾਰਮ ਖਰਾਬ ਹੋ ਕੇ ਖ਼ਾਲੀ ਫੀਲਡ 'ਤੇ ਕ੍ਰੈਸ਼ ਕਰ ਰਹੀ ਹੈ, ਤਦ ਤੁਸੀਂ ਮਿਲ ਸਕਦੇ ਹੋ:
ਆਮ ਤੌਰ 'ਤੇ ਵਿਕਲਪ A ਟ੍ਰਾਇਏਜ ਚੋਣ ਹੁੰਦਾ ਹੈ: ਛੋਟਾ, ਆਸਾਨ ਰਿਵਿਊ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਹੋਰ ਚੀਜ਼ਾਂ ਤੋੜਨ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੁੰਦੀ ਹੈ।
ਨੈਰੋ ਰੱਖਣ ਲਈ ਘੱਟੋ-ਘੱਟ ਫਾਇਲਾਂ ਨੂੰ ਛੂਹੋ, ਲੋਕਲ ਫਿਕਸਾਂ ਨੂੰ ਰਿਫੈਕਟਰ ਵੱਲ ਤਰਜੀਹ ਦਿਓ, ਗਾਰਡ ਅਤੇ ਵੈਧਤਾ ਜੋੜੋ ਜਿੱਥੋਂ ਖਰਾਬ ਮੁੱਲ ਦਾਖਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਵਿਵਹਾਰ ਬਦਲਾਅ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਪਹਿਲਾਂ/ਬਾਅਦ ਨਾਲ ਰੱਖੋ। ਜਦ ਕਿ ਕਾਰਨ obvious ਨਾ ਹੋਵੇ ਤਾਂ ਹੀ ਟਿੱਪਣੀ ਛੱਡੋ।
ਇਕ ਕਨਕ੍ਰੀਟ ਉਦਾਹਰਨ: ਇੱਕ Go API ਐਂਡਪੌਇੰਟ ਪੈਨਿਕ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਵਿਵਕਲਪਿਕ ਕੁਐਰੀ ਪੈਰਾਮ ਮੌਜੂਦ ਨਹੀਂ ਹੁੰਦਾ। ਨੈਰੋ ਫਿਕਸ ਹੈ ਹੈਂਡਲਰ ਬਾਊਂਡਰੀ 'ਤੇ ਖਾਲੀ ਸਟਰਿੰਗ ਨੂੰ ਸੰਭਾਲਣਾ (ਡਿਫਾਲਟ ਨਾਲ ਪਾਰਸ ਕਰੋ, ਜਾਂ 400 ਰਿਟਰਨ ਕਰੋ ਸਪੱਸ਼ਟ ਸੁਨੇਹਾ ਨਾਲ)। ਸਾਂਝੇ ਪਾਰਸਿੰਗ ਯੂਟਿਲਿਟੀ ਨੂੰ ਬਦਲਣ ਤੱਕ ਨਾ ਜਾਓ ਜਦ ਤੱਕ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਸਾਬਿਤ ਨਾ ਕਰੇ ਕਿ ਸਮੱਸਿਆ ਉਸ ਸਾਂਝੇ ਕੋਡ ਵਿੱਚ ਹੈ।
ਚੇਂਜ ਤੋਂ ਬਾਅਦ, ਫੇਲਿੰਗ ਟੈਸਟ ਅਤੇ ਨੇੜਲੇ ਇੱਕ-ਦੋ ਟੈਸਟਾਂ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਓ। ਜੇ ਤੁਹਾਡਾ ਫਿਕਸ ਬੇਹਿਸਾਬ ਅਣ-ਸੰਬੰਧਤ ਟੈਸਟ ਅਪਡੇਟ ਕਰਨ ਲੱਜ਼ਮੀ ਬਣਾਉਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਿਗਨਲ ਹੈ ਕਿ ਚੇਂਜ ਬਹੁਤ ਵਿਆਪਕ ਹੈ।
ਵੈਰੀਫਿਕੇਸ਼ਨ ਉਹ ਰੁਕਾਵਟ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਛੋਟੀ, ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਸਕਣ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਫੜਦੇ ਹੋ: ਇੱਕ ਫਿਕਸ ਜੋ ਇੱਕ ਟੈਸਟ ਪਾਸ ਕਰਵਾਉਂਦਾ ਹੈ ਪਰ ਨੇੜੇ ਰਾਹ ਨੂੰ ਤੋੜਦਾ ਹੈ, ਇੱਕ ਐਰਰ ਸੁਨੇਹਾ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਸੁਸਤ ਕੁਐਰੀ ਜੋੜਦਾ ਹੈ।
ਪਹਿਲਾਂ, ਉਹ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਦੁਬਾਰਾ ਚਲਾਓ ਜੋ ਤੁਸੀਂ ਜੋੜਿਆ ਸੀ। ਜੇ ਇਹ ਪਾਸ ਹੋ ਗਿਆ, ਨੇੜਲੇ-ਨੇੜਲੇ ਟੈਸਟ ਚਲਾਓ: ਓਹੇ ਫਾਇਲ, ਓਹੇ ਮੋਡੀਊਲ, ਅਤੇ ਕੋਈ ਵੀ ਟੈਸਟ ਜੋ ਉਹੀ ਇਨਪੁੱਟ ਕਵਰ ਕਰਦਾ ਹੈ। ਬੱਗ ਅਕਸਰ ਸਾਂਝੇ ਹੈਲਪਰਾਂ, ਪਾਰਸਿੰਗ, ਬਾਊਂਡਰੀ ਚੈਕਾਂ, ਜਾਂ ਕੈਸ਼ਿੰਗ ਵਿੱਚ ਛੁਪਦੇ ਹਨ, ਇਸ ਲਈ ਸਭ ਤੋਂ ਸੰਬੰਧਤ ਫੇਲ ਨੇੜੇ ਹੀ ਮੁਲਾਂਕਣ ਵਿੱਚ ਆਉਂਦੇ ਹਨ।
ਫਿਰ ਮੂਲ ਰਿਪੋਰਟ ਦੇ ਉਹੀ ਕਦਮ ਅਨੁਸਾਰ ਇੱਕ ਛੋਟੀ ਮੈਨੁਅਲ ਚੈੱਕ ਕਰੋ। ਛੋਟਾ ਅਤੇ ਨਿਰਧਾਰਿਤ ਰੱਖੋ: ਉਹੀ ਵਾਤਾਵਰਨ, ਉਹੀ ਡੇਟਾ, ਉਹੀ ਕਲਿੱਕ ਜਾਂ API ਕਾਲਾਂ ਕ੍ਰਮ। ਜੇ ਰਿਪੋਰਟ ਧੁੰਦਲੀ ਸੀ, ਤਾਂ ਉਸ ਖਾਸ ਸਥਿਤੀ ਦੀ ਤੁਸੀਂ ਜਿਨ੍ਹਾਂ ਨਾਲ ਰਿਪ੍ਰੋ ਕੀਤਾ ਸੀ ਉਹੀ ਟੈਸਟ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਧਿਆਨ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, Claude ਨੂੰ ਆਪਣੇ ਚੇਂਜ ਅਤੇ ਫੇਲਿੰਗ ਸਥਿਤੀ 'ਤੇ ਆਧਾਰਿਤ ਛੋਟੀ ਵੈਰੀਫਿਕੇਸ਼ਨ ਯੋਜਨਾ ਮੰਗੋ। ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਫਾਇਲ ਨੂੰ ਬਦਲਿਆ, ਤੁਸੀਂ ਕੀ ਉਮੀਦ ਕੀਤੀ, ਅਤੇ ਕੀ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦਾ ਹੈ। ਵਧੀਆ ਯੋਜਨਾਵਾਂ ਛੋਟੀ ਤੇ ਕਾਰਗਰ ਹੁੰਦੀਆਂ ਹਨ: 5 ਤੋਂ 8 ਚੈੱਕ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਖ਼ਤਮ ਕਰ ਸਕਦੇ ਹੋ, ਹਰੇਕ ਦਾ ਸਪੱਸ਼ਟ ਪਾਸ/ਫੇਲ।
ਅਖੀਰ 'ਚ, ਜੋ ਤੁਸੀਂ ਵੈਰੀਫਾਈ ਕੀਤਾ ਉਸਨੂੰ PR ਜਾਂ ਨੋਟਸ ਵਿੱਚ ਦਰਜ ਕਰੋ: ਕਿਸ ਟੈਸਟ ਚਲਾਏ, ਕਿਹੜੇ ਮਨੁਅਲ ਕਦਮ ਕੀਤੇ, ਅਤੇ ਕੋਈ ਸੀਮਾਵਾਂ (ਉਦਾਹਰਣ ਲਈ, “ਮੋਬਾਈਲ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ”)। ਇਹ ਫਿਕਸ ਨੂੰ ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਅਤੇ ਮੁੜ ਵੇਖਣ ਲਈ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਸਮਾਂ ਵੈਸਟ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇਕ “ਫਿਕਸ” ਨੂੰ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਬੂਲ ਕਰ ਲਓ ਕਿ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਮੁੱਦੇ ਨੂੰ ਭਰੋਸੇ ਨਾਲ ਦੁਹਰਾਉਣਾ ਨਹੀਂ ਸਿੱਖ ਲੈਂਦੇ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਕਰਨਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣ ਸਕਦੇ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਬਿਹਤਰ ਹੋਇਆ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: ਜਦ ਤੱਕ ਤੁਸੀਂ ਇੱਕ ਦੁਹਰਾਊ ਸੈਟਅਪ (ਠੀਕ ਕਦਮ, ਇਨਪੁਟ, ਵਾਤਾਵਰਨ, ਅਤੇ "ਖਰਾਬ" ਕੀ ਦਿਖਦਾ ਹੈ) ਵੇਰਵਾ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਫਿਕਸ ਮੰਗੋ ਨਹੀਂ। ਜੇ ਰਿਪੋਰਟ ਧੁੰਦਲੀ ਹੈ, ਤਾਂ ਆਪਣੀਆਂ ਪਹਿਲੀਆਂ ਮਿੰਟਾਂ ਨੂੰ ਇਸਨੂੰ ਇੱਕ ਚੈਕਲਿਸਟ ਵਿੱਚ ਬਦਲਣ 'ਤੇ ਖਰਚ ਕਰੋ ਜੋ ਤੁਸੀਂ ਦੋ ਵਾਰ ਚਲਾ ਕੇ ਉਹੀ ਨਤੀਜਾ ਲੈ ਸਕੋ।
ਰਿਪ੍ਰੋਡਯੂਸਬਲ ਕੇਸ ਦੇ ਬਿਨਾਂ ਫਿਕਸ ਕਰਨਾ. ਇੱਕ ਨਿਊਨਤਮ "ਹਰ ਵਾਰੀ ਫੇਲ" ਸਕ੍ਰਿਪਟ ਜਾਂ ਕਦਮ ਲੋੜੀਂਦਾ ਕਰੋ। ਜੇ ਇਹ ਸਿਰਫ "ਕਦੇ-ਕਦੇ" ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਟਾਈਮਿੰਗ, ਡੇਟਾ ਸਾਈਜ਼, ਫੀਚਰ ਫਲੈਗ, ਅਤੇ ਲੌਗ ਇਹਨਾ ਤਬ ਤਕ ਇਕੱਠੇ ਕਰੋ ਜਦ ਤੱਕ ਇਹ ਰੈਂਡਮ ਨਾ ਰਹਿ ਜਾਏ।
ਬਹੁਤ ਜਲਦੀ ਘੱਟ ਕਰਨਾ. ਜੇ ਤੁਸੀਂ ਮੂਲ ਫੇਲ ਨੂੰ ਪੁਸ਼ਟੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੇਸ ਨੂੰ ਘਟਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸਿਗਨਲ ਗੁੰਮ ਕਰ ਸਕਦੇ ਹੋ। ਪਹਿਲਾਂ ਬੇਸਲਾਈਨ ਰਿਪ੍ਰੋ ਲੌਕ ਕਰੋ, ਫਿਰ ਇੱਕ-ਇਕ ਕਰਕੇ ਘਟਾਓ।
Claude ਨੂੰ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦਿਓ. Claude ਸੰਭਾਵਿਤ ਕਾਰਨ ਦੱਸ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਹਮੇਸ਼ਾ ਸਬੂਤ ਚਾਹੀਦਾ ਹੈ। 2–3 ਹਾਇਪੋਥੇਸਿਸ ਮੰਗੋ ਅਤੇ ਹਰ ਇੱਕ ਨੂੰ ਪੁਸ਼ਟੀ ਕਰਨ ਵਾਲੀਆਂ ਵਿਸ਼ੇਸ਼ ਨਿਰੀਕਸ਼ਣ ਵਿਖਾਓ (ਇੱਕ ਲੌਗ ਲਾਈਨ, ਇੱਕ ਬਰੇਕਪੋਇੰਟ, ਇੱਕ ਕੁਐਰੀ ਨਤੀਜਾ)।
ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਜੋ ਗਲਤ ਕਾਰਨ ਲਈ ਪਾਸ ਹੁੰਦੇ ਹਨ. ਇੱਕ ਟੈਸਟ “ਪਾਸ” ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕਦੇ ਵੀ ਫੇਲਿੰਗ ਪਾਥ 'ਤੇ ਨਹੀਂ ਜਾਂਦਾ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ ਫਿਕਸ ਤੋਂ ਪਹਿਲਾਂ ਫੇਲ ਹੁੰਦਾ ਸੀ, ਅਤੇ ਇਹ ਉਮੀਦ ਕੀਤੀ ਗਈ ਸੁਨੇਹਾ ਜਾਂ ਅਸਰਸ਼ਨ ਲਈ ਫੇਲ ਹੁੰਦਾ ਹੈ।
ਲੱਛਣਾਂ ਦੀ ਥਾਂ ਟ੍ਰਿਗਰ ਨੂੰ ਇਲਾਜ ਕਰਨਾ. ਜੇ ਤੁਸੀਂ ਨੱਲ ਚੈੱਕ ਜੋੜਦੇ ਹੋ ਪਰ ਅਸਲ ਮੁੱਦਾ ਇਹ ਹੈ ਕਿ "ਇਹ ਮੂਲ ਰੂਪ ਵਿੱਚ ਨੱਲ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ," ਤਾਂ ਤੁਸੀਂ ਗਹਿਰਾ ਬੱਗ ਛੁਪਾਉ ਸਕਦੇ ਹੋ। ਬੁਰਾ ਸਥਿਤੀ ਬਣਾਉਣ ਵਾਲੀ ਹਾਲਤ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਤਰਜੀਹ ਦਿਓ।
ਨਵਾਂ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਅਤੇ ਮੂਲ ਰਿਪ੍ਰੋ ਸਟੈਪ ਨੂੰ ਆਪਣੀ ਬਦਲ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਚਲਾਓ। ਜੇ ਇੱਕ ਚੈੱਕਆਊਟ ਬੱਗ ਸਿਰਫ਼ ਤਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਪ੍ਰੋਮੋ ਕੋਡ ਸ਼ਿਪਿੰਗ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਲਾਗੂ ਕੀਤਾ ਗਿਆ, ਤਾਂ ਉਸ ਪੂਰੇ ਕ੍ਰਮ ਨੂੰ ਆਪਣੀ “ਸੱਚਾਈ” ਵਜੋਂ ਰੱਖੋ, ਭਾਵੇਂ ਤੁਹਾਡਾ ਘੱਟਾ ਟੈਸਟ ਛੋਟਾ ਹੋ।
ਜੇ ਤੁਹਾਡੀ ਵੈਰੀਫਿਕੇਸ਼ਨ “ਹੁਣ ਵਧੀਆ ਲੱਗਦਾ ਹੈ” 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਇਕ-ਸਪੱਸ਼ਟ ਚੈੱਕ (ਲੌਗ, ਮੈਟ੍ਰਿਕ, ਜਾਂ ਨਿਰਧਾਰਤ ਆਉਟਪੁੱਟ) ਜੋੜੋ ਤਾਂ ਕਿ ਅਗਲਾ ਵਿਅਕਤੀ ਤੇਜ਼ੀ ਨਾਲ ਉਸਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕੇ।
ਜਦ ਤੁਸੀਂ ਸਮਾਂ ਦਬਾਅ ਵਿੱਚ ਹੋ, ਇੱਕ ਛੋਟਾ, ਦੁਹਰਾਊ ਲੂਪ ਹੀ ਮਹਾਨ ਬਕਾਇਆ ਡੀਬੱਗਿੰਗ ਕਰਦਾ ਹੈ।
ਅਖੀਰ ਦਾ ਫੈਸਲਾ ਕੁਝ ਸਤਰਾਂ ਵਿੱਚ ਲਿਖੋ ਤਾਂ ਕਿ ਅਗਲਾ ਵਿਅਕਤੀ (ਅਕਸਰ ਭਵਿੱਖ ਦਾ ਤੁਸੀਂ) ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕੇ। ਇੱਕ ਉਪਯੋਗੀ ਫਾਰਮੈਟ ਹੋ ਸਕਦਾ ਹੈ: “Root cause: X. Trigger: Y. Fix: Z. Why safe: W. What we did not change: Q.”
ਅਗਲੇ ਕਦਮ: ਜੋ ਕੁਝ ਤੁਸੀਂ ਆਟੋਮੇਟ ਕਰ ਸਕਦੇ ਹੋ ਉਹ ਆਟੋਮੇਟ ਕਰੋ (ਇੱਕ ਸੰਭਾਲਿਆ ਰਿਪ੍ਰੋ ਸਕ੍ਰਿਪਟ, ਇੱਕ ਸਟੈਂਡਰਡ ਟੈਸਟ ਕਮਾਂਡ, ਰੂਟ-ਕਾਰਨ ਨੋਟਸ ਲਈ ਇੱਕ ਟੈਮਪਲੇਟ)।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਨਾਲ ਐਪ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ Planning Mode ਤੁਹਾਨੂੰ ਬਦਲਾਅ ਦਾ ਆਉਟਲਾਈਨ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਕੋਡ ਛੂਹੋ, ਅਤੇ ਸਨੇਪਸ਼ਾਟ/ਰੋਲਬੈਕ ਤੁਹਾਨੂੰ ਪ੍ਰਯੋਗ ਦੌਰਾਨ ਸੁਰੱਖਿਅਤ ਅਨੁਭਵ ਕਰਾਉਂਦੇ ਹਨ। ਇੱਕ ਵਾਰ ਫਿਕਸ ਵੈਰੀਫਾਈ ਹੋ ਜਾਣ 'ਤੇ, ਤੁਸੀਂ ਸੋर्स ਕੋਡ ਨਿਰਯਾਤ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਅਪਡੇਟ ਕੀਤੀ ਐਪ ਡਿਪਲੌਇ ਅਤੇ ਹੋਸਟ ਕਰ ਸਕਦੇ ਹੋ, ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ קਸਟਮ ਡੋਮੇਨ ਸਹਿਤ।
ਬੱਗ ਟ੍ਰਾਇਏਜ ਉਸ ਆਦਤ ਨੂੰ ਕਹਿੰਦੇ ਹਨ ਜਿਸ ਵਿੱਚ ਇਕ ਅਸਪਸ਼ਟ ਰਿਪੋਰਟ ਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ, ਟੈਸਟ ਕਰਨਯੋਗ ਬਿਆਨ ਵਿੱਚ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਸਭ ਤੋਂ ਛੋਟੀ ਚੇਜ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜੋ ਉਹ ਬਿਆਨ ਬਰਾਬਰ ਨਾ ਰਹਿਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੇ।
ਇਹ "ਸਭ ਕੁਝ ਠੀਕ ਕਰੋ" ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਹੈ, ਸਗੋਂ ਅਣਿਸ਼ਚਿਤਤਾ ਨੂੰ ਕਦਮ-ਦਰ-ਕਦਮ ਘਟਾਉਣਾ ਹੈ: ਰਿਪ੍ਰੋਡਿਊਸ ਕਰੋ, ਘੱਟ ਕਰੋ, ਸਬੂਤ-ਆਧਾਰਿਤ ਜੁਆਬਦਾਰੀਆਂ ਬਣਾਓ, ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਜੋੜੋ, ਨੈਰੋ ਫਿਕਸ ਕਰੋ ਅਤੇ ਵੈਰੀਫਾਈ ਕਰੋ।
ਕਿਉਂਕਿ ਹਰ ਕਦਮ ਇੱਕ ਵੱਖਰਾ ਅਣਜਾਣ ਪੱਖ ਘਟਾਉਂਦਾ ਹੈ।
ਇਸ ਨੂੰ ਦੁਬਾਰਾ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੋ: “ਜਦੋਂ ਮੈਂ X ਕਰਦਾ/ਦੀ ਹਾਂ, ਮੈਂ ਉਮੀਦ ਕਰਦਾ/ਦੀ ਹਾਂ Y, ਪਰ ਮੈਨੂੰ Z ਮਿਲਦਾ ਹੈ.”
ਫਿਰ ਟੈਸਟ ਕਰਨਯੋਗ ਬਣਾਉਣ ਲਈ ਜ਼ਰੂਰੀ ਸੰਦੇਸ਼ ਇਕੱਠੇ ਕਰੋ:
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਉਸ ਸਭ ਤੋਂ ਛੋਟੇ ਵਾਤਾਵਰਨ 'ਚ ਰਿਪ੍ਰੋ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਮੁੱਦਾ ਦਿਖਾਉਂਦਾ ਹੈ (ਅਕਸਰ ਲੋਕਲ ਡੈਵ ਨਾਲ ਇੱਕ ਛੋਟੀ ਡੇਟਾਸੈਟ)।
ਜੇ ਇਹ “ਕਦੇ-ਕਦੇ” ਹੁੰਦਾ ਹੈ, ਤਾਂ ਵੈਰੀਏਬਲਾਂ ਨੂੰ ਕੰਟਰੋਲ ਕਰਕੇ ਇਸਨੂੰ ਡੀਟੈਰਮਿਨਿਸਟਿਕ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ:
ਜਦ ਤੱਕ ਤੁਸੀਂ ਮੰਗੇ ਤੇ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਇਸਨੂੰ ਫੇਲ ਕਰਨਾ ਨਹੀਂ ਦੇਖਦੇ, ਅੱਗੇ ਨਾ ਵਧੋ।
ਮਿਨੀਮਾਈਜ਼ੇਸ਼ਨ ਦਾ ਮਤਲਬ ਹੈ ਉਹ ਸਭ ਹਟਾਉਣਾ ਜੋ ਲਾਜ਼ਮੀ ਨਹੀਂ ਹੈ ਪਰ ਬੱਗ ਨੂੰ ਰੱਖਣਾ।
“ਅੱਧਾ ਹਟਾਓ ਅਤੇ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰੋ” ਇੱਕ ਵਰਤੋਂਯੋਗ ਤਰੀਕਾ ਹੈ:
ਕਦੋਂ ਤੱਕ ਤੁਸੀਂ ਬੱਗ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਸੰਰਚਨਾ ਵਿੱਚ ਦੁਹਰਾਉ ਸਕਦੇ ਹੋ, ਨਹੀਂ ਰੁਕੋ।
Claude Code ਨੂੰ ਵਿਸ਼ਲੇਸ਼ਣ ਤੇ ਗਤੀ ਲਈ ਵਰਤੋ, ਪਰ ਵੈਰਿਫਿਕੇਸ਼ਨ ਆਪ ਕਰੋ।
ਚੰਗੀਆਂ ਬੇਨਤੀਆਂ ਉਦਾਹਰਨ:
ਫਿਰ ਤੁਸੀਂ ਲੋਕਲ ਵਿਵਸਥਾ ਤੇ ਦੁਹਰਾਓ, ਲੌਗ/ਟਰੇਸ ਚੈੱਕ ਕਰੋ, ਅਤੇ ਦੇਖੋ ਕਿ ਟੈਸਟ ਠੀਕ ਕਾਰਨ ਲਈ ਫੇਲ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਸਮੇਂ 'ਚ ਤਿੰਨ ਰੁੱਖ-ਕਾਰਨ ਅਨੁਮਾਨ ਰੱਖੋ। ਇਸ ਤੋਂ ਜ਼ਿਆਦਾ ਹੋਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡਾ ਰਿਪ੍ਰੋ ਅਜੇ ਵੀ ਬੜਾ ਹੈ ਜਾਂ ਪ੍ਰੇਖਣ ਧੁੰਦਲੇ ਹਨ।
ਹਰ ਅਨੁਮਾਨ ਲਈ ਲਿਖੋ:
ਉਹ ਸਭ ਤੋਂ ਛੋਟਾ ਟੈਸਟ ਪੱਧਰ ਚੁਣੋ ਜੋ ਫੇਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ:
ਇੱਕ ਚੰਗਾ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ:
ਸਭ ਤੋਂ ਛੋਟੀ ਚੇਂਜ ਕਰੋ ਜੋ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਨੂੰ ਸਹੀ ਕਾਰਨ ਲਈ ਪਾਸ ਕਰਵਾ ਦਿੰਦੀ ਹੈ।
ਨਿਯਮ-ਇੱਸਰੇ:
ਇਹ ਤਰੀਕਾ ਜੋਖਮ ਘਟਾਉਂਦਾ ਹੈ।
ਵੈਰੀਫਿਕੇਸ਼ਨ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਛੋਟੀ, ਆਸਾਨ-ਨਜ਼ਰਅੰਦਾਜ਼ ਗਲਤੀਆਂ ਫੜਦੇ ਹੋ: ਇੱਕ ਫਿਕਸ ਜੋ ਇਕ ਟੈਸਟ ਪਾਸ ਕਰਵਾਉਂਦਾ ਹੈ ਪਰ ਨੇੜੇ ਰਾਹ ਨੂੰ ਤੋੜ ਦਿੰਦਾ ਹੈ, ਸੁਨੇਹਾ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਸੁਸਤ ਕਵੈਰੀ ਜੋੜਦਾ ਹੈ।
ਪਹਿਲਾਂ ਆਪਣਾ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਦੁਬਾਰਾ ਚਲਾਓ। ਜੇ ਪਾਸ ਹੋ ਗਿਆ, ਨੇੜਲੇ ਟੈਸਟਾਂ ਨੂੰ ਚਲਾਓ: ਉਹ ਫਾਇਲ, ਮੋਡੀਊਲ ਅਤੇ ਉਹ ਜੋ ਉਹੀ ਇਨਪੁਟ ਕਵਰ ਕਰਦੇ ਹਨ।
ਫਿਰ ਮੂਲ ਰਿਪੋਰਟ ਦੇ ਉਹੀ ਕਦਮ ਤੁਰੰਤ ਮਨੁਅਲ ਚੈੱਕ ਕਰੋ: ਉਹੀ ਵਾਤਾਵਰਨ, ਉਹੀ ਡੇਟਾ, ਉਹੀ ਕਿਰਿਆ-ਸ਼੍ਰੇਣੀ।
ਅਖੀਰ 'ਤੇ PR ਜਾਂ ਨੋਟਸ ਵਿੱਚ ਜੋ ਤੁਸੀਂ ਵੈਰੀਫਾਈ ਕੀਤਾ, ਉਹ ਦਰਜ ਕਰੋ: ਕਿਸ ਟੈਸਟ ਚਲਾਏ, ਕਿਸ ਮਨੁਅਲ ਕਦਮ ਨੂੰ ਕੋਸ਼ਿਸ਼ ਕੀਤਾ, ਅਤੇ ਕੀ ਨਹੀਂ ਚੈੱਕ ਕੀਤਾ ਗਿਆ।
ਇਸ ਨਾਲ ਤਰੱਕੀ ਹੁੰਦੀ ਹੈ ਅਤੇ ਬੇਅੰਤ “ਸ਼ਾਇਦ ਇਹ X ਹੈ” ਡਿਬੱਗਿੰਗ ਰੁਕਦੀ ਹੈ।