Edge Case and Corner Case

ধরো, তুমি একটি লিফট তৈরি করছো। নিয়ম অনুযায়ী এই লিফটে ১ থেকে ১০ জন মানুষ উঠতে পারে। সিস্টেমটি চমৎকারভাবে কাজ করছে—দরজা খুলছে, বন্ধ হচ্ছে, সবাই খুশি।

তুমি সিস্টেমটি টেস্ট করার সময় ১ জন উঠিয়ে চেক করলে, আবার ১০ জন উঠিয়েও চেক করলে। লিফট পারফেক্টলি চললো। এই যে তুমি একদম সর্বনিম্ন (১) এবং সর্বোচ্চ (১০) সীমানায় টেস্ট করলে—এগুলোই হলো Edge Case।

হঠাৎ একদিন, লিফটে ১০ জন মানুষ উঠলো, যাদের প্রত্যেকেই ওজনে বেশ ভারী এবং তাদের সাথে অতিরিক্ত মালামালও রয়েছে। সিস্টেমের কাউন্ট অনুযায়ী ১০ জন (Valid), কিন্তু ওজনের কারণে লিফট আর নড়লো না! অর্থাৎ, আলাদাভাবে কন্ডিশনগুলো ঠিক থাকলেও, যখন একাধিক Extreme কন্ডিশন একসাথে মিলে গেল, তখন সিস্টেম ক্র্যাশ করলো। এটাই হলো Corner Case।

সফটওয়্যার ইঞ্জিনিয়ারিংয়ে তুমি যতই সাধারণ (Happy Path) টেস্ট করো না কেন, ইউজাররা সাধারণত এই অস্বাভাবিক কিন্তু সম্ভাব্য Extreme পরিস্থিতিগুলোতেই সবচেয়ে বেশি বাগ (Bug) রিপোর্ট করে।

Edge Case কী

Edge Case হলো এমন একটি পরিস্থিতি, যেখানে একটি মাত্র ইনপুট বা ভ্যারিয়েবল তার সাধারণ সীমার (Boundary) একেবারে শেষ প্রান্তে অবস্থান করে। সফটওয়্যার টেস্টিংয়ে এটি বের করার জন্য Boundary Value Analysis (BVA) টেকনিক ব্যবহার করা হয়।

সিস্টেম সাধারণ অবস্থায় ঠিক চললেও, সীমানার একদম প্রান্তে গিয়ে কোড ব্রেক করতে পারে।

  • উদাহরণ ১: পাসওয়ার্ড ফিল্ডে ঠিক ৮ ক্যারেক্টারের ইনপুট দেওয়া (মিনিমাম সীমা)।

  • উদাহরণ ২: ইউজারনেম ফিল্ডে ঠিক ২০ ক্যারেক্টার দেওয়া (ম্যাক্সিমাম সীমা)।

  • উদাহরণ ৩: অডিও ভলিউম ঠিক ০% বা ১০০% এ সেট করা।

Corner Case কী

Corner Case তখন তৈরি হয়, যখন একাধিক ইনপুট, ভ্যারিয়েবল বা কন্ডিশন একসাথে তাদের Extreme অবস্থায় পৌঁছায়। এরা প্রত্যেকে আলাদাভাবে Valid বা হ্যান্ডেল করা থাকলেও, একসাথে ঘটলে সিস্টেম কনফিউজড হয়ে যায় বা ক্র্যাশ করে।

  • উদাহরণ ১: ইউজার ঠিক ২০ ক্যারেক্টারের ইউজারনেম দিলো (Valid), সাথে ৫MB সাইজের ম্যাক্সিমাম লিমিটের প্রোফাইল পিকচার আপলোড করলো (Valid), এবং তার ইন্টারনেট কানেকশন খুবই স্লো (External factor)। এই ৩টি বিষয় একসাথে মিলে সার্ভারে টাইমআউট ঘটিয়ে দিলো।

  • উদাহরণ ২: একই মিলি-সেকেন্ডে দুইজন ইউজার ডাটাবেসের একই রো (Row) আপডেট করার চেষ্টা করলো (যাকে Race Condition বলা হয়)।

User Registration Form এর Edge ও Corner Case এনালাইসিস

ধরা যাক, তুমি একটি ইউজার রেজিস্ট্রেশন ফর্ম বানাচ্ছো। এর ফিল্ডগুলো হলো:

  • Username (৩-২০ ক্যারেক্টার)

  • Password (৬-২০ ক্যারেক্টার)

  • Age (১-১২০ বছর)

  • Email (সঠিক ইমেইল ফরম্যাট)

নিচে এই ফর্মের বিভিন্ন Edge এবং Corner Case গুলো গভীরভাবে বিশ্লেষণ করা হলো:

Username Field এর টেস্টিং

  • Boundary/Edge Cases: ঠিক ৩ ক্যারেক্টার (Minimum) এবং ঠিক ২০ ক্যারেক্টার (Maximum) দেওয়া।

  • Invalid Boundaries: ২ ক্যারেক্টার (Below min) বা ২১ ক্যারেক্টার (Above max) দেওয়া।

  • White Spaces: শুধু স্পেস দিয়ে সাবমিট করা (" ") অথবা নামের আগে-পেছনে স্পেস দেওয়া (" user ")।

  • Security & Encoding: ইউনিকোড ক্যারেক্টার (যেমন: 🙂 বা ইউজার), অথবা SQL Injection এর চেষ্টা করা (' OR '1'='1)।

Password Field এর টেস্টিং

  • Boundary/Edge Cases: ঠিক ৬ ক্যারেক্টার এবং ঠিক ২০ ক্যারেক্টার ইনপুট।

  • Content Types: শুধু স্পেস দিয়ে পাসওয়ার্ড সেট করার চেষ্টা করা, অথবা পুরোটাই স্পেশাল ক্যারেক্টার (!@#$%^) দিয়ে পূর্ণ করা।

  • Pasting Limit: ইউজার যদি কপি করে ১০০ ক্যারেক্টারের পাসওয়ার্ড পেস্ট করে, তবে সিস্টেম সেটি ট্রাঙ্কেট (Truncate) করছে নাকি ক্র্যাশ করছে তা চেক করা।

Age Field এর টেস্টিং

  • Data Type Mismatch: বয়সের জায়গায় স্ট্রিং ("twenty"), ফ্লোট (12.5) বা স্পেশাল ক্যারেক্টার দেওয়া।

  • Logical Boundaries: একদম ০ বা -১ দেওয়া, অথবা অবাস্তব বয়স (যেমন: ৯৯৯) দেওয়া।

  • Null Handling: API এর মাধ্যমে ডেটা পাঠানোর সময় age ফিল্ডে null পাস করা।

Email Field এর টেস্টিং

  • Format Breaking: @ চিহ্ন না থাকা (userexample.com), ডোমেইন না থাকা (user@.com), বা ইউজারনেম না থাকা (@example.com)।

  • Plus Addressing: জিমেইলের ক্ষেত্রে + সাইন ব্যবহার করা (যেমন: user+test@example.com), যা অনেক ভ্যালিডেটর রিজেক্ট করে দেয়।

  • Extreme Length: ২৫৪ ক্যারেক্টারের বিশাল বড় একটি ইমেইল অ্যাড্রেস ইনপুট দেওয়া।

Multi-field Corner Cases (আসল চ্যালেঞ্জ)

  • Maximum Payload: প্রতিটি ফিল্ডে ম্যাক্সিমাম ক্যারেক্টার দেওয়া। ইউজারনেম ২০ ক্যারেক্টার, পাসওয়ার্ড ২০ ক্যারেক্টার, ২৫৪ ক্যারেক্টারের ইমেইল এবং ১২০ বয়স—সব ডেটা একসাথে ডাটাবেস কলামের সাইজ লিমিট অতিক্রম করে কি না তা চেক করা।

  • Double Submission: নেটওয়ার্ক স্লো থাকা অবস্থায় ইউজার যদি "Register" বাটনে খুব দ্রুত ডাবল ক্লিক (বা ৩-৪ বার ক্লিক) করে, তবে সিস্টেমে ডুপ্লিকেট ইউজার তৈরি হচ্ছে কি না (Idempotency চেক)।

  • Encoding Clash: ইউজারনেমে জাপানিজ ক্যারেক্টার এবং ইমেইলে স্পেশাল ক্যারেক্টার—একাধিক এনকোডিং রিকোয়ারমেন্ট একসাথে প্রসেস করা।