05 ਜਨ 2026·6 ਮਿੰਟ
ਉਹ ਬੱਗ ਰਿਪੋਰਟਾਂ ਡੀਬੱਗ ਕਰੋ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਲਿਖੀਆਂ: ਇੱਕ ਵਿਆਵਹਾਰਿਕ ਵਰਕਫਲੋ
ਉਹ ਬੱਗ ਰਿਪੋਰਟਾਂ ਡੀਬੱਗ ਕਰੋ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਲਿਖੀਆਂ — ਮੁੱਦੇ ਨੂੰ ਦੁਹਰਾਓ, UI/API/DB ਨੂੰ ਵੱਖ ਕਰੋ, ਅਤੇ ਇੱਕ ਘੱਟ, ਟੈਸਟ ਕਰਨ ਯੋਗ AI/ਮੈਨੂੰਅਲ ਫਿਕਸ ਮੰਗੋ।
ਉਹ ਬੱਗ ਰਿਪੋਰਟਾਂ ਡੀਬੱਗ ਕਰੋ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਲਿਖੀਆਂ — ਮੁੱਦੇ ਨੂੰ ਦੁਹਰਾਓ, UI/API/DB ਨੂੰ ਵੱਖ ਕਰੋ, ਅਤੇ ਇੱਕ ਘੱਟ, ਟੈਸਟ ਕਰਨ ਯੋਗ AI/ਮੈਨੂੰਅਲ ਫਿਕਸ ਮੰਗੋ।
ਜਿਹੜੀ ਬੱਗ ਰਿਪੋਰਟ ਤੁਸੀਂ ਨਹੀਂ ਲਿਖੀ, ਉਸਨੂੰ ਡੀਬੱਗ ਕਰਨਾ ਔਖਾ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਕੋਲ ਮੂਲ ਬਣਾਉਣ ਵਾਲੇ ਦਾ ਮਾਨਸਿਕ ਨਕਸ਼ਾ ਨਹੀਂ ਹੁੰਦਾ। ਤੁਹਾਨੂੰ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਕੀ ਨਾਜ਼ੁਕ ਹੈ, ਕੀ "ਸਹੀ" ਹੈ, ਜਾਂ ਕਿਹੜੀਆਂ ਛੁੱਟੀਆਂ ਰਾਹਾਂ ਲਈਆਂ ਗਈਆਂ। ਇਕ ਛੋਟੀ ਲੱਛਣ (ਇੱਕ ਬਟਨ, ਇਕ ਟਾਈਪੋ, ਇੱਕ ਸਲੋ ਸਕ੍ਰੀਨ) ਵੀ deeper ਮੁੱਦੇ ਤੋਂ ਆ ਸਕਦੀ ਹੈ — API, ਡੇਟਾਬੇਸ, ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਵਿੱਚ।
ਇੱਕ ਉਪਯੋਗੀ ਬੱਗ ਰਿਪੋਰਟ ਤੁਹਾਨੂੰ ਚਾਰ ਚੀਜ਼ਾਂ ਦਿੰਦੀ ਹੈ:
ਜ਼ਿਆਦਾਤਰ ਰਿਪੋਰਟਾਂ ਸਿਰਫ ਆਖਰੀ ਇਕ ਦਿੰਦੀਆਂ ਹਨ: "Saving doesn't work," "it's broken," "random error." ਜੋ ਗੁੰਮ ਹੈ ਉਹ ਸੰਦਰਭ ਹੈ ਜੋ ਇਸਨੂੰ ਦੁਹਰਾਏ ਯੋਗ ਬਣਾਉਂਦਾ: ਯੂਜ਼ਰ ਰੋਲ, ਖਾਸ ਰਿਕਾਰਡ, ਵਾਤਾਵਰਣ (prod vs staging), ਅਤੇ ਇਹ ਕਿ ਕੀ ਇਹ ਕਿਸੇ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਸ਼ੁਰੂ ਹੋਇਆ।
ਮਕਸਦ ਇੱਕ ਅਸਪਸ਼ਟ ਲੱਛਣ ਨੂੰ ਇਕ ਭਰੋਸੇਯੋਗ ਰੀਪ੍ਰੋ ਵਿੱਚ ਬਦਲਣਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਮੰਗ 'ਤੇ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਇਹ ਹੋਰ ਰਾਜ਼ ਨਹੀਂ ਰਹਿੰਦਾ। ਇਹ ਇੱਕ ਲੜੀ ਚੈੱਕਸ ਬਣ ਜਾਂਦੀ ਹੈ।
ਤੁਸੀਂ ਤੁਰੰਤ ਜੋ ਕੰਟਰੋਲ ਕਰ ਸਕਦੇ ਹੋ:
"Done" ਦਾ ਮਤਲਬ "ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਮੈਂ ਨੇ ਠੀਕ ਕੀਤਾ" ਨਹੀਂ। Done ਉਹ ਹੈ: ਤੁਹਾਡੇ ਰੀਪ੍ਰੋ steps ਇੱਕ ਛੋਟੀ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਪਾਸ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਜਲਦੀ ਨੇੜਲੇ ਵਰਤਾਰੇ ਦੀ ਰੀਟੈਸਟਿੰਗ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦਾ ਸੀ।
ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਸਮਾਂ ਖੋਣ ਦਾ ਤਰੀਕਾ ਹੈ ਇੱਕੋ ਸਮੇਂ ਕਈ ਚੀਜ਼ਾਂ ਬਦਲਨਾ। ਆਪਣਾ ਸ਼ੁਰੂਆਤੀ ਨੁਕਤਾ ਫ੍ਰੀਜ਼ ਕਰੋ ਤਾਂ ਜੋ ਹਰ ਟੈਸਟ ਨਤੀਜਾ ਕਿਸੇ ਮਤਲਬ ਰੱਖੇ।
ਇੱਕ ਵਾਤਾਵਰਣ ਚੁਣੋ ਅਤੇ ਉਸੇ 'ਤੇ ਟਿਕੇ ਰਹੋ ਜਦ ਤਕ ਤੁਸੀਂ ਮੁੱਦੇ ਨੂੰ ਦੁਹਰਾ ਨਹੀਂ ਸਕਦੇ। ਜੇ ਰਿਪੋਰਟ ਪ੍ਰੋਡਕਸ਼ਨ ਤੋਂ ਆਈ ਸੀ ਤਾਂ ਪਹਿਲਾਂ ਉੱਥੇ ਪੁਸ਼ਟੀ ਕਰੋ। ਜੇ ਇਹ ਖਤਰਨਾਕ ਹੈ ਤਾਂ staging ਵਰਤੋ। ਲੋਕਲ ਠੀਕ ਹੈ ਜੇ ਤੁਸੀਂ ਡੇਟਾ ਅਤੇ ਸੈਟਿੰਗਜ਼ ਨੂੰ ਨਜ਼ਦੀਕੀ ਤੌਰ 'ਤੇ ਮੇਲ ਕਰ ਸਕਦੇ ਹੋ।
ਫਿਰ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਕੋਡ ਚੱਲ ਰਿਹਾ ਹੈ: ਵਰਜਨ, build date, ਅਤੇ ਕੋਈ ਵੀ feature flags ਜਾਂ config ਜੋ ਫਲੋ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ। ਛੋਟੀਆਂ ਭਿੰਨਤਾਵਾਂ (ਵਿਚਕਾਰ integrations ਬੰਦ ਹੋਣਾ, ਵੱਖਰਾ API base URL, ਗਾਇਬ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ) ਇੱਕ ਅਸਲ ਬੱਗ ਨੂੰ ਭੂਤ ਵਿੱਚ ਬਦਲ ਸਕਦੀਆਂ ਹਨ।
ਇੱਕ ਸਾਫ਼, ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਟੈਸਟ ਸੈਟਅਪ ਬਣਾਓ। ਤਾਜ਼ਾ ਖਾਤਾ ਅਤੇ ਜਾਣਿਆ ਹੋਇਆ ਡੇਟਾ ਵਰਤੋਂ। ਜੇ ਮुमਕਿਨ ਹੋਵੇ, ਹਰ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਪਹਿਲਾਂ ਸਥਿਤੀ ਰੀਸੈਟ ਕਰੋ (ਲੌਗ ਆਊਟ, ਕੈਸ਼ ਸਾਫ਼ ਕਰੋ, ਇੱਕੋ ਰਿਕਾਰਡ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ)।
ਆਪਣੇ ਧਾਰਣਾਂ ਨੂੰ ਲਿਖੋ ਜਦੋਂ ਤੁਸੀਂ ਜਾਂਦੇ ਹੋ। ਇਹ ਫੁਜ਼ੀ ਕੰਮ ਨਹੀਂ; ਇਹ ਬਾਅਦ ਵਿੱਚ ਆਪਣੇ ਆਪ ਨਾਲ ਜ਼ਹਨੀ ਟਕਰਾਅ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਇੱਕ ਬੇਸਲਾਈਨ ਨੋਟ ਟੈਮਪਲੇਟ:
ਜੇ ਰੀਪ੍ਰੋ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਇਹ ਨੋਟਸ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਅਗਲੇ ਕਦਮ ਵਿੱਚ ਤੁਸੀਂ ਕਿਸ ਨੂੰ ਬਦਲੋ, ਇੱਕ-ਇੱਕ knob ਵਾਰ।
ਤੁਰੰਤ ਜਿੱਤ ਹਾਂ ਇੱਕ ਅਜਿਹੀ ਅਸਪਸ਼ਟ ਸ਼ਿਕਾਇਤ ਨੂੰ ਐਸੇ ਕੁਝ ਵਿੱਚ ਬਦਲ ਦੇਣਾ ਜੋ ਤੁਸੀਂ ਇੱਕ ਸਕ੍ਰਿਪਟ ਵਾਂਗ ਚਲਾ ਸਕੋ।
ਰਿਪੋਰਟ ਨੂੰ ਇੱਕ ਛੋਟੀ user story ਵਾਂਗ ਮੁੜ ਲਿਖਣ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ: ਕੌਣ ਕੀ ਕਰ ਰਿਹਾ ਹੈ, ਕਿੱਥੇ, ਅਤੇ ਉਹ ਕੀ ਉਮੀਦ ਕਰ ਰਿਹਾ ਸੀ। ਫਿਰ ਵੇਖਿਆ ਗਿਆ ਨਤੀਜਾ ਜੋੜੋ।
ਉਦਾਹਰਨ ਦੁਬਾਰਾ ਲਿਖਾਈ:
"As a billing admin, when I change an invoice status to Paid and click Save on the invoice page, the status should persist. Instead, the page stays the same and the status is unchanged after refresh."
ਅਗਲਾ, ਉਹ ਹਾਲਤਾਂ ਕੈਪਚਰ ਕਰੋ ਜੋ ਰਿਪੋਰਟ ਨੂੰ ਸਚ ਬਨਾਉਂਦੀਆਂ ਹਨ। ਬੱਗ ਅਕਸਰ ਇੱਕ ਘੱਟ-ਡਿੱਟੇਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ: ਰੋਲ, ਰਿਕਾਰਡ ਸਟੇਟ, ਲੋਕੇਲ ਜਾਂ ਵਾਤਾਵਰਣ।
ਰਿਮਜ਼ ਵਰਣਨ ਕਰਨ ਲਈ ਮੁੱਖ ਇਨਪੁੱਟਾਂ:
ਉਹ ਬਿਹੀਵਿਯਰ ਕੈਪਚਰ ਕਰੋ ਜਦ ਤਕ ਤੁਹਾਡੇ ਕੋਲ ਅਸਲ ਵਰਤਾਰਾ ਹੈ। ਸਕ੍ਰੀਨਸ਼ਾਟਸ ਮਦਦਗਾਰ ਹਨ, ਪਰ ਇੱਕ ਛੋਟਾ ਰਿਕਾਰਡਿੰਗ ਬਿਹਤਰ ਹੈ ਕਿਉਂਕਿ ਇਸ ਵਿੱਚ ਟਾਇਮਿੰਗ ਅਤੇ ਸਹੀ ਕਲਿਕਸ ਆ ਜਾਂਦੇ ਹਨ। ਹਮੇਸ਼ਾ ਇੱਕ timestamp ਨੋਟ ਕਰੋ (ਟਾਈਮਜ਼ੋਨ ਸਮੇਤ) ਤਾਂ ਜੋ ਤੁਸੀਂ ਲੌਗਸ ਨਾਲ ਮੇਲ ਕਰ ਸਕੋ।
ਤੀਨ ਸਾਫ਼ ਕਰਨ ਵਾਲੇ ਸਵਾਲ ਜੋ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਅਨੁਮਾਨ ਘਟਾਉਂਦੇ ਹਨ:
ਕਾਰਨ ਦੇ ਅਨੁਮਾਨ ਨਾਲ ਸ਼ੁਰੂ ਨਾ ਕਰੋ। ਸਮੱਸਿਆ ਨੂੰ ਇਰਾਦੇ ਨਾਲ, ਇੱਕੋ ਹੀ ਢੰਗ ਨਾਲ ਅਤੇ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰੀ ਬਣਾਉ।
ਪਹਿਲਾਂ, ਰਿਪੋਰਟਰ ਦੇ ਕਦਮਾਂ ਨੂੰ ਠੀਕ ਠੀਕ ਦੌਰਾਉ। ਉਨ੍ਹਾਂ ਨੂੰ "ਸੁਧਾਰ" ਨਾ ਕਰੋ। ਜੋ ਪਹਿਲਾ ਥਾਂ ਤੁਹਾਡਾ ਅਨੁਭਵ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ, ਉਸਨੂੰ ਨੋਟ ਕਰੋ, ਭਾਵੇਂ ਉਹ ਛੋਟਾ ਲੱਗੇ (ਵੱਖਰਾ ਬਟਨ ਲੇਬਲ, ਮਿਸਿੰਗ ਫੀਲਡ, ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਐਰਰ ਟੈਕਸਟ)। ਉਹ ਪਹਿਲਾ ਅਨਮੈਚ ਅਕਸਰ ਇਸ਼ਾਰਾ ਹੁੰਦਾ ਹੈ।
ਆਮ ਐਪਾਂ ਵਿੱਚ ਕੰਮ ਕਰਨ वाला ਇੱਕ ਸਧਾਰਨ ਵਰਕਫਲੋ:
ਜਦੋਂ ਇਹ ਦੁਹਰਾਏ ਯੋਗ ਹੋ ਜਾਵੇ, ਇੱਕ-ਇੱਕ ਚੀਜ਼ ਵੱਖ-ਵੱਖ ਬਦਲੋ। ਇਕ-ਵੈਰੀਏਬਲ ਟੈਸਟਾਂ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਨਤੀਜਾ ਦਿੰਦੀਆਂ ਹਨ:
ਅੰਤ 'ਤੇ ਇੱਕ ਛੋਟੀ repro ਸਕ੍ਰਿਪਟ ਛੱਡੋ ਜੋ ਕੋਈ ਹੋਰ 2 ਮਿੰਟ ਵਿੱਚ ਚਲਾ ਸਕੇ: ਪ੍ਰਾਰੰਭਿਕ ਸਥਿਤੀ, ਕਦਮ, ਇਨਪੁੱਟ, ਅਤੇ ਪਹਿਲੀ failing ਪਰਖਾਂ।
ਪੂਰੇ ਕੋਡਬੇਸ ਨੂੰ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਿਹੜਾ ਲੇਅਰ ਫੇਲ ਕਰ ਰਿਹਾ ਹੈ।
ਸਵਾਲ ਪੁੱਛੋ: ਕੀ ਲੱਛਣ ਸਿਰਫ UI ਵਿੱਚ ਹੈ, ਜਾਂ ਡੇਟਾ ਅਤੇ API ਜਵਾਬਾਂ ਵਿੱਚ ਵੀ ਹੈ?
ਉਦਾਹਰਨ: "ਮੇਰਾ ਪ੍ਰੋਫਾਈਲ ਨਾਂ ਅਪਡੇਟ ਨਹੀਂ ਹੋਇਆ." ਜੇ API ਨਵਾਂ ਨਾਂ ਵਾਪਸ ਕਰਦਾ ਹੈ ਪਰ UI ਪੁਰਾਣਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ UI state/caching ਤੇ ਸੰਦਰਭ ਸ਼ੱਕ ਕਰੋ। ਜੇ API ਕਦੇ ਵੀ ਸੇਵ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਮੁਕਾਬਲਾ API ਜਾਂ DB ਖੇਤਰ ਹੈ।
ਤੁਰੰਤ ਟ੍ਰਿਆਜ ਲਈ ਸਵਾਲ ਜੋ ਤੁਸੀਂ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹੋ:
UI ਚੈਕਾਂ ਭਰੋਸੇਯੋਗਤਾ ਬਾਰੇ ਹੁੰਦੇ ਹਨ: console errors, Network tab, ਅਤੇ stale state (UI save ਦੇ ਬਾਅਦ re-fetch ਨਾ ਕਰਨਾ ਜਾਂ ਪੁਰਾਣੇ cache ਤੋਂ ਪੜ੍ਹਨਾ)।
API ਚੈਕਾਂ contract ਬਾਰੇ ਹੁੰਦੇ ਹਨ: payload (fields, types, IDs), status code, ਅਤੇ error body. ਇੱਕ 200 ਜਿਸਦੀ ਬਾਡੀ ਅਚੰਭੇ ਵਾਲੀ ਹੋਵੇ, ਉਹ 400 ਤੱਕ ਦੇ ਜਵਾਬ ਵਰਗਾ ਮਹੱਤਵ ਰੱਖ ਸਕਦਾ ਹੈ।
DB ਚੈਕਸ ਰੀਅਲਟੀ ਬਾਰੇ ਹੁੰਦੇ ਹਨ: ਗਾਇਬ ਰੋਜ਼, ਅਧੂਰੇ ਲਿਖਤ, constraint failures, ਉਹ ਅਪਡੇਟ ਜਿਹੜੇ zero rows ਨੂੰ ਟਚ ਕਰ ਰਹੇ ਹਨ ਕਿਉਂਕਿ WHERE clause ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।
ਪ੍ਰਸਿੱਧ ਰਹਿਣ ਲਈ ਇਕ ਛੋਟਾ ਨਕਸ਼ਾ ਬਣਾਓ: ਕਿਹੜਾ UI action ਕਿਸ endpoint ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਕਿਹੜੀਆਂ table(s) ਨੂੰ ਪੜ੍ਹਦਾ ਜਾਂ ਲਿਖਦਾ ਹੈ।
ਸਪਸ਼ਟਤਾ ਅਕਸਰ ਇੱਕ ਅਸਲੀ ਬੇਨਤੀ ਨੂੰ ਕਲਿਕ ਤੋਂ ਡੇਟਾਬੇਸ ਤੱਕ ਅਤੇ ਵਾਪਸ ਫਾਲੋ ਕਰਨ ਤੋਂ ਆਉਂਦੀ ਹੈ।
ਰਿਪੋਰਟ ਜਾਂ ਤੁਹਾਡੇ ਰੀਪ੍ਰੋ ਤੋਂ ਤਿੰਨ ਐਂਕਰ ਲੋ:
ਜੇ ਤੁਹਾਡੇ ਕੋਲ correlation ID ਨਹੀਂ ਹੈ, ਤਾਂ ਆਪਣੇ gateway/backend ਵਿੱਚ ਇੱਕ ਜੋੜੋ ਅਤੇ ਇਸਨੂੰ response headers ਅਤੇ logs ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰੋ।
ਸ਼ੋਰ-ਸ਼ਰਾਬੇ ਵਿੱਚ ਡੁੱਬਣ ਤੋਂ ਬਚਣ ਲਈ, ਸਿਰਫ ਉਹੀ ਕੈਪਚਰ ਕਰੋ ਜੋ ਸਵਾਲ "ਕਿੱਥੇ ਫੇਲ ਹੋਇਆ ਅਤੇ ਕਿਉਂ?" ਦਾ ਜਵਾਬ ਦੇਵੇ:
ਨਿਸ਼ਾਨੀਅਾਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ:
ਜੇ "ਕੱਲ੍ਹ ਚੱਲ ਰਹਿਆ ਸੀ" ਪਰ ਅੱਜ ਨਹੀਂ, ਤਾਂ ਵਾਤਾਵਰਣ drift 'ਤੇ ਸ਼ੱਕ ਕਰੋ: ਫਲੈਗਸ ਬਦਲੇ, secrets ਰੋਟੇਟ ਹੋਏ, missing migrations, ਜਾਂ ਰੁਕੇ ਹੋਏ jobs।
ਸਭ ਤੋਂ ਆਸਾਨ ਬੱਗ ਠੀਕ ਕਰਨ ਯੋਗ ਏਕ ਛੋਟਾ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਪਰਖ ਹੁੰਦਾ ਹੈ।
ਹਰ ਚੀਜ਼ ਨੂੰ ਘਟਾਓ: ਘੱਟ ਕਲਿੱਕ, ਘੱਟ ਫੀਲਡ, ਸਭ ਤੋਂ ਛੋਟੀ ਡੇਟਾਸੈਟ ਜੋ ਫੇਲ ਹੋਣੀ ਨਵੀ ਹੈ। ਜੇ ਇਹ ਕੇਵਲ "ਕਈ ਰਿਕਾਰਡ ਵਾਲੇ customers" ਨਾਲ ਹੀ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਘੱਟੋ-ਘੱਟ ਕੇਸ ਬਣਾਉ ਜੋ ਫਿਰ ਵੀ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਬਣਾਉ ਸਕਦੇ, ਤਾਂ ਇਹ ਸੰਕੇਤ ਹੈ ਕਿ ਬੱਗ ਡੇਟਾ-ਪਰਿਮਾਣ ਜਾਂ ਵਾਲੀਅਮ-ਸਬੰਧੀ ਹੋ ਸਕਦੀ ਹੈ।
"ਬੁਰਾ ਸਟੇਟ" ਨੂੰ "ਬੁਰਾ ਕੋਡ" ਤੋਂ ਵੱਖਰਾ ਕਰਨ ਲਈ ਸੂਬਾ ਸੂਚਿਤ ਰੀਸੈਟ ਕਰੋ: ਸਾਫ ਖਾਤਾ, ਤਾਜ਼ਾ ਟੇਨੈਂਟ ਜਾਂ ਡੇਟਾਸੈਟ, ਜਾਣਿਆ ਹੋਇਆ build।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕ ਇੱਕ ਕੰਪੈਕਟ ਇਨਪੁੱਟ ਟੇਬਲ ਰੱਖਣਾ ਹੈ:
| Given (setup) | When (action) | Expect | Got |
|---|---|---|---|
| User role: Editor; one record with Status=Draft | Click Save | Toast "Saved" + updated timestamp | Button shows spinner then stops; no change |
ਰੀਪ੍ਰੋ ਨੂੰ ਪੋਰਟੇਬਲ ਬਣਾਓ ਤਾਂ ਜੋ ਕੋਈ ਹੋਰ ਤੇਜ਼ੀ ਨਾਲ ਚਲਾ ਸਕੇ:
ਸਭ ਤੋਂ ਤੇਜ਼ ਰਾਹ ਆਮ ਤੌਰ 'ਤੇ ਸਾਧਾਰਣ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਚੀਜ਼ ਬਦਲੋ, ਦੇਖੋ, ਨੋਟਸ ਰੱਖੋ।
ਆਮ ਗਲਤੀਆਂ:
ਇੱਕ ਯਥਾਰਥ ਉਦਾਹਰਨ: ਇੱਕ ਟਿਕਟ ਵਿੱਚ ਕਿਹਾ ਗਿਆ "Export CSV ਖਾਲੀ ਆ ਰਿਹਾ ਹੈ." ਤੁਸੀਂ admin ਖਾਤੇ ਨਾਲ ਟੈਸਟ ਕਰਦੇ ਹੋ ਅਤੇ ਡੇਟਾ ਵੇਖਦੇ ਹੋ। ਯੂਜ਼ਰ ਦਾ ਰੋਲ restricted ਹੈ ਅਤੇ API permission filter ਕਾਰਨ ਖਾਲੀ ਲਿਸਟ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ UI ਨੂੰ ਕੇਵਲ "No rows" ਦਿਖਾਉਣ ਲਈ ਪੈਚ ਕਰ ਦਿਤਾ ਤਾਂ ਤੁਸੀਂ ਅਸਲ ਸਵਾਲ ਗੁਆ ਬੈਠੋ: ਕੀ ਉਸ ਰੋਲ ਨੂੰ export ਦੀ ਆਗਿਆ ਹੋਣੀ ਚਾਹੀਦੀ ਸੀ, ਜਾਂ product ਨੂੰ ਜਾਣਕਾਰੀ ਦੇਣੀ ਚਾਹੀਦੀ ਕਿ ਫਿਲਟਰ ਕਰਕੇ ਕੋਈ ਪਤਿਆਂ ਨਹੀਂ ਮਿਲੇ?
ਕਿਸੇ ਵੀ ਫਿਕਸ ਤੋਂ ਬਾਅਦ, ਉਹੇ ਰੀਪ੍ਰੋ ਕਦਮ ਦੁਹਰਾਓ ਜੋ ਮੂਲ ਤੌਰ 'ਤੇ ਦਿੱਤੇ ਗਏ ਸਨ, ਫਿਰ ਇੱਕ ਨੇੜਲਾ ਸੈਨੇਰਿਓ ਟੈਸਟ ਕਰੋ ਜੋ ਹੁਣ ਵੀ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇਕ ਸੰਗੀਨ ਪੈਕੇਜ ਨਾਲ ਆਓਗੇ ਤਾਂ ਟੀਮਮੈਟ (ਜਾਂ ਟੂਲ) ਵਲੋਂ ਵਧੀਆ ਜਵਾਬ ਮਿਲਣਗੇ: ਦੋਹਰਾਏ ਜਾਣ ਯੋਗ ਕਦਮ, ਇੱਕ ਸੰਭਾਵਿਤ ਫੇਲ ਲੇਅਰ, ਅਤੇ ਸਬੂਤ।
ਕੋਡ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪੱਕਾ ਕਰੋ:
ਫਿਰ ਇੱਕ ਛੋਟਾ regression pass ਕਰੋ: ਵੱਖਰਾ ਰੋਲ, ਦੂਜਾ browser/private window, ਇੱਕ ਨੇੜਲਾ ਫੀਚਰ ਜੋ ਉਹੀ endpoint/table ਵਰਤਦਾ ਹੈ, ਅਤੇ ਇੱਕ edge-case ਇਨਪੁੱਟ (ਖਾਲੀ, ਲੰਬਾ ਟੈਕਸਟ, ਵਿਸ਼ੇਸ਼ ਅੱਖਰ)।
ਸਪੋਰਟ ਸੁਨੇਹੇ ਵਿੱਚ ਕਿਹਾ ਗਿਆ: "Edit Customer ਫਾਰਮ 'ਤੇ Save ਬਟਨ ਕੁਝ ਨਹੀਂ ਕਰਦਾ." ਇਕ follow-up ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ ਕਿ ਇਹ ਸਿਰਫ ਉਹ ਗਾਹਕਾਂ ਲਈ ਹੁੰਦਾ ਜੋ ਪਿਛਲੇ ਮਹੀਨੇ ਤੋਂ ਪਹਿਲਾਂ ਬਣੇ ਸਨ, ਅਤੇ ਸਿਰਫ ਜਦੋਂ ਤੁਸੀਂ billing email ਬਦਲਦੇ ਹੋ।
UI ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਸਭ ਤੋਂ ਸਧਾਰਣ ਫੇਲ-ਕਾਰਨ ਨੂੰ ਧਾਰਨਾ ਕਰੋ। ਰਿਕਾਰਡ ਖੋਲ੍ਹੋ, ਸੋਧ ਕਰੋ, ਅਤੇ ਵੇਖੋ ਕਿ "ਕੁਝ ਨਹੀਂ" ਅਸਲ ਵਿੱਚ ਕਿਸੇ ਚੀਜ਼ ਦਾ ਸੰਕੇਤ ਹੈ: disabled button, hidden toast, validation message ਜੋ render ਨਹੀਂ ਹੋ ਰਿਹਾ। ਫਿਰ ਬ੍ਰਾਉਜ਼ਰ console ਅਤੇ Network tab ਖੋਲੋ।
ਇੱਥੇ, Save 'ਤੇ ਕਲਿਕ ਕਰਨ ਨਾਲ ਇਕ ਰਿਕਵੈਸਟ ਟ੍ਰਿਗਰ ਹੁੰਦੀ ਹੈ, ਪਰ UI ਨਤੀਜਾ ਕਦੇ ਵੀ ਨਹੀਂ ਦਿਖਾਂਦਾ ਕਿਉਂਕਿ frontend ਕੇਵਲ 200 ਨੂੰ success ਮੰਨਦਾ ਹੈ ਅਤੇ 400 errors ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ। Network tab 400 ਰਿਸਪਾਂਸ ਦਿਖਾਂਦਾ ਹੈ ਜਿਹੜਾ JSON ਬਾਡੀ ਵਰਗਾ ਹੈ: {\"error\":\"billingEmail must be unique\"}.
ਹੁਣ verify ਕਰੋ ਕਿ API ਵਾਸਤਵ ਵਿੱਚ ਫੇਲ ਹੋ ਰਿਹਾ ਹੈ: ਰਿਕਵੈਸਟ ਤੋਂ ਠੀਕ-ਠੀਕ payload ਲੈਕੇ ਇਸਨੂੰ ਦੁਹਰਾ ਦਿਓ। ਜੇ ਇਹ UI ਤੋਂ ਬਿਨਾਂ ਵੀ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਫਰੰਟਐਂਡ ਸਟੇਟ ਬਗ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹੋ।
ਫਿਰ ਡੇਟਾਬੇਸ ਚੈੱਕ ਕਰੋ: ਇਹ ਅੰਦਾਜ਼ਾ ਲਗਾਓ ਕਿ uniqueness ਕਿਉਂ ਸਿਰਫ ਪੁਰਾਣੇ ਰਿਕਾਰਡਾਂ ਤੇ ਫੇਲ ਕਰ ਰਹੀ ਹੈ? ਤੁਸੀਂ ਪਤਾ ਲਗਾਉਂਦੇ ਹੋ ਕਿ legacy customers ਸਾਲਾਂ ਪਹਿਲਾਂ ਇੱਕ placeholder billing_email ਸਾਂਝਾ ਕਰਦੇ ਸੀ। ਇੱਕ ਨਵੀਂ uniqueness ਚੈਕ ਹੁਣ ਕਿਸੇ ਵੀ ਗਾਹਕ ਨੂੰ ਜਿਨ੍ਹਾਂ ਕੋਲ ਉਹੀ placeholder ਹੈ, ਬਚਾ ਕੇ ਰੱਖਣ 'ਤੇ ਰੋਕਦੀ ਹੈ।
Minimum repro ਜੋ ਤੁਸੀਂ ਹਸਤਾਂਤਰਿਤ ਕਰ ਸਕਦੇ ਹੋ:
billing_email = [email protected] ਹੈbillingEmail must be uniqueAcceptance test: ਜਦੋਂ API validation error ਵਾਪਸ ਕਰੇ, UI ਸੁਨੇਹਾ ਦਿਖਾਏ, ਯੂਜ਼ਰ ਦੀਆਂ ਸੋਧਾਂ ਨੂੰ ਰੱਖੇ, ਅਤੇ error ਉਸ ਖਾਸ ਫੀਲਡ ਦਾ ਨਾਂ ਦੱਸੇ ਜੋ ਫੇਲ ਹੋਈ।
ਜਦੋਂ ਬੱਗ reproducible ਹੋਵੇ ਅਤੇ ਤੁਸੀਂ ਸੰਭਾਵਿਤ ਲੇਅਰ ਪਛਾਣ ਲਈ ਹੋ, ਮਦਦ ਮੰਗੋ ਇਸ ਤਰੀਕੇ ਨਾਲ ਕਿ ਛੋਟਾ, ਸੁਰੱਖਿਅਤ ਪੈਚ ਮਿਲੇ।
ਇੱਕ ਸਧਾਰਨ "case file" ਪੈਕੇਜ ਕਰੋ: ਘੱਟੋ-ਘੱਟ repro steps (ਇਨਪੁੱਟ, ਵਾਤਾਵਰਣ, ਰੋਲ), ਉਮੀਦ ਵਿਰੁੱਧ ਅਸਲ, ਤੁਸੀਂ ਕਿਉਂ ਸਮਝਦੇ ਹੋ ਕਿ ਇਹ UI/API/DB ਹੈ, ਅਤੇ ਸਬ ਤੋਂ ਛੋਟਾ ਲੌਗ excerpt ਜੋ ਫੇਲ ਦਰਸਾਉਂਦਾ ਹੈ।
ਫਿਰ ਬੇਨਤੀ ਨਰਾਰੋ ਕਰੋ:
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਇਹ case-file ਪਹੁੰਚ ਸੁਝਾਅਾਂ ਨੂੰ ਕੇਂਦਰਿਤ ਰੱਖਦੀ ਹੈ। ਇਸਦੇ snapshots ਅਤੇ rollback ਤੁਹਾਨੂੰ ਛੋਟੇ ਬਦਲਾਅ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਟੈਸਟ ਕਰਨ ਅਤੇ ਜਾਣੇ-ਪਛਾਣ ਵਾਲੀ ਸਥਿਤੀ 'ਤੇ ਵਾਪਸ ਜਾਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ।
ਜਦੋਂ ਫਿਕਸ security, payments, data migrations ਜਾਂ ਅਜਿਹੀਆਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਛੂਹਦਾ ਹੋਵੇ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦੀ ਹੈ, ਤਾਂ ਇਹ ਕੰਮ ਕਿਸੇ ਤਜਰਬੇਕਾਰ developer ਨੂੰ ਹਵਾਲਾ ਕਰੋ। ਉਹ ਵੀ ਹਵਾਲਾ ਕਰੋ ਜੇ ਬਦਲਾਅ ਇੱਕ ਛੋਟੀ ਪੈਚ ਤੋਂ ਵੱਧ ਵਿਸਥਾਰ 'ਤੇ ਚਲਾ ਜਾ ਰਿਹਾ ਹੋਵੇ ਜਾਂ ਤੁਸੀਂ ਖ਼ਤਰੇ ਨੂੰ ਸਧੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਸਮਝਾ ਨਹੀਂ ਪਾ ਰਹੇ।
ਪਹਿਲਾਂ ਇਸਨੂੰ reproducible ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਲਿਖੋ: ਕਿਸਨੇ (ਰੋਲ), ਕਿੱਥੇ (ਪੇਜ/ਫਲੋ), ਸਹੀ इनਪੁਟਾਂ (IDs, ਫਿਲਟਰ, ਪੇਲੋਡ), ਤੁਸੀਂ ਕੀ ਉਮੀਦ ਕੀਤੀ ਸੀ, ਅਤੇ ਤੁਸੀਂ ਕੀ ਵੇਖਿਆ। ਜੇ ਇਹ ਹਿੱਸੇ ਗਾਇਬ ਹਨ ਤਾਂ ਇਕ ਨਮੂਨਾ ਖਾਤਾ ਅਤੇ ਇਕ ਨਮੂਨਾ ਰਿਕਾਰਡ ID ਮੰਗੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਓਹੀ ਸਿਨੈਰੀਓ ਐਂਡ-ਟੂ-ਐਂਡ ਚਲਾ ਸਕੋ।
ਇੱਕ ਮਾਹਿਰੇ ਤਰੀਕੇ ਲਈ ਇੱਕ ਵਾਤਾਵਰਣ ਚੁਣੋ ਅਤੇ ਉੱਥੇ ਹੀ ਰਹੋ ਹੇਠਾਂ ਤਕ ਜੋ ਤਸੀਂ ਮੁੱਦਾ ਦੁਹਰਾ ਸਕੋ। ਫਿਰ build/version, feature flags, config, ਟੈਸਟ ਖਾਤਾ/ਰੋਲ ਅਤੇ ਵਰਤੇ ਗਏ ਨਿਰਧਾਰਤ ਡੇਟਾ ਨੂੰ ਦਰਜ ਕਰੋ। ਇਹ ਤੁਹਾਨੂੰ ਇਸ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਐਸਾ ਬਗ ਠੀਕ ਕਰ ਰਹੇ ਹੋ ਜੋ ਕੇਵਲ ਤੁਹਾਡੇ ਸੈਟਅਪ ਦੀ ਕਾਰਨ ਹੈ।
ਉਹੀ ਕਦਮ ਅਤੇ ਇਨਪੁੱਟਾਂ ਨਾਲ ਵਾਰ-ਵਾਰ ਦੋ ਵਾਰ ਹੋਣ ਦਿਓ, ਫਿਰ ਜੋ ਲੋੜੀਂਦਾ ਨਹੀਂ ਹੈ ਉਸਨੂੰ ਹਟਾਉ. ਕੋਸ਼ਿਸ਼ ਕਰੋ 3–6 ਕਦਮਾਂ ਦੀ ਇਕ ਸਾਫ਼ सूची ਬਣਾਉ ਜੋ ਸਾਫ ਸਟਾਰਟ ਤੋਂ ਚੱਲਦੀ ਹੋਵੇ ਅਤੇ ਇਕ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਰਿਕਾਰਡ ਜਾਂ ਰਿਕਵੇਸਟ ਬਾਡੀ ਹੋਵੇ. ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਘਟਾ ਨਹੀਂ ਸਕਦੇ ਤਾਂ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲੇ ਵਿੱਚ ਇਹ ਡੇਟਾ-ਵਾਲਿਊਮ, ਟਾਈਮਿੰਗ ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਡੀਪੈਂਡੈਂਸੀ ਦਾ ਇਸ਼ਾਰਾ ਹੈ।
ਕੋਈ ਵੀ ਤਬਦੀਲੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੁੜ-ਪ੍ਰੋਡਿਊਸ ਕਰੋ। ਪਹਿਲਾਂ ਰਿਪੋਰਟਰ ਦੇ ਕਦਮਾਂ ਨੂੰ ਠੀਕ ਠੀਕ ਦੌਰਾਉ ਅਤੇ ਨੋਟ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਅਨੁਭਵ ਵਿੱਚ ਪਹਿਲਾ ਅੰਤਰ ਕਿੱਥੇ ਆਉਂਦਾ ਹੈ (ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਬਟਨ ਲੇਬਲ, ਮਿਸਿੰਗ ਫੀਲਡ, ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਐਰਰ ਟੈਕਸਟ). ਉਹ ਪਹਿਲਾ ਅੰਤਰ ਅਕਸਰ ਅਸਲ ਟਿਗਰ ਦੀ ਚਾਬੀ ਹੁੰਦਾ ਹੈ।
ਚੇਕ ਕਰੋ ਕਿ ਡੇਟਾ ਵਾਸਤਵ ਵਿੱਚ ਬਦਲਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੇ API ਨਵਾਂ ਮੁੱਲ ਵਾਪਸ ਕਰਦਾ ਹੈ ਪਰ UI ਪੁਰਾਣਾ ਵੇਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ UI ਸਟੇਟ, ਕੈਸ਼ਿੰਗ ਜਾਂ ਰੀ-ਫੈਚਿੰਗ ਦੀ ਸੰਭਾਵਨਾ ਹੈ। ਜੇ API ਜਵਾਬ ਗਲਤ ਹੈ ਜਾਂ ਸੇਵ ਨਹੀਂ ਹੋ ਰਿਹਾ, ਤਾਂ API ਜਾਂ DB ਉੱਤੇ ਧਿਆਨ ਦਿਓ। ਜੇ DB ਰੋਅ ਨਹੀਂ ਅਪਡੇਟ ਹੁੰਦੀ, ਤਾਂ ਪERSISTENCE ਲੇਅਰ ਜਾਂ ਕੁয়ারੀ ਸ਼ਰਤਾਂ ਦੀ ਜਾਂਚ ਕਰੋ।
ਨੈੱਟਵਰਕ ਰਿਕਵੈਸਟ ਜਾਂਚੋ ਕਿ ਓਹ ਫਾਇਰ ਹੋ ਰਹੀ ਹੈ, ਫਿਰ ਰਿਕਵੈਸਟ ਪੇਲੋਡ ਅਤੇ ਰਿਸਪਾਂਸ ਬਾਡੀ ਨੂੰ ਇੰਸਪੈਕਟ ਕਰੋ, ਸਿਰਫ ਸਟੇਟਸ ਕੋਡ ਨਹੀਂ। ਇੱਕ timestamp (ਟਾਈਮਜ਼ੋਨ ਸਮੇਤ) ਅਤੇ ਯੂਜ਼ਰ identifier ਕੈਪਚਰ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਬੈਕਐਂਡ ਲੌਗਸ ਨਾਲ ਮੇਲ ਕਰ ਸਕੋ। ਕਈ ਵਾਰੀ 200 ਹੋ ਕੇ ਵੀ ਗਲਤ ਬਾਡੀ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ।
ਇੱਕ-ਇੱਕ ਕਰਕੇ ਇੱਕ ਜ਼ਿੰਦਗੀ ਵਿਕਲਪ ਬਦਲੋ: ਰੋਲ, ਰਿਕਾਰਡ (ਨਵਾਂ ਵਿ. ਲੇਗੇਸੀ), ਬ੍ਰਾਉਜ਼ਰ/ਡਿਵਾਈਸ, ਸਾਫ ਸੈਸ਼ਨ (ਇੰਕੋਗਨੀਟੋ/ਕੈਸ਼ ਸਾਫ), ਅਤੇ ਨੈਟਵਰਕ. ਇਕ-ਵੈਰੀਏਬਲ ਟੈਸਟਿੰਗ ਇਸ਼ਾਰਾ ਦਿੰਦੀ ਹੈ ਕਿ ਕਿਹੜਾ ਸ਼ਰਤ ਮਹੱਤਵਪੂਰਨ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਇਕੱਠੇ ਬਦਲ ਕੇ ਭਟਕਣ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ।
ਇੱਕ-ਥਾਂ 'ਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਬਦਲਣਾ, ਰਿਪੋਰਟਰ ਦੇ ਵੱਖਰੇ ਵਾਤਾਵਰਣ 'ਤੇ ਟੈਸਟ ਕਰਨਾ, ਅਤੇ ਰੋਲ/ਪ੍ਰੇਮੀਸ਼ਨ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਵੱਡੇ ਸਮੇਂ ਦੀ ਬਰਬਾਦੀ ਹਨ। ਇੱਕ ਹੋਰ ਪ੍ਰਚਲਿਤ ਫੇਲ-ਪੈਟਰਨ UI ਦੀ ਸਤਹੀ ਸਮੱਸਿਆ ਨੂੰ ਠੀਕ ਕਰ ਦੇਣਾ ਹੈ ਜਦਕਿ ਨਿਮਨ API/DB ਵੈਧਤਾ ਵਿੱਚ ਅਜੇ ਵੀ ਦिक਼ਤ ਹੈ। ਹਮੇਸ਼ਾ ਆਪਣੀ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਉਹੇ ਰੀਪ੍ਰੋ ਕਦਮ ਦੁਬਾਰਾ ਚਲਾਓ ਅਤੇ ਇੱਕ ਨੇੜਲਾ ਸਵਾਲ ਭੀ ਜਾਚੋ।
“Done” ਦਾ ਮਤਲਬ ਹੈ: ਮੂਲ ਨਿਮਨ ਰੀਪ੍ਰੋ ਹੁਣ ਪਾਸ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਇੱਕ ਨੇੜਲੇ ਫਲੋ ਨੂੰ ਜਾਂਚਿਆ ਹੈ ਜੋ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦਾ ਸੀ. ਇਸਨੂੰ ਕਿਸੇ ਨਜਿੱਠ ਰੂਪ ਵਿੱਚ ਰੱਖੋ — ਜਿਵੇਂ ਵਿਜ਼ੁਅਲ ਸਫਲਤਾ ਸੰਕੇਤ, ਸਹੀ HTTP ਜਵਾਬ, ਜਾਂ ਉਮੀਦ ਕੀਤੀ DB ਰੋਅ ਚੇੰਜ. “ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਇਹ ਠੀਕ ਹੈ” ਬਿਨਾਂ ਇਕਸਾਰ ਟੈਸਟ ਦੇ ਕਾਫੀ ਨਹੀਂ।
ਇੱਕ ਤੰਗ case file ਦਿਓ: ਘੱਟੋ-ਘੱਟ ਸਟੈਪਸ (ਇਨਪੁੱਟ, ਵਾਤਾਵਰਣ, ਰੋਲ), ਉਮੀਦ ਵਿਰੁੱਧ ਅਸਲ, ਅਤੇ ਇਕ ਪ੍ਰਮਾਣ (ਰਿਕਵੈਸਟ/ਰਿਸਪਾਂਸ, ਐਰਰ ਟੈਕਸਟ, ਜਾਂ ਲੌਗ ਸਨਿੱਪੇਟ). ਫਿਰ ਸਭ ਤੋਂ ਛੋਟੀ ਪੈਚ ਦਾ ਸੁਝਾਅ ਮੰਗੋ ਜੋ ਰੀਪ੍ਰੋ ਨੂੰ ਪਾਸ ਕਰਵਾ ਸਕੇ ਅਤੇ ਇਕ ਛੋਟਾ ਟੈਸਟ ਪਲਾਨ ਸ਼ਾਮਿਲ ਕਰੋ. ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਇਹ case-file ਵਿਧੀ ਸੁਝਾਅਾਂ ਨੂੰ ਕੇਂਦਰਿਤ ਰੱਖਦੀ ਹੈ।