১০টি সার্টিফিকেট থাকা সত্ত্বেও যে টেস্টার একটি বাগ খুঁজে পেল না
আপনার কাছে সব ধরণের সার্টিফিকেট আছে। ISTQB, ScrumMaster, Cloud এবং Security। আপনার জীবনবৃত্তান্ত (resume) শুধু সংক্ষিপ্ত শব্দের (acronyms) একটি দেয়াল।
কিন্তু আপনি এমন একটি টেস্টও লিখতে পারেন না যা একটি আসল বাগ (bug) খুঁজে বের করতে পারে।
গত প্রান্তিকে আমি একজন প্রার্থীর ইন্টারভিউ নিয়েছিলাম। তিনি কেবল তাত্ত্বিক কথা বলছিলেন। তিনি V-model এবং shift-left সম্পর্কে উল্লেখ করেছিলেন। যখন আমি তাকে এমন একটি টেস্ট দেখাতে বললাম যা তিনি লিখেছিলেন এবং সেটি একটি বাগ ধরেছিল, তিনি চুপ হয়ে গেলেন।
তিনি এমন কোনো টেস্ট কখনো লেখেননি যা কোনো কিছু ভেঙে ফেলে (break)। তিনি কেবল সেই টেস্টগুলোই লিখতেন যা পাস (pass) হয়।
সার্টিফিকেট আপনার স্মৃতিশক্তি পরীক্ষা করে। বাগ পরীক্ষা করে আপনার চিন্তাশক্তি।
সার্টিফিকেট আপনাকে শব্দভাণ্ডার এবং কাঠামো প্রদান করে। এগুলো আপনাকে রিক্রুটারদের বাছাই প্রক্রিয়ায় (recruiter screens) উত্তীর্ণ হতে সাহায্য করে। কিন্তু এগুলো আপনাকে ত্রুটি (defects) খুঁজে বের করতে শেখায় না।
পরীক্ষার প্রশ্ন একটি সিলেবাস অনুসরণ করে। কিন্তু বাস্তব অ্যাপ্লিকেশনそう করে না। একটি লগইন ফর্মের কোনো সিলেবাস থাকে না। এতে অদ্ভুত সব 'এজ কেস' (edge cases) থাকে, যেমন সার্ভারের ঘড়ি চার মিনিট পিছিয়ে থাকা বা নির্দিষ্ট টাইমিং সংক্রান্ত সমস্যা।
একজন সার্টিফাইড টেস্টার একটি চেকলিস্ট অনুসরণ করেন। তারা রিকোয়ারমেন্ট (requirements) থেকে টেস্ট লেখেন এবং সেগুলোকে পাস বা ফেল হিসেবে চিহ্নিত করেন।
একজন বাগ হান্টার (bug hunter) টেস্টিং-কে একটি তদন্তের মতো বিবেচনা করেন। তারা একটি হাইপোথিসিস (hypothesis) দিয়ে শুরু করেন। তারা অ্যাপ্লিকেশনটিকে ভুল প্রমাণ করার চেষ্টা করেন।
মানসিকতার পার্থক্যটি দেখুন।
একটি সাধারণ টেস্ট 'হ্যাপি পাথ' (happy path) পরীক্ষা করে:
- প্রোডাক্টস পেজে যান।
- কার্টে যোগ করুন।
- সঠিক কার্ডের তথ্য দিন।
- অর্ডার কনফার্মেশন আশা করুন।
এই টেস্টটি প্রমাণ করে যে সবকিছু নিখুঁত থাকলে ফিচারটি কাজ করে। এটি কখনোই কোনো বাগ খুঁজে পাবে না।
একজন বাগ হান্টারের টেস্ট হয় সন্দেহপ্রবণ:
- টাইপোসহ একটি কার্ড নম্বর দিন।
- একটি এরর মেসেজ (error message) আশা করুন।
- পরীক্ষা করুন যে অর্ডার কনফার্মেশনটি তবুও প্রদর্শিত হয়নি কি না।
দ্বিতীয় টেস্টটি ধরে নেয় যে অ্যাপ্লিকেশনটি ব্যর্থ হবে। এটি প্রশ্ন করে: "এটি কোথায় ভেঙে পড়বে?"
অনেক টেস্টারের অভিজ্ঞতায় ঘাটতি থাকে, তাদের জীবনবৃত্তান্তে নয়। আপনি দেখেছেন খারাপ ডেটা বা ডাউন এনভায়রনমেন্টের কারণে টেস্ট ব্যর্থ হয়েছে। কিন্তু আপনি এমন কোনো টেস্ট ব্যর্থ হতে দেখেননি যা লজিকের কোনো ত্রুটি খুঁজে পাওয়ার কারণে ব্যর্থ হয়েছে।
নতুন পরীক্ষার জন্য পড়া বন্ধ করুন। ব্যর্থ হওয়ার জন্য ডিজাইন করা টেস্ট লিখে এই ঘাটতি পূরণ করুন।
এই অনুশীলনটি চেষ্টা করে দেখুন: একটি ফিচার বেছে নিন। সেটি ভেঙে ফেলার চেষ্টা করতে এক ঘণ্টা সময় দিন।
একটি সার্চ ফিচারের জন্য:
- অর্থহীন (gibberish) কুয়েরি দিয়ে টেস্ট করুন।
- SQL ইনজেকশন ক্যারেক্টার দিয়ে টেস্ট করুন।
- খালি স্ট্রিং (empty strings) দিয়ে টেস্ট করুন।
একটি ফাইল আপলোডের জন্য:
- এক্সটেনশনহীন ফাইল দিয়ে টেস্ট করুন।
- বিশাল আকারের ফাইল দিয়ে টেস্ট করুন।
- ক্ষতিকারক (malicious) ফাইলের নাম দিয়ে টেস্ট করুন।
আমি একবার ৯৫% কভারেজ সম্পন্ন একটি পেমেন্ট সিস্টেম নিয়ে কাজ করেছিলাম। প্রতিটি টেস্ট পাস করেছিল। তারপর, রাউন্ডিং এররের (rounding error) কারণে প্রোডাকশনে সিস্টেমটি টাকা হারিয়ে ফেলে। আমাদের টেস্টগুলো 'হ্যাপি পাথ' (happy path) কভার করেছিল, কিন্তু কেউ গণিতের লজিক টেস্ট করার কথা ভাবেনি।
এখন, আমি প্রতিটি টেস্ট একটি প্রশ্ন দিয়ে শুরু করি: "এই ফিচারটি নিঃশব্দে ব্যর্থ হওয়ার জন্য কী কী শর্ত পূরণ হওয়া প্রয়োজন?"
একটি পোর্টফোলিও সাইট তৈরি করবেন না। আপনার লিঙ্কডইন (LinkedIn) আপডেট করবেন না।
এমন একটি টেস্ট লিখুন যা ব্যর্থ হওয়ার জন্য ডিজাইন করা হয়েছে। যদি এটি পাস করে, তবে আপনার কাছে একটি নিরাপত্তার নিশ্চয়তা আছে। যদি এটি ব্যর্থ হয়, তবে আপনি একটি বাগ (bug) খুঁজে পেয়েছেন।
আপনি কী টেস্ট করেছেন, কীভাবে করেছেন এবং কী পেয়েছেন তা লিখে রাখুন। এটাই আসল প্রমাণ যে আপনি চিন্তা করতে পারেন।
আপনি এই সপ্তাহে কোন একটি টেস্ট লিখবেন যা প্রমাণ করবে যে আপনি বাগ খুঁজে পেতে পারেন?
Optional learning community: https://t.me/GyaanSetuAi