শিফট-লেফট টেস্টিং
এই পাঠে যা শিখবেন
- শিফট-লেফট টেস্টিং-এর সংজ্ঞা এবং এটি ঐতিহ্যবাহী "শেষে টেস্ট করা" পদ্ধতি থেকে কীভাবে আলাদা
- SDLC-এর কোন কোন ধাপে টেস্টিং-সম্পর্কিত কার্যক্রম যোগ করা যায়, ও প্রতিটির উদ্দেশ্য
- কেন শিফট-লেফট খরচ কমায় — M1/L03-এর ডিফেক্ট-কস্ট কার্ভের সাথে সরাসরি সম্পর্ক
- একটি ছোট গণনার মাধ্যমে দেখা যে শিফট-লেফট পদ্ধতিতে টেস্টিং কার্যক্রম গড়ে কতটা আগে ঘটে
১ · "শিফট-লেফট" মানে কী
একটি SDLC টাইমলাইনকে যদি বাঁ থেকে ডানে আঁকা হয় — রিকোয়ারমেন্ট → ডিজাইন → কোডিং → টেস্টিং → ডিপ্লয়মেন্ট — তাহলে ঐতিহ্যবাহী পদ্ধতিতে টেস্টিং-সম্পর্কিত কাজ প্রায় সবটাই টাইমলাইনের ডান দিকে, "টেস্টিং" নামের একটি আলাদা ফেজে জমা থাকে। শিফট-লেফট টেস্টিংShift-left Testingটেস্টিং-সম্পর্কিত কার্যক্রমকে SDLC টাইমলাইনে যতটা সম্ভব আগে ("বাঁ দিকে") সরিয়ে আনা, যাতে সমস্যাগুলো কোড লেখা শেষ হওয়ার অনেক আগেই ধরা পড়ে। মানে এই কার্যক্রমগুলোকে টাইমলাইনের বাঁ দিকে, অর্থাৎ আগের ধাপগুলোতে ছড়িয়ে দেওয়া — রিকোয়ারমেন্ট লেখার সময়ই সেগুলো রিভিউ করা, ডিজাইনের সময় ডিজাইন রিভিউ করা, আর কোডিং-এর সময়ই (কোডিং শেষ হওয়ার আগেই) টেস্ট লেখা শুরু করা।
২ · কোন কার্যক্রম কোথায় শিফট হয়
স্পেসিফিকেশন লেখার সময়ই টেস্টাররা প্রশ্ন তোলেন — অস্পষ্ট বা পরস্পরবিরোধী রিকোয়ারমেন্ট কোড লেখার আগেই ধরা পড়ে।
আর্কিটেকচার/ডিজাইন ডকুমেন্ট রিভিউ করে দেখা হয় কোন অংশ টেস্ট করা কঠিন হবে, বা কোথায় ফেইলিওর-মোড মিস হয়ে যাচ্ছে।
কোড লেখার আগেই টেস্ট লেখা — যাচাই কোডিং-এর সাথে সমান্তরালে চলে, আলাদা পরবর্তী ফেজ হিসেবে নয়।
প্রতিটি কমিটে স্বয়ংক্রিয়ভাবে লিন্টিং ও সিকিউরিটি স্ক্যান চলে — মানুষ চোখে দেখার আগেই যান্ত্রিক চেক শেষ হয়ে যায়।
M1/L03-এ দেখানো হয়েছে একটি নির্দিষ্ট ডিফেক্ট যত পরে ধরা পড়ে, ঠিক করার খরচ তত বেশি বেড়ে যায় (একটি সাধারণভাবে-উল্লেখিত ইলাস্ট্রেটিভ প্যাটার্ন, কোনো নির্ভুল সার্বজনীন পরিসংখ্যান নয়)। শিফট-লেফট টেস্টিং ঠিক এই কার্ভের সুবিধা নেয় — যত বেশি ডিফেক্ট রিকোয়ারমেন্ট/ডিজাইন/কোডিং ধাপেই ধরা পড়ে, তত কম ডিফেক্ট দামি "টেস্টিং" বা "প্রোডাকশন" ধাপ পর্যন্ত পৌঁছায়। M9/L40-এ একই যুক্তি সিকিউরিটি-নির্দিষ্ট প্রেক্ষাপটে (থ্রেট মডেলিং, CI-তে SAST, রিলিজের আগে DAST) প্রয়োগ করা হয়েছে।
৩ · "কতটা আগে?" — একটি সরল গণনা
নিচের কোড সেলে একই পাঁচটি QA-সম্পর্কিত কার্যক্রম দুটি মডেলে (ঐতিহ্যবাহী বনাম শিফট-লেফট) কোন SDLC ফেজে ঘটে তা ফেজ-ইনডেক্স (০=রিকোয়ারমেন্ট ... ৪=ডিপ্লয়মেন্ট) দিয়ে চিহ্নিত করে গড় ফেজ-ইনডেক্স বের করা হয়েছে — গড় যত কম, কার্যক্রমগুলো গড়ে তত আগে ঘটছে।
PHASES = ["রিকোয়ারমেন্ট", "ডিজাইন", "কোডিং", "টেস্টিং", "ডিপ্লয়মেন্ট"]
# ফেজ-ইনডেক্স: ０=রিকোয়ারমেন্ট, ১=ডিজাইন, ২=কোডিং, ৩=টেস্টিং, ৪=ডিপ্লয়মেন্ট
# একই পাঁচটি কার্যক্রম, দুটি মডেলে কোন ফেজে ঘটে তার ইনডেক্স
activities = [
# (কার্যক্রম, ঐতিহ্যবাহী ফেজ-ইনডেক্স, শিফট-লেফট ফেজ-ইনডেক্স)
("স্পেসিফিকেশন অস্পষ্টতা যাচাই", 3, 0), # আগে: টেস্টিং-এ ধরা পড়ে; শিফট-লেফট: রিকোয়ারমেন্ট রিভিউ-তেই
("আর্কিটেকচারের টেস্টেবিলিটি যাচাই", 3, 1), # আগে: টেস্টিং-এ; শিফট-লেফট: ডিজাইন রিভিউ-তে
("ইউনিট-লেভেল আচরণ যাচাই", 3, 2), # আগে: টেস্টিং-এ; শিফট-লেফট: কোডিং-এর সময় TDD দিয়ে
("কোড-স্টাইল/স্ট্যাটিক ভুল যাচাই", 3, 2), # আগে: টেস্টিং-এ; শিফট-লেফট: CI-তে প্রতি কমিটে (কোডিং-এর সাথে সমান্তরাল)
("রিগ্রেশন যাচাই", 3, 3), # দুই মডেলেই টেস্টিং ফেজে -- এটি সবসময়ই থেকে যায়, শিফট-লেফট এটিকে বাদ দেয় না
]
def average_phase_index(pick):
indices = [pick(row) for row in activities]
return sum(indices) / len(indices)
traditional_avg = average_phase_index(lambda row: row[1])
shift_left_avg = average_phase_index(lambda row: row[2])
print("কার্যক্রম-ভিত্তিক ফেজ-ইনডেক্স তুলনা:")
for name, trad_idx, sl_idx in activities:
print(f" {name:32s} ঐতিহ্যবাহী={PHASES[trad_idx]:12s} শিফট-লেফট={PHASES[sl_idx]}")
print(f"\nগড় ফেজ-ইনডেক্স -- ঐতিহ্যবাহী: {traditional_avg:.2f}")
print(f"গড় ফেজ-ইনডেক্স -- শিফট-লেফট: {shift_left_avg:.2f}")
assert shift_left_avg < traditional_avg, "শিফট-লেফট মডেলের গড় ফেজ-ইনডেক্স ঐতিহ্যবাহীর চেয়ে কম হওয়ার কথা"
print(f"\nযাচাই সফল: শিফট-লেফট মডেলে একই কার্যক্রমগুলো গড়ে {traditional_avg - shift_left_avg:.2f} ফেজ আগে ঘটছে।")শিফট-লেফট টেস্টিং টেস্টিংকে একটি "শেষে করা" আলাদা কাজ হিসেবে না দেখে, পুরো SDLC জুড়ে ছড়িয়ে থাকা একটি ধারাবাহিক অভ্যাস হিসেবে দেখে। রিকোয়ারমেন্ট রিভিউ, ডিজাইন রিভিউ, TDD (M12/L52), আর CI-তে স্ট্যাটিক অ্যানালাইসিস (M12/L54) — প্রতিটিই M1/L03-এর খরচ-কার্ভের সুবিধা নিয়ে ডিফেক্টকে যত সম্ভব আগে ধরার চেষ্টা করে, আর M9/L40 দেখায় ঠিক এই একই নীতি সিকিউরিটির জন্যও সমান প্রযোজ্য।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ শিফট-লেফট টেস্টিং কি পরবর্তী ধাপের (যেমন সিস্টেম টেস্টিং, M5/L21) টেস্টিং সম্পূর্ণ বাদ দিতে বলে?
না। উপরের কোড সেলে দেখা গেছে "রিগ্রেশন যাচাই"-এর মতো কিছু কার্যক্রম দুই মডেলেই টেস্টিং ফেজে থেকে যায়। শিফট-লেফট মানে টেস্টিং ফেজ বাদ দেওয়া নয় — বরং অতিরিক্তভাবে আগের ধাপগুলোতেও যাচাই যোগ করা, যাতে টেস্টিং ফেজে পৌঁছানোর আগেই যতটা সম্ভব বেশি ডিফেক্ট ধরা পড়ে যায়। সিস্টেম/E2E টেস্টিং (M5/L21) এখনও প্রয়োজন, কারণ পুরো সিস্টেম একসাথে কাজ করছে কি না তা আগে ধাপে যাচাই করা যায় না।
প্র ০২ একটি টিম বলছে, "আমরা তো CI-তে unit test চালাই, তাহলে আমরা কি ইতিমধ্যেই শিফট-লেফট করছি?" — এই দাবি কতটা সম্পূর্ণ?
আংশিক সত্যি — CI-তে unit test চালানো শিফট-লেফটের একটি গুরুত্বপূর্ণ অংশ (কোডিং-এর গা ঘেঁষে যাচাই)। কিন্তু উপরের ডায়াগ্রামে দেখানো "পরে" মডেলটি তার চেয়েও বিস্তৃত — রিকোয়ারমেন্ট রিভিউ ও ডিজাইন রিভিউয়ের মতো কোডিং-এরও আগের ধাপগুলো এতে অন্তর্ভুক্ত। শুধু CI-তে টেস্ট চালানো শিফট-লেফটের একটি অংশ মাত্র, সম্পূর্ণ চিত্র নয়।
প্র ০৩ উপরের কোড সেলে "কোড-স্টাইল/স্ট্যাটিক ভুল যাচাই" আর "ইউনিট-লেভেল আচরণ যাচাই" — দুটোই শিফট-লেফট মডেলে ফেজ-ইনডেক্স ২ (কোডিং) পেয়েছে, কিন্তু ঐতিহ্যবাহী মডেলে দুটোই ৩ (টেস্টিং)। কেন?
ঐতিহ্যবাহী মডেলে ধরে নেওয়া হয়েছে কোনো ধরনের যান্ত্রিক বা আচরণগত যাচাই কোডিং শেষ না হওয়া পর্যন্ত শুরু হয় না — সবকিছু একসাথে "টেস্টিং" ফেজে জমা হয়। শিফট-লেফট মডেলে এই দুটো কার্যক্রম কোডিং-এর সাথে সমান্তরালে ঘটে — TDD-তে টেস্ট কোডের সাথেই লেখা হয় (M12/L52), আর প্রতিটি কমিটে CI-তে স্ট্যাটিক চেক চলে (M12/L54) — তাই দুটোরই ফেজ-ইনডেক্স কোডিং-এ নেমে আসে, আলাদা পরবর্তী ফেজে অপেক্ষা করতে হয় না।
অনুশীলন
-
চিন্তা করুন: আপনার পরিচিত কোনো প্রজেক্টে (কলেজ প্রজেক্ট বা কাজের প্রজেক্ট) টেস্টিং
ঠিক কোন ধাপে হয়েছিল — শুরুতে, নাকি শুধু শেষে? সেটি যদি সম্পূর্ণ শিফট-লেফট হতো তাহলে কোন কার্যক্রমগুলো
আগে সরানো যেত?
এই প্রশ্নের কোনো একক "সঠিক" উত্তর নেই — লক্ষ্য হলো নিজের অভিজ্ঞতার সাথে উপরের "আগে/পরে" টাইমলাইন ডায়াগ্রামটি মিলিয়ে দেখা। সাধারণ প্যাটার্ন: বেশিরভাগ ছাত্র/জুনিয়র প্রজেক্টে টেস্টিং (থাকলে) কোড সম্পূর্ণ হওয়ার পরই শুরু হয় — রিকোয়ারমেন্ট বা ডিজাইন রিভিউয়ের সময় কোনো টেস্টিং চিন্তা থাকে না, যা এই পাঠের "আগে" মডেলের সাথে মেলে।
-
পরীক্ষা করুন: উপরের কোড সেলে
activitiesলিস্টে একটি ষষ্ঠ এন্ট্রি যোগ করুন —("পারফরম্যান্স যাচাই", 3, 3)— এবং Run চেপে দেখুন গড় ফেজ-ইনডেক্স দুটোই (ঐতিহ্যবাহী ও শিফট-লেফট) কীভাবে পরিবর্তিত হয়।দুটো গড়ই সামান্য বেড়ে যাবে (তালিকার একটি নতুন এন্ট্রি দুই মডেলেই ইনডেক্স ৩ যোগ করছে, যা দুটো গড় গণনার গড়কেই উপরের দিকে টানবে) — কিন্তু
shift_left_avgএখনওtraditional_avg-এর চেয়ে কম থাকবে, কারণ পারফরম্যান্স টেস্টিং বাস্তবেও সাধারণত সম্পূর্ণ কোড থাকা পর্যন্ত অপেক্ষা করতে হয় — এটি শিফট-লেফট করা কঠিন এক ধরনের কার্যক্রমের একটি বাস্তবসম্মত উদাহরণ।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পরবর্তী পাঠ: টেস্ট-ড্রিভেন ডেভেলপমেন্ট (TDD) পাঠ ৫২ শিফট-লেফটের সবচেয়ে বাস্তব প্রয়োগ — কোড লেখার আগেই টেস্ট লেখা, একটি সত্যিকারের red-green-refactor ওয়াকথ্রুসহ।
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ টেস্ট ডিজাইন টেকনিক, ইউনিট টেস্টিং, টেস্ট ডাবলস, ইন্টিগ্রেশন টেস্টিং, কভারেজ, অটোমেশন, পারফরম্যান্স ও সিকিউরিটি টেস্টিং, অ্যাডভান্সড টেকনিক ও CI/CD ইন্টিগ্রেশন।
- Software Engineering Principles & Git কোর্স সহোদর কোর্স SDLC মডেল ও সাধারণ ইঞ্জিনিয়ারিং প্রিন্সিপলের ভিত্তি সেই কোর্সেই তৈরি হয়েছে — এই পাঠ সেই টাইমলাইনের উপর টেস্টিং কীভাবে বসে তা দেখায়।