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

টেস্ট কেস ডিজাইন ও ম্যানেজমেন্ট

Test case design & management
৭ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

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

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

১ · একটি ভালো টেস্ট কেসের গঠন

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

প্রিকন্ডিশন (Preconditions)
টেস্ট শুরুর আগে সিস্টেমের অবস্থা কী হতে হবে — যেমন "ব্যবহারকারী রেজিস্টার্ড কিন্তু লগ-ইন করা নেই।"
স্টেপস (Steps)
ক্রমানুসারে ঠিক কী কী অ্যাকশন নিতে হবে — যেমন "১. লগইন পেজে যান ২. ভুল পাসওয়ার্ড লিখুন ৩. Submit চাপুন।"
প্রত্যাশিত ফলাফল (Expected Result)
ঠিক কী দেখা উচিত — যেমন "'ভুল পাসওয়ার্ড' এরর মেসেজ দেখাবে, ব্যবহারকারী লগ-ইন হবে না।"

এই তিনটি অংশ থাকলে যে কেউ (এমনকি অন্য একজন টেস্টার, বা ভবিষ্যতে একটি অটোমেশন স্ক্রিপ্ট — M7-এ বিস্তারিত) টেস্ট কেসটি ঠিক একইভাবে চালাতে পারবেন এবং ফলাফল নিয়ে দ্বিমত হবে না।

২ · টেস্ট কেস সংগঠিত করা

একটি বাস্তব প্রোডাক্টে শত শত টেস্ট কেস জমা হয়ে যায় — তাই সংগঠন ছাড়া দ্রুত সেগুলো ব্যবস্থাপনার অযোগ্য হয়ে পড়ে। তিনটি সাধারণ সংগঠন-অক্ষ:

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

বাস্তব টিমগুলো এই সংগঠন হাতে-কলমে স্প্রেডশিটে না করে TestRail, Zephyr, বা JIRA-এর টেস্ট ম্যানেজমেন্ট প্লাগইনের মতো ডেডিকেটেড টুল ব্যবহার করে — এগুলো ফিচার, প্রায়োরিটি, টাইপ অনুযায়ী ফিল্টার/ট্যাগ করার পাশাপাশি রান-হিস্ট্রি ও পাস/ফেল ট্রেন্ডও ট্র্যাক রাখে। এই কোর্স এই টুলগুলোর নির্দিষ্ট ইন্টারফেস শেখায় না, বরং তাদের পেছনের সাংগঠনিক নীতিগুলো শেখায়।

৩ · সীমিত সময়ে কোনটা আগে — ওয়েটেড স্কোরিং

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

Python
# প্রতিটি মানদণ্ডের ওজন — যোগফল অবশ্যই 1.0 হতে হবে
WEIGHTS = {
    "business_criticality": 0.5,
    "defect_likelihood": 0.3,
    "execution_ease": 0.2,   # দ্রুত/সহজে চালানো যায় এমন টেস্টকে সামান্য অগ্রাধিকার
}
assert abs(sum(WEIGHTS.values()) - 1.0) < 1e-9, "ওজনের যোগফল অবশ্যই ১.০ হতে হবে"

# প্রতিটি মানদণ্ড 1 (সর্বনিম্ন) থেকে 10 (সর্বোচ্চ) স্কেলে অনুমান করা হয়েছে
candidates = [
    {"name": "পেমেন্ট চেকআউট — সফল লেনদেন",      "business_criticality": 10, "defect_likelihood": 6, "execution_ease": 4},
    {"name": "প্রোফাইল ছবি আপলোড",                "business_criticality": 4,  "defect_likelihood": 5, "execution_ease": 8},
    {"name": "ডিসকাউন্ট কুপন — এজ-কেস",           "business_criticality": 7,  "defect_likelihood": 9, "execution_ease": 5},
    {"name": "ফুটার লিংক নেভিগেশন",                "business_criticality": 2,  "defect_likelihood": 2, "execution_ease": 9},
    {"name": "লগইন — ভুল পাসওয়ার্ড হ্যান্ডলিং",   "business_criticality": 8,  "defect_likelihood": 4, "execution_ease": 7},
]

def compute_score(case):
    return sum(WEIGHTS[criterion] * case[criterion] for criterion in WEIGHTS)

for case in candidates:
    case["score"] = round(compute_score(case), 2)

ranked = sorted(candidates, key=lambda c: c["score"], reverse=True)

print("সময় সীমিত হলে এই ক্রমে টেস্ট কেস লিখুন/চালান:")
for rank, case in enumerate(ranked, start=1):
    print(f"{rank}. {case['name']} — স্কোর: {case['score']}")

    
লক্ষ্য করুন "পেমেন্ট চেকআউট" (উচ্চ ক্রিটিক্যালিটি ১০) আর "ডিসকাউন্ট কুপন এজ-কেস" (উচ্চ ডিফেক্ট-সম্ভাবনা ৯) সবচেয়ে উপরে থাকে — যদিও একটাও দুই মানদণ্ডেই সর্বোচ্চ নয়, ওজনযুক্ত যোগফল সঠিকভাবে দুটোকেই "গুরুত্বপূর্ণ" হিসেবে চিহ্নিত করে। "ফুটার লিংক নেভিগেশন" সবার নিচে থাকে — যদিও চালাতে সবচেয়ে সহজ (৯), কম ক্রিটিক্যালিটি ও কম ডিফেক্ট-সম্ভাবনা তাকে নিচে টেনে নামায়, কারণ ক্রিটিক্যালিটি ও ডিফেক্ট-সম্ভাবনার ওজন (০.৫ + ০.৩ = ০.৮) execution_ease-এর ওজনের (০.২) চেয়ে অনেক বেশি।
মূল কথা · Key takeaway

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

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

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

প্র ০১ "লগইন ফিচার টেস্ট করুন" — এটি একটি ভালো টেস্ট কেস নয় কেন?

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

প্র ০২ টেস্ট কেস ফিচার অনুযায়ী সংগঠিত করার একটি সুবিধা কী, যা শুধু প্রায়োরিটি অনুযায়ী সংগঠিত করলে পাওয়া যায় না?

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

প্র ০৩ উপরের কোড সেলে যদি WEIGHTS-এ execution_ease-এর ওজন বাড়িয়ে ০.৬ করা হয় (আর অন্য দুটো কমিয়ে যোগফল ১.০ রাখা হয়), র‍্যাঙ্কিং-এ কী পরিবর্তন আসতে পারে বলে মনে করেন?

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

অনুশীলন

  1. চিন্তা করুন: "ব্যবহারকারী লগ-আউট করলে সেশন শেষ হয়ে যায়" এই আচরণের জন্য একটি সম্পূর্ণ টেস্ট কেস লিখুন — প্রিকন্ডিশন, স্টেপস, প্রত্যাশিত ফলাফলসহ।

    প্রিকন্ডিশন: ব্যবহারকারী সফলভাবে লগ-ইন করা আছে। স্টেপস: ১. "লগ-আউট" বাটনে ক্লিক করুন ২. পেছনের বাটন দিয়ে আগের পেজে ফিরে যাওয়ার চেষ্টা করুন। প্রত্যাশিত ফলাফল: ব্যবহারকারীকে লগইন পেজে পাঠানো হবে, এবং পুরনো সেশন টোকেন দিয়ে কোনো সুরক্ষিত পেজ অ্যাক্সেস করা যাবে না।

  2. পরিবর্তন করুন: উপরের কোড সেলে candidates-এ আপনার নিজের একটি ষষ্ঠ টেস্ট কেস (নাম ও তিনটি স্কোর সহ) যোগ করুন, তারপর Run চেপে দেখুন এটি কোথায় র‍্যাঙ্ক করে।

    উদাহরণস্বরূপ, যদি আপনি {"name": "সার্চ রেজাল্ট সাজানো", "business_criticality": 5, "defect_likelihood": 5, "execution_ease": 6} যোগ করেন, তার স্কোর হবে 0.5*5 + 0.3*5 + 0.2*6 = 2.5 + 1.5 + 1.2 = 5.2 — যা "প্রোফাইল ছবি আপলোড"-এর (৫.১) ঠিক উপরে, তালিকার মাঝামাঝি জায়গায় স্থান পাবে।

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

  • কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ টেস্ট ডিজাইন টেকনিক, ইউনিট টেস্টিং, টেস্ট ডাবলস, কভারেজ, অটোমেশন, পারফরম্যান্স ও সিকিউরিটি টেস্টিং, টেস্ট ম্যানেজমেন্ট ও CI/CD ইন্টিগ্রেশন — সব একসাথে।
  • পরের পাঠ: ডিফেক্ট/বাগ লাইফসাইকেল L48 একটি বাগ রিপোর্ট হওয়ার পর থেকে বন্ধ হওয়া পর্যন্ত কোন কোন অবস্থা দিয়ে যায়, আর কীভাবে "রিওপেন" ঘটে — একটি সত্যিকারের স্টেট মেশিন দিয়ে।
  • সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps, Computer Networks, Operating Systems, Computer Architecture, Programming Languages & Compiler Design, Software Engineering & Git, Theory of Computation, Engineering Economics, Full-Stack Web Frameworks, Mobile App Development, Ethics in Computing & AI Safety ও Software Testing & Quality Assurance — সব এক জায়গায়।
আগের পাঠ
টেস্ট প্ল্যানিং ও স্ট্র্যাটেজি