বাগের প্রকৃত খরচ — কেন আগে ধরা সস্তা
এই পাঠে যা শিখবেন
- কেন বাগ পরে ধরা পড়লে খরচ বাড়ে — মূল কারণ (rework) বোঝা
- SDLC-এর কোন ধাপে বাগ ধরা পড়লে কী পরিমাণ কাজ পুনরায় করতে হতে পারে
- দৃষ্টান্তমূলক গুণিতক সংখ্যা ব্যবহার করে Python দিয়ে প্রকৃত খরচের পার্থক্য গণনা করা
- কেন এই সংখ্যাগুলোকে নির্ভুল পরিসংখ্যান হিসেবে না নিয়ে একটি সাধারণ প্রবণতা হিসেবে বোঝা উচিত
১ · কেন খরচ বাড়ে
একটি বাগ যদি Requirements পর্যায়ে ধরা পড়ে (যেমন — একটি স্পেসিফিকেশন রিভিউ মিটিং-এ কেউ লক্ষ্য করলো একটি নিয়ম অস্পষ্ট বা ভুল লেখা হয়েছে), তাহলে ঠিক করতে শুধু ডকুমেন্ট আপডেট করতে হয় — এখনো কোনো কোড লেখা হয়নি। কিন্তু একই বাগ যদি Production-এ ধরা পড়ে (একজন ব্যবহারকারী রিপোর্ট করলেন), তখন ইতিমধ্যে কোড লেখা হয়ে গেছে, টেস্ট হয়ে গেছে, ডিপ্লয় হয়ে গেছে, হয়তো অন্য ফিচার সেই ভুল আচরণের উপর নির্ভর করে তৈরি হয়ে গেছে — ঠিক করতে এখন কোড পরিবর্তন, রিটেস্ট, রিডিপ্লয়, এবং সম্ভবত কাস্টমার সাপোর্ট ও হটফিক্স প্রক্রিয়ার অতিরিক্ত কাজ লাগে। যত বেশি কাজ ইতিমধ্যে হয়ে গেছে, তত বেশি rework (পুনরায় কাজ) দরকার হয় — এটাই খরচ বৃদ্ধির মূল কারণ।
২ · Python দিয়ে খরচের পার্থক্য গণনা
নিচের কোড সেলে ধরে নেওয়া হয়েছে একই একটি বাগ বিভিন্ন পর্যায়ে ধরা পড়লে কী খরচ হতো — উপরের দৃষ্টান্তমূলক গুণিতক সংখ্যাগুলো ব্যবহার করে। এরপর একই ধরনের একাধিক বাগের জন্য প্রকল্প-স্তরের একটি তুলনাও গণনা করা হয়েছে।
import unittest
def cost_to_fix(stage, base_cost):
"""
base_cost: Requirements পর্যায়ে এই একই বাগ ঠিক করতে যে (arbitrary একক) খরচ লাগত।
multipliers নিচে কমনলি-সাইটেড দৃষ্টান্তমূলক সংখ্যা — নির্ভুল সার্বজনীন পরিসংখ্যান নয়।
"""
multipliers = {
"requirements": 1,
"design": 5,
"coding": 10,
"testing": 15,
"production": 30,
}
return base_cost * multipliers[stage]
base_cost = 100 # ধরে নিচ্ছি Requirements পর্যায়ে এই বাগ ঠিক করতে ১০০ টাকা-সমতুল্য কাজ লাগে
print("একই বাগ বিভিন্ন পর্যায়ে ধরা পড়লে খরচ (দৃষ্টান্তমূলক গুণিতক দিয়ে):")
for stage in ["requirements", "design", "coding", "testing", "production"]:
print(f" {stage:12s}: {cost_to_fix(stage, base_cost):6d} টাকা")
ratio = cost_to_fix("production", base_cost) / cost_to_fix("requirements", base_cost)
print(f"\nProduction-এ ধরা পড়লে Requirements-এর তুলনায় {ratio:.0f}x বেশি খরচ")
n_defects = 20
cost_if_caught_early = n_defects * cost_to_fix("requirements", base_cost)
cost_if_caught_late = n_defects * cost_to_fix("production", base_cost)
savings = cost_if_caught_late - cost_if_caught_early
print(f"\n{n_defects}টি একই-ধরনের বাগ Requirements পর্যায়ে ধরলে মোট খরচ: {cost_if_caught_early} টাকা")
print(f"একই {n_defects}টি বাগ Production পর্যায়ে ধরলে মোট খরচ: {cost_if_caught_late} টাকা")
print(f"আগে ধরার ফলে সাশ্রয়: {savings} টাকা")
class CostToFixTests(unittest.TestCase):
def test_requirements_stage_equals_base_cost(self):
self.assertEqual(cost_to_fix("requirements", 100), 100)
def test_production_stage_is_thirty_times_base(self):
self.assertEqual(cost_to_fix("production", 100), 3000)
suite = unittest.TestLoader().loadTestsFromTestCase(CostToFixTests)
unittest.TextTestRunner(verbosity=2).run(suite)
ratio-এর মান base_cost-এর উপর নির্ভর করে না — যেহেতু
cost_to_fix() উভয় পাশেই base_cost-কে গুণ করে, এটি ভাগফলে বাতিল হয়ে যায় এবং শুধু
গুণিতকের অনুপাত (৩০/১ = ৩০) থেকে যায়। তাই base_cost পরিবর্তন করলে মোট টাকার অঙ্ক বদলাবে, কিন্তু
"কতগুণ বেশি খরচ" অনুপাতটি একই থাকবে — এটি দৃষ্টান্তমূলক মডেলের একটি স্বাভাবিক বৈশিষ্ট্য।
Software Engineering Principles & Git কোর্সে SDLC-এর ধাপগুলো (Requirements, Design, Coding ইত্যাদি) বিস্তারিত শেখানো হয়েছে — এই পাঠ সেই ধাপগুলোর উপর ভিত্তি করে দেখায় কেন টেস্টিংকে যত আগে সম্ভব শুরু করা গুরুত্বপূর্ণ।
বাগ পরে ধরা পড়লে খরচ বাড়ার মূল কারণ rework — ইতিমধ্যে করা কাজ বাতিল বা পরিবর্তন করতে হয়। নির্দিষ্ট গুণিতক সংখ্যাগুলো দৃষ্টান্তমূলক হলেও, "যত আগে ধরা পড়ে তত সস্তা" প্রবণতাটি ব্যাপকভাবে সত্য এবং এই কোর্সের বেশিরভাগ কৌশলের (early test design, TDD, shift-left) পেছনের মূল যুক্তি — L04-এ এটিকে আনুষ্ঠানিকভাবে সাতটি মূলনীতির একটি হিসেবে দেখা হবে।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ যদি একটি বাগ কোডিং পর্যায়ে ধরা পড়েও ডেভেলপার সেটা তখনই ঠিক না করে "পরে ঠিক করব" বলে ফেলে রাখেন, এবং সেটা শেষ পর্যন্ত Production-এ ধরা পড়ে — এক্ষেত্রে খরচ বৃদ্ধি কি এড়ানো যেত এমন একটি সিদ্ধান্তের ফল, নাকি স্বাভাবিক?
এটি একটি এড়ানো যেত এমন সিদ্ধান্তের ফল। খরচ-বৃদ্ধির প্যাটার্ন আসলে বাগ কোন পর্যায়ে সমাধান হচ্ছে তার সাথে সম্পর্কিত, শুধু কোথায় প্রথম আবিষ্কৃত হয়েছে তার সাথে নয়। কোডিং পর্যায়ে ধরা পড়েও ফিক্স দেরি করলে অন্য কোড সেই ভুল আচরণের উপর নির্ভর করে তৈরি হতে পারে — ফলে দেরিতে ঠিক করার খরচ প্রায় ততটাই বেশি হয়ে যায় যতটা পরে আবিষ্কার হলে হতো।
প্র ০২
L01-এর calculate_shipping_cost বাউন্ডারি বাগটি যদি কোড লেখার সময়েই ইউনিট টেস্ট দিয়ে ধরা
পড়ত, বনাম প্রোডাক্টে রিলিজ হওয়ার পর একজন কাস্টমার রিপোর্ট করতেন — Production-এ কোন অতিরিক্ত খরচ/ঝুঁকি যোগ
হতো যা কোডিং পর্যায়ে থাকত না?
কাস্টমারের আস্থা নষ্ট হওয়া, সাপোর্ট টিকিট হ্যান্ডলিং, জরুরি হটফিক্স ডিপ্লয়মেন্ট প্রক্রিয়ার অতিরিক্ত চাপ, ভুল শিপিং চার্জের কারণে সম্ভাব্য আর্থিক ক্ষতি, এবং একটি পোস্ট-মর্টেম/ইনসিডেন্ট রিভিউ চালানোর প্রয়োজন — এগুলো সবই শুধু ডেভেলপারের কোড ঠিক করার সময়ের বাইরে অতিরিক্ত খরচ, যা কোডিং পর্যায়ে ধরা পড়লে লাগত না।
প্র ০৩ এই পাঠের কোড সেলে ব্যবহৃত গুণিতক সংখ্যাগুলো (১x, ৫x, ১০x, ১৫x, ৩০x) কি প্রতিটি প্রজেক্টে হুবহু একই রকম হওয়া উচিত? কেন বা কেন নয়?
না। এই সংখ্যাগুলো কমনলি-সাইটেড দৃষ্টান্তমূলক পরিসংখ্যান, প্রতিটি প্রজেক্টে নির্ভুলভাবে প্রযোজ্য নয় — বাস্তব অনুপাত প্রজেক্টের ধরন, ক্রিটিক্যালিটি, ও টিমের প্রক্রিয়ার পরিপক্বতার উপর নির্ভর করে ব্যাপকভাবে ভিন্ন হতে পারে। গুরুত্বপূর্ণ, সাধারণীকরণযোগ্য অন্তর্দৃষ্টি হলো এই ধারাবাহিক ঊর্ধ্বমুখী প্রবণতা — নির্দিষ্ট সংখ্যাগুলো নয়।
অনুশীলন
-
চিন্তা করুন: L01-এর
calculate_shipping_costবাউন্ডারি বাগটির কথা মনে করুন (>-এর বদলে>=হওয়ার কথা ছিল)। এই নির্দিষ্ট বাগটি সবচেয়ে সস্তায় কোন পর্যায়ে ধরা পড়তে পারত বলে আপনার মনে হয়, এবং কীভাবে?সবচেয়ে সস্তা হতো Requirements পর্যায়ে — যদি স্পেসিফিকেশন রিভিউ মিটিংয়ে কেউ প্রশ্ন তুলতেন, "১০০০ টাকা ঠিক এই মানে কী হবে, ফ্রি না চার্জড?" এই ধরনের অস্পষ্ট বাউন্ডারি নিয়ম নিয়ে আলোচনা করাই একটি সস্তা, প্রোঅ্যাকটিভ QA-ধরনের কার্যক্রম — কোনো কোড লেখার আগেই অস্পষ্টতা দূর হয়ে যেত।
-
পরীক্ষা করুন: উপরের কোড সেলে
base_cost-কে500-এ এবংn_defects-কে50-এ পরিবর্তন করে Run চেপে দেখুন মোট খরচ ও সাশ্রয় কীভাবে বদলায়, এবংratio-এর মান বদলায় কি না।মোট খরচ ও সাশ্রয় অনুপাতে বেড়ে যাবে (যেমন সাশ্রয় আগের চেয়ে অনেক বেশি টাকায় দেখাবে), কিন্তু
ratio-এর মান অপরিবর্তিত থেকে যাবে — এখনও৩০, কারণ এটি শুধু গুণিতকগুলোর অনুপাতের উপর নির্ভর করে (৩০/১),base_cost-এর প্রকৃত মানের উপর নয়।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পরবর্তী পাঠ L04 সফটওয়্যার টেস্টিং-এর সাতটি মূলনীতি — "early testing saves time and money" নীতিটি এই পাঠের উপর ভিত্তি করে আনুষ্ঠানিকভাবে দেখুন।
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ টেস্ট ডিজাইন টেকনিক, ইউনিট টেস্টিং, টেস্ট ডাবলস, ইন্টিগ্রেশন টেস্টিং, কভারেজ, অটোমেশন, পারফরম্যান্স ও সিকিউরিটি টেস্টিং, অ্যাডভান্সড টেকনিক ও CI/CD ইন্টিগ্রেশন — বাকি পাঠগুলো শীঘ্রই যুক্ত হবে।
- Software Engineering Principles & Git কোর্স সহোদর কোর্স SDLC-এর ধাপগুলো সেই কোর্সে বিস্তারিত শেখানো হয়েছে — এই কোর্স তার উপর ভিত্তি করে টেস্টিং-এর খরচ ও প্রভাব বিশ্লেষণ করে।
- সব 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 — সব এক জায়গায়।