१० प्रमाणपत्रे असलेला टेस्टर, ज्याला एकही बग सापडला नाही
तुमच्याकडे सर्व प्रकारची प्रमाणपत्रे आहेत. ISTQB, ScrumMaster, Cloud आणि Security. तुमचा रिझ्युमे संक्षिप्त शब्दांनी (acronyms) भरलेला आहे.
पण तुम्ही असा एकही टेस्ट लिहू शकत नाही जो एखादा खरा बग शोधू शकेल.
गेल्या तिमाहीत मी एका उमेदवाराची मुलाखत घेतली. ते फक्त सिद्धांतांबद्दल (theory) बोलत होते. त्यांनी V-model आणि shift-left चा उल्लेख केला. जेव्हा मी त्यांना त्यांनी लिहिलेला असा एखादा टेस्ट दाखवायला सांगितला ज्याने एखादा बग पकडला होता, तेव्हा ते शांत राहिले.
त्यांनी कधीही असा टेस्ट लिहिला नव्हता ज्याने काहीतरी बिघडवले (break) असेल. त्यांनी फक्त 'पास' होणारे टेस्ट लिहिले होते.
प्रमाणपत्रे तुमच्या स्मरणशक्तीची परीक्षा घेतात. बग्स तुमच्या विचार करण्याच्या क्षमतेची परीक्षा घेतात.
प्रमाणपत्रे तुम्हाला शब्दसंग्रह आणि रचना प्रदान करतात. ती तुम्हाला रिक्रूटर्सच्या (recruiters) स्क्रीनिंगमध्ये मदत करतात. पण ती तुम्हाला दोष (defects) कसे शोधायचे हे शिकवत नाहीत.
परीक्षेचे प्रश्न एका अभ्यासक्रमाचे (syllabus) पालन करतात. वास्तविक ॲप्लिकेशन्स तसे करत नाहीत. लॉगिन फॉर्मचा कोणताही अभ्यासक्रम नसतो. त्यामध्ये विचित्र 'edge cases' असतात, जसे की सर्व्हरची वेळ चार मिनिटे मागे असणे किंवा विशिष्ट टाइमिंगच्या समस्या.
प्रमाणित टेस्टर (certified tester) चेकलिस्टचे पालन करतो. ते गरजांनुसार (requirements) टेस्ट लिहितात आणि त्यांना 'pass' किंवा 'fail' म्हणून मार्क करतात.
बग हंटर (bug hunter) टेस्टिंगला एका तपासाप्रमाणे (investigation) पाहतो. ते एका गृहितकापासून (hypothesis) सुरुवात करतात. ते ॲप्लिकेशन चुकीचे आहे हे सिद्ध करण्याचा प्रयत्न करतात.
विचारसरणीतील (mindset) फरक पहा.
एक मानक टेस्ट (standard test) 'happy path' तपासते:
- प्रॉडक्ट्सवर जा.
- कार्टमध्ये ॲड करा.
- कार्डचे वैध तपशील भरा.
- ऑर्डर कन्फर्मेशनची अपेक्षा करा.
ही टेस्ट हे सिद्ध करते की जेव्हा सर्व काही परिपूर्ण असते तेव्हा फीचर काम करते. यामुळे कधीही बग सापडणार नाही.
बग हंटरची टेस्ट संशयास्पद असते:
- कार्ड नंबरमध्ये स्पेलिंगची चूक (typo) करून प्रविष्ट करा.
- एरर मेसेजची अपेक्षा करा.
- तरीही ऑर्डर कन्फर्मेशन आले नाही ना, याची खात्री करा.
दुसरी टेस्ट असे गृहीत धरते की ॲप्लिकेशन फेल होईल. ती विचारते: "हे कुठे तुटते (break होते)?"
अनेक टेस्टर्समध्ये अनुभवाचा अभाव असतो, त्यांच्या रिझ्युमेमध्ये नाही. तुम्ही चुकीचा डेटा किंवा डाऊन एन्व्हायर्नमेंटमुळे (down environments) टेस्ट फेल होताना पाहिल्या असतील. पण लॉजिकमधील त्रुटीमुळे टेस्ट फेल होताना तुम्ही पाहिली नसेल.
नवीन परीक्षांसाठी अभ्यास करणे थांबवा. फेल होण्यासाठी डिझाइन केलेल्या टेस्ट लिहून हा फरक भरून काढा.
हा सराव करून पहा: एक फीचर निवडा. ते बिघडवण्याचा (break करण्याचा) प्रयत्न करण्यासाठी एक तास द्या.
सर्च फीचरसाठी:
- अर्थहीन (gibberish) क्वेरीज तपासा.
- SQL injection कॅरेक्टर्स तपासा.
- रिकाम्या स्ट्रिंग्स (empty strings) तपासा.
फाईल अपलोडसाठी:
- एक्सटेंशन नसलेल्या फाईल्स तपासा.
- खूप मोठ्या आकाराच्या फाईल्स तपासा.
- घातक (malicious) फाईल नावे तपासा.
मी एकदा ९५% कव्हरेज असलेल्या एका पेमेंट सिस्टमवर काम केले होते. प्रत्येक टेस्ट पास झाली होती. त्यानंतर, राउंडिंग एररमुळे (rounding error) प्रोडक्शनमध्ये सिस्टमचे नुकसान झाले. आमच्या टेस्ट्समध्ये 'हॅपी पाथ' (happy path) कव्हर झाला होता, पण कोणालाही मॅथ लॉजिक (math logic) टेस्ट करण्याचा विचार सुचला नाही.
आता, मी प्रत्येक टेस्ट एका प्रश्नाने सुरू करतो: "हे फीचर शांतपणे (silently) फेल होण्यासाठी नक्की काय घडले पाहिजे?"
पोर्टफोलिओ साइट बनवू नका. तुमचे LinkedIn अपडेट करू नका.
फेल होण्यासाठी डिझाइन केलेली एक टेस्ट लिहा. जर ती पास झाली, तर तुमच्याकडे सुरक्षिततेची खात्री आहे. जर ती फेल झाली, तर तुम्हाला बग (bug) सापडला आहे.
तुम्ही काय टेस्ट केले, ते कसे टेस्ट केले आणि तुम्हाला काय आढळले, हे लिहून ठेवा. तुम्ही विचार करू शकता याचे ते खरे प्रमाण आहे.
तुम्ही बग शोधू शकता हे सिद्ध करण्यासाठी या आठवड्यात तुम्ही कोणती एक टेस्ट लिहाल?
पर्यायी लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi