সফটওয়্যার টেস্টিং কী ও কেন গুরুত্বপূর্ণ

What is software testing & why it matters

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

এক নজরে · TL;DR

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

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

সফটওয়্যার টেস্টিং-এর সংজ্ঞা এবং এটি ডিবাগিং থেকে ঠিক কীভাবে আলাদা
কেন টেস্টিং গুরুত্বপূর্ণ — আত্মবিশ্বাস, খরচ, এবং "বাগের উপস্থিতি বনাম অনুপস্থিতি" ধারণা
এই কোর্স ঠিক কী কভার করে ও কীভাবে সাজানো হয়েছে
Python-এর unittest দিয়ে একটি সত্যিকারের, চলমান ডেমো — একটি বাস্তব বাউন্ডারি বাগ কীভাবে টেস্টিং দিয়ে ধরা পড়ে

১ · সফটওয়্যার টেস্টিং কী

সফটওয়্যার টেস্টিংSoftware Testingকোড পরিকল্পিতভাবে চালিয়ে যাচাই করা যে এটি প্রত্যাশিত আচরণ করছে কি না, এবং কোথায় তা করছে না তা নিয়মতান্ত্রিকভাবে খুঁজে বের করা। মানে কোড লিখে "একবার চালিয়ে দেখলাম, কাজ করছে" এর চেয়ে অনেক বেশি কিছু। প্রকৃত টেস্টিং একটি নিয়মতান্ত্রিক প্রক্রিয়া — কোন ইনপুটগুলো পরীক্ষা করলে সবচেয়ে বেশি সম্ভাব্য বাগ ধরা পড়বে তা চিন্তা করে বেছে নেওয়া (M2-এ টেস্ট ডিজাইন টেকনিক), সেই টেস্টগুলো কোডে লিখে রাখা যাতে বারবার স্বয়ংক্রিয়ভাবে চালানো যায় (M3-M4), এবং ফলাফল বিশ্লেষণ করে বোঝা কোথায় ভরসা রাখা যায় আর কোথায় নয়।

টেস্টিং একটি ব্যর্থ টেস্ট দিয়ে সমস্যার অস্তিত্ব জানান দেয়; ডিবাগিং সেই ব্যর্থতার মূল কারণ খুঁজে সমাধান করে — এই দুটো আলাদা দক্ষতা, একই কাজ নয়।

২ · কেন টেস্টিং গুরুত্বপূর্ণ

আত্মবিশ্বাস
একটি ভালো টেস্ট স্যুট পাস করলে কোড পরিবর্তনের পরও নিশ্চিন্তে ডিপ্লয় করা যায় — প্রতিবার ম্যানুয়ালি পুরো অ্যাপ চেক করার দরকার পড়ে না।

খরচ
একটি বাগ যত পরে ধরা পড়ে, ঠিক করার খরচ তত বেশি বেড়ে যায় — ডিজাইনে ধরা পড়া বাগ আর প্রোডাকশনে ধরা পড়া বাগের মধ্যে বিশাল পার্থক্য (M1/L03-এ বিস্তারিত)।

উপস্থিতি, অনুপস্থিতি নয়
টেস্টিং বাগের উপস্থিতি দেখাতে পারে, কিন্তু কখনোই প্রমাণ করতে পারে না যে কোনো বাগ নেই — এটি টেস্টিং-এর একটি মৌলিক, স্বীকৃত সীমাবদ্ধতা।

Software Engineering & Git কোর্সের সাথে সম্পর্ক

Software Engineering Principles & Git কোর্সে সফটওয়্যার ডেভেলপমেন্ট লাইফসাইকেল (SDLC) ও সাধারণ ইঞ্জিনিয়ারিং প্রিন্সিপল শেখানো হয়েছে — এই কোর্স সেই ভিত্তির উপর দাঁড়িয়ে টেস্টিং ও কোয়ালিটি অ্যাসুরেন্সকে অনেক গভীরে নিয়ে যায়। Python Programming কোর্সের ভাষাগত ভিত্তি এখানে ধরে নেওয়া হয়েছে।

৩ · একটি সত্যিকারের বাগ-ধরার ডেমো

নিচের কোড সেলে একটি ছোট্ট calculate_shipping_cost ফাংশন আছে — নিয়ম হলো, অর্ডার টোটাল ১০০০ টাকা বা তার বেশি হলে শিপিং ফ্রি, নাহলে ৬০ টাকা চার্জ। ফাংশনটিতে একটি সূক্ষ্ম বাউন্ডারি বাগ লুকিয়ে আছে — Python-এর সত্যিকারের unittest মডিউল দিয়ে লেখা তিনটি টেস্ট কেস চালিয়ে দেখা যাক এটি ধরা পড়ে কি না (M2-এ "বাউন্ডারি ভ্যালু অ্যানালাইসিস" নামে এই টেকনিকটি ফরমালি শেখানো হবে)।

Python

import unittest

def calculate_shipping_cost(order_total):
    # নিয়ম: অর্ডার টোটাল 1000 টাকা বা তার বেশি হলে শিপিং ফ্রি, নাহলে 60 টাকা
    if order_total > 1000:
        return 0
    return 60

class ShippingCostTests(unittest.TestCase):
    def test_below_threshold(self):
        self.assertEqual(calculate_shipping_cost(500), 60)

    def test_above_threshold(self):
        self.assertEqual(calculate_shipping_cost(1500), 0)

    def test_at_threshold(self):
        # স্পেসিফিকেশন অনুযায়ী ঠিক 1000 টাকাতেও শিপিং ফ্রি হওয়ার কথা
        self.assertEqual(calculate_shipping_cost(1000), 0)

suite = unittest.TestLoader().loadTestsFromTestCase(ShippingCostTests)
unittest.TextTestRunner(verbosity=2).run(suite)

লক্ষ্য করুন test_at_threshold ব্যর্থ (FAIL) হয় — কারণ কোডে লেখা আছে order_total > 1000 (কঠোরভাবে বেশি), কিন্তু স্পেসিফিকেশন বলছে "1000 বা তার বেশি" (>= হওয়ার কথা)। ঠিক 1000 ইনপুটে ফাংশনটি ভুলভাবে 60 রিটার্ন করে, অথচ 0 হওয়ার কথা ছিল। এই ধরনের "অফ-বাই-ওয়ান" বা বাউন্ডারি বাগ ম্যানুয়ালি চোখে দেখে ধরা প্রায়ই কঠিন, কিন্তু একটি লক্ষ্যভেদী টেস্ট কেস সাথে সাথে ধরে ফেলে — এটিই স্বয়ংক্রিয় টেস্টিং-এর আসল শক্তি।

মূল কথা · Key takeaway

সফটওয়্যার টেস্টিং মানে কোডে ভরসা যাচাই করার একটি নিয়মতান্ত্রিক পদ্ধতি — এলোমেলোভাবে হাতে চালিয়ে দেখা নয়। একটি ভালো-ডিজাইন করা টেস্ট (যেমন উপরের বাউন্ডারি টেস্ট) এমন বাগ ধরতে পারে যা সহজ ম্যানুয়াল চেকে চোখ এড়িয়ে যায়। এই কোর্স ধাপে ধাপে — টেস্ট ডিজাইন থেকে অটোমেশন, পারফরম্যান্স, সিকিউরিটি ও CI/CD পর্যন্ত — এই নিয়মতান্ত্রিক পদ্ধতির সম্পূর্ণ টুলকিট শেখাবে।

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

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

প্র ০১ "টেস্টিং বাগের উপস্থিতি দেখাতে পারে, কিন্তু অনুপস্থিতি প্রমাণ করতে পারে না" — এর মানে কী, এবং এটি কেন গুরুত্বপূর্ণ?

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

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

ম্যানুয়াল চেক একবারের জন্য কার্যকর হতে পারে, কিন্তু ভবিষ্যতে কোড পরিবর্তন হলে (এমনকি সম্পূর্ণ ভিন্ন একটি ফিচারে) সেই পুরনো আচরণ এখনও ঠিক আছে কি না তা আবার ম্যানুয়ালি যাচাই করা বাস্তবে অসম্ভব হয়ে যায়। লেখা টেস্ট কোড পুনরাবৃত্তিযোগ্য ও স্বয়ংক্রিয় — এক সেকেন্ডে শত শত পুরনো আচরণ আবার যাচাই করে ফেলে (একেই "রিগ্রেশন টেস্টিং" বলা হয়, M5/L22-এ বিস্তারিত), যা ম্যানুয়াল চেকে কখনোই সম্ভব নয়।

প্র ০৩ উপরের কোড সেলে ঠিক কোন লাইনে বাগ আছে, এবং এটি ঠিক করতে কী পরিবর্তন করতে হবে?

বাগটি আছে if order_total > 1000: লাইনে — এখানে কঠোর "বেশি" (>) ব্যবহার করা হয়েছে, কিন্তু স্পেসিফিকেশন অনুযায়ী "1000 বা তার বেশি" বোঝাতে >= ব্যবহার করা উচিত। >-কে >=-এ পরিবর্তন করলেই test_at_threshold সহ তিনটি টেস্টই পাস করবে।

অনুশীলন

চিন্তা করুন: উপরের calculate_shipping_cost ফাংশনের জন্য আর কোন কোন ইনপুট মান পরীক্ষা করা উচিত বলে আপনার মনে হয়? (হিন্ট: থ্রেশহোল্ডের ঠিক এক টাকা কমে কী হয়? নেগেটিভ বা শূন্য অর্ডার টোটালে কী হওয়া উচিত?)

ভালো প্রার্থী: 999 (থ্রেশহোল্ডের ঠিক নিচে, ৬০ টাকা হওয়ার কথা — এটি বর্তমান কোডে সঠিকভাবেই কাজ করে), 0 বা নেগেটিভ মান (স্পেসিফিকেশনে অস্পষ্ট — এমন ইনপুট বাস্তবে ঘটা উচিত না হলেও, ফাংশনটি কী করে তা যাচাই করে রাখা ভালো অভ্যাস)। এই ধরনের "থ্রেশহোল্ডের ঠিক আশেপাশের মান" বেছে নেওয়ার পদ্ধতিগত কৌশলই M2/L06-এ "বাউন্ডারি ভ্যালু অ্যানালাইসিস" নামে শেখানো হবে।
পরীক্ষা করুন: উপরের কোড সেলে if order_total > 1000:-কে if order_total >= 1000:-এ পরিবর্তন করে Run চেপে দেখুন এখন তিনটি টেস্টই পাস করে কি না।

হ্যাঁ — >=-এ পরিবর্তনের পর calculate_shipping_cost(1000) এখন সঠিকভাবে 0 রিটার্ন করবে, তাই test_at_threshold-সহ তিনটি টেস্টই পাস করবে এবং আউটপুটে "OK" দেখাবে, আগের "FAILED (failures=1)"-এর বদলে।