ಬಳಕೆದಾರರ ಕಥೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವುದು ಯಾವಾಗ?

ನೀವು ಚುರುಕುಬುದ್ಧಿಯ ವಾತಾವರಣದಲ್ಲಿ ಕ್ಯೂಎ ಆಗಿ ಕೆಲಸ ಮಾಡಿದ್ದರೆ, ಬಹುಶಃ ನೀವು ಕೆಲವು ರೀತಿಯ ಪರೀಕ್ಷಾ ಯಾಂತ್ರೀಕರಣವನ್ನು ನೋಡುತ್ತಿದ್ದೀರಿ. ನಾನು ಸಾಮಾನ್ಯವಾಗಿ ಡೆವಲಪರ್ ಕೇಂದ್ರಿತ ಚಟುವಟಿಕೆಯಾದ ಯುನಿಟ್ ಟೆಸ್ಟ್ ಆಟೊಮೇಷನ್ ಎಂದರ್ಥವಲ್ಲ, ಆದರೆ ಕ್ರಿಯಾತ್ಮಕ ಸ್ವೀಕಾರ ಪರೀಕ್ಷಾ ಯಾಂತ್ರೀಕೃತಗೊಂಡವು ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ QA ಅಥವಾ ಟೆಸ್ಟ್‌ನಲ್ಲಿ ಸಾಫ್ಟ್‌ವೇರ್ ಡೆವಲಪರ್‌ನ ಹೊಸ ಅಲಂಕಾರಿಕ ಪಾತ್ರದಿಂದ ಮಾಡಲಾಗುತ್ತದೆ.

ಮೊದಲಿಗೆ, ಪರೀಕ್ಷಾ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಕೆಲವು ಮಾನದಂಡಗಳು ಮತ್ತು ಕಾರಣಗಳನ್ನು ನೋಡೋಣ, ಅದು “ಪರೀಕ್ಷೆಗಳು ಏಕೆ ಸ್ವಯಂಚಾಲಿತವಾಗಬಾರದು / ಮಾಡಬಾರದು” ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಬೇಕು.



ಪುನರಾವರ್ತನೆ

ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳು ಪುನರಾವರ್ತಿತವಾಗಬೇಕು ಮತ್ತು ಪ್ರತಿ ಓಟದಲ್ಲಿ output ಟ್‌ಪುಟ್ ಸ್ಥಿರವಾಗಿರಬೇಕು ಇದರಿಂದ ಡೆವಲಪರ್‌ಗಳು ಪರೀಕ್ಷೆಗಳ ಫಲಿತಾಂಶವನ್ನು ಅವಲಂಬಿಸಬಹುದು. ಪರೀಕ್ಷೆಯನ್ನು ಒಮ್ಮೆ ಮಾತ್ರ ಚಲಾಯಿಸಲು ಹೋದರೆ ನಾವು ಅದನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವುದಿಲ್ಲ ಎಂದೂ ಇದರರ್ಥ; ಅನೇಕ ಲಿಂಕ್‌ಗಳೊಂದಿಗೆ ಲಿಂಕ್ ಪುನರ್ನಿರ್ದೇಶನ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವಂತಹ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಡೇಟಾದ ವಿರುದ್ಧ ನೀವು ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುತ್ತಿದ್ದರೆ ಇದಕ್ಕೆ ಏಕೈಕ ಅಪವಾದ.




ವಿಶ್ವಾಸಾರ್ಹತೆ

ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳು ನಿಜವಾಗಿಯೂ ಪರಿಶೀಲನೆಗಳನ್ನು ಸರಿಯಾಗಿ ಪರಿಶೀಲಿಸುತ್ತಿರಬೇಕು ಮತ್ತು ಮಾನ್ಯ ನಿರೀಕ್ಷಿತ ಫಲಿತಾಂಶಗಳ ವಿರುದ್ಧ ನಿಜವಾದ ಫಲಿತಾಂಶಗಳನ್ನು ನಿರ್ಧರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಇದರರ್ಥ ಫಲಿತಾಂಶಗಳನ್ನು ಸುಲಭವಾಗಿ ನಿರ್ಧರಿಸಲಾಗದಿದ್ದರೆ ಅಥವಾ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳು ಪರಿಸರ ಸಮಸ್ಯೆಗಳಿಗೆ ಒಳಪಟ್ಟರೆ ಅದು ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳಲ್ಲಿ ತಪ್ಪು ಧನಾತ್ಮಕತೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಆಗ ಪರೀಕ್ಷೆಗಳು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿರಲು ಸಾಧ್ಯವಿಲ್ಲ.



ಸಮಯ

ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳು ಸಹ ನಮ್ಮ ಸಮಯವನ್ನು ಉಳಿಸಬೇಕು. ಸರಳ ಪರೀಕ್ಷೆಯು ಪೂರ್ಣಗೊಳ್ಳಲು 10 ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಂಡರೂ ಅದೇ ಫಲಿತಾಂಶವನ್ನು 1 ನಿಮಿಷದಲ್ಲಿ ಕೈಯಾರೆ ನಿರ್ಧರಿಸಿದರೆ, ಅಂತಹ ಪರೀಕ್ಷೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸದಿರುವುದು ಉತ್ತಮ.




ಸುರಕ್ಷಾ ಬಲೆ

ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಸುರಕ್ಷತಾ ಜಾಲವನ್ನು ಒದಗಿಸಬೇಕು, ಇದರಿಂದಾಗಿ ಕೋಡ್ ಬೇಸ್‌ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳ ಪರಿಣಾಮವಾಗಿ ಉತ್ತಮ ಕಾರ್ಯ ಕೋಡ್‌ನಿಂದ ಯಾವುದೇ ವಿಚಲನವನ್ನು ತ್ವರಿತವಾಗಿ ಹೈಲೈಟ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಡೆವಲಪರ್‌ಗಳಿಗೆ ವರದಿ ಮಾಡಲಾಗುತ್ತದೆ.



ಕಥೆಗಳನ್ನು ಯಾವಾಗ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬೇಕು?

ಒಂದು ವಿಶಿಷ್ಟ ಸ್ಪ್ರಿಂಟ್‌ನಲ್ಲಿ, 7 ಕಥೆಗಳು ಸ್ಪ್ರಿಂಟ್‌ಗೆ ಬದ್ಧವಾಗಿವೆ ಎಂದು ಹೇಳಿ, ಅದರಲ್ಲಿ 5 ಕಥೆಗಳು ಮೇಲಿನ ಮಾನದಂಡಗಳ ಆಧಾರದ ಮೇಲೆ ಸ್ವಯಂಚಾಲಿತವಾಗಲು ಉತ್ತಮ ಅಭ್ಯರ್ಥಿಗಳಾಗಿವೆ. ಆದರೆ ಈ ಕಥೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಉತ್ತಮ ಸಮಯ ಯಾವಾಗ? ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿರುವುದರಿಂದ ನಾವು ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಬೇಕೇ? ವೈಶಿಷ್ಟ್ಯವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವವರೆಗೆ ನಾವು ಕಾಯಬೇಕು ಮತ್ತು ನಂತರ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಬೇಕೇ? ನಾವು ಸ್ಪ್ರಿಂಟ್ನ ಕೊನೆಯವರೆಗೂ ಕಾಯುತ್ತೇವೆ ಮತ್ತು ನಂತರ ಕಥೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸೋಣವೇ?

ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಕಥೆಗಳು ದೋಷ ಪರಿಹಾರಗಳು ಅಥವಾ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವೈಶಿಷ್ಟ್ಯಕ್ಕೆ ಸ್ವಲ್ಪ ಮಾರ್ಪಾಡು ಅಥವಾ ವರ್ಧನೆಯಾಗಿದ್ದಾಗ, ವೈಶಿಷ್ಟ್ಯವನ್ನು ಡೆವಲಪರ್‌ಗಳು ಮಾರ್ಪಡಿಸುತ್ತಿರುವುದರಿಂದ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಲು ಇದು ಎಲ್ಲಾ ಅರ್ಥವನ್ನು ನೀಡುತ್ತದೆ. ವೈಶಿಷ್ಟ್ಯವನ್ನು ಮಾರ್ಪಡಿಸುವುದಕ್ಕಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಯೂ ಸಹ ಇರಬಹುದು, ಇದರಲ್ಲಿ ಹೊಸ ಬದಲಾವಣೆಗಳಿಗೆ ಅನುಗುಣವಾಗಿ ನೀವು ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ತಿರುಚಬೇಕಾಗುತ್ತದೆ.

ಇತರ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಕಥೆಯು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಹೊಸ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ, ಮುಂಚಿತವಾಗಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಲು ಸಾಧ್ಯವಾಗುವಂತೆ ಅಂತಿಮ ಉತ್ಪನ್ನವು ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂದು ನಮಗೆ ಹೇಗೆ ಗೊತ್ತು? ಇಲ್ಲಿ, ಸ್ವೀಕಾರ ಪರೀಕ್ಷೆಗಳನ್ನು ಮುಂಚಿತವಾಗಿ ವಿವರಿಸುವ ವೈಶಿಷ್ಟ್ಯ ಫೈಲ್‌ಗಳ ಬಗ್ಗೆ ನಾನು ಮಾತನಾಡುವುದಿಲ್ಲ, ಆದರೆ ವಿತರಿಸಿದ ಕೋಡ್‌ಗೆ ವಿರುದ್ಧವಾಗಿ ನಡೆಯುವ ನಿಜವಾದ ನೆಲೆವಸ್ತುಗಳು ಅಥವಾ ಸೆಲೆನಿಯಮ್ ಪರೀಕ್ಷೆಗಳು (ಪರೀಕ್ಷೆಗಳ ಅನುಷ್ಠಾನ).


ಬಾಟಮ್ ಲೈನ್ - ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ ಮಾಡಲಿರುವ ಯಾವುದೇ ಪರೀಕ್ಷೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬೇಕು. ಮತ್ತು ನಾವು ಯಾವ ಪರೀಕ್ಷೆಗಳನ್ನು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಿದ್ದೇವೆ? ಹಿಂಜರಿತ ಪರೀಕ್ಷೆಗಳು. ಮತ್ತು ಹಿಂಜರಿತ ಪರೀಕ್ಷೆಗಳು ಯಾವುವು? ಹೊಸ ಮಾರ್ಪಾಡುಗಳು ಮತ್ತು ವೈಶಿಷ್ಟ್ಯಗಳ ಪರಿಣಾಮವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಕ್ರಿಯಾತ್ಮಕತೆಯಲ್ಲಿ ಹಿಮ್ಮೆಟ್ಟಿದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುವ ಪರೀಕ್ಷೆಗಳು.

ಆದರೆ, ತಿಳಿದಿರುವ ಒಳಹರಿವು ಮತ್ತು .ಟ್‌ಪುಟ್‌ಗಳೊಂದಿಗಿನ ವರ್ತನೆಯ ವಿಷಯದಲ್ಲಿ ಸ್ಥಿರವಾದ, ಚೆನ್ನಾಗಿ ಅರ್ಥವಾಗುವ ಮತ್ತು ನಿರ್ಣಾಯಕವಾದ ವ್ಯವಸ್ಥೆಯ ವಿರುದ್ಧ ಮಾತ್ರ ನೀವು ಉತ್ತಮ ಸ್ವಯಂಚಾಲಿತ ಹಿಂಜರಿತ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಬಹುದು.

ವೈಶಿಷ್ಟ್ಯವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿರುವಾಗ ಅದರ ವಿರುದ್ಧ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಲು ಪ್ರಯತ್ನಿಸುವುದರಲ್ಲಿನ ಸಮಸ್ಯೆ ಎಂದರೆ ನೀವು ದೀರ್ಘಕಾಲ ಮತ್ತು ಸ್ಪ್ರಿಂಟ್ ಸಮಯದಲ್ಲಿ ನಿರಂತರ ಬದಲಾವಣೆಗೆ ಒಳಪಡುವ ಯಾವುದಾದರೂ ವಿರುದ್ಧ ಸ್ವಯಂಚಾಲಿತ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬರೆಯಲು ಬಹಳ ಸಮಯ ಮತ್ತು ಹೆಚ್ಚಿನ ಶ್ರಮವನ್ನು ಕಳೆಯಬಹುದು. ಇದಲ್ಲದೆ, ಒಂದು ಕಥೆಯನ್ನು ಸ್ಪ್ರಿಂಟ್‌ಗೆ ಬದ್ಧವಾಗಿಟ್ಟುಕೊಂಡು ನಂತರ ಸ್ಪ್ರಿಂಟ್‌ನಿಂದ ಹೊರತೆಗೆಯುವುದನ್ನು ನಾವು ಎಷ್ಟು ಬಾರಿ ನೋಡಿದ್ದೇವೆ? ನಂತರ ನಾವು ಅದನ್ನು ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಮಾಡದ ಯಾವುದನ್ನಾದರೂ ಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡಲು ಸಮಯ ವ್ಯರ್ಥ ಮಾಡಿದ್ದೇವೆ.

ಕೆಲವು ಸಂಸ್ಥೆಗಳು ಕಥೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವವರೆಗೆ “ಮಾಡಲಾಗುವುದಿಲ್ಲ” ಎಂಬ ಕಟ್ಟುನಿಟ್ಟಿನ ನಿಯಮವನ್ನು ವಿಧಿಸುತ್ತವೆ! QA ವಿವಿಧ ಕಾರಣಗಳಿಂದಾಗಿ ಸಮಯಕ್ಕೆ ಯಾಂತ್ರೀಕೃತಗೊಂಡಾಗ ಅಥವಾ ನೀಡಲಾಗದ ಕಾರಣ ಬಿಡುಗಡೆಯಾಗಬೇಕಾದ ಪ್ರಮುಖ ವೈಶಿಷ್ಟ್ಯವನ್ನು ನಾವು ನಿಲ್ಲಿಸಲಿದ್ದೇವೆಯೇ? ಅಥವಾ ಕಥೆಯನ್ನು “ಮುಗಿದಿಲ್ಲ” ಏಕೆಂದರೆ ಪುಟದಲ್ಲಿನ ಗುಂಡಿಯ ಅಸ್ತಿತ್ವವನ್ನು ಪರಿಶೀಲಿಸಲು ನಮ್ಮಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತ ಸ್ಕ್ರಿಪ್ಟ್ ಇಲ್ಲ. ಗಂಭೀರವಾಗಿ?


ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಪರೀಕ್ಷೆಯ ಉತ್ತಮ ಉದ್ದೇಶವೆಂದರೆ ಹಿಂಜರಿತ ಪರೀಕ್ಷೆ ಮತ್ತು ಹಿಂಜರಿತ ಪರೀಕ್ಷೆಗಳನ್ನು ಯಾವಾಗಲೂ ತಿಳಿದಿರುವ ರಾಜ್ಯ ಮತ್ತು ನಿರ್ಣಾಯಕ ವ್ಯವಸ್ಥೆಯ ವಿರುದ್ಧ ಬೇಸ್‌ಲೈನ್‌ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಯಿಂದ ಅರ್ಥಪೂರ್ಣ ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯುವುದು ಪರೀಕ್ಷೆಯು ಚಾಲನೆಯಾದಾಗ ಮಾತ್ರ ಮತ್ತು ಒಮ್ಮೆಯಾದರೂ ಹಸ್ತಚಾಲಿತವಾಗಿ ರವಾನಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ನೀವು ಹಸ್ತಚಾಲಿತ ಮರಣದಂಡನೆಯ ವಿರುದ್ಧ ಸ್ವಯಂಚಾಲಿತ ಚಾಲನೆಯ ಫಲಿತಾಂಶಗಳನ್ನು ಹೋಲಿಸಬಹುದು.

ಈ ವ್ಯಾಖ್ಯಾನದಿಂದ, ಕಥೆಗಳನ್ನು ಸ್ಪ್ರಿಂಟ್‌ನೊಳಗೆ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬೇಕು (ಅನುಷ್ಠಾನ) ಮತ್ತು ವೈಶಿಷ್ಟ್ಯವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕೈಯಾರೆ ಪರಿಶೀಲಿಸಿದಾಗ ಮಾತ್ರ. ಕಥೆ ಪೂರ್ಣಗೊಂಡ ನಂತರ ಮತ್ತು ಅದನ್ನು ಮೊದಲು ಕೈಯಾರೆ ಪರಿಶೀಲಿಸಿದ ನಂತರ, ಇದು ವಿಶ್ವಾಸಾರ್ಹ ವೈಶಿಷ್ಟ್ಯ ಮತ್ತು ಸ್ಥಿರವಾದ ವ್ಯವಸ್ಥೆಯಾಗಿದ್ದು, ನಂತರ ನೀವು ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಬಹುದು ಮತ್ತು ಬರೆಯಬಹುದು. ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ ನಂತರ, ಮುಂದಿನ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿರುವುದರಿಂದ ಹಿಂಜರಿತ ದೋಷಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಮತ್ತು ಪತ್ತೆಹಚ್ಚಲು ಅದನ್ನು ಹಿಂಜರಿತ ಪರೀಕ್ಷಾ ಸೂಟ್‌ಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ.

ಆಸಕ್ತಿಕರ ಲೇಖನಗಳು