Test case নকশা — equivalence partitioning, boundary value আর decision table

১ · কেন test case নকশা করতে হয় — অসীম ইনপুট, সীমিত সময়

একটি কাল্পনিক বিশ্ববিদ্যালয়ের ফল-পোর্টালের কথা ভাবুন। একটি ঘরে শিক্ষক নম্বর লেখেন, আর system grade বসায়। নিয়মটিও কাল্পনিক: ০–৩৯ F, ৪০–৫৯ C, ৬০–৭৯ B, ৮০–১০০ A; এর বাইরে কিছু লিখলে system সেটি গ্রহণ করবে না। এমন একটি ঘর ঠিক আছে কি না যাচাই করতে কয়টি test লাগবে?

Integer ধরলেও বৈধ মানই ১০১টি। এর সাথে আছে ঋণাত্মক সংখ্যা, ১০০-র বেশি সংখ্যা, দশমিক, খালি ঘর, অক্ষর, বাংলা অঙ্ক “৪৫”। আর একটি পাতায় এমন ঘর থাকে দশটি — সব মিলনের সংখ্যা তখন কার্যত অসীম। সব ইনপুট চালিয়ে দেখাকে বলে exhaustive testing, আর বাস্তব software-এ এটি অসম্ভব। তাই প্রশ্ন বদলে যায়: সবচেয়ে কম test দিয়ে সবচেয়ে বেশি ভুল ধরার সম্ভাবনা কীভাবে? এর উত্তরই test design technique.

একটি test case-এর অন্তত চারটি অংশ থাকে: পূর্বশর্ত (যেমন শিক্ষক লগইন করেছেন), ইনপুট (নম্বর 40), প্রত্যাশিত ফল (grade C), আর চালানোর পরের অবস্থা। প্রত্যাশিত ফল কোথা থেকে আসবে, সেটি ঠিক করার উৎসকে বলে test oracle — এখানে requirement-এর নিয়মটি। প্রত্যাশিত ফল আগে লিখতে হয়; চালানোর পরে যা এল তা দেখে “এটাই তো ঠিক” বলা আসলে যাচাই নয়।

এই পর্বের কৌশলগুলো প্রায় সবই black-box: কোডের ভেতর না দেখে, শুধু requirement আর আচরণ দেখে test বানানো। পর্ব ৪৫ Testing-এর মৌলিক-এ black-box আর white-box-এর পার্থক্য আর test-এর স্তর আছে। কোডের শাখা আর পথ ধরে test (statement, branch coverage, path testing) আসবে পর্ব ৫০ Coverage আর complexity-তে। আর এখানে বানানো test-গুলো কোডে কীভাবে লিখবেন — Arrange-Act-Assert, assertion, fixture — তা পর্ব ৪৬ Unit test-এ।

২ · Equivalence partitioning — একই আচরণের ইনপুট এক দলে

Equivalence partitioning-এর (EP) মূল অনুমান সহজ: যে ইনপুটগুলোর সাথে system একইভাবে আচরণ করার কথা, তাদের যেকোনো একটি দিয়ে test করলেই বাকিগুলোর প্রতিনিধিত্ব হয়। নম্বর 45 যদি C দেয়, 52-ও C দেবে বলে আশা করা যায় — দুটিই একই নিয়মের শাখায় পড়ে। তাই 40–59 একটি partition (equivalence class), আর এ থেকে একটি মান বেছে নিলেই চলে।

ধাপে ধাপে: grade-এর ঘর

1. Valid partition: requirement যেখানে আলাদা আচরণ বলে, সেখানেই আলাদা দল। এখানে চারটি: F (0–39), C (40–59), B (60–79), A (80–100).
2. Invalid partition: যা গ্রহণ করার কথা নয়। সংখ্যার দিকে দুটি: 0-র নিচে (−1, −50…) আর 100-র ওপরে (101, 500…)। ধরনের দিক থেকে আরও: খালি ঘর, অক্ষর (“abc”), দশমিক (45.5) — যদি requirement integer চায়।
3. প্রতিনিধি: প্রতিটি partition থেকে একটি মান, সাধারণত মাঝামাঝি: −5, 19, 49, 69, 90, 105. সংখ্যার দিকের ৬টি partition-এ তাই ৬টি test.

EP-র coverage মাপা হয় এভাবে: যতগুলো partition চিহ্নিত, তার কয়টিতে অন্তত একটি test আছে। ৬টির মধ্যে ৬টি হলে ১০০% equivalence partition coverage. খেয়াল করুন, এটি partition চেনার মানের ওপর নির্ভর করে — একটি partition চোখ এড়ালে “১০০%” মিথ্যা আশ্বাস দেয়।

একাধিক ইনপুট — partition কীভাবে মেলাবেন

বাস্তব ফর্মে ঘর অনেক। ধরুন ফল-পোর্টালে দুটি ঘর: নম্বর (৬টি partition) আর ছাত্রের roll (২টি: বৈধ ৭ অঙ্ক, অবৈধ)। তিনটি পথ আছে:

• প্রতিটি partition অন্তত একবার (each-choice): দুই ঘরের partition একসাথে মিলিয়ে test গোনা হয় বড়টির সমান — এখানে ৬টি test-এই দুই ঘরের ৮টি partition ঢাকা যায়।
• সব মিলন: ৬ × ২ = ১২টি test. ঘর বাড়লে গুণফল দ্রুত ফুলে ওঠে — এই সমস্যার মাঝামাঝি সমাধান অংশ ৭-এর pairwise.
• অবৈধ মান একবারে একটি: এটি নিয়ম, পছন্দ নয়। একটি test-এ নম্বর 105 আর roll “abc” দুটোই দিলে system প্রথমটিতেই থেমে error দিতে পারে; দ্বিতীয় ঘরের যাচাই আদৌ আছে কি না জানা যায় না। একে বলে error masking. তাই বৈধ মানগুলো একসাথে মেলানো চলে, কিন্তু প্রতিটি invalid partition-এর আলাদা test, বাকি সব ঘর বৈধ রেখে।

৩ · Boundary value analysis — ভুল লুকায় কিনারায়

প্রোগ্রামাররা সবচেয়ে বেশি ভুল করেন সীমায়: < না <=, লুপ ০ থেকে না ১ থেকে, শেষ উপাদান বাদ পড়ল কি না। এই ধরনের ভুলের নাম off-by-one error. ধরুন নিয়ম “৪০ বা বেশি হলে C”, কিন্তু কোডে লেখা if marks > 40. EP-র প্রতিনিধি 49 দিয়ে test করলে C আসবে, test পাস — অথচ ঠিক 40 পাওয়া ছাত্রটি F পাবেন। Boundary value analysis (BVA) এই কারণেই আছে: partition-এর কিনারার মান আলাদা করে test করা।

On point আর off point

প্রতিটি সীমায় দুটি বিশেষ বিন্দু। On point হলো সীমার মানটি নিজেই, অর্থাৎ ঠিক সীমার ওপর পড়া বিন্দু — যেমন C-র নিচের সীমায় 40. Off point হলো সীমার অন্য পাশে সবচেয়ে কাছের মান — এখানে 39, যা F-এ পড়ে। Integer-এ “সবচেয়ে কাছে” মানে ১ কম বা বেশি; টাকার মতো দুই দশমিকের সংখ্যায় ০.০১; দৈর্ঘ্যের সীমায় একটি অক্ষর। এই ক্ষুদ্রতম ধাপটি requirement-এর নির্ভুলতা (precision) থেকে আসে, তাই আগে জেনে নিন ঘরটি integer, না দশমিক।

২-মান বনাম ৩-মান BVA (ISTQB)

ISTQB-এর Foundation syllabus (সংস্করণ ৪.০) দুটি রূপ আলাদা করে বলে। ২-মান BVA-তে প্রতিটি সীমার মান আর পাশের partition-এর সবচেয়ে কাছের মান — অর্থাৎ on point আর off point. ৩-মান BVA-তে প্রতিটি সীমার মান আর তার দুই পাশের প্রতিবেশী। এক রেঞ্জের ঘর, বয়স 18–60:

• ২-মান: 17, 18, 60, 61 — ৪টি test.
• ৩-মান: 17, 18, 19, 59, 60, 61 — ৬টি test.

এখানে (আর এই পর্বের সব হিসাবে) ৩-মানের প্রতিবেশী নেওয়া হয়েছে valid partition-এর কিনারা ধরে। কেউ invalid partition-এর কিনারাকেও (17, 61) আলাদা সীমার মান ধরলে 16 আর 62 যোগ হয়ে ৮টি হয় — উৎসভেদে দুই রকম হিসাবই দেখা যায়।

৩-মান কেন? ধরুন একটি ঘরে মাত্র একটি সীমা: “বয়স ৬০ বা কম হলে ছাড়” (age <= 60), কিন্তু কোডে ভুল করে age == 60. ২-মানের 60 আর 61 দুটিতেই ফল ঠিক আসে (60-এ ছাড়, 61-এ নয়) — ভুলটি ধরা পড়ে না। ৩-মানের 59 ছাড় পায় না, ভুল ধরা পড়ে। অর্থাৎ ৩-মান বাড়তি খরচে কিছু বাড়তি ধরনের ভুল ধরে; কোনটি নেবেন তা ঝুঁকির ওপর নির্ভর করে (অংশ ৯)। পুরোনো বইয়ে “min, min+1, nominal, max−1, max” ধাঁচের আরেকটি রূপও পাওয়া যায় (যেমন robustness testing-এ min−1 আর max+1 যোগ) — স্কুলভেদে নাম আর মানের তালিকা আলাদা, তাই পরীক্ষায় প্রশ্ন কোন রূপ চাইছে খেয়াল করুন।

এবার পুরো grade-এর ঘরটি ধাপে ধাপে ভাঙি। “পরে” চাপুন:

এই হিসাবটি কোডে করলে ভুল কম হয়, আর নতুন ঘরের জন্য আবার ব্যবহার করা যায়। নিচের প্রোগ্রামটি প্রতিটি ঘরের valid partition-এর তালিকা নেয়, invalid দুই পাশ নিজেই যোগ করে, তারপর প্রতিনিধি, ২-মান আর ৩-মান BVA ছাপে:

// Equivalence classes + 2-value / 3-value boundary values (integer inputs).
// Each field: a list of VALID partitions [lo, hi, label]; outside = invalid.
function design(name, parts) {
  const lo = parts[0][0], hi = parts[parts.length - 1][1];
  const classes = [["INVALID low", -Infinity, lo - 1], ...parts.map(p => [p[2], p[0], p[1]]),
                   ["INVALID high", hi + 1, Infinity]];
  console.log(`== ${name}`);
  for (const [label, a, b] of classes) {
    // one representative per class: middle of the class (or a value near the edge)
    const rep = a === -Infinity ? b - 4 : b === Infinity ? a + 4 : Math.floor((a + b) / 2);
    console.log(`  ${label.padEnd(12)} ${String(a).padStart(9)} .. ${String(b).padEnd(9)} rep=${rep}`);
  }
  const bounds = [];                     // every edge value of every valid partition
  for (const [a, b] of parts) bounds.push(a, b);
  const two = new Set(), three = new Set();
  for (const v of bounds) {
    const isLow = parts.some(p => p[0] === v);
    two.add(v); two.add(isLow ? v - 1 : v + 1);       // the value + its nearest neighbour in the next class
    three.add(v - 1); three.add(v); three.add(v + 1); // the value + both neighbours
  }
  const sort = s => [...s].sort((x, y) => x - y);
  console.log(`  EP tests : ${classes.length}`);
  console.log(`  2-value  : ${sort(two).join(", ")}  (${two.size})`);
  console.log(`  3-value  : ${sort(three).join(", ")}  (${three.size})`);
}
design("age (single range 18-60)", [[18, 60, "valid"]]);
design("marks (grades)", [[0, 39, "F"], [40, 59, "C"], [60, 79, "B"], [80, 100, "A"]]);

== age (single range 18-60)
  INVALID low  -Infinity .. 17        rep=13
  valid               18 .. 60        rep=39
  INVALID high        61 .. Infinity  rep=65
  EP tests : 3
  2-value  : 17, 18, 60, 61  (4)
  3-value  : 17, 18, 19, 59, 60, 61  (6)
== marks (grades)
  INVALID low  -Infinity .. -1        rep=-5
  F                    0 .. 39        rep=19
  C                   40 .. 59        rep=49
  B                   60 .. 79        rep=69
  A                   80 .. 100       rep=90
  INVALID high       101 .. Infinity  rep=105
  EP tests : 6
  2-value  : -1, 0, 39, 40, 59, 60, 79, 80, 100, 101  (10)
  3-value  : -1, 0, 1, 38, 39, 40, 41, 58, 59, 60, 61, 78, 79, 80, 81, 99, 100, 101  (18)

৪ · Decision table — শর্তের সব মিলন

EP আর BVA একটি একটি ঘর দেখে। কিন্তু অনেক নিয়মে ফল নির্ভর করে কয়েকটি শর্ত একসাথে কেমন, তার ওপর। এমন জায়গায় decision table সবচেয়ে কাজের। একটি কাল্পনিক শহরের বাস-ভাড়ার ছাড় নিয়ম:

টেবিলের চারটি অংশ। শর্ত (condition): C1 যাত্রী ৬০+, C2 ছাত্র-কার্ড, C3 off-peak. কাজ (action): A1 ছাড়ের হার। প্রতিটি rule একটি কলাম: শর্তগুলোর একটি মিলন আর তার কাজ। n-টি Y/N শর্তে সব মিলন 2ⁿটি — এখানে 2³ = ৮টি। Rule বেশি হলে কিছু শর্ত ফলে কোনো প্রভাব ফেলে না, আর সেখানে বসে don't-care চিহ্ন “−”।

একই কাজ কোডে। প্রোগ্রামটি নিয়ম থেকে ৮টি rule বানায়, তারপর বারবার এমন দুটি rule মেশায় যাদের কাজ একই আর ঠিক একটি শর্তে পার্থক্য — সেই শর্তে বসে “−”:

from itertools import product

CONDS = ["C1 senior (60+)", "C2 student card", "C3 off-peak"]

def discount(senior, student, offpeak):          # the fictional rule (spec)
    if senior:
        return 50
    return (30 if student else 0) + (10 if offpeak else 0)

def show(title, rules):
    print(title)
    for i, c in enumerate(CONDS):
        print(f"  {c:16}" + "".join(f"{r[0][i]:>4}" for r in rules))
    print(f"  {'A1 discount %':16}" + "".join(f"{r[1]:>4}" for r in rules))

def merge_once(rules):   # join 2 rules: same action, differ in exactly 1 Y/N
    for a, b in product(rules, rules):
        d = [i for i in range(3) if a[0][i] != b[0][i]]
        if a[1] == b[1] and len(d) == 1 and "-" not in (a[0][d[0]], b[0][d[0]]):
            new = (a[0][:d[0]] + "-" + a[0][d[0] + 1:], a[1])
            return [r for r in rules if r not in (a, b)] + [new]
    return None

full = [("".join("Y" if v else "N" for v in vals), discount(*vals))
        for vals in product([True, False], repeat=3)]
show(f"Full table: 2^3 = {len(full)} rules", full)
rules = full
while (nxt := merge_once(rules)) is not None:
    rules = nxt
rules.sort(key=lambda r: [{"Y": 0, "-": 0, "N": 1}[c] for c in r[0]])
show(f"Collapsed: {len(rules)} rules", rules)
print("Test cases (one per collapsed rule; '-' filled with N):")
for k, (cond, act) in enumerate(rules, 1):
    v = [c == "Y" for c in cond]
    print(f"  TC{k}: senior={v[0]!s:5} student={v[1]!s:5} offpeak={v[2]!s:5} -> {act}%")

Full table: 2^3 = 8 rules
  C1 senior (60+)    Y   Y   Y   Y   N   N   N   N
  C2 student card    Y   Y   N   N   Y   Y   N   N
  C3 off-peak        Y   N   Y   N   Y   N   Y   N
  A1 discount %     50  50  50  50  40  30  10   0
Collapsed: 5 rules
  C1 senior (60+)    Y   N   N   N   N
  C2 student card    -   Y   Y   N   N
  C3 off-peak        -   Y   N   Y   N
  A1 discount %     50  40  30  10   0
Test cases (one per collapsed rule; '-' filled with N):
  TC1: senior=True  student=False offpeak=False -> 50%
  TC2: senior=False student=True  offpeak=True  -> 40%
  TC3: senior=False student=True  offpeak=False -> 30%
  TC4: senior=False student=False offpeak=True  -> 10%
  TC5: senior=False student=False offpeak=False -> 0%

শর্তগুলো সবসময় Y/N হয় না। “যাত্রার দূরত্ব: ১০ কিমির কম / ১০–৩০ / ৩০-এর বেশি” এমন তিন মানের শর্তে টেবিলটি extended entry — মোট rule তখন মানগুলোর গুণফল (২ × ২ × ৩ = ১২)। আর একটি শর্তের ভেতরের রেঞ্জ ঠিক করতে আবার EP আর BVA লাগে — কৌশলগুলো একসাথে কাজ করে। Requirement-এর ভাষা থেকে শর্ত আর ফলের সম্পর্ক আগে একটি ছবিতে আঁকার পদ্ধতিও আছে, cause-effect graph; তা থেকে decision table বের করা হয়।

৫ · State transition testing — অবস্থা আর ঘটনা

কিছু system-এর ফল শুধু এখনকার ইনপুটে নয়, আগে কী ঘটেছে তার ওপরও নির্ভর করে। একই “বাতিল” বোতাম টিকিট পরিশোধের আগে এক কাজ করে, পরে আরেক কাজ, আর যাত্রা শেষে কিছুই না। এমন জিনিসকে state আর transition দিয়ে মডেল করা হয় — UML state machine diagram পর্ব ২৩ Requirement modeling-এ আর পর্ব ৩০ UML behaviour diagram-এ দেখেছেন। State transition testing সেই মডেল থেকেই test বের করে।

একটি কাল্পনিক অনলাইন বাস-টিকিটের জীবনচক্র: আসন সংরক্ষণের পরে ১৫ মিনিটের মধ্যে টাকা না দিলে বাতিল; পরিশোধের পরে যাত্রার আগে বাতিল বা আসন বদল করা যায়; বাসে উঠলে টিকিট ব্যবহৃত।

State table — ছবির ফাঁকগুলো খুঁজে পাওয়া

ছবিতে শুধু বৈধ পথ আঁকা থাকে। কিন্তু ব্যবহারকারী ভুল সময়ে ভুল বোতামও চাপেন — দুবার pay, ব্যবহৃত টিকিট বাতিল। State table-এ প্রতিটি state-এর সারি আর প্রতিটি event-এর কলাম থাকে, তাই প্রতিটি মিলন চোখে পড়ে:

৪টি state × ৫টি event = ২০টি ঘর: ৬টি বৈধ transition আর ১৪টি invalid transition (✗)। প্রতিটি ✗-এর জন্য requirement-কে জিজ্ঞেস করতে হয়: এখানে কী হওয়ার কথা — চুপচাপ উপেক্ষা, error বার্তা, নাকি log? “Paid অবস্থায় আবার pay” যদি দ্বিতীয়বার টাকা কেটে নেয়, সেটি গুরুতর bug — আর ছবি দেখে এই প্রশ্ন সহজে ওঠে না, টেবিলে ওঠে।

Coverage: 0-switch আর 1-switch

• সব state: প্রতিটি state অন্তত একবার পৌঁছানো — সবচেয়ে দুর্বল মাপ।
• 0-switch coverage (সব বৈধ transition): T1–T6 প্রতিটি অন্তত একবার। প্রতিটি test শুরু হয় Reserved থেকে, তাই sequence হিসেবে লাগে: (ক) pay, change, board → T1, T6, T5; (খ) pay, cancel → T1, T4; (গ) cancel → T2; (ঘ) timeout → T3. ৪টি sequence-এ ৬টি transition. কম সম্ভব নয়: T2, T3 আর T1 প্রতিটি শুরুর transition, আর T4, T5 দুটিই শেষ state-এ নিয়ে যায়।
• 1-switch coverage (পরপর দুটি transition-এর প্রতিটি বৈধ জোড়া): Paid-এ ঢোকে T1 আর T6, Paid থেকে বের হয় T4, T5, T6 — তাই জোড়া ২ × ৩ = ৬টি: T1T4, T1T5, T1T6, T6T4, T6T5, T6T6. এটি switch coverage-এর ধারণা (Chow, ১৯৭৮-এর কাজ থেকে আসা)। N-switch মানে N+1টি পরপর transition-এর ক্রম।
• অবৈধ transition: ১৪টির প্রতিটি আলাদা test — প্রত্যাশিত ফল “প্রত্যাখ্যাত, state অপরিবর্তিত”।

এবার state table ধরে একটি event-এর ক্রম চালান — বৈধ আর অবৈধ দুটোই আছে:

৬ · Use case আর scenario testing — গল্প ধরে test

EP থেকে state transition পর্যন্ত কৌশলগুলো ছোট অংশ দেখে। কিন্তু ব্যবহারকারী একটি লক্ষ্য নিয়ে ধাপে ধাপে কাজ করেন, আর অনেক bug লুকিয়ে থাকে ধাপের সংযোগে। Scenario testing-এ use case-এর প্রতিটি পথ এক বা একাধিক test হয়। Use case লেখা আর acceptance criteria পর্ব ২২ Use case আর user story-এ বিস্তারিত আছে; এখানে শুধু test-এ রূপান্তর।

কাল্পনিক ফল-পোর্টালের use case “ছাত্র ফল দেখেন”:

• Main success scenario: ১. ছাত্র roll আর registration নম্বর দেন; ২. system মিলিয়ে দেখে; ৩. ছাত্র পরীক্ষা বাছেন; ৪. system grade-সহ ফল দেখায়।
• Extension 2a: নম্বর মেলেনি — বার্তা, আবার চেষ্টা; ৩ বার ভুলে ১০ মিনিট অপেক্ষা।
• Extension 3a: ফল এখনো প্রকাশ হয়নি — “প্রকাশের তারিখ” দেখায়।
• Extension 4a: ছাত্রের বকেয়া ফি আছে — ফল আটকে বার্তা দেখায়।

ন্যূনতম test: main scenario-র জন্য ১টি আর প্রতিটি extension-এর জন্য ১টি — মোট ৪টি। এরপর ভেতরের কৌশল যোগ হয়: 2a-তে “৩ বার” একটি সীমা, তাই ২য় আর ৩য় ভুলের test (BVA); “১০ মিনিট” আরেকটি সীমা। আর user story-র Given-When-Then আকারের acceptance criteria প্রায় সরাসরি scenario test হয়ে যায় — পর্ব ৪৮ TDD আর BDD-তে এগুলো চালানো যায় এমন test হিসেবে দেখবেন।

৭ · Pairwise আর combinatorial testing — ৮১ থেকে ৯

ফল-পোর্টালটি কোন পরিবেশে চলবে: device (phone, tablet, laptop), network (2G, 4G, wifi), ভাষা (বাংলা, ইংরেজি, মিশ্র), ভূমিকা (ছাত্র, শিক্ষক, admin). ৪টি parameter, প্রতিটির ৩টি মান: সব মিলন 3⁴ = ৮১টি। প্রতিটি হাতে চালাতে ১০ মিনিট লাগলে সাড়ে ১৩ ঘণ্টা।

Pairwise testing-এর যুক্তি: বাস্তবে অনেক ভুল ঘটে একটি parameter-এর একটি মানে, বা দুটি parameter-এর একটি নির্দিষ্ট জোড়ায় (যেমন “phone + 2G”-তে ফল লোড হয় না)। তাই লক্ষ্য হলো প্রতিটি parameter-জোড়ার প্রতিটি মান-জোড়া অন্তত একটি test-এ আসা। হিসাব: parameter-জোড়া C(4,2) = ৬টি, প্রতিটিতে 3 × 3 = ৯টি মান-জোড়া — মোট ৫৪টি জোড়া। একটি test একসাথে ৬টি জোড়া ঢাকে, তাই অন্তত ৫৪ ÷ ৬ = ৯টি test লাগবে। আর ৯টিতেই সম্ভব — নিচের প্রোগ্রাম দেখাবে:

// Greedy all-pairs (pairwise) suite: 4 parameters x 3 values (fictional result portal).
const P = { device: ["phone", "tablet", "laptop"], net: ["2G", "4G", "wifi"],
            lang: ["bn", "en", "mixed"], role: ["student", "teacher", "admin"] };
const names = Object.keys(P);
let all = [[]];                                   // every full combination
for (const n of names) all = all.flatMap(c => P[n].map(v => [...c, v]));
const pairsOf = t => {                            // the 6 pairs one test covers
  const out = [];
  for (let i = 0; i < t.length; i++)
    for (let j = i + 1; j < t.length; j++) out.push(`${i}=${t[i]}&${j}=${t[j]}`);
  return out;
};
const need = new Set(all.flatMap(pairsOf));       // all pairs that must appear
const uncovered = new Set(need), suite = [];
while (uncovered.size > 0) {                      // pick the combo that covers most new pairs
  let best = null, bestGain = -1;
  for (const t of all) {
    const gain = pairsOf(t).filter(p => uncovered.has(p)).length;
    if (gain > bestGain) { best = t; bestGain = gain; }
  }
  pairsOf(best).forEach(p => uncovered.delete(p));
  suite.push(best);
  console.log(`T${suite.length}: ${best.join(" / ").padEnd(30)} +${bestGain} new pairs`);
}
const covered = new Set(suite.flatMap(pairsOf));
console.log(`full combinations : ${all.length}`);
console.log(`pairs to cover    : ${need.size}`);
console.log(`pairwise suite    : ${suite.length} tests`);
console.log(`every pair covered: ${[...need].every(p => covered.has(p))}`);

T1: phone / 2G / bn / student      +6 new pairs
T2: phone / 4G / en / teacher      +6 new pairs
T3: phone / wifi / mixed / admin   +6 new pairs
T4: tablet / 2G / en / admin       +6 new pairs
T5: tablet / 4G / mixed / student  +6 new pairs
T6: tablet / wifi / bn / teacher   +6 new pairs
T7: laptop / 2G / mixed / teacher  +6 new pairs
T8: laptop / 4G / bn / admin       +6 new pairs
T9: laptop / wifi / en / student   +6 new pairs
full combinations : 81
pairs to cover    : 54
pairwise suite    : 9 tests
every pair covered: true

Orthogonal array-র ধারণা পরিসংখ্যানের পরীক্ষা-নকশা থেকে আসে (Genichi Taguchi-র কাজে শিল্পে জনপ্রিয়); software test-এ এর ব্যবহার নিয়ে ১৯৮০-এর দশক থেকে লেখা আছে, আর ১৯৯০-এর দশকে AETG-এর মতো greedy পদ্ধতি নিয়ে গবেষণা হয়। আজ বেশ কিছু open-source আর গবেষণা প্রতিষ্ঠানের তৈরি pairwise-generator tool আছে; এদের অনেকেই নিষেধ (constraint) মানতে পারে — যেমন “laptop-এ 2G থাকবে না” — আর তিনটি বা তার বেশি parameter-এর মিলনও (combinatorial testing, t-way) বানাতে পারে। কোন tool কোন বৈশিষ্ট্য দেয়, তা সংস্করণভেদে আলাদা; ব্যবহারের আগে নথি দেখে নিন।

৮ · অভিজ্ঞতা-নির্ভর কৌশল আর property-based testing-এর প্রথম স্বাদ

Error guessing আর checklist

অভিজ্ঞ tester জানেন কোথায় ভুল থাকে। Error guessing সেই জ্ঞানকে সচেতনভাবে ব্যবহার করে: সম্ভাব্য ভুলের তালিকা বানিয়ে প্রতিটির জন্য test. দলের অভিজ্ঞতা এক জায়গায় লিখে রাখলে হয় checklist-based testing. ফর্ম আর ইনপুট-ঘরের জন্য একটি নমুনা checklist:

• খালি, শুধু space, আর সামনে-পেছনে space-সহ মান
• শূন্য, ঋণাত্মক, অনেক বড় সংখ্যা, দশমিক, বৈজ্ঞানিক রূপ (1e3)
• বাংলা অঙ্ক (৪৫), বাংলা আর ইংরেজি মেশানো নাম, যুক্তাক্ষর, emoji
• সর্বোচ্চ দৈর্ঘ্যের ঠিক সমান আর এক অক্ষর বেশি
• তারিখ: ২৯ ফেব্রুয়ারি, মাসের শেষ দিন, মধ্যরাত, সময়-অঞ্চল (+06:00 বনাম UTC)
• দ্রুত দুবার “জমা দিন” চাপা, পাতা reload, পেছনে যাওয়ার বোতাম
• ধীর বা বিচ্ছিন্ন network-এ মাঝপথে কাজ থেমে যাওয়া

Exploratory testing

Exploratory testing-এ test-এর নকশা, চালানো আর শেখা একসাথে চলে: আগে থেকে ধাপ লেখা থাকে না, প্রতিটি পর্যবেক্ষণ পরের পদক্ষেপ ঠিক করে। এটি “এলোমেলো ক্লিক” নয়। একটি নির্দিষ্ট লক্ষ্য থাকে — test charter, যেমন “৯০ মিনিট: ধীর network-এ ফল প্রকাশের দিনের ভিড় অনুকরণ করে দেখা, ফল-পাতা কোথায় ভাঙে” — আর শেষে লিখিত নোট: কী দেখলাম, কী bug, কোন প্রশ্ন বাকি। শব্দটি ১৯৮০-এর দশকে Cem Kaner-এর লেখায় আসে বলে জানা যায়; সময় বেঁধে charter-ভিত্তিক session-এর পদ্ধতি (session-based test management) Jonathan আর James Bach ২০০০ সালের দিকে বর্ণনা করেন। Scripted test যা জানা, তা নিশ্চিত করে; exploratory test যা জানা নেই, তা খোঁজে — দুটি একে অপরের পরিপূরক।

Property-based testing — একটি নিয়ম, অনেক এলোমেলো ইনপুট

এতক্ষণ প্রতিটি test-এ একটি নির্দিষ্ট ইনপুট আর একটি নির্দিষ্ট প্রত্যাশিত ফল ছিল। Property-based testing উল্টো দিক থেকে ভাবে: এমন একটি property লিখুন যা যেকোনো বৈধ ইনপুটে সত্য হওয়ার কথা, তারপর যন্ত্রকে শত শত এলোমেলো ইনপুট বানাতে দিন। Sort-এর ক্ষেত্রে দুটি property: ফলাফল ছোট থেকে বড় ক্রমে, আর ফলাফলে ঠিক ইনপুটের উপাদানগুলোই আছে (একই সংখ্যায়)। ভাড়ার ছাড়ের ক্ষেত্রে: ছাড়ের পরের ভাড়া কখনো শূন্যের কম বা মূল ভাড়ার বেশি নয়।

ব্যর্থ ইনপুট পাওয়া গেলে tool সেটিকে ধাপে ধাপে ছোট করে — উপাদান বাদ দিয়ে, মান কমিয়ে — যতক্ষণ test ব্যর্থ থাকে। একে বলে shrinking; এতে ৫০টি উপাদানের জট পাকানো ইনপুটের বদলে সবচেয়ে ছোট উদাহরণ হাতে আসে। নিচে কোনো library ছাড়া একটি খেলনা রূপ। ইনপুট আসে একটি নির্দিষ্ট seed-এর PRNG থেকে, তাই প্রতিবার একই ক্রম, আর ফল পুনরুৎপাদনযোগ্য:

import random
from collections import Counter
def my_sort(xs):                       # hand-written insertion sort (has a bug)
    out = []
    for x in xs:
        i = 0
        while i < len(out) - 1 and out[i] < x:   # off-by-one: should be len(out)
            i += 1
        out.insert(i, x)
    return out

def holds(xs):                         # the properties (invariants) of any sort
    ys = my_sort(xs)
    in_order = all(ys[k] <= ys[k + 1] for k in range(len(ys) - 1))
    return in_order and Counter(ys) == Counter(xs)   # same items, same counts
def shrink(xs):                        # keep a smaller input while it still fails
    while True:
        smaller = [xs[:k] + xs[k + 1:] for k in range(len(xs))]        # drop one
        smaller += [xs[:k] + [v // 2] + xs[k + 1:] for k, v in enumerate(xs) if v]
        bad = next((s for s in smaller if not holds(s)), None)
        if bad is None:
            return xs
        xs = bad

rng = random.Random(47)                # fixed seed: same inputs every run
for trial in range(1, 101):
    xs = [rng.randint(0, 100) for _ in range(rng.randint(0, 8))]
    if not holds(xs):
        print(f"trial {trial}: FAILED on {xs}")
        print(f"  my_sort gives  {my_sort(xs)}")
        small = shrink(xs)
        print(f"  shrunk to      {small} -> {my_sort(small)}")
        break
else:
    print("100 random inputs passed")

trial 1: FAILED on [8, 55, 70, 58, 73]
  my_sort gives  [55, 58, 70, 73, 8]
  shrunk to      [0, 1] -> [1, 0]

এই ধারণা জনপ্রিয় করে Koen Claessen আর John Hughes-এর Haskell library QuickCheck (ICFP ২০০০-এর গবেষণাপত্র)। Python-এ এর পরিচিত উত্তরসূরি Hypothesis (David MacIver-এর শুরু করা, ২০১০-এর দশকে)। আসল tool-গুলো ইনপুটের ধরন বুঝে বানায়, শুরুতেই সীমার কাছের মান (0, খালি তালিকা, খুব বড় সংখ্যা) বেশি চেষ্টা করে, ব্যর্থ উদাহরণ মনে রাখে, আর shrinking অনেক বুদ্ধিমান। বৈশিষ্ট্যগুলো সংস্করণভেদে আলাদা; এখানকার কোড শুধু মূল ভাবনা দেখায়। Property খোঁজা প্রায়ই কঠিন — পর্ব ৩১ Interface আর contract-এর precondition আর postcondition এখানে ভালো সূত্র দেয়।

৯ · কোন কৌশল কখন — ঝুঁকি ধরে বেছে নেওয়া

কোনো একটি কৌশল সব জায়গায় সেরা নয়। কৌশল বাছাইয়ের প্রশ্ন দুটি: এই অংশের আচরণ কী ধরনের (রেঞ্জ, শর্তের মিলন, অবস্থা, ধাপের ক্রম, অনেক configuration), আর ভুল হলে ক্ষতি কত (risk). ঝুঁকি দেখে test-এর গভীরতা ঠিক করাকে বলে risk-based testing (ঝুঁকির হিসাব আর মাপ পর্ব ৬২ Risk আর quality management-এ)।

একটি বাস্তব চিত্র: ফল-পোর্টালে grade বসানো আর টাকা কাটা সবচেয়ে ঝুঁকিপূর্ণ (ভুল হলে ছাত্রের ভবিষ্যৎ বা টাকা) — সেখানে ৩-মান BVA, পূর্ণ decision table, 1-switch. প্রোফাইলের ছবি বদলানোর মতো কম ঝুঁকির অংশে EP আর একটি exploratory session যথেষ্ট। এই বাছাইয়ের সিদ্ধান্ত test plan-এ লিখে রাখুন, যাতে পরে বোঝা যায় কেন কোথায় কতটা test (requirement থেকে test পর্যন্ত traceability পর্ব ২৪ Requirement management-এ)।

১০ · AI-এর যুগে test নকশা — AI-কে কৌশল ধরিয়ে দেওয়া, আর তার কাজ যাচাই

AI-কে “এই function-এর test লিখে দাও” বললে সাধারণত কয়েকটি সুন্দর দেখতে, সহজ পথের test আসে: 50 → C, 95 → A. সীমা থাকে না, invalid partition থাকে না, আর প্রায়ই প্রত্যাশিত ফল নেওয়া হয় কোড চালিয়ে — ফলে test কোডের ভুলকেই “সঠিক” বলে পাকা করে। AI আরও যা করে: ISTQB বা কোনো মানের নামে এমন সংজ্ঞা বা “নিয়ম” বলে যা সেখানে নেই; pairwise tool-এর অস্তিত্বহীন option বানায়; decision table-এ rule গুনতে ভুল করে; state diagram-এ UML-এর বাইরের চিহ্ন বসায়। AI-কে কৌশলের নাম আর requirement সরাসরি দিন, আর তার উত্তর হাতে গুনে মিলিয়ে নিন:

AI-এর test নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• Partition, boundary আর rule-এর সংখ্যা নিজে গুনে মিলিয়েছি (2ⁿ, ২-মান/৩-মান)
• প্রত্যাশিত ফল requirement থেকে এসেছে, কোড চালিয়ে নয় — test যেন implementation-এর আয়না না হয়
• প্রতিটি invalid partition আর invalid transition-এর আলাদা test আছে
• কোডে ইচ্ছা করে একটি off-by-one ভুল (>= থেকে >) ঢুকিয়ে দেখেছি অন্তত একটি test ব্যর্থ হয় কি না (mutation testing পর্ব ৫০-এ)
• AI যে মান বা tool-এর option-এর নাম বলেছে, তা আসল নথিতে খুঁজে পেয়েছি
• Prompt-এ আসল ছাত্র বা যাত্রীর ব্যক্তিগত তথ্য দিইনি — কাল্পনিক data ব্যবহার করেছি