পাঠ ০২ · ৫৭-এর মধ্যে · মডিউল ১
Home / Courses / Software Testing & Quality Assurance / টেস্টিং vs QA vs QC

টেস্টিং বনাম QA বনাম QC — পার্থক্য

Testing vs QA vs QC — the difference
৭ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

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

  • Testing, QA, QC-এর যথাযথ সংজ্ঞা এবং একে অপরের সাথে তাদের সম্পর্ক
  • প্রক্রিয়া-কেন্দ্রিক (process) বনাম প্রোডাক্ট-কেন্দ্রিক (product) দৃষ্টিভঙ্গির পার্থক্য
  • প্রোঅ্যাকটিভ (আগে থেকে প্রতিরোধ) বনাম রিঅ্যাকটিভ (পরে খুঁজে বের করা) দৃষ্টিভঙ্গির পার্থক্য
  • Python দিয়ে বাস্তব উদাহরণ classify করে তিনটির মধ্যে পার্থক্য নিশ্চিত করা

১ · তিনটি সংজ্ঞা

এই তিনটি শব্দ প্রায়ই সমার্থক হিসেবে ব্যবহৃত হয়, কিন্তু বাস্তবে এদের স্কোপ ভিন্ন। TestingTestingসফটওয়্যার সত্যিকারভাবে চালিয়ে দেখা যে এটি প্রত্যাশিতভাবে আচরণ করছে কি না, এবং তাতে বাগ খুঁজে বের করা। হলো একটি নির্দিষ্ট কার্যক্রম — সফটওয়্যার চালিয়ে দেখা এবং তাতে বাগ খুঁজে বের করা। QAQuality Assuranceউন্নয়ন প্রক্রিয়া নিজেই উন্নত করে ভবিষ্যতে বাগ সৃষ্টি হওয়ার সম্ভাবনা কমানো — প্রোঅ্যাকটিভ, প্রক্রিয়া-কেন্দ্রিক। (Quality Assurance) হলো উন্নয়ন প্রক্রিয়া-কেন্দ্রিক একটি প্রোঅ্যাকটিভ কার্যক্রম — কোডিং স্ট্যান্ডার্ড ঠিক করা, কোড রিভিউ প্রসেস তৈরি করা, ডেভেলপারদের প্রশিক্ষণ দেওয়ার মতো কাজ করে যাতে বাগ প্রথমেই তৈরি হওয়ার সম্ভাবনা কমে। QCQuality Controlতৈরি হওয়া প্রোডাক্টে বাগ খুঁজে বের করা — রিঅ্যাকটিভ, প্রোডাক্ট-কেন্দ্রিক। Testing হলো QC-এর একটি প্রধান কার্যক্রম। (Quality Control) হলো তৈরি হওয়া প্রোডাক্টে-কেন্দ্রিক একটি রিঅ্যাকটিভ কার্যক্রম — ইতিমধ্যে লেখা কোড বা তৈরি ফিচারে বাগ আছে কি না তা যাচাই করে। Testing হলো QC বাস্তবায়নের সবচেয়ে গুরুত্বপূর্ণ, execution-based কার্যক্রম।

QA · Quality Assurance — প্রক্রিয়া-কেন্দ্রিক, প্রোঅ্যাকটিভ QC · Quality Control — প্রোডাক্ট-কেন্দ্রিক, রিঅ্যাকটিভ Testing সফটওয়্যার চালিয়ে বাগ খোঁজার কার্যক্রম — QC-এর একটি অংশ
QA সবচেয়ে বিস্তৃত — পুরো ডেভেলপমেন্ট প্রক্রিয়া উন্নত করে বাগ প্রতিরোধ করতে চায়। QC তার একটি অংশ — তৈরি হওয়া প্রোডাক্টে বাগ খুঁজে বের করে। Testing হলো QC বাস্তবায়নের প্রধান কার্যক্রম — সফটওয়্যার সত্যিই চালিয়ে দেখা।

২ · বাস্তব উদাহরণে পার্থক্য

QA-এর উদাহরণ
কোডিং স্ট্যান্ডার্ড ডকুমেন্ট লেখা, কোড রিভিউ চেকলিস্ট তৈরি করা, টিমকে Git কমিট কনভেনশন শেখানো — এগুলো সরাসরি কোনো প্রোডাক্ট চেক করে না, বরং ভবিষ্যতের সব কাজের মান উন্নত করে।
QC-এর উদাহরণ
একটি তৈরি ফিচার রিকোয়ারমেন্ট পূরণ করেছে কি না ম্যানুয়ালি যাচাই করা, রিলিজের আগে চেকলিস্ট অনুযায়ী প্রোডাক্ট পরীক্ষা করা — নির্দিষ্ট প্রোডাক্টে ফোকাস।
Testing-এর উদাহরণ
একটি ইউনিট টেস্ট স্যুট চালানো, একটি ফিচারের রিগ্রেশন টেস্ট রান করা — সফটওয়্যার সত্যিকারভাবে execute করে ফলাফল যাচাই করা (একটি QC কার্যক্রম)।
লক্ষ্য করুন বাস্তব প্রতিষ্ঠানে অনেক সময় একটি টিমের নাম "QA Team" রাখা হয়, যদিও তাদের দৈনন্দিন কাজ মূলত টেস্টিং/QC-ধরনের (ফিচার চালিয়ে বাগ খোঁজা) — নামকরণ এখানে বিভ্রান্তিকর হতে পারে। প্রকৃত QA কার্যক্রম (প্রক্রিয়া উন্নয়ন) আলাদা এবং প্রায়ই পুরো ইঞ্জিনিয়ারিং টিমের যৌথ দায়িত্ব — শুধু একটি নির্দিষ্ট টিমের কাজ নয়।

৩ · Python দিয়ে classify করা

নিচের কোড সেলে কয়েকটি বাস্তব কার্যক্রমকে তিনটি বৈশিষ্ট্য দিয়ে বর্ণনা করা হয়েছে — এটি process-কেন্দ্রিক নাকি product-কেন্দ্রিক, এটি proactive নাকি reactive, এবং এটি সফটওয়্যার সত্যিই execute করে কি না। একটি ছোট্ট classify() ফাংশন এই তথ্যের উপর ভিত্তি করে প্রতিটি কার্যক্রমকে QA, QC বা Testing বিভাগে ফেলে, এবং একটি সত্যিকারের unittest স্যুট নিশ্চিত করে যে classifier-টি প্রতিটি সীমান্ত-কেসে সঠিক সিদ্ধান্ত নিচ্ছে।

Python
import unittest

def classify(activity):
    """
    activity: dict, keys:
      - focus: 'process' অথবা 'product'
      - runs_the_software: bool — কার্যক্রমটি কি সফটওয়্যার সত্যিই চালায়?
    রিটার্ন করে: 'QA', 'QC', অথবা 'Testing'
    """
    if activity["focus"] == "process":
        return "QA"
    if activity["runs_the_software"]:
        return "Testing"
    return "QC"

activities = [
    {"name": "কোডিং স্ট্যান্ডার্ড ডকুমেন্ট লেখা",                       "focus": "process", "runs_the_software": False},
    {"name": "কোড রিভিউ চেকলিস্ট তৈরি করা",                          "focus": "process", "runs_the_software": False},
    {"name": "রিগ্রেশন টেস্ট স্যুট চালানো",                            "focus": "product", "runs_the_software": True},
    {"name": "ফিচার রিকোয়ারমেন্ট পূরণ করেছে কি না ম্যানুয়ালি যাচাই করা", "focus": "product", "runs_the_software": False},
]

for a in activities:
    print(f"{a['name']:45s} -> {classify(a)}")

class ClassifierTests(unittest.TestCase):
    def test_process_activity_is_qa(self):
        self.assertEqual(
            classify({"focus": "process", "runs_the_software": False}), "QA"
        )

    def test_product_activity_that_runs_software_is_testing(self):
        self.assertEqual(
            classify({"focus": "product", "runs_the_software": True}), "Testing"
        )

    def test_product_activity_without_running_software_is_qc(self):
        self.assertEqual(
            classify({"focus": "product", "runs_the_software": False}), "QC"
        )

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

    
লক্ষ্য করুন classify()-এর সিদ্ধান্ত-নেওয়ার ক্রম নিজেই সংজ্ঞাগুলো প্রতিফলিত করে — প্রথমে জিজ্ঞেস করে "এটি কি প্রক্রিয়া উন্নয়নের কাজ?" (হ্যাঁ হলে QA), তারপর "এটি কি সফটওয়্যার সত্যিই চালায়?" (হ্যাঁ হলে Testing, নাহলে QC)। তিনটি unittest কেসই পাস করে, কারণ ফাংশনটি প্রতিটি সীমান্ত-কেসে সঠিক সিদ্ধান্ত দিচ্ছে।
মূল কথা · Key takeaway

Testing, QA, ও QC তিনটি ভিন্ন স্কোপের ধারণা — Testing একটি নির্দিষ্ট কার্যক্রম, QC তার বিস্তৃত ক্যাটেগরি (প্রোডাক্ট-কেন্দ্রিক, রিঅ্যাকটিভ), আর QA আরও বিস্তৃত — পুরো প্রক্রিয়া উন্নত করার প্রোঅ্যাকটিভ প্রচেষ্টা। এই পার্থক্য স্পষ্ট থাকলে একটি টিম বুঝতে পারে কেন শুধু বেশি টেস্ট চালানো (QC) কখনোই প্রক্রিয়াগত সমস্যার (যেখানে QA দরকার) পূর্ণ সমাধান নয়।

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

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

প্র ০১ একজন টিম লিড বলছেন, "আমাদের QA টিম প্রতিটি রিলিজের আগে টেস্ট করে" — এই বাক্যে টেস্টিং, QA, QC শব্দগুলো ঠিকভাবে ব্যবহৃত হয়েছে কি? না হলে কীভাবে বলা উচিত ছিল?

কঠোরভাবে দেখলে না। "রিলিজের আগে টেস্ট করা" আসলে একটি QC/Testing কার্যক্রম বর্ণনা করছে, QA কার্যক্রম নয়। বাস্তবে অনেক প্রতিষ্ঠানে টিমের নাম "QA Team" রাখা হলেও তাদের দৈনন্দিন কাজ মূলত টেস্টিং। আরও নির্ভুলভাবে বলা যেত — "আমাদের টেস্টিং টিম প্রতিটি রিলিজের আগে QC হিসেবে টেস্ট চালায়।" প্রকৃত QA কার্যক্রম (প্রক্রিয়া উন্নয়ন) আলাদা।

প্র ০২ একটি টিম কখনো কোনো কোডিং স্ট্যান্ডার্ড, রিভিউ প্রসেস বা চেকলিস্ট তৈরি করে না — শুধু প্রোডাক্ট রিলিজের আগে টেস্ট করে বাগ খোঁজে। তাদের কাছে QC আছে কিন্তু QA নেই — এটি কেন সমস্যাজনক?

QA ছাড়া, একই ধরনের ভুল (যেমন একই ধরনের বাউন্ডারি বাগ, একই কোডিং অভ্যাসজনিত সমস্যা) বারবার নতুন ফিচারে ফিরে আসতে থাকে, কারণ মূল কারণ (root cause) — প্রক্রিয়াগত দুর্বলতা — কখনো সমাধান হয় না। শুধু QC-এর উপর নির্ভর করা মানে প্রতিবার বাগ প্রোডাক্টে তৈরি হওয়ার পরই ধরা পড়ে, যা L03-এ দেখা "পরে ধরা পড়া বাগ বেশি খরচে ঠিক করতে হয়" নীতির সাথে সরাসরি যুক্ত।

প্র ০৩ "Testing হলো QC-এর একটি কার্যক্রম" — এই বাক্যটির মানে একটি উদাহরণসহ ব্যাখ্যা করুন।

এর মানে QC-এর আওতা টেস্টিং-এর চেয়ে বড়। যেমন — একটি সম্পূর্ণ তৈরি ফিচার কোনো কোড না চালিয়ে শুধু ডকুমেন্টেশন ও UI স্ক্রিনশট দেখে রিকোয়ারমেন্ট পূরণ করেছে কি না যাচাই করাও একটি QC কার্যক্রম (প্রোডাক্ট-কেন্দ্রিক, রিঅ্যাকটিভ), কিন্তু যেহেতু এতে সফটওয়্যার সত্যিই চালানো হয়নি, উপরের কোড সেলের classify() অনুযায়ী এটি "Testing" নয়, শুধু "QC" — Testing হলো নির্দিষ্টভাবে execution-based QC কার্যক্রম।

অনুশীলন

  1. চিন্তা করুন: আপনার নিজের পড়াশোনা বা কাজের অভিজ্ঞতা থেকে আরও ৩টি কার্যক্রমের কথা ভাবুন, এবং উপরের তিনটি প্রশ্ন ("এটি কি প্রক্রিয়া না প্রোডাক্ট-কেন্দ্রিক?", "প্রোঅ্যাকটিভ না রিঅ্যাকটিভ?", "সফটওয়্যার সত্যিই চালায় কি?") দিয়ে সেগুলোকে QA/QC/Testing-এ শ্রেণীবদ্ধ করুন।

    কিছু ভালো উদাহরণ: "একটি টিম-ওয়াইড পেয়ার-প্রোগ্রামিং নীতি চালু করা" (QA — process, proactive), "একটি সিকিউরিটি বাগের জন্য কোড ম্যানুয়ালি পড়ে (না চালিয়ে) রিভিউ করা" (QC — product, কিন্তু execution ছাড়া), "একটি স্মোক টেস্ট চালিয়ে দেখা ডিপ্লয়মেন্ট সফল হয়েছে কি না" (Testing — product, execution-based)। সঠিক উত্তর একটাই নয়, গুরুত্বপূর্ণ হলো তিনটি প্রশ্ন দিয়ে যুক্তিসঙ্গতভাবে যাচাই করা।

  2. পরীক্ষা করুন: উপরের কোড সেলের activities লিস্টে নিজের একটি নতুন কার্যক্রম dict হিসেবে যোগ করুন (নিজের focus ও runs_the_software মান দিয়ে), তারপর Run চেপে দেখুন classify() এটিকে কী হিসেবে চিহ্নিত করে।

    উদাহরণস্বরূপ {"name": "স্মোক টেস্ট চালানো", "focus": "product", "runs_the_software": True} যোগ করলে আউটপুটে এটি Testing হিসেবে দেখাবে, কারণ এটি product-কেন্দ্রিক এবং সফটওয়্যার সত্যিই চালায় — classify()-এর যুক্তি অনুযায়ী এটিই প্রত্যাশিত ফলাফল। মূল তিনটি unittest কেসের ফলাফলে কোনো পরিবর্তন হবে না, কারণ classifier ফাংশনটি নিজেই অপরিবর্তিত থাকে।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

  • পরবর্তী পাঠ L03 বাগের প্রকৃত খরচ — কেন আগে ধরা সস্তা। QC/Testing দুর্বল হলে কেন বাগ পরে ধরা পড়ে এবং সেটির প্রকৃত খরচ কেমন বাড়ে তা গণনাসহ দেখুন।
  • কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ টেস্ট ডিজাইন টেকনিক, ইউনিট টেস্টিং, টেস্ট ডাবলস, ইন্টিগ্রেশন টেস্টিং, কভারেজ, অটোমেশন, পারফরম্যান্স ও সিকিউরিটি টেস্টিং, অ্যাডভান্সড টেকনিক ও CI/CD ইন্টিগ্রেশন — বাকি পাঠগুলো শীঘ্রই যুক্ত হবে।
  • Software Engineering Principles & Git কোর্স সহোদর কোর্স SDLC ও সাধারণ ইঞ্জিনিয়ারিং প্রিন্সিপলের ভিত্তি সেই কোর্সেই তৈরি হয়েছে — এই কোর্স টেস্টিং ও QA/QC-কে গভীরে নিয়ে যায়।
  • সব 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 — সব এক জায়গায়।
আগের পাঠ
সফটওয়্যার টেস্টিং কী ও কেন গুরুত্বপূর্ণ