টেস্ট প্ল্যানিং ও স্ট্র্যাটেজি
এই পাঠে যা শিখবেন
- টেস্ট প্ল্যান কী, এবং কেন প্রতিটি বড় টেস্টিং প্রচেষ্টার আগে এটি লেখা দরকার
- একটি ভালো টেস্ট প্ল্যানের ৬টি মূল অংশ — স্কোপ, উদ্দেশ্য, রিসোর্স, শিডিউল, রিস্ক এলাকা, এন্ট্রি/এক্সিট ক্রাইটেরিয়া
- এন্ট্রি বনাম এক্সিট ক্রাইটেরিয়ার পার্থক্য এবং বাস্তব উদাহরণ
- একটি সত্যিকারের Python ফাংশন দিয়ে একটি ড্রাফট টেস্ট প্ল্যান সম্পূর্ণ কি না তা যাচাই
১ · টেস্ট প্ল্যান কী ও কেন দরকার
টেস্ট প্ল্যানTest Planএকটি লিখিত দলিল যা টেস্টিং প্রচেষ্টার স্কোপ, পদ্ধতি, রিসোর্স ও শিডিউল নির্ধারণ করে। হলো এমন একটি দলিল যা টিমকে একটি সাধারণ প্রশ্নের উত্তর দেয়: "আমরা ঠিক কী টেস্ট করছি, কেন, কারা করছে, আর কখন বলা যাবে এটি যথেষ্ট হয়েছে?" এটি কোনো আমলাতান্ত্রিক কাগজপত্র নয় — এটি ছাড়া বড় একটি প্রজেক্টে টেস্টিং সহজেই এলোমেলো হয়ে পড়ে: একজন টেস্টার একই ফিচার তিনবার চেক করেন, অন্যদিকে পেমেন্ট গেটওয়ের মতো ক্রিটিক্যাল এলাকা কেউ ছোঁয়ই না, কারণ কেউ ধরে নিয়েছিল অন্য কেউ করবে। Software Engineering Principles & Git কোর্সে SDLC-এর সাধারণ কাঠামো ধরে নেওয়া হয়েছে — টেস্ট প্ল্যান সেই কাঠামোর মধ্যে "টেস্টিং" অংশটুকু কীভাবে সংগঠিত হবে তা নির্দিষ্ট করে।
২ · একটি টেস্ট প্ল্যানে যা থাকে
টেস্ট প্ল্যানের বিস্তারিত ফরম্যাট টিম থেকে টিমে ভিন্ন হতে পারে, কিন্তু নিচের ছয়টি অংশ প্রায় প্রতিটি বাস্তব টেস্ট প্ল্যানে থাকে:
কোন ফিচার/মডিউল টেস্ট করা হবে, আর কোনটি ইচ্ছাকৃতভাবে বাদ থাকবে — যেমন "শুধু চেকআউট ফ্লো, প্রোফাইল সেটিংস এই রাউন্ডে নয়।"
এই টেস্টিং রাউন্ড দিয়ে কী অর্জন করতে চাই — যেমন "রিলিজের আগে সব ক্রিটিক্যাল-প্রায়োরিটি বাগ শূন্যে নামানো।"
কতজন টেস্টার, কী টুল, কোন এনভায়রনমেন্ট (স্টেজিং সার্ভার, টেস্ট ডেটা) প্রয়োজন।
টেস্টিং কবে শুরু, কবে শেষ, কোন মাইলস্টোন কবে — রিলিজ ডেটের সাথে সংযুক্ত।
কোন অংশে বাগ হলে সবচেয়ে বেশি ক্ষতি হবে, তাই বেশি মনোযোগ দরকার (L49-এ রিস্ক-বেসড প্রায়োরিটাইজেশন বিস্তারিত)।
টেস্টিং কবে শুরু করা "নিরাপদ", আর কবে বলা যাবে যথেষ্ট টেস্ট করা হয়েছে — নিচে বিস্তারিত।
৩ · এন্ট্রি ও এক্সিট ক্রাইটেরিয়া গভীরে
এই দুটি সবচেয়ে বেশি ভুল বোঝা হয় এবং সবচেয়ে বেশি গুরুত্বপূর্ণ:
এন্ট্রি ক্রাইটেরিয়া (Entry criteria) — টেস্টিং শুরু করার আগে যে শর্তগুলো পূরণ হতে হবে। উদাহরণ: কোড ফ্রিজ সম্পন্ন হয়েছে, স্টেজিং এনভায়রনমেন্ট রেডি ও স্থিতিশীল, প্রয়োজনীয় টেস্ট ডেটা লোড করা আছে। এই শর্তগুলো ছাড়া টেস্টিং শুরু করলে সময় নষ্ট হয় — একটি অস্থিতিশীল এনভায়রনমেন্টে টেস্ট চালিয়ে "বাগ" রিপোর্ট করা আসলে এনভায়রনমেন্ট সমস্যা হতে পারে, প্রকৃত কোড বাগ নয়।
এক্সিট ক্রাইটেরিয়া (Exit criteria) — টেস্টিং "শেষ" ঘোষণা করার শর্ত। উদাহরণ: পরিকল্পিত সব ক্রিটিক্যাল ও হাই-প্রায়োরিটি টেস্ট কেস পাস করেছে, কোনো ওপেন ব্লকার বা ক্রিটিক্যাল বাগ নেই, পরিকল্পিত কভারেজ লক্ষ্যমাত্রা (M6) অর্জিত হয়েছে। এক্সিট ক্রাইটেরিয়া ছাড়া টেস্টিং কখনো "শেষ" হয় না, বা উল্টো — সময় শেষ হওয়ায় হুট করে থামিয়ে দেওয়া হয়, রিস্কি এলাকা না টেস্ট করেই।
অনেক টিম "টেস্ট প্ল্যান" ও "টেস্ট স্ট্র্যাটেজি" শব্দ দুটো প্রায় সমার্থকভাবে ব্যবহার করে, তবে ধারণাগতভাবে স্ট্র্যাটেজি একটু বেশি উচ্চ-স্তরের ও দীর্ঘস্থায়ী (পুরো প্রজেক্ট/প্রোডাক্ট জুড়ে সাধারণ পদ্ধতি — কোন ধরনের টেস্টিং কে করবে, কোন টুল ব্যবহার হবে), আর প্ল্যান একটি নির্দিষ্ট রিলিজ/স্প্রিন্টের জন্য সেই স্ট্র্যাটেজির বাস্তব প্রয়োগ (এই রাউন্ডে ঠিক কী, কবে, কার দ্বারা)।
৪ · একটি টেস্ট প্ল্যান সম্পূর্ণ কি না — সত্যিকারের যাচাই
নিচের কোড সেলে একটি ছোট্ট ফাংশন আছে যা একটি ড্রাফট টেস্ট প্ল্যানকে (Python dict হিসেবে
উপস্থাপিত) উপরের ছয়টি প্রয়োজনীয় সেকশনের বিপরীতে যাচাই করে — কোনো সেকশন অনুপস্থিত থাকলে বা ফাঁকা থাকলে
তা ধরিয়ে দেয়।
REQUIRED_SECTIONS = [
"scope", "objectives", "resources",
"schedule", "risk_areas", "entry_criteria", "exit_criteria",
]
def validate_test_plan(plan: dict):
# অনুপস্থিত অথবা ফাঁকা (falsy) মানসহ যেকোনো সেকশনকে "missing" হিসেবে ধরা হচ্ছে
missing = [s for s in REQUIRED_SECTIONS if s not in plan or not plan[s]]
is_complete = len(missing) == 0
return is_complete, missing
draft_plan = {
"scope": "লগইন ও চেকআউট মডিউল",
"objectives": "রিলিজের আগে ক্রিটিক্যাল বাগ শূন্যে নামানো",
"resources": "২ জন QA ইঞ্জিনিয়ার, ১ সপ্তাহ",
"schedule": "", # ভুলবশত ফাঁকা রয়ে গেছে
"risk_areas": ["পেমেন্ট গেটওয়ে ইন্টিগ্রেশন", "ডিসকাউন্ট কুপন লজিক"],
"entry_criteria": "কোড ফ্রিজ সম্পন্ন, স্টেজিং এনভায়রনমেন্ট রেডি",
# exit_criteria সেকশনটাই লেখা হয়নি
}
complete, missing = validate_test_plan(draft_plan)
print("ড্রাফট প্ল্যান সম্পূর্ণ?", complete)
print("অনুপস্থিত সেকশন:", missing)
# ঘাটতিগুলো পূরণ করে দেওয়া হলো
final_plan = dict(draft_plan)
final_plan["schedule"] = "৫ কর্মদিবস (সোম-শুক্র)"
final_plan["exit_criteria"] = "সকল ক্রিটিক্যাল/হাই-প্রায়োরিটি টেস্ট কেস পাস, কোনো ওপেন ব্লকার নেই"
complete2, missing2 = validate_test_plan(final_plan)
print("চূড়ান্ত প্ল্যান সম্পূর্ণ?", complete2)
print("অনুপস্থিত সেকশন:", missing2)
missing তালিকায় দুটো সেকশন আসে — schedule (কারণ এর
মান ফাঁকা স্ট্রিং "", যা Python-এ falsy) এবং exit_criteria (কারণ এটি
dict-এই নেই)। দ্বিতীয় যাচাইয়ে দুটোই পূরণ করার পর তালিকা খালি হয়ে যায় ও
is_complete সত্যি হয় — এটি একটি সরল কিন্তু সত্যিকারের "চেকলিস্ট" স্বয়ংক্রিয়করণ, ঠিক যেমন
বাস্তব টিমগুলো টেমপ্লেট বা টুলের মাধ্যমে করে।
একটি টেস্ট প্ল্যান টিমকে "কী, কেন, কারা, কখন, কতটা" প্রশ্নের স্পষ্ট উত্তর দেয় — বিশেষভাবে এন্ট্রি ও এক্সিট ক্রাইটেরিয়া ঠিক করে দেয় কখন শুরু করা নিরাপদ আর কখন থামা যায়। পরের পাঠে (L47) আমরা দেখব কীভাবে সেই প্ল্যানের ভেতরের প্রতিটি টেস্ট কেস স্পষ্টভাবে লেখা ও সংগঠিত করতে হয়।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ একটি টিম বলছে "আমরা এন্ট্রি ক্রাইটেরিয়া ছাড়াই টেস্টিং শুরু করে দিয়েছি, সময় বাঁচাতে" — এতে কী ঝুঁকি আছে?
এনভায়রনমেন্ট অস্থিতিশীল থাকলে বা টেস্ট ডেটা ঠিকমতো সেট না হলে, টেস্টাররা যে সমস্যাগুলো দেখবেন সেগুলো আসল কোড বাগ নাও হতে পারে — বরং এনভায়রনমেন্ট সমস্যা। এতে সময় নষ্ট হয় ভুল বাগ ডিবাগ করতে, প্রকৃত টেস্টিং পিছিয়ে যায়, এবং টেস্ট রেজাল্টের উপর আস্থা কমে যায়।
প্র ০২ এক্সিট ক্রাইটেরিয়া ছাড়া একটি টেস্টিং রাউন্ড কীভাবে শেষ হতে পারে, এবং কেন সেটা সমস্যাজনক?
স্পষ্ট এক্সিট ক্রাইটেরিয়া ছাড়া টেস্টিং সাধারণত শেষ হয় "সময় শেষ হয়ে গেছে, তাই থামছি" ভিত্তিতে — কোন এলাকা টেস্ট করা হলো, কোনটি হলো না তার কোনো নিয়মতান্ত্রিক হিসাব থাকে না। এতে সবচেয়ে ঝুঁকিপূর্ণ এলাকাই হয়তো টেস্ট না করে বাদ পড়ে যায়, নিছক দুর্ভাগ্যক্রমে সেটাই শেষে সারিতে ছিল বলে।
প্র ০৩
উপরের কোড সেলে validate_test_plan ফাংশনটি খালি স্ট্রিং ""-কে "অনুপস্থিত"
হিসেবে গণ্য করে — এটি কি সবসময় সঠিক আচরণ? কখন এটি ভুল সিদ্ধান্তে নিয়ে যেতে পারে?
বেশিরভাগ ক্ষেত্রে যুক্তিসঙ্গত, কারণ একটি ফাঁকা স্ট্রিং মানে কেউ সেকশনটা লেখা শুরুই করেননি। তবে যদি
কোনো সেকশনের বৈধ মান সত্যিই 0 বা একটি খালি তালিকা [] হতে পারত (যেমন
"risk_areas: কোনো পরিচিত রিস্ক নেই" ইচ্ছাকৃতভাবে খালি তালিকা দিয়ে বোঝানো), তাহলে not plan[s]
চেক ভুলভাবে সেটিকে "অনুপস্থিত" বলে ধরে ফেলবে — বাস্তব টুলে তাই প্রায়ই "কী আছে" (key present) আর
"ইচ্ছাকৃতভাবে খালি" এই দুটোকে আলাদাভাবে যাচাই করা প্রয়োজন হয়।
অনুশীলন
-
চিন্তা করুন: আপনার পরিচিত কোনো (কাল্পনিক বা বাস্তব) সফটওয়্যার প্রজেক্টের জন্য এন্ট্রি
ও এক্সিট ক্রাইটেরিয়ার একটি করে বাস্তবসম্মত উদাহরণ লিখুন।
উদাহরণ (একটি মোবাইল অ্যাপ রিলিজ): এন্ট্রি ক্রাইটেরিয়া — "বিল্ড সফলভাবে তৈরি হয়েছে ও টেস্ট ডিভাইসে ইনস্টল করা গেছে, স্মোক টেস্ট পাস করেছে"; এক্সিট ক্রাইটেরিয়া — "রিগ্রেশন স্যুটের ৯৫%+ পাস, কোনো P0/P1 বাগ ওপেন নেই।"
-
পরিবর্তন করুন: উপরের কোড সেলে
REQUIRED_SECTIONS-এ একটি নতুন সেকশন"stakeholders"যোগ করুন, কিন্তুdraft_plan-এ সেটি না দিয়ে Run চাপুন — আউটপুট কীভাবে পরিবর্তিত হয় দেখুন।দুটো যাচাইয়েই (প্রথম ও চূড়ান্ত প্ল্যান) এখন
missingতালিকায়"stakeholders"যুক্ত হয়ে যাবে, কারণ এটি কোনোdict-এই নেই — এমনকি "চূড়ান্ত" প্ল্যানেরis_complete-ও এখনFalseদেখাবে, যতক্ষণ না সেটিও যোগ করা হয়।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ টেস্ট ডিজাইন টেকনিক, ইউনিট টেস্টিং, টেস্ট ডাবলস, কভারেজ, অটোমেশন, পারফরম্যান্স ও সিকিউরিটি টেস্টিং, টেস্ট ম্যানেজমেন্ট ও CI/CD ইন্টিগ্রেশন — সব একসাথে।
- পরের পাঠ: টেস্ট কেস ডিজাইন ও ম্যানেজমেন্ট L47 একটি ভালো টেস্ট কেস কীভাবে লিখতে হয়, এবং সীমিত সময়ে কোনটা আগে চালাবেন তা স্কোর করে ঠিক করবেন।
- সব 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 — সব এক জায়গায়।