ਅਸੀਂ ਟੈਸਟਰਾਂ ਲਈ ਹੈਕਾਥਨ ਕਿਉਂ ਆਯੋਜਿਤ ਕੀਤਾ?

ਇਹ ਲੇਖ ਉਹਨਾਂ ਲਈ ਦਿਲਚਸਪੀ ਵਾਲਾ ਹੋਵੇਗਾ ਜੋ, ਸਾਡੇ ਵਾਂਗ, ਟੈਸਟਿੰਗ ਦੇ ਖੇਤਰ ਵਿੱਚ ਇੱਕ ਢੁਕਵੇਂ ਮਾਹਰ ਦੀ ਚੋਣ ਕਰਨ ਦੀ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰ ਰਹੇ ਹਨ.

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

ਮੈਂ ਸਾਰੀਆਂ IT ਕੰਪਨੀਆਂ ਲਈ ਗੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਪਰ ਅਸੀਂ QA/QC ਦੀ ਭੂਮਿਕਾ ਆਪਣੇ ਗੁਣਵੱਤਾ ਮਾਹਰਾਂ ਨੂੰ ਸੌਂਪੀ ਹੈ। ਉਹ ਵਿਕਾਸ ਟੀਮ ਦਾ ਹਿੱਸਾ ਹਨ ਅਤੇ ਖੋਜ ਤੋਂ ਲੈ ਕੇ ਇੱਕ ਨਵੇਂ ਸੰਸਕਰਣ ਨੂੰ ਜਾਰੀ ਕਰਨ ਤੱਕ, ਵਿਕਾਸ ਦੇ ਸਾਰੇ ਪੜਾਵਾਂ ਵਿੱਚ ਹਿੱਸਾ ਲੈਂਦੇ ਹਨ।

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

ਟੈਸਟਰਾਂ ਦੀ ਭਾਲ ਕਰਦੇ ਸਮੇਂ ਸਾਨੂੰ ਕੀ ਮਿਲਿਆ

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

ਅੱਗੇ, ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗਾ ਕਿ ਗੁਣਵੱਤਾ ਲਈ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਉਡੀਕ ਰਹੇ ਲੜਾਕਿਆਂ ਨੂੰ ਲੱਭਣ ਲਈ ਅਸੀਂ ਕਿਹੜੇ ਕਦਮ ਚੁੱਕੇ ਅਤੇ ਕਿਹੜੀਆਂ ਗਲਤੀਆਂ ਕੀਤੀਆਂ।

ਅਸੀਂ ਸਥਿਤੀ ਨੂੰ ਕਿਵੇਂ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ

ਸੋਰਸਿੰਗ ਤਿਆਰ ਮਾਹਿਰਾਂ ਨਾਲ ਥੱਕ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਨੇੜਲੇ ਖੇਤਰਾਂ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕੀਤਾ:

1. ਅਸੀਂ ਬਹੁਤ ਸਾਰੇ "ਛੱਡੋ-ਇਸ" ਲੋਕਾਂ ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਮੁਲਾਂਕਣ ਅਭਿਆਸਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਜਿਨ੍ਹਾਂ ਤੋਂ ਅਸੀਂ ਮਜ਼ਬੂਤ ​​ਮਾਹਰ ਵਿਕਸਿਤ ਕਰ ਸਕਦੇ ਹਾਂ।

   ਅਸੀਂ ਲਗਭਗ ਇੱਕੋ ਪੱਧਰ ਦੇ ਗਿਆਨ ਵਾਲੇ ਸੰਭਾਵੀ ਉਮੀਦਵਾਰਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਨੂੰ ਕਾਰਜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਕਿਹਾ। ਉਨ੍ਹਾਂ ਦੀ ਵਿਚਾਰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਦੇਖਦੇ ਹੋਏ, ਅਸੀਂ ਸਭ ਤੋਂ ਹੋਨਹਾਰ ਉਮੀਦਵਾਰ ਦੀ ਪਛਾਣ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ।

   ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਧਿਆਨ ਦੇਣ, ਤਕਨਾਲੋਜੀ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਦੀ ਸਮਝ ਅਤੇ ਬਹੁ-ਸੱਭਿਆਚਾਰਵਾਦ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਪਰਖਣ ਲਈ ਕੰਮ ਲੈ ਕੇ ਆਏ ਹਾਂ:

   
   

2. ਅਸੀਂ ਮੌਜੂਦਾ ਦਲ ਦੇ ਵਿਚਕਾਰ ਪੇਸ਼ੇ ਦੀ ਸਮਝ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਵਧਾਉਣ ਲਈ ਟੈਸਟਰਾਂ ਲਈ ਮੀਟਿੰਗਾਂ ਕੀਤੀਆਂ।

   ਮੈਂ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਬਾਰੇ ਥੋੜਾ ਜਿਹਾ ਦੱਸਾਂਗਾ.

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

   
   
   ਫਿਰ, 1-2 ਮਹੀਨਿਆਂ ਦੇ ਅੰਤਰਾਲ ਨਾਲ, ਅਸੀਂ ਦੋ ਹੋਰ ਮੁਲਾਕਾਤਾਂ ਕੀਤੀਆਂ। ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਦੁੱਗਣੇ ਭਾਗੀਦਾਰ ਸਨ। "Ufa ਸੌਫਟਵੇਅਰ QA ਅਤੇ ਟੈਸਟਿੰਗ ਮੀਟਅੱਪ #2" 'ਤੇ ਅਸੀਂ ਵਿਸ਼ੇ ਦੇ ਖੇਤਰ ਵਿੱਚ ਡੂੰਘੇ ਗਏ। ਉਹਨਾਂ ਨੇ ਬੱਗ ਟਰੈਕਿੰਗ ਪ੍ਰਣਾਲੀਆਂ, UI/UX ਟੈਸਟਿੰਗ, ਡੌਕਰ, Ansible ਨੂੰ ਛੂਹਣ ਬਾਰੇ ਗੱਲ ਕੀਤੀ, ਅਤੇ ਇੱਕ ਡਿਵੈਲਪਰ ਅਤੇ ਇੱਕ ਟੈਸਟਰ ਵਿਚਕਾਰ ਸੰਭਾਵੀ ਟਕਰਾਅ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੇ ਤਰੀਕਿਆਂ ਬਾਰੇ ਵੀ ਗੱਲ ਕੀਤੀ।

   ਸਾਡੀ ਤੀਜੀ ਮੀਟਿੰਗ, "Ufa ਸੌਫਟਵੇਅਰ QA ਅਤੇ ਟੈਸਟਿੰਗ ਮੀਟਿੰਗ #3," ਅਸਿੱਧੇ ਤੌਰ 'ਤੇ ਟੈਸਟਰਾਂ ਦੇ ਕੰਮ ਨਾਲ ਸਬੰਧਤ ਹੈ, ਪਰ ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਦੇ ਤਕਨੀਕੀ ਅਤੇ ਸੰਗਠਨਾਤਮਕ ਕਰਤੱਵਾਂ ਦੀ ਸਮੇਂ ਸਿਰ ਯਾਦ ਦਿਵਾਉਣ ਵਿੱਚ ਉਪਯੋਗੀ ਸੀ: ਲੋਡ ਟੈਸਟਿੰਗ, e2e ਟੈਸਟਿੰਗ, ਆਟੋਟੈਸਟਿੰਗ ਵਿੱਚ ਸੇਲੇਨਿਅਮ, ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਕਮਜ਼ੋਰੀਆਂ। .

   ਇਸ ਸਾਰੇ ਸਮੇਂ ਤੋਂ ਅਸੀਂ ਸਿੱਖ ਰਹੇ ਹਾਂ ਕਿ ਸਾਡੇ ਸਮਾਗਮਾਂ ਤੋਂ ਪ੍ਰਸਾਰਣ ਵਿੱਚ ਸਾਧਾਰਨ ਰੋਸ਼ਨੀ ਅਤੇ ਆਵਾਜ਼ ਕਿਵੇਂ ਬਣਾਉਣੀ ਹੈ:

   → ਟੈਸਟਿੰਗ ਵਿੱਚ ਪਹਿਲੇ ਕਦਮ - Ufa ਸੌਫਟਵੇਅਰ QA ਅਤੇ ਟੈਸਟਿੰਗ ਮੀਟਿੰਗ #1
   → UI/UX ਟੈਸਟਿੰਗ - Ufa ਸਾਫਟਵੇਅਰ QA ਅਤੇ ਟੈਸਟਿੰਗ ਮੀਟਿੰਗ #2
   → ਸੁਰੱਖਿਆ ਟੈਸਟਿੰਗ, ਲੋਡ ਟੈਸਟਿੰਗ ਅਤੇ ਆਟੋ ਟੈਸਟਿੰਗ - Ufa QA ਅਤੇ ਟੈਸਟਿੰਗ ਮੀਟਿੰਗ #3

3. ਅਤੇ ਅੰਤ ਵਿੱਚ ਅਸੀਂ ਟੈਸਟਰਾਂ ਲਈ ਇੱਕ ਹੈਕਾਥਨ ਆਯੋਜਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ

ਅਸੀਂ ਟੈਸਟਰਾਂ ਲਈ ਇੱਕ ਹੈਕਾਥਨ ਕਿਵੇਂ ਤਿਆਰ ਕੀਤਾ ਅਤੇ ਆਯੋਜਿਤ ਕੀਤਾ

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

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

ਅਸੀਂ ਭਾਗੀਦਾਰਾਂ ਦੀ ਸੰਭਾਵੀ ਸੰਖਿਆ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਇਆ ਅਤੇ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਸਾਨੂੰ MVP ਰੀਲੀਜ਼ਾਂ, 5 ਉਤਪਾਦਾਂ ਅਤੇ 5 ਲੋਕਾਂ ਲਈ ਘੱਟੋ-ਘੱਟ 5 ਬੈਕਲਾਗਾਂ ਦੀ ਲੋੜ ਹੈ ਜੋ ਉਤਪਾਦ ਮਾਲਕਾਂ ਵਜੋਂ ਕੰਮ ਕਰਨਗੇ, ਵਪਾਰਕ ਲੋੜਾਂ ਨੂੰ ਸਮਝਣਗੇ ਅਤੇ ਪਾਬੰਦੀਆਂ 'ਤੇ ਫੈਸਲੇ ਲੈਣਗੇ।

ਇੱਥੇ ਸਾਨੂੰ ਕੀ ਮਿਲਿਆ ਹੈ: ਹੈਕਾਥਨ ਲਈ ਬੈਕਲਾਗ.

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

ਅਸੀਂ ਕਿਹੜੀਆਂ ਗ਼ਲਤੀਆਂ ਕੀਤੀਆਂ ਅਤੇ ਅਸੀਂ ਇਸ ਤੋਂ ਵਧੀਆ ਕੀ ਕਰ ਸਕਦੇ ਹਾਂ?

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

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

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

ਘਟਨਾ ਦੇ ਨਤੀਜਿਆਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਸਾਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਅਸੀਂ ਬਹੁਤ ਸਾਰੀਆਂ ਗਲਤੀਆਂ ਕੀਤੀਆਂ ਹਨ:

1. ਸਭ ਤੋਂ ਮਾਫੀਯੋਗ ਗਲਤੀ ਇਹ ਮੰਨਣਾ ਸੀ ਕਿ ਸਾਡੇ ਲਈ 4-5 ਘੰਟੇ ਕਾਫੀ ਹੋਣਗੇ। ਨਤੀਜੇ ਵਜੋਂ, ਬੈਕਲਾਗ ਨਾਲ ਜਾਣ-ਪਛਾਣ ਅਤੇ ਜਾਣ-ਪਛਾਣ ਵਿੱਚ ਲਗਭਗ 2 ਘੰਟੇ ਲੱਗ ਗਏ।
   ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ 'ਤੇ ਉਤਪਾਦ ਦੇ ਮਾਲਕਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਅਤੇ ਵਿਸ਼ਾ ਖੇਤਰ ਵਿੱਚ ਗੋਤਾਖੋਰੀ ਕਰਨ ਲਈ ਸਮਾਂ ਦੀ ਸਮਾਨ ਮਾਤਰਾ ਲਈ ਗਈ। ਇਸ ਲਈ ਬਾਕੀ ਸਮਾਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਟੈਸਟਿੰਗ ਨਕਸ਼ਿਆਂ ਦੇ ਵਿਆਪਕ ਵਿਕਾਸ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ ਸੀ।
2. ਹਰੇਕ ਨਕਸ਼ੇ 'ਤੇ ਵਿਸਤ੍ਰਿਤ ਫੀਡਬੈਕ ਲਈ ਕਾਫ਼ੀ ਸਮਾਂ ਅਤੇ ਊਰਜਾ ਨਹੀਂ ਸੀ, ਕਿਉਂਕਿ ਇਹ ਪਹਿਲਾਂ ਹੀ ਰਾਤ ਸੀ। ਇਸ ਲਈ, ਅਸੀਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇਸ ਹਿੱਸੇ ਨੂੰ ਅਸਫਲ ਕਰ ਦਿੱਤਾ, ਪਰ ਸ਼ੁਰੂ ਵਿੱਚ ਹੈਕਾਥਨ ਵਿੱਚ ਸਭ ਤੋਂ ਕੀਮਤੀ ਹੋਣ ਦਾ ਇਰਾਦਾ ਸੀ.
3. ਅਸੀਂ ਸਾਰੇ ਭਾਗੀਦਾਰਾਂ ਦੀ ਇੱਕ ਸਧਾਰਨ ਵੋਟ ਦੁਆਰਾ ਵਿਕਾਸ ਦੀ ਗੁਣਵੱਤਾ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਹਰੇਕ ਟੀਮ ਲਈ 3 ਵੋਟਾਂ ਨਿਰਧਾਰਤ ਕੀਤੀਆਂ, ਜੋ ਉਹ ਉੱਚ ਗੁਣਵੱਤਾ ਵਾਲੇ ਕੰਮ ਲਈ ਦੇ ਸਕਦੀਆਂ ਹਨ। ਸ਼ਾਇਦ ਜਿਊਰੀ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨਾ ਬਿਹਤਰ ਹੋਵੇਗਾ.

ਤੁਸੀਂ ਕੀ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ?

ਅਸੀਂ ਆਪਣੀ ਸਮੱਸਿਆ ਨੂੰ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਹੱਲ ਕਰ ਲਿਆ ਹੈ ਅਤੇ ਹੁਣ ਸਾਡੇ ਕੋਲ 4 ਬਹਾਦਰ, ਸੁੰਦਰ ਆਦਮੀ ਸਾਡੇ ਲਈ ਕੰਮ ਕਰ ਰਹੇ ਹਨ, 4 ਵਿਕਾਸ ਟੀਮਾਂ ਦੇ ਪਿਛਲੇ ਹਿੱਸੇ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ. ਸੰਭਾਵੀ ਮਜ਼ਬੂਤ ​​ਉਮੀਦਵਾਰਾਂ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਪੂਲ ਅਤੇ ਸ਼ਹਿਰ ਦੇ QA ਕਮਿਊਨਿਟੀ ਦੇ ਪੱਧਰ ਵਿੱਚ ਠੋਸ ਤਬਦੀਲੀਆਂ ਨੂੰ ਅਜੇ ਤੱਕ ਦੇਖਿਆ ਨਹੀਂ ਗਿਆ ਹੈ। ਪਰ ਕੁਝ ਤਰੱਕੀ ਹੋਈ ਹੈ ਅਤੇ ਇਹ ਖੁਸ਼ੀ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਸਰੋਤ: www.habr.com