ਐਂਟਰਪ੍ਰਾਈਜ਼ ਚੈੱਕਲਿਸਟ: QA/UAT ਵਿੱਚ ਅਸਥਾਈ ਈਮੇਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ OTP ਜੋਖਮ ਘਟਾਓ
OTP ਪੁਸ਼ਟੀਕਰਨ ਉਸ QA ਪਾਈਪਲਾਈਨ ਦੀ ਸਭ ਤੋਂ ਨਾਜ਼ੁਕ ਕੜੀ ਹੈ ਜੋ ਅਸਥਾਈ ਈਮੇਲ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਇੱਕ ਬਲੌਕ ਕੀਤਾ ਡੋਮੇਨ, ਰੀਸੈਂਡ ਤੂਫ਼ਾਨ ਜਾਂ ਮਿਆਦ ਪੁੱਗਿਆ ਇਨਬਾਕਸ ਸੈਂਕੜਿਆਂ ਝੂਠੀਆਂ ਟੈਸਟ ਅਸਫਲਤਾਵਾਂ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ—ਅਤੇ ਸਫ਼ਾਈ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਕਿਸੇ ਦੀ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਐਂਟਰਪ੍ਰਾਈਜ਼-ਤਿਆਰ ਚੈੱਕਲਿਸਟ QA ਲੀਡਾਂ ਅਤੇ DevOps ਟੀਮਾਂ ਨੂੰ UAT ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ OTP ਜੋਖਮ ਘਟਾਉਣ ਲਈ ਇੱਕ ਢਾਂਚਾਬੱਧ ਪਹੁੰਚ ਦਿੰਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਡੋਮੇਨ ਰੋਟੇਸ਼ਨ ਸਮਾਂ-ਸਾਰਣੀਆਂ, ਰੀਸੈਂਡ ਥ੍ਰੌਟਲ ਨਿਯਮ, TTFOM (time-to-first-OTP-message) ਦੇ p50/p90 ਬੈਂਚਮਾਰਕ, ਇਨਬਾਕਸ ਮਾਲਕੀ ਦੀਆਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਅਤੇ ਸਪ੍ਰਿੰਟ ਦੇ ਵਿਚਕਾਰ ਈਮੇਲ ਡਿਲਿਵਰੀ ਟੁੱਟਣ ’ਤੇ ਅੱਗੇ ਭੇਜਣ ਦੇ ਰਸਤੇ ਸ਼ਾਮਲ ਹਨ।
ਤੇਜ਼ ਪਹੁੰਚ
ਸੰਖੇਪ
- OTP ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਇੱਕ ਮਾਪਣਯੋਗ SLO ਮੰਨੋ, ਜਿਸ ਵਿੱਚ ਸਫਲਤਾ ਦਰ ਅਤੇ TTFOM (p50/p90, p95) ਸ਼ਾਮਲ ਹਨ।
- ਸਾਖ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਨੁਕਸਾਨ ਤੋਂ ਬਚਾਉਣ ਲਈ QA/UAT ਟ੍ਰੈਫਿਕ ਅਤੇ ਡੋਮੇਨਾਂ ਨੂੰ ਉਤਪਾਦਨ ਤੋਂ ਵੱਖ ਰੱਖੋ।
- ਦੁਬਾਰਾ ਭੇਜਣ ਦੀਆਂ ਵਿੰਡੋਜ਼ ਨੂੰ ਮਿਆਰੀ ਬਣਾਓ ਅਤੇ ਰੋਟੇਸ਼ਨਾਂ ਦੀ ਹੱਦ ਨਿਰਧਾਰਤ ਕਰੋ; ਅਨੁਸ਼ਾਸਿਤ ਰੀਟਰੀਜ਼ ਤੋਂ ਬਾਅਦ ਹੀ ਰੋਟੇਸ਼ਨ ਕਰੋ।
- ਟੈਸਟ ਦੀ ਕਿਸਮ ਮੁਤਾਬਕ ਇਨਬਾਕਸ ਰਣਨੀਤੀ ਚੁਣੋ: ਰਿਗ੍ਰੈਸ਼ਨ ਲਈ ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ ਇਨਬਾਕਸ; ਥੋੜ੍ਹੇ ਸਮੇਂ ਵਾਲੇ ਟੈਸਟਾਂ ਲਈ ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ ਇਨਬਾਕਸ।
- ਭੇਜਣ ਵਾਲੇ×ਡੋਮੇਨ ਦੇ ਮੈਟ੍ਰਿਕਸ ਵਿੱਚ ਅਸਫਲਤਾ ਕੋਡ ਦਰਜ ਕਰੋ ਅਤੇ ਤਿਮਾਹੀ ਨਿਯੰਤਰਣ ਸਮੀਖਿਆਵਾਂ ਲਾਜ਼ਮੀ ਬਣਾਓ।
QA/UAT ਵਿੱਚ ਅਸਥਾਈ ਈਮੇਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਉੱਦਮਾਂ ਲਈ OTP ਜੋਖਮ ਘਟਾਉਣ ਦੀ ਚੈੱਕਲਿਸਟ
ਇੱਥੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਹੈ: ਟੈਸਟ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ OTP ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਸਿਰਫ਼ "ਈਮੇਲ ਦੀ ਗੱਲ" ਨਹੀਂ ਹੈ। ਇਹ ਸਮੇਂ-ਸਬੰਧੀ ਆਦਤਾਂ, ਭੇਜਣ ਵਾਲੇ ਦੀ ਸਾਖ, ਗ੍ਰੇਲਿਸਟਿੰਗ, ਡੋਮੇਨ ਦੀ ਚੋਣ ਅਤੇ ਤਣਾਅ ਹੇਠ ਤੁਹਾਡੀਆਂ ਟੀਮਾਂ ਦੇ ਵਿਹਾਰ ਵਿਚਕਾਰ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਹੈ। ਇਹ ਚੈੱਕਲਿਸਟ ਇਸ ਉਲਝਣ ਨੂੰ ਸਾਂਝੀਆਂ ਪਰਿਭਾਸ਼ਾਵਾਂ, ਸੁਰੱਖਿਆ-ਸੀਮਾਵਾਂ ਅਤੇ ਸਬੂਤ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਅਸਥਾਈ ਇਨਬਾਕਸਾਂ ਲਈ ਨਵੇਂ ਹੋ, ਤਾਂ ਸ਼ਰਤਾਂ ਅਤੇ ਬੁਨਿਆਦੀ ਵਿਹਾਰਾਂ ਨਾਲ ਜਾਣੂ ਹੋਣ ਲਈ ਪਹਿਲਾਂ ਟੈਂਪ ਮੇਲ ਦੀਆਂ ਜ਼ਰੂਰੀ ਗੱਲਾਂ ਪੜ੍ਹੋ।
1) QA/UAT ਵਿੱਚ OTP ਜੋਖਮ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ
ਸਾਂਝੀ ਸ਼ਬਦਾਵਲੀ ਨਿਰਧਾਰਤ ਕਰੋ ਤਾਂ ਜੋ QA, ਸੁਰੱਖਿਆ ਅਤੇ ਉਤਪਾਦ ਟੀਮਾਂ OTP ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਬਾਰੇ ਇੱਕੋ ਭਾਸ਼ਾ ਬੋਲਣ।
"OTP ਸਫਲਤਾ ਦਰ" ਦਾ ਕੀ ਅਰਥ ਹੈ
OTP ਸਫਲਤਾ ਦਰ ਉਹਨਾਂ OTP ਬੇਨਤੀਆਂ ਦਾ ਪ੍ਰਤੀਸ਼ਤ ਹੈ ਜਿਨ੍ਹਾਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਨੀਤੀ ਅਨੁਸਾਰ ਨਿਰਧਾਰਤ ਸਮਾਂ-ਸੀਮਾ ਅੰਦਰ ਇੱਕ ਵੈਧ ਕੋਡ ਪ੍ਰਾਪਤ ਕੀਤਾ ਅਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਟੈਸਟ ਪ੍ਰਵਾਹਾਂ ਲਈ ਦਸ ਮਿੰਟ)। ਇਸਨੂੰ ਭੇਜਣ ਵਾਲੇ (ਕੋਡ ਜਾਰੀ ਕਰਨ ਵਾਲੀ ਐਪ/ਸਾਈਟ) ਅਤੇ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਡੋਮੇਨ ਪੂਲ ਮੁਤਾਬਕ ਟਰੈਕ ਕਰੋ। ਘਟਨਾ ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਧੁੰਦਲਾ ਹੋਣ ਤੋਂ ਰੋਕਣ ਲਈ ਉਪਭੋਗਤਾ ਵੱਲੋਂ ਛੱਡੇ ਗਏ ਮਾਮਲਿਆਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਬਾਹਰ ਰੱਖੋ।
ਟੀਮਾਂ ਲਈ ਟੀਟੀਐਫਓਐਮ ਪੀ 50 / ਪੀ 90
ਪਹਿਲੇ OTP ਸੁਨੇਹੇ ਤੱਕ ਦਾ ਸਮਾਂ (TTFOM)—"ਕੋਡ ਭੇਜੋ" ਤੋਂ ਲੈ ਕੇ ਪਹਿਲੇ ਇਨਬਾਕਸ ਵਿੱਚ ਸੁਨੇਹਾ ਪਹੁੰਚਣ ਤੱਕ ਦੇ ਸਕਿੰਟ। p50 ਅਤੇ p90 (ਅਤੇ ਤਣਾਅ ਟੈਸਟਾਂ ਲਈ p95) ਦਾ ਚਾਰਟ ਬਣਾਓ। ਇਹ ਵੰਡ ਕਤਾਰਬੰਦੀ, ਥ੍ਰੋਟਲਿੰਗ ਅਤੇ ਗ੍ਰੇਲਿਸਟਿੰਗ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਇਸ ਲਈ ਕਿੱਸਿਆਂ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਰਹਿਣਾ ਪੈਂਦਾ।
ਝੂਠੇ ਨਕਾਰਾਤਮਕ ਬਨਾਮ ਅਸਲ ਅਸਫਲਤਾਵਾਂ
ਇੱਕ "ਝੂਠਾ ਨਕਾਰਾਤਮਕ" ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੋਡ ਪ੍ਰਾਪਤ ਹੋ ਜਾਂਦਾ ਹੈ, ਪਰ ਟੈਸਟਰ ਦਾ ਪ੍ਰਵਾਹ ਇਸਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ—ਅਕਸਰ ਐਪ ਦੀ ਸਥਿਤੀ, ਟੈਬ ਬਦਲਣ, ਜਾਂ ਮਿਆਦ ਪੁੱਗੇ ਟਾਈਮਰ ਕਾਰਨ। ਇੱਕ "ਅਸਲ ਅਸਫਲਤਾ" ਉਹ ਹੈ ਜਦੋਂ ਸਮਾਂ-ਸੀਮਾ ਅੰਦਰ ਕੋਈ ਸੁਨੇਹਾ ਨਹੀਂ ਪਹੁੰਚਦਾ। ਆਪਣੀ ਵਰਗੀਕਰਨ ਵਿੱਚ ਦੋਵਾਂ ਨੂੰ ਵੱਖ ਰੱਖੋ; ਸਿਰਫ਼ ਅਸਲ ਅਸਫਲਤਾਵਾਂ ਹੀ ਰੋਟੇਸ਼ਨ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਂਦੀਆਂ ਹਨ।
ਜਦੋਂ ਸਟੇਜਿੰਗ ਡਿਲੀਵਰੇਬਿਲਟੀ ਦੇ ਅੰਕੜਿਆਂ ਨੂੰ ਵਿਗਾੜਦੀ ਹੈ
ਸਟੇਜਿੰਗ ਐਂਡਪੁਆਇੰਟ ਅਤੇ ਸਿੰਥੈਟਿਕ ਟ੍ਰੈਫਿਕ ਪੈਟਰਨ ਅਕਸਰ ਗ੍ਰੇਲਿਸਟਿੰਗ ਜਾਂ ਘੱਟ ਤਰਜੀਹ ਮਿਲਣ ਨੂੰ ਚਾਲੂ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ ਬੇਸਲਾਈਨ ਉਤਪਾਦਨ ਨਾਲੋਂ ਮਾੜੀ ਲੱਗਦੀ ਹੈ, ਤਾਂ ਇਹ ਉਮੀਦਯੋਗ ਹੈ: ਗੈਰ-ਮਨੁੱਖੀ ਟ੍ਰੈਫਿਕ ਦੀ ਵੰਡ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ। ਸੰਖੇਪ ਜਾਣ-ਪਛਾਣ ਲਈ, ਇਹ ਵੇਖੋ ਕਿ ਡਿਸਪੋਜ਼ੇਬਲ ਇਨਬਾਕਸ ਪੈਟਰਨ ਟੈਸਟਾਂ ਦੌਰਾਨ ਡਿਲੀਵਰੇਬਿਲਟੀ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ—ਇਸ ਬਾਰੇ ਸੰਖੇਪ 2025 ਵਿੱਚ ਸੰਖੇਪ ਟੈਂਪ ਮੇਲ ਮਾਰਗਦਰਸ਼ਨ ਵੇਖੋ।
2) ਆਮ ਅਸਫਲਤਾ ਦੇ ਢੰਗਾਂ ਦਾ ਮਾਡਲ ਬਣਾਓ
ਸਪੁਰਦਗੀ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਪ੍ਰਭਾਵ ਪਾਉਣ ਵਾਲੀਆਂ ਰੁਕਾਵਟਾਂ ਦੀ ਪਛਾਣ ਕਰੋ, ਤਾਂ ਜੋ ਨੀਤੀਆਂ ਅਤੇ ਟੂਲਿੰਗ ਰਾਹੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਰੋਕਿਆ ਜਾ ਸਕੇ।
ਗ੍ਰੇਲਿਸਟਿੰਗ ਅਤੇ ਭੇਜਣ ਵਾਲੇ ਦੀ ਸਾਖ
ਗ੍ਰੇਲਿਸਟਿੰਗ ਭੇਜਣ ਵਾਲਿਆਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਲਈ ਕਹਿੰਦੀ ਹੈ; ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਦੇਰੀ ਹੋ ਸਕਦੀ ਹੈ। ਨਵੇਂ ਜਾਂ "ਠੰਢੇ" ਭੇਜਣ ਵਾਲੇ ਪੂਲਾਂ ਨੂੰ ਵੀ ਉਦੋਂ ਤੱਕ ਸਮੱਸਿਆ ਆ ਸਕਦੀ ਹੈ, ਜਦੋਂ ਤੱਕ ਉਨ੍ਹਾਂ ਦੀ ਸਾਖ ਨਹੀਂ ਬਣ ਜਾਂਦੀ। ਨਵੇਂ ਬਿਲਡ ਦੀ ਨੋਟੀਫਿਕੇਸ਼ਨ ਸੇਵਾ ਦੇ ਪਹਿਲੇ ਘੰਟਿਆਂ ਦੌਰਾਨ p90 ਵਿੱਚ ਉਛਾਲਾਂ ਦੀ ਉਮੀਦ ਰੱਖੋ।
ISP ਸਪੈਮ ਫਿਲਟਰ ਅਤੇ ਠੰਢੇ ਪੂਲ
ਕੁਝ ਪ੍ਰਦਾਤਾ ਠੰਢੇ IP ਜਾਂ ਡੋਮੇਨਾਂ ਦੀ ਵਧੇਰੇ ਸਖ਼ਤੀ ਨਾਲ ਜਾਂਚ ਕਰਦੇ ਹਨ। ਨਵੇਂ ਪੂਲ ਤੋਂ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ OTP ਭੇਜਣ ਵਾਲੇ QA ਰਨ ਮੁਹਿੰਮਾਂ ਵਰਗੇ ਲੱਗ ਸਕਦੇ ਹਨ ਅਤੇ ਗੈਰ-ਜ਼ਰੂਰੀ ਸੁਨੇਹਿਆਂ ਨੂੰ ਧੀਮਾ ਕਰ ਸਕਦੇ ਹਨ। ਵਾਰਮ-ਅੱਪ ਕ੍ਰਮ (ਘੱਟ ਅਤੇ ਨਿਯਮਤ ਮਾਤਰਾ) ਇਸ ਪ੍ਰਭਾਵ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।
ਦਰ-ਸੀਮਾਵਾਂ ਅਤੇ ਵੱਧ ਭੀੜ
ਮੁੜ ਭੇਜਣ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦਾ ਅਚਾਨਕ ਵਾਧਾ ਦਰ-ਸੀਮਾਵਾਂ ਨੂੰ ਸਰਗਰਮ ਕਰ ਸਕਦਾ ਹੈ। ਵੱਧ ਲੋਡ ਹੇਠ (ਜਿਵੇਂ ਵਿਕਰੀ ਸਮਾਗਮਾਂ ਜਾਂ ਗੇਮਿੰਗ ਲਾਂਚਾਂ ਦੌਰਾਨ), ਭੇਜਣ ਵਾਲੀਆਂ ਕਤਾਰਾਂ ਲੰਬੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ TTFOM p90 ਵਧ ਜਾਂਦਾ ਹੈ। ਤੁਹਾਡੀ ਚੈੱਕਲਿਸਟ ਵਿੱਚ ਆਪਣੇ ਹੱਥੀਂ ਪੈਦਾ ਕੀਤੀਆਂ ਦੇਰੀਆਂ ਤੋਂ ਬਚਣ ਲਈ ਮੁੜ ਭੇਜਣ ਦੀਆਂ ਸਮਾਂ-ਖਿੜਕੀਆਂ ਅਤੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਦੀਆਂ ਅਧਿਕਤਮ ਹੱਦਾਂ ਨਿਰਧਾਰਤ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।
ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਉਹ ਵਿਹਾਰ ਜੋ ਪ੍ਰਵਾਹ ਤੋੜ ਦਿੰਦੇ ਹਨ
ਟੈਬ ਬਦਲਣਾ, ਮੋਬਾਈਲ ਐਪ ਨੂੰ ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਭੇਜਣਾ ਅਤੇ ਗਲਤ ਉਪਨਾਮ ਕਾਪੀ ਕਰਨਾ—ਇਹ ਸਭ ਅਸਵੀਕਾਰ ਹੋਣ ਜਾਂ ਮਿਆਦ ਪੁੱਗਣ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੇ ਹਨ, ਭਾਵੇਂ ਸੁਨੇਹੇ ਪਹੁੰਚ ਗਏ ਹੋਣ। ਟੈਸਟਾਂ ਲਈ UI ਦੇ ਛੋਟੇ ਲਿਖਤ-ਸੁਨੇਹਿਆਂ ਵਿੱਚ "ਪੰਨੇ 'ਤੇ ਰਹੋ, ਉਡੀਕ ਕਰੋ, ਇੱਕ ਵਾਰ ਮੁੜ ਭੇਜੋ" ਸ਼ਾਮਲ ਕਰੋ।
3) ਵਾਤਾਵਰਣ ਵੱਖਰੇ, ਸੰਕੇਤ ਵੱਖਰੇ
ਭੇਜਣ ਵਾਲੇ ਦੀ ਸਾਖ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਖ਼ਰਾਬ ਹੋਣ ਤੋਂ ਬਚਾਉਣ ਲਈ QA/UAT ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਤੋਂ ਅਲੱਗ ਰੱਖੋ।
ਸਟੇਜਿੰਗ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਡੋਮੇਨ
ਸਟੇਜਿੰਗ ਲਈ ਵੱਖਰੇ ਭੇਜਣ ਵਾਲੇ ਡੋਮੇਨ ਅਤੇ reply-to ਪਛਾਣਾਂ ਬਣਾਈ ਰੱਖੋ। ਜੇ ਟੈਸਟ OTP ਪ੍ਰੋਡਕਸ਼ਨ ਪੂਲਾਂ ਵਿੱਚ ਲੀਕ ਹੋ ਜਾਣ, ਤਾਂ ਤੁਸੀਂ ਗਲਤ ਨਤੀਜੇ ਕੱਢੋਗੇ ਅਤੇ ਠੀਕ ਉਸ ਵੇਲੇ ਸਾਖ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੇ ਹੋ, ਜਦੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਪੁਸ਼ ਨੂੰ ਇਸ ਦੀ ਲੋੜ ਹੋਵੇ।
ਟੈਸਟ ਖਾਤੇ ਅਤੇ ਕੋਟੇ
ਨਾਮਜ਼ਦ ਟੈਸਟ ਖਾਤੇ ਬਣਾਓ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਕੋਟੇ ਦਿਓ। ਕੁਝ ਗਿਣਤੀ ਵਿੱਚ ਅਨੁਸ਼ਾਸਿਤ ਟੈਸਟ ਪਛਾਣਾਂ, ਸੈਂਕੜੇ ਬੇਤਰਤੀਬਾ ਪਛਾਣਾਂ ਨਾਲੋਂ ਬਿਹਤਰ ਹਨ, ਜੋ ਫ੍ਰੀਕੁਐਂਸੀ-ਅਧਾਰਿਤ ਨਿਯਮਾਂ ਨੂੰ ਸਰਗਰਮ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਸਿੰਥੈਟਿਕ ਟ੍ਰੈਫਿਕ ਦੀਆਂ ਸਮਾਂ-ਖਿੜਕੀਆਂ
ਸਿੰਥੈਟਿਕ OTP ਟ੍ਰੈਫਿਕ ਨੂੰ ਘੱਟ-ਭੀੜ ਵਾਲੀਆਂ ਸਮਾਂ-ਖਿੜਕੀਆਂ ਵਿੱਚ ਚਲਾਓ। ਲੇਟੈਂਸੀ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਲਈ ਛੋਟੇ ਸਮੇਂ ਦੇ ਉਛਾਲ ਵਰਤੋ, ਨਾ ਕਿ ਅਜਿਹੇ ਬੇਅੰਤ ਹੜ੍ਹ ਜੋ ਦੁਰਵਰਤੋਂ ਵਰਗੇ ਲੱਗਣ।
ਮੇਲ ਫੁੱਟਪ੍ਰਿੰਟ ਦਾ ਆਡਿਟ
ਉਨ੍ਹਾਂ ਡੋਮੇਨਾਂ, IP ਪਤਿਆਂ ਅਤੇ ਪ੍ਰਦਾਤਾਵਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਹਾਡੇ ਟੈਸਟ ਛੁਹਿੰਦੇ ਹਨ। ਇਹ ਪੱਕਾ ਕਰੋ ਕਿ ਸਟੇਜਿੰਗ ਪਛਾਣਾਂ ਲਈ SPF/DKIM/DMARC ਇੱਕਸਾਰ ਹਨ, ਤਾਂ ਜੋ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਸਪੁਰਦਗੀ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਨਾ ਮਿਲਾਇਆ ਜਾਵੇ।
4) ਸਹੀ ਇਨਬਾਕਸ ਰਣਨੀਤੀ ਚੁਣੋ
ਕੀ ਤੁਸੀਂ ਟੈਸਟ ਸੰਕੇਤਾਂ ਨੂੰ ਸਥਿਰ ਰੱਖਣ ਲਈ ਇਹ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਪਤੇ ਕਦੋਂ ਮੁੜ ਵਰਤਣੇ ਹਨ ਅਤੇ ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ ਇਨਬਾਕਸ ਕਦੋਂ ਵਰਤਣੇ ਹਨ?
ਰੀਗ੍ਰੇਸ਼ਨ ਲਈ ਮੁੜ ਵਰਤੋਂਯੋਗ ਪਤੇ
ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ ਟੈਸਟਾਂ (ਰੀਗ੍ਰੇਸ਼ਨ ਸੂਟਾਂ, ਪਾਸਵਰਡ ਰੀਸੈਟ ਲੂਪਾਂ) ਲਈ, ਇੱਕ ਮੁੜ ਵਰਤੋਂਯੋਗ ਪਤਾ ਨਿਰੰਤਰਤਾ ਅਤੇ ਸਥਿਰਤਾ ਕਾਇਮ ਰੱਖਦਾ ਹੈ। token-ਅਧਾਰਿਤ ਮੁੜ ਖੋਲ੍ਹਣ ਨਾਲ ਕਈ ਦਿਨਾਂ ਅਤੇ ਡਿਵਾਈਸਾਂ ਵਿੱਚ ਬੇਲੋੜਾ ਸ਼ੋਰ ਘਟਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਇਹ ਕਈ ਬਿਲਡਾਂ ਦੇ ਇੱਕੋ ਜਿਹੇ ਨਤੀਜਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਲਈ ਆਦਰਸ਼ ਬਣ ਜਾਂਦਾ ਹੈ। ਕਾਰਜਸ਼ੀਲ ਵੇਰਵਿਆਂ ਲਈ, ਸਹੀ ਇਨਬਾਕਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਮੁੜ ਖੋਲ੍ਹਣ ਬਾਰੇ ਹਦਾਇਤਾਂ ਲਈ 'ਅਸਥਾਈ ਮੇਲ ਪਤੇ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰੋ' ਵੇਖੋ.
ਬਰਸਟ ਟੈਸਟਿੰਗ ਲਈ ਥੋੜ੍ਹੇ ਸਮੇਂ ਵਾਲੇ ਇਨਬਾਕਸ
ਇੱਕ-ਵਾਰ ਦੇ ਵਾਧੂ ਲੋਡ ਅਤੇ ਖੋਜੀ QA ਲਈ, ਥੋੜ੍ਹੇ ਸਮੇਂ ਵਾਲੇ ਇਨਬਾਕਸ ਬਚਿਆ ਹੋਇਆ ਡਾਟਾ ਘੱਟ ਕਰਦੇ ਹਨ ਅਤੇ ਸੂਚੀ ਵਿੱਚ ਬੇਲੋੜਾ ਭਾਰ ਪੈਣ ਤੋਂ ਰੋਕਦੇ ਹਨ। ਇਹ ਟੈਸਟ ਦ੍ਰਿਸ਼ਾਂ ਵਿਚਕਾਰ ਸਾਫ਼-ਸੁਥਰੇ ਰੀਸੈੱਟ ਨੂੰ ਵੀ ਉਤਸ਼ਾਹਿਤ ਕਰਦੇ ਹਨ। ਜੇ ਕਿਸੇ ਟੈਸਟ ਲਈ ਸਿਰਫ਼ ਇੱਕ OTP ਦੀ ਲੋੜ ਹੈ, ਤਾਂ 10 ਮਿੰਟ ਮੇਲ ਵਰਗਾ ਥੋੜ੍ਹੇ ਸਮੇਂ ਵਾਲਾ ਮਾਡਲ ਢੁਕਵਾਂ ਰਹਿੰਦਾ ਹੈ।
token-ਅਧਾਰਿਤ ਰਿਕਵਰੀ ਅਨੁਸ਼ਾਸਨ
ਜੇ ਮੁੜ ਵਰਤੋਂਯੋਗ ਟੈਸਟ ਇਨਬਾਕਸ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਤਾਂ access token ਨੂੰ ਕਿਸੇ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਵਾਂਗ ਸੰਭਾਲੋ। ਤੁਸੀਂ ਇਸਨੂੰ ਟੈਸਟ ਸੂਟ ਦੇ ਲੇਬਲ ਹੇਠਾਂ, ਭੂਮਿਕਾ-ਅਧਾਰਿਤ ਪਹੁੰਚ ਵਾਲੇ ਪਾਸਵਰਡ ਮੈਨੇਜਰ ਵਿੱਚ ਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ।
ਪਤਿਆਂ ਦੇ ਟਕਰਾਅ ਤੋਂ ਬਚਣਾ
ਉਪਨਾਮਾਂ ਨੂੰ ਬੇਤਰਤੀਬ ਬਣਾਉਣਾ, ਮੂਲ ASCII ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਅਤੇ ਤੁਰੰਤ ਵਿਲੱਖਣਤਾ ਜਾਂਚ ਕਰਨਾ ਪੁਰਾਣੇ ਟੈਸਟ ਪਤਿਆਂ ਨਾਲ ਟਕਰਾਅ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। ਹਰ ਸੂਟ ਲਈ ਉਪਨਾਮਾਂ ਦੇ ਨਾਮਕਰਨ ਅਤੇ ਸਟੋਰੇਜ ਦਾ ਢੰਗ ਮਿਆਰੀ ਬਣਾਓ।
5) ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰੀਸੈਂਡ ਵਿੰਡੋਜ਼ ਸਥਾਪਤ ਕਰੋ
ਸਮੇਂ-ਸਬੰਧੀ ਵਿਹਾਰਾਂ ਨੂੰ ਮਿਆਰੀ ਬਣਾਕੇ “ਬੇਤਾਬੀ ਨਾਲ ਰੀਸੈਂਡ” ਅਤੇ ਗਲਤ throttling ਨੂੰ ਘਟਾਓ।
ਰੀਸੈਂਡ ਤੋਂ ਪਹਿਲਾਂ ਘੱਟੋ-ਘੱਟ ਉਡੀਕ
ਪਹਿਲੀ ਬੇਨਤੀ ਤੋਂ ਬਾਅਦ, ਇੱਕੋ ਇੱਕ ਵਿਵਸਥਿਤ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਪਹਿਲਾਂ 60–90 ਸਕਿੰਟ ਉਡੀਕ ਕਰੋ। ਇਸ ਨਾਲ greylisting ਦੀ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਅਸਫਲ ਹੋਣ ਤੋਂ ਬਚਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ sender queues ਸਾਫ਼ ਰਹਿੰਦੀਆਂ ਹਨ।
ਇੱਕੋ ਇੱਕ ਵਿਵਸਥਿਤ ਮੁੜ ਕੋਸ਼ਿਸ਼
ਟੈਸਟ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਇੱਕ ਰਸਮੀ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ, ਫਿਰ ਰੁਕੋ। ਜੇ ਕਿਸੇ ਦਿਨ p90 ਵਿੱਚ ਦੇਰੀ ਵੱਧ ਦਿਖਾਈ ਦੇਵੇ, ਤਾਂ ਵਾਰ-ਵਾਰ spam retries ਕਰਕੇ ਸਭ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਖ਼ਰਾਬ ਕਰਨ ਦੀ ਬਜਾਏ ਉਮੀਦਾਂ ਨੂੰ ਉਸ ਅਨੁਸਾਰ ਢਾਲੋ।
ਐਪ ਟੈਬ ਬਦਲਣ ਨੂੰ ਸੰਭਾਲਣਾ
ਜਦੋਂ ਵਰਤੋਂਕਾਰ ਐਪ ਨੂੰ background ਵਿੱਚ ਭੇਜਦੇ ਹਨ ਜਾਂ ਕਿਸੇ ਹੋਰ ਥਾਂ ਚਲੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਕੋਡ ਅਕਸਰ ਅਵੈਧ ਹੋ ਜਾਂਦੇ ਹਨ। QA ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ “ਸਕ੍ਰੀਨ ਉੱਤੇ ਰਹੋ” ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਕਦਮ ਵਜੋਂ ਸ਼ਾਮਲ ਕਰੋ; OS ਅਤੇ background ਵਿਹਾਰਾਂ ਨੂੰ logs ਵਿੱਚ ਦਰਜ ਕਰੋ।
ਟਾਈਮਰ ਟੈਲੀਮੈਟਰੀ ਦਰਜ ਕਰਨਾ
ਸਹੀ timestamps ਦਰਜ ਕਰੋ: ਬੇਨਤੀ, ਰੀਸੈਂਡ, ਇਨਬਾਕਸ ਵਿੱਚ ਪਹੁੰਚਣਾ, ਕੋਡ ਦਰਜ ਕਰਨਾ ਅਤੇ ਸਵੀਕਾਰ/ਅਸਵੀਕਾਰ ਸਥਿਤੀ। ਭੇਜਣ ਵਾਲੇ ਅਤੇ ਡੋਮੇਨ ਦੁਆਰਾ ਸਮਾਗਮਾਂ ਨੂੰ ਟੈਗ ਕਰੋ ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ ਫੋਰੈਂਸਿਕ ਸੰਭਵ ਹੋਵੇ।
6) ਡੋਮੇਨ ਰੋਟੇਸ਼ਨ ਨੀਤੀ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਓ
ਟੈਸਟ ਦੀ ਨਿਗਰਾਨੀਯੋਗਤਾ ਨੂੰ ਵੰਡੇ ਬਿਨਾਂ greylisting ਨੂੰ ਪਾਰ ਕਰਨ ਲਈ ਸਮਝਦਾਰੀ ਨਾਲ rotation ਕਰੋ।
ਪ੍ਰਤੀ ਭੇਜਣ ਵਾਲੇ ਰੋਟੇਸ਼ਨ ਕੈਪਸ
ਪਹਿਲੀ ਵਾਰ ਅਸਫਲ ਹੋਣ 'ਤੇ ਆਟੋ-ਰੋਟੇਸ਼ਨ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। ਭੇਜਣ ਵਾਲੇ ਦੇ ਆਧਾਰ 'ਤੇ ਸੀਮਾਵਾਂ ਨਿਰਧਾਰਤ ਕਰੋ: ਉਦਾਹਰਨ ਲਈ, ਇਕੋ ਭੇਜਣ ਵਾਲੇ×ਡੋਮੇਨ ਜੋੜੇ ਜੋੜੇ ਲਈ ਦੋਵੇਂ ਵਿੰਡੋਜ਼ ਅਸਫਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ ਰੋਟੇਸ਼ਨ ਕਰੋ—ਸੈਸ਼ਨਾਂ ਨੂੰ ≤2 ਰੋਟੇਸ਼ਨਾਂ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ ਤਾਂ ਜੋ reputation ਸੁਰੱਖਿਅਤ ਰਹੇ।
ਪੂਲ ਦੀ ਸਫ਼ਾਈ ਅਤੇ TTLs
ਪੁਰਾਣੇ ਅਤੇ ਨਵੇਂ ਡੋਮੇਨਾਂ ਦੇ ਮਿਸ਼ਰਣ ਨਾਲ domain pools ਤਿਆਰ ਕਰੋ। ਜਦੋਂ p90 ਵਿੱਚ ਗਿਰਾਵਟ ਆਵੇ ਜਾਂ ਸਫਲਤਾ ਘਟੇ, ਤਾਂ “ਥੱਕੇ ਹੋਏ” ਡੋਮੇਨਾਂ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਹਟਾ ਦਿਓ; recovery ਤੋਂ ਬਾਅਦ ਮੁੜ ਸ਼ਾਮਲ ਕਰੋ। TTLs ਨੂੰ ਟੈਸਟ ਦੀ cadence ਨਾਲ ਮਿਲਾਓ ਤਾਂ ਜੋ inbox ਦੀ ਦਿੱਖ ਤੁਹਾਡੀ review window ਨਾਲ ਇਕਸਾਰ ਰਹੇ।
A/B ਲਈ ਸਟਿੱਕੀ ਰੂਟਿੰਗ
ਬਿਲਡਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਸਮੇਂ, ਸਟਿੱਕੀ ਰੂਟਿੰਗ ਰੱਖੋ: ਇਕੋ ਭੇਜਣ ਵਾਲਾ ਸਾਰੇ ਰੂਪਾਂ ਵਿੱਚ ਇਕੋ ਡੋਮੇਨ ਪਰਿਵਾਰ ਵੱਲ ਜਾਂਦਾ ਹੈ. ਇਹ ਮੈਟ੍ਰਿਕਸ ਦੇ ਅੰਤਰ-ਦੂਸ਼ਿਤਤਾ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਰੋਟੇਸ਼ਨ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਨੂੰ ਮਾਪਣਾ
ਘੁੰਮਣਾ ਕੋਈ ਅਨੁਮਾਨ ਨਹੀਂ ਹੈ. ਇਕੋ ਜਿਹੇ ਰੀਸੈਂਡ ਵਿੰਡੋਜ਼ ਦੇ ਅਧੀਨ ਘੁੰਮਣ ਦੇ ਨਾਲ ਅਤੇ ਬਿਨਾਂ ਰੂਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ. ਡੂੰਘੇ ਤਰਕ ਅਤੇ ਗਾਰਡਰੇਲ ਲਈ, ਇਸ ਵਿਆਖਿਆਕਾਰ ਵਿੱਚ ਓਟੀਪੀ ਲਈ ਡੋਮੇਨ ਰੋਟੇਸ਼ਨ ਵੇਖੋ: ਓਟੀਪੀ ਲਈ ਡੋਮੇਨ ਰੋਟੇਸ਼ਨ.
7) ਸਹੀ ਮੈਟ੍ਰਿਕਸ ਦਾ ਸਾਧਨ ਬਣਾਓ
ਲੇਟੈਂਸੀ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਕੇ ਅਤੇ ਮੂਲ-ਕਾਰਨ ਲੇਬਲ ਨਿਰਧਾਰਤ ਕਰਕੇ ਓਟੀਪੀ ਦੀ ਸਫਲਤਾ ਨੂੰ ਮਾਪਣਯੋਗ ਬਣਾਓ.
ਡੋਮੇਨ × ਭੇਜਣ ਵਾਲੇ ਦੁਆਰਾ ਓਟੀਪੀ ਸਫਲਤਾ: ਚੋਟੀ ਦੀ ਲਾਈਨ ਐਸਐਲਓ ਨੂੰ ਡੋਮੇਨ ਮੈਟ੍ਰਿਕਸ × ਭੇਜਣ ਵਾਲੇ ਦੁਆਰਾ ਵਿਗਾੜਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਜੋ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਮੁੱਦਾ ਕਿਸੇ ਸਾਈਟ / ਐਪ ਨਾਲ ਹੈ ਜਾਂ ਵਰਤੇ ਗਏ ਡੋਮੇਨ ਨਾਲ ਹੈ.
ਟੀਟੀਐਫਓਐਮ ਪੀ 50 / ਪੀ 90, ਪੀ 95
ਮੱਧਮ ਅਤੇ ਪੂਛ ਦੇਰੀ ਵੱਖਰੀਆਂ ਕਹਾਣੀਆਂ ਦੱਸਦੀਆਂ ਹਨ. ਪੀ 50 ਰੋਜ਼ਾਨਾ ਸਿਹਤ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ; ਪੀ 90 / ਪੀ 95 ਤਣਾਅ, ਥ੍ਰੋਟਲਿੰਗ ਅਤੇ ਕਤਾਰ ਦਾ ਖੁਲਾਸਾ ਕਰਦਾ ਹੈ.
ਮੁੜ-ਭੇਜੋ ਅਨੁਸ਼ਾਸਨ ٪
ਅਧਿਕਾਰਤ ਮੁੜ-ਭੇਜਣ ਦੀ ਯੋਜਨਾ ਦੀ ਪਾਲਣਾ ਕਰਨ ਵਾਲੇ ਸੈਸ਼ਨਾਂ ਦੇ ਹਿੱਸੇ ਨੂੰ ਟਰੈਕ ਕਰੋ। ਜੇ ਬਹੁਤ ਜਲਦੀ ਨਾਰਾਜ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਨ੍ਹਾਂ ਅਜ਼ਮਾਇਸ਼ਾਂ ਨੂੰ ਸਪੁਰਦਗੀ ਦੇ ਸਿੱਟਿਆਂ ਤੋਂ ਛੋਟ ਦਿਓ.
ਅਸਫਲਤਾ ਵਰਗੀਕਰਨ ਕੋਡ
ਇਹਨਾਂ ਵਰਗੇ codes ਅਪਣਾਓ: ਜੀਐਲ ( ਗ੍ਰੇਲਿਸਟਿੰਗ), ਆਰਟੀ ( ਰੇਟ-ਸੀਮਾ), ਬੀਐਲ (ਬਲੌਕਡ ਡੋਮੇਨ; ਉਪਭੋਗਤਾ ਇੰਟਰੈਕਸ਼ਨ / ਟੈਬ ਸਵਿੱਚ), ਅਤੇ ਓਟੀ ( (ਹੋਰ)। ਘਟਨਾ ਨੋਟਾਂ ਵਿੱਚ ਕੋਡ ਲਾਜ਼ਮੀ ਕਰੋ।
8) ਪੀਕ ਸਮਿਆਂ ਲਈ QA ਪਲੇਬੁੱਕ ਬਣਾਓ
ਗੇਮਿੰਗ ਲਾਂਚਾਂ ਜਾਂ ਫਿਨਟੈਕ ਕਟਓਵਰਾਂ ਦੌਰਾਨ ਕੋਡ ਗੁਆਏ ਬਿਨਾਂ ਟ੍ਰੈਫਿਕ ਦੇ ਅਚਾਨਕ ਵਾਧੇ ਨੂੰ ਸੰਭਾਲੋ।
ਇਵੈਂਟਾਂ ਤੋਂ ਪਹਿਲਾਂ ਵਾਰਮ-ਅੱਪ ਰਨ
ਪੀਕ ਸਮੇਂ ਤੋਂ 24–72 ਘੰਟੇ ਪਹਿਲਾਂ ਜਾਣੇ-ਪਛਾਣੇ ਭੇਜਣ ਵਾਲਿਆਂ ਤੋਂ ਘੱਟ ਦਰ 'ਤੇ ਨਿਯਮਿਤ OTP ਭੇਜੋ, ਤਾਂ ਜੋ ਭੇਜਣ ਵਾਲੇ ਦੀ ਪ੍ਰਤਿਸ਼ਠਾ ਵਧੇ। ਵਾਰਮ-ਅੱਪ ਦੌਰਾਨ p90 ਦੇ ਰੁਝਾਨ ਮਾਪੋ।
ਜੋਖਮ ਅਨੁਸਾਰ ਬੈਕਆਫ ਪ੍ਰੋਫਾਈਲ
ਜੋਖਮ ਸ਼੍ਰੇਣੀਆਂ ਨਾਲ ਬੈਕਆਫ ਕਰਵ ਜੋੜੋ। ਆਮ ਸਾਈਟਾਂ ਲਈ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਦੋ ਰੀਟਰੀ ਕਾਫ਼ੀ ਹਨ। ਉੱਚ-ਜੋਖਮ ਵਾਲੇ ਫਿਨਟੈਕ ਲਈ ਲੰਬੀਆਂ ਵਿੰਡੋਜ਼ ਅਤੇ ਘੱਟ ਰੀਟਰੀ ਕਰਨ ਨਾਲ ਘੱਟ ਫਲੈਗ ਉੱਠਦੇ ਹਨ।
ਕੈਨਰੀ ਰੋਟੇਸ਼ਨ ਅਤੇ ਚੇਤਾਵਨੀਆਂ
ਇਵੈਂਟ ਦੌਰਾਨ 5–10% OTP ਨੂੰ ਕੈਨਰੀ ਡੋਮੇਨਾਂ ਦੇ ਇੱਕ ਉਪ-ਸਮੂਹ ਰਾਹੀਂ ਰੂਟ ਕਰੋ। ਜੇ ਕੈਨਰੀਆਂ ਵਿੱਚ p90 ਵਧਦਾ ਜਾਂ ਸਫਲਤਾ ਦਰ ਘਟਦੀ ਦਿਖੇ, ਤਾਂ ਪ੍ਰਾਇਮਰੀ ਪੂਲ ਨੂੰ ਜਲਦੀ ਰੋਟੇਟ ਕਰੋ।
ਪੇਜਰ ਅਤੇ ਰੋਲਬੈਕ ਟ੍ਰਿਗਰ
ਸੰਖਿਆਤਮਕ ਟ੍ਰਿਗਰ ਨਿਰਧਾਰਤ ਕਰੋ—ਜਿਵੇਂ ਕਿ OTP Success 10 ਮਿੰਟਾਂ ਲਈ 92% ਤੋਂ ਹੇਠਾਂ ਚਲਾ ਜਾਵੇ ਜਾਂ TTFOM p90 180 ਸਕਿੰਟ ਤੋਂ ਵੱਧ ਹੋ ਜਾਵੇ—ਤਾਂ ਜੋ ਆਨ-ਕਾਲ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਪੇਜ ਕੀਤਾ ਜਾ ਸਕੇ, ਵਿੰਡੋਜ਼ ਵਧਾਈਆਂ ਜਾ ਸਕਣ ਜਾਂ ਨਵੇਂ ਤਿਆਰ ਪੂਲ 'ਤੇ ਸਵਿਚ ਕੀਤਾ ਜਾ ਸਕੇ।
9) ਸੁਰੱਖਿਅਤ ਹੈਂਡਲਿੰਗ ਅਤੇ ਗੋਪਨੀਯਤਾ ਨਿਯੰਤਰਣ
ਨਿਯਮਬੱਧ ਉਦਯੋਗਾਂ ਵਿੱਚ ਟੈਸਟ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹੋਏ ਉਪਭੋਗਤਾ ਦੀ ਗੋਪਨੀਯਤਾ ਦੀ ਰੱਖਿਆ ਕਰੋ।
ਸਿਰਫ਼ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਟੈਸਟ ਮੇਲਬਾਕਸ
ਦੁਰਵਿਵਹਾਰ ਵੈਕਟਰਾਂ ਨੂੰ ਰੋਕਣ ਅਤੇ ਬਾਹਰੀ ਜੋਖਮ ਨੂੰ ਸੀਮਤ ਕਰਨ ਲਈ ਸਿਰਫ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਅਸਥਾਈ ਈਮੇਲ ਪਤੇ ਦੀ ਵਰਤੋਂ ਕਰੋ. ਅਟੈਚਮੈਂਟ ਸਿਰਫ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਹਨ - ਇੱਕ ਟਮੇਲਰ ਇਨਬਾਕਸ ਫਾਈਲਾਂ ਬਿਲਕੁਲ ਵੀ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਕਿਉਂਕਿ ਹਰ ਆਉਣ ਵਾਲੀ ਅਟੈਚਮੈਂਟ ਪਹੁੰਚਦੇ ਹੀ ਹਟਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਜੇ ਟੈਸਟ ਅਧੀਨ ਪ੍ਰਵਾਹ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਫਾਈਲ ਵਜੋਂ ਭੇਜਦਾ ਹੈ, ਤਾਂ ਇਸ ਦੀ ਇੱਥੇ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ।
24-ਘੰਟਿਆਂ ਦੀ ਦਿੱਖ ਵਿੰਡੋ
ਟੈਸਟ ਸੁਨੇਹੇ ਪਹੁੰਚਣ ਤੋਂ ਲਗਭਗ 24 ਘੰਟਿਆਂ ਤੱਕ ਦਿਖਾਈ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ, ਫਿਰ ਆਪਣੇ ਆਪ ਮਿਟ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਇਹ ਵਿੰਡੋ ਸਮੀਖਿਆ ਲਈ ਕਾਫ਼ੀ ਲੰਬੀ ਅਤੇ ਗੋਪਨੀਯਤਾ ਲਈ ਕਾਫ਼ੀ ਛੋਟੀ ਹੈ। ਨੀਤੀ ਦੀ ਝਲਕ ਅਤੇ ਵਰਤੋਂ ਸਬੰਧੀ ਸੁਝਾਵਾਂ ਲਈ, ਟੈਂਪ ਮੇਲ ਗਾਈਡ ਟੀਮਾਂ ਲਈ ਸਥਾਈ ਬੁਨਿਆਦੀ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਦਾ ਹੈ।
ਜੀਡੀਪੀਆਰ/ਸੀਸੀਪੀਏ ਵਿਚਾਰ
ਜਿੱਥੇ ਵੀ ਪ੍ਰਵਾਹ ਇਜਾਜ਼ਤ ਦੇਵੇ, ਟੈਸਟ ਈਮੇਲਾਂ ਵਿੱਚੋਂ ਅਸਲ ਨਿੱਜੀ ਡੇਟਾ ਬਾਹਰ ਰੱਖੋ। ਜਿੱਥੇ ਕੋਈ ਟੈਸਟ ਇਸ ਤੋਂ ਬਚ ਨਹੀਂ ਸਕਦਾ, ਉੱਥੇ ਡੇਟਾ ਨੂੰ ਟੈਸਟ ਲਈ ਲੋੜੀਂਦੀ ਹੱਦ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ, ਧਾਰਣ ਮਿਆਦ ਛੋਟੀ ਰੱਖੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਲੌਗ, ਸਕ੍ਰੀਨਸ਼ਾਟ ਅਤੇ ਕਾਪੀ ਕੀਤੇ ਕੋਡਾਂ ਨੂੰ ਤੁਰੰਤ ਸਾਫ਼ ਕਰੋ। ਛੋਟੀ ਧਾਰਣ ਮਿਆਦ, ਸਾਫ਼ ਕੀਤਾ HTML ਅਤੇ ਚਿੱਤਰ ਪ੍ਰੌਕਸੀ ਐਕਸਪੋਜ਼ਰ ਘਟਾਉਂਦੇ ਹਨ—ਪਰ ਇਹ ਸਾਂਝੇ, ਬਿਨਾਂ ਪ੍ਰਮਾਣੀਕਰਨ ਵਾਲੇ ਇਨਬਾਕਸ ਨੂੰ ਨਿੱਜੀ ਡੇਟਾ ਲਈ ਸੁਰੱਖਿਅਤ ਥਾਂ ਨਹੀਂ ਬਣਾਉਂਦੇ। ਅਸਥਾਈ ਈਮੇਲ ਪਤਾ ਨਿਯੰਤਰਿਤ ਡੇਟਾ ਸਟੋਰ ਨਹੀਂ ਹੈ: ਜਿਸ ਕਿਸੇ ਕੋਲ ਪਤਾ ਹੈ, ਉਹ ਉਸ ਵਿੱਚ ਆਉਣ ਵਾਲੀ ਸਮੱਗਰੀ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਨਬਾਕਸ ਵਿੱਚ ਕੋਈ ਸਪੈਮ ਫੋਲਡਰ ਜਾਂ ਫਿਲਟਰ ਨਹੀਂ ਹਨ, ਇਸ ਲਈ ਹਰ ਆਉਣ ਵਾਲਾ ਸੁਨੇਹਾ ਸਿੱਧਾ ਦਿਖਾਇਆ ਜਾਂਦਾ ਹੈ।
ਲੌਗ ਰੈਡੈਕਸ਼ਨ ਅਤੇ ਪਹੁੰਚ ਨਿਯੰਤਰਣ
ਐਕਸੈਸ ਟੋਕਨ ਅਤੇ ਕੋਡਾਂ ਲਈ ਸਕ੍ਰੱਬ ਲੌਗ; ਇਨਬਾਕਸ ਲਈ ਐਕਸੈਸ ਟੋਕਨ ਲਈ ਭੂਮਿਕਾ-ਅਧਾਰਤ ਪਹੁੰਚ ਨੂੰ ਤਰਜੀਹ ਦਿਓ. ਕਿਹੜਾ ਟੈਸਟ ਮੇਲਬਾਕਸ ਕਿਸ ਨੇ ਦੁਬਾਰਾ ਖੋਲ੍ਹਿਆ ਅਤੇ ਕਦੋਂ ਖੋਲ੍ਹਿਆ, ਇਸ ਲਈ ਆਡਿਟ ਟ੍ਰੇਲ ਰੱਖੋ. ਐਕਸੈਸ ਟੋਕਨ ਨੂੰ ਅਸਫਲਤਾ ਦੇ ਇਕੋ ਬਿੰਦੂ ਵਜੋਂ ਮੰਨੋ: ਇਹ ਪਾਸਵਰਡ ਦੀ ਬਜਾਏ ਰਿਕਵਰੀ ਕੁੰਜੀ ਹੈ, ਇਹ ਕਿਸੇ ਹੋਰ ਨੂੰ ਪਤੇ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਰੱਖਦਾ, ਅਤੇ ਗੁੰਮ ਹੋਏ ਟੋਕਨ ਨੂੰ ਕਿਸੇ ਦੁਆਰਾ ਦੁਬਾਰਾ ਨਹੀਂ ਬਣਾਇਆ ਜਾ ਸਕਦਾ - ਟਮੇਲਰ ਸਮੇਤ.
10) ਗਵਰਨੈਂਸ: ਚੈੱਕਲਿਸਟ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਕਿਸਦੀ ਹੈ
ਇਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਹਰ ਨਿਯੰਤਰਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰੀ, ਸਮੀਖਿਆ ਦੀ ਆਵਰਤੀ ਅਤੇ ਸਬੂਤ ਨਿਰਧਾਰਤ ਕਰੋ।
ਓਟੀਪੀ ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਆਰਏਸੀਆਈ
ਜ਼ਿੰਮੇਵਾਰ ਮਾਲਕ (ਅਕਸਰ QA), ਜਵਾਬਦੇਹ ਪ੍ਰਾਯੋਜਕ (ਸੁਰੱਖਿਆ ਜਾਂ ਉਤਪਾਦ), ਸਲਾਹ-ਮਸ਼ਵਰਾ ਕੀਤਾ ਜਾਣ ਵਾਲਾ (ਇਨਫਰਾ / ਈਮੇਲ), ਅਤੇ ਸੂਚਿਤ ( (ਸਹਾਇਤਾ)। ਇਸ RACI ਨੂੰ ਰੈਪੋ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ।
ਤਿਮਾਹੀ ਨਿਯੰਤਰਣ ਸਮੀਖਿਆਵਾਂ
ਹਰ ਤਿਮਾਹੀ, ਚੈੱਕਲਿਸਟ ਦੇ ਆਧਾਰ ’ਤੇ ਨਮੂਨਾ ਟੈਸਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਤਾਂ ਜੋ ਇਹ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾ ਸਕੇ ਕਿ ਮੁੜ-ਭੇਜਣ ਦੀਆਂ ਵਿੰਡੋਜ਼, ਰੋਟੇਸ਼ਨ ਥ੍ਰੈਸ਼ਹੋਲਡ ਅਤੇ ਮੈਟ੍ਰਿਕ ਲੇਬਲ ਅਜੇ ਵੀ ਲਾਗੂ ਹਨ।
ਸਬੂਤ ਅਤੇ ਟੈਸਟ ਕਲਾਕ੍ਰਿਤੀਆਂ
ਹਰੇਕ ਨਿਯੰਤਰਣ ਨਾਲ ਸਕ੍ਰੀਨਸ਼ਾਟ, TTFOM ਵੰਡਾਂ ਅਤੇ ਭੇਜਣ ਵਾਲੇ×ਡੋਮੇਨ ਸਾਰਣੀਆਂ ਨੱਥੀ ਕਰੋ—access token ਨੂੰ ਉਨ੍ਹਾਂ ਟੈਸਟ ਸੂਟਾਂ ਦੇ ਹਵਾਲਿਆਂ ਸਮੇਤ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸਟੋਰ ਕਰੋ ਜਿਨ੍ਹਾਂ ਲਈ ਉਹ ਵਰਤੇ ਜਾਂਦੇ ਹਨ।
ਨਿਰੰਤਰ ਸੁਧਾਰ ਚੱਕਰ
ਜਦੋਂ ਘਟਨਾਵਾਂ ਵਾਪਰਦੀਆਂ ਹਨ, ਤਾਂ ਰਨਬੁੱਕ ਵਿੱਚ ਇੱਕ ਚੰਗੀ ਪ੍ਰਥਾ/ਵਿਰੋਧੀ-ਪੈਟਰਨ ਸ਼ਾਮਲ ਕਰੋ। ਥ੍ਰੈਸ਼ਹੋਲਡਾਂ ਨੂੰ ਸੁਧਾਰੋ, ਡੋਮੇਨ ਪੂਲਾਂ ਨੂੰ ਤਾਜ਼ਾ ਕਰੋ ਅਤੇ ਟੈਸਟਰਾਂ ਨੂੰ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਕਾਪੀ ਨੂੰ ਅਪਡੇਟ ਕਰੋ।
ਤੁਲਨਾ ਸਾਰਣੀ — ਰੋਟੇਸ਼ਨ ਬਨਾਮ ਬਿਨਾਂ ਰੋਟੇਸ਼ਨ (QA/UAT)
ਇਹ ਸਾਰਣੀ ਇੰਜੀਨੀਅਰਿੰਗ ਮਾਰਗਦਰਸ਼ਨ ਹੈ, ਬੈਂਚਮਾਰਕ ਡੇਟਾ ਨਹੀਂ. ਇਸ ਵਿੱਚ ਜਾਣ-ਬੁੱਝ ਕੇ ਲੇਟੈਂਸੀ ਜਾਂ ਸਫਲਤਾ-ਦਰ ਦੇ ਕੋਈ ਅੰਕੜੇ ਨਹੀਂ ਦਿੱਤੇ ਗਏ: ਇਹ ਭੇਜਣ ਵਾਲੇ ਪਲੇਟਫਾਰਮ, ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਡੋਮੇਨ, ਬਿਲਡ ਅਤੇ ਦਿਨ ਦੇ ਸਮੇਂ ’ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਥੇ ਛਪਿਆ ਕੋਈ ਵੀ ਅੰਕੜਾ ਦੁਹਰਾਇਆ ਨਹੀਂ ਜਾ ਸਕੇਗਾ। ਉੱਪਰ ਪਰਿਭਾਸ਼ਿਤ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਮਾਪੋ ਅਤੇ ਆਪਣੀ ਬੇਸਲਾਈਨ ਨਿਰਧਾਰਤ ਕਰੋ—ਫਿਰ ਇਸ ਬਾਰੇ ਫੈਸਲਾ ਕਰਨ ਲਈ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਕਤਾਰਾਂ ਵਰਤੋ।
| ਦ੍ਰਿਸ਼ | ਰੋਟੇਸ਼ਨ ਦੇ ਨਾਲ | ਬਿਨਾਂ ਰੋਟੇਸ਼ਨ | ਕੀ ਦੇਖਣਾ ਹੈ |
|---|---|---|---|
| ਗ੍ਰੇਲਿਸਟਿੰਗ ਦਾ ਸ਼ੱਕ | ਇੱਕ ਪੂਰੀ ਮੁੜ-ਭੇਜਣ ਵਿੰਡੋ ਦੀ ਉਡੀਕ ਕਰੋ, ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਨੂੰ ਲੌਗ ਕਰੋ, ਫਿਰ ਇੱਕੋ ਜਿਹੇ ਵਿਕਲਪਕ ਡੋਮੇਨ ਨਾਲ ਤੁਲਨਾ ਕਰੋ | ਇੱਕ ਵਿਸਤ੍ਰਿਤ ਨਿਰੀਖਣ ਵਿੰਡੋ ਦੌਰਾਨ ਉਸੇ ਪਤੇ ’ਤੇ ਬਣੇ ਰਹੋ | ਬਹੁਤ ਜਲਦੀ ਰੋਟੇਟ ਕਰਨ ਨਾਲ ਤੁਲਨਾ ਬੇਕਾਰ ਹੋ ਜਾਂਦੀ ਹੈ: ਫਿਰ ਇਹ ਪਤਾ ਨਹੀਂ ਲੱਗ ਸਕਦਾ ਕਿ ਬਦਲਾਅ ਉਡੀਕ ਕਾਰਨ ਹੋਇਆ ਜਾਂ ਪਤਾ ਬਦਲਣ ਕਾਰਨ |
| ਭੇਜਣ ਵਾਲੇ ਦੀਆਂ ਪੀਕ ਕਤਾਰਾਂ | ਸਿਰਫ਼ ਤਾਂ ਹੀ ਰੋਟੇਟ ਕਰੋ ਜੇ ਇੱਕੋ ਜਿਹੇ ਭੇਜਣ ਵਾਲੇ ਲੋਡ ਹੇਠ ਕੋਈ ਪ੍ਰਾਪਤਕਰਤਾ ਡੋਮੇਨ ਵਧੇਰੇ ਖ਼ਰਾਬ ਵਿਹਾਰ ਕਰੇ | ਉਡੀਕ ਵਿੰਡੋ ਵਧਾਓ ਅਤੇ ਡੋਮੇਨ ਨੂੰ ਸਥਿਰ ਰੱਖੋ | ਕਤਾਰ ਦੀ ਭੀੜ ਆਮ ਤੌਰ ’ਤੇ ਭੇਜਣ ਵਾਲੇ ਪਾਸੇ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਡੋਮੇਨ ਬਦਲਣ ਨਾਲ ਮੂਲ ਕਾਰਨ ਨੂੰ ਛੇੜੇ ਬਿਨਾਂ ਸਿਰਫ਼ ਵਾਧੂ ਸ਼ੋਰ ਪੈਦਾ ਹੁੰਦਾ ਹੈ |
| ਠੰਢਾ ਭੇਜਣ ਵਾਲਾ ਪੂਲ | ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਵਾਰਮ-ਅੱਪ ਕਰੋ ਅਤੇ ਇੱਕ ਛੋਟੇ ਕੈਨਰੀ ਉਪ-ਸਮੂਹ ਨੂੰ ਰੂਟ ਕਰੋ | ਕੇਵਲ ਇੱਕ ਸਥਿਰ ਡੋਮੇਨ 'ਤੇ ਵਾਰਮ-ਅੱਪ ਕਰੋ | ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਵਾਰਮ-ਅੱਪ ਕਰਨ ਦਾ ਅਨੁਸ਼ਾਸਨ ਬਦਲਾਅ ਕਰਨ ਨਾਲੋਂ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਹੈ; ਬਿਲਡਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵਾਰਮ-ਅੱਪ ਦੀ ਮਿਆਦ ਰਿਕਾਰਡ ਕਰੋ |
| ਸਥਿਰ ਭੇਜਣ ਵਾਲਾ | ਪ੍ਰਤੀ ਸੈਸ਼ਨ 0–1 ਰੋਟੇਸ਼ਨ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ | ਰੋਟੇਸ਼ਨ ਨਾ ਕਰਨ ਨੂੰ ਤਰਜੀਹ ਦਿਓ | ਬੇਲੋੜੀ ਅਦਲਾ-ਬਦਲੀ ਸਬੂਤਾਂ ਨੂੰ ਟੁਕੜਿਆਂ ਵਿੱਚ ਵੰਡ ਦਿੰਦੀ ਹੈ ਅਤੇ ਸਿਹਤਮੰਦ ਕੰਟਰੋਲ ਪਾਥ ਨੂੰ ਧੁੰਦਲਾ ਕਰ ਦਿੰਦੀ ਹੈ |
| ਇੱਕ ਪ੍ਰਾਪਤਕਰਤਾ ਡੋਮੇਨ ਫਲੈਗ ਕੀਤਾ ਗਿਆ ਹੈ | ਇੱਕ ਵਿਕਲਪਕ ਡੋਮੇਨ ਅਜ਼ਮਾਓ — ਇਹ ਡਿਲਿਵਰੀ ਦੀ ਖ਼ਰਾਬੀ ਦੀ ਆਮ ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ ਹੈ | ਉਸੇ ਡੋਮੇਨ 'ਤੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਰਹੋ ਅਤੇ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਲੌਗ ਕਰੋ | ਰਿਕਾਰਡ ਕਰੋ ਕਿ ਕਿਹੜਾ ਭੇਜਣ ਵਾਲਾ × ਡੋਮੇਨ ਜੋੜਾ ਅਸਫਲ ਹੋਇਆ, ਤਾਂ ਜੋ ਨਤੀਜਾ ਕਿੱਸੇ-ਕਹਾਣੀ ਦੀ ਬਜਾਏ ਦੁਹਰਾਉਣਯੋਗ ਹੋਵੇ |
| ਸਾਈਟ ਦੀ ਨੀਤੀ ਅਸਥਾਈ ਈਮੇਲ ਦੀ ਮਨਾਹੀ ਕਰਦੀ ਹੈ | ਰੋਟੇਟ ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ। ਰੁਕੋ। | ਇੱਥੇ ਅਸਥਾਈ ਈਮੇਲ ਟੈਸਟ ਪਾਥ ਬੰਦ ਕਰੋ | ਇਹ ਨੀਤੀ ਦੀ ਸੀਮਾ ਹੈ, ਡਿਲਿਵਰੀ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ। ਫ਼ਲੋ ਨੂੰ ਅਸਲ ਜਾਂ ਕੰਪਨੀ-ਨਿਯੰਤਰਿਤ ਮੇਲਬਾਕਸ ਵੱਲ ਲਿਜਾਓ; ਸਵੀਕ੍ਰਿਤੀ ਨੂੰ ਮਜਬੂਰ ਕਰਨ ਲਈ ਅਸਥਾਈ ਈਮੇਲ ਪਤਿਆਂ ਨੂੰ ਵਾਰ-ਵਾਰ ਬਦਲਣਾ ਨੀਤੀ ਤੋਂ ਬਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਹੈ, ਅਤੇ QA ਨੂੰ ਅਜਿਹਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ |
ਤਰੀਕਾ
OTP ਟੈਸਟਿੰਗ, ਭੇਜਣ ਵਾਲੇ ਦੇ ਅਨੁਸ਼ਾਸਨ ਅਤੇ ਵਾਤਾਵਰਣਾਂ ਨੂੰ ਵੱਖ ਰੱਖਣ ਲਈ ਇੱਕ ਢਾਂਚਾਗਤ ਪ੍ਰਕਿਰਿਆ — QA, UAT ਅਤੇ ਉਤਪਾਦਨ ਨੂੰ ਅਲੱਗ ਰੱਖਣ ਲਈ ਲਾਭਦਾਇਕ।
ਕਦਮ 1: ਵਾਤਰਵਰਣਾਂ ਨੂੰ ਅਲੱਗ ਕਰੋ
ਵੱਖਰੀਆਂ QA/UAT ਭੇਜਣ ਵਾਲੇ ਪਛਾਣਾਂ ਅਤੇ ਡੋਮੇਨ ਪੂਲ ਬਣਾਓ; ਉਨ੍ਹਾਂ ਨੂੰ ਕਦੇ ਵੀ ਉਤਪਾਦਨ ਨਾਲ ਸਾਂਝਾ ਨਾ ਕਰੋ।
ਕਦਮ 2: ਮੁੜ ਭੇਜਣ ਦਾ ਸਮਾਂ ਮਿਆਰੀ ਬਣਾਓ
ਇੱਕ ਵਾਰ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ 60–90 ਸਕਿੰਟ ਉਡੀਕ ਕਰੋ; ਪ੍ਰਤੀ ਸੈਸ਼ਨ ਮੁੜ ਭੇਜਣ ਦੀ ਕੁੱਲ ਗਿਣਤੀ ਸੀਮਿਤ ਰੱਖੋ।
ਕਦਮ 3: ਰੋਟੇਸ਼ਨ ਸੀਮਾਵਾਂ ਕੌਂਫਿਗਰ ਕਰੋ
ਉਸੇ ਭੇਜਣ ਵਾਲੇ×ਡੋਮੇਨ ਲਈ ਸੀਮਾ ਪਾਰ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ ਰੋਟੇਸ਼ਨ ਕਰੋ; ਪ੍ਰਤੀ ਸੈਸ਼ਨ ≤2 ਰੋਟੇਸ਼ਨ।
ਕਦਮ 4: Token-ਅਧਾਰਿਤ ਮੁੜ ਵਰਤੋਂ ਅਪਣਾਓ
ਰੀਗ੍ਰੇਸ਼ਨ ਅਤੇ ਰੀਸੈੱਟ ਲਈ ਉਸੇ ਪਤੇ ਨੂੰ ਮੁੜ ਖੋਲ੍ਹਣ ਵਾਸਤੇ Access Tokens ਦੀ ਵਰਤੋਂ ਕਰੋ; Access Tokens ਨੂੰ ਪਾਸਵਰਡ ਮੈਨੇਜਰ ਵਿੱਚ ਸਟੋਰ ਕਰੋ।
ਕਦਮ 5: ਮੈਟ੍ਰਿਕਸ ਇੰਸਟਰੂਮੈਂਟ ਕਰੋ
ਲੌਗ ਓਟੀਪੀ ਸਫਲਤਾ, ਟੀਟੀਐਫਓਐਮ ਪੀ 50 / ਪੀ 90 (ਅਤੇ ਪੀ 95), ਅਨੁਸ਼ਾਸਨ ਨੂੰ ਦੁਬਾਰਾ ਭੇਜੋ ਪ੍ਰਤੀਸ਼ਤ, ਅਤੇ ਅਸਫਲਤਾ ਕੋਡ.
ਕਦਮ 6: ਪੀਕ ਰਿਹਰਸਲ ਚਲਾਓ
ਭੇਜਣ ਵਾਲਿਆਂ ਨੂੰ ਵਾਰਮ-ਅੱਪ ਕਰੋ; ਡ੍ਰਿਫ਼ਟ ਨੂੰ ਜਲਦੀ ਪਕੜਨ ਲਈ ਚੇਤਾਵਨੀਆਂ ਸਮੇਤ ਕੈਨਰੀ ਰੋਟੇਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ।
ਕਦਮ 7: ਸਮੀਖਿਆ ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਨ
ਨੱਥੀ ਸਬੂਤਾਂ ਦੇ ਆਧਾਰ ’ਤੇ ਹਰੇਕ ਕੰਟਰੋਲ ਦੀ ਸਮੀਖਿਆ ਕਰੋ ਅਤੇ ਮਨਜ਼ੂਰੀ ਦਰਜ ਕਰੋ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਂਦੇ ਪ੍ਰਸ਼ਨ
QA ਦੌਰਾਨ OTP ਕੋਡ ਦੇਰ ਨਾਲ ਕਿਉਂ ਪਹੁੰਚਦੇ ਹਨ, ਪਰ ਉਤਪਾਦਨ ਵਿੱਚ ਨਹੀਂ?
ਸਟੇਜਿੰਗ ਟ੍ਰੈਫਿਕ ਪ੍ਰਾਪਤਕਰਤਾਵਾਂ ਨੂੰ ਵਧੇਰੇ ਰੌਲਿਆਂ ਭਰਿਆ ਅਤੇ ਨਵਾਂ ਲੱਗਦਾ ਹੈ; greylisting ਅਤੇ throttling ਕਾਰਨ pools ਦੇ ਗਰਮ ਹੋਣ ਤੱਕ p90 ਵਧ ਜਾਂਦਾ ਹੈ।
“ਕੋਡ ਮੁੜ ਭੇਜੋ” ’ਤੇ ਟੈਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੈਨੂੰ ਕਿੰਨਾ ਇੰਤਜ਼ਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?
ਲਗਭਗ 60–90 ਸਕਿੰਟ। ਇਸ ਤੋਂ ਬਾਅਦ ਇੱਕ ਸੁਵਿਧਾਨੁਸਾਰ retry ਕਰੋ; ਵਾਰ-ਵਾਰ resend ਕਰਨ ਨਾਲ ਅਕਸਰ queues ਹੋਰ ਵਿਗੜ ਜਾਂਦੀਆਂ ਹਨ।
ਕੀ ਡੋਮੇਨ ਰੋਟੇਸ਼ਨ ਹਮੇਸ਼ਾਂ ਇਕੋ ਡੋਮੇਨ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ?
ਨਹੀਂ. ਥ੍ਰੈਸ਼ਹੋਲਡ ਟ੍ਰਿਪ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ ਘੁੰਮਾਓ; ਓਵਰ-ਰੋਟੇਸ਼ਨ ਸਾਖ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦਾ ਹੈ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਚਿੱਕੜ ਦਿੰਦਾ ਹੈ.
ਟੀਟੀਐਫਓਐਮ ਅਤੇ ਸਪੁਰਦਗੀ ਦੇ ਸਮੇਂ ਵਿੱਚ ਕੀ ਅੰਤਰ ਹੈ?
ਟੀਟੀਐਫਓਐਮ ਉਦੋਂ ਤੱਕ ਮਾਪਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਪਹਿਲਾ ਸੁਨੇਹਾ ਇਨਬਾਕਸ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦਾ; ਸਪੁਰਦਗੀ ਦੇ ਸਮੇਂ ਵਿੱਚ ਤੁਹਾਡੀ ਟੈਸਟ ਵਿੰਡੋ ਤੋਂ ਪਰੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਸ਼ਾਮਲ ਹੋ ਸਕਦੀ ਹੈ.
ਕੀ ਮੁੜ ਵਰਤੋਂ ਯੋਗ ਪਤੇ ਟੈਸਟਿੰਗ ਵਿੱਚ ਸਪੁਰਦਗੀ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੇ ਹਨ?
ਜ਼ਰੂਰੀ ਨਹੀਂ। ਇਹ ਤੁਲਨਾਵਾਂ ਨੂੰ ਸਥਿਰ ਰੱਖਦੇ ਹਨ, access token ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸੰਭਾਲਦੇ ਹਨ ਅਤੇ ਘਬਰਾਹਟ ਵਿੱਚ ਕੀਤੇ retries ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ।
ਮੈਂ ਵੱਖ-ਵੱਖ ਭੇਜਣ ਵਾਲਿਆਂ ਵਿੱਚ ਓਟੀਪੀ ਸਫਲਤਾ ਨੂੰ ਕਿਵੇਂ ਟਰੈਕ ਕਰਾਂ?
ਭੇਜਣ ਵਾਲੇ × ਡੋਮੇਨ ਦੁਆਰਾ ਆਪਣੇ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਮੈਟ੍ਰਿਕਸ ਕਰੋ ਤਾਂ ਜੋ ਇਹ ਉਜਾਗਰ ਕੀਤਾ ਜਾ ਸਕੇ ਕਿ ਕੀ ਮੁੱਦੇ ਕਿਸੇ ਸਾਈਟ / ਐਪ ਜਾਂ ਡੋਮੇਨ ਪਰਿਵਾਰ ਨਾਲ ਰਹਿੰਦੇ ਹਨ.
ਕੀ ਅਸਥਾਈ ਈਮੇਲ ਪਤੇ QA ਦੇ ਦੌਰਾਨ GDPR/CCPA ਦੇ ਅਨੁਕੂਲ ਹੋ ਸਕਦੇ ਹਨ?
ਹਾਂ-ਸਿਰਫ-ਪ੍ਰਾਪਤ, ਛੋਟੀ ਦਿੱਖ ਵਿੰਡੋਜ਼, ਸੈਨੀਟਾਈਜ਼ਡ HTML, ਅਤੇ ਚਿੱਤਰ ਪ੍ਰੌਕਸੀ ਗੋਪਨੀਯਤਾ-ਪਹਿਲੀ ਜਾਂਚ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ.
ਗ੍ਰੇਲਿਸਟਿੰਗ ਅਤੇ ਵਾਰਮ-ਅਪ ਓਟੀਪੀ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਤ ਕਰਦੇ ਹਨ?
greylisting ਸ਼ੁਰੂਆਤੀ ਕੋਸ਼ਿਸ਼ਾਂ ਵਿੱਚ ਦੇਰੀ ਕਰਦੀ ਹੈ; cold pools ਨੂੰ ਸਥਿਰ warm-up ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਦੋਵੇਂ ਮੁੱਖ ਤੌਰ ’ਤੇ p90 ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ, p50 ਨੂੰ ਨਹੀਂ।
ਕੀ ਮੈਨੂੰ QA ਅਤੇ UAT ਮੇਲਬਾਕਸ ਨੂੰ ਉਤਪਾਦਨ ਤੋਂ ਵੱਖ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ?
ਹਾਂ. ਪੂਲ ਵੱਖ ਕਰਨਾ ਸਟੇਜਿੰਗ ਸ਼ੋਰ ਨੂੰ ਉਤਪਾਦਨ ਦੀ ਸਾਖ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਘਟਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ.
ਓਟੀਪੀ ਸਫਲਤਾ ਆਡਿਟ ਲਈ ਕਿਹੜੀ ਟੈਲੀਮੈਟਰੀ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਣ ਹੈ?
ਓਟੀਪੀ ਸਫਲਤਾ ٪, ਟੀਟੀਐਫਓਐਮ ਪੀ 50 / ਪੀ 90 (ਤਣਾਅ ਲਈ ਪੀ 95), ਅਨੁਸ਼ਾਸਨ ਨੂੰ ਦੁਬਾਰਾ ਭੇਜੋ ਪ੍ਰਤੀਸ਼ਤ, ਅਤੇ ਅਸਫਲਤਾ ਕੋਡ ਟਾਈਮਸਟੈਂਪਡ ਸਬੂਤ ਦੇ ਨਾਲ. ਤੁਰੰਤ ਹਵਾਲੇ ਲਈ, ਟੈਂਪ ਮੇਲ ਅਕਸਰ ਪੁੱਛੇ ਜਾਂਦੇ ਪ੍ਰਸ਼ਨ ਵੇਖੋ.
Priya Nair focuses on email deliverability and one-time-password (OTP) flows. She tests how verification codes from Google, Apple, social and crypto platforms land in disposable inboxes, and documents what improves OTP reliability on temp mail.
