𝟭𝟬 ಸರ್ಟಿಫಿಕೇಟ್ಗಳಿದ್ದರೂ ಬಗ್ ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಾಗದ ಟೆಸ್ಟರ್
ನಿಮ್ಮ ಬಳಿ ಎಲ್ಲಾ ಸರ್ಟಿಫಿಕೇಟ್ಗಳಿವೆ. ISTQB, ScrumMaster, Cloud, ಮತ್ತು Security. ನಿಮ್ಮ ರೆಸ್ಯೂಮೆ (resume) ಸಂಕ್ಷಿಪ್ತ ರೂಪದ ಪದಗಳಿಂದ (acronyms) ತುಂಬಿದೆ.
ಆದರೆ ನೈಜವಾದ ಬಗ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಒಂದೇ ಒಂದು ಟೆಸ್ಟ್ ಅನ್ನು ನೀವು ಬರೆಯಲು ಸಾಧ್ಯವಾಗುತ್ತಿಲ್ಲ.
ಕಳೆದ ತ್ರೈಮಾಸಿಕದಲ್ಲಿ ನಾನು ಒಬ್ಬ ಅಭ್ಯರ್ಥಿಯನ್ನು ಸಂದರ್ಶಿಸಿದೆ. ಅವರು ಕೇವಲ ಸಿದ್ಧಾಂತದ (theory) ಬಗ್ಗೆ ಮಾತನಾಡಿದರು. ಅವರು V-model ಮತ್ತು shift-left ಬಗ್ಗೆ ಉಲ್ಲೇಖಿಸಿದರು. ಅವರು ಬರೆದ ಯಾವುದಾದರೂ ಒಂದು ಟೆಸ್ಟ್ ಬಗ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚಿದೆಯೇ ಎಂದು ನಾನು ಕೇಳಿದಾಗ, ಅವರು ಮೌನವಾಗಿದ್ದರು.
ಯಾವುದನ್ನಾದರೂ ವಿಫಲಗೊಳಿಸುವ (break) ಟೆಸ್ಟ್ ಅನ್ನು ಅವರು ಎಂದಿಗೂ ಬರೆದವರಲ್ಲ. ಅವರು ಕೇವಲ ಪಾಸಾಗುವ (pass) ಟೆಸ್ಟ್ಗಳನ್ನು ಮಾತ್ರ ಬರೆಯುತ್ತಿದ್ದರು.
ಸರ್ಟಿಫಿಕೇಟ್ಗಳು ನಿಮ್ಮ ನೆನಪಿನ ಶಕ್ತಿಯನ್ನು ಪರೀಕ್ಷಿಸುತ್ತವೆ. ಬಗ್ಗಳು ನಿಮ್ಮ ಆಲೋಚನಾ ಶಕ್ತಿಯನ್ನು ಪರೀಕ್ಷಿಸುತ್ತವೆ.
ಸರ್ಟಿಫಿಕೇಟ್ಗಳು ನಿಮಗೆ ಪದಕೋಶ ಮತ್ತು ರಚನೆಯನ್ನು ನೀಡುತ್ತವೆ. ಅವು ನೀವು ನೇಮಕಾತಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು (recruiter screens) ದಾಟಲು ಸಹಾಯ ಮಾಡುತ್ತವೆ. ಆದರೆ ದೋಷಗಳನ್ನು (defects) ಹೇಗೆ ಪತ್ತೆಹಚ್ಚಬೇಕು ಎಂಬುದನ್ನು ಅವು ಕಲಿಸುವುದಿಲ್ಲ.
ಪರೀಕ್ಷೆಯ ಪ್ರಶ್ನೆಗಳು ಪಠ್ಯಕ್ರಮವನ್ನು (syllabus) ಅನುಸರಿಸುತ್ತವೆ. ಆದರೆ ನೈಜ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಹಾಗಲ್ಲ. ಲಾಗಿನ್ ಫಾರ್ಮ್ಗೆ ಯಾವುದೇ ಪಠ್ಯಕ್ರಮ ಇರುವುದಿಲ್ಲ. ಅದರಲ್ಲಿ ವಿಚಿತ್ರವಾದ ಎಡ್ಜ್ ಕೇಸ್ಗಳು (edge cases) ಇರುತ್ತವೆ, ಉದಾಹರಣೆಗೆ ಸರ್ವರ್ ಗಡಿಯಾರವು ನಾಲ್ಕು ನಿಮಿಷಗಳ ವ್ಯತ್ಯಾಸದಲ್ಲಿದ್ದರೆ ಅಥವಾ ನಿರ್ದಿಷ್ಟ ಸಮಯದ ಸಮಸ್ಯೆಗಳಿದ್ದರೆ (timing issues).
ಸರ್ಟಿಫೈಡ್ ಟೆಸ್ಟರ್ ಒಂದು ಚೆಕ್ಲಿಸ್ಟ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತಾರೆ. ಅವರು ಅವಶ್ಯಕತೆಗಳ (requirements) ಆಧಾರದ ಮೇಲೆ ಟೆಸ್ಟ್ಗಳನ್ನು ಬರೆಯುತ್ತಾರೆ ಮತ್ತು ಅವುಗಳನ್ನು ಪಾಸ್ ಅಥವಾ ಫೇಲ್ ಎಂದು ಗುರುತಿಸುತ್ತಾರೆ.
ಬಗ್ ಹಂಟರ್ (bug hunter) ಟೆಸ್ಟಿಂಗ್ ಅನ್ನು ಒಂದು ತನಿಖೆಯಂತೆ ಪರಿಗಣಿಸುತ್ತಾರೆ. ಅವರು ಒಂದು ಕಲ್ಪನೆಯೊಂದಿಗೆ (hypothesis) ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ಅವರು ಅಪ್ಲಿಕೇಶನ್ ತಪ್ಪಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ.
ಮನಸ್ಥಿತಿಯ (mindset) ವ್ಯತ್ಯಾಸವನ್ನು ಗಮನಿಸಿ.
ಒಂದು ಸಾಮಾನ್ಯ ಟೆಸ್ಟ್ 'ಹ್ಯಾಪಿ ಪಾತ್' (happy path) ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ:
- ಉತ್ಪನ್ನಗಳಿಗೆ ಹೋಗಿ.
- ಕಾರ್ಟ್ಗೆ ಸೇರಿಸಿ.
- ಮಾನ್ಯವಾದ ಕಾರ್ಡ್ ವಿವರಗಳನ್ನು ನಮೂದಿಸಿ.
- ಆರ್ಡರ್ ಕನ್ಫರ್ಮೇಶನ್ ನಿರೀಕ್ಷಿಸಿ.
ಎಲ್ಲವೂ ಸರಿಯಾಗಿದ್ದಾಗ ಫೀಚರ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಈ ಟೆಸ್ಟ್ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಇದು ಎಂದಿಗೂ ಬಗ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚಲಾರದು.
ಬಗ್ ಹಂಟರ್ ಟೆಸ್ಟ್ ಅನುಮಾನಾಸ್ಪದವಾಗಿರುತ್ತದೆ:
- ಕಾರ್ಡ್ ಸಂಖ್ಯೆಯಲ್ಲಿ ತಪ್ಪನ್ನು (typo) ನಮೂದಿಸಿ.
- ಎರರ್ ಮೆಸೇಜ್ (error message) ನಿರೀಕ್ಷಿಸಿ.
- ಆದರೂ ಆರ್ಡರ್ ಕನ್ಫರ್ಮೇಶನ್ ಕಾಣಿಸಿಕೊಳ್ಳಲಿಲ್ಲ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
ಎರಡನೇ ಟೆಸ್ಟ್ ಅಪ್ಲಿಕೇಶನ್ ವಿಫಲವಾಗುತ್ತದೆ ಎಂದು ಭಾವಿಸುತ್ತದೆ. ಅದು ಕೇಳುತ್ತದೆ: "ಇದು ಎಲ್ಲಿ ಮುರಿದು ಬೀಳುತ್ತದೆ (break)?"
ಅನೇಕ ಟೆಸ್ಟರ್ಗಳಿಗೆ ಅನುಭವದಲ್ಲಿ ಕೊರತೆಯಿದೆ ಹೊರತು ಅವರ ರೆಸ್ಯೂಮೆಯಲ್ಲಿಲ್ಲ. ಕೆಟ್ಟ ಡೇಟಾ ಅಥವಾ ಡೌನ್ ಆಗಿರುವ ಎನ್ವಿರಾನ್ಮೆಂಟ್ನಿಂದಾಗಿ ಟೆಸ್ಟ್ಗಳು ವಿಫಲವಾಗುವುದನ್ನು ನೀವು ನೋಡಿದ್ದೀರಿ. ಆದರೆ ನೀವು ಲಾಜಿಕಿನಲ್ಲಿ ದೋಷವನ್ನು ಪತ್ತೆಹಚ್ಚಿದ್ದರಿಂದ ಟೆಸ್ಟ್ಗಳು ವಿಫಲವಾಗುವುದನ್ನು ನೀವು ನೋಡಿಲ್ಲ.
ಹೊಸ ಪರೀಕ್ಷೆಗಳಿಗಾಗಿ ಓದುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ವಿಫಲವಾಗುವಂತೆ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಟೆಸ್ಟ್ಗಳನ್ನು ಬರೆಯುವ ಮೂಲಕ ಆ ಕೊರತೆಯನ್ನು ತುಂಬಿರಿ.
ಈ ಅಭ್ಯಾಸವನ್ನು ಪ್ರಯತ್ನಿಸಿ: ಒಂದು ಫೀಚರ್ ಅನ್ನು ಆರಿಸಿ. ಅದನ್ನು ವಿಫಲಗೊಳಿಸಲು (break) ಒಂದು ಗಂಟೆ ಸಮಯವನ್ನು ವ್ಯಯಿಸಿ.
ಸರ್ಚ್ ಫೀಚರ್ಗಾಗಿ:
- ಅರ್ಥಹೀನ ಕ್ವೆರಿಗಳನ್ನು (gibberish queries) ಪರೀಕ್ಷಿಸಿ.
- SQL ಇಂಜೆಕ್ಷನ್ ಕ್ಯಾರೆಕ್ಟರ್ಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ.
- ಖಾಲಿ ಸ್ಟ್ರಿಂಗ್ಗಳನ್ನು (empty strings) ಪರೀಕ್ಷಿಸಿ.
ಫೈಲ್ ಅಪ್ಲೋಡ್ಗಾಗಿ:
- ಎಕ್ಸ್ಟೆನ್ಷನ್ ಇಲ್ಲದ ಫೈಲ್ಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ.
- ಬೃಹತ್ ಗಾತ್ರದ ಫೈಲ್ಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ.
- ಹಾನಿಕಾರಕ (malicious) ಫೈಲ್ ಹೆಸರುಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ.
ನಾನು ಒಮ್ಮೆ 95% ಕವರೇಜ್ ಹೊಂದಿದ್ದ ಪೇಮೆಂಟ್ ಸಿಸ್ಟಮ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ್ದೆ. ಪ್ರತಿಯೊಂದು ಟೆಸ್ಟ್ ಕೂಡ ಪಾಸಾಯಿತು. ನಂತರ, ರೌಂಡಿಂಗ್ ಎರರ್ನಿಂದಾಗಿ (rounding error) ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಸಿಸ್ಟಮ್ ಹಣವನ್ನು ಕಳೆದುಕೊಂಡಿತು. ನಮ್ಮ ಟೆಸ್ಟ್ಗಳು ಹ್ಯಾಪಿ ಪಾತ್ ಅನ್ನು (happy path) ಕವರ್ ಮಾಡಿದ್ದವು, ಆದರೆ ಯಾರೂ ಮ್ಯಾತ್ ಲಾಜಿಕ್ ಅನ್ನು ಟೆಸ್ಟ್ ಮಾಡಲು ಯೋಚಿಸಲಿಲ್ಲ.
ಈಗ, ನಾನು ಪ್ರತಿಯೊಂದು ಟೆಸ್ಟ್ ಅನ್ನು ಒಂದು ಪ್ರಶ್ನೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುತ್ತೇನೆ: "ಈ ಫೀಚರ್ ಮೌನವಾಗಿ ವಿಫಲವಾಗಲು (fail silently) ಏನಾಗಬೇಕಾಗುತ್ತದೆ?"
ಪೋರ್ಟ್ಫೋಲಿಯೊ ಸೈಟ್ ಅನ್ನು ನಿರ್ಮಿಸಬೇಡಿ. ನಿಮ್ಮ LinkedIn ಅನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಬೇಡಿ.
ವಿಫಲವಾಗುವಂತೆ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಒಂದು ಟೆಸ್ಟ್ ಬರೆಯಿರಿ. ಅದು ಪಾಸಾದರೆ, ನಿಮ್ಮ ಬಳಿ ಸುರಕ್ಷತೆಯ ಭರವಸೆ ಇದೆ. ಅದು ಫೇಲ್ ಆದರೆ, ನೀವು ಬಗ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚಿದ್ದೀರಿ ಎಂದರ್ಥ.
ನೀವು ಏನನ್ನು ಟೆಸ್ಟ್ ಮಾಡಿದ್ದೀರಿ, ಅದನ್ನು ಹೇಗೆ ಟೆಸ್ಟ್ ಮಾಡಿದ್ದೀರಿ ಮತ್ತು ನೀವು ಏನನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಬರೆಯಿರಿ. ನೀವು ಯೋಚಿಸಬಲ್ಲರೆಂಬುದು ಅದಕ್ಕೆ ನಿಜವಾದ ಸಾಕ್ಷಿ.
ನೀವು ಬಗ್ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಬಲ್ಲರೆಂದು ಸಾಬೀತುಪಡಿಸಲು ಈ ವಾರ ಬರೆಯುವ ಒಂದು ಟೆಸ್ಟ್ ಯಾವುದು?
ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯ: https://t.me/GyaanSetuAi