টেস্ট রিপোর্টিং ও গুরুত্বপূর্ণ মেট্রিক্স

Test reporting & metrics that matter

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

এক নজরে · TL;DR

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

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

ভ্যানিটি মেট্রিক কী, এবং কেন শুধু কাঁচা টেস্ট সংখ্যা প্রায়ই ভ্যানিটি মেট্রিক
তিনটি সত্যিকারের অর্থবহ মেট্রিক্স — পাস রেট, ডিফেক্ট ডেনসিটি, ডিফেক্ট এস্কেপ রেট — এবং প্রতিটির অর্থ
কীভাবে একসাথে দেখা মেট্রিক্স একক মেট্রিকের চেয়ে বেশি সত্য প্রকাশ করে
একটি সত্যিকারের Python গণনা যা সিন্থেটিক ডেটা থেকে এই মেট্রিক্স বের করে ও একটি রেড ফ্ল্যাগ শনাক্ত করে

১ · ভ্যানিটি মেট্রিক — সংখ্যা যা দেখতে ভালো লাগে কিন্তু কিছু বলে না

একটি টিম গর্বের সাথে বলতে পারে "আমাদের ৩,০০০টি টেস্ট আছে" — কিন্তু এই একটি সংখ্যা একা প্রশ্নের কোনো উত্তর দেয় না: এই ৩,০০০ টেস্ট কি প্রকৃতপক্ষে গুরুত্বপূর্ণ এলাকা কভার করে (L49-এর রিস্ক-বেসড প্রায়োরিটাইজেশন), নাকি বেশিরভাগই তুচ্ছ, পুনরাবৃত্তিমূলক চেক? একা টেস্ট সংখ্যা — কোনো প্রসঙ্গ ছাড়া — একটি ক্লাসিক ভ্যানিটি মেট্রিকVanity Metricএমন একটি সংখ্যা যা দেখতে চিত্তাকর্ষক কিন্তু প্রকৃত মান বা ঝুঁকি সম্পর্কে কার্যকর সিদ্ধান্ত নিতে সাহায্য করে না। — এটি বাড়ানো সহজ (আরও ছোট, তুচ্ছ টেস্ট যোগ করুন), কিন্তু এর সাথে প্রকৃত সফটওয়্যার কোয়ালিটির সরাসরি সম্পর্ক নেই।

২ · যে মেট্রিক্স সত্যিই কিছু বলে

টেস্ট পাস রেট
পাস হওয়া টেস্টের অনুপাত — tests_passed / tests_run। একা উচ্চ পাস রেট বিভ্রান্তিকর হতে পারে যদি টেস্টগুলো দুর্বল/অগুরুত্বপূর্ণ হয় (L26-এ কভারেজের সীমাবদ্ধতার সাথে সম্পর্কিত)।

ডিফেক্ট ডেনসিটি
কোডের আকারের সাপেক্ষে কতগুলো বাগ পাওয়া গেছে (যেমন প্রতি হাজার লাইন কোডে) — একটি ছোট মডিউলে ১০টি বাগ একটি বিশাল মডিউলে ১০টি বাগের চেয়ে অনেক বেশি উদ্বেগজনক।

ডিফেক্ট এস্কেপ রেট
মোট পাওয়া ডিফেক্টের মধ্যে কতগুলো টেস্টিং এড়িয়ে প্রোডাকশনে পৌঁছেছে — production_defects / total_defects। এটিই সবচেয়ে সরাসরি বলে দেয় টেস্ট স্যুট আসলে কতটা কার্যকর।

লক্ষণীয়, এই তিনটির কোনোটিই একা সম্পূর্ণ চিত্র দেয় না — একসাথে দেখলেই আসল গল্প বোঝা যায়, যেমন নিচের গণনায় দেখা যাবে।

৩ · একটি সত্যিকারের গণনা — কেন "বড় স্যুট" বিভ্রান্তিকর হতে পারে

নিচের কোড সেলে একটি সিন্থেটিক দৃশ্যকল্প আছে: একটি টিম গর্ব করে বলছে তারা ৩,০০০টি টেস্ট চালিয়েছে, এবং পাস রেটও দেখতে চমৎকার (৯৮%)। কিন্তু ডিফেক্ট ডেনসিটি ও এস্কেপ রেট গণনা করলেই বোঝা যায় আসল সমস্যা কোথায়।

Python

# --- সিন্থেটিক রিলিজ ডেটা ---
tests_run = 3000
tests_passed = 2940
defects_found_in_testing = 30
defects_found_in_production = 45
size_kloc = 50  # কোডের আকার — হাজার লাইন কোড (illustrative)

pass_rate = tests_passed / tests_run * 100

total_defects = defects_found_in_testing + defects_found_in_production
defect_density = total_defects / size_kloc

escape_rate = defects_found_in_production / total_defects * 100

print(f"মোট টেস্ট চালানো হয়েছে: {tests_run}  (একা এই সংখ্যাটি কিছু বলে না)")
print(f"টেস্ট পাস রেট: {pass_rate:.1f}%")
print(f"ডিফেক্ট ডেনসিটি: {defect_density:.2f} ডিফেক্ট/KLOC")
print(f"ডিফেক্ট এস্কেপ রেট: {escape_rate:.1f}%  "
      f"({defects_found_in_production}/{total_defects} মোট ডিফেক্ট প্রোডাকশনে ধরা পড়েছে)")

if escape_rate > 50:
    print(
        "\nসতর্কতা: অর্ধেকের বেশি ডিফেক্ট টেস্টিং এড়িয়ে প্রোডাকশনে পৌঁছেছে — "
        "৩,০০০টি টেস্ট ও ৯৮% পাস রেট থাকা সত্ত্বেও টেস্ট স্যুট প্রকৃত রিস্ক এলাকা কভার করছে না।"
    )
else:
    print("\nএস্কেপ রেট গ্রহণযোগ্য পরিসরে — টেস্ট স্যুট প্রকৃত রিস্ক এলাকা মোটামুটি ভালোভাবে কভার করছে।")

লক্ষ্য করুন গণনার ফলাফল: পাস রেট ৯৮.০% — দেখতে চমৎকার। কিন্তু এস্কেপ রেট ৬০.০% (45/75) — অর্থাৎ মোট পাওয়া ৭৫টি ডিফেক্টের মধ্যে ৪৫টিই টেস্টিং এড়িয়ে প্রোডাকশনে পৌঁছেছে, মাত্র ৩০টি টেস্টিং-এই ধরা পড়েছে। এর মানে ৩,০০০টি টেস্টের বিশাল সংখ্যা ও উচ্চ পাস রেট সত্ত্বেও, স্যুটটি আসলে সঠিক জায়গায় মনোযোগ দিচ্ছে না — হয়তো বেশিরভাগ টেস্টই কম-ঝুঁকির এলাকা বারবার চেক করছে, প্রকৃত সমস্যাযুক্ত এলাকা এড়িয়ে যাচ্ছে। এটিই দেখায় কেন একা "টেস্ট সংখ্যা" বা একা "পাস রেট" বিভ্রান্তিকর — এস্কেপ রেট ছাড়া এই সমস্যাটি সম্পূর্ণ আড়ালে থেকে যেত।

রিপোর্টিং-এ প্রসঙ্গ ছাড়া সংখ্যা দেখাবেন না

একটি ভালো টেস্ট রিপোর্ট শুধু সংখ্যা তালিকাভুক্ত করে না — প্রতিটি সংখ্যার পাশে তুলনা বা প্রবণতা দেখায় (গত রিলিজের তুলনায় এস্কেপ রেট বেড়েছে না কমেছে?), এবং L49-এর মতো রিস্ক-বেসড দৃষ্টিভঙ্গি দিয়ে ব্যাখ্যা করে কোন এলাকায় সংখ্যাগুলো এসেছে। "৩,০০০টি টেস্ট, ৯৮% পাস" — এই একটি লাইন স্টেকহোল্ডারদের আশ্বস্ত করতে পারে ভুলভাবে, যদি এস্কেপ রেটের মতো সম্পূরক মেট্রিক না দেখানো হয়।

মূল কথা · Key takeaway

কাঁচা টেস্ট সংখ্যা একা কখনো কোয়ালিটির প্রমাণ নয় — পাস রেট, ডিফেক্ট ডেনসিটি ও ডিফেক্ট এস্কেপ রেট একসাথে দেখলেই আসল চিত্র পাওয়া যায়। একটি বড়, উচ্চ-পাস-রেট স্যুট যদি উচ্চ এস্কেপ রেট নিয়েও চলতে থাকে, সেটি একটি স্পষ্ট রেড ফ্ল্যাগ — টেস্টিং প্রচেষ্টা ভুল জায়গায় বিনিয়োগ হচ্ছে। এই কোর্সের M11 জুড়ে যা শিখলাম — পরিকল্পনা (L46), টেস্ট কেস ডিজাইন (L47), ডিফেক্ট ট্র্যাকিং (L48), রিস্ক-বেসড অগ্রাধিকার (L49) — এই মেট্রিক্সগুলো সেই পুরো প্রক্রিয়া আসলে কাজ করছে কি না তার প্রতিফলন।

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

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

প্র ০১ একজন ম্যানেজার বলছেন "আমরা এই কোয়ার্টারে টেস্ট সংখ্যা ৫০০ থেকে ২,০০০-এ বাড়িয়েছি, তাই কোয়ালিটি অনেক ভালো হয়েছে" — এই যুক্তিতে কী সমস্যা থাকতে পারে?

টেস্ট সংখ্যা বাড়া মানেই কোয়ালিটি বাড়া নয় — নতুন যোগ হওয়া টেস্টগুলো যদি একই কম-ঝুঁকির এলাকা বারবার চেক করে, বা দুর্বল অ্যাসারশন থাকে (L26-এর মতো), তাহলে সংখ্যা বাড়লেও এস্কেপ রেট অপরিবর্তিত বা আরও খারাপ থাকতে পারে। প্রকৃত উপসংহারে পৌঁছাতে এস্কেপ রেট ও ডিফেক্ট ডেনসিটির প্রবণতা (কোয়ার্টার-টু-কোয়ার্টার) দেখা দরকার, শুধু কাঁচা টেস্ট সংখ্যা নয়।

প্র ০২ উপরের কোড সেলে যদি defects_found_in_production কমিয়ে ১০ করা হতো (বাকি সব একই থাকলে), এস্কেপ রেট ও এর সাথে সিদ্ধান্তের সিগন্যাল কীভাবে বদলে যেত?

তাহলে total_defects = 30 + 10 = 40, আর escape_rate = 10/40*100 = 25.0% — যা ৫০%-এর নিচে, তাই কোডের if escape_rate > 50 শাখাটি আর চলবে না, বরং "গ্রহণযোগ্য পরিসরে" বার্তা দেখাবে। এটি দেখায় একই পাস রেট ও একই টেস্ট সংখ্যা থাকা সত্ত্বেও, শুধু প্রোডাকশন-ডিফেক্ট সংখ্যা বদলালেই সামগ্রিক উপসংহার সম্পূর্ণ বদলে যেতে পারে — কেন এই একটি মেট্রিক এত গুরুত্বপূর্ণ তারই প্রমাণ।

প্র ০৩ ডিফেক্ট ডেনসিটি গণনায় size_kloc (কোডের আকার) ব্যবহার না করে যদি শুধু কাঁচা total_defects সংখ্যা রিপোর্ট করা হতো, কী সমস্যা হতে পারত?

একটি ৫০,০০০-লাইনের বড় মডিউলে ৭৫টি ডিফেক্ট আর একটি ৫,০০০-লাইনের ছোট মডিউলে ৭৫টি ডিফেক্ট — দুটোর তীব্রতা সম্পূর্ণ ভিন্ন, যদিও কাঁচা সংখ্যা একই। কোডের আকারের সাপেক্ষে স্বাভাবিক করা (normalize করা) ছাড়া দুটো ভিন্ন আকারের মডিউল বা দুটো ভিন্ন রিলিজের মধ্যে ন্যায্য তুলনা করা যায় না।

অনুশীলন

চিন্তা করুন: "মোট টেস্ট সংখ্যা" ছাড়া আর কোন কোন মেট্রিককে আপনি সম্ভাব্য ভ্যানিটি মেট্রিক মনে করেন (যেমন "কোড লাইন সংখ্যা", "মিটিং সংখ্যা")? কেন?

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

pass_rate বদলে যাবে (2940/500 আসলে ১০০%-এর বেশি হয়ে যাবে, যা একটি অবাস্তব সংমিশ্রণ নির্দেশ করে — এই অনুশীলনটি দেখায় ডেটা সামঞ্জস্যপূর্ণ রাখা কতটা গুরুত্বপূর্ণ)। কিন্তু defect_density ও escape_rate একদমই বদলাবে না, কারণ এই দুটো গণনায় tests_run কোথাও ব্যবহৃত হয় না — শুধু ডিফেক্ট সংখ্যা ও কোডের আকারের উপর নির্ভর করে। এটিই দেখায় কেন এই মেট্রিক্সগুলো টেস্ট সংখ্যার "স্ফীতি" থেকে স্বাধীন এবং তাই আরও নির্ভরযোগ্য।