ಯಾರೂ ಅದರ ವೈಫಲ್ಯಗಳನ್ನು ನಂಬದಿದ್ದರೆ ನಿಮ್ಮ ಟೆಸ್ಟ್ ಸೂಟ್ ಪ್ರಯೋಜನವಿಲ್ಲದಂತಾಗುತ್ತದೆ. ತಂಡಗಳು ಹೆಚ್ಚಿನ ಟೆಸ್ಟ್ಗಳು, ಸಮೃದ್ಧ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಳು ಅಥವಾ ಪ್ಯಾರಲಲ್ ಎಕ್ಸಿಕ್ಯೂಷನ್ ಅನ್ನು ಸೇರಿಸಬಹುದು, ಆದರೂ ಕೆಂಪು ಬಾಕ್ಸ್ ಮಾಯವಾಗಲಿ ಎಂಬ ಭರವಸೆಯಲ್ಲಿ ಡೆವಲಪರ್ಗಳು ಇನ್ನೂ ಪೈಪ್ಲೈನ್ಗಳನ್ನು ಮರು ಚಲಾಯಿಸುತ್ತಾರೆ. ಈ ಅಭ್ಯಾಸವು ಸಂಭಾವ್ಯ ಮೌಲ್ಯಯುತವಾದ ಸಂಕೇತವನ್ನು ದುಬಾರಿ ಗದ್ದಲವನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.
ನಿಜವಾದ ಸಮಸ್ಯೆ ಕವರೇಜ್ ಅಲ್ಲ, ನಂಬಿಕೆ
ಹೆಚ್ಚಿನ ಎಂಜಿನಿಯರಿಂಗ್ ಗುಂಪುಗಳು ಟೆಸ್ಟ್ಗಳ ಕೊರತೆ ಅಥವಾ ಅಸಮರ್ಪಕ ಬ್ರೌಸರ್ ಕವರೇಜ್ ಅನ್ನು ದೂಷಿಸುತ್ತವೆ. ವಾಸ್ತವದಲ್ಲಿ, ವೈಫಲ್ಯಗಳನ್ನು ಕೇವಲ ಗದ್ದಲವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಡ್ಯಾಶ್ಬೋರ್ಡ್ನಲ್ಲಿ 96% ಪಾಸ್ ರೇಟ್ ಆಕರ್ಷಕವಾಗಿ ಕಾಣಿಸಬಹುದು, ಆದರೆ 4% ವೈಫಲ್ಯಗಳು ನೈಜ ದೋಷಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಿದೆಯೇ ಅಥವಾ ಅವು ಹೊರಬರಲು ಹಲವಾರು ಮರುಪ್ರಯತ್ನಗಳು ಬೇಕಾಗಿದೆಯೇ ಎಂಬುದರ ಬಗ್ಗೆ ಅದು ನಿಮಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಡೆವಲಪರ್ಗಳು ವೈಫಲ್ಯಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದಾಗ, ಟೆಸ್ಟ್ ಸೂಟ್ ನಿರ್ಧಾರಗಳ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರದೆ ಸಮಯ ಮತ್ತು ಕಂಪ್ಯೂಟ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ.
ಪಾಸ್ ರೇಟ್ಗಳು ಏಕೆ ದಾರಿ ತಪ್ಪಿಸಬಹುದು
ಪಾಸ್-ರೇಟ್ ಮೆಟ್ರಿಕ್ಸ್ಗಳು ಎಲ್ಲಾ ಫಲಿತಾಂಶಗಳನ್ನು ಒಂದೇ ಸಂಖ್ಯೆಗೆ ಕುಗ್ಗಿಸುತ್ತವೆ, ಇದು ಎರಡು ಪ್ರಮುಖ ಪ್ರಶ್ನೆಗಳನ್ನು ಮರೆಮಾಚುತ್ತದೆ:
- ವೈಫಲ್ಯಗಳು ನೈಜ ದೋಷಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸಿದವೇ? ಬಗ್ ಅನ್ನು ಎಂದಿಗೂ ಪತ್ತೆಹಚ್ಚದ ಫ್ಲೇಕಿ (flaky) ಟೆಸ್ಟ್ ಯಾವುದೇ ಮೌಲ್ಯವನ್ನು ನೀಡುವುದಿಲ್ಲ.
- ಎಷ್ಟು ಮರುಪ್ರಯತ್ನಗಳು ಬೇಕಾದವು? ಅಂತಿಮ ಪಾಸ್ ರೇಟ್ ಹೆಚ್ಚಿದ್ದರೂ ಸಹ, ಮೂರು ಸ್ವಯಂಚಾಲಿತ ಮರುಪ್ರಯತ್ನಗಳ ನಂತರ ಪಾಸ್ ಆಗುವ ಟೆಸ್ಟ್ ಸೂಟ್ ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲ.
99% ಯಶಸ್ಸನ್ನು ವರದಿ ಮಾಡುವ ಆದರೆ ಚೆಕ್ಔಟ್ ವೈಫಲ್ಯಗಳನ್ನು ಪದೇ ಪದೇ ತಪ್ಪಿಸಿಕೊಳ್ಳುವ ಟೆಸ್ಟ್ ಸೂಟ್, 92% ರಷ್ಟು ಬಾರಿ ಪಾಸ್ ಆಗುವ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಆದಾಯದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಬಗ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಟೆಸ್ಟ್ ಸೂಟ್ಗಿಂತ ಬಹಳ ಕೆಟ್ಟದಾಗಿದೆ. ಗುರಿ ಎಂದರೆ ಕೇವಲ ಹೆಚ್ಚಿನ ಶೇಕಡಾವಾರು ಸಂಖ್ಯೆಯಲ್ಲ; ಅದು ಅಪಾಯದ ಬಗ್ಗೆ ಉತ್ತಮ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವುದು.
ಮುಖ್ಯವಾದ ಮೆಟ್ರಿಕ್ಸ್ಗಳು
ಪಾಸ್-ರೇಟ್ ಗಮನವನ್ನು ಬದಲಿಸಿ, ಟೆಸ್ಟ್ ಸೂಟ್ನ ಉಪಯುಕ್ತತೆಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವ ಅಳತೆಗೋಲುಗಳನ್ನು ಬಳಸಿ:
- Failure recurrence – ಸತತ ಚಲನಾವಳಿಗಳಲ್ಲಿ ಒಂದೇ ಟೆಸ್ಟ್ ಎಷ್ಟು ಬಾರಿ ಫೇಲ್ ಆಗುತ್ತದೆ.
- Defect detection rate – ವೈಫಲ್ಯಗಳಲ್ಲಿ ದೃಢೀಕರಿಸಲ್ಪಟ್ಟ ಬಗ್ಗಳ ಪ್ರಮಾಣ.
- Time to diagnosis – ಫೇಲ್ ಆದ ಟೆಸ್ಟ್ ಅನ್ನು ಎಷ್ಟು ಬೇಗ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ಅದರ ಮೇಲೆ ಕ್ರಮ ತೆಗೆದುಕೊಳ್ಳಬಹುದು.
- Retry dependence – ಪಾಸ್ ಆಗಲು ಸ್ವಯಂಚಾಲಿತ ಮರುಚಾಲನೆ ಬೇಕಾಗುವ ಟೆಸ್ಟ್ಗಳ ಆವರ್ತನ.
- Escaped regressions – ಟೆಸ್ಟ್ ಸೂಟ್ ಇದ್ದರೂ ಪತ್ತೆಯಾಗದೆ ತಪ್ಪಿಹೋದ ದೋಷಗಳು.
ಈ ಸಂಕೇತಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದರಿಂದ ವೈಫಲ್ಯವು ನೀವು ಕ್ರಮ ತೆಗೆದುಕೊಳ್ಳಬಹುದಾದ ಎಚ್ಚರಿಕೆಯೇ ಅಥವಾ ಕೇವಲ ಒಂದು ಫ್ಲೇಕ್ (flake) ಎಂಬುದನ್ನು ನೀವು ತಿಳಿಯಬಹುದು.
ನಿರ್ವಹಣೆಯ ಗುಪ್ತ ವೆಚ್ಚ
ಬರೆಯಲು ಹತ್ತು ನಿಮಿಷಗಳು ಬೇಕು ಆದರೆ ತಿಂಗಳಿಗೆ ಸರಿಪಡಿಸಲು ಮೂರು ಗಂಟೆಗಳು ಬೇಕಾಗುವ ಟೆಸ್ಟ್ ಒಂದು ಕೆಟ್ಟ ಹೂಡಿಕೆಯಾಗಿದೆ. ಟೆಸ್ಟ್ಗಳು ಅಸ್ಥಿರವಾಗಿದ್ದಾಗ, ನಿರಂತರ ಡೇಟಾ ಅಪ್ಡೇಟ್ಗಳನ್ನು ಬಯಸುವಾಗ ಅಥವಾ ದುರ್ಬಲ UI ಸೆಲೆಕ್ಟರ್ಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದ್ದಾಗ ನಿರ್ವಹಣಾ ವೆಚ್ಚವು ಹೆಚ್ಚಾಗುತ್ತದೆ. AI ಟೆಸ್ಟ್ಗಳನ್ನು ರಚಿಸಿದಾಗ ಈ ವೆಚ್ಚವು ಎದ್ದು ಕಾಣುತ್ತದೆ. UI ಬದಲಾದ ಪ್ರತಿ ಬಾರಿಯೂ ರಚಿಸಲಾದ ಟೆಸ್ಟ್ಗಳು ಮುರಿದುಹೋದರೆ, ಅವುಗಳ ರಚನೆಯ ವೇಗಕ್ಕೆ ಹೆಚ್ಚಿನ ಮಹತ್ವವಿಲ್ಲ.
AI-ಸೃಷ್ಟಿತ ಟೆಸ್ಟ್ಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವಾಗ, ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಕೇಳಿ:
- ಟೆಸ್ಟ್ಗೆ ಎಷ್ಟು ಬಾರಿ ಮ್ಯಾನುಯಲ್ ಎಡಿಟಿಂಗ್ ಅಗತ್ಯವಿದೆ?
- ಅದು ಏಕೆ ಫೇಲ್ ಆಯಿತು ಎಂಬುದನ್ನು ಎಷ್ಟು ಸ್ಪಷ್ಟವಾಗಿ ವಿವರಿಸುತ್ತದೆ?
- ವೈಫಲ್ಯವನ್ನು ಸರಿಪಡಿಸಲು ಮನುಷ್ಯನಿಗೆ ಎಷ್ಟು ಮಟ್ಟದ ಸಂದರ್ಭದ ಮಾಹಿತಿ (context) ಬೇಕಾಗುತ್ತದೆ?
ಉತ್ತರಗಳು ಪದೇ ಪದೇ ಮಾನವ ಹಸ್ತಕ್ಷೇಪವನ್ನು ಸೂಚಿಸಿದರೆ, ಆಟೊಮೇಷನ್ನ ಪ್ರಯೋಜನವು ಮಾಯವಾಗುತ್ತದೆ.
ಅಬ್ಸರ್ವೇಬಿಲಿಟಿ (Observability): ವೈಫಲ್ಯಗಳನ್ನು ಕ್ರಮ ಕೈಗೊಳ್ಳುವಂತನ್ನಾಗಿ ಮಾಡುವುದು
ವಿಶ್ಲೇಷಿಸಲು ನಲವತ್ತು ನಿಮಿಷ ತೆಗೆದುಕೊಳ್ಳುವ 4,000 ಸಾಲುಗಳ ಲಾಗ್, ಯಾವುದೇ ಲಾಗ್ ಇಲ್ಲದಿರುವುದಕ್ಕೆ ಸಮಾನವಾಗಿದೆ. ಉತ್ತಮ ಅಬ್ಸರ್ವೇಬಿಲಿಟಿ ನೀವು ಮೂರು ಪ್ರಶ್ನೆಗಳಿಗೆ ವೇಗವಾಗಿ ಉತ್ತರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ:
- ಟೆಸ್ಟ್ ಏನನ್ನು ನಿರೀಕ್ಷಿಸಿತ್ತು?
- ವಾಸ್ತವವಾಗಿ ಏನಾಯಿತು?
- ಮೂಲ ಕಾರಣವು ಉತ್ಪನ್ನದ ಬಗ್ ಆಗಿದೆಯೇ, ಡೇಟಾ ಸಮಸ್ಯೆಯೇ ಅಥವಾ ಮೂಲಸೌಕರ್ಯದ ಸಮಸ್ಯೆಯೇ?
AI ಏಜೆಂಟ್ಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಆಳವಾದ ಪರಿಶೀಲನೆಗಳು ಬೇಕು
ಪರೀಕ್ಷಿಸಲಾಗುತ್ತಿರುವ ವ್ಯವಸ್ಥೆಯು AI-ಚಾಲಿತ ಏಜೆಂಟ್ ಆಗಿದ್ದಾಗ, ಪಾಸ್ ಆದ ಟೆಸ್ಟ್ ಒಳಗಿನ ದೋಷಪೂರಿತ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮರೆಮಾಚಬಹುದು. ಏಜೆಂಟ್ ತಪ್ಪಾದ ಶಾರ್ಟ್ಕಟ್ ತೆಗೆದುಕೊಳ್ಳುವ ಮೂಲಕ, ತಪ್ಪು ಟೂಲ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಮೂಲಕ ಅಥವಾ ತನ್ನ ಮೆಮೊರಿಯನ್ನು ಸರಿಯಾಗಿ ಅಪ್ಡೇಟ್ ಮಾಡದ ಮೂಲಕ ಸರಿಯಾದ ಉತ್ತರವನ್ನು ತಲುಪಬಹುದು. ಆದ್ದರಿಂದ ವಿಶ್ವಾಸಾರ್ಹ ಪರೀಕ್ಷೆಯು ಇವುಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕು:
- Tool selection logic
- Memory update behavior
- Recovery mechanisms after errors
ವೈಫಲ್ಯದ ಸಂದರ್ಭಗಳಲ್ಲಿ ಏಜೆಂಟ್ ಮುನ್ಸೂಚನೆ ನೀಡಬಹುದಾದ ರೀತಿಯಲ್ಲಿ ವರ್ತಿಸಿದಾಗ ಮಾತ್ರ ಅದರ ಫಲಿತಾಂಶವನ್ನು ನಂಬಬಹುದು.
ಟೆಸ್ಟ್ ನಿರ್ವಹಣೆಯನ್ನು ಉತ್ಪನ್ನದ ಕೆಲಸದಂತೆ ಪರಿಗಣಿಸಿ
ಅಸ್ಥಿರ ಟೆಸ್ಟ್ಗಳನ್ನು ಇತರ ಯಾವುದೇ ಕೋಡ್ನಷ್ಟೇ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ನಿರ್ವಹಿಸಿ:
- ವ್ಯವಹಾರದ ಮೌಲ್ಯವನ್ನು ಪ್ರತಿಬಿಂಬಿಸದ ಟೆಸ್ಟ್ಗಳನ್ನು ತೆಗೆದುಹಾಕಿ.
- ಪದೇ ಪದೇ ಮರುಪ್ರಯತ್ನಗಳು ಬೇಕಾಗುವ ಟೆಸ್ಟ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ರಿಫ್ಯಾಕ್ಟರ್ (refactor) ಮಾಡಿ.
- ಡೇಟಾ ಮುರಿಯುವ ಮೊದಲೇ ಟೆಸ್ಟ್ ಡೇಟಾವನ್ನು ಮುನ್ನೆಚ್ಚರಿಕೆಯಿಂದ ಅಪ್ಡೇಟ್ ಮಾಡಿ.
- ಫ್ಲೇಕಿ ಅಥವಾ ಹೆಚ್ಚಿನ ಅಪಾಯವಿರುವ ಪ್ರದೇಶಗಳಿಗೆ ಸ್ಪಷ್ಟವಾದ ಮಾಲೀಕತ್ವವನ್ನು (ownership) ನಿಯೋಜಿಸಿ.
ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು
AI-ಸೃಷ್ಟಿತ ಟೆಸ್ಟ್ ಟೂಲಿಂಗ್ ಅನ್ನು ಗಮನಿಸಿ: ಅದರ ಮೌಲ್ಯವನ್ನು ಟೆಸ್ಟ್ಗಳ ಪ್ರಮಾಣದಿಂದಲ್ಲದೆ, ಮ್ಯಾನುಯಲ್ ಎಡಿಟ್ಗಳ ಕಡಿತ ಮತ್ತು ಸ್ಪಷ್ಟವಾದ ವೈಫಲ್ಯದ ವಿವರಣೆಗಳಿಂದ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ.
ಸಾರಾಂಶ
ಒಂದು ಟೆಸ್ಟ್ ಸೂಟ್ ಪ್ರತಿ ಉಪಯುಕ್ತ ವೈಫಲ್ಯದ ಮೂಲಕ ನಂಬಿಕೆಯನ್ನು ಗಳಿಸುತ್ತದೆ. ವೈಫಲ್ಯಗಳು ಉಪಯುಕ್ತವಾಗುವುದನ್ನು ನಿಲ್ಲಿಸಿದಾಗ, ಹೆಚ್ಚಿನ ಟೆಸ್ಟ್ಗಳನ್ನು ಸೇರಿಸುವುದು ಸಮಸ್ಯೆಯನ್ನು ಮತ್ತಷ್ಟು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಹೊಳೆಯುವ ಪಾಸ್ ಶೇಕಡಾವಾರುಗಳ ಬದಲಿಗೆ ನಿರ್ದಿಷ್ಟ ಅಪಾಯ-ಕೇಂದ್ರಿತ ಮೆಟ್ರಿಕ್ಸ್ಗಳ ಮೇಲೆ ಗಮನ ಹರಿಸಿ, ಅಬ್ಸರ್ವೇಬಿಲಿಟಿಯಲ್ಲಿ ಹೂಡಿಕೆ ಮಾಡಿ ಮತ್ತು ಟೆಸ್ಟ್ ನಿರ್ವಹಣೆಯನ್ನು ಪ್ರಮುಖ ಉತ್ಪನ್ನ ಚಟುವಟಿಕೆಯಾಗಿ ಪರಿಗಣಿಸಿ. ಇದರ ಫಲಿತಾಂಶವು ತಂಡವನ್ನು ಗದ್ದಲದಲ್ಲಿ ಮುಳುಗಿಸದೆ, ವಾಸ್ತವವಾಗಿ ನಿರ್ಧಾರಗಳಿಗೆ ಮಾರ್ಗದರ್ಶನ ನೀಡುವ ಹೆಚ್ಚು ಸುಸಜ್ಜಿತ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹ ಆಟೊಮೇಷನ್ ಪದರವಾಗಿರುತ್ತದೆ.