𝗧𝗵𝗲 𝗧𝗲𝘀𝘁𝗲𝗿 𝗪𝗶𝘁𝗵 𝟭𝟬 𝗖𝗲𝗿𝘁𝘀 𝗪𝗵𝗼 𝗖𝗼𝘂𝗹𝗱𝗻'𝘁 𝗙𝗶𝗻𝗱 𝗮 𝗕𝘂𝗴
ਤੁਹਾਡੇ ਕੋਲ ਹਰ ਤਰ੍ਹਾਂ ਦੇ ਸਰਟੀਫਿਕੇਟ ਹਨ। ISTQB, ScrumMaster, Cloud, ਅਤੇ Security। ਤੁਹਾਡਾ ਰੈਜ਼ਿਊਮੇ (resume) ਸੰਖੇਪ ਰੂਪਾਂ (acronyms) ਦੀ ਇੱਕ ਕੰਧ ਵਰਗਾ ਹੈ।
ਪਰ ਤੁਸੀਂ ਇੱਕ ਵੀ ਅਜਿਹਾ ਟੈਸਟ ਨਹੀਂ ਲਿਖ ਸਕਦੇ ਜੋ ਅਸਲ ਵਿੱਚ ਕੋਈ ਬੱਗ (bug) ਲੱਭ ਸਕੇ।
ਮੈਂ ਪਿਛਲੀ ਤਿਮਾਹੀ ਵਿੱਚ ਇੱਕ ਉਮੀਦਵਾਰ ਦਾ ਇੰਟਰਵਿਊ ਲਿਆ। ਉਹ ਸਿਰਫ਼ ਸਿਧਾਂਤਾਂ (theory) ਦੀ ਗੱਲ ਕਰ ਰਹੇ ਸਨ। ਉਨ੍ਹਾਂ ਨੇ V-model ਅਤੇ shift-left ਦਾ ਜ਼ਿਕਰ ਕੀਤਾ। ਜਦੋਂ ਮੈਂ ਉਨ੍ਹਾਂ ਨੂੰ ਉਹ ਇੱਕ ਟੈਸਟ ਦਿਖਾਉਣ ਲਈ ਕਿਹਾ ਜੋ ਉਨ੍ਹਾਂ ਨੇ ਲਿਖਿਆ ਸੀ ਅਤੇ ਜਿਸ ਨਾਲ ਕੋਈ ਬੱਗ ਫੜਿਆ ਗਿਆ ਸੀ, ਤਾਂ ਉਹ ਚੁੱਪ ਰਹਿ ਗਏ।
ਉਨ੍ਹਾਂ ਨੇ ਕਦੇ ਵੀ ਅਜਿਹਾ ਟੈਸਟ ਨਹੀਂ ਲਿਖਿਆ ਸੀ ਜਿਸ ਨਾਲ ਕੁਝ ਟੁੱਟਿਆ (break) ਹੋਵੇ। ਉਹ ਸਿਰਫ਼ ਉਹ ਟੈਸਟ ਲਿਖਦੇ ਸਨ ਜੋ ਪਾਸ (pass) ਹੋ ਜਾਂਦੇ ਸਨ।
ਸਰਟੀਫਿਕੇਸ਼ਨ ਤੁਹਾਡੀ ਯਾਦਦਾਸ਼ਤ ਦੀ ਪਰਖ ਕਰਦੇ ਹਨ। ਬੱਗ ਤੁਹਾਡੀ ਸੋਚ ਦੀ ਪਰਖ ਕਰਦੇ ਹਨ।
ਸਰਟੀਫਿਕੇਸ਼ਨ ਤੁਹਾਨੂੰ ਸ਼ਬਦਾਵਲੀ ਅਤੇ ਢਾਂਚਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਉਹ ਤੁਹਾਨੂੰ ਰਿਕਰੂਟਰਾਂ ਦੀ ਸਕ੍ਰੀਨਿੰਗ ਪਾਸ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ। ਉਹ ਤੁਹਾਨੂੰ ਖ਼ਾਮੀਆਂ (defects) ਲੱਭਣਾ ਨਹੀਂ ਸਿਖਾਉਂਦੇ।
ਪ੍ਰੀਖਿਆ ਦੇ ਸਵਾਲ ਇੱਕ ਸਿਲੇਬਸ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ। ਅਸਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨਹੀਂ ਕਰਦੀਆਂ। ਇੱਕ ਲੌਗਇਨ ਫਾਰਮ ਦਾ ਕੋਈ ਸਿਲੇਬਸ ਨਹੀਂ ਹੁੰਦਾ। ਇਸ ਵਿੱਚ ਅਜੀਬ 'ਐਜ ਕੇਸ' (edge cases) ਹੁੰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਸਰਵਰ ਕਲਾਕ ਦਾ ਚਾਰ ਮਿੰਟ ਪਿੱਛੇ ਹੋਣਾ ਜਾਂ ਸਮੇਂ ਨਾਲ ਸਬੰਧਤ ਖਾਸ ਸਮੱਸਿਆਵਾਂ।
ਸਰਟੀਫਾਈਡ ਟੈਸਟਰ ਇੱਕ ਚੈੱਕਲਿਸਟ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ। ਉਹ ਲੋੜਾਂ (requirements) ਦੇ ਅਧਾਰ 'ਤੇ ਟੈਸਟ ਲਿਖਦੇ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਪਾਸ ਜਾਂ ਫੇਲ ਵਜੋਂ ਮਾਰਕ ਕਰਦੇ ਹਨ।
ਬੱਗ ਹੰਟਰ (bug hunter) ਟੈਸਟਿੰਗ ਨੂੰ ਇੱਕ ਜਾਂਚ ਵਾਂਗ ਮੰਨਦਾ ਹੈ। ਉਹ ਇੱਕ ਪਰਿਕਲਪਨਾ (hypothesis) ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ। ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਗਲਤ ਸਾਬਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ।
ਮਾਨਸਿਕਤਾ (mindset) ਵਿੱਚ ਅੰਤਰ ਦੇਖੋ।
ਇੱਕ ਸਟੈਂਡਰਡ ਟੈਸਟ 'ਹੈਪੀ ਪਾਥ' (happy path) ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ:
- ਉਤਪਾਦਾਂ (products) 'ਤੇ ਜਾਓ।
- ਕਾਰਟ ਵਿੱਚ ਜੋੜੋ।
- ਵੈਧ ਕਾਰਡ ਵੇਰਵੇ ਭਰੋ।
- ਆਰਡਰ ਦੀ ਪੁਸ਼ਟੀ ਦੀ ਉਮੀਦ ਕਰੋ।
ਇਹ ਟੈਸਟ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਫੀਚਰ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਸਭ ਕੁਝ ਸਹੀ ਹੁੰਦਾ ਹੈ। ਇਹ ਕਦੇ ਵੀ ਬੱਗ ਨਹੀਂ ਲੱਭ ਸਕੇਗਾ।
ਇੱਕ ਬੱਗ ਹੰਟਰ ਟੈਸਟ ਸ਼ੱਕੀ ਹੁੰਦਾ ਹੈ:
- ਟਾਈਪੋ (typo) ਦੇ ਨਾਲ ਕਾਰਡ ਨੰਬਰ ਭਰੋ।
- ਐਰਰ ਮੈਸੇਜ (error message) ਦੀ ਉਮੀਦ ਕਰੋ।
- ਚੈੱਕ ਕਰੋ ਕਿ ਆਰਡਰ ਦੀ ਪੁਸ਼ਟੀ ਫਿਰ ਵੀ ਨਾ ਦਿਖਾਈ ਦਿੱਤੀ ਹੋਵੇ।
ਦੂਜਾ ਟੈਸਟ ਇਹ ਮੰਨ ਕੇ ਚੱਲਦਾ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਫੇਲ ਹੋ ਜਾਵੇਗੀ। ਇਹ ਪੁੱਛਦਾ ਹੈ: "ਇਹ ਕਿੱਥੇ ਟੁੱਟਦਾ ਹੈ?"
ਬਹੁਤ ਸਾਰੇ ਟੈਸਟਰਾਂ ਦੇ ਤਜ਼ਰਬੇ ਵਿੱਚ ਕਮੀ ਹੁੰਦੀ ਹੈ, ਨਾ ਕਿ ਉਨ੍ਹਾਂ ਦੇ ਰੈਜ਼ਿਊਮੇ ਵਿੱਚ। ਤੁਸੀਂ ਗਲਤ ਡੇਟਾ ਜਾਂ ਡਾਊਨ ਵਾਤਾਵਰਣ (environments) ਕਾਰਨ ਟੈਸਟ ਫੇਲ ਹੁੰਦੇ ਦੇਖੇ ਹਨ। ਤੁਸੀਂ ਟੈਸਟ ਇਸ ਲਈ ਫੇਲ ਹੁੰਦੇ ਨਹੀਂ ਦੇਖੇ ਕਿਉਂਕਿ ਤੁਸੀਂ ਲੌਜਿਕ (logic) ਵਿੱਚ ਕੋਈ ਖਾਮੀ ਲੱਭੀ ਸੀ।
ਨਵੀਆਂ ਪ੍ਰੀਖਿਆਵਾਂ ਦੀ ਤਿਆਰੀ ਕਰਨਾ ਬੰਦ ਕਰੋ। ਫੇਲ ਹੋਣ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਟੈਸਟ ਲਿਖ ਕੇ ਇਸ ਕਮੀ ਨੂੰ ਦੂਰ ਕਰੋ।
ਇਸ ਅਭਿਆਸ ਨੂੰ ਅਜ਼ਮਾਓ: ਇੱਕ ਫੀਚਰ ਚੁਣੋ। ਇਸ ਨੂੰ ਤੋੜਨ (break ਕਰਨ) ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵਿੱਚ ਇੱਕ ਘੰਟਾ ਬਿਤਾਓ।
ਇੱਕ ਸਰਚ ਫੀਚਰ ਲਈ:
- ਅਰਥਹੀਣ (gibberish) ਕੁਐਰੀਆਂ ਦਾ ਟੈਸਟ ਕਰੋ।
- SQL ਇੰਜੈਕਸ਼ਨ (injection) ਅੱਖਰਾਂ ਦਾ ਟੈਸਟ ਕਰੋ।
- ਖਾਲੀ ਸਟ੍ਰਿੰਗਾਂ (empty strings) ਦਾ ਟੈਸਟ ਕਰੋ।
ਇੱਕ ਫਾਈਲ ਅਪਲੋਡ ਲਈ:
- ਬਿਨਾਂ ਐਕਸਟੈਂਸ਼ਨ (extensions) ਵਾਲੀਆਂ ਫਾਈਲਾਂ ਦਾ ਟੈਸਟ ਕਰੋ।
- ਬਹੁਤ ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਦੇ ਸਾਈਜ਼ ਦਾ ਟੈਸਟ ਕਰੋ।
- ਮਾਲੀਸ਼ੀਅਸ (malicious) ਫਾਈਲ ਨਾਮਾਂ ਦਾ ਟੈਸਟ ਕਰੋ।
ਮੈਂ ਇੱਕ ਵਾਰ 95% ਕਵਰੇਜ ਵਾਲੇ ਇੱਕ ਪੇਮੈਂਟ ਸਿਸਟਮ 'ਤੇ ਕੰਮ ਕੀਤਾ ਸੀ। ਹਰ ਟੈਸਟ ਪਾਸ ਹੋ ਗਿਆ ਸੀ। ਫਿਰ, ਰੌਂਡਿੰਗ ਐਰਰ (rounding error) ਕਾਰਨ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਸਿਸਟਮ ਦਾ ਪੈਸਾ ਨੁਕਸਾਨ ਹੋ ਗਿਆ। ਸਾਡੇ ਟੈਸਟਾਂ ਨੇ 'ਹੈਪੀ ਪਾਥ' (happy path) ਨੂੰ ਕਵਰ ਕੀਤਾ ਸੀ, ਪਰ ਕਿਸੇ ਨੇ ਵੀ ਮੈਥ ਲੌਜਿਕ (math logic) ਨੂੰ ਟੈਸਟ ਕਰਨ ਬਾਰੇ ਨਹੀਂ ਸੋਚਿਆ।
ਹੁਣ, ਮੈਂ ਹਰ ਟੈਸਟ ਇੱਕ ਸਵਾਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦਾ ਹਾਂ: "ਇਸ ਫੀਚਰ ਦੇ ਚੁੱਪਚਾਪ ਫੇਲ ਹੋਣ ਲਈ ਕੀ ਹੋਣਾ ਜ਼ਰੂਰੀ ਹੈ?"
ਕੋਈ ਪੋਰਟਫੋਲੀਓ ਸਾਈਟ ਨਾ ਬਣਾਓ। ਆਪਣਾ LinkedIn ਅਪਡੇਟ ਨਾ ਕਰੋ।
ਇੱਕ ਅਜਿਹਾ ਟੈਸਟ ਲਿਖੋ ਜੋ ਫੇਲ ਹੋਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੋਵੇ। ਜੇਕਰ ਇਹ ਪਾਸ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਸੁਰੱਖਿਆ ਦੀ ਗਾਰੰਟੀ ਹੈ। ਜੇਕਰ ਇਹ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਬੱਗ (bug) ਮਿਲ ਗਿਆ ਹੈ।
ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਕੀ ਟੈਸਟ ਕੀਤਾ, ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਟੈਸਟ ਕੀਤਾ, ਅਤੇ ਤੁਹਾਨੂੰ ਕੀ ਮਿਲਿਆ। ਇਹ ਅਸਲੀ ਸਬੂਤ ਹੈ ਕਿ ਤੁਸੀਂ ਸੋਚ ਸਕਦੇ ਹੋ।
ਇਸ ਹਫ਼ਤੇ ਤੁਸੀਂ ਇਹ ਸਾਬਤ ਕਰਨ ਲਈ ਕਿ ਤੁਸੀਂ ਬੱਗ ਲੱਭ ਸਕਦੇ ਹੋ, ਕਿਹੜਾ ਇੱਕ ਟੈਸਟ ਲਿਖੋਗੇ?
Optional learning community: https://t.me/GyaanSetuAi