রিস্ক-বেসড টেস্টিং ও প্রায়োরিটাইজেশন

Risk-based testing & prioritization

৮ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এক নজরে · TL;DR

রিস্ক-বেসড টেস্টিং মানে সব এলাকা সমান গুরুত্ব দিয়ে টেস্ট না করে, সবচেয়ে বেশি ঝুঁকিপূর্ণ এলাকায় সীমিত সময়/রিসোর্স কেন্দ্রীভূত করা।
ঝুঁকি (risk) সাধারণত দুটো জিনিসের গুণফল হিসেবে গণনা করা হয়: likelihood (ঐ এলাকায় বাগ থাকার সম্ভাবনা কতটা) × impact (বাগ থাকলে সেটার প্রভাব কতটা ক্ষতিকর)।
এই গণনাকে প্রায়ই রিস্ক-ম্যাট্রিক্স বলা হয় — একই ধরনের likelihood×severity গণনা সিকিউরিটি ও প্রজেক্ট ম্যানেজমেন্টেও ব্যবহৃত হয়।
নিচের কোড সেলে ৬টি বাস্তবসম্মত টেস্ট এলাকার জন্য একটি সত্যিকারের রিস্ক-প্রায়োরিটি স্কোর গণনা করে র‍্যাঙ্ক করা হয়েছে।

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

রিস্ক-বেসড টেস্টিং কী এবং কেন সময়/রিসোর্স সীমিত থাকলে এটি প্রয়োজনীয়
likelihood × impact দিয়ে একটি রিস্ক-প্রায়োরিটি স্কোর কীভাবে গণনা করতে হয়
একই স্কোরের ভিন্ন উৎস (উচ্চ likelihood/কম impact বনাম কম likelihood/উচ্চ impact) কীভাবে ভিন্ন সিদ্ধান্তে নিয়ে যেতে পারে
একটি সত্যিকারের Python কোড সেল যা একাধিক টেস্ট এলাকাকে রিস্ক স্কোর অনুযায়ী র‍্যাঙ্ক করে

১ · কেন সব এলাকা সমান গুরুত্ব পায় না

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

২ · রিস্ক = likelihood × impact

একটি এলাকার ঝুঁকি (risk) সাধারণত দুটো স্বতন্ত্র প্রশ্নের উত্তর একত্র করে গণনা করা হয়:

Likelihood
এই এলাকায় বাগ থাকার সম্ভাবনা কতটা বেশি? (জটিল লজিক, ঘন ঘন পরিবর্তিত কোড, বা নতুন ফিচার — উচ্চ likelihood।)

Impact
বাগ থাকলে সেটার প্রভাব কতটা ক্ষতিকর? (ব্যবহারকারীর ক্ষতি, রাজস্ব ক্ষতি, খ্যাতির ক্ষতি — টাকার লেনদেন জড়িত এলাকায় সাধারণত উচ্চ impact।)

Risk score
risk = likelihood × impact — দুটোই উচ্চ হলে সবচেয়ে বিপজ্জনক এলাকা, দুটোই নিম্ন হলে সবচেয়ে কম অগ্রাধিকারের এলাকা।

লক্ষণীয় যে গুণফল ব্যবহার করা হয়, যোগফল নয় — এর একটি গুরুত্বপূর্ণ ফলাফল: যদি impact প্রায় শূন্যের কাছাকাছি হয় (যেমন একটি অলঙ্করণমূলক UI উপাদান), likelihood যত বেশিই হোক না কেন, সামগ্রিক রিস্ক স্কোর কম থাকবে — যা স্বজ্ঞাতভাবেও ঠিক মনে হয়।

৩ · ৬টি টেস্ট এলাকার রিস্ক-প্রায়োরিটি গণনা

নিচের কোড সেলে একটি ছোট ই-কমার্স অ্যাপের ৬টি ভিন্ন এলাকার জন্য (১–৫ স্কেলে) likelihood ও impact অনুমান করে, প্রতিটির রিস্ক স্কোর গণনা করে, এবং একটি সরল থ্রেশহোল্ড দিয়ে High/Medium/Low প্রায়োরিটি টায়ারে ভাগ করা হয়েছে।

Python

# likelihood ও impact — উভয়ই 1 (সর্বনিম্ন) থেকে 5 (সর্বোচ্চ) স্কেলে অনুমান করা হয়েছে
areas = [
    {"name": "পেমেন্ট ও চেকআউট",              "likelihood": 3, "impact": 5},
    {"name": "লগইন/অথেন্টিকেশন",              "likelihood": 2, "impact": 5},
    {"name": "প্রোডাক্ট সার্চ",                "likelihood": 4, "impact": 2},
    {"name": "রিপোর্ট এক্সপোর্ট (CSV/PDF)",     "likelihood": 3, "impact": 2},
    {"name": "থার্ড-পার্টি SMS নোটিফিকেশন",     "likelihood": 4, "impact": 3},
    {"name": "অ্যাডমিন প্যানেল থিম সেটিংস",     "likelihood": 2, "impact": 1},
]

def risk_score(area):
    return area["likelihood"] * area["impact"]

def priority_tier(score):
    if score >= 15:
        return "High"
    elif score >= 8:
        return "Medium"
    else:
        return "Low"

for area in areas:
    area["risk_score"] = risk_score(area)
    area["tier"] = priority_tier(area["risk_score"])

ranked = sorted(areas, key=lambda a: a["risk_score"], reverse=True)

print("রিস্ক-প্রায়োরিটি অনুযায়ী টেস্ট এলাকার র‍্যাঙ্কিং:")
for rank, area in enumerate(ranked, start=1):
    print(
        f"{rank}. {area['name']} — likelihood={area['likelihood']}, "
        f"impact={area['impact']}, risk={area['risk_score']} ({area['tier']})"
    )

লক্ষ্য করুন "পেমেন্ট ও চেকআউট" (৩×৫=১৫) শীর্ষে থাকে ও একমাত্র High টায়ারে পড়ে — মাঝারি likelihood কিন্তু সর্বোচ্চ impact-এর কারণে। "থার্ড-পার্টি SMS নোটিফিকেশন" (৪×৩=১২) দ্বিতীয় স্থানে — likelihood-এ "পেমেন্ট"-এর চেয়েও বেশি হলেও কম impact-এর কারণে সামগ্রিক স্কোর কম। আর "অ্যাডমিন প্যানেল থিম সেটিংস" (২×১=২) সবচেয়ে নিচে — উভয় মান নিম্ন হওয়ায় এটি সবচেয়ে কম অগ্রাধিকারের প্রার্থী, যদিও একেবারে টেস্ট-না-করার যোগ্য নয়।

সময় সীমিত হলে কী করবেন

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

মূল কথা · Key takeaway

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

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

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

প্র ০১ রিস্ক গণনা করার সময় likelihood ও impact যোগ না করে গুণ করা হয় কেন?

গুণফল ব্যবহার করলে যেকোনো একটি উপাদান শূন্যের কাছাকাছি হলে সামগ্রিক ঝুঁকিও স্বয়ংক্রিয়ভাবে কমে যায় — যেমন একটি এলাকায় বাগ হওয়ার সম্ভাবনা অত্যন্ত কম হলে, সেটার impact যত বেশিই হোক, বাস্তব ঝুঁকি কম। যোগফল ব্যবহার করলে একটি অত্যন্ত-উচ্চ-impact কিন্তু প্রায়-অসম্ভব এলাকা ভুলভাবে একটি মাঝারি-likelihood মাঝারি-impact এলাকার সমান বা বেশি স্কোর পেয়ে যেতে পারত।

প্র ০২ উপরের ডেটায় "লগইন/অথেন্টিকেশন"-এর likelihood মাত্র ২ (কম) কিন্তু impact ৫ (সর্বোচ্চ) — এটি বাস্তবে কেমন হতে পারে তার একটা যুক্তি দিন।

লগইন লজিক সাধারণত পুরনো, ভালোভাবে টেস্ট করা এবং কম পরিবর্তিত হয় বলে নতুন বাগ আসার সম্ভাবনা কম (কম likelihood) — কিন্তু যদি সেখানে বাগ থাকেই, একজন ব্যবহারকারী তার অ্যাকাউন্টেই ঢুকতে না পারা, বা আরও খারাপ, অন্যের অ্যাকাউন্টে ঢুকে পড়া, এর প্রভাব অত্যন্ত মারাত্মক (সর্বোচ্চ impact) — তাই কম likelihood সত্ত্বেও এটি এখনও Medium-টায়ারে থেকে যায়, একদম Low নয়।

প্র ০৩ উপরের কোড সেলে যদি priority_tier-এর থ্রেশহোল্ড score >= 15 থেকে কমিয়ে score >= 12 করা হয়, র‍্যাঙ্কিং-এর ক্রম বদলাবে কি না, আর টায়ার বণ্টন কীভাবে বদলাবে?

র‍্যাঙ্কিং-এর ক্রম বদলাবে না, কারণ থ্রেশহোল্ড শুধু টায়ার-লেবেল (High/Medium/Low) ঠিক করে, স্কোরের ভিত্তিতে সাজানোর ক্রম নয়। তবে টায়ার বণ্টন বদলাবে — "থার্ড-পার্টি SMS নোটিফিকেশন" (স্কোর ১২) এখন Medium থেকে High-এ উঠে যাবে, ফলে High-টায়ারে দুটো এলাকা থাকবে একটির বদলে।

অনুশীলন

চিন্তা করুন: আপনার পরিচিত কোনো অ্যাপের জন্য তিনটি টেস্ট এলাকা কল্পনা করুন এবং প্রতিটির likelihood ও impact (১–৫) অনুমান করুন — কোনটির রিস্ক স্কোর সবচেয়ে বেশি হবে বলে মনে করেন?

উদাহরণ (একটি রাইড-শেয়ারিং অ্যাপ): "ড্রাইভার লোকেশন ট্র্যাকিং" (likelihood ৩, impact ৫ — ভুল লোকেশন মানে যাত্রী ভুল জায়গায় গাড়ি খুঁজবে), "রাইড ভাড়া গণনা" (likelihood ২, impact ৫ — ভুল ভাড়া সরাসরি টাকার ক্ষতি), "প্রোফাইল ছবি ক্রপিং" (likelihood ৪, impact ১)। এখানে প্রথম দুটোর স্কোর (১৫) সমান হলেও, ভাড়া গণনায় ভুল হলে সরাসরি আর্থিক বিরোধ তৈরি হয় বলে বাস্তবে এটিকে সামান্য বেশি গুরুত্ব দেওয়া যুক্তিসঙ্গত হতে পারে — সংখ্যা সবসময় শেষ কথা নয়, মানুষের বিচারবোধও লাগে।
পরিবর্তন করুন: উপরের কোড সেলে areas-এ আপনার একটি সপ্তম এলাকা যোগ করুন যার likelihood ও impact উভয়ই ৫ (সর্বোচ্চ), Run চেপে দেখুন এটি র‍্যাঙ্কিং-এ কোথায় স্থান পায়।

এই এলাকার রিস্ক স্কোর হবে 5 × 5 = 25 — যা তালিকার সবচেয়ে উপরে চলে যাবে, "পেমেন্ট ও চেকআউট"-এর (১৫) ওপরেও, এবং একমাত্র সবচেয়ে বেশি-অগ্রাধিকারের এলাকা হয়ে দাঁড়াবে।