ਅਸਪਸ਼ਟ ਗੁਣਵੱਤਾ ਟੀਚੇ ਨੂੰ ਵੇਖੇ ਜਾ ਸਕਣ ਵਾਲੇ ਜਵਾਬ ਅਤੇ ਮਾਪਣ ਦੇ ਨਿਯਮ ਵਾਲੇ scenario ਵਿੱਚ ਬਦਲੋ। “ਪੋਰਟਲ ਤੇਜ਼ ਹੋਵੇ” ਡਿਜ਼ਾਈਨ ਚੁਣਨ ਜਾਂ release ਲੋੜ ਪੂਰੀ ਕਰਦਾ ਹੈ ਕਿ ਨਹੀਂ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ।
Stimulus ਦਾ ਸਰੋਤ, stimulus, ਪ੍ਰਭਾਵਿਤ ਸਿਸਟਮ, ਚਾਲੂ ਹਾਲਾਤ, ਉਮੀਦ ਕੀਤਾ response ਅਤੇ ਉਸਦਾ ਮਾਪ ਪਛਾਣੋ। ਇਹ ਭਾਗ ਧਾਰਨਾਵਾਂ ਸਪਸ਼ਟ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਵੱਖਰੀਆਂ ਟੀਮਾਂ ਇੱਕੋ ਦਾਅਵਾ ਜਾਂਚ ਸਕਣ।
ਉਦਾਹਰਨ ਵਾਲੇ ਵਾਪਸੀ ਪੋਰਟਲ ਲਈ ਕਾਰੋਬਾਰੀ ਮਾਲਕ ਨਾਲ ਇਹ scenario ਤੈਅ ਕਰੋ:
ਇਹ ਅੰਕ ਉਦਾਹਰਨ ਦੇ ਟੀਚੇ ਹਨ, ਉਦਯੋਗ ਦੇ default ਨਹੀਂ। ਅਸਫਲਤਾਵਾਂ ਵੱਖਰੀਆਂ ਦਿਖਾਓ ਤਾਂ ਜੋ ਤੇਜ਼ rejection latency ਨੂੰ ਚੰਗਾ ਨਾ ਦਿਖਾਏ। Acknowledgment ਗੋਦਾਮ ਦੇ ਕੰਮ ਮੁਕੰਮਲ ਹੋਣ ਤੋਂ ਵੀ ਵੱਖਰਾ ਹੈ; ਉਸ ਲਈ ਆਪਣਾ ਕਾਰੋਬਾਰੀ ਸਮਾਂ ਮਾਪਦੰਡ ਚਾਹੀਦਾ ਹੈ।
ਡਿਜ਼ਾਈਨ ਬੇਨਤੀ ਨੂੰ ਪੱਕੇ ਤੌਰ 'ਤੇ ਸਵੀਕਾਰ ਕਰਕੇ ਗੋਦਾਮ ਦਾ ਕੰਮ asynchronously ਕਰ ਸਕਦਾ ਹੈ। ਹਕੀਕਤੀ ਨੈੱਟਵਰਕ ਹਾਲਾਤਾਂ ਸਮੇਤ ਓਹੀ ਰਸਤਾ ਟੈਸਟ ਕਰੋ। ਅਣਉਪਲਬਧ ਨਿਰਭਰਤਾ ਅਤੇ recovery ਲਈ ਵੱਖਰੇ scenarios ਲਿਖੋ; ਸਿਹਤਮੰਦ ਸਿਸਟਮ ਦਾ load test ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।
ਔਸਤ latency ਹੌਲੀ ਸੇਵਾ ਲੈ ਰਹੇ ਵਰਤੋਂਕਾਰ ਲੁਕਾ ਦਿੰਦੀ ਹੈ। ਅਣਪਰਿਭਾਸ਼ਿਤ dataset ਨਤੀਜੇ ਦੁਹਰਾਉਣ ਔਖੇ ਕਰਦਾ ਹੈ। “ਹਮੇਸ਼ਾ ਉਪਲਬਧ” failure boundary ਜਾਂ measurement window ਨਹੀਂ ਦਿੰਦਾ। ਮਜ਼ਬੂਤ ਜਵਾਬ ਦੱਸਦਾ ਹੈ ਕੀ, ਕਿੱਥੋਂ, ਕਿਹੜੇ ਹਾਲਾਤਾਂ ਵਿੱਚ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਟੀਚਾ ਕਾਫ਼ੀ ਹੋਣ ਨਾਲ ਕੌਣ ਸਹਿਮਤ ਹੈ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ