Testing-এর মৌলিক — verification-validation, test-এর স্তর আর black-box বনাম white-box

১ · Test কেন — চারটি কাজ

মডিউল ৭-এ দেখেছেন কোড কীভাবে সাজাবেন, পরিষ্কার রাখবেন আর অন্যের চোখে পড়িয়ে নেবেন (পর্ব ৪৪ Code review). কিন্তু একটি প্রশ্ন বাকি: কোডটি যা করার কথা, তা-ই করছে — এটা জানবেন কীভাবে? এই মডিউলের উত্তর হলো software testing.

একটি দল test লেখে চারটি কারণে:

Fault, error আর failure-এর পার্থক্য পর্ব ৩-এ (Software quality) বিস্তারিত দেখেছেন। মনে করিয়ে দিই: কোডের ভেতরের ভুল শর্তটি fault (প্রচলিত কথায় bug বা defect); চলার সময় তার কারণে ভুল অবস্থা হলো error; আর বাইরে থেকে দেখা ভুল ফল বা crash হলো failure. সাবধান: ISTQB আর IEEE-র glossary-তে “error” মানে মানুষের ভুল কাজ (mistake), যা থেকে defect জন্মায়; ভুল অবস্থার অর্থটি dependability-র ধারার। Test সরাসরি fault দেখে না, failure দেখে — তারপর debugging করে fault খোঁজা হয়। এ কারণেই fault থাকা সত্ত্বেও test সবুজ থাকতে পারে, যদি কোনো test সেই fault-কে জাগিয়ে তোলার মতো ইনপুট না দেয়।

এই মডিউলে কী কী আছে

এই পর্বটি পুরো Testing মডিউলের মানচিত্র। এখানে ধারণা আর শব্দভান্ডার; প্রতিটি অংশের হাতে-কলমে রূপ পরের পর্বগুলোতে:

২ · Testing কী পারে না — Dijkstra আর সব ইনপুটের হিসাব

কেন অনুপস্থিতি দেখানো যায় না? কারণ একটি test মানে একটি ইনপুটে একবার চালানো। “সব ইনপুটেই ঠিক” বলতে হলে সব ইনপুটে চালাতে হবে — একে বলে exhaustive testing. হিসাবটি দেখুন। ধরুন সেকেন্ডে ১০০ কোটি (10⁹) test চালাতে পারেন — বাস্তবের বেশিরভাগ test suite-এর চেয়ে অনেক উদার অনুমান:

// Exhaustive testing calculator. ASSUMPTION: 1,000,000,000 tests per second
// (far faster than most real test suites), one machine, no setup cost.
const RATE = 1_000_000_000n;
const SEC_PER_YEAR = 365.25 * 24 * 3600;

const domains = [
  ["3 boolean flags",                 2n ** 3n],
  ["one 8-bit byte",                  2n ** 8n],
  ["one 32-bit int",                  2n ** 32n],
  ["8-char id, a-z and 0-9",          36n ** 8n],
  ["two 32-bit ints",                 2n ** 64n],
  ["16-char password, 95 symbols",    95n ** 16n],
];

function human(seconds) {
  if (seconds < 1) return (seconds * 1e9).toFixed(0) + " ns";
  if (seconds < 60) return seconds.toFixed(1) + " s";
  if (seconds < 3600) return (seconds / 60).toFixed(1) + " min";
  if (seconds < 86400) return (seconds / 3600).toFixed(1) + " h";
  const y = seconds / SEC_PER_YEAR;
  return y < 1e6 ? y.toFixed(1) + " years" : y.toExponential(2) + " years";
}

console.log("input domain".padEnd(30) + "cases".padStart(33) + "   time");
for (const [name, cases] of domains) {
  const seconds = Number(cases) / Number(RATE);
  console.log(name.padEnd(30) + cases.toString().padStart(33) + "   " + human(seconds));
}
const y64 = Number(2n ** 64n) / Number(RATE) / SEC_PER_YEAR;
console.log("\n2^64 cases = " + (2n ** 64n).toString());
console.log("at 1e9 tests/s: " + y64.toFixed(1) + " years");

input domain                                              cases   time
3 boolean flags                                               8   8 ns
one 8-bit byte                                              256   256 ns
one 32-bit int                                       4294967296   4.3 s
8-char id, a-z and 0-9                            2821109907456   47.0 min
two 32-bit ints                            18446744073709551616   584.5 years
16-char password, 95 symbols   44012666865176569775543212890625   1.39e+15 years

2^64 cases = 18446744073709551616
at 1e9 tests/s: 584.5 years

এবার একটি বাস্তবধর্মী function ধাপে ধাপে বড় করে দেখুন। একটি কাল্পনিক রেলের টিকিট অ্যাপের fare() ভাড়া হিসাব করে; প্রতিটি ধাপে একটি করে ইনপুট যোগ হচ্ছে, হার আগের মতোই সেকেন্ডে 10⁹:

৩ · Verification বনাম validation — আর static বনাম dynamic testing

পর্ব ৩-এ Barry Boehm-এর দুই প্রশ্ন সংক্ষেপে দেখেছেন। এবার নিখুঁতভাবে। Boehm-এর লেখায় (যেমন IEEE Software-এ ১৯৮৪ সালের তাঁর প্রবন্ধ “Verifying and Validating Software Requirements and Design Specifications”) জনপ্রিয় হওয়া রূপটি:

আনুষ্ঠানিক সংজ্ঞাও উৎসভেদে একটু আলাদা। IEEE-র পুরোনো glossary (IEEE 610.12-1990)-তে verification মোটামুটি “একটি development ধাপের ফল সেই ধাপের শুরুতে বেঁধে দেওয়া শর্ত মানে কি না”, আর validation “development-এর সময়ে বা শেষে system নির্দিষ্ট requirement মানে কি না” যাচাই। পরের অনেক মানে (যেমন ISO 9000-ধারার সংজ্ঞা আর IEEE 1012) validation-এর জোর পড়ে উদ্দিষ্ট ব্যবহার আর ব্যবহারকারীর প্রয়োজনের ওপর। মনে রাখার কৌশল: verification তাকায় পেছনে, আগের নথির দিকে; validation তাকায় বাইরে, মানুষের দিকে।

Static testing বনাম dynamic testing

কোড না চালিয়েও ভুল খোঁজা যায়। Static testing মানে কাজের ফল (requirement, নকশা, কোড, test নিজেই) পড়ে বা বিশ্লেষণ করে যাচাই: review, walkthrough, inspection, আর static analysis tool — পর্ব ৪৪-এ দেখেছেন। Dynamic testing মানে software চালিয়ে আচরণ দেখা — এই মডিউলের বাকি সব।

৪ · Test-এর স্তর — unit, integration, system, acceptance

বাড়ি বানানোর কথা ভাবুন। প্রথমে প্রতিটি ইট আর রডের মান দেখা হয়; তারপর দেখা হয় কলাম আর বিম ঠিকমতো জোড়া লেগেছে কি না; বাড়ি শেষ হলে পানি, বিদ্যুৎ, গ্যাস — পুরো বাড়ি একসাথে কাজ করে কি না; আর শেষে মালিক ঘুরে দেখে চাবি বুঝে নেন। Software-এর test level-ও এমন চারটি:

“Unit” কত বড় — একটি function, না একটি class, না কয়েকটি class মিলে একটি আচরণ — তা নিয়ে বিভিন্ন ঘরানায় মতভেদ আছে; পর্ব ৪৬-এ (Unit test) দেখবেন। Integration-এর বিস্তারিত (contract test, end-to-end) পর্ব ৫১-এ।

Acceptance-এর রকমফের

• User acceptance testing (UAT): আসল ব্যবহারকারী বা তাঁদের প্রতিনিধি নিজের কাজের পরিস্থিতিতে দেখেন — “এ দিয়ে আমার কাজ চলবে?”
• Alpha testing: প্রকাশের আগে, নির্মাতার নিজের জায়গায় বা নিয়ন্ত্রিত পরিবেশে, ভেতরের মানুষ বা বাছাই করা ব্যবহারকারী দিয়ে।
• Beta testing: সীমিত সংখ্যক বাইরের ব্যবহারকারী তাঁদের নিজের পরিবেশে (নিজের ফোন, নিজের network) ব্যবহার করে মতামত দেন।
• Operational acceptance testing (OAT): চালানোর দল দেখে system চালানো যায় কি না — install, backup ও restore, monitoring, বিপর্যয়ের পরে চালু করা, নিরাপত্তার নিয়ম।
• এ ছাড়া চুক্তি বা আইনের শর্ত মানা হয়েছে কি না, তার contractual ও regulatory acceptance — যেমন ব্যাংক বা চিকিৎসার software-এ।

V-model-এ স্তরগুলোর জায়গা

পর্ব ৪-এ (SDLC আর process model) V-model দেখেছেন: বাঁ দিকের প্রতিটি নকশার ধাপের পাশে ডান দিকে একটি test স্তর। ছবিতে প্রতিটি জোড় দেখায় কোন স্তর কোন নথির সাথে মিলিয়ে দেখা হয়:

এবার একটি requirement ধরে দেখুন, প্রতিটি স্তরে তার কোন দিকটি যাচাই হয়। কাল্পনিক অনলাইন বাজার অ্যাপের নিয়ম: “সদস্যরা ১,০০০ টাকা বা তার বেশি কেনাকাটায় ১০% ছাড় পাবেন।”

Members get 10% off when cart total >= 1000 taka.
AC1: member, 1000 taka  -> pays 900
AC2: member,  999 taka  -> pays 999
AC3: non-member, 5000   -> pays 5000

discount(1000, member=True)  == 100
discount(999,  member=True)  == 0
discount(1500, member=False) == 0
discount(-5, True)  -> raises error

user 42 is a member in the test DB
cart service asks member service -> true
cart total 1200 -> discount line 120
member service down -> checkout still works,
                       no discount, warning logged

log in as member -> add items worth 1000
-> checkout page shows 900, invoice PDF 900
-> payment gateway (sandbox) charged 900
also: 500 checkouts/min, page < 2 s

owner: "discount must show BEFORE payment,
        not only on the invoice"
member: "I could not see why I got no
         discount on 990 taka"
-> new requirement: show "10 taka more for 10% off"

৫ · Test-এর ধরন — কী যাচাই করছেন

স্তর বলে কতটুকু জোড়া লাগিয়ে দেখছেন; test type বলে কোন গুণ দেখছেন। যেকোনো ধরন যেকোনো স্তরে হতে পারে — performance test একটি function-এও হয়, পুরো system-এও।

Non-functional-এর তালিকা আসে quality-র মডেল থেকে — ISO/IEC 25010-এর characteristic, পর্ব ৩ আর পর্ব ২১ (Functional আর non-functional requirement). Requirement মাপা যায় এমন করে লেখা থাকলে (“২ সেকেন্ডের মধ্যে”), তবেই non-functional test-এর পাস-ফেল ঠিক করা যায়।

৬ · Black-box, white-box আর grey-box

তৃতীয় প্রশ্ন: test বানানোর সময় আপনি ভেতরের কতটা জানেন বা ব্যবহার করছেন?

একটি সূক্ষ্ম কথা: black-box আর white-box হলো test বানানোর পদ্ধতি, স্তর নয়। Unit test সাধারণত white-box ভেবে লেখা হয়, তবে black-box-ও হতে পারে; আর system test সাধারণত black-box, তবে coverage মেপে white-box চোখেও দেখা যায়। ISTQB-র নতুন syllabus-এ নামগুলো “black-box test technique” আর “white-box test technique”, পাশে অভিজ্ঞতা-ভিত্তিক (experience-based) কৌশল, যেমন exploratory testing.

৭ · Testing-এর সাতটি নীতি — আর test oracle-এর সমস্যা

ISTQB (International Software Testing Qualifications Board)-এর Foundation Level syllabus সাতটি সাধারণ নীতির তালিকা দেয়, যা চাকরির পরীক্ষা আর ইন্টারভিউতে খুব চেনা। নিচে লেখার সময়ের সর্বশেষ সংস্করণ (CTFL v4.0, ২০২৩)-এর ক্রম আর ভাষা, আমাদের জানামতে; আগের সংস্করণ (২০১৮)-এর নাম বন্ধনীতে:

1. Testing ত্রুটির উপস্থিতি দেখায়, অনুপস্থিতি নয়। Dijkstra-র কথাই — test সবুজ মানে “এই case-গুলোতে ভুল পাইনি”।
2. Exhaustive testing অসম্ভব। অংশ ২-এর হিসাব; তাই ঝুঁকি আর অগ্রাধিকার ধরে বাছাই।
3. আগে testing সময় আর টাকা বাঁচায় (early testing). Requirement-এর review-এ ধরা ভুল কোড লেখার আগেই মেটে।
4. Defect জোট বাঁধে (defect clustering). অল্প কিছু module-এ বেশিরভাগ defect — Pareto-র ধাঁচ। নিচে simulation দেখুন।
5. Test-এর ধার কমে যায় (tests wear out; আগে নাম ছিল pesticide paradox). একই test বারবার চালালে একসময় নতুন ভুল আর ধরে না — যেমন একই কীটনাশক বারবার দিলে পোকা সয়ে যায়। “Pesticide paradox” নামটি Boris Beizer-এর Software Testing Techniques (দ্বিতীয় সংস্করণ, ১৯৯০) থেকে প্রচলিত। প্রতিকার: test হালনাগাদ করা, নতুন test, নতুন কৌশল। তবে regression-এর জন্য পুরোনো test চালিয়ে যাওয়া তবুও দরকার।
6. Testing প্রসঙ্গের ওপর নির্ভর করে. হাসপাতালের ওষুধের মাত্রার software আর একটি রান্নার রেসিপির অ্যাপ একইভাবে test হয় না।
7. “ত্রুটি নেই” মানেই সফল নয় (absence-of-defects fallacy; আগে “absence-of-errors fallacy”). সব test সবুজ, কিন্তু ব্যবহারকারীর যা দরকার তা না বানালে লাভ নেই — অংশ ৪-এর acceptance ধাপ।

এগুলো “নীতি” — গাণিতিক সূত্র নয়, অভিজ্ঞতা থেকে আসা সাধারণীকরণ। এবার চতুর্থ নীতিটি একটি simulation-এ দেখুন। Data বানানো, আসল কোনো project-এর নয়: একটি কাল্পনিক অনলাইন বাজার অ্যাপের ২০টি module-এ ৪০০টি defect ছড়ানো হয়েছে, প্রতিটি module-এর “ভুলপ্রবণতা” এসেছে একটি দীর্ঘ-লেজের (heavy-tailed) বণ্টন থেকে, স্থির seed দিয়ে:

import random
# Simulated (NOT real) data: 400 defects spread over 20 modules of a
# fictional online-market app. Each module gets a "proneness" weight from a
# heavy-tailed distribution; a fixed seed makes every run identical.
rng = random.Random(45)
modules = [f"M{i:02d}" for i in range(1, 21)]
weight = {m: rng.paretovariate(0.8) for m in modules}
total_w = sum(weight.values())

count = dict.fromkeys(modules, 0)
for _ in range(400):                       # place each defect by weight
    u, acc = rng.random() * total_w, 0.0
    for m in modules:
        acc += weight[m]
        if u < acc:
            count[m] += 1
            break
    else:
        count[modules[-1]] += 1

ranked = sorted(modules, key=lambda m: -count[m])
running = 0
for i, m in enumerate(ranked, 1):
    running += count[m]
    if i <= 6 or i == 20:
        bar = "#" * (count[m] // 4)
        print(f"{i:2} {m} {count[m]:4}  cum {running / 400:6.1%}  {bar}")
    elif i == 7:
        print("   ...")
top = len(modules) // 5                    # top 20% = 4 modules
share = sum(count[m] for m in ranked[:top]) / 400
print(f"\ntop {top} of 20 modules (20%) hold {share:.1%} of defects")
print("modules with 0 defects:", sum(1 for m in modules if count[m] == 0))

 1 M17   74  cum  18.5%  ##################
 2 M14   47  cum  30.2%  ###########
 3 M18   45  cum  41.5%  ###########
 4 M15   44  cum  52.5%  ###########
 5 M12   31  cum  60.2%  #######
 6 M10   26  cum  66.8%  ######
   ...
20 M03    6  cum 100.0%  #

top 4 of 20 modules (20%) hold 52.5% of defects
modules with 0 defects: 0

Test oracle-এর সমস্যা

একটি test-এ দুটি জিনিস লাগে: ইনপুট, আর প্রত্যাশিত ফল। প্রত্যাশিত ফল কোথা থেকে আসে, তার উৎসকে বলে test oracle — spec, হাতে করা হিসাব, পুরোনো সংস্করণ, অন্য একটি স্বাধীন implementation, বা একজন বিশেষজ্ঞ। Oracle problem হলো: অনেক ক্ষেত্রে সঠিক ফল জানাই কঠিন। আবহাওয়ার পূর্বাভাসের model, machine learning-এর ফল, একটি জটিল বিমার প্রিমিয়াম — “ঠিক উত্তর কত হওয়া উচিত” কে বলবে? ধারণাটি ১৯৭০-এর দশকের শেষের testing-সাহিত্যে (যেমন William Howden-এর কাজে) আসে বলে সাধারণত ধরা হয়, আর Elaine Weyuker-এর ১৯৮২ সালের প্রবন্ধ “On Testing Non-Testable Programs” এর ক্লাসিক আলোচনা।

পুরো উত্তর না জানলেও আংশিক oracle কাজে লাগে: বৈশিষ্ট্য যাচাই (ছাড় কখনো মোটের চেয়ে বেশি হবে না, ফল কখনো ঋণাত্মক নয়), সম্পর্ক যাচাই (মোট দ্বিগুণ হলে ছাড়ও দ্বিগুণ — metamorphic testing), বা crash না হওয়া। আর একটি বিপদ মনে রাখুন: কোড থেকেই প্রত্যাশিত ফল কপি করলে test শুধু বলে “কোড যা করে, তা-ই করে” — ভুলটিও পাস করে যায়। AI দিয়ে test লেখালে এটি খুব বেশি হয় (অংশ ১০)।

৮ · Test case, test runner আর defect-এর জীবনচক্র

একটি test case পরিষ্কার লেখা থাকলে যে কেউ চালিয়ে একই সিদ্ধান্তে পৌঁছাবেন — রান্নার রেসিপির খাতার মতো: উপকরণ, আগে কী তৈরি রাখবেন, ধাপ, আর শেষে কেমন হওয়ার কথা। আনুষ্ঠানিক test নথির মান হলো ISO/IEC/IEEE 29119-3 (আগে IEEE 829); প্রচলিত ঘরগুলো:

Automated test-এ এই ঘরগুলো কোডের ভেতরে থাকে: test-এর নাম = শিরোনাম, setup = precondition, function call = steps ও data, assertion = expected result. একটি test runner সব test খুঁজে চালায় আর ফল গুনে দেখায়। ভেতরে জিনিসটি কত সরল, তা দেখতে ২০ লাইনের একটি runner বানিয়ে ফেলি — describe, it আর expect নাম Jest-ধাঁচের framework থেকে নেওয়া। পরীক্ষাধীন কোড: অংশ ৪-এর ছাড়ের নিয়ম।

// A tiny test runner (toy). Real ones: Jest, Vitest, Mocha (JS); pytest, unittest (Python).
const results = [];
function describe(name, fn) { console.log(name); fn(); }
function it(name, fn) {
  try { fn(); results.push(true); console.log("  PASS " + name); }
  catch (e) { results.push(false); console.log("  FAIL " + name + "\n       " + e.message); }
}
function expect(actual) {
  return {
    toBe(expected) {
      if (actual !== expected) throw new Error(`expected ${expected}, got ${actual}`);
    },
    toThrow() {
      try { actual(); } catch (e) { return; }
      throw new Error("expected an error, none was thrown");
    },
  };
}
// Code under test (fictional rule): members get 10% off when total >= 1000 taka.
function discount(total, isMember) {
  if (total < 0) throw new RangeError("negative total");
  if (isMember && total > 1000) return total * 0.10;   // the rule says >=
  return 0;
}
describe("discount()", () => {
  it("member, 1500 taka -> 150", () => expect(discount(1500, true)).toBe(150));
  it("non-member gets nothing", () => expect(discount(1500, false)).toBe(0));
  it("member, 999 taka -> 0", () => expect(discount(999, true)).toBe(0));
  it("member, exactly 1000 -> 100", () => expect(discount(1000, true)).toBe(100));
  it("negative total throws", () => expect(() => discount(-5, true)).toThrow());
});
const passed = results.filter(Boolean).length;
console.log(`\n${passed} passed, ${results.length - passed} failed, ${results.length} total`);

discount()
  PASS member, 1500 taka -> 150
  PASS non-member gets nothing
  PASS member, 999 taka -> 0
  FAIL member, exactly 1000 -> 100
       expected 100, got 0
  PASS negative total throws

4 passed, 1 failed, 5 total

Defect-এর জীবনচক্র

Test ফেল করলে কাজ শুরু হয়: defect-টি লেখা, কে ঠিক করবেন ঠিক করা, সংশোধন, আবার যাচাই। এই পথের নাম defect lifecycle. অবস্থার নাম tool আর দলভেদে আলাদা (Bugzilla, Jira বা GitHub Issues-এর মতো issue tracker-এ নিজের মতো সাজানো যায়), তবে মূল ধাপগুলো প্রায় একই। অংশ ৮-এর ফেল হওয়া test থেকে একটি defect-এর যাত্রা:

Severity বনাম priority

দুটি আলাদা মাপ, আর সাধারণত আলাদা মানুষ ঠিক করেন। Severity হলো defect-এর প্রভাব system আর ব্যবহারকারীর ওপর কত বড় (critical, major, minor, trivial-এর মতো ধাপ) — প্রায়ই tester প্রস্তাব করেন। Priority হলো কত তাড়াতাড়ি ঠিক করতে হবে (P1, P2…) — প্রায়ই product owner বা manager ঠিক করেন, ব্যবসা, সময়সীমা আর কতজন ব্যবহারকারী আক্রান্ত তা দেখে। ধাপের নাম আর সংখ্যা প্রতিষ্ঠানভেদে আলাদা।

একটি কাল্পনিক পরীক্ষার ফলাফল পোর্টালের defect-তালিকা নিচে priority, তারপর severity ধরে সাজানো হলো:

from dataclasses import dataclass
# Fictional bug list of an exam-result portal. Severity = how bad the effect is
# on the system; priority = how soon the business needs the fix.
SEV = {"critical": 1, "major": 2, "minor": 3, "trivial": 4}
PRI = {"P1": 1, "P2": 2, "P3": 3, "P4": 4}

@dataclass
class Bug:
    id: str
    title: str
    severity: str
    priority: str

bugs = [
    Bug("B-101", "crash when exporting 1990s archive", "critical", "P3"),
    Bug("B-102", "university name misspelt on home page", "trivial", "P1"),
    Bug("B-103", "GPA rounds 3.995 down to 3.99", "major", "P1"),
    Bug("B-104", "login fails for every student", "critical", "P1"),
    Bug("B-105", "tooltip text overlaps on old phones", "minor", "P4"),
    Bug("B-106", "PDF marksheet missing page numbers", "minor", "P3"),
    Bug("B-107", "slow search (8 s) on result day", "major", "P2"),
]
queue = sorted(bugs, key=lambda b: (PRI[b.priority], SEV[b.severity], b.id))
print(f"{'#':<3}{'id':<7}{'pri':<5}{'severity':<10}title")
for i, b in enumerate(queue, 1):
    print(f"{i:<3}{b.id:<7}{b.priority:<5}{b.severity:<10}{b.title}")

odd = [b.id for b in bugs if abs(PRI[b.priority] - SEV[b.severity]) >= 2]
print("\nseverity and priority far apart:", ", ".join(odd))

#  id     pri  severity  title
1  B-104  P1   critical  login fails for every student
2  B-103  P1   major     GPA rounds 3.995 down to 3.99
3  B-102  P1   trivial   university name misspelt on home page
4  B-107  P2   major     slow search (8 s) on result day
5  B-101  P3   critical  crash when exporting 1990s archive
6  B-106  P3   minor     PDF marksheet missing page numbers
7  B-105  P4   minor     tooltip text overlaps on old phones

severity and priority far apart: B-101, B-102

৯ · Agile দলে testing — whole-team আর shift-left

Waterfall-ধাঁচের পুরোনো ধারায় testing ছিল একটি আলাদা ধাপ, শেষের দিকে, আলাদা দলের হাতে: developer “শেষ” করে test দলের দিকে কোড “ছুড়ে” দিতেন। দুটি সমস্যা হতো — ভুল ধরা পড়ত দেরিতে, যখন সারানো সবচেয়ে দামি; আর quality হয়ে যেত “অন্যের কাজ”।

Agile দলে (পর্ব ৫ Agile আর Scrum) দুটি বড় বদল:

• Whole-team approach: Quality পুরো দলের দায়িত্ব। Developer নিজের unit আর integration test লেখেন; tester-এর দক্ষতা কাজে লাগে ঝুঁকি খোঁজা, acceptance criteria লেখায় সাহায্য, exploratory testing আর test কৌশল ঠিক করায়; product owner acceptance-এর সিদ্ধান্তে থাকেন। Extreme Programming (Kent Beck, ১৯৯৯)-এ এই ধারণা নাম পায়।
• Shift-left: সময়রেখা বাঁ থেকে ডানে আঁকলে testing-কে বাঁ দিকে — আগে — সরানো: requirement লেখার সময়েই “কীভাবে test করব?” প্রশ্ন (Given-When-Then, পর্ব ২২ আর ৪৮), কোড লেখার আগে test (TDD, পর্ব ৪৮), প্রতিটি commit-এ স্বয়ংক্রিয় test (continuous integration, পর্ব ৫৮)। এর পাশাপাশি অনেক দল “shift-right”-ও করে — production-এ monitoring, ধাপে ধাপে release, feature flag দিয়ে আসল ব্যবহার থেকে শেখা।

Sprint-এর মধ্যে test শেষ না হলে কাজটি “Done” নয় — এটি দলের Definition of Done-এ লেখা থাকে। আর কোন ধরনের test কেন, তা সাজানোর একটি জনপ্রিয় ছক হলো Agile testing quadrants: Brian Marick-এর প্রস্তাব (২০০৩), Lisa Crispin আর Janet Gregory-র বই Agile Testing (২০০৯)-এ জনপ্রিয়। এর চার ঘরে পড়ে unit ও component test, functional ও story test, exploratory ও usability test, আর performance ও security test.

১০ · AI-এর যুগে — AI-লেখা test আর AI-এর দেওয়া testing-জ্ঞান

AI কয়েক সেকেন্ডে ডজনখানেক test লিখে দেয়, আর “coverage ৯৫%” দেখে মনে হয় কাজ শেষ। কিন্তু অংশ ৭-এর oracle-এর সমস্যা এখানেই সবচেয়ে বেশি কামড়ায়: AI প্রায়ই কোড পড়ে প্রত্যাশিত ফল লেখে, তাই কোডের ভুলটিই test-এ “ঠিক” হিসেবে বসে যায়।

AI-এর সাহায্যে testing — চেকলিস্ট

• প্রত্যাশিত ফল requirement বা স্বাধীন হিসাব থেকে এসেছে, কোড থেকে কপি নয়
• অন্তত একটি ইচ্ছাকৃত ভুল কোডে ঢুকিয়ে দেখেছি AI-লেখা test লাল হয়
• সীমার মান, খালি ও অবৈধ ইনপুট, error-এর পথ — তালিকায় আছে
• AI-এর দেওয়া framework API, flag আর সংজ্ঞা documentation বা মূল syllabus-এ মিলিয়েছি
• Test ফেল করলে AI assertion বদলায়নি — কোডের ভুল সারিয়েছে, বা requirement নিয়ে প্রশ্ন তুলেছে
• Git-এর ধ্বংসাত্মক command (reset --hard, clean -fdx, push --force) আগে throwaway clone-এ বুঝে নিয়েছি
• Prompt-এ আসল গ্রাহকের তথ্য, password বা token নেই