পাঠ ৪৪ · ৫৭-এর মধ্যে · মডিউল ১০
Home / Courses / Software Testing & Quality Assurance / এক্সপ্লোরেটরি টেস্টিং

এক্সপ্লোরেটরি টেস্টিং

Exploratory testing
৯ মিনিট পড়া অ্যাডভান্সড আলোচনা-ভিত্তিক সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • এক্সপ্লোরেটরি টেস্টিং কী এবং স্ক্রিপ্টেড টেস্টিং থেকে এটি ঠিক কীভাবে আলাদা
  • এটি কেন বিশেষভাবে "ভাবাই হয়নি এমন" বাগ খুঁজে বের করতে কার্যকর
  • সেশন-বেসড এক্সপ্লোরেটরি টেস্টিং (SBTM) কী এবং একটি ভালো চার্টার কেমন দেখতে হয়
  • কখন এক্সপ্লোরেটরি টেস্টিং বেছে নেবেন, কখন স্ক্রিপ্টেড/স্বয়ংক্রিয় টেস্টিং (M7/L28) বেছে নেবেন

১ · এক্সপ্লোরেটরি টেস্টিং কী

এক্সপ্লোরেটরি টেস্টিংExploratory Testingএকজন দক্ষ টেস্টার একই সাথে সফটওয়্যার সম্পর্কে শেখেন, পরবর্তী টেস্ট ডিজাইন করেন ও চালান — আগে থেকে লেখা স্ক্রিপ্ট অনুসরণ না করে। এই কোর্সের এখন পর্যন্ত প্রায় সব আলোচনা ছিল স্ক্রিপ্টেড টেস্টিং নিয়ে — M2-এ টেস্ট ডিজাইন টেকনিক দিয়ে আগে থেকে টেস্ট কেস ঠিক করা, তারপর M3-M7-এ সেগুলো (ম্যানুয়ালি বা স্বয়ংক্রিয়ভাবে) চালানো। এই পদ্ধতিতে "কী টেস্ট করব" এবং "কীভাবে টেস্ট করব" প্রশ্নগুলোর উত্তর টেস্ট চালানোর আগেই ঠিক হয়ে যায়।

এক্সপ্লোরেটরি টেস্টিং-এ এই তিনটি কাজ — শেখা, ডিজাইন করা, চালানো — সময়ের সাথে ক্রমাগত মিশে থাকে। একজন টেস্টার অ্যাপ্লিকেশনের একটি অংশ ব্যবহার করেন, তার আচরণ সম্পর্কে কিছু শেখেন, সেই নতুন জ্ঞান থেকে পরবর্তী মুহূর্তে কী চেষ্টা করবেন তা সিদ্ধান্ত নেন, সেটি চালান, তা থেকে আরও শেখেন — এভাবে চক্রাকারে চলতে থাকে। এটি দক্ষতা-নির্ভর কারণ ভালো এক্সপ্লোরেটরি টেস্টিং-এর জন্য অ্যাপ্লিকেশনের ডোমেইন সম্পর্কে বোঝাপড়া, "এখানে কী ভুল হতে পারে" এই অনুমান করার ক্ষমতা, এবং কৌতূহল দরকার — যা একটি নির্দিষ্ট স্ক্রিপ্ট অনুসরণ করার চেয়ে অনেক বেশি কিছু।

স্ক্রিপ্টেড টেস্টিং টেস্ট ডিজাইন টেস্ট লিখে রাখা টেস্ট চালানো এক্সপ্লোরেটরি টেস্টিং শেখা ডিজাইন করা চালানো তিনটি কাজ একই সাথে, ক্রমাগত একে অপরকে প্রভাবিত করে — আগে থেকে আলাদা করা যায় না
স্ক্রিপ্টেড টেস্টিং-এ ডিজাইন, লেখা ও চালানো তিনটি আলাদা, ক্রমিক ধাপ — এক্সপ্লোরেটরি টেস্টিং-এ শেখা, ডিজাইন করা ও চালানো একটি একক, ক্রমাগত চক্র হিসেবে মিশে থাকে।

২ · কেন এটি স্ক্রিপ্টেড টেস্টিং যা পারে না তা করে

একটি প্রি-ডিফাইন্ড টেস্ট কেস শুধুমাত্র সেই জিনিসটাই চেক করতে পারে যা টেস্ট-লেখক লেখার সময় চিন্তা করেছিলেন। কিন্তু বাস্তব জগতের অনেক সিরিয়াস বাগ ঠিক সেই জায়গায় লুকিয়ে থাকে যেখানে কেউ চিন্তাই করেনি সমস্যা হতে পারে — দুটো ফিচারের মধ্যে একটি অস্বাভাবিক ইন্টার‍্যাকশন, একটি নির্দিষ্ট ক্রমে ধাপগুলো করলে দেখা দেওয়া সমস্যা, অথবা একটি ভিজ্যুয়াল/ইউজেবিলিটি সমস্যা যা কোনো assertEqual দিয়ে ধরাই সম্ভব নয়। একজন দক্ষ এক্সপ্লোরেটরি টেস্টার অ্যাপ্লিকেশনের সাথে সরাসরি ইন্টার‍্যাক্ট করার সময় এই ধরনের জিনিস লক্ষ্য করেন এবং সাথে সাথে সেই সূত্র অনুসরণ করে আরও গভীরে যান — এটি একটি স্থির স্ক্রিপ্টের পক্ষে করা অসম্ভব।

M7/L28-এর সাথে সম্পর্ক — কী অটোমেট করবেন, কী ম্যানুয়াল রাখবেন

M7/L28-এ বলা হয়েছিল স্থিতিশীল, পুনরাবৃত্তিমূলক, নির্ধারক (deterministic) চেক অটোমেট করা উচিত, আর এক্সপ্লোরেটরি/ইউজেবিলিটি/দ্রুত-পরিবর্তনশীল-UI চেক ম্যানুয়াল রাখা উচিত। এই পাঠ ঠিক সেই "ম্যানুয়াল রাখা উচিত" তালিকার সবচেয়ে গুরুত্বপূর্ণ আইটেমটির গভীরে যায় — এক্সপ্লোরেটরি টেস্টিং সংজ্ঞা অনুযায়ীই অটোমেট করা যায় না, কারণ এর মূল মূল্য মানুষের রিয়েল-টাইম বিচারবুদ্ধি ও অভিযোজন থেকে আসে, যা একটি স্ক্রিপ্টে আগে থেকে লেখা সম্ভব নয়।

৩ · সেশন-বেসড এক্সপ্লোরেটরি টেস্টিং (SBTM)

"এক্সপ্লোরেটরি টেস্টিং" মানে "যা খুশি তাই করা" নয় — সম্পূর্ণ দিকহীন এক্সপ্লোরেশন ফলাফলে অসামঞ্জস্যপূর্ণ ও রিপোর্ট করা কঠিন। বাস্তব-জগতে দলগুলো সেশন-বেসড টেস্ট ম্যানেজমেন্ট (SBTM) নামের একটি হালকা কাঠামো ব্যবহার করে — প্রতিটি এক্সপ্লোরেশন একটি টাইম-বক্সড সেশন (সাধারণত ৩০-৯০ মিনিট), যার শুরুতে একটি স্পষ্ট চার্টার (মিশন) লিখে রাখা হয়। সেশন শেষে টেস্টার একটি সংক্ষিপ্ত রিপোর্ট লেখেন — কী পরীক্ষা করা হলো, কী পাওয়া গেল, কী প্রশ্ন উঠল।

চার্টার
এক বাক্যে সেশনের লক্ষ্য — কী এলাকা এক্সপ্লোর করা হবে এবং কী ধরনের সমস্যা খোঁজা হচ্ছে। যথেষ্ট নির্দিষ্ট যাতে ফোকাস থাকে, যথেষ্ট খোলা যাতে স্বাধীনভাবে অনুসন্ধান করা যায়।
টাইম-বক্স
একটি নির্দিষ্ট সময়সীমা (যেমন ৩০, ৬০, বা ৯০ মিনিট) — এটি ফোকাস বজায় রাখে এবং একাধিক টেস্টারের কাজ তুলনাযোগ্য/পরিকল্পনাযোগ্য করে তোলে।
সেশন রিপোর্ট
সেশন শেষে সংক্ষিপ্ত নোট — কভার করা এলাকা, পাওয়া বাগ, বাকি থাকা প্রশ্ন। এটি এক্সপ্লোরেশনের ফলাফলকে দৃশ্যমান ও ট্র্যাকযোগ্য রাখে (M11/L50-এর টেস্ট রিপোর্টিং নীতির সাথে সামঞ্জস্যপূর্ণ)।

৪ · একটি সম্পূর্ণ ওয়ার্কড চার্টার উদাহরণ

ধরা যাক একটি ই-কমার্স অ্যাপ্লিকেশনের চেকআউট ফ্লো নিয়ে একটি সেশন পরিকল্পনা করা হচ্ছে। একটি ভালো চার্টার সাধারণত এই ফরম্যাট মেনে চলে: "[এলাকা] এক্সপ্লোর করুন [সরঞ্জাম/টেকনিক] ব্যবহার করে, [লক্ষ্য/উদ্বেগ] খুঁজে বের করার জন্য।"

উদাহরণ চার্টার

মিশন: "চেকআউট ফ্লো এক্সপ্লোর করুন অস্বাভাবিক পেমেন্ট পরিমাণ ব্যবহার করে (শূন্য, নেগেটিভ, খুব ছোট দশমিক, খুব বড় সংখ্যা, একাধিক মুদ্রার মিশ্রণ), মূল্য গণনা বা অর্ডার নিশ্চিতকরণে ভাঙন খুঁজে বের করার জন্য।"

টাইম-বক্স: ৩০ মিনিট।
সেশন চার্টার-এর ভেতরে থাকা প্রশ্নগুলো (টেস্টার নিজেকে সেশন চলাকালীন জিজ্ঞেস করেন):

  • কার্টে একটি আইটেমের পরিমাণ (quantity) 0 বা নেগেটিভ করা গেলে টোটাল কী দেখায়?
  • একটি কুপন কোড একাধিকবার প্রয়োগ করার চেষ্টা করলে কী হয়?
  • চেকআউট পেজ খোলা রেখে অন্য ট্যাবে গিয়ে দাম পরিবর্তন হওয়া একটি প্রোডাক্ট আবার যোগ করলে টোটাল আপডেট হয়?
  • পেমেন্ট প্রসেসিং চলাকালীন ব্যাক বাটন চাপলে ডাবল-চার্জ হওয়ার সম্ভাবনা আছে কি?

লক্ষ্য করুন এই প্রশ্নগুলো আগে থেকে সব লেখা নেই — টেস্টার সেশনের সময় প্রথম প্রশ্নের ফলাফল দেখে হয়তো সম্পূর্ণ নতুন একটি প্রশ্ন ভাববেন যা তালিকায় ছিল না। এটাই এক্সপ্লোরেটরি টেস্টিং-এর জোর — চার্টার দিকনির্দেশনা দেয়, কিন্তু পথ বেঁধে দেয় না।

সেশন শেষে রিপোর্টে লেখা হতে পারে: "৩০ মিনিটে চেকআউট মূল্য গণনার ৪টি দিক কভার হয়েছে; একটি সম্ভাব্য বাগ পাওয়া গেছে (কুপন কোড দুইবার প্রয়োগ করলে ডিসকাউন্ট দুইবার প্রয়োগ হয়ে যাচ্ছে); ব্যাক-বাটন ডাবল-চার্জ প্রশ্নটি নিশ্চিতভাবে যাচাই করা যায়নি, পরবর্তী সেশনে অগ্রাধিকার দেওয়া উচিত।" — এই ধরনের একটি সংক্ষিপ্ত, সৎ রিপোর্টই সেশন-বেসড এক্সপ্লোরেটরি টেস্টিং-কে দলের কাছে দৃশ্যমান ও কার্যকর করে তোলে, নিছক "অনানুষ্ঠানিক ঘোরাঘুরি" নয়।
মূল কথা · Key takeaway

এক্সপ্লোরেটরি টেস্টিং স্ক্রিপ্টেড/স্বয়ংক্রিয় টেস্টিং-এর প্রতিদ্বন্দ্বী নয়, পরিপূরক — যা ইতিমধ্যে জানা এবং স্থিতিশীল, সেটির জন্য অটোমেশন (M7); যা এখনো অজানা এবং মানুষের বিচারবুদ্ধি দরকার, সেটির জন্য দক্ষ, চার্টার- গাইডেড এক্সপ্লোরেশন। দুটোই একটি পরিণত টেস্টিং স্ট্র্যাটেজির (M11/L46) অংশ হওয়া উচিত।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ "এক্সপ্লোরেটরি টেস্টিং মানে দক্ষতাহীন, এলোমেলো ক্লিক করা" — এই ধারণাটি কেন ভুল?

কারণ ভালো এক্সপ্লোরেটরি টেস্টিং আসলে অত্যন্ত দক্ষতা-নির্ভর — একজন দক্ষ টেস্টার অ্যাপ্লিকেশনের ডোমেইন বোঝেন, ঝুঁকিপূর্ণ এলাকা চিনতে পারেন, এবং একটি পর্যবেক্ষণ থেকে দ্রুত পরবর্তী প্রাসঙ্গিক প্রশ্ন তৈরি করতে পারেন। এলোমেলো ক্লিকিং-এর সাথে পার্থক্য হলো — এটি একটি স্পষ্ট চার্টার, টাইম-বক্স, এবং একটি অভিজ্ঞ মনের "এখানে কী ভুল হতে পারে" এই সক্রিয় অনুমান দিয়ে পরিচালিত। এই কারণেই একজন নতুন টেস্টার ও একজন অভিজ্ঞ টেস্টার একই অ্যাপ্লিকেশনে একই সময় দিয়ে সম্পূর্ণ ভিন্ন মানের ফলাফল পান।

প্র ০২ একটি বাগ এক্সপ্লোরেটরি সেশনে পাওয়া গেল যা কোনো লিখিত টেস্ট কেসে ছিল না। এরপর কী করা উচিত এই বাগটি নিয়ে দীর্ঘমেয়াদে?

বাগটি ঠিক করার পর, এই নির্দিষ্ট পরিস্থিতিকে (যেমন উপরের কুপন-দুইবার-প্রয়োগ কেস) একটি স্থায়ী রিগ্রেশন টেস্ট (M5/L22) হিসেবে যোগ করা উচিত — সম্ভব হলে অটোমেটেড। এভাবে এক্সপ্লোরেটরি টেস্টিং শুধু একটি বাগ ধরেই থেমে থাকে না, বরং ভবিষ্যতে সেই একই বাগ আবার ফিরে এলে স্বয়ংক্রিয়ভাবে ধরা পড়বে তা নিশ্চিত করে — এক্সপ্লোরেশন ও অটোমেশন একে অপরকে শক্তিশালী করে।

প্র ০৩ একটি টিম লিড বলছেন, "আমাদের সব রিগ্রেশন টেস্ট অটোমেটেড আছে, তাই ম্যানুয়াল/এক্সপ্লোরেটরি টেস্টিং-এর আর দরকার নেই" — এই যুক্তির সমস্যা কী?

অটোমেটেড রিগ্রেশন টেস্ট শুধু ইতিমধ্যে জানা আচরণ যাচাই করে — যা টেস্ট-লেখক আগে থেকে ভেবে লিখে রেখেছেন। এটি নতুন ফিচারে বা ফিচারগুলোর মধ্যে অপ্রত্যাশিত ইন্টার‍্যাকশনে থাকা নতুন, অজানা বাগ কখনোই খুঁজে বের করতে পারবে না — কারণ সংজ্ঞা অনুযায়ীই কেউ এখনো সেই টেস্ট কেসটি লেখেনি। এক্সপ্লোরেটরি টেস্টিং ঠিক এই ফাঁকটাই পূরণ করে, এবং এটি M1/L04-এর "exhaustive testing is impossible" নীতির একটি ব্যবহারিক প্রতিক্রিয়া — যেহেতু সবকিছু আগে থেকে লেখা সম্ভব নয়, একজন দক্ষ মানুষের অভিযোজিত অনুসন্ধান এখনো অপরিহার্য।

অনুশীলন

  1. চিন্তা করুন: একটি সোশ্যাল মিডিয়া অ্যাপের "পোস্ট শেয়ার করা" ফিচারের জন্য একটি ৪৫-মিনিটের এক্সপ্লোরেটরি টেস্টিং সেশনের চার্টার লিখুন (উপরের ফরম্যাট অনুসরণ করে: এলাকা + টেকনিক + লক্ষ্য)।

    একটি সম্ভাব্য চার্টার: "পোস্ট শেয়ার করা ফিচার এক্সপ্লোর করুন অস্বাভাবিক কন্টেন্ট টাইপ ব্যবহার করে (খুব দীর্ঘ টেক্সট, ইমোজি-শুধু পোস্ট, একাধিক ভাষার মিশ্রণ, একসাথে অনেকগুলো ছবি/ভিডিও), শেয়ার করার পর প্রিভিউ বা নোটিফিকেশন ভেঙে যায় কি না খুঁজে বের করার জন্য।" — লক্ষ্য করুন এটি একটি নির্দিষ্ট এলাকায় ফোকাসড, কিন্তু ঠিক কোন কোন নির্দিষ্ট পদক্ষেপ নেওয়া হবে তা আগে থেকে বেঁধে দেয়নি।

  2. বিশ্লেষণ করুন: উপরের চেকআউট চার্টার উদাহরণে "একাধিক মুদ্রার মিশ্রণ" এলাকাটি এক্সপ্লোর করার সময় টেস্টার একটি সম্পূর্ণ নতুন পর্যবেক্ষণ করলেন — কারেন্সি পরিবর্তন করলে পুরনো কারেন্সিতে যোগ করা কার্ট আইটেম হারিয়ে যাচ্ছে। এটি মূল চার্টারের সাথে সম্পর্কিত হলেও চার্টারে লেখা প্রশ্নগুলোর কোনোটিতেই সরাসরি ছিল না। এক্ষেত্রে টেস্টারের কী করা উচিত?

    এই পর্যবেক্ষণটি অনুসরণ করা উচিত — এটাই এক্সপ্লোরেটরি টেস্টিং-এর মূল মূল্য, একটি অপ্রত্যাশিত সূত্র পাওয়া গেলে সাথে সাথে সেই দিকে গভীরে যাওয়া, এমনকি তা মূল চার্টারের বাইরে সামান্য বেরিয়ে গেলেও (যতক্ষণ না এটি সম্পূর্ণ ভিন্ন, অসম্পর্কিত একটি এলাকায় চলে যায়)। সেশন রিপোর্টে এই আবিষ্কারটি স্পষ্টভাবে নোট করে রাখা উচিত, প্রয়োজনে একটি আলাদা বাগ রিপোর্ট হিসেবে, যাতে এটি দলের কাছে দৃশ্যমান থাকে এবং হারিয়ে না যায়।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
ফাজ টেস্টিং