ਉਹ ਬੱਗ ਰਿਪੋਰਟਾਂ ਡੀਬੱਗ ਕਰੋ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਲਿਖੀਆਂ: ਇੱਕ ਵਿਆਵਹਾਰਿਕ ਵਰਕਫਲੋ

ਕੀ ਇਹ ਬੱਗ ਰਿਪੋਰਟਾਂ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੀਆਂ ਹਨ (ਅਤੇ ਤੁਸੀਂ ਕੀ ਕੰਟਰੋਲ ਕਰ ਸਕਦੇ ਹੋ)

ਜਿਹੜੀ ਬੱਗ ਰਿਪੋਰਟ ਤੁਸੀਂ ਨਹੀਂ ਲਿਖੀ, ਉਸਨੂੰ ਡੀਬੱਗ ਕਰਨਾ ਔਖਾ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਕੋਲ ਮੂਲ ਬਣਾਉਣ ਵਾਲੇ ਦਾ ਮਾਨਸਿਕ ਨਕਸ਼ਾ ਨਹੀਂ ਹੁੰਦਾ। ਤੁਹਾਨੂੰ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਕੀ ਨਾਜ਼ੁਕ ਹੈ, ਕੀ "ਸਹੀ" ਹੈ, ਜਾਂ ਕਿਹੜੀਆਂ ਛੁੱਟੀਆਂ ਰਾਹਾਂ ਲਈਆਂ ਗਈਆਂ। ਇਕ ਛੋਟੀ ਲੱਛਣ (ਇੱਕ ਬਟਨ, ਇਕ ਟਾਈਪੋ, ਇੱਕ ਸਲੋ ਸਕ੍ਰੀਨ) ਵੀ deeper ਮੁੱਦੇ ਤੋਂ ਆ ਸਕਦੀ ਹੈ — API, ਡੇਟਾਬੇਸ, ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਵਿੱਚ।

ਇੱਕ ਉਪਯੋਗੀ ਬੱਗ ਰਿਪੋਰਟ ਤੁਹਾਨੂੰ ਚਾਰ ਚੀਜ਼ਾਂ ਦਿੰਦੀ ਹੈ:

• ਠੀਕ ਕਾਰਵਾਈ
• ਠੀਕ ਡੇਟਾ
• ਉਮੀਦ ਕੀਤਾ ਨਤੀਜਾ
• ਅਸਲ ਨਤੀਜਾ

ਜ਼ਿਆਦਾਤਰ ਰਿਪੋਰਟਾਂ ਸਿਰਫ ਆਖਰੀ ਇਕ ਦਿੰਦੀਆਂ ਹਨ: "Saving doesn't work," "it's broken," "random error." ਜੋ ਗੁੰਮ ਹੈ ਉਹ ਸੰਦਰਭ ਹੈ ਜੋ ਇਸਨੂੰ ਦੁਹਰਾਏ ਯੋਗ ਬਣਾਉਂਦਾ: ਯੂਜ਼ਰ ਰੋਲ, ਖਾਸ ਰਿਕਾਰਡ, ਵਾਤਾਵਰਣ (prod vs staging), ਅਤੇ ਇਹ ਕਿ ਕੀ ਇਹ ਕਿਸੇ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਸ਼ੁਰੂ ਹੋਇਆ।

ਮਕਸਦ ਇੱਕ ਅਸਪਸ਼ਟ ਲੱਛਣ ਨੂੰ ਇਕ ਭਰੋਸੇਯੋਗ ਰੀਪ੍ਰੋ ਵਿੱਚ ਬਦਲਣਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਮੰਗ 'ਤੇ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਇਹ ਹੋਰ ਰਾਜ਼ ਨਹੀਂ ਰਹਿੰਦਾ। ਇਹ ਇੱਕ ਲੜੀ ਚੈੱਕਸ ਬਣ ਜਾਂਦੀ ਹੈ।

ਤੁਸੀਂ ਤੁਰੰਤ ਜੋ ਕੰਟਰੋਲ ਕਰ ਸਕਦੇ ਹੋ:

• ਉਸੀ ਕਾਰਵਾਈਆਂ ਦਾ ਸਭ ਤੋਂ ਛੋਟਾ ਸੈੱਟ ਜੋ ਮੁੱਦੇ ਨੂੰ ਟਿੱਪਦਾ ਹੈ
• ਠੀਕ ਟੈਸਟ ਡੇਟਾ (IDs, email, payload, filters)
• ਵਾਤਾਵਰਣ ਅਤੇ ਵਰਜਨ (build, feature flags, browser/device)
• ਇਹ ਸਾਬਤ ਕਰਨ ਲਈ ਸਬੂਤ ਕਿ ਇਹ ਵਾਕਈ ਹੋਇਆ (timestamp, screenshot, error text, log snippet)
• ਇੱਕ ਸਾਫ਼ ਸਫਲ/ਅਸਫਲ ਨਤੀਜਾ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾ ਸਕਦੇ ਹੋ

"Done" ਦਾ ਮਤਲਬ "ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਮੈਂ ਨੇ ਠੀਕ ਕੀਤਾ" ਨਹੀਂ। Done ਉਹ ਹੈ: ਤੁਹਾਡੇ ਰੀਪ੍ਰੋ steps ਇੱਕ ਛੋਟੀ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਪਾਸ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਜਲਦੀ ਨੇੜਲੇ ਵਰਤਾਰੇ ਦੀ ਰੀਟੈਸਟਿੰਗ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦਾ ਸੀ।

ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਛੇਡਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਥਿਰ ਬੇਸਲਾਈਨ ਸੈੱਟ ਕਰੋ

ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਸਮਾਂ ਖੋਣ ਦਾ ਤਰੀਕਾ ਹੈ ਇੱਕੋ ਸਮੇਂ ਕਈ ਚੀਜ਼ਾਂ ਬਦਲਨਾ। ਆਪਣਾ ਸ਼ੁਰੂਆਤੀ ਨੁਕਤਾ ਫ੍ਰੀਜ਼ ਕਰੋ ਤਾਂ ਜੋ ਹਰ ਟੈਸਟ ਨਤੀਜਾ ਕਿਸੇ ਮਤਲਬ ਰੱਖੇ।

ਇੱਕ ਵਾਤਾਵਰਣ ਚੁਣੋ ਅਤੇ ਉਸੇ 'ਤੇ ਟਿਕੇ ਰਹੋ ਜਦ ਤਕ ਤੁਸੀਂ ਮੁੱਦੇ ਨੂੰ ਦੁਹਰਾ ਨਹੀਂ ਸਕਦੇ। ਜੇ ਰਿਪੋਰਟ ਪ੍ਰੋਡਕਸ਼ਨ ਤੋਂ ਆਈ ਸੀ ਤਾਂ ਪਹਿਲਾਂ ਉੱਥੇ ਪੁਸ਼ਟੀ ਕਰੋ। ਜੇ ਇਹ ਖਤਰਨਾਕ ਹੈ ਤਾਂ staging ਵਰਤੋ। ਲੋਕਲ ਠੀਕ ਹੈ ਜੇ ਤੁਸੀਂ ਡੇਟਾ ਅਤੇ ਸੈਟਿੰਗਜ਼ ਨੂੰ ਨਜ਼ਦੀਕੀ ਤੌਰ 'ਤੇ ਮੇਲ ਕਰ ਸਕਦੇ ਹੋ।

ਫਿਰ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਕੋਡ ਚੱਲ ਰਿਹਾ ਹੈ: ਵਰਜਨ, build date, ਅਤੇ ਕੋਈ ਵੀ feature flags ਜਾਂ config ਜੋ ਫਲੋ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ। ਛੋਟੀਆਂ ਭਿੰਨਤਾਵਾਂ (ਵਿਚਕਾਰ integrations ਬੰਦ ਹੋਣਾ, ਵੱਖਰਾ API base URL, ਗਾਇਬ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ) ਇੱਕ ਅਸਲ ਬੱਗ ਨੂੰ ਭੂਤ ਵਿੱਚ ਬਦਲ ਸਕਦੀਆਂ ਹਨ।

ਇੱਕ ਸਾਫ਼, ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਟੈਸਟ ਸੈਟਅਪ ਬਣਾਓ। ਤਾਜ਼ਾ ਖਾਤਾ ਅਤੇ ਜਾਣਿਆ ਹੋਇਆ ਡੇਟਾ ਵਰਤੋਂ। ਜੇ ਮुमਕਿਨ ਹੋਵੇ, ਹਰ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਪਹਿਲਾਂ ਸਥਿਤੀ ਰੀਸੈਟ ਕਰੋ (ਲੌਗ ਆਊਟ, ਕੈਸ਼ ਸਾਫ਼ ਕਰੋ, ਇੱਕੋ ਰਿਕਾਰਡ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ)।

ਆਪਣੇ ਧਾਰਣਾਂ ਨੂੰ ਲਿਖੋ ਜਦੋਂ ਤੁਸੀਂ ਜਾਂਦੇ ਹੋ। ਇਹ ਫੁਜ਼ੀ ਕੰਮ ਨਹੀਂ; ਇਹ ਬਾਅਦ ਵਿੱਚ ਆਪਣੇ ਆਪ ਨਾਲ ਜ਼ਹਨੀ ਟਕਰਾਅ ਤੋਂ ਰੋਕਦਾ ਹੈ।

ਇੱਕ ਬੇਸਲਾਈਨ ਨੋਟ ਟੈਮਪਲੇਟ:

• Environment: prod, staging, ਜਾਂ local
• Version/build: commit, tag, ਜਾਂ build timestamp
• Config: feature flags, integrations, test keys
• Test identity: account email/role, permissions
• Data: record IDs, seeded items, expected starting state

ਜੇ ਰੀਪ੍ਰੋ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਇਹ ਨੋਟਸ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਅਗਲੇ ਕਦਮ ਵਿੱਚ ਤੁਸੀਂ ਕਿਸ ਨੂੰ ਬਦਲੋ, ਇੱਕ-ਇੱਕ 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."

ਅਗਲਾ, ਉਹ ਹਾਲਤਾਂ ਕੈਪਚਰ ਕਰੋ ਜੋ ਰਿਪੋਰਟ ਨੂੰ ਸਚ ਬਨਾਉਂਦੀਆਂ ਹਨ। ਬੱਗ ਅਕਸਰ ਇੱਕ ਘੱਟ-ਡਿੱਟੇਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ: ਰੋਲ, ਰਿਕਾਰਡ ਸਟੇਟ, ਲੋਕੇਲ ਜਾਂ ਵਾਤਾਵਰਣ।

ਰਿਮਜ਼ ਵਰਣਨ ਕਰਨ ਲਈ ਮੁੱਖ ਇਨਪੁੱਟਾਂ:

• ਯੂਜ਼ਰ ਰੋਲ ਅਤੇ ਅਕਾਊਂਟ ਕਿਸਮ (admin vs standard, trial vs paid)
• ਡੇਟਾ ਸਟੇਟ (record ID, status, ਲੋੜੀਂਦੇ ਸੰਬੰਧਿਤ ਡੇਟਾ)
• ਕਲਾਇਐਂਟ ਵੇਰਵੇ (OS, browser/app ਵਰਜ਼ਨ)
• ਲੋਕੇਲ ਅਤੇ ਸਮਾਂ ਸੈਟਿੰਗ (ਭਾਸ਼ਾ, ਟਾਈਮਜ਼ੋਨ, ਤਾਰੀਖ ਰੇਂਜ)
• ਵਾਤਾਵਰਣ ਅਤੇ build (prod vs staging, release version, feature flags)

ਉਹ ਬਿਹੀਵਿਯਰ ਕੈਪਚਰ ਕਰੋ ਜਦ ਤਕ ਤੁਹਾਡੇ ਕੋਲ ਅਸਲ ਵਰਤਾਰਾ ਹੈ। ਸਕ੍ਰੀਨਸ਼ਾਟਸ ਮਦਦਗਾਰ ਹਨ, ਪਰ ਇੱਕ ਛੋਟਾ ਰਿਕਾਰਡਿੰਗ ਬਿਹਤਰ ਹੈ ਕਿਉਂਕਿ ਇਸ ਵਿੱਚ ਟਾਇਮਿੰਗ ਅਤੇ ਸਹੀ ਕਲਿਕਸ ਆ ਜਾਂਦੇ ਹਨ। ਹਮੇਸ਼ਾ ਇੱਕ timestamp ਨੋਟ ਕਰੋ (ਟਾਈਮਜ਼ੋਨ ਸਮੇਤ) ਤਾਂ ਜੋ ਤੁਸੀਂ ਲੌਗਸ ਨਾਲ ਮੇਲ ਕਰ ਸਕੋ।

ਤੀਨ ਸਾਫ਼ ਕਰਨ ਵਾਲੇ ਸਵਾਲ ਜੋ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਅਨੁਮਾਨ ਘਟਾਉਂਦੇ ਹਨ:

• ਇਹ ਕਿਹੜੇ ਖ਼ਾਸ ਯੂਜ਼ਰ ਅਕਾਊਂਟ ਅਤੇ ਰੋਲ 'ਤੇ ਹੋਇਆ, ਅਤੇ ਤੁਸੀਂ ਇਕ ਉਦਾਹਰਨ ਰਿਕਾਰਡ ID ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹੋ?
• ਕਾਰਵਾਈ ਦੇ ਬਾਦ ਤੁਸੀਂ ਤੁਰੰਤ ਕੀ ਦੇਖਣ ਦੀ ਉਮੀਦ ਕੀਤੀ ਸੀ, ਅਤੇ ਅਸਲ ਵਿੱਚ ਕੀ ਦੇਖਿਆ?
• ਕੀ ਇਹ ਹਰ ਵਾਰੀ ਹੀ ਹੁੰਦਾ ਹੈ ਉਹੀ ਕਦਮਾਂ ਨਾਲ, ਜਾਂ ਕੇਵਲ ਖਾਸ ਡੇਟਾ (status, date range, locale, large inputs) ਨਾਲ?

ਮੁੱਦੇ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਦੁਹਰਾਓ

ਕਾਰਨ ਦੇ ਅਨੁਮਾਨ ਨਾਲ ਸ਼ੁਰੂ ਨਾ ਕਰੋ। ਸਮੱਸਿਆ ਨੂੰ ਇਰਾਦੇ ਨਾਲ, ਇੱਕੋ ਹੀ ਢੰਗ ਨਾਲ ਅਤੇ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰੀ ਬਣਾਉ।

ਪਹਿਲਾਂ, ਰਿਪੋਰਟਰ ਦੇ ਕਦਮਾਂ ਨੂੰ ਠੀਕ ਠੀਕ ਦੌਰਾਉ। ਉਨ੍ਹਾਂ ਨੂੰ "ਸੁਧਾਰ" ਨਾ ਕਰੋ। ਜੋ ਪਹਿਲਾ ਥਾਂ ਤੁਹਾਡਾ ਅਨੁਭਵ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ, ਉਸਨੂੰ ਨੋਟ ਕਰੋ, ਭਾਵੇਂ ਉਹ ਛੋਟਾ ਲੱਗੇ (ਵੱਖਰਾ ਬਟਨ ਲੇਬਲ, ਮਿਸਿੰਗ ਫੀਲਡ, ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਐਰਰ ਟੈਕਸਟ)। ਉਹ ਪਹਿਲਾ ਅਨਮੈਚ ਅਕਸਰ ਇਸ਼ਾਰਾ ਹੁੰਦਾ ਹੈ।

ਆਮ ਐਪਾਂ ਵਿੱਚ ਕੰਮ ਕਰਨ वाला ਇੱਕ ਸਧਾਰਨ ਵਰਕਫਲੋ:

• ਜਾਣਿਆ ਹੋਇਆ ਪ੍ਰਾਰੰਭਿਕ ਸਟੇਟ ਤੇ ਰੀਸੈਟ ਕਰੋ (ਤਾਜ਼ਾ ਲੋਡ, ਇੱਕੋ ਖਾਤਾ, ਇੱਕੋ permissions, ਇੱਕੋ flags)
• ਕਦਮ-ਦਰ-কਦਮ ਫਾਲੋ ਕਰੋ ਅਤੇ ਵਰਤੇ ਗਏ ਸਹੀ ਇਨਪੁੱਟ (IDs, dates, filters) ਦਰਜ ਕਰੋ
• ਉਸ ਕਦਮ ਤੇ ਉਮੀਦ-ਵਿਰੁੱਧ ਅਸਲ ਨੋਟ ਕਰੋ ਜਿੱਥੇ ਇਹ ਟੁਟਦੀ ਹੈ
• ਇੱਕ ਵਾਰੀ ਫੇਰ ਦੁਹਰਾਓ ਤਾਂ ਕਿ ਇਹ ਦੁਹਰਾਏ ਯੋਗ ਹੋਵੇ
• ਉਸੇ ਤਰ੍ਹਾਂ ਛੋਟਾ ਕਰੋ ਜੋ ਹੁਣ ਵੀ ਮੁੱਦਾ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ

ਜਦੋਂ ਇਹ ਦੁਹਰਾਏ ਯੋਗ ਹੋ ਜਾਵੇ, ਇੱਕ-ਇੱਕ ਚੀਜ਼ ਵੱਖ-ਵੱਖ ਬਦਲੋ। ਇਕ-ਵੈਰੀਏਬਲ ਟੈਸਟਾਂ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਨਤੀਜਾ ਦਿੰਦੀਆਂ ਹਨ:

• ਉਹੀ ਕਦਮ, ਵੱਖਰਾ ਰੋਲ
• ਉਹੀ ਕਦਮ, ਵੱਖਰਾ ਰਿਕਾਰਡ (ਨਵਾਂ vs ਲੇਗੇਸੀ)
• ਉਹੀ ਕਦਮ, ਵੱਖਰਾ browser/device
• ਉਹੀ ਕਦਮ, ਸਾਫ ਸੈਸ਼ਨ (incognito, cache cleared)
• ਉਹੀ ਕਦਮ, ਵੱਖਰਾ ਨੈੱਟਵਰਕ

ਅੰਤ 'ਤੇ ਇੱਕ ਛੋਟੀ repro ਸਕ੍ਰਿਪਟ ਛੱਡੋ ਜੋ ਕੋਈ ਹੋਰ 2 ਮਿੰਟ ਵਿੱਚ ਚਲਾ ਸਕੇ: ਪ੍ਰਾਰੰਭਿਕ ਸਥਿਤੀ, ਕਦਮ, ਇਨਪੁੱਟ, ਅਤੇ ਪਹਿਲੀ failing ਪਰਖਾਂ।

ਫੇਲ ਹੋ ਰਹੇ ਲੇਅਰ ਨੂੰ ਵੱਖਰਾ ਕਰੋ: UI, API, ਜਾਂ DB

ਪੂਰੇ ਕੋਡਬੇਸ ਨੂੰ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਿਹੜਾ ਲੇਅਰ ਫੇਲ ਕਰ ਰਿਹਾ ਹੈ।

ਸਵਾਲ ਪੁੱਛੋ: ਕੀ ਲੱਛਣ ਸਿਰਫ UI ਵਿੱਚ ਹੈ, ਜਾਂ ਡੇਟਾ ਅਤੇ API ਜਵਾਬਾਂ ਵਿੱਚ ਵੀ ਹੈ?

ਉਦਾਹਰਨ: "ਮੇਰਾ ਪ੍ਰੋਫਾਈਲ ਨਾਂ ਅਪਡੇਟ ਨਹੀਂ ਹੋਇਆ." ਜੇ API ਨਵਾਂ ਨਾਂ ਵਾਪਸ ਕਰਦਾ ਹੈ ਪਰ UI ਪੁਰਾਣਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ UI state/caching ਤੇ ਸੰਦਰਭ ਸ਼ੱਕ ਕਰੋ। ਜੇ API ਕਦੇ ਵੀ ਸੇਵ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਮੁਕਾਬਲਾ API ਜਾਂ DB ਖੇਤਰ ਹੈ।

ਤੁਰੰਤ ਟ੍ਰਿਆਜ ਲਈ ਸਵਾਲ ਜੋ ਤੁਸੀਂ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹੋ:

• ਕੀ ਤੁਸੀਂ ਇਹ ਵੱਖ-ਵੱਖ browser/device 'ਤੇ ਦੁਹਰਾ ਸਕਦੇ ਹੋ?
• ਕੀ ਇੱਕ ਹਾਰਡ ਰੀਫ੍ਰੈਸ਼ ਨਾਲ ਕੁਝ ਬਦਲਦਾ ਹੈ?
• ਕੀ ਬਟਨ ਕਲਿਕ ਕਰਨ 'ਤੇ ਕੋਈ ਨੈੱਟਵਰਕ ਰਿਕਵੈਸਟ ਫਾਇਰ ਹੋ ਰਹੀ ਹੈ?
• ਕੀ API ਰਿਸਪਾਂਸ ਪਹਿਲਾਂ ਹੀ ਗਲਤ ਦਿੱਸਦਾ ਹੈ?
• ਕੀ ਡੇਟਾਬੇਸ ਕਾਰਵਾਈ ਤੋਂ ਬਾਅਦ ਉਮੀਦ ਮੁਤਾਬਕ ਰੋਅ ਦਿਖਾਉਂਦਾ ਹੈ?

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) ਨੂੰ ਪੜ੍ਹਦਾ ਜਾਂ ਲਿਖਦਾ ਹੈ।

ਲੌਗਸ ਅਤੇ ਟਾਈਮਸਟੈਂਪ ਨਾਲ ਬੇਨਤੀ ਨੂੰ ਅੰਤ ਤੋਂ ਅੰਤ ਤੱਕ ਫਾਲੋ ਕਰੋ

ਸਪਸ਼ਟਤਾ ਅਕਸਰ ਇੱਕ ਅਸਲੀ ਬੇਨਤੀ ਨੂੰ ਕਲਿਕ ਤੋਂ ਡੇਟਾਬੇਸ ਤੱਕ ਅਤੇ ਵਾਪਸ ਫਾਲੋ ਕਰਨ ਤੋਂ ਆਉਂਦੀ ਹੈ।

ਰਿਪੋਰਟ ਜਾਂ ਤੁਹਾਡੇ ਰੀਪ੍ਰੋ ਤੋਂ ਤਿੰਨ ਐਂਕਰ ਲੋ:

• ਠੀਕ ਸਮਾਂ (ਟਾਈਮਜ਼ੋਨ ਨਾਲ)
• ਯੂਜ਼ਰ ਪਛਾਣ (account/email/internal ID)
• correlation ID (request ID/trace ID/session ID)

ਜੇ ਤੁਹਾਡੇ ਕੋਲ correlation ID ਨਹੀਂ ਹੈ, ਤਾਂ ਆਪਣੇ gateway/backend ਵਿੱਚ ਇੱਕ ਜੋੜੋ ਅਤੇ ਇਸਨੂੰ response headers ਅਤੇ logs ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰੋ।

ਸ਼ੋਰ-ਸ਼ਰਾਬੇ ਵਿੱਚ ਡੁੱਬਣ ਤੋਂ ਬਚਣ ਲਈ, ਸਿਰਫ ਉਹੀ ਕੈਪਚਰ ਕਰੋ ਜੋ ਸਵਾਲ "ਕਿੱਥੇ ਫੇਲ ਹੋਇਆ ਅਤੇ ਕਿਉਂ?" ਦਾ ਜਵਾਬ ਦੇਵੇ:

• timestamp ਰੇਂਜ (ਉਦਾਹਰਣ ਲਈ, ਘੰਟੇ ਤੋਂ 1 ਮਿੰਟ ਪਹਿਲਾਂ ਤੋਂ 1 ਮਿੰਟ ਬਾਅਦ)
• ਇੱਕ ਯੂਜ਼ਰ ID (ਅਤੇ tenant/org ID ਜੇ ਲਾਗੂ ਹੋਵੇ)
• correlation ID
• method, path, status code, latency
• ਪਹਿਲਾ ਮਾਇਨੇ ਵਾਲਾ error message (ਲੰਮੇ stack traces ਨਹੀੰ)

ਨਿਸ਼ਾਨੀਅਾਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ:

• Timeouts/ਲੰਬਾ latency: slow queries, external calls, locks
• 401/403: permission ਜਾਂ tenant context ਸਮੱਸਿਆਵਾਂ
• 400 validation errors: ਅਕਸਰ UI payload mismatch

ਜੇ "ਕੱਲ੍ਹ ਚੱਲ ਰਹਿਆ ਸੀ" ਪਰ ਅੱਜ ਨਹੀਂ, ਤਾਂ ਵਾਤਾਵਰਣ drift 'ਤੇ ਸ਼ੱਕ ਕਰੋ: ਫਲੈਗਸ ਬਦਲੇ, secrets ਰੋਟੇਟ ਹੋਏ, missing migrations, ਜਾਂ ਰੁਕੇ ਹੋਏ jobs।

ਘੱਟੋ-ਘੱਟ reproducible ਕੇਸ ਬਣਾਓ (ਤਾਂ ਜੋ ਫਿਕਸ ਛੋਟੇ ਰਹਿਣ)

ਸਭ ਤੋਂ ਆਸਾਨ ਬੱਗ ਠੀਕ ਕਰਨ ਯੋਗ ਏਕ ਛੋਟਾ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਪਰਖ ਹੁੰਦਾ ਹੈ।

ਹਰ ਚੀਜ਼ ਨੂੰ ਘਟਾਓ: ਘੱਟ ਕਲਿੱਕ, ਘੱਟ ਫੀਲਡ, ਸਭ ਤੋਂ ਛੋਟੀ ਡੇਟਾਸੈਟ ਜੋ ਫੇਲ ਹੋਣੀ ਨਵੀ ਹੈ। ਜੇ ਇਹ ਕੇਵਲ "ਕਈ ਰਿਕਾਰਡ ਵਾਲੇ customers" ਨਾਲ ਹੀ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਘੱਟੋ-ਘੱਟ ਕੇਸ ਬਣਾਉ ਜੋ ਫਿਰ ਵੀ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਬਣਾਉ ਸਕਦੇ, ਤਾਂ ਇਹ ਸੰਕੇਤ ਹੈ ਕਿ ਬੱਗ ਡੇਟਾ-ਪਰਿਮਾਣ ਜਾਂ ਵਾਲੀਅਮ-ਸਬੰਧੀ ਹੋ ਸਕਦੀ ਹੈ।

"ਬੁਰਾ ਸਟੇਟ" ਨੂੰ "ਬੁਰਾ ਕੋਡ" ਤੋਂ ਵੱਖਰਾ ਕਰਨ ਲਈ ਸੂਬਾ ਸੂਚਿਤ ਰੀਸੈਟ ਕਰੋ: ਸਾਫ ਖਾਤਾ, ਤਾਜ਼ਾ ਟੇਨੈਂਟ ਜਾਂ ਡੇਟਾਸੈਟ, ਜਾਣਿਆ ਹੋਇਆ build।

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕ ਇੱਕ ਕੰਪੈਕਟ ਇਨਪੁੱਟ ਟੇਬਲ ਰੱਖਣਾ ਹੈ:

ਰੀਪ੍ਰੋ ਨੂੰ ਪੋਰਟੇਬਲ ਬਣਾਓ ਤਾਂ ਜੋ ਕੋਈ ਹੋਰ ਤੇਜ਼ੀ ਨਾਲ ਚਲਾ ਸਕੇ:

• ਸਾਫ਼ ਸ਼ੁਰੂ ਤੋਂ 3 ਤੋਂ 6 ਕਦਮ
• ਇੱਕ ਟੈਸਟ ਰਿਕਾਰਡ (ਜਾਂ ਇੱਕ ਰਿਕਵੇਸਟ ਬਾਡੀ) ਜੋ ਤੁਸੀਂ ਦੁਹਰਾ ਸਕੋ
• ਇੱਕ ਸਾਫ਼ ਸਫਲਤਾ ਸੰਕੇਤ (UI message, HTTP ਕੋਡ, DB row count)
• ਠੀਕ ਵਾਤਾਵਰਣ ਵੇਰਵੇ (build/version, role, flags)

ਸਮਾਨ ਤਰ੍ਹਾਂ ਫਸਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਜੋ ਸਮਾਂ ਨਾਸ਼ ਕਰਦੀਆਂ ਹਨ

ਸਭ ਤੋਂ ਤੇਜ਼ ਰਾਹ ਆਮ ਤੌਰ 'ਤੇ ਸਾਧਾਰਣ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਚੀਜ਼ ਬਦਲੋ, ਦੇਖੋ, ਨੋਟਸ ਰੱਖੋ।

ਆਮ ਗਲਤੀਆਂ:

• ਸਤਹੀ ਲੱਛਣ ਨੂੰ ਠੀਕ ਕਰਨਾ (ਅਸਲ API/DB ਐਰਰ ਨੂੰ ਛਪਾਉਣਾ)
• ਇਕੋ ਵਾਰ ਕਈ ਵੇਰੀਏਬਲ ਬਦਲਣਾ (dependency updates + config tweaks + refactor)
• ਰਿਪੋਰਟਰ ਦੀ ਥਾਂ ਤੋਂ ਵੱਖਰੀ ਬੇਸਲਾਈਨ 'ਤੇ ਟੈਸਟ ਕਰਨਾ (env, data, build, browser)
• permissions ਅਤੇ roles ਨੂੰ ਭੁੱਲਣਾ (admin vs regular user)
• feature flags ਜਾਂ experiments ਗੁਆਚ ਜਿਨ੍ਹਾਂ ਨਾਲ ਫਲੋ ਬਦਲਦਾ ਹੈ
• verification ਬਿਨਾਂ ਜਿੱਤ ਦਾ ਐਲਾਨ ਕਰਨਾ (ਰੀਪ੍ਰੋ ਦਾ ਦੁਹਰਾਅ ਨਹੀਂ ਕਰਨਾ, ਕੋਈ side-effect ਚੈਕ ਨਹੀਂ)

ਇੱਕ ਯਥਾਰਥ ਉਦਾਹਰਨ: ਇੱਕ ਟਿਕਟ ਵਿੱਚ ਕਿਹਾ ਗਿਆ "Export CSV ਖਾਲੀ ਆ ਰਿਹਾ ਹੈ." ਤੁਸੀਂ admin ਖਾਤੇ ਨਾਲ ਟੈਸਟ ਕਰਦੇ ਹੋ ਅਤੇ ਡੇਟਾ ਵੇਖਦੇ ਹੋ। ਯੂਜ਼ਰ ਦਾ ਰੋਲ restricted ਹੈ ਅਤੇ API permission filter ਕਾਰਨ ਖਾਲੀ ਲਿਸਟ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ UI ਨੂੰ ਕੇਵਲ "No rows" ਦਿਖਾਉਣ ਲਈ ਪੈਚ ਕਰ ਦਿਤਾ ਤਾਂ ਤੁਸੀਂ ਅਸਲ ਸਵਾਲ ਗੁਆ ਬੈਠੋ: ਕੀ ਉਸ ਰੋਲ ਨੂੰ export ਦੀ ਆਗਿਆ ਹੋਣੀ ਚਾਹੀਦੀ ਸੀ, ਜਾਂ product ਨੂੰ ਜਾਣਕਾਰੀ ਦੇਣੀ ਚਾਹੀਦੀ ਕਿ ਫਿਲਟਰ ਕਰਕੇ ਕੋਈ ਪਤਿਆਂ ਨਹੀਂ ਮਿਲੇ?

ਕਿਸੇ ਵੀ ਫਿਕਸ ਤੋਂ ਬਾਅਦ, ਉਹੇ ਰੀਪ੍ਰੋ ਕਦਮ ਦੁਹਰਾਓ ਜੋ ਮੂਲ ਤੌਰ 'ਤੇ ਦਿੱਤੇ ਗਏ ਸਨ, ਫਿਰ ਇੱਕ ਨੇੜਲਾ ਸੈਨੇਰਿਓ ਟੈਸਟ ਕਰੋ ਜੋ ਹੁਣ ਵੀ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਫਿਕਸ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ

ਜੇ ਤੁਸੀਂ ਇਕ ਸੰਗੀਨ ਪੈਕੇਜ ਨਾਲ ਆਓਗੇ ਤਾਂ ਟੀਮਮੈਟ (ਜਾਂ ਟੂਲ) ਵਲੋਂ ਵਧੀਆ ਜਵਾਬ ਮਿਲਣਗੇ: ਦੋਹਰਾਏ ਜਾਣ ਯੋਗ ਕਦਮ, ਇੱਕ ਸੰਭਾਵਿਤ ਫੇਲ ਲੇਅਰ, ਅਤੇ ਸਬੂਤ।

ਕੋਡ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪੱਕਾ ਕਰੋ:

• ਤੁਸੀਂ ਇਹੇ ਇਨਪੁੱਟਾਂ ਨਾਲ ਦੋ ਵਾਰੀ ਰੀਪ੍ਰੋ ਕਰ ਸਕਦੇ ਹੋ (ਉਹੀ ਯੂਜ਼ਰ, ਉਹੀ ਡੇਟਾ, ਉਹੀ ਵਾਤਾਵਰਣ)
• ਤੁਸੀਂ ਫੇਲ ਹੋ रेਹ ਲੇਅਰ (UI, API, ਜਾਂ DB) ਨਾਂਮ ਦੇ ਸਕਦੇ ਹੋ ਅਤੇ ਇੱਕ ਕਾਰਨ ਦੱਸ ਸਕਦੇ ਹੋ
• ਤੁਸੀਂ ਸਬੂਤ ਕੈਪਚਰ ਕੀਤਾ: request, response/error, ਸਮੰਬੰਧਤ ਲੌਗ, ਅਤੇ ਮਿਲਦਾ-ਜੁਲਦਾ timestamp
• ਤੁਸੀਂ repro ਨੂੰ ਸਭ ਤੋਂ ਛੋਟੇ ਕੇਸ ਤੱਕ ਘਟਾ ਦਿੱਤਾ
• ਤੁਸੀਂ ਇਕ-ਵਾਕ ਵਿੱਚ acceptance criteria ਲਿਖੀ (ਉਦਾਹਰਨ: "Saving updates the record and shows success within 2 seconds")

ਫਿਰ ਇੱਕ ਛੋਟਾ regression pass ਕਰੋ: ਵੱਖਰਾ ਰੋਲ, ਦੂਜਾ browser/private window, ਇੱਕ ਨੇੜਲਾ ਫੀਚਰ ਜੋ ਉਹੀ endpoint/table ਵਰਤਦਾ ਹੈ, ਅਤੇ ਇੱਕ edge-case ਇਨਪੁੱਟ (ਖਾਲੀ, ਲੰਬਾ ਟੈਕਸਟ, ਵਿਸ਼ੇਸ਼ ਅੱਖਰ)।

ਇੱਕ ਯਥਾਰਥ ਉਦਾਹਰਨ: "Save button does nothing" ਬੱਗ ਨੂੰ Narrow ਕਰਨਾ

ਸਪੋਰਟ ਸੁਨੇਹੇ ਵਿੱਚ ਕਿਹਾ ਗਿਆ: "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 ਜੋ ਤੁਸੀਂ ਹਸਤਾਂਤਰਿਤ ਕਰ ਸਕਦੇ ਹੋ:

• ਇਕ legacy customer ਚੁਣੋ ਜਿਸਦਾ billing_email = [email protected] ਹੈ
• ਕੋਈ ਵੀ ਫੀਲਡ ਬਦਲੋ ਅਤੇ Save 'ਤੇ ਕਲਿਕ ਕਰੋ
• API 400 ਵਾਪਸ ਕਰਦਾ ਹੈ billingEmail must be unique
• UI ਕੋਈ error ਨਹੀਂ ਦਿਖਾਉਂਦਾ ਅਤੇ ਫਾਰਮ ਬਦਲਿਆ ਹੋਇਆ ਰੱਖਦਾ ਹੈ

Acceptance test: ਜਦੋਂ API validation error ਵਾਪਸ ਕਰੇ, UI ਸੁਨੇਹਾ ਦਿਖਾਏ, ਯੂਜ਼ਰ ਦੀਆਂ ਸੋਧਾਂ ਨੂੰ ਰੱਖੇ, ਅਤੇ error ਉਸ ਖਾਸ ਫੀਲਡ ਦਾ ਨਾਂ ਦੱਸੇ ਜੋ ਫੇਲ ਹੋਈ।

ਅਗਲੇ ਕਦਮ: ਇਕ ਛੋਟਾ ਫਿਕਸ ਮੰਗੋ ਜੋ ਤੁਸੀਂ ਟੈਸਟ ਕਰ ਸਕੋ

ਜਦੋਂ ਬੱਗ reproducible ਹੋਵੇ ਅਤੇ ਤੁਸੀਂ ਸੰਭਾਵਿਤ ਲੇਅਰ ਪਛਾਣ ਲਈ ਹੋ, ਮਦਦ ਮੰਗੋ ਇਸ ਤਰੀਕੇ ਨਾਲ ਕਿ ਛੋਟਾ, ਸੁਰੱਖਿਅਤ ਪੈਚ ਮਿਲੇ।

ਇੱਕ ਸਧਾਰਨ "case file" ਪੈਕੇਜ ਕਰੋ: ਘੱਟੋ-ਘੱਟ repro steps (ਇਨਪੁੱਟ, ਵਾਤਾਵਰਣ, ਰੋਲ), ਉਮੀਦ ਵਿਰੁੱਧ ਅਸਲ, ਤੁਸੀਂ ਕਿਉਂ ਸਮਝਦੇ ਹੋ ਕਿ ਇਹ UI/API/DB ਹੈ, ਅਤੇ ਸਬ ਤੋਂ ਛੋਟਾ ਲੌਗ excerpt ਜੋ ਫੇਲ ਦਰਸਾਉਂਦਾ ਹੈ।

ਫਿਰ ਬੇਨਤੀ ਨਰਾਰੋ ਕਰੋ:

• ਸਭ ਤੋਂ ਛੋਟਾ ਕੋਡ ਬਦਲਾਅ ਪ੍ਰਭਾਵਿਤ repro ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰੋ
• ਜੇ ਲੋੜ ਨਾ ਹੋਵੇ ਤਾਂ refactors ਤੋਂ ਬਚੋ
• ਕਾਰਨ ਸਧੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਸਮਝਾਓ
• ਇਕ ਛੋਟਾ ਟੈਸਟ ਪਲਾਨ ਸ਼ਾਮਿਲ ਕਰੋ (ਕਿਵੇਂ ਫਿਕਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨੀ ਹੈ, ਅਤੇ ਕੀ ਨੇੜਲੇ ਹਿੱਸੇ ਟੁੱਟ ਸਕਦੇ ਹਨ)

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਇਹ case-file ਪਹੁੰਚ ਸੁਝਾਅਾਂ ਨੂੰ ਕੇਂਦਰਿਤ ਰੱਖਦੀ ਹੈ। ਇਸਦੇ snapshots ਅਤੇ rollback ਤੁਹਾਨੂੰ ਛੋਟੇ ਬਦਲਾਅ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਟੈਸਟ ਕਰਨ ਅਤੇ ਜਾਣੇ-ਪਛਾਣ ਵਾਲੀ ਸਥਿਤੀ 'ਤੇ ਵਾਪਸ ਜਾਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ।

ਜਦੋਂ ਫਿਕਸ security, payments, data migrations ਜਾਂ ਅਜਿਹੀਆਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਛੂਹਦਾ ਹੋਵੇ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦੀ ਹੈ, ਤਾਂ ਇਹ ਕੰਮ ਕਿਸੇ ਤਜਰਬੇਕਾਰ developer ਨੂੰ ਹਵਾਲਾ ਕਰੋ। ਉਹ ਵੀ ਹਵਾਲਾ ਕਰੋ ਜੇ ਬਦਲਾਅ ਇੱਕ ਛੋਟੀ ਪੈਚ ਤੋਂ ਵੱਧ ਵਿਸਥਾਰ 'ਤੇ ਚਲਾ ਜਾ ਰਿਹਾ ਹੋਵੇ ਜਾਂ ਤੁਸੀਂ ਖ਼ਤਰੇ ਨੂੰ ਸਧੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਸਮਝਾ ਨਹੀਂ ਪਾ ਰਹੇ।