কী অটোমেট করবেন, কী ম্যানুয়াল রাখবেন

What to automate vs what to keep manual

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

এক নজরে · TL;DR

সব টেস্ট অটোমেট করার চেষ্টা করা ভুল লক্ষ্য — অটোমেশনেরও একটি খরচ আছে (লেখা, রক্ষণাবেক্ষণ), তাই বিচার করে বেছে নিতে হয় কোনটি অটোমেট করলে সবচেয়ে বেশি মূল্য পাওয়া যাবে।
অটোমেট করার ভালো প্রার্থী: স্থিতিশীল (কম পরিবর্তনশীল), পুনরাবৃত্তিমূলক (বারবার চালাতে হয়), নিয়ন্ত্রিত/ডিটারমিনিস্টিক ফলাফল (স্পষ্ট পাস/ফেইল)।
ম্যানুয়াল রাখার ভালো প্রার্থী: এক্সপ্লোরেটরি (M10/L44), ব্যবহারযোগ্যতা (usability) মূল্যায়ন, একবারের চেক, দ্রুত-পরিবর্তনশীল UI।
কোড সেলে একটি সত্যিকারের ওয়েটেড-স্কোরিং ফাংশন দিয়ে চারটি উদাহরণ টেস্ট-দৃশ্যকে বাস্তবে র‍্যাংক করা হয়েছে — কোনটি আগে অটোমেট করা উচিত তা সংখ্যা দিয়ে দেখানো।

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

অটোমেশন কেন "সব কিছুর জন্য সবসময় সঠিক উত্তর" নয় — অটোমেশনের নিজস্ব খরচ
কোন বৈশিষ্ট্যগুলো একটি টেস্টকে ভালো অটোমেশন-প্রার্থী বানায়, কোনগুলো ম্যানুয়ালে রাখার পক্ষে যুক্তি দেয়
Python দিয়ে একটি ওয়েটেড-স্কোরিং ফাংশন লিখে একাধিক দৃশ্যকে বস্তুনিষ্ঠভাবে র‍্যাংক করা
এক্সপ্লোরেটরি টেস্টিং-এর সাথে সম্পর্ক (M10/L44-এ বিস্তারিত)

১ · অটোমেশনের নিজস্ব খরচ আছে

একটি সাধারণ ভুল ধারণা হলো "যত বেশি অটোমেশন তত ভালো"। বাস্তবে প্রতিটি অটোমেটেড টেস্ট লেখা, রিভিউ করা, এবং UI বা স্পেসিফিকেশন বদলালে রক্ষণাবেক্ষণ করার খরচ বহন করে (M7/L31-এ মেইনটেইনেবিলিটি বিস্তারিত)। যদি একটি চেক কালই আবার ম্যানুয়ালি করতে হতো, আর সেটি খুব কম সময়েই পরিবর্তিত হয়ে যায়, তাহলে সেটি অটোমেট করার প্রচেষ্টা প্রায়ই তার মূল্যের চেয়ে বেশি খরচ করে ফেলে।

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

ম্যানুয়াল রাখুন যখন
চেকটি এক্সপ্লোরেটরি (M10/L44 — মানুষের বিচারশক্তি লাগে), ব্যবহারযোগ্যতা/নান্দনিকতা-কেন্দ্রিক, একবারের জন্য, অথবা UI/স্পেসিফিকেশন প্রায়ই বদলায়।

এক্সপ্লোরেটরি টেস্টিং-এর সাথে সম্পর্ক

এক্সপ্লোরেটরি টেস্টিং — যেখানে একজন দক্ষ টেস্টার একই সাথে শেখা, টেস্ট ডিজাইন করা ও চালানো করেন — সংজ্ঞা অনুযায়ীই অটোমেট করা যায় না, কারণ এর মূল্য মানুষের অপ্রত্যাশিত পর্যবেক্ষণে (M10/L44-এ বিস্তারিত)। এই পাঠের স্কোরিং মডেল সেই ধরনের কাজকে সবসময় কম স্কোর দেবে — এবং সেটাই প্রত্যাশিত, কারণ তারা ভিন্ন ধরনের মূল্য দেয়, অটোমেশনের বিকল্প নয়।

২ · একটি ওয়েটেড-স্কোরিং মডেল

তিনটি মানদণ্ড ব্যবহার করা যাক — পুনরাবৃত্তির হার (কত ঘন ঘন এই চেকটি চালানো দরকার), স্থিতিশীলতা (আচরণ/UI কতটা কম বদলায়), আর ম্যানুয়াল-চালানোর খরচ (হাতে করলে কতটা সময়সাপেক্ষ/একঘেয়ে) — প্রতিটির একটি ওজন (weight) সহ, যেগুলোর যোগফল অবশ্যই ১.০ হতে হবে।

Python

import math

# ওজন — যোগফল অবশ্যই ১.০ হতে হবে
WEIGHTS = {"repetition": 0.40, "stability": 0.35, "manual_cost": 0.25}
assert math.isclose(sum(WEIGHTS.values()), 1.0), "ওজনের যোগফল ১.০ হতে হবে"

# প্রতিটি মানদণ্ডে ০ (সবচেয়ে কম) থেকে ১ (সবচেয়ে বেশি) স্কেলে রেটিং — টিমের বিচারবোধ থেকে আসা
scenarios = {
    "লগইন ফর্ম ভ্যালিডেশন":        {"repetition": 0.90, "stability": 0.85, "manual_cost": 0.60},
    "চেকআউট রিগ্রেশন স্যুট":       {"repetition": 0.95, "stability": 0.70, "manual_cost": 0.80},
    "নতুন মার্কেটিং ব্যানার চেক":   {"repetition": 0.10, "stability": 0.20, "manual_cost": 0.30},
    "এক্সপ্লোরেটরি UX রিভিউ":      {"repetition": 0.05, "stability": 0.15, "manual_cost": 0.50},
}

def automation_score(ratings, weights=WEIGHTS):
    return sum(weights[k] * ratings[k] for k in weights)

ranked = sorted(scenarios.items(), key=lambda kv: automation_score(kv[1]), reverse=True)

print("অটোমেশন-প্রার্থী র‍্যাংকিং (সবচেয়ে বেশি স্কোর আগে):\n")
for rank, (name, ratings) in enumerate(ranked, start=1):
    score = automation_score(ratings)
    verdict = "অটোমেট করুন" if score >= 0.5 else "ম্যানুয়াল রাখুন"
    print(f"{rank}. {name:26s} স্কোর = {score:.4f}  →  {verdict}")

র‍্যাংকিং এভাবে দাঁড়ায়: চেকআউট রিগ্রেশন স্যুট (স্কোর ≈ ০.৮২৫) ও লগইন ফর্ম ভ্যালিডেশন (স্কোর ≈ ০.৮০৭৫) — দুটোই ০.৫-এর অনেক উপরে, স্পষ্টভাবে অটোমেশনের ভালো প্রার্থী। অন্যদিকে এক্সপ্লোরেটরি UX রিভিউ (≈ ০.১৯৭৫) ও নতুন মার্কেটিং ব্যানার চেক (≈ ০.১৮৫) — দুটোই ০.৫-এর অনেক নিচে, যা নিশ্চিত করে এগুলো ম্যানুয়াল রাখাই যুক্তিসঙ্গত। লক্ষ্য করুন এক্সপ্লোরেটরি রিভিউয়ের স্কোর মার্কেটিং ব্যানারের চেয়ে সামান্য বেশি হলেও — কারণ, সংখ্যাগত স্কোর নির্বিশেষে, এক্সপ্লোরেটরি কাজ প্রকৃতিগতভাবেই মানুষের বিচারশক্তি দাবি করে, তাই বাস্তবে সবসময় ম্যানুয়াল থাকবে।

মূল কথা · Key takeaway

অটোমেশন সিদ্ধান্ত একটি বাইনারি নিয়ম নয় ("সব অটোমেট করো" বা "কিছুই না") — এটি একটি খরচ-বনাম-মূল্য বিশ্লেষণ। স্থিতিশীল, পুনরাবৃত্তিমূলক, ব্যয়বহুল-ম্যানুয়াল-এক্সিকিউশন চেকগুলো অটোমেশনে সবচেয়ে বেশি রিটার্ন দেয়; অস্থির, একবারের, বা মানুষের বিচারশক্তি-নির্ভর চেকগুলো ম্যানুয়াল থাকাই বুদ্ধিমানের কাজ।

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

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

প্র ০১ একটি টেস্ট যা মাত্র একবার (একটি নির্দিষ্ট রিলিজের জন্য) চালাতে হবে, কিন্তু চালাতে ম্যানুয়ালি ৩ ঘণ্টা লাগে — এটি কি ভালো অটোমেশন-প্রার্থী? উপরের স্কোরিং মডেলে এটি কীভাবে প্রতিফলিত হবে?

সম্ভবত না — manual_cost বেশি হলেও repetition খুব কম হবে (একবারই চালাতে হবে), তাই মডেলের ওজন অনুযায়ী চূড়ান্ত স্কোর কম হওয়ার কথা। এটি বাস্তব যুক্তির সাথেও মেলে — একবারের জন্য অটোমেশন স্ক্রিপ্ট লেখার খরচ প্রায়ই সরাসরি একবার ম্যানুয়ালি চালানোর খরচের চেয়ে বেশি হয়ে যায়, যদি না ভবিষ্যতেও এটি বারবার লাগার সম্ভাবনা থাকে।

প্র ০২ একটি ফিচারের UI প্রতি স্প্রিন্টে ব্যাপকভাবে বদলাচ্ছে (এখনও ডিজাইন স্থির হয়নি) — এই মুহূর্তে এর UI টেস্ট অটোমেট করা কেন ঝুঁকিপূর্ণ হতে পারে?

UI বদলালে অটোমেটেড সিলেক্টর/ইন্টারঅ্যাকশনও বদলাতে হবে, তাই প্রতি স্প্রিন্টে টেস্ট স্ক্রিপ্ট নতুন করে ঠিক করতে হবে — যা প্রায়ই নতুন ফিচার তৈরির চেয়ে বেশি সময় নিয়ে ফেলে। উপরের মডেলে এটি কম stability স্কোর হিসেবে ধরা পড়বে, ফলে চূড়ান্ত স্কোরও কমে যাবে — ডিজাইন স্থির হওয়া পর্যন্ত ম্যানুয়াল রাখাই বাস্তবসম্মত।

প্র ০৩ উপরের কোড সেলে ওজন {"repetition": 0.40, "stability": 0.35, "manual_cost": 0.25} ব্যবহার করা হয়েছে। যদি একটি টিম manual_cost-কে সবচেয়ে বেশি গুরুত্ব দিতে চায়, কী পরিবর্তন করতে হবে, এবং তাতে র‍্যাংকিং-এর উপর কী প্রভাব পড়তে পারে?

manual_cost-এর ওজন বাড়িয়ে (যেমন ০.৫০) আর বাকি দুটো কমিয়ে যোগফল ১.০ রাখতে হবে। এতে যেসব চেক ম্যানুয়ালি চালাতে সবচেয়ে বেশি সময়সাপেক্ষ (যেমন চেকআউট রিগ্রেশন স্যুট, যার manual_cost = ০.৮০) সেগুলোর স্কোর আরও বাড়বে, আর কম ম্যানুয়াল-খরচের চেকগুলোর আপেক্ষিক গুরুত্ব কমবে — ওজন বদলালে র‍্যাংকিং-ও বদলাতে পারে, যা দেখায় এই মডেলের সিদ্ধান্ত টিমের অগ্রাধিকারের উপর নির্ভরশীল, একটি চূড়ান্ত সত্য নয়।

অনুশীলন

চিন্তা করুন: আপনার পরিচিত কোনো অ্যাপ বা ওয়েবসাইটের একটি ফিচার নিয়ে ভাবুন। সেটির জন্য একটি টেস্ট দৃশ্য কল্পনা করুন যা স্পষ্টভাবে অটোমেশনের ভালো প্রার্থী, আর আরেকটি যা স্পষ্টভাবে ম্যানুয়াল রাখা উচিত। কোন বৈশিষ্ট্যগুলো আপনাকে সিদ্ধান্তে পৌঁছাতে সাহায্য করলো?

সাধারণ প্যাটার্ন: লগইন, পেমেন্ট গণনা, ফর্ম ভ্যালিডেশন-এর মতো স্থিতিশীল, নিয়ম-ভিত্তিক আচরণ অটোমেশনের ভালো প্রার্থী। নতুন ফিচারের প্রথম ভিজ্যুয়াল/UX রিভিউ, বা "এটি ব্যবহার করতে স্বাভাবিক লাগছে কি না" জাতীয় প্রশ্ন ম্যানুয়াল/এক্সপ্লোরেটরি থাকাই ভালো — এই ধরনের প্রশ্নের কোনো একক "সঠিক" আউটপুট নেই যা একটি assertion দিয়ে চেক করা যায়।
পরীক্ষা করুন: উপরের কোড সেলে scenarios ডিকশনারিতে নিজের একটি পঞ্চম দৃশ্য (স্বনামে, তিনটি রেটিং সহ) যোগ করে Run চেপে দেখুন এটি র‍্যাংকিং-এ কোথায় স্থান পায়।

যদি নতুন দৃশ্যের তিনটি রেটিংই বেশি (যেমন সবগুলো ০.৭-এর উপরে) হয়, এটি র‍্যাংকিং-এর শীর্ষের কাছাকাছি বসবে; রেটিং কম হলে নিচের দিকে। কোড নিজে থেকেই sorted(...) দিয়ে সঠিক অবস্থানে বসাবে — কোনো হার্ডকোড করা অবস্থান নেই, তাই নতুন ডেটার সাথে স্বয়ংক্রিয়ভাবে মানিয়ে নেয়।

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

১ · অটোমেশনের নিজস্ব খরচ আছে

২ · একটি ওয়েটেড-স্কোরিং মডেল

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

অনুশীলন

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