ਗੁਣਵੱਤਾ ਲਈ ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਹੈ?

ਹੇ ਹਬਰ!

ਸਾਡੇ ਕੋਲ ਇੱਕ ਨਵਾਂ ਮਹੱਤਵਪੂਰਨ ਵਿਸ਼ਾ ਹੈ - ਆਈਟੀ ਉਤਪਾਦਾਂ ਦਾ ਉੱਚ-ਗੁਣਵੱਤਾ ਵਿਕਾਸ। HighLoad++ 'ਤੇ ਅਸੀਂ ਅਕਸਰ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ ਕਿ ਕਿਵੇਂ ਵਿਅਸਤ ਸੇਵਾਵਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਨਾ ਹੈ, ਅਤੇ Frontend Conf 'ਤੇ ਅਸੀਂ ਇੱਕ ਵਧੀਆ ਉਪਭੋਗਤਾ ਇੰਟਰਫੇਸ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ ਜੋ ਹੌਲੀ ਨਹੀਂ ਹੁੰਦਾ। ਸਾਡੇ ਕੋਲ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਟੈਸਟਿੰਗ ਬਾਰੇ ਵਿਸ਼ੇ ਹਨ, ਅਤੇ ਟੈਸਟਿੰਗ ਸਮੇਤ ਵੱਖ-ਵੱਖ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਜੋੜਨ ਬਾਰੇ DevOpsConf। ਪਰ ਇਸ ਬਾਰੇ ਕਿ ਕੀ ਆਮ ਤੌਰ 'ਤੇ ਗੁਣਵੱਤਾ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸ 'ਤੇ ਵਿਆਪਕ ਤੌਰ' ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ - ਨਹੀਂ.

ਆਓ ਇਸ ਨੂੰ ਠੀਕ ਕਰੀਏ QualityConf - ਅਸੀਂ ਵਿਕਾਸ ਦੇ ਹਰ ਪੜਾਅ 'ਤੇ ਉਪਭੋਗਤਾ ਲਈ ਅੰਤਮ ਉਤਪਾਦ ਦੀ ਗੁਣਵੱਤਾ ਬਾਰੇ ਸੋਚਣ ਦਾ ਸੱਭਿਆਚਾਰ ਵਿਕਸਿਤ ਕਰਾਂਗੇ। ਆਪਣੀ ਜਿੰਮੇਵਾਰੀ ਦੇ ਖੇਤਰ 'ਤੇ ਧਿਆਨ ਨਾ ਦੇਣ ਦੀ ਆਦਤ, ਅਤੇ ਗੁਣਵੱਤਾ ਨੂੰ ਨਾ ਸਿਰਫ ਟੈਸਟਰਾਂ ਨਾਲ ਜੋੜਨਾ.

ਕੱਟ ਦੇ ਹੇਠਾਂ ਅਸੀਂ ਪ੍ਰੋਗਰਾਮ ਕਮੇਟੀ ਦੇ ਮੁਖੀ, Tinkoff.Business ਵਿਖੇ ਟੈਸਟਿੰਗ ਦੇ ਮੁਖੀ, ਰੂਸੀ ਬੋਲਣ ਵਾਲੇ QA ਭਾਈਚਾਰੇ ਦੇ ਸਿਰਜਣਹਾਰ ਨਾਲ ਗੱਲ ਕਰਾਂਗੇ Anastasia Aseeva-Nguyen QA ਉਦਯੋਗ ਦੀ ਸਥਿਤੀ ਅਤੇ ਨਵੀਂ ਕਾਨਫਰੰਸ ਦੇ ਮਿਸ਼ਨ ਬਾਰੇ।

- Nastia ਹੈਲੋ. ਕਿਰਪਾ ਕਰਕੇ ਸਾਨੂੰ ਆਪਣੇ ਬਾਰੇ ਦੱਸੋ।

ਅਨਾਸਤਾਸੀਆ: ਮੈਂ ਇੱਕ ਬੈਂਕ ਵਿੱਚ ਜਾਂਚ ਦੀ ਅਗਵਾਈ ਕਰਦਾ ਹਾਂ ਅਤੇ ਇੱਕ ਬਹੁਤ ਵੱਡੀ ਟੀਮ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਾਂ—ਅਸੀਂ 90 ਤੋਂ ਵੱਧ ਲੋਕ ਹਾਂ। ਸਾਡੇ ਕੋਲ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਵਪਾਰਕ ਲਾਈਨ ਹੈ; ਅਸੀਂ ਕਾਨੂੰਨੀ ਸੰਸਥਾਵਾਂ ਲਈ ਈਕੋਸਿਸਟਮ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਾਂ।

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

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

ਇਹ ਮੇਰੇ ਲਈ ਸਪੱਸ਼ਟ ਹੈ ਇਸ ਦਿਸ਼ਾ ਵਿੱਚ ਭਾਈਚਾਰਾ ਕਾਫ਼ੀ ਪਰਿਪੱਕ ਨਹੀਂ ਹੈ, ਘੱਟੋ ਘੱਟ ਰੂਸ ਵਿੱਚ. ਅਸੀਂ ਹਮੇਸ਼ਾ ਇਹ ਨਹੀਂ ਸਮਝਦੇ ਹਾਂ ਕਿ ਗੁਣਵੱਤਾ ਦਾ ਭਰੋਸਾ ਸਿਰਫ਼ ਲੋੜਾਂ ਦੀ ਪਾਲਣਾ ਲਈ ਅਰਜ਼ੀ ਦੀ ਜਾਂਚ ਕਰਨ ਦਾ ਤੱਥ ਨਹੀਂ ਹੈ। ਮੈਂ ਇਸ ਸਥਿਤੀ ਨੂੰ ਬਦਲਣਾ ਚਾਹਾਂਗਾ।

- ਤੁਸੀਂ ਕੁਆਲਿਟੀ ਐਸ਼ੋਰੈਂਸ ਅਤੇ ਟੈਸਟਿੰਗ ਸ਼ਬਦਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ। ਔਸਤ ਵਿਅਕਤੀ ਦੀ ਨਜ਼ਰ ਵਿੱਚ, ਇਹ ਦੋ ਸ਼ਬਦ ਅਕਸਰ ਓਵਰਲੈਪ ਹੁੰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਡੂੰਘੀ ਖੁਦਾਈ ਕਰਦੇ ਹੋ ਤਾਂ ਉਹ ਕਿਵੇਂ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ?

ਅਨਾਸਤਾਸੀਆ: ਇਸ ਦੀ ਬਜਾਇ, ਉਹ ਵੱਖਰੇ ਨਹੀਂ ਹਨ. ਟੈਸਟਿੰਗ ਕੁਆਲਿਟੀ ਅਸ਼ੋਰੈਂਸ ਅਨੁਸ਼ਾਸਨ ਦਾ ਹਿੱਸਾ ਹੈ, ਇਹ ਇੱਕ ਸਿੱਧੀ ਗਤੀਵਿਧੀ ਹੈ - ਇਹ ਤੱਥ ਕਿ ਮੈਂ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹਾਂ। ਅਸਲ ਵਿੱਚ ਟੈਸਟਿੰਗ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਕਿਸਮਾਂ ਹਨ, ਅਤੇ ਕਈ ਤਰ੍ਹਾਂ ਦੇ ਲੋਕ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੇ ਟੈਸਟਾਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਨ। ਪਰ ਇੱਥੇ ਰੂਸ ਵਿੱਚ, ਜਦੋਂ ਆਊਟਸੋਰਸਰਾਂ ਦੀ ਇੱਕ ਲਹਿਰ ਦਿਖਾਈ ਦਿੱਤੀ ਜੋ ਕੰਪਨੀਆਂ ਨੂੰ ਟੈਸਟਰ ਸਪਲਾਈ ਕਰਦੇ ਹਨ, ਤਾਂ ਟੈਸਟਿੰਗ ਨੂੰ ਇੱਕ ਕਿਸਮ ਵਿੱਚ ਘਟਾ ਦਿੱਤਾ ਗਿਆ ਸੀ।

ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਉਹ ਸਿਰਫ ਫੰਕਸ਼ਨਲ ਟੈਸਟਿੰਗ ਤੱਕ ਹੀ ਸੀਮਿਤ ਹੁੰਦੇ ਹਨ: ਉਹ ਜਾਂਚ ਕਰਦੇ ਹਨ ਕਿ ਡਿਵੈਲਪਰਾਂ ਨੇ ਜੋ ਕੋਡ ਕੀਤਾ ਹੈ ਉਹ ਨਿਰਧਾਰਨ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹ ਹੀ ਹੈ।

- ਕਿਰਪਾ ਕਰਕੇ ਸਾਨੂੰ ਦੱਸੋ ਕਿ ਇੱਥੇ ਹੋਰ ਕੀ ਗੁਣਵੱਤਾ ਭਰੋਸਾ ਅਨੁਸ਼ਾਸਨ ਹਨ? ਇੱਥੇ ਟੈਸਟਿੰਗ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਕੀ ਸ਼ਾਮਲ ਹੈ?

ਅਨਾਸਤਾਸੀਆ: ਕੁਆਲਿਟੀ ਐਸ਼ੋਰੈਂਸ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਇੱਕ ਗੁਣਵੱਤਾ ਉਤਪਾਦ ਬਣਾਉਣ ਬਾਰੇ ਹੈ। ਭਾਵ, ਅਸੀਂ ਆਪਣੇ ਆਪ ਤੋਂ ਪੁੱਛਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਉਤਪਾਦ ਵਿੱਚ ਕਿਹੜੀਆਂ ਗੁਣਵੱਤਾ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਇਸ ਅਨੁਸਾਰ, ਜੇ ਅਸੀਂ ਇਸ ਨੂੰ ਸਮਝਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਤੁਲਨਾ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ ਇਹਨਾਂ ਗੁਣਾਂ ਦੇ ਗੁਣਾਂ ਨੂੰ ਕੌਣ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ. ਕੋਈ ਫਰਕ ਨਹੀਂ ਪੈਂਦਾ, ਡਿਵੈਲਪਰ, ਪ੍ਰੋਜੈਕਟ ਮੈਨੇਜਰ ਜਾਂ ਉਤਪਾਦ ਮਾਹਰ ਉਹ ਵਿਅਕਤੀ ਹੈ ਜੋ ਕਿਸੇ ਉਤਪਾਦ ਦੇ ਵਿਕਾਸ, ਇਸਦੇ ਬੈਕਲਾਗ ਅਤੇ ਇਸਦੀ ਰਣਨੀਤੀ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।

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

- ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਜੋ ਤੁਸੀਂ ਹੁਣੇ ਦੱਸਿਆ ਹੈ ਉਹ ਇੱਕ ਉਤਪਾਦ ਮਾਹਰ ਦਾ ਕੰਮ ਹੈ। ਇਹ, ਸਿਧਾਂਤ ਵਿੱਚ, ਟੈਸਟਿੰਗ ਬਾਰੇ ਨਹੀਂ ਹੈ ਅਤੇ ਗੁਣਵੱਤਾ ਬਾਰੇ ਨਹੀਂ - ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਉਤਪਾਦ ਪ੍ਰਬੰਧਨ ਬਾਰੇ ਹੈ, ਨਹੀਂ?

ਅਨਾਸਤਾਸੀਆ: ਸਮੇਤ. ਕੁਆਲਿਟੀ ਐਸ਼ੋਰੈਂਸ ਕੋਈ ਅਨੁਸ਼ਾਸਨ ਨਹੀਂ ਹੈ ਜਿਸ ਲਈ ਇੱਕ ਖਾਸ ਵਿਅਕਤੀ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਹੁਣ ਟੈਸਟਿੰਗ ਵਿੱਚ ਇੱਕ ਪ੍ਰਸਿੱਧ ਦਿਸ਼ਾ ਹੈ, ਜਿਸਨੂੰ ਇੱਕ ਪਹੁੰਚ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਚੁਸਤ ਟੈਸਟਿੰਗ. ਇਸਦੀ ਪਰਿਭਾਸ਼ਾ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸਦੀ ਹੈ ਕਿ ਇਹ ਟੈਸਟਿੰਗ ਲਈ ਇੱਕ ਟੀਮ ਪਹੁੰਚ ਹੈ, ਜਿਸ ਵਿੱਚ ਅਭਿਆਸਾਂ ਦਾ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਮੂਹ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ। ਇਸ ਪਹੁੰਚ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਸਮੁੱਚੀ ਟੀਮ ਜ਼ਿੰਮੇਵਾਰ ਹੈ, ਇਹ ਵੀ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ ਕਿ ਟੀਮ ਵਿਚ ਕੋਈ ਟੈਸਟਰ ਹੋਵੇ। ਪੂਰੀ ਟੀਮ ਗਾਹਕ ਨੂੰ ਮੁੱਲ ਪ੍ਰਦਾਨ ਕਰਨ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੈ ਕਿ ਮੁੱਲ ਗਾਹਕ ਦੀਆਂ ਉਮੀਦਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ।

- ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਗੁਣਵੱਤਾ ਲਗਭਗ ਸਾਰੇ ਆਲੇ-ਦੁਆਲੇ ਦੇ ਅਨੁਸ਼ਾਸਨਾਂ ਨੂੰ ਕੱਟਦੀ ਹੈ, ਆਲੇ ਦੁਆਲੇ ਦੀ ਹਰ ਚੀਜ਼ 'ਤੇ ਇੱਕ ਫਰੇਮਵਰਕ ਥੋਪਦੀ ਹੈ?

ਅਨਾਸਤਾਸੀਆ: ਸਹੀ। ਜਦੋਂ ਅਸੀਂ ਇਸ ਤੱਥ ਬਾਰੇ ਸੋਚਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਇੱਕ ਗੁਣਵੱਤਾ ਉਤਪਾਦ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਗੁਣਵੱਤਾ ਦੇ ਵੱਖੋ-ਵੱਖਰੇ ਗੁਣਾਂ ਬਾਰੇ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਾਂ। ਉਦਾਹਰਨ ਲਈ, ਕਿਵੇਂ ਜਾਂਚ ਕਰੀਏ ਕਿ ਅਸੀਂ ਅਸਲ ਵਿੱਚ ਉਹ ਵਿਸ਼ੇਸ਼ਤਾ ਬਣਾਈ ਹੈ ਜਿਸਦੀ ਸਾਡੇ ਕਲਾਇੰਟ ਦੀ ਲੋੜ ਹੈ।

ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇਸ ਕਿਸਮ ਦੀ ਜਾਂਚ ਆਉਂਦੀ ਹੈ: ਯੂ.ਏ.ਟੀ. (ਉਪਭੋਗਤਾ ਸਵੀਕ੍ਰਿਤੀ ਟੈਸਟਿੰਗ). ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਹ ਰੂਸ ਵਿੱਚ ਘੱਟ ਹੀ ਅਭਿਆਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਕਈ ਵਾਰ ਅੰਤਮ ਕਲਾਇੰਟ ਲਈ ਇੱਕ ਡੈਮੋ ਵਜੋਂ SCRUM ਟੀਮਾਂ ਵਿੱਚ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ। ਇਹ ਵਿਦੇਸ਼ੀ ਕੰਪਨੀਆਂ ਵਿੱਚ ਇੱਕ ਕਾਫ਼ੀ ਆਮ ਕਿਸਮ ਦੀ ਜਾਂਚ ਹੈ। ਸਾਰੇ ਗਾਹਕਾਂ ਲਈ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਪਹਿਲਾਂ UAT ਕਰਦੇ ਹਾਂ, ਯਾਨੀ ਅਸੀਂ ਅੰਤਮ ਉਪਭੋਗਤਾ ਨੂੰ ਟੈਸਟ ਕਰਨ ਲਈ ਸੱਦਾ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਤੁਰੰਤ ਇਸ ਬਾਰੇ ਫੀਡਬੈਕ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਾਂ ਕਿ ਕੀ ਉਤਪਾਦ ਅਸਲ ਵਿੱਚ ਉਮੀਦਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ ਅਤੇ ਦਰਦ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ ਹੀ ਬਾਕੀ ਸਾਰੇ ਗਾਹਕਾਂ ਲਈ ਸਕੇਲਿੰਗ ਸੰਭਵ ਹੈ।

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

ਇਸ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਆਰਕੀਟੈਕਚਰ ਅਜਿਹਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਅਸੀਂ ਸਾਫ਼ ਕੋਡ ਲਿਖ ਸਕੀਏ ਜੋ ਸਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਤਬਦੀਲੀਆਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ ਅਤੇ ਡਰਨਾ ਨਹੀਂ ਕਿ ਅਸੀਂ ਸਭ ਕੁਝ ਤੋੜ ਦੇਵਾਂਗੇ. ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰਨ ਲਈ ਕਿ ਸੰਸ਼ੋਧਨ ਦੁਹਰਾਓ ਕਈ ਮਹੀਨਿਆਂ ਤੱਕ ਨਹੀਂ ਫੈਲਦਾ ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਿਰਾਸਤ ਹੈ, ਸਾਨੂੰ ਲੰਬੇ ਟੈਸਟਿੰਗ ਪੜਾਅ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ।

- ਕੁੱਲ ਮਿਲਾ ਕੇ, ਡਿਵੈਲਪਰ, ਆਰਕੀਟੈਕਟ, ਉਤਪਾਦ ਵਿਗਿਆਨੀ, ਉਤਪਾਦ ਪ੍ਰਬੰਧਕ, ਅਤੇ ਟੈਸਟਰ ਖੁਦ ਪਹਿਲਾਂ ਹੀ ਸ਼ਾਮਲ ਹਨ। ਗੁਣਵੱਤਾ ਭਰੋਸਾ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਹੋਰ ਕੌਣ ਸ਼ਾਮਲ ਹੈ?

ਅਨਾਸਤਾਸੀਆ: ਹੁਣ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਗਾਹਕ ਨੂੰ ਵਿਸ਼ੇਸ਼ਤਾ ਪ੍ਰਦਾਨ ਕਰ ਚੁੱਕੇ ਹਾਂ। ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਉਤਪਾਦ ਦੀ ਗੁਣਵੱਤਾ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਭਾਵੇਂ ਇਹ ਪਹਿਲਾਂ ਹੀ ਉਤਪਾਦਨ ਵਿੱਚ ਹੋਵੇ. ਇਸ ਪੜਾਅ 'ਤੇ, ਗੈਰ-ਸਪੱਸ਼ਟ ਦ੍ਰਿਸ਼ਾਂ ਵਾਲੀਆਂ ਸਥਿਤੀਆਂ, ਅਖੌਤੀ ਬੱਗ, ਪ੍ਰਗਟ ਹੋ ਸਕਦੇ ਹਨ।

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

ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਸ਼ੋਸ਼ਣ ਖੇਡ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਜਾਂ ਜਿਵੇਂ ਕਿ ਉਹ ਇਸਨੂੰ ਹੁਣ ਕਹਿੰਦੇ ਹਨ। DevOps. ਅਸਲ ਵਿੱਚ, ਇਹ ਉਹ ਲੋਕ ਹਨ ਜੋ ਉਤਪਾਦ ਨੂੰ ਚਲਾਉਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਇਹ ਪਹਿਲਾਂ ਹੀ ਉਤਪਾਦਨ ਵਿੱਚ ਹੁੰਦਾ ਹੈ. ਇਸ ਵਿੱਚ ਕਈ ਤਰ੍ਹਾਂ ਦੀ ਨਿਗਰਾਨੀ ਸ਼ਾਮਲ ਹੈ। ਟੈਸਟਿੰਗ ਦੀ ਇੱਕ ਉਪ-ਕਿਸਮ ਵੀ ਹੈ - ਉਤਪਾਦਨ 'ਤੇ ਟੈਸਟਿੰਗ, ਜਦੋਂ ਅਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਉਤਪਾਦਨ 'ਤੇ ਤੁਰੰਤ ਇਸ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ। ਇਹ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਗਤੀਵਿਧੀਆਂ ਦੀ ਇੱਕ ਲੜੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਕਿਸੇ ਘਟਨਾ ਦਾ ਤੁਰੰਤ ਜਵਾਬ ਦੇਣ, ਇਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਅਤੇ ਇਸਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ।

ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਅਕਸਰ ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ, ਇੱਕ ਟੈਸਟ ਦੇ ਦੌਰਾਨ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਅਸੰਭਵ ਹੁੰਦਾ ਹੈ ਕਿ ਸਾਡੇ ਕੋਲ ਅਸਲ ਵਿੱਚ ਉਹ ਸਭ ਕੁਝ ਹੈ ਜੋ ਅਸੀਂ ਗਾਹਕ ਨੂੰ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਅਸੀਂ ਇਸਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਰੋਲ ਆਊਟ ਕਰਦੇ ਹਾਂ ਅਤੇ ਗੈਰ-ਸਪੱਸ਼ਟ ਸਥਿਤੀਆਂ ਨੂੰ ਫੜਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ। ਅਤੇ ਸਭ ਕਿਉਂਕਿ ਟੈਸਟ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਉਤਪਾਦਨ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ. ਇਹ ਇੱਕ ਨਵੀਂ ਕਿਸਮ ਦੀ ਜਾਂਚ ਵੱਲ ਖੜਦਾ ਹੈ - ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਜਾਂਚ. ਇਹਨਾਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਸੰਰਚਨਾਵਾਂ, ਸੈਟਿੰਗਾਂ, ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਆਦਿ ਸ਼ਾਮਲ ਹਨ।

ਇਹ ਸਵਾਲ ਪੈਦਾ ਕਰਦਾ ਹੈ - ਸ਼ਾਇਦ ਟੀਮ ਨੂੰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਕੋਡ ਵਜੋਂ ਵਰਤਣ ਦੀ ਲੋੜ ਹੈ.

ਮੇਰਾ ਮੰਨਣਾ ਹੈ ਕਿ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਉਤਪਾਦ ਦੀ ਗੁਣਵੱਤਾ ਨੂੰ ਸਿੱਧਾ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।

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

- ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਬਾਰੇ ਕੀ?

ਅਨਾਸਤਾਸੀਆ: ਇਹ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸਿਸਟਮਾਂ 'ਤੇ ਵਧੇਰੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਅਸੀਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਵਿਸ਼ਲੇਸ਼ਕ ਅਤੇ ਸਿਸਟਮ ਵਿਸ਼ਲੇਸ਼ਕ ਵਰਗੇ ਲੋਕ ਤੁਰੰਤ ਮਨ ਵਿੱਚ ਆਉਂਦੇ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਕਈ ਵਾਰ ਤਕਨੀਕੀ ਲੇਖਕ ਵੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਲਿਖਣ ਅਤੇ ਇਸਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਇੱਕ ਕੰਮ ਮਿਲਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਮਹੀਨੇ ਲਈ।

ਇਹ ਵਾਰ-ਵਾਰ ਸਾਬਤ ਹੋਇਆ ਹੈ ਕਿ ਅਜਿਹੇ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਲਿਖਣਾ ਬਹੁਤ ਲੰਬੇ ਵਿਕਾਸ ਦੁਹਰਾਓ ਅਤੇ ਸੁਧਾਰ ਦੇ ਲੰਬੇ ਦੁਹਰਾਓ ਵੱਲ ਅਗਵਾਈ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਟੈਸਟਿੰਗ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ਬੱਗ ਪਛਾਣੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਵਾਪਸੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਬਹੁਤ ਸਾਰੇ ਲੂਪ ਹਨ ਜੋ ਵਿਕਾਸ ਦੀ ਲਾਗਤ ਨੂੰ ਵਧਾਉਂਦੇ ਹਨ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਕਮਜ਼ੋਰੀਆਂ ਪੇਸ਼ ਕਰ ਸਕਦਾ ਹੈ। ਜਾਪਦਾ ਹੈ ਕਿ ਸਾਡੇ ਕੋਲ ਸੰਦਰਭ ਕੋਡ ਲਿਖਿਆ ਹੋਇਆ ਹੈ, ਪਰ ਫਿਰ ਅਸੀਂ ਅਜਿਹੀਆਂ ਤਬਦੀਲੀਆਂ ਕੀਤੀਆਂ ਜੋ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੋਚੇ-ਸਮਝੇ ਢਾਂਚੇ ਨੂੰ ਤੋੜਦੀਆਂ ਹਨ।

ਨਤੀਜੇ ਵਜੋਂ, ਨਤੀਜਾ ਬਹੁਤ ਉੱਚ-ਗੁਣਵੱਤਾ ਵਾਲਾ ਉਤਪਾਦ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਪੈਚ ਪਹਿਲਾਂ ਹੀ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋ ਚੁੱਕੇ ਹਨ, ਕੁਝ ਸਥਾਨਾਂ ਵਿੱਚ ਕੋਡ ਟੈਸਟਾਂ ਨਾਲ ਢੁਕਵੇਂ ਨਹੀਂ ਹਨ, ਕਿਉਂਕਿ ਸਮਾਂ-ਸੀਮਾ ਖਤਮ ਹੋ ਰਹੀ ਹੈ, ਸਾਰੇ ਬੱਗਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬੰਦ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਅਤੇ ਇਹ ਸਭ ਕਿਉਂਕਿ ਅਸਲ ਨਿਰਧਾਰਨ ਨੇ ਉਹਨਾਂ ਸਾਰੇ ਬਿੰਦੂਆਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖਿਆ ਜਿਨ੍ਹਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ.

ਡਿਵੈਲਪਰ ਕੀੜੇ ਨਹੀਂ ਹਨ ਅਤੇ ਜਾਣਬੁੱਝ ਕੇ ਗਲਤੀਆਂ ਨਾਲ ਕੋਡ ਨਹੀਂ ਲਿਖਦੇ ਹਨ।

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

ਸੰਪੂਰਣ 100-ਪੰਨਿਆਂ ਦੇ ਨਿਰਧਾਰਨ ਨੂੰ ਲਿਖਣਾ ਸੰਭਵ ਤੌਰ 'ਤੇ ਅਸੰਭਵ ਹੈ। ਇਸ ਕਰਕੇ ਦਸਤਾਵੇਜ਼ ਲਿਖਣ ਦੇ ਵਿਕਲਪਿਕ ਤਰੀਕਿਆਂ ਬਾਰੇ ਸੋਚਣ ਦੀ ਲੋੜ ਹੈ, ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਕਾਰਜ ਕਥਨ ਜੋ ਸਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੇ ਨੇੜੇ ਲਿਆਏਗਾ ਕਿ ਵਿਕਾਸਕਾਰ ਬਿਲਕੁਲ ਉਹੀ ਕਰਦਾ ਹੈ ਜਿਸਦੀ ਲੋੜ ਹੈ।

ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਚੁਸਤ ਪਹੁੰਚ ਮਨ ਵਿੱਚ ਆਉਂਦੀ ਹੈ - ਸਵੀਕ੍ਰਿਤੀ ਦੇ ਮਾਪਦੰਡ ਦੇ ਨਾਲ ਉਪਭੋਗਤਾ ਕਹਾਣੀਆਂ। ਇਹ ਉਹਨਾਂ ਟੀਮਾਂ ਲਈ ਵਧੇਰੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਜੋ ਛੋਟੀਆਂ ਦੁਹਰਾਅ ਵਿੱਚ ਵਿਕਸਤ ਹੁੰਦੀਆਂ ਹਨ।

- ਉਪਯੋਗਤਾ ਜਾਂਚ, ਉਤਪਾਦ ਉਪਯੋਗਤਾ, ਡਿਜ਼ਾਈਨ ਬਾਰੇ ਕੀ?

ਅਨਾਸਤਾਸੀਆ: ਇਹ ਇੱਕ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਨੁਕਤਾ ਹੈ, ਕਿਉਂਕਿ ਟੀਮ ਵਿੱਚ ਡਿਜ਼ਾਈਨਰ ਹਨ. ਬਹੁਤੇ ਅਕਸਰ, ਡਿਜ਼ਾਈਨਰਾਂ ਨੂੰ ਇੱਕ ਸੇਵਾ ਵਜੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ - ਜਾਂ ਤਾਂ ਇੱਕ ਡਿਜ਼ਾਈਨ ਵਿਭਾਗ ਦੁਆਰਾ ਜਾਂ ਇੱਕ ਆਊਟਸੋਰਸਡ ਡਿਜ਼ਾਈਨਰ ਦੁਆਰਾ। ਅਕਸਰ ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਿੱਥੇ ਇਹ ਲਗਦਾ ਹੈ ਕਿ ਡਿਜ਼ਾਈਨਰ ਨੇ ਉਤਪਾਦ ਵਿਗਿਆਨੀ ਦੀ ਗੱਲ ਸੁਣੀ ਅਤੇ ਉਹੀ ਕੀਤਾ ਜੋ ਉਹ ਸਮਝਦਾ ਹੈ. ਪਰ ਜਦੋਂ ਅਸੀਂ ਦੁਹਰਾਓ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਜੋ ਕੀਤਾ ਗਿਆ ਸੀ ਉਹ ਨਹੀਂ ਸੀ ਜਿਸਦੀ ਉਮੀਦ ਕੀਤੀ ਗਈ ਸੀ: ਡਿਜ਼ਾਇਨਰ ਕੁਝ ਭੁੱਲ ਗਿਆ, ਵਿਵਹਾਰ ਦੁਆਰਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਸੋਚਿਆ, ਕਿਉਂਕਿ ਉਹ ਟੀਮ ਵਿੱਚ ਨਹੀਂ ਸੀ ਅਤੇ ਸੰਦਰਭ ਵਿੱਚ ਨਹੀਂ ਸੀ, ਜਾਂ ਸਾਹਮਣੇ. -ਐਂਡ ਡਿਵੈਲਪਰ ਨੇ ਇਸ ਦੇ ਖਾਕੇ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਸਮਝਿਆ। ਇਸ ਵਿੱਚ ਕਈ ਦੁਹਰਾਓ ਲੱਗ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਡਿਜ਼ਾਇਨ ਬਾਰੇ ਫਰੰਟ-ਐਂਡ ਡਿਵੈਲਪਰ ਦੀ ਸਮਝ ਵਿੱਚ ਕੋਈ ਸਮੱਸਿਆ ਹੈ।

ਇਸ ਤੋਂ ਇਲਾਵਾ ਇੱਕ ਹੋਰ ਸਮੱਸਿਆ ਹੈ। ਡਿਜ਼ਾਈਨ ਸਿਸਟਮ ਹੁਣ ਪ੍ਰਸਿੱਧੀ ਪ੍ਰਾਪਤ ਕਰ ਰਹੇ ਹਨ. ਉਹ ਹਾਈਪ 'ਤੇ ਹਨ, ਪਰ ਉਨ੍ਹਾਂ ਤੋਂ ਲਾਭ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹਨ।

ਮੈਨੂੰ ਇਸ ਰਾਏ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਰਿਹਾ ਹੈ ਕਿ ਡਿਜ਼ਾਇਨ ਸਿਸਟਮ, ਇੱਕ ਪਾਸੇ, ਵਿਕਾਸ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦੇ ਹਨ, ਪਰ ਦੂਜੇ ਪਾਸੇ, ਉਹ ਇੰਟਰਫੇਸ 'ਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਪਾਬੰਦੀਆਂ ਲਾਉਂਦੇ ਹਨ.

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਉਹ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ ਬਣਾਉਂਦੇ ਜੋ ਕਲਾਇੰਟ ਚਾਹੁੰਦਾ ਹੈ, ਪਰ ਇੱਕ ਜੋ ਸਾਡੇ ਲਈ ਸੁਵਿਧਾਜਨਕ ਹੈ, ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਕੁਝ ਕਿਊਬ ਹਨ ਜਿਨ੍ਹਾਂ ਤੋਂ ਅਸੀਂ ਇਸਨੂੰ ਬਣਾ ਸਕਦੇ ਹਾਂ।

ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਧਿਆਨ ਦੇਣਾ ਅਤੇ ਇਹ ਸੋਚਣਾ ਮਹੱਤਵਪੂਰਣ ਹੈ ਕਿ ਕੀ ਡਿਜ਼ਾਈਨ ਦੇ ਕੰਮ ਨੂੰ ਸਰਲ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋਏ ਅਸੀਂ ਅਸਲ ਵਿੱਚ ਗਾਹਕ ਦੇ ਦਰਦ ਨੂੰ ਹੱਲ ਕਰ ਰਹੇ ਹਾਂ.

- ਕੁਆਲਿਟੀ ਐਸ਼ੋਰੈਂਸ ਨਾਲ ਸਬੰਧਤ ਬਹੁਤ ਸਾਰੇ ਵਿਸ਼ਿਆਂ ਦੀ ਹੈਰਾਨੀਜਨਕ ਗਿਣਤੀ ਹੈ। ਕੀ ਰੂਸ ਵਿਚ ਕੋਈ ਕਾਨਫਰੰਸ ਹੈ ਜਿੱਥੇ ਉਨ੍ਹਾਂ ਸਾਰਿਆਂ 'ਤੇ ਚਰਚਾ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ?

ਅਨਾਸਤਾਸੀਆ: ਟੈਸਟਿੰਗ 'ਤੇ ਸਭ ਤੋਂ ਪੁਰਾਣੀ ਕਾਨਫਰੰਸ ਹੈ, ਜੋ ਇਸ ਸਾਲ 25ਵੀਂ ਵਾਰ ਆਯੋਜਿਤ ਕੀਤੀ ਜਾਵੇਗੀ ਅਤੇ ਇਸ ਨੂੰ ਕੁਆਲਿਟੀ ਅਸ਼ੋਰੈਂਸ ਕਾਨਫਰੰਸ SQA ਡੇਜ਼ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਮੁੱਖ ਤੌਰ 'ਤੇ ਕਾਰਜਸ਼ੀਲ ਟੈਸਟਰਾਂ ਲਈ ਟੂਲਸ ਅਤੇ ਖਾਸ ਟੈਸਟਿੰਗ ਪਹੁੰਚਾਂ ਦੀ ਚਰਚਾ ਕਰਦਾ ਹੈ। ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇ, SQA ਡੇਜ਼ ਦੀਆਂ ਰਿਪੋਰਟਾਂ ਟੈਸਟਰਾਂ ਦੀ ਖੁਦ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਦੇ ਖੇਤਰ ਵਿੱਚ ਖਾਸ ਖੇਤਰਾਂ ਦੀ ਡੂੰਘਾਈ ਨਾਲ ਜਾਂਚ ਕਰਦੀਆਂ ਹਨ, ਪਰ ਗੁੰਝਲਦਾਰ ਗਤੀਵਿਧੀਆਂ ਦੀ ਨਹੀਂ।

ਇਹ ਵੱਖ-ਵੱਖ ਸਾਧਨਾਂ ਅਤੇ ਪਹੁੰਚਾਂ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਬਹੁਤ ਮਦਦ ਕਰਦਾ ਹੈ, ਡੇਟਾਬੇਸ, API, ਆਦਿ ਦੀ ਜਾਂਚ ਕਿਵੇਂ ਕਰਨੀ ਹੈ। ਪਰ ਇਸਦੇ ਨਾਲ ਹੀ, ਇੱਕ ਪਾਸੇ, ਇਹ ਇੱਕ ਬਿਹਤਰ ਉਤਪਾਦ ਦੀ ਸਿਰਜਣਾ ਵਿੱਚ ਸਿਰਫ ਟੈਸਟਿੰਗ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਤ ਨਹੀਂ ਕਰਦਾ. ਦੂਜੇ ਪਾਸੇ, ਟੈਸਟਰ ਉਤਪਾਦ ਦੇ ਗਲੋਬਲ ਟੀਚੇ ਅਤੇ ਇਸਦੇ ਵਪਾਰਕ ਹਿੱਸੇ ਬਾਰੇ ਸੋਚਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਵਧੇਰੇ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦੇ ਹਨ।

ਮੈਂ ਇੱਕ ਵੱਡਾ ਵਿਭਾਗ ਚਲਾਉਂਦਾ ਹਾਂ ਅਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਇੰਟਰਵਿਊਆਂ ਦਾ ਸੰਚਾਲਨ ਕਰਦਾ ਹਾਂ, ਜੋ ਅਸਲ ਵਿੱਚ ਸਮੁੱਚੇ ਉਦਯੋਗ ਦੀ ਸਥਿਤੀ ਬਾਰੇ ਸਮਝ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਸਾਡੇ ਮੁੰਡੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਕੋਲ ਜ਼ਿੰਮੇਵਾਰੀ ਦਾ ਇੱਕ ਸਪਸ਼ਟ ਖੇਤਰ ਹੈ. ਵਿਦੇਸ਼ੀ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲੇ ਸਹਿਕਰਮੀ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੇ ਟੈਸਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ: ਉਹ ਖੁਦ ਲੋਡ ਟੈਸਟਿੰਗ, ਪ੍ਰਦਰਸ਼ਨ ਟੈਸਟਿੰਗ, ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਕਈ ਵਾਰ ਸੁਰੱਖਿਆ ਜਾਂਚ ਵੀ ਕਰ ਸਕਦੇ ਹਨ, ਕਿਉਂਕਿ ਉਹ ਅਸਲ ਵਿੱਚ ਉਤਪਾਦ ਦੀ ਗੁਣਵੱਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਵਿੱਚ ਟੀਮ ਦੀ ਮਦਦ ਕਰਦੇ ਹਨ।

ਮੈਂ ਚਾਹਾਂਗਾ ਕਿ ਰੂਸ ਦੇ ਲੋਕ ਵੀ ਇਸ ਤੱਥ ਬਾਰੇ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕਰਨ ਕਿ ਉਦਯੋਗ ਕਾਰਜਸ਼ੀਲ ਟੈਸਟਿੰਗ ਨਾਲ ਖਤਮ ਨਹੀਂ ਹੁੰਦਾ।

— ਇਸ ਉਦੇਸ਼ ਲਈ, ਅਸੀਂ ਇੱਕ ਨਵੀਂ ਕਾਨਫਰੰਸ, QualityConf ਦਾ ਆਯੋਜਨ ਕਰ ਰਹੇ ਹਾਂ, ਜੋ ਇੱਕ ਅਟੁੱਟ ਅਨੁਸ਼ਾਸਨ ਵਜੋਂ ਗੁਣਵੱਤਾ ਨੂੰ ਸਮਰਪਿਤ ਹੈ। ਸਾਨੂੰ ਵਿਚਾਰ ਬਾਰੇ ਹੋਰ ਦੱਸੋ, ਕਾਨਫਰੰਸ ਦਾ ਮੁੱਖ ਟੀਚਾ ਕੀ ਹੈ?

ਅਨਾਸਤਾਸੀਆ: ਅਸੀਂ ਗੁਣਵੱਤਾ ਵਾਲੇ ਉਤਪਾਦ ਬਣਾਉਣ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਣ ਵਾਲੇ ਲੋਕਾਂ ਦਾ ਇੱਕ ਭਾਈਚਾਰਾ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਇੱਕ ਪਲੇਟਫਾਰਮ ਪੇਸ਼ ਕਰੋ ਜਿੱਥੇ ਉਹ ਆ ਸਕਦੇ ਹਨ, ਰਿਪੋਰਟਾਂ ਸੁਣ ਸਕਦੇ ਹਨ ਅਤੇ ਕਾਨਫਰੰਸ ਨੂੰ ਇੱਕ ਖਾਸ ਸਮਝ ਦੇ ਨਾਲ ਛੱਡ ਸਕਦੇ ਹਨ ਕਿ ਗੁਣਵੱਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ ਲਈ ਉਹਨਾਂ ਨੂੰ ਕੀ ਬਦਲਣ ਦੀ ਲੋੜ ਹੈ।

ਅੱਜ-ਕੱਲ੍ਹ ਮੈਂ ਅਕਸਰ ਇਸ ਬਾਰੇ ਸਲਾਹ-ਮਸ਼ਵਰਾ ਕਰਨ ਲਈ ਬੇਨਤੀ ਸੁਣਦਾ ਹਾਂ ਕਿ ਜਦੋਂ ਟੈਸਟਿੰਗ ਅਤੇ ਗੁਣਵੱਤਾ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਆਉਂਦੀਆਂ ਹਨ ਤਾਂ ਕੀ ਕਰਨਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਟੀਮਾਂ ਨਾਲ ਸੰਚਾਰ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ ਸਮੱਸਿਆ ਖੁਦ ਟੈਸਟਰਾਂ ਨਾਲ ਨਹੀਂ ਹੈ, ਪਰ ਪ੍ਰਕਿਰਿਆ ਦੇ ਢਾਂਚੇ ਦੇ ਤਰੀਕੇ ਨਾਲ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਡਿਵੈਲਪਰ ਮੰਨਦੇ ਹਨ ਕਿ ਉਹ ਸਿਰਫ ਕੋਡ ਲਿਖਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਉਸੇ ਸਮੇਂ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਉਹ ਕੰਮ ਨੂੰ ਟੈਸਟਿੰਗ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦੇ ਹਨ।

ਹਰ ਕੋਈ ਇਸ ਤੱਥ ਬਾਰੇ ਨਹੀਂ ਸੋਚਦਾ ਕਿ ਖਰਾਬ ਆਰਕੀਟੈਕਚਰ ਦੇ ਨਾਲ ਮਾੜੀ ਲਿਖਤ, ਘੱਟ-ਗੁਣਵੱਤਾ ਵਾਲਾ ਕੋਡ ਪ੍ਰੋਜੈਕਟ ਲਈ ਵੱਡੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਖਤਰਾ ਬਣਾਉਂਦਾ ਹੈ. ਉਹ ਗਲਤੀਆਂ ਦੀ ਲਾਗਤ ਬਾਰੇ ਨਹੀਂ ਸੋਚਦੇ, ਉਹ ਬੱਗ ਜੋ ਉਤਪਾਦਨ ਵਿੱਚ ਖਤਮ ਹੁੰਦੇ ਹਨ ਕੰਪਨੀ ਅਤੇ ਟੀਮ ਲਈ ਵੱਡੇ ਖਰਚੇ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੇ ਹਨ। ਇਸ ਬਾਰੇ ਸੋਚਣ ਦਾ ਕੋਈ ਸੱਭਿਆਚਾਰ ਨਹੀਂ ਹੈ। ਮੈਂ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਅਸੀਂ ਇਸ ਨੂੰ ਕਾਨਫਰੰਸ ਵਿਚ ਵੰਡਣਾ ਸ਼ੁਰੂ ਕਰੀਏ।

ਮੈਂ ਸਮਝਦਾ ਹਾਂ ਕਿ ਇਹ ਨਵੀਨਤਾ ਨਹੀਂ ਹੈ। ਗੁਣਵੱਤਾ ਦੇ 14 ਸਿਧਾਂਤਾਂ ਦੇ ਲੇਖਕ ਐਡਵਰਡ ਡੇਮਿੰਗ ਨੇ ਪਿਛਲੀ ਸਦੀ ਵਿੱਚ ਇੱਕ ਗਲਤੀ ਦੀ ਕੀਮਤ ਬਾਰੇ ਲਿਖਿਆ ਸੀ। ਇੱਕ ਅਨੁਸ਼ਾਸਨ ਵਜੋਂ ਗੁਣਵੱਤਾ ਦਾ ਭਰੋਸਾ ਇਸ ਕਿਤਾਬ 'ਤੇ ਅਧਾਰਤ ਹੈ, ਪਰ, ਬਦਕਿਸਮਤੀ ਨਾਲ, ਆਧੁਨਿਕ ਵਿਕਾਸ ਇਸ ਬਾਰੇ ਭੁੱਲ ਜਾਂਦਾ ਹੈ।

- ਕੀ ਤੁਸੀਂ ਟੈਸਟਿੰਗ ਅਤੇ ਟੂਲਸ ਬਾਰੇ ਸਿੱਧੇ ਵਿਸ਼ਿਆਂ 'ਤੇ ਛੂਹਣ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹੋ?

ਅਨਾਸਤਾਸੀਆ: ਮੈਂ ਮੰਨਦਾ ਹਾਂ ਕਿ ਸਾਧਨਾਂ ਬਾਰੇ ਰਿਪੋਰਟਾਂ ਹੋਣਗੀਆਂ। ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਵਿਆਪਕ ਸਾਧਨ ਹਨ ਜਿਨ੍ਹਾਂ ਨਾਲ ਕੰਪਨੀਆਂ ਅਤੇ ਟੀਮਾਂ ਉਤਪਾਦ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰ ਸਕਦੀਆਂ ਹਨ.

ਸਾਰੀਆਂ ਰਿਪੋਰਟਾਂ ਇੱਕ ਸਾਂਝੇ ਮਿਸ਼ਨ ਦੁਆਰਾ ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ ਇੱਕਜੁੱਟ ਹੋਣਗੀਆਂ: ਦਰਸ਼ਕਾਂ ਨੂੰ ਇਹ ਦੱਸਣ ਲਈ ਕਿ ਇਸ ਪਹੁੰਚ, ਸਾਧਨ, ਵਿਧੀ, ਪ੍ਰਕਿਰਿਆ, ਟੈਸਟਿੰਗ ਦੀ ਕਿਸਮ ਦੀ ਮਦਦ ਨਾਲ, ਅਸੀਂ ਉਤਪਾਦ ਦੀ ਗੁਣਵੱਤਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ ਹੈ ਅਤੇ ਗਾਹਕ ਦੇ ਜੀਵਨ ਵਿੱਚ ਸੁਧਾਰ ਕੀਤਾ ਹੈ।

ਸਾਡੇ ਕੋਲ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਕਿਸੇ ਟੂਲ ਦੀ ਖ਼ਾਤਰ ਕਿਸੇ ਟੂਲ ਬਾਰੇ ਰਿਪੋਰਟਾਂ ਨਹੀਂ ਹੋਣਗੀਆਂ। ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਸ਼ਾਮਲ ਸਾਰੀਆਂ ਰਿਪੋਰਟਾਂ ਇੱਕ ਸਾਂਝੇ ਟੀਚੇ ਦੁਆਰਾ ਇਕਜੁੱਟ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ।

- ਤੁਸੀਂ ਕਿਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹੋ, ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਕਾਨਫਰੰਸ ਦੇ ਮਹਿਮਾਨ ਵਜੋਂ ਦੇਖਦੇ ਹੋ, ਇਸ ਵਿੱਚ ਕੌਣ ਦਿਲਚਸਪੀ ਰੱਖਦਾ ਹੈ?

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

ਇਹ ਉਹ ਲੋਕ ਹਨ ਜੋ ਹੈਰਾਨ ਹੁੰਦੇ ਹਨ ਕਿ ਕਿਸੇ ਉਤਪਾਦ ਜਾਂ ਪ੍ਰਣਾਲੀ ਦੀ ਗੁਣਵੱਤਾ ਨੂੰ ਕਿਵੇਂ ਸੁਧਾਰਿਆ ਜਾਵੇ। ਸਾਡੀ ਕਾਨਫਰੰਸ ਵਿੱਚ, ਉਹ ਉਪਾਵਾਂ ਦੇ ਵੱਖ-ਵੱਖ ਸੈੱਟਾਂ ਬਾਰੇ ਸਿੱਖਣਗੇ ਅਤੇ ਇਹ ਸਮਝਣ ਦੇ ਯੋਗ ਹੋਣਗੇ ਕਿ ਹੁਣ ਉਹਨਾਂ ਵਿੱਚ ਕੀ ਗਲਤ ਹੈ ਅਤੇ ਕੀ ਬਦਲਣ ਦੀ ਲੋੜ ਹੈ।

ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਮੁੱਖ ਮਾਪਦੰਡ ਇਹ ਸਮਝਣਾ ਹੈ ਕਿ ਗੁਣਵੱਤਾ ਵਿੱਚ ਕੁਝ ਗਲਤ ਹੈ ਅਤੇ ਇਸਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ. ਅਸੀਂ ਸ਼ਾਇਦ ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਾਂਗੇ ਜੋ ਸੋਚਦੇ ਹਨ ਕਿ ਅਜਿਹਾ ਪਹਿਲੀ ਵਾਰ ਹੋਵੇਗਾ।

- ਕੀ ਤੁਹਾਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਉਦਯੋਗ ਸਿਰਫ ਟੈਸਟਿੰਗ ਬਾਰੇ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਗੁਣਵੱਤਾ ਦੇ ਸੱਭਿਆਚਾਰ ਬਾਰੇ ਗੱਲ ਕਰਨ ਲਈ ਤਿਆਰ ਹੈ?

ਅਨਾਸਤਾਸੀਆ: ਮੇਰਾ ਮੰਨਣਾ ਹੈ ਕਿ ਮੈਂ ਪਰਿਪੱਕ ਹੋ ਗਿਆ ਹਾਂ। ਹੁਣ ਬਹੁਤ ਸਾਰੀਆਂ ਕੰਪਨੀਆਂ ਐਜੀਲ ਵੱਲ ਰਵਾਇਤੀ ਵਾਟਰਫਾਲ ਪਹੁੰਚ ਤੋਂ ਦੂਰ ਜਾ ਰਹੀਆਂ ਹਨ। ਕਲਾਇੰਟ 'ਤੇ ਫੋਕਸ ਹੈ, ਟੀਮਾਂ ਦੇ ਲੋਕ ਸੱਚਮੁੱਚ ਇਸ ਬਾਰੇ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹਨ ਕਿ ਗੁਣਵੱਤਾ ਉਤਪਾਦ ਕਿਵੇਂ ਬਣਾਉਣਾ ਹੈ. ਇੱਥੋਂ ਤੱਕ ਕਿ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਕੰਪਨੀਆਂ ਗੁਣਵੱਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ 'ਤੇ ਮੁੜ ਕੇਂਦ੍ਰਤ ਕਰ ਰਹੀਆਂ ਹਨ।

ਕਮਿਊਨਿਟੀ ਵਿੱਚ ਪੈਦਾ ਹੋਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਦੇ ਆਧਾਰ ਤੇ, ਮੈਂ ਵਿਸ਼ਵਾਸ ਕਰਦਾ ਹਾਂ ਕਿ ਇਹ ਸਮਾਂ ਹੈ. ਬੇਸ਼ੱਕ, ਮੈਨੂੰ ਯਕੀਨ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਇੱਕ ਵੱਡੇ ਪੈਮਾਨੇ ਦੀ ਕ੍ਰਾਂਤੀ ਹੋਵੇਗੀ, ਪਰ ਮੈਂ ਚੇਤਨਾ ਵਿੱਚ ਇਹ ਇਨਕਲਾਬ ਹੋਣਾ ਚਾਹਾਂਗਾ।

- ਸਹਿਮਤ! ਅਸੀਂ ਸੱਭਿਆਚਾਰ ਪੈਦਾ ਕਰਾਂਗੇ ਅਤੇ ਚੇਤਨਾ ਬਦਲਾਂਗੇ।

ਆਈਟੀ ਉਤਪਾਦਾਂ ਦੇ ਉੱਚ-ਗੁਣਵੱਤਾ ਦੇ ਵਿਕਾਸ 'ਤੇ ਕਾਨਫਰੰਸ QualityConf ਸਥਾਨ ਲਿਆ ਜਾਵੇਗਾ ਮਾਸਕੋ ਵਿੱਚ 7 ​​ਜੂਨ ਨੂੰ. ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਕਿਹੜੇ ਪੜਾਅ ਇੱਕ ਉੱਚ-ਗੁਣਵੱਤਾ ਉਤਪਾਦ ਬਣਾਉਂਦੇ ਹਨ, ਸਾਡੇ ਕੋਲ ਉਤਪਾਦਨ ਵਿੱਚ ਸਫਲਤਾਪੂਰਵਕ ਬੱਗਾਂ ਦਾ ਮੁਕਾਬਲਾ ਕਰਨ ਦੇ ਮਾਮਲੇ ਹਨ, ਅਸੀਂ ਆਪਣੇ ਅਭਿਆਸ ਵਿੱਚ ਪ੍ਰਸਿੱਧ ਤਰੀਕਿਆਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਹੈ - ਸਾਨੂੰ ਤੁਹਾਡੇ ਅਨੁਭਵ ਦੀ ਲੋੜ ਹੈ। ਭੇਜੋ ਆਪਣੇ 1 ਮਈ ਤੱਕ ਅਰਜ਼ੀਆਂ, ਅਤੇ ਪ੍ਰੋਗਰਾਮ ਕਮੇਟੀ ਕਾਨਫਰੰਸ ਦੀ ਸਮੁੱਚੀ ਅਖੰਡਤਾ ਲਈ ਥੀਮ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗੀ।

ਨਾਲ ਜੁੜੋ ਗੱਲਬਾਤ, ਜਿਸ ਵਿੱਚ ਅਸੀਂ ਗੁਣਵੱਤਾ ਦੇ ਮੁੱਦਿਆਂ ਅਤੇ ਕਾਨਫਰੰਸ ਬਾਰੇ ਚਰਚਾ ਕਰਦੇ ਹਾਂ, ਦੀ ਗਾਹਕੀ ਲੈਂਦੇ ਹਾਂ ਟੈਲੀਗ੍ਰਾਮ ਚੈਨਲਪ੍ਰੋਗਰਾਮ ਦੀਆਂ ਖ਼ਬਰਾਂ ਨਾਲ ਅਪ ਟੂ ਡੇਟ ਰੱਖਣ ਲਈ.

ਸਰੋਤ: www.habr.com