Importance of white box testing and real scenario example

বাংলাদেশে বেশিরভাগ QA এখনো শুধুই UI ভিত্তিক টেস্টিং করে। কিন্তু modern QA/SDET role এ White-Box Testing ছাড়া কোন সিস্টেমই নির্ভুলভাবে validate করা যায় না।

White-Box Testing কি এবং কেন এটি গুরুত্বপূর্ণ:

White-Box Testing এমন একটি টেস্টিং পদ্ধতি যেখানে QA ইঞ্জিনিয়ার শুধুমাত্র UI দেখে সিদ্ধান্ত নেন না, বরং সিস্টেমের অভ্যন্তরীণ কাজগুলো বুঝে যাচাই করেন। এর মধ্যে থাকে কোড, ডাটা ফ্লো, API Behaviour, সিকিউরিটি রুল, Caching, ব্যাকগ্রাউন্ড জব, Dependency flow এবং অন্যান্য internal logic. একারনে Whitebox testing কে বলা হয় Glassbox বা Clearbox testing technique.

সংক্ষেপে বলতে গেলে,

White-Box Testing মানে ভিতরের লজিক ও কোড বুঝে টেস্ট করা।

Black-Box এবং White-Box এর পার্থক্য:

Black-Box Testing শুধু দেখে UI level থেকে সবকিছু ঠিক আছে কিনা।

যেমন:

• UI ঠিকমতো দেখাচ্ছে কিনা
• Requirement অনুযায়ী কাজ করছে কিনা
• Success response পাওয়া যাচ্ছে কিনা
• Functionality কাজ করছে কিনা
• কোনো Error দেখা যাচ্ছে কিনা

White-Box Testing নিশ্চিত করে system এর ভিতর থেকে সবকিছু সঠিকভাবে কাজ করছে কিনা।

যেমন:

• ভিতরের লজিক ভেঙে গেছে কিনা
• ব্যাকগ্রাউন্ডে কোনো Silent Failure হচ্ছে কিনা
• Performance সংক্রান্ত বাধা তৈরি হচ্ছে কিনা
• Error swallow হয়ে গেছে কিনা

Software Testing এ কেন শুধুমাত্র Black-Box যথেষ্ট নয়:

1. Logic Validation: Business rule সঠিকভাবে কোডে প্রয়োগ হয়েছে কিনা এটি কোড না বুঝলে শনাক্ত করা কঠিন।
2. Edge Case Handling: If-else, loop, condition coverage Black-Box দিয়ে 100% statement coverage ans 100% decision coverage প্রায় অসম্ভব।
3. API এবং Integration Behaviour: Data কীভাবে flow হচ্ছে, কোথায় transform হচ্ছে এবং response কীভাবে তৈরি হচ্ছে এগুলো White-Box ছাড়া বোঝা যায় না।
4. Security Assurance: Auth, JWT validation, permission check বা encryption এর ভুলগুলো UI দিয়ে ধরা কঠিন।
5. Background Systems: Queue processor, cron job, retry logic, caching engine এসব component সম্পূর্ণরূপে hidden থাকে।
6. Shift-Left Testing Support: Developer যখন নির্দিষ্ট feature branch এ কাজ করে, QA যদি White-Box বোঝে তাহলে UI আসার আগেই sanity এবং feature testing করা

Shift-Left Model এ White-Box Testing এর ভূমিকা

Agile environment এ developer নতুন feature গুলো আলাদা আলাদা branch এ তৈরি করে। যখন একটা একটা করে ফিচার ডেভেলপ করা হয়ে যায় তখন QA সবগুলো ফিচার একসাথে merge হওয়ার অপেক্ষা না করে নির্দিষ্ট ব্রাঞ্চে সুইচ করে ফিচার ও স্যানিটি টেস্টিং এর কাজ শুরু করে দিতে পারে।

Shift-Left এ QA সাধারণত যেসব কাজ করে:

• Feature PR review
• API contract এবং logic validation
• Unit test behavior analysis
• DB migration (if needed)
• Merge এর আগেই integration logic testing

ফলাফল:

• Bug আগে থেকেই প্রতিরোধ করা যায়
• Merge এর পর ঝুঁকি কমে
• UI তৈরি হওয়ার আগেই Quality নিশ্চিত হয়

Whitebox testing approach in real life scenario:

1. OTP Verification Without SMS Gateway: যখন staging environment এ SMS পাঠানোর সুযোগ নেই অথবা SMS gateway down, তখন Terminal log বা DB টেবিল থেকে generated OTP সংগ্রহ করে UI তে verify করা হয়। এটি কেবল তখনই সম্ভব যখন সিস্টেমের অভ্যন্তরীণ স্ট্রাকচার জানা থাক
2. Sandbox KYC verification with Same NID: ধরা যাক একটা সিস্টেমে এক্টাই Sandbox NID আছে যেটা দিয়ে User এর KYC verify করা যায়। এখন আপনি যদি অনেকগুলো account registration করে Test করতে হয়, তখন কি করবেন? তখন DB তে NID ফিল্ডটিকে null বা blank করে দিতে হয়। UI বা Requirement দিয়ে এটি সম্ভব নয
3. Third-Party API Failure Simulation: External API (যেমন Payment, KYC বা Fraud API) যদি কোন কারনে ডাউন থাকে, তখন সিস্টেম এর বিহেভ কিভাবে টেস্ট করবেন? এই ধরনের টেস্ট করতে ENV ফাইলে ইচ্ছাকৃতভাবে ভুল URL দেওয়া হয় যাতে System fallback ঠিকমতো কাজ করছে কিনা তা যাচাই করা হয়।
4. Payment Checkout During Gateway Down: ধরুন, payment gateway down আছে, কিন্তু আপনাকে নিশ্চিত করতে হবে payment সফল হলে order আসলে confirm হয় কি না। তখন আপনি payment API-কে mock করে success, failure এবং timeout—এই তিন ধরনের response simulate করবেন, যাতে gateway বাস্তবে up না থাকলেও পুরো checkout flow যাচাই করা যায়। Success response এ দেখবেন order “Confirmed” হচ্ছে কিনা, failure এ “Failed/Cancelled” অবস্থায় যাচ্ছে এবং rollback/refund logic ঠিকমতো কাজ করছে কিনা, আর timeout এ checkout flow retry করছে বা pending state নিচ্ছে কিনা—এসব মিলিয়ে mock response ব্যবহার করে নিশ্চিত করা যায় যে order lifecycle, rollback workflow এবং error handling সম্পূর্ণভাবে সঠিকভাবে কাজ করছে।
5. QR Payment Without RFID Device: ধরুন, আপনার কাছে কোনো physical kiosk বা RFID ডিভাইস নেই। কিন্তু আপনাকে QR-based বা RFID-based payment flow ঠিকমতো কাজ করছে কিনা সেটা টেস্ট করতে হবে। তখন কী করবেন? Physical kiosk বা RFID ডিভাইস না থাকলে RFID API তে manual payload পাঠিয়ে QR বা RFID ভিত্তিক payment flow পরীক্ষা করা হয়।
6. Root-Cause Analysis via Logs: Customer report করেছে "Checkout fail হচ্ছে" বা "Notification আসছে না" UI দিয়ে সমস্যার কারণ বোঝা যাবে না। কীভাবে টেস্ট/ডিবাগ করা হয়: Log trace দেখে কোন function-এ error, কোন parameter null, কোন dependency fail তা নির্ণয় করা • Stack trace → ফাইল, লাইন নাম্বার, function name এটি কোড স্ট্রাকচার বুঝলে সম্ভব।
7. Sanity Testing: Developer payment module পরিবর্তন করলে পুরো সিস্টেম না টেস্ট করে কেবল commit diff দেখে সংশ্লিষ্ট dependency অনুযায়ী checkout, invoice, refund বা webhook এর অংশগুলো sanity test করা হয়।
8. Token Expiry Time: ধরুন, আপনার token-এর expiry সময় ২৪ ঘণ্টা, কিন্তু QA বাস্তবে ২৪ ঘণ্টা অপেক্ষা করে verify করা সম্ভব নয়। তখন কী করবেন? আপনি token-এর lifetime সাময়িকভাবে ৬০ সেকেন্ড করে দেবেন, যাতে দ্রুতই expiry simulate হয় এবং তারপর success, failure ও logout/unauthorized flow ঠিকমতো কাজ করছে কিনা—অর্থাৎ token expire হওয়ার পর API access বন্ধ হচ্ছে কি না, refresh mechanism trigger হচ্ছে কি না, এবং session handling সঠিকভাবে কাজ করছে কি না—এই পুরো lifecycle অল্প সময়েই verify করা যায়।
9. Cron/Background job testing: ধরুন, আপনার cron job প্রতি রাত ১২টায় execute হয়, কিন্তু QA হিসেবে আপনি সঙ্গে সঙ্গে verify করতে চাইছেন যে cron-এর কাজ সঠিকভাবে হচ্ছে কি না। তখন কী করবেন? আপনি cron-এর schedule সাময়িকভাবে প্রতি ১০ মিনিটে রান করার মতো করে বদলে নেবেন, যাতে দ্রুত execution ট্রিগার হয় এবং job আসলে ঠিকমতো চলছে কিনা—যেমন data cleanup, auto-update, notification dispatch বা যেকোনো scheduled workflow—সবকিছু স্বল্প সময়ে পরীক্ষা করা যায়, রাত ১২টা পর্যন্ত অপেক্ষা না করেই।
10. Geo location testing: ধরুন, আপনাকে চট্টগ্রাম শহরের nearby restaurant feature টেস্ট করতে হবে, কিন্তু আপনি আছেন ঢাকায়। বাস্তবে সেখানে যাওয়া সম্ভব নয়। তখন কী করবেন? আপনি manually চট্টগ্রামের latitude–longitude payload পাঠিয়ে Redis-এর GEO radius check simulate করবেন, যাতে সিস্টেম চট্টগ্রামকে nearest location হিসেবে শনাক্ত করছে কি না, distance-based logic ঠিকভাবে কাজ করছে কি না, আর zone-based validation সঠিক হচ্ছে কি না এসব ভ্রমণ ছাড়াই যাচাই করা যায়।

উপরের সবগুলো উদাহরণ প্রমাণ করে যে White-Box Testing real সফটওয়্যার সিস্টেমের জটিল ফিচারগুলো দ্রুত এবং নির্ভুলভাবে যাচাই করার জন্য অপরিহার্য। শুধু UI বা requirement দেখলে এগুলোর কোনোটিই সঠিকভাবে বোঝা বা টেস্ট করা সম্ভব নয়।

একজন আধুনিক QA বা SDET শুধু UI টেস্টার নয়। তারা configuration পরিবর্তন করতে পারে, data manipulate করতে পারে, API mock করতে পারে, time simulation করতে পারে, device behavior simulate করতে পারে, logs বিশ্লেষণ করতে পারে এবং business logic validate করতে পারে।

এটাই আধুনিক মানের Quality Assurance Engineering।

আপনি কি regular testing-এ White-Box পদ্ধতির কিছু অংশ ব্যবহার করেন? আপনার অভিজ্ঞতা কী?