ವೆಬ್ ಆಧಾರಿತ ಡಿಸೈನ್ ಟೂಲ್ನಲ್ಲಿ ನಡೆಸಿದ AI-ಚಾಲಿತ QA, “ಎಲ್ಲಾ ಫೀಚರ್ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆ, ಪಾಸು” ಎಂದು ವರದಿ ಮಾಡಿತು, ಆದರೂ ಕ್ಯಾನ್ವಾಸ್ನಲ್ಲಿ ಏನೂ ಕಾಣಿಸಲಿಲ್ಲ. ಈ ತಪ್ಪು ಪಾಸು (false pass) ಮಾಡೆಲ್ನ ತರ್ಕದಲ್ಲಿನ ದೋಷವಾಗಿರಲಿಲ್ಲ; ಬದಲಾಗಿ ಬ್ರೌಸರ್ ಅಡಗಿರುವ ಟ್ಯಾಬ್ಗಳನ್ನು (hidden tabs) ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಟೆಸ್ಟ್ ಸ್ಕ್ರಿಪ್ಟ್ ದೃಶ್ಯಾವಳಿ ಫಲಿತಾಂಶದ (visual output) ಬದಲಿಗೆ “ಹೆಲ್ತ್” ಅನ್ನು ಹೇಗೆ ಅಳೆಯುತ್ತದೆ ಎಂಬುವುದರ ಪರಿಣಾಮವಾಗಿತ್ತು.
AI QA ಏಜೆಂಟ್ಗಳು ಖಾಲಿ ಕ್ಯಾನ್ವಾಸ್ ಅನ್ನು ಏಕೆ ಗುರುತಿಸಲು ಸಾಧ್ಯವಾಗದಿರಬಹುದು
ಅವುಗಳು JavaScript ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತವೆ, ಸ್ಕ್ರೀನ್ಶಾಟ್ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಫೀಚರ್ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿದೆಯೇ ಎಂದು ಮಾಡೆಲ್ ಮೂಲಕ ನಿರ್ಧರಿಸುತ್ತವೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, UI ವಾಸ್ತವವಾಗಿ ಖಾಲಿಯಿದ್ದಾಗ ಸಹ, ಎರಡು ತಾಂತ್ರಿಕ ಅಂಧತಾಣಗಳು (blind spots) ಪದೇ ಪದೇ ಪಾಸು ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತವೆ.
ಅಡಗಿರುವ ಟ್ಯಾಬ್ ಥ್ರೊಟಲಿಂಗ್ (Hidden-tab throttling) ವಿವರಣೆ
ಮುಖ್ಯ ವಿಂಡೋವನ್ನು ಇತರ ಕೆಲಸಗಳಿಗಾಗಿ ಮುಕ್ತವಾಗಿಡಲು Chrome MCP ಹೆಚ್ಚಾಗಿ ಹಿನ್ನೆಲೆ ಟ್ಯಾಬ್ಗಳಲ್ಲಿ (background tabs) ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುತ್ತದೆ. ಟ್ಯಾಬ್ನ document.visibilityState hidden ಆಗಿದ್ದಾಗ, ಬ್ರೌಸರ್ ರೆಂಡರಿಂಗ್ ಪೈಪ್ಲೈನ್ ಅನ್ನು ಥ್ರೊಟಲ್ ಮಾಡುತ್ತದೆ:
- JavaScript ಕಾರ್ಯನಿರ್ವಹಣೆಯನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ ರನ್ಟೈಮ್ ದೋಷಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ.
requestAnimationFrameಕಾಲ್ಬ್ಯಾಕ್ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ, ಇದರಿಂದ ಅನಿಮೇಷನ್ ಫ್ರೇಮ್ ಕೌಂಟ್ ಶೂನ್ಯದಲ್ಲಿ ಉಳಿಯುತ್ತದೆ.- ಟೈಮರ್ಗಳು ಬಹಳ ಕಡಿಮೆ ಬಾರಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ; 33 ms ಅಂತರವನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತಿದ್ದ ಪರೀಕ್ಷೆಯು ಕೇವಲ ನಾಲ್ಕು ಬಾರಿ ಮಾತ್ರ ಗಮನಿಸುತ್ತದೆ.
AI ಏಜೆಂಟ್ ಸ್ವಚ್ಛವಾದ JS ಫಲಿತಾಂಶಗಳನ್ನು ಮತ್ತು ಸ್ಕ್ರೀನ್ಶಾಟ್ ಅನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಅನಿಮೇಷನ್ ಕೆಲಸ ಮಾಡಿದೆ ಎಂದು ಭಾವಿಸುತ್ತದೆ. ರೆಂಡರಿಂಗ್ ಲೂಪ್ ಎಂದಿಗೂ ಪಿಕ್ಸೆಲ್ಗಳನ್ನು ಉತ್ಪಾದಿಸದ ಕಾರಣ, ದೃಶ್ಯ ದೋಷವು (visual defect) ಅಡಗಿದೆಯೇ ಇರುತ್ತದೆ.
ಅಡಗಿರುವ ಟ್ಯಾಬ್ ಸಮಸ್ಯೆಗಳಿಗೆ ಪರಿಹಾರಗಳು
- ಯಾವುದೇ ಕ್ಯಾನ್ವಾಸ್, ಅನಿಮೇಷನ್ ಅಥವಾ ಗ್ರಾಫಿಕ್ಸ್ ಪರಿಶೀಲನೆಗಾಗಿ ಟೆಸ್ಟ್ ಟ್ಯಾಬ್ ಅನ್ನು ದೃಶ್ಯಾವಳಿಗಳಲ್ಲಿ (visible) ಇರಿಸಿ.
- ಟ್ಯಾಬ್ ಫೋರ್ಗ್ರೌಂಡ್ನಲ್ಲಿರುವ ನಂತರವಷ್ಟೇ ಇಂಟರಾಕ್ಷನ್ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿ.
- ಸ್ಕ್ರೀನ್ಶಾಟ್ ತೆಗೆದುಕೊಳ್ಳುವ ಮೊದಲು ಸ್ವಲ್ಪ ಸಮಯದ ವಿರಾಮವನ್ನು (ಕೆಲವೇ ಸೆಕೆಂಡುಗಳು) ನೀಡಿ, ಇದರಿಂದ ಫ್ರೇಮ್ ಬಫರ್ ತುಂಬಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
- ಅಡಗಿರುವ ಟ್ಯಾಬ್ ಅನ್ನು ಬಳಸಲೇಬೇಕಾದ ಸಂದರ್ಭದಲ್ಲಿ, ವರದಿಯ ಆರಂಭದಲ್ಲಿ “rendering not visually observed” ಎಂಬಂತಹ ಡಿಸ್ಕ್ಲೈಮರ್ ಅನ್ನು ಸೇರಿಸಿ.
ಕೋಡ್ ಹೆಲ್ತ್ vs. ಫೀಚರ್ ವರ್ತನೆ (Code health vs. feature behavior)
ಹೆಚ್ಚಿನ AI QA ಸ್ಕ್ರಿಪ್ಟ್ಗಳು “ಕೋಡ್ ಹೆಲ್ತ್” ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತವೆ: ಕ್ಲಿಕ್ ಹ್ಯಾಂಡ್ಲರ್ಗಳು ಸರಿಯಾಗಿ ಜೋಡಿಸಲ್ಪಟ್ಟಿವೆ, ಯಾವುದೇ JavaScript ಎಕ್ಸೆಪ್ಶನ್ಗಳು ಉಂಟಾಗಿಲ್ಲ ಮತ್ತು ಅಗತ್ಯವಿರುವ ಲೈಬ್ರರಿಗಳು ಲೋಡ್ ಆಗಿವೆ ಎಂಬುದನ್ನು ಅವು ಖಚಿತಪಡಿಸುತ್ತವೆ. ಈ ಸಂಕೇತಗಳು ಕೋಡ್ ರನ್ ಆಗಿದೆ ಎಂಬುದನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ, ಆದರೆ UI ಉದ್ದೇಶಿತವಾಗಿ ಬದಲಾಗಿದೆ ಎಂಬುದನ್ನು ಅಲ್ಲ. ಡ್ರಾಯಿಂಗ್ ಕಮಾಂಡ್ಗಳು ಶೂನ್ಯ-ಅಳತೆಯ ಬಫರ್ ಅಥವಾ ಖಾಲಿ ಅಸೆಟ್ ಅನ್ನು ಗುರಿಯಾಗಿಸಿಕೊಂಡಿದ್ದರೆ, ಕ್ಯಾನ್ವಾಸ್ ಎಲಿಮೆಂಟ್ ಅನ್ನು ರಚಿಸಬಹುದು, ಡ್ರಾಯಿಂಗ್ ರೂಟೀನ್ ಅನ್ನು ಕರೆಯಬಹುದು ಮತ್ತು ಆದರೂ ಏನನ್ನೂ ರೆಂಡರ್ ಮಾಡದಿರಬಹುದು.
ಈ ವ್ಯತ್ಯಾಸವು ಮುಖ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ ಆರೋಗ್ಯಕರವಾದ ಕೋಡ್ ಪಾತ್ (healthy code path) ಕಾಣೆಯಾದ ದೃಶ್ಯ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಅನ್ನು ಮರೆಮಾಚಬಹುದು.
ವರ್ತನೆ ಪರಿಶೀಲನೆಗಳನ್ನು (behavior checks) ಸೇರಿಸುವುದು
- ಡೈನಾಮಿಕ್ ಎಲಿಮೆಂಟ್ಗಳನ್ನು ಗುರುತಿಸಿ – ಕ್ಯಾನ್ವಾಸ್ ಟ್ಯಾಗ್ಗಳು, ಫೈಲ್-ಇನ್ಪುಟ್ ಫೀಲ್ಡ್ಗಳು, ಡೌನ್ಲೋಡ್ ಬಟನ್ಗಳು ಮತ್ತು ಅನಿಮೇಷನ್ ಲೂಪ್ಗಳಿಗಾಗಿ ಸೋರ್ಸ್ ಅನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಿ.
- ಗಮನಿಸಬಹುದಾದ ಫಲಿತಾಂಶಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ – ಕ್ಯಾನ್ವಾಸ್ ಆಗಿದ್ದರೆ, ಬಿಟ್ಮ್ಯಾಪ್ ಖಾಲಿ ಇಲ್ಲ ಎಂದು ಪಿಕ್ಸೆಲ್-ಮಟ್ಟದ ಪರಿಶೀಲನೆಯನ್ನು ಕೇಳಿ. ಫೈಲ್ ಇನ್ಪುಟ್ ಆಗಿದ್ದರೆ, ಪ್ರಿವ್ಯೂ ಇಮೇಜ್ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಡೌನ್ಲೋಡ್ ಆಗಿದ್ದರೆ, ಫೈಲ್ಸಿಸ್ಟಮ್ನಲ್ಲಿ ಫೈಲ್ ರಚನೆಯಾಗಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಅನಿಮೇಷನ್ಗಳಿಗಾಗಿ, ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾದ ಪ್ರಾಪರ್ಟಿ ಕಾಲಾನಂತರದಲ್ಲಿ ಬದಲಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
- ಕವರೇಜ್ ವರದಿ ಮಾಡಿ – ಪ್ರತಿ ಫೀಚರ್, ಕೋಡ್-ಹೆಲ್ತ್ ಸ್ಥಿತಿ ಮತ್ತು ವರ್ತನೆ ಪರಿಶೀಲನೆಯ ಫಲಿತಾಂಶವನ್ನು ಪಟ್ಟಿ ಮಾಡುವ ಕೋಷ್ಟಕವನ್ನು QA ಔಟ್ಪುಟ್ಗೆ ಲಗತ್ತಿಸಿ. ವರ್ತನೆ ಪರಿಶೀಲನೆ ಇಲ್ಲದ ಯಾವುದೇ ವಿಷಯವು “pass” ಬದಲಿಗೆ “unverified” ಎಂದು ಉಳಿಯುತ್ತದೆ.
ಈ ನಿಯಮವನ್ನು ಅನ್ವಯಿಸುವುದರಿಂದ ಲೇಖಕರ ಟೆಸ್ಟ್ ಸೂಟ್ನಲ್ಲಿ ಫಾಲ್ಸ್ ಪಾಸಿಟಿವ್ಗಳು (false positives) ಗಣನೀಯವಾಗಿ ಕಡಿಮೆಯಾದವು ಮತ್ತು ಸ್ಟೈಲ್ಶೀಟ್ ಒಂದು ಬಣ್ಣವನ್ನು ಘೋಷಿಸಿದರೂ ರೆಂಡರ್ ಆದ ಪಿಕ್ಸೆಲ್ ವಿಭಿನ್ನವಾಗಿದ್ದಲ್ಲಿನ CSS ಮಿಸ್ಮ್ಯಾಚ್ಗಳನ್ನು ಸಹ ಇದು ಬಹಿರಂಗಪಡಿಸಿತು.
ವಿಶ್ವಾಸಾರ್ಹ ದೃಶ್ಯ ಪರೀಕ್ಷೆಗಾಗಿ ಪ್ರಾಯೋಗಿಕ ಹಂತಗಳು
- ಫೀಚರ್ ರೆಂಡರಿಂಗ್ ಅನ್ನು ಒಳಗೊಂಡಿದ್ದರೆ ಯಾವಾಗಲೂ ಟೆಸ್ಟ್ ಅನ್ನು ದೃಶ್ಯಾವಳಿ ಟ್ಯಾಬ್ನಲ್ಲಿ (visible tab) ರನ್ ಮಾಡಿ.
- UI ಸ್ಥಿರವಾಗುವವರೆಗೆ ಕಾಯಿರಿ; ಕೆಲವು ಸೆಕೆಂಡುಗಳ ನಿಗದಿತ ವಿಳಂಬವು ಸಾಕಾಗಬಹುದು, ಆದರೆ
getImageDataಬಳಸಿ ಖಾಲಿ ಇಲ್ಲದ ಕ್ಯಾನ್ವಾಸ್ಗಾಗಿ ಪೋಲ್ (poll) ಮಾಡುವುದು ಹೆಚ್ಚು ದೃಢವಾದ ವಿಧಾನವಾಗಿದೆ. - ಟೆಸ್ಟ್ ಸ್ಕ್ರಿಪ್ಟ್ನಲ್ಲಿ ಕೋಡ್-ಹೆಲ್ತ್ ಅಸರ್ಷನ್ಗಳನ್ನು ದೃಶ್ಯ ಅಸರ್ಷನ್ಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ; AI ಮಾಡೆಲ್ ಪ್ರತಿಯೊಂದನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಬಿಡಿ.
- ರೋಗನಿರ್ಣಯದ ಔಟ್ಪುಟ್ನ (diagnostic output) ಭಾಗವಾಗಿ ದೃಶ್ಯಾವಳಿ ಸ್ಥಿತಿ ಮತ್ತು ಫ್ರೇಮ್ ಕೌಂಟರ್ಗಳನ್ನು (
requestAnimationFrameಕಾಲ್ಗಳು) ಲಾಗ್ ಮಾಡಿ. - ಅನಿವಾರ್ಯವಾಗಿ ಅಡಗಿರುವ ಟ್ಯಾಬ್ನಲ್ಲಿ ನಡೆಸುವ ಯಾವುದೇ ರನ್ಗಳನ್ನು ಸ್ಪಷ್ಟ ಎಚ್ಚರಿಕೆಗಳೊಂದಿಗೆ ದಾಖಲಿಸಿ, ಇದರಿಂದ ಮುಂದಿನ ಪರಿಶೀಲಕರಿಗೆ (reviewers) ಮಿತಿಗಳು ಅರ್ಥವಾಗುತ್ತವೆ.
ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು
AI-ಸಹಾಯಿತ QA ಪರಿಕರಗಳು ಹೆಚ್ಚಾದಂತೆ, ಡೆವಲಪರ್ಗಳು ಅವುಗಳನ್ನು ಸಹಾಯಕರೆಂದು ಪರಿಗಣಿಸಬೇಕೇ ಹೊರತು ನಿರ್ಧಾರಕರೆಲ್ಲ (arbiters) ಅಲ್ಲ. ಕೋಡ್-ಹೆಲ್ತ್ ಮೆಟ್ರಿಕ್ಸ್ಗಳು ಯಾವಾಗಲೂ ಬಳಕೆದಾರರ ಮುಖಾಮುಖಿ ವರ್ತನೆಗೆ ಅಪೂರ್ಣ ಪ್ರತಿನಿಧಿಯಾಗಿರುತ್ತವೆ. ಇದರ ಸಾರಾಂಶ ಸರಳವಾಗಿದೆ: AI ಮಾಡೆಲ್ ಅದಕ್ಕೆ ಏನು ಕಾಣಿಸುತ್ತದೆಯೋ ಅದನ್ನು ಮಾತ್ರ ವರದಿ ಮಾಡಬಲ್ಲದು. ಟ್ಯಾಬ್ ಅಡಗಿರುವ ಕಾರಣ ಬ್ರೌಸರ್ ಎಂದಿಗೂ ಪೇಂಟ್ ಮಾಡದಿದ್ದರೆ, ಅಥವಾ ಟೆಸ್ಟ್ ಸ್ಕ್ರಿಪ್ಟ್ “ಸ್ಕ್ರೀನ್ ಮೇಲೆ ಏನಾದರೂ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತಿದೆಯೇ?” ಎಂದು ಎಂದಿಗೂ ಕೇಳದಿದ್ದರೆ, ಮಾಡೆಲ್ ಸಂತೋಷದಿಂದ ಯಶಸ್ಸನ್ನು ಘೋಷಿಸುತ್ತದೆ. ದೃಶ್ಯಾವಳಿ ಅಗತ್ಯತೆ ಮತ್ತು ವರ್ತನೆ-ಪರಿಶೀಲನಾ ಹಂತವನ್ನು ಸೇರಿಸುವುದು ಒಂದು ಹೊಳೆಯುವ ಪಾಸನ್ನು ವಿಶ್ವಾಸಾರ್ಹ ಫಲಿತಾಂಶವನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.