ਇੱਕ ਵੈੱਬ-ਅਧਾਰਤ ਡਿਜ਼ਾਈਨ ਟੂਲ 'ਤੇ ਚੱਲ ਰਹੇ AI-ਸੰਚਾਲਿਤ QA ਨੇ ਰਿਪੋਰਟ ਕੀਤੀ “ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਕੰਮ ਕਰ ਰਹੀਆਂ ਹਨ, ਪਾਸ,” ਫਿਰ ਵੀ ਕੈਨਵਸ 'ਤੇ ਕੁਝ ਵੀ ਦਿਖਾਈ ਨਹੀਂ ਦਿੱਤਾ। ਇਹ ਗਲਤ ਪਾਸ (false pass) ਮਾਡਲ ਦੇ ਤਰਕ ਵਿੱਚ ਕੋਈ ਗਲਤੀ ਨਹੀਂ ਸੀ; ਇਹ ਇਸ ਗੱਲ ਦਾ ਇੱਕ ਸਾਈਡ-ਇਫੈਕਟ ਸੀ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਨੇ ਲੁਕਵੇਂ ਟੈਬਸ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਿਆ ਅਤੇ ਟੈਸਟ ਸਕ੍ਰਿਪਟ ਨੇ ਵਿਜ਼ੂਅਲ ਆਉਟਪੁੱਟ ਦੀ ਬਜਾਏ “health” ਨੂੰ ਕਿਵੇਂ ਮਾਪਿਆ।
AI QA ਏਜੰਟ ਇੱਕ ਖਾਲੀ ਕੈਨਵਸ ਨੂੰ ਕਿਉਂ miss ਕਰ ਸਕਦੇ ਹਨ
ਉਹ JavaScript ਚਲਾਉਂਦੇ ਹਨ, ਸਕ੍ਰੀਨਸ਼ੌਟ ਲੈਂਦੇ ਹਨ, ਅਤੇ ਮਾਡਲ ਨੂੰ ਇਹ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦਿੰਦੇ ਹਨ ਕਿ ਕੀ ਕੋਈ ਫੀਚਰ ਸਹੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਅਸਲ ਵਿੱਚ, ਦੋ ਤਕਨੀਕੀ ਕਮੀਆਂ ਵਾਰ-ਵਾਰ ਉਦੋਂ 'ਪਾਸ' ਦਿਖਾਉਂਦੀਆਂ ਹਨ ਜਦੋਂ UI ਅਸਲ ਵਿੱਚ ਖਾਲੀ ਹੁੰਦਾ ਹੈ।
Hidden-tab throttling ਦੀ ਵਿਆਖਿਆ
Chrome MCP ਅਕਸਰ ਮੁੱਖ ਵਿੰਡੋ ਨੂੰ ਹੋਰ ਕੰਮਾਂ ਲਈ ਖਾਲੀ ਰੱਖਣ ਲਈ ਬੈਕਗ੍ਰਾਊਂਡ ਟੈਬਸ ਵਿੱਚ ਟੈਸਟ ਚਲਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਕਿਸੇ ਟੈਬ ਦੀ document.visibilityState hidden ਹੁੰਦੀ ਹੈ, ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਰੈਂਡਰਿੰਗ ਪਾਈਪਲਾਈਨ ਨੂੰ ਥ੍ਰੌਟਲ (throttle) ਕਰ ਦਿੰਦਾ ਹੈ:
- JavaScript ਚੱਲਦੀ ਰਹਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਕੋਈ runtime errors ਨਹੀਂ ਆਉਂਦੇ।
requestAnimationFrameਕਾਲਬੈਕਸ (callbacks) ਚੱਲਣਾ ਬੰਦ ਹੋ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਐਨੀਮੇਸ਼ਨ ਫਰੇਮ ਦੀ ਗਿਣਤੀ ਜ਼ੀਰੋ ਰਹਿ ਜਾਂਦੀ ਹੈ।- ਟਾਈਮਰ ਬਹੁਤ ਘੱਟ ਵਾਰ ਚੱਲਦੇ ਹਨ; ਇੱਕ ਟੈਸਟ ਜਿਸ ਨੇ 33 ms ਦੇ ਅੰਤਰਲ ਦੀ ਉਮੀਦ ਕੀਤੀ ਸੀ, ਉਸਨੇ ਸਿਰਫ਼ ਚਾਰ ਵਾਰ ਹੀ ਦੇਖਿਆ।
AI ਏਜੰਟ ਸਾਫ਼ JS ਨਤੀਜੇ ਅਤੇ ਇੱਕ ਸਕ੍ਰੀਨਸ਼ੌਟ ਦੇਖਦਾ ਹੈ, ਅਤੇ ਮੰਨ ਲੈਂਦਾ ਹੈ ਕਿ ਐਨੀਮੇਸ਼ਨ ਕੰਮ ਕਰ ਰਹੀ ਸੀ। ਕਿਉਂਕਿ ਰੈਂਡਰਿੰਗ ਲੂਪ ਨੇ ਕਦੇ ਵੀ ਪਿਕਸਲ ਪੈਦਾ ਨਹੀਂ ਕੀਤੇ, ਵਿਜ਼ੂਅਲ 결 (defect) ਲੁਕਿਆ ਰਹਿੰਦਾ ਹੈ।
Hidden-tab ਸਮੱਸਿਆਵਾਂ ਲਈ ਹੱਲ
- ਕਿਸੇ ਵੀ ਕੈਨਵਸ, ਐਨੀਮੇਸ਼ਨ, ਜਾਂ ਗ੍ਰਾਫਿਕਸ ਵੈਰੀਫਿਕੇਸ਼ਨ ਲਈ ਟੈਸਟ ਟੈਬ ਨੂੰ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ (visible) ਰੱਖੋ।
- ਇੰਟਰੈਕਸ਼ਨਾਂ ਨੂੰ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਟ੍ਰਿਗਰ ਕਰੋ ਜਦੋਂ ਟੈਬ ਫੋਰਗ੍ਰਾਊਂਡ (foreground) ਵਿੱਚ ਹੋਵੇ।
- ਸਕ੍ਰੀਨਸ਼ੌਟ ਲੈਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਇੰਤਜ਼ਾਰ (ਕੁਝ ਸਕਿੰਟ) ਸ਼ਾਮਲ ਕਰੋ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਫਰੇਮ ਬਫਰ ਭਰ ਗਿਆ ਹੈ।
- ਜੇਕਰ ਲੁਕਵੇਂ ਟੈਬ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਹੀ ਪਵੇ, ਤਾਂ ਰਿਪੋਰਟ ਦੇ ਨਾਲ ਇੱਕ ਡਿਸਕਲੇਮਰ ਜੋੜੋ ਜਿਵੇਂ ਕਿ “rendering not visually observed.”
Code health ਬਨਾਮ feature behavior
ਜ਼ਿਆਦਾਤਰ AI QA ਸਕ੍ਰਿਪਟਾਂ “code health” ਦਾ ਮੁਲਾਂਕਣ ਕਰਦੀਆਂ ਹਨ: ਉਹ ਪੁਸ਼ਟੀ ਕਰਦੀਆਂ ਹਨ ਕਿ click handlers ਜੁੜੇ ਹੋਏ ਹਨ, ਕੋਈ JavaScript exceptions ਨਹੀਂ ਆਏ ਹਨ, ਅਤੇ ਲੋੜੀਂਦੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਲੋਡ ਹੋ ਗਈਆਂ ਹਨ। ਉਹ ਸੰਕੇਤ ਸਾਬਤ ਕਰਦੇ ਹਨ ਕਿ ਕੋਡ ਚੱਲਿਆ ਹੈ, ਨਾ ਕਿ ਇਹ ਕਿ UI ਉਮੀਦ ਅਨੁਸਾਰ ਬਦਲਿਆ ਹੈ। ਇੱਕ ਕੈਨਵਸ ਐਲੀਮੈਂਟ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਡਰਾਇੰਗ ਰੁਟੀਨ ਨੂੰ ਕਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਵੀ ਕੁਝ ਵੀ ਰੈਂਡਰ ਨਹੀਂ ਹੁੰਦਾ ਜੇਕਰ ਡਰਾਇੰਗ ਕਮਾਂਡਾਂ ਜ਼ੀਰੋ-ਸਾਈਜ਼ ਬਫਰ ਜਾਂ ਖਾਲੀ ਐਸੇਟ (asset) ਨੂੰ ਟਾਰਗੇਟ ਕਰਦੀਆਂ ਹਨ।
ਇਹ ਅੰਤਰ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇੱਕ ਸਿਹਤਮੰਦ ਕੋਡ ਪਾਥ (code path) ਇੱਕ ਗੁੰਮ ਹੋਏ ਵਿਜ਼ੂਅਲ ਆਰਟੀਫੈਕਟ (visual artifact) ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ।
Behavior ਚੈੱਕਸ ਜੋੜਨਾ
- ਡਾਇਨਾਮਿਕ ਐਲੀਮੈਂਟਸ ਦੀ ਪਛਾਣ ਕਰੋ – ਕੈਨਵਸ ਟੈਗਸ, file-input ਫੀਲਡਸ, ਡਾਊਨਲੋਡ ਬਟਨਾਂ ਅਤੇ ਐਨੀਮੇਸ਼ਨ ਲੂਪਸ ਲਈ ਸੋਰਸ ਦੀ ਜਾਂਚ ਕਰੋ।
- ਨਿਰੀਖਣਯੋਗ ਨਤੀਜੇ (observable outcomes) ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ – ਕੈਨਵਸ ਲਈ, ਇੱਕ ਪਿਕਸਲ-ਲੇਵਲ ਚੈੱਕ ਦੀ ਲੋੜ ਹੈ ਕਿ ਬਿਟਮੈਪ ਖਾਲੀ ਨਹੀਂ ਹੈ। ਫਾਈਲ ਇਨਪੁਟ ਲਈ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪ੍ਰੀਵਿਊ ਇਮੇਜ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ। ਡਾਊਨਲੋਡ ਲਈ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਫਾਈਲ ਸਿਸਟਮ 'ਤੇ ਬਣ ਗਈ ਹੈ। ਐਨੀਮੇਸ਼ਨਾਂ ਲਈ, ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇੱਕ ਟ੍ਰੈਕ ਕੀਤੀ ਗਈ ਪ੍ਰਾਪਰਟੀ ਸਮੇਂ ਦੇ ਨਾਲ ਬਦਲਦੀ ਹੈ।
- ਕਵਰੇਜ ਦੀ ਰਿਪੋਰਟ ਕਰੋ – QA ਆਉਟਪੁੱਟ ਦੇ ਨਾਲ ਇੱਕ ਟੇਬਲ ਲਗਾਓ ਜਿਸ ਵਿੱਚ ਹਰੇਕ ਫੀਚਰ, ਕੋਡ-ਹੈਲਥ ਸਟੇਟਸ, ਅਤੇ ਵਿਵਹਾਰ ਵੈਰੀਫਿਕੇਸ਼ਨ (behavior verification) ਨਤੀਜੇ ਦੀ ਸੂਚੀ ਹੋਵੇ। ਜਿਸ ਵਿੱਚ ਵੀ ਵਿਵਹਾਰ ਚੈੱਕ ਦੀ ਕਮੀ ਹੈ, ਉਸ ਨੂੰ “pass” ਦੀ ਬਜਾਏ “unverified” ਵਜੋਂ ਰੱਖਿਆ ਜਾਵੇਗਾ।
ਇਸ ਨਿਯਮ ਨੂੰ ਲਾਗੂ ਕਰਨ ਨਾਲ ਲੇਖਕ ਦੇ ਟੈਸਟ ਸੁਇਟ ਵਿੱਚ ਫਾਲਸ ਪੋਜ਼ੀਟਿਵਜ਼ (false positives) ਵਿੱਚ ਭਾਰੀ ਕਮੀ ਆਈ ਅਤੇ CSS ਮਿਸਮੈਚ ਵੀ ਸਾਹਮਣੇ ਆਏ ਜਿੱਥੇ ਸਟਾਈਲਸ਼ੀਟ ਨੇ ਇੱਕ ਰੰਗ ਐਲਾਨਿਆ ਸੀ ਪਰ ਰੈਂਡਰ ਕੀਤਾ ਗਿਆ ਪਿਕਸਲ ਵੱਖਰਾ ਸੀ।
ਭਰੋਸੇਯੋਗ ਵਿਜ਼ੂਅਲ ਟੈਸਟਿੰਗ ਲਈ ਵਿਵਹਾਰਕ ਕਦਮ
- ਟੈਸਟ ਇੱਕ ਦਿਖਾਈ ਦੇਣ ਵਾਲੇ ਟੈਬ ਵਿੱਚ ਚਲਾਓ ਜਦੋਂ ਵੀ ਫੀਚਰ ਵਿੱਚ ਰੈਂਡਰਿੰਗ ਸ਼ਾਮਲ ਹੋਵੇ।
- UI ਦੇ ਸੈਟਲ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰੋ; ਕੁਝ ਸਕਿੰਟਾਂ ਦੀ ਫਿਕਸਡ ਡਿਲੇਅ ਅਕਸਰ ਕਾਫੀ ਹੁੰਦੀ ਹੈ, ਪਰ ਇੱਕ ਵਧੇਰੇ ਮਜ਼ਬੂਤ ਤਰੀਕਾ
getImageDataਦੀ ਵਰਤੋਂ ਕਰਕੇ ਗੈਰ-ਖਾਲੀ ਕੈਨਵਸ ਲਈ ਪੋਲ (poll) ਕਰਨਾ ਹੈ। - ਟੈਸਟ ਸਕ੍ਰਿਪਟ ਵਿੱਚ code-health ਐਸਰਸ਼ਨਾਂ (assertions) ਨੂੰ ਵਿਜ਼ੂਅਲ ਐਸਰਸ਼ਨਾਂ ਤੋਂ ਵੱਖ ਕਰੋ; AI ਮਾਡਲ ਨੂੰ ਹਰੇਕ ਦਾ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਮੁਲਾਂਕਣ ਕਰਨ ਦਿਓ।
- ਡਾਇਗਨੌਸਟਿਕ ਆਉਟਪੁੱਟ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਵਿਜ਼ਿਬਿਲਟੀ ਸਟੇਟ ਅਤੇ ਫਰੇਮ ਕਾਊਂਟਰ (
requestAnimationFrameਕਾਲਸ) ਨੂੰ ਲੌਗ (log) ਕਰੋ। - ਕਿਸੇ ਵੀ ਅਟੱਲ ਲੁਕਵੇਂ-ਟੈ