1000 ದೋಷಗಳು, ಒಂದು Google Sheet, ಮತ್ತು ನಾನು ಎಂದಿಗೂ ಮರಳಿ ಪಡೆಯಲಾಗದ ಐದು ಗಂಟೆಗಳು
ಪ್ರತಿಯೊಂದು ಬಗ್ಗೂ ಒಂದು ಕಥೆಯಿದೆ. ಹೆಚ್ಚಿನವುಗಳು "ಇದು ನನ್ನ ಮಷೀನ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ" ಎಂಬ ವಾಕ್ಯದೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತವೆ.
ನಾವು ಒಂದು ಲೀಡ್ ಜನರೇಷನ್ (lead generation) ಕಂಪನಿಗಾಗಿ ಡೇಟಾ ಇಂಪೋರ್ಟ್ ಫೀಚರ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದೆವು. ಆ ಫೀಚರ್ ಸರಳವಾಗಿ ಕಾಣುತ್ತಿತ್ತು. ನೀವು ಇಂಪೋರ್ಟ್ ಬಟನ್ ಕ್ಲಿಕ್ ಮಾಡಿ, ಸ್ಪ್ರೆಡ್ಶೀಟ್ ಅಪ್ಲೋಡ್ ಮಾಡಿದರೆ ಸಾಕು, ಸಿಸ್ಟಮ್ ಸಂಪರ್ಕಗಳನ್ನು (contacts) ಲೋಡ್ ಮಾಡುತ್ತದೆ. ಎಲ್ಲರೂ ಅದು ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಭಾವಿಸಿದ್ದರು.
ಆ ಭಾವನೆಯೇ ಒಂದು ಬಲೆ.
ಆ ಭಾವನೆಯನ್ನು ಮುರಿಯುವುದೇ ಟೆಸ್ಟರ್ಗಳ ಕೆಲಸ. "ಹ್ಯಾಪಿ ಪಾತ್" (happy path) ಯಾವಾಗಲೂ ನಿಮಗೆ ಸುಳ್ಳು ಹೇಳುತ್ತದೆ.
ನಾವು ಒಂದು ಕ್ಲೀನ್ ಎಕ್ಸೆಲ್ (Excel) ಫೈಲ್ ಬಳಸಿದ್ದರೆ, ಇಂಪೋರ್ಟ್ ಯಶಸ್ವಿಯಾಗಿರುತ್ತಿತ್ತು. ನಾವು ಮಧ್ಯಾಹ್ನದ ಊಟಕ್ಕೆ ಹೋಗಬಹುದಿತ್ತು ಅಥವಾ ಆ ಫೀಚರ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಬಹುದಿತ್ತು. ಆದರೆ ಒಬ್ಬ ಗ್ರಾಹಕರು ಸೋಮವಾರ ಬೆಳಿಗ್ಗೆ ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ (production) ಆ ಬಗ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತಿದ್ದರು.
ಸಮಸ್ಯೆ ಎಲ್ಲಿಂದ ಎದುರಾಯಿತೆಂದರೆ ಅದು Google Sheet ಇತ್ತು.
ನೈಜ ಬಳಕೆದಾರರು ಯಾವಾಗಲೂ ಕ್ಲೀನ್ ಎಕ್ಸೆಲ್ ಫೈಲ್ಗಳನ್ನು ಬಳಸುವುದಿಲ್ಲ. ಅವರು ಅಸ್ತವ್ಯಸ್ತವಾದ Google Sheets ಬಳಸುತ್ತಾರೆ. ಸಿಸ್ಟಮ್ಗಳು ಅವರ ಅಸ್ತವ್ಯಸ್ತತೆಯನ್ನು ನಿಭಾಯಿಸಬೇಕೆಂದು ಅವರು ನಿರೀಕ್ಷಿಸುತ್ತಾರೆ.
ನಾವು Google Sheet ಡೇಟಾವನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಿದಾಗ, ಸಿಸ್ಟಮ್ ವಿಫಲವಾಯಿತು. ನಮಗೆ 1,000 ಕ್ಕೂ ಹೆಚ್ಚು ದೋಷಗಳು ಕಂಡುಬಂದವು. ಸ್ಕ್ರೀನ್ ಪೂರ್ತಿ ದೋಷಗಳಿಂದ ತುಂಬಿಹೋಯಿತು. ಕೇವಲ ಮೂಲ ಫಾರ್ಮ್ಯಾಟ್ (source format) ಬದಲಾದ ಕಾರಣಕ್ಕಾಗಿ, ಅದೇ ಬಟನ್ ಮತ್ತು ಅದೇ ಡೇಟಾ ಟೈಪ್ ಸಂಪೂರ್ಣ ವಿಫಲತೆಯನ್ನು ಉಂಟುಮಾಡಿತು.
ಹೆಚ್ಚಿನ ಪರೀಕ್ಷೆಗಾಗಿ ನಾವು ಮತ್ತೆ ಎಕ್ಸೆಲ್ಗೆ ಮರಳಿದೆವು. ನಾವು ಸರಿಯಾದ ಮತ್ತು ತಪ್ಪಾದ ರೋ (rows) ಗಳ ಮಿಶ್ರಣವನ್ನು ಪ್ರಯತ್ನಿಸಿದೆವು. ಸಿಸ್ಟಮ್ ಅದನ್ನು ಚೆನ್ನಾಗಿ ನಿಭಾಯಿಸಿತು. ಅದು ತಪ್ಪಾದ ರೋಗಳನ್ನು ಬಿಟ್ಟು ಮುಂದಕ್ಕೆ ಸಾಗಿತು.
ನಂತರ ನಾವು ನೈಜ ಪ್ರಪಂಚದ ಅಸ್ತವ್ಯಸ್ತತೆಯನ್ನು ಪರೀಕ್ಷಿಸಿದೆವು. ನೂರಾರು ರೋಗಳಿರುವ ಬಲ್ಕ್ ಫೈಲ್ ಅನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಿದೆವು. ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಕಸವಾಗಿದ್ದವು (garbage). ಕೇವಲ ಕೆಲವು ಮಾತ್ರ ಸರಿಯಾಗಿದ್ದವು.
ಸಿಸ್ಟಮ್ ಸಂಪೂರ್ಣವಾಗಿ ಕುಸಿದುಹೋಯಿತು. ವ್ಯಾಲಿಡೇಶನ್ ಲಾಜಿಕ್ (validation logic) ಕೆಲವು ತಪ್ಪಾದ ರೋಗಳಿಗೆ ಕೆಲಸ ಮಾಡಿತು, ಆದರೆ ದೋಷಪೂರಿತ ಡೇಟಾದ ಬೆಟ್ಟದ ಅಡಿಯಲ್ಲಿ ಅದು ಸೋತುಹೋಯಿತು.
ಮೂಲ ಕಾರಣವನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಾವು ಐದು ಗಂಟೆಗಳನ್ನು ವ್ಯಯಿಸಿದೆವು. ನಾವು ಸ್ಕ್ರೀನ್ಗಳನ್ನೇ ದಿಟ್ಟಿಸಿ ನೋಡಿದೆವು, ಪರೀಕ್ಷೆಗಳನ್ನು ಮತ್ತೆ ಮಾಡಿದೆವು ಮತ್ತು ಫೈಲ್ಗಳು, ಬ್ರೌಸರ್ ಹಾಗೂ ಕಾಫಿಯನ್ನೇ ದೂಷಿಸಿದೆವು.
ಆ ಐದು ಗಂಟೆಗಳು ಅಗ್ಗವಾಗಿದ್ದವು. ಇಲ್ಲದಿದ್ದರೆ, ಒಬ್ಬ ಗ್ರಾಹಕರು ತಮ್ಮ ಮಧ್ಯಾಹ್ನವನ್ನು ಕಳೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತಿತ್ತು ಮತ್ತು ನಮ್ಮ ಉತ್ಪನ್ನದ ಮೇಲಿನ ನಂಬಿಕೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತಿತ್ತು. ಟೆಸ್ಟಿಂಗ್ನಲ್ಲಿ ಬಗ್ಗಳಿದ್ದರೆ ಸಮಯವನ್ನು ಪಾವತಿಸಬೇಕಾಗುತ್ತದೆ. ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಬಗ್ಗಳಿದ್ದರೆ ಗ್ರಾಹಕರನ್ನು ಕಳೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ.
ನಾನು ಪ್ರತಿ ಬಾರಿಯೂ ಆ ಐದು ಗಂಟೆಗಳನ್ನೇ ಆರಿಸಿಕೊಳ್ಳುತ್ತೇನೆ.
ಒಬ್ಬ ಉತ್ತಮ ಟೆಸ್ಟರ್ ಫೀಚರ್ ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ ಎಂದು ಕೇಳುವುದಿಲ್ಲ. ಬದಲಾಗಿ, ಅದನ್ನು ಹೇಗೆ ಮುರಿಯಬಹುದು (break) ಎಂದು ಕೇಳುತ್ತಾನೆ.
ಒಬ್ಬ ಡೆವಲಪರ್ನಂತೆ ಯೋಚಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಈ ಕೆಳಗಿನವರಂತೆ ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸಿ:
- ತಪ್ಪು ಫೈಲ್ ಫಾರ್ಮ್ಯಾಟ್ ಅಪ್ಲೋಡ್ ಮಾಡುವ ಸೋಮಾರಿ ಬಳಕೆದಾರ.
- ಮರ್ಜ್ಡ್ ಸೆಲ್ಸ್ (merged cells) ಮತ್ತು ಖಾಲಿ ರೋಗಳಿರುವ ಅಸ್ತವ್ಯಸ್ತ ಬಳಕೆದಾರ.
- 10 ಕ್ಲೀನ್ ರೆಕಾರ್ಡ್ಗಳ ಬದಲಿಗೆ 4,000 ಅಸ್ತವ್ಯಸ್ತವಾದ ರೆಕಾರ್ಡ್ಗಳನ್ನು ಹೊಂದಿರುವ ಬಲ್ಕ್ ಬಳಕೆದಾರ.
- ಮಾಡಬಾರದ ಕೆಲಸವನ್ನು ಮಾಡಿಯೇ ತೀರುವ ತೊಂದರೆ ಕೊಡುವ ವ್ಯಕ್ತಿ.
ನೀವು ನಿರೀಕ್ಷಿಸದ ಇನ್ಪುಟ್ಗಳ (inputs) ಕಾರಣದಿಂದ ಸಾಫ್ಟ್ವೇರ್ ಮುರಿದುಬೀಳುತ್ತದೆ.
ಅತ್ಯಂತ "ಸರಳ" ಎಂದು ಕಾಣುವ ಫೀಚರ್ಗಳೇ ಹೆಚ್ಚಾಗಿ ಅಪಾಯಕಾರಿಯಾಗಿರುತ್ತವೆ. ಇಂಪೋರ್ಟ್ ಬಟನ್, ಸರ್ಚ್ ಬಾಕ್ಸ್ ಮತ್ತು ಕಾಂಟ್ಯಾಕ್ಟ್ ಫಾರ್ಮ್ ಹಾನಿಕಾರಕವಲ್ಲದಂತೆ ಕಾಣುತ್ತವೆ. ಆದರೆ ಅವು ಹಾಗಲ್ಲ.
ಒಂದು ಫೀಚರ್ "ಹ್ಯಾಪಿ ಪಾತ್" ಅನ್ನು ಪಾಸು ಮಾಡಿದರೆ, ಅಲ್ಲಿಗೆ ನಿಲ್ಲಬೇಡಿ. "ನಾನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಬಹುದಾದ ಅತ್ಯಂತ ಕೆಟ್ಟ ಫೈಲ್ ಅನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಿದರೆ ಏನಾಗುತ್ತದೆ?" ಎಂದು ಕೇಳುವ ವ್ಯಕ್ತಿಯಾಗಿರಿ.
ನಂತರ ಅದನ್ನು ಮಾಡಿ ನೋಡಿ.
Optional learning community: https://t.me/GyaanSetuAi