Claude Code সহ বাগ ট্রায়েজ: দ্রুত সমাধানের জন্য একটি ব্যবহারিক লুপ

What bug triage is and why the loop matters

বাগগুলো অনিয়মিত মনে হয় যখন প্রতিটি রিপোর্টই একটি একক রহস্যে পরিণত হয়। আপনি কোডে চিটকানো করেন, কয়েকটি ধারণা পরীক্ষা করেন, এবং আশা করেন সমস্যা চলে যাবে। কখনও কখনও চলে যায়, কিন্তু আপনি খুব বেশি কিছু শিখেন না, এবং একই সমস্যা আবার ভিন্ন আকারে ফিরে আসে।

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

এই কারণেই লুপটি গুরুত্বপূর্ণ: পুনরুত্পাদন (reproduce), ছোট করা (minimize), প্রমাণসমেত সম্ভাব্য কারণ শনাক্ত করা, রিগ্রেশন টেস্ট যোগ করা, সংকীর্ণ ফিক্স ইমপ্লিমেন্ট করা, এবং যাচাই করা। প্রতিটি ধাপ একটি নির্দিষ্ট ধরনের আন্দাজ সরিয়ে দেয়। ধাপগুলো বাদ দিলে পরে বড় ফিক্স, পার্শ্বপ্রতিক্রিয়া, বা এমন “ফিক্স” পেতে পারেন যা আসলে ঠিক হয়নি।

এখানে একটি বাস্তবসম্মত উদাহরণ। একজন ব্যবহারকারী বলে: “Save বোতাম কখনও কখনও কাজ করে না।” লুপ না থাকলে আপনি UI কোড ব্রাউজ করে টাইমিং, স্টেট, বা নেটওয়ার্ক কল পরিবর্তন করতে পারেন। লুপের সঙ্গে, আপনি প্রথমে “কখনও কখনও”কে নির্দিষ্ট শর্তে “প্রতি বার” করতে করেন, যেমন: “শিরোনাম সম্পাদনা করার পরে দ্রুত ট্যাব বদলে দিলে, Save অক্ষমই থাকে।” সেই এক বাক্যই ইতিমধ্যেই অগ্রগতি।

Claude Code চিন্তার অংশকে দ্রুত করতে পারে: রিপোর্টগুলোকে নিখুঁত অনুমানগুলোতে পরিণত করা, কোথায় দেখবেন তা পরামর্শ করা, এবং একটি ন্যূনতম টেস্ট প্রস্তাব করা যা ফেল করা উচিত। এটি কোড, লোগ, এবং সাম্প্রতিক ডিফ স্ক্যান করে দ্রুত যুক্তিসঙ্গত ব্যাখ্যা তৈরিতেও বিশেষভাবে সহায়ক।

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

ফলাফল হবে একটি ছোট, নিরাপদ ফিক্স যা আপনি ব্যাখ্যা করতে পারবেন, রক্ষা করতে পারবেন, এবং রিগ্রেশনে আটকাতে পারবেন।

Set up the triage workspace (before touching code)

ভাল ফিক্সের শুরু হয় একটি পরিষ্কার ওয়ার্কস্পেস এবং একটি একক, পরিষ্কার সমস্যা বিবৃতির সঙ্গে। Claude-কে কিছু জিজ্ঞাসা করার আগে একটি রিপোর্ট বেছে নিন এবং এটিকে এভাবে পুনরায় লিখুন:

“যখন আমি X করি, আমি Y আশা করি, কিন্তু আমি Z পাই।”

আপনি যদি সেই বাক্যটি লিখতে না পারেন, তাহলে আপনার কাছে এখনও বাগ নেই—আপনার কাছে একটি রহস্য আছে।

শুরুতে মৌলিক বিষয়গুলো সংগ্রহ করুন যাতে বারবার ফিরে যেতে না হয়। এই বিবরণগুলোই পরামর্শগুলোকে অস্পষ্ট হওয়ার বদলে পরীক্ষাযোগ্য করে তোলে: অ্যাপ সংস্করণ বা কমিট (এবং এটা লোকাল, স্টেজিং, না প্রোডাকশনে), পরিবেশ বিবরণ (OS, ব্রাউজার/ডিভাইস, ফিচার ফ্ল্যাগ, অঞ্চল), সঠিক ইনপুট (ফর্ম ফিল্ড, API পে-লোড, ব্যবহারকারীর ক্রিয়া), কে দেখে (সবাই, একটি রোল, একটি অ্যাকাউন্ট/টেন্যান্ট), এবং “প্রত্যাশিত” কী অর্থ তাও (কপিরাইট, UI স্টেট, স্ট্যাটাস কোড, ব্যবসায়িক নিয়ম)।

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

উদাহরণ: একটি Koder.ai-জেনারেটেড React অ্যাপ “Payment succeeded” দেখায় কিন্তু অর্ডার “Pending” থাকে। ব্যবহারকারীর রোল, সঠিক অর্ডার আইডি, API রেসপন্স বডি, এবং সেই রিকোয়েস্ট আইডির সার্ভার লগ লাইনগুলো নোট করুন। এখন Claude-কে এক ফ্লোতে ফোকাস করতে বলাই যায়, ঝোঁক ছাড়া।

শেষে, একটি স্টপিং রুল নির্ধারণ করুন। কোড করা শুরু করার আগে কীকে ফিক্স গ্রহণযোগ্য হবে তা ঠিক করুন: একটি নির্দিষ্ট টেস্ট পাস করা, একটি UI স্টেট পরিবর্তন, লগে একটি এরর না দেখা, প্লাস একটি ছোট ভ্যালিডেশন চেকলিস্ট যা আপনি প্রতিবার চালাবেন। এটা আপনাকে উপসর্গ “ফিক্স” করে নতুন বাগ পাঠানোর থেকে বাঁচায়।

Turn the bug report into a precise question for Claude

একটি অব্যবস্থাপক রিপোর্ট সাধারণত তথ্য, অনুমান, এবং হতাশা মিশিয়ে দেয়। সাহায্য চাওয়ার আগে এটিকে একটি পরিষ্কার প্রশ্নে রূপান্তর করুন যাতে Claude প্রমাণসহ উত্তর দিতে পারে।

একটি বাক্য সারসংক্ষেপ দিয়ে শুরু করুন যা ফিচার এবং ব্যর্থতাকে নামকরণ করে। ভাল উদাহরণ: “Saving a draft sometimes deletes the title on mobile.” খারাপ উদাহরণ: “Drafts are broken.” সেই বাক্যটিই পুরো ট্রায়েজ থ্রেডের অ্যাংকর হবে।

তারপর আলাদা করে রাখুন আপনি যা দেখেছেন এবং আপনি কী প্রত্যাশা করেছিলেন। বিরক্তিকরভাবে নির্দিষ্ট থাকুন: আপনি কোন বোতামটি ক্লিক করেছেন, স্ক্রিনে কী বার্তা ছিল, কোন লোগ লাইন, টাইমস্ট্যাম্প, ডিভাইস, ব্রাউজার, ব্রাঞ্চ, কমিট। যদি এসব না থাকে, তা স্পষ্টভাবে বলুন।

একটি সহজ স্ট্রাকচার যেটি আপনি পেস্ট করতে পারেন:

• Summary (one sentence)
• Observed behavior (what happened, including any error text)
• Expected behavior (what should happen)
• Repro steps (numbered, smallest set you know)
• Environment (app version, device, OS, browser, config flags)

যদি ডিটেইলস না থাকে, সেগুলো হ্যাঁ/না প্রশ্ন আকারে চেয়ে নিন যাতে লোকরা দ্রুত উত্তর দিতে পারে: এটা কি fresh account-এও হয়? শুধু মোবাইলে? রিফ্রেশ করার পরই কি শুধুমাত্র হয়? শেষ রিলিজের পর কি শুরু হয়েছে? ইনকগনিটো-তেই কি রিপ্রো করেন?

Claude-কে “রিপোর্ট ক্লিনার” হিসেবেও ব্যবহার করা যায়। মূল রিপোর্ট (স্ক্রিনশট থেকে কপি করা টেক্সট, লগ, চ্যাট স্নিপেটসহ) পেস্ট করে বলুন:

“Rewrite this as a structured checklist. Flag contradictions. List the top 5 missing facts as yes/no questions. Do not guess causes yet.”

যদি একজন টীমমেট বলে “It fails randomly,” তাকে টেস্টেবল কিছুতে ঠেলুন: “Fails 2/10 times on iPhone 14, iOS 17.2, when tapping Save twice quickly.” এখন আপনি ইচ্ছাকৃতভাবে রিপ্রো করতে পারবেন।

Step 1 - Reproduce the bug reliably

আপনি যদি বাগটি অন-ডিমান্ডে ঘটাতে না পারেন, পরবর্তী প্রতিটি ধাপই আন্দাজভিত্তিক।

ছোট পরিবেশে এটি পুনরুত্পাদন করতে শুরু করুন যা এখনও সমস্যাটি দেখাতে পারে: একটি লোকাল ডেভ বিল্ড, একটি মিনিমাল ব্রাঞ্চ, একটি ক্ষুদ্র ডেটাসেট, এবং যতটা সম্ভব কম সার্ভিস চালু।

এক্সাক্ট স্টেপগুলো লিখে রাখুন যাতে অন্য কেউ প্রশ্ন ছাড়াই ফলো করতে পারে। কপি-পেস্ট-বন্ধুভাবেই রাখুন: কমান্ড, আইডি, এবং স্যাম্পল পে-লোডগুলো ঠিক যেমন ব্যবহার করা হয় তা অন্তর্ভুক্ত করুন।

একটি সাধারণ ক্যাপচার টেম্পলেট:

• Setup: branch/commit, config flags, database state (empty, seeded, production copy)
• Steps: numbered actions with exact inputs
• Expected vs actual: what you thought would happen, what happened instead
• Evidence: error text, screenshots, timestamps, request IDs
• Frequency: always, sometimes, first run only, only after a refresh

ফ্রিকোয়েন্সি আপনার কৌশল বদলে দেয়। “Always” বাগ দ্রুত ইটের জন্য ভালো। “Sometimes” বাগগুলো প্রায়ই টাইমিং, ক্যাশ, রেস কন্ডিশন, বা লুকানো স্টেটে ইঙ্গিত করে।

একবার রিপ্রো নোট থাকলে, Claude-কে ছোট প্রোবস জিজ্ঞাসা করুন যা অ্যাপ পুনলিখন না করেই অনিশ্চয়তা কমায়। ভালো প্রোবগুলো ছোট: ফেল হওয়ার সীমানার কাছে একটি টার্গেটেড লოგ লাইন (ইনপুট, আউটপুট, কী স্টেট), একটি একক কম্পোনেন্টের জন্য ডিবাগ ফ্ল্যাগ, ডিটারমিনিস্টিক আচরণ জোর করার উপায় (ফিক্সড র্যান্ডম সীড, ফিক্সড টাইম, একক ওয়ার্কার), একটি ছোট সিড ডেটা সেট যা ইস্যুটি ট্রিগার করে, বা একটি একক ফেলিং রিকোয়েস্ট/রেসপন্স পেয়ার রেপ্লে করার উপায়।

উদাহরণ: একটি সাইনআপ ফ্লো “sometimes” ফেল করে। Claude প্রস্তাব করতে পারে যে জেনারেটেড ইউজার আইডি, ইমেল নর্ম্যালাইজেশন রেজাল্ট, এবং ইউনিক কনস্ট্রেনট এরর ডিটেইল লগ করুন, তারপর একই পে-লোড 10 বার পুনরায় চালান। যদি ফেল প্রথম রানেই ডিপ্লয় এর পরে হয়, তাহলে মাইগ্রেশন, ক্যাশ ওরমআপ, বা মিসিং সিড ডেটা চেক করার শক্ত ইঙ্গিত পেতে পারেন।

Step 2 - Minimize to a small, repeatable test case

ভালো রিপ্রো ব্যবহারযোগ্য। একটি মিনিমাল রিপ্রো শক্তিশালী। এটি বাগ বুঝতে দ্রুত করে, ডিবাগ করা সহজ করে, এবং “অজান্তে ফিক্স” হওয়ার সম্ভাবনা কমায়।

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

তারপর ডেটা ছোট করুন। যদি বাগটি একটি বড় পে-লোডে লাগে, তাহলে সবচেয়ে ছোট পে-লোড খুঁজে দেখুন যা এখনও ভাঙে। যদি 500 আইটেমের তালিকা লাগে, দেখুন 5 কি ফেল করে, তারপর 2, তারপর 1। ফিল্ডগুলো এক করে এক করে সরান। লক্ষ্য হলো যত কম চলমান অংশ ব্যবহৃত হচ্ছে তত কম।

প্র্যাকটিক্যাল পদ্ধতি হল “অর্ধেক কেটে পুনরায় পরীক্ষা”:

• স্টেপগুলো অর্ধেক করুন এবং দেখুন বাগটি এখনও ঘটে কি না।
• যদি ঘটে, বাকি অংশে রেখে আবার কেটে যান।
• যদি না ঘটে, যেটা নেওয়া হয়েছে তার অর্ধেক ফিরিয়ে নিয়ে আবার কেটে দেখুন।
• ততক্ষণ পুনরাবৃত্তি করুন যতক্ষণ না কিছুই বাদ দিলে বাগ হারায়।

উদাহরণ: একটি চেকআউট পেজ “sometimes” ক্র্যাশ করে কুপন প্রয়োগ করার সময়। আপনি আবিষ্কার করেন এটি কেবল তখনই ফেল করে যখন কার্টে অন্তত একটি ডিসকাউন্টেড আইটেম থাকে, কুপনটি লোয়ারকেসে থাকে, এবং শিপিং “pickup” সেট আছে। আপনার মিনিমাল কেস হবে: এক ডিসকাউন্টেড আইটেম, এক লোয়ারকেস কুপন, একটি পিকআপ অপশন।

একবার মিনিমাল কেস স্পষ্ট হলে, Claude-কে একটি ছোট রিপ্রো স্ক্যাফল্ড তৈরি করতে বলুন: একটি ন্যূনতম টেস্ট যা ব্যর্থ ফাংশন কল করে সবচেয়ে ছোট ইনপুট নিয়ে, একটি সংক্ষিপ্ত স্ক্রিপ্ট যা একটি এন্ডপয়েন্টে হিট করে রিডিউসড পে-লোড দিয়ে, অথবা একটি ছোট UI টেস্ট যা একটি রুট ভিজিট করে এবং একটি অ্যাকশন করে।

Step 3 - Identify likely root causes (with evidence)

একবার আপনি সমস্যা পুনরুত্পাদন করতে পারেন এবং একটি ছোট টেস্ট কেস পেয়েছেন, অানুমান ছেড়ে দাঁড়ান। লক্ষ্য হলো সম্ভাব্য কারণগুলোর একটি সংক্ষিপ্ত তালিকা করা, তারপর প্রতিটি প্রমাণ বা প্রত্যাখ্যান করা।

একটি দরকারী নিয়ম হলো তিনটি হাইপোথিসিসে সীমাবদ্ধ থাকা। এর বেশি হলে সম্ভবত আপনার টেস্ট কেস এখনও বড় বা পর্যবেক্ষণগুলো অস্পষ্ট।

Map symptoms to components

আপনি যা দেখেছেন সেটিকে কোন কম্পোনেন্টে হতে পারে তা অনুবাদ করুন। একটি UI লক্ষণ মানেই UI বাগ নয়।

উদাহরণ: একটি React পেজ “Saved” টোস্ট দেখায়, কিন্তু রেকর্ড পরে মিসিং। সেটি নির্দেশ করতে পারে (1) UI স্টেট, (2) API আচরণ, বা (3) ডাটাবেস রাইট পাথ।

Build evidence for each hypothesis

Claude-কে বলুন সম্ভাব্য ফেইলিয়ার মোডগুলো সাধারণ ভাষায় ব্যাখ্যা করতে, তারপর প্রতিটি যাচাই করার জন্য কোন প্রমাণ লাগবে তা জিজ্ঞাসা করুন। লক্ষ্য হলো “হয়তো” থেকে “এইটা চেক করুন” এ ফেরা।

তিনটি সাধারণ হাইপোথিসিস এবং প্রতিটির প্রমাণ:

• UI/state mismatch: ক্লায়েন্ট সার্ভার কনফার্মেশনের আগে লক্যাল স্টেট আপডেট করে। প্রমাণ: অ্যাকশনের আগে ও পরে স্টেট স্ন্যাপশট এবং আসল API রেসপন্স তুলনা করুন।
• API edge case: হ্যান্ডলার 200 ফেরত দেয় কিন্তু কাজটি চুপচাপ বাদ দেয় (ভ্যালিডেশন, ID পার্সিং, ফিচার ফ্ল্যাগ)। প্রমাণ: করেলেশন আইডিসহ রিকোয়েস্ট/রেসপন্স লোগ যোগ করুন এবং যাচাই করুন যে হ্যান্ডলার রাইট কল পর্যন্ত পৌঁছেছে কি না।
• Database or timing issue: একটি ট্রানজ্যাকশন ব্যাক করে দেয়, কনফ্লিক্ট এরর ঘটে, বা “read after write” ক্যাশ/রেপ্লিকা থেকে পরিবেশন হচ্ছে। প্রমাণ: DB কুয়েরি, rows affected, এরর কোড দেখুন; ট্রানজ্যাকশন বাউন্ডারি ও রিট্রাই আচরণ লগ করুন।

আপনার নোটগুলো টাইট রাখুন: লক্ষণ, হাইপোথিসিস, প্রমাণ, ফলাফল। যখন একটি হাইপোথিসিস ফ্যাক্টের সঙ্গে মেলে, তখন আপনি রিগ্রেশন টেস্ট লক ইন করে শুধুমাত্র প্রয়োজনীয় জিনিস ঠিক করতে পারবেন।

Step 4 - Add a regression test that fails for the right reason

একটি ভাল রিগ্রেশন টেস্ট আপনার সেফটি বেল্ট। এটি প্রমাণ করে বাগটি আছে, এবং যখন আপনি সত্যিই ঠিক করেছেন তবেই বলে।

শুরু করুন সবচেয়ে ছোট টেস্ট থেকে যা বাস্তব ব্যর্থতার সাথে মেলে। বাগটি একাধিক অংশের কাজ করার সময়ই হয়, তাহলে ইউনিট টেস্ট মিস করতে পারে।

Pick the test level that matches the bug

একটি ফাংশন ভুল ফলাফল দিলে ইউনিট টেস্ট ব্যবহার করুন। boundary সমস্যার জন্য (API হ্যান্ডলার + DB, বা UI + স্টেট) ইন্টিগ্রেশন টেস্ট ব্যবহার করুন। শুধুমাত্র যদি পুরো ইউজার ফ্লো দরকার হয় তবেই end-to-end ব্যবহার করুন।

Claude-কে কিছু লিখতে বলার আগে মিনিমাইজড কেসকে একটি কঠোর প্রত্যাশিত আচরণ হিসেবে পুনরায় লিখুন। উদাহরণ: “When the user saves an empty title, the API must return 400 with message ‘title required’.” এখন টেস্টের একটি স্পষ্ট টার্গেট আছে।

তারপর Claude-কে প্রথমে একটি ফেলিং টেস্ট ড্রাফট করতে বলুন। সেটআপ ন্যূনতম রাখুন এবং কেবল সেই ডেটা কপি করুন যা বাগ ট্রিগার করে। টেস্টের নামটি ব্যবহারকারীর অভিজ্ঞতার উপর ভিত্তি করে রাখুন, না যে অন্দরিভাবে কোন ফাংশন।

Verify the draft (don’t trust it blindly)

দ্রাফট টেস্টটি নিজে একবার দেখুন:

• নিশ্চিত করুন এটি বর্তমান কোডে উদ্দেশ্যপ্রণোদিত কারণেই ফেল করে (কোনো মিসিং ফিক্সচার বা ভুল ইম্পোর্ট না)\
• Assertions নির্দিষ্ট কিনা দেখুন (ঠিক স্ট্যাটাস কোড, মেসেজ, রেন্ডার্ড টেক্সট)\
• নিশ্চিত করুন টেস্ট একটিই বাগ কভার করে, নানা আচরণ নয়\
• নামটি ইউজার-ফোকাসড কিনা দেখুন, উদাহরণ: “rejects empty title on save” rather than “handles validation”

একবার টেস্টটি সঠিক কারণে ফেল করলে, আপনি আত্মবিশ্বাসের সাথে সংকীর্ণ ফিক্স ইমপ্লিমেন্ট করতে প্রস্তুত।

Step 5 - Implement a narrow fix

একবার আপনার কাছে একটি ছোট রিপ্রো এবং একটি ফেলিং রিগ্রেশন টেস্ট গেলে, “ক্লিনআপ” করার বাসনা ঠেকিয়ে রাখুন। লক্ষ্য হলো সবচেয়ে ছোট পরিবর্তন করা যা টেস্টটি সঠিকভাবে পাশ করায়।

একটি ভাল সংকীর্ণ ফিক্স সবচেয়ে ছোট সারফেস এরিয়া বদলে দেয়। যদি ব্যর্থতা এক ফাংশনে হয়, সেই ফাংশনই ঠিক করুন, পুরো মডিউল নয়। যদি একটি বাউন্ডারি চেক মিসিং থাকে, বাউন্ডারিতে চেক যোগ করুন, পুরো কল চেইন জুড়ে নয়।

Claude সাহায্য করলে দুইটি ফিক্স অপশন জিজ্ঞাসা করুন, তারপর স্কোপ ও ঝুঁকি তুলনা করুন। উদাহরণ: একটি React ফর্ম ফিল্ড খালি থাকলে ক্র্যাশ করলে:

• অপশন A: সাবমিট হ্যান্ডলারেই গার্ড যোগ করুন এবং একটি এরর দেখান।
• অপশন B: স্টেট হ্যান্ডলিং রিফ্যাক্টর করুন যাতে ফিল্ড কখনও খালি না হয়।

অপশন A সাধারণত ট্রায়াজ পছন্দ: ছোট, রিভিউ করা সহজ, এবং অন্য কিছু ভেঙে দেওয়ার ঝুঁকি কম।

ফিক্স সংকীর্ণ রাখার নিয়মগুলো: যত কম ফাইল স্পর্শ করবেন, তত চমৎকার; লোকাল ফিক্সকে অগ্রাধিকার দিন রিফ্যাক্টরের উপরে; খারাপ ভ্যালু যেখানে আসে সেখানে গার্ড/ভ্যালিডেশন দিন; এবং আচরণ পরিবর্তনটি স্পষ্ট রাখুন একটিবefore/after সহ। কারণ পরিষ্কার না হলে কেবল নোট হিসেবে মন্তব্য রাখুন।

কনক্রিট উদাহরণ: একটি Go API এন্ডপয়েন্ট অপশনাল কুয়েরি প্যারাম মিসিং হলে panic করে। সংকীর্ণ ফিক্স হল হ্যান্ডলার বাউন্ডারিতে খালি স্ট্রিং হ্যান্ডেল করা (ডিফল্ট দিয়ে পার্স করা, অথবা স্পষ্ট 400 রিটার্ন করা)। শেয়ার্ড পার্সিং ইউটিলিটিতে বদল আনবেন না যদি রিগ্রেশন টেস্ট প্রমাণ না করে বাগটা সেখানে।

পরিবর্তনের পরে ফেল করা টেস্ট এবং কাছাকাছি ১–২টি টেস্ট পুনরায় চালান। যদি আপনার ফিক্স অনেক অপ্রাসঙ্গিক টেস্ট আপডেটের দাবি করে, সেটা সংকেত যে পরিবর্তনটি বেশি বিস্তৃত।

Step 6 - Validate the fix with clear checks

ভ্যালিডেশন হল জায়গা যেখানে ছোট, সহজ-এড়ানোর মত সমস্যা ধরবেন: একটি ফিক্স যা একটি টেস্ট পাস করালেও পাশে কোনো পথ ভেঙে দিতে পারে, একটি এরর মেসেজ বদলে দিতে পারে, অথবা ধীর কুয়েরি যোগ করতে পারে।

প্রথমে রিগ্রেশন টেস্টটি আবার চালান। পাস করলে নিকটস্থ টেস্টগুলো চালান: একই ফাইল, একই মডিউল, এবং একই ইনপুট কভার করা যেকোনো টেস্ট। বাগগুলো প্রায়ই শেয়ার্ড হেল্পার, পার্সিং, বাউন্ডারি চেক, বা ক্যাশিং-এ লুকিয়ে থাকে, তাই সবচেয়ে সম্ভাব্য ব্যর্থতাগুলো কাছেই দেখা যায়।

তারপর মূল রিপোর্টের স্টেপগুলো ম্যানুয়ালি দ্রুত চেক করুন। সংক্ষিপ্ত ও নির্দিষ্ট থাকুন: একই পরিবেশ, একই ডেটা, একই ক্লিক বা API কলের অনুক্রম। রিপোর্ট যদি অস্পষ্ট হয়, আপনি যে নির্দিষ্ট সিনারিও দিয়ে রিপ্রো করেছিলেন সেটা টেস্ট করুন।

A simple validation checklist

• রিগ্রেশন টেস্ট পাস করেছে, প্লাস একই এলাকায় সম্পর্কিত টেস্টগুলো
• ম্যানুয়াল রিপ্রো স্টেপগুলো আর বাগ ট্রিগার করে না
• এরর হ্যান্ডলিং যুক্তিসঙ্গত (মেসেজ, স্ট্যাটাস কোড, রিট্রাই)
• এজ কেসগুলো ঠিক আছে (খালি ইনপুট, সর্বোচ্চ সাইজ, অস্বাভাবিক ক্যারেক্টার)
• স্পষ্ট পারফরম্যান্স ইস্যু নেই (অতিরিক্ত লুপ, অতিরিক্ত কল, ধীর কুয়েরি)

আপনি ফোকাস রাখতে চান তাহলে Claude-কে আপনার পরিবর্তন এবং ফেলিং সিনারিও শেয়ার করে একটি ছোট ভ্যালিডেশন প্ল্যান বলুন। সেরা প্ল্যানগুলো সংক্ষিপ্ত ও কার্যকর: 5–8টি চেক যা মিনিটের মধ্যে করা যায়, প্রতিটির জন্য একটুখানি পাস/ফেইল ক্রাইটেরিয়া।

শেষে, আপনি যা যাচাই করেছেন তা PR বা নোটে ক্যাপচার করুন: আপনি কোন টেস্টগুলো চালিয়েছেন, কোন ম্যানুয়াল স্টেপগুলো চেষ্টা করেছেন, এবং কোনো সীমাবদ্ধতা (উদাহরণ: “মোবাইল টেস্ট করা হয়নি”)। এটি ফিক্সটিকে বিশ্বাসযোগ্য করে তোলে এবং পরে সহজে রিভিউ করা যায়।

Common mistakes and traps (and how to avoid them)

সবচেয়ে দ্রুত সময় নষ্ট করার উপায় হল এমন একটি “ফিক্স” গ্রহণ করা যেটা আপনি ডিমান্ডে রিপ্রো করতে পারেন না। আপনি যদি স্থিরভাবে ফেল করাতে না পারেন, আপনি জানতেই পারবেন না আসলে কী উন্নত হয়েছে।

একটি বাস্তবসম্মত নিয়ম: রিপ্রোযোগ্য সেটআপ (ঠিক স্টেপ, ইনপুট, পরিবেশ, এবং কী “ভুল” দেখাচ্ছে) বর্ণনা না করা পর্যন্ত ফিক্স চাইবেন না। রিপোর্ট যদি অস্পষ্ট হয়, আপনার প্রথম কয়েক মিনিট সেটিকে একটি চেকলিস্টে পরিণত করতে ব্যয় করুন যাতে আপনি দু'বার চালিয়ে একই ফল পেতে পারেন।

Traps that slow you down

Fixing without a reproducible case. একটি মিনিমাল “প্রতি বার ফেল করে” স্ক্রিপ্ট বা স্টেপস দাবী করুন। যদি এটি কেবল “sometimes” হয়, তখন পর্যন্ত টাইমিং, ডেটা সাইজ, ফিচার ফ্ল্যাগ, এবং লোগ সংগ্রহ করুন যতক্ষণ না এটি র‍্যান্ডম না থাকে।

Minimizing too early. যদি আপনি মূল ব্যর্থতাকে নিশ্চিত না করে কেসটি ছোট করেন, তাহলে সিগন্যাল হারাতে পারেন। প্রথমে বেসলাইন রিপ্রো লক করুন, তারপর একে একে সঙ্কুচিত করুন।

Letting Claude guess. Claude সম্ভাব্য কারণ প্রস্তাব করতে পারে, কিন্তু আপনাকে এখনও প্রমাণ সংগ্রহ করতে হবে। 2–3টি হাইপোথিসিস এবং প্রতিটি নিশ্চিত/প্রত্যাখ্যান করার জন্য ঠিক কোন পর্যবেক্ষণ লাগবে তা জিজ্ঞাসা করুন (একটি লোগ লাইন, একটি ব্রেকপয়েন্ট, একটি কুয়েরি রেজাল্ট)।

Regression tests that pass for the wrong reason. একটি টেস্ট “পাস” করতে পারে কারণ এটি কখনও ফেলিং পথটিই হিট করে না। নিশ্চিত করুন এটি ফিক্সের আগে ফেল করে এবং প্রত্যাশিত মেসেজ বা assertion-এ ফেল করে।

Treating symptoms instead of the trigger. আপনি যদি একটি নাল চেক যোগ করেন কিন্তু আসল ইস্যু হল “এই ভ্যালু কখনওই null হওয়া উচিত নয়”, তাহলে আপনি গভীরতর বাগ ঢেকে দিচ্ছেন। খারাপ অবস্থা তৈরির শর্তকেই সম্ভব হলে ঠিক করা শ্রেয়।

A quick sanity check before you call it done

নতুন রিগ্রেশন টেস্ট এবং মূল রিপ্রো স্টেপগুলো আপনার পরিবর্তনের আগে ও পরে চালান। যদি একটি চেকআউট বাগ কেবল তখনই ঘটে যখন একটি প্রোমো কোড শিপিং পরিবর্তনের পরে প্রয়োগ করা হয়, সেই পুরো সিকোয়েন্সটাকেই আপনার “ট্রুথ” হিসেবে রাখুন, যদিও আপনার মিনিমাইজড টেস্ট ছোট।

যদি আপনার ভ্যালিডেশন নির্ভর করে “এখন এটা ভালো দেখাচ্ছে”–এর উপর, একটি স্পষ্ট চেক যোগ করুন (একটি লোগ, একটি মেট্রিক, বা একটি নির্দিষ্ট আউটপুট) যাতে পরবর্তী ব্যক্তি দ্রুত যাচাই করতে পারে।

A quick checklist, prompt templates, and next steps

সময় কম থাকলে, একটি ছোট, পুনরাবৃত্তি যোগ্য লুপ হিরোয়িক ডিবাগিংকে হারিয়ে দেয়।

One-page triage checklist

• Reproduce: একটি নির্ভরযোগ্য রিপ্রো পান এবং সঠিক ইনপুট, পরিবেশ, এবং প্রত্যাশিত বনাম প্রকৃত নোট করুন।
• Minimize: সবচেয়ে ছোট স্টেপ বা টেস্টে সংকুচিত করুন যা এখনও ফেল করে।
• Explain: 2–3টি সম্ভাব্য মূল কারণ এবং প্রতিটির প্রমাণ তালিকাভুক্ত করুন।
• Lock it in: একটি রিগ্রেশন টেস্ট যোগ করুন যা সঠিক কারণে ফেল করে।
• Fix + validate: সবচেয়ে সংকীর্ণ পরিবর্তন করুন, তারপর একটি সংক্ষিপ্ত ভ্যালিডেশন চেকলিস্ট চালান।

ফাইনাল ডিসিশন কয়েক লাইনে লিখে রাখুন যাতে পরবর্তী ব্যক্তি (প্রায়শই ভবিষ্যৎ আপনি) এটিকে বিশ্বাস করতে পারে। একটি ব্যবহারযোগ্য ফরম্যাট: “Root cause: X. Trigger: Y. Fix: Z. Why safe: W. What we did not change: Q.”

Prompt templates you can paste

• “Given this bug report and logs, ask me only the missing questions needed to reproduce it reliably.”
• “Help me minimize: propose a smaller test case and tell me what to remove first, one change at a time.”
• “Rank likely root causes and cite the exact files, functions, or conditions that support each claim.”
• “Write a regression test that fails only because of this bug. Explain why it fails for the right reason.”
• “Suggest the narrowest fix, plus a validation checklist (unit, integration, and manual checks) that proves we didn’t break nearby behavior.”

Next steps: যা সম্ভব অটোম্যাট করুন (একটি সেভড রিপ্রো স্ক্রিপ্ট, একটি স্ট্যান্ডার্ড টেস্ট কমান্ড, রুট-কারণ নোটের টেম্পলেট)।

যদি আপনি Koder.ai (koder.ai) দিয়ে অ্যাপ বানান, Planning Mode আপনাকে পরিবর্তনটি কোড স্পর্শ করার আগে আউটলাইন করতে সাহায্য করতে পারে, এবং স্ন্যাপশট/রোলব্যাক কঠিন রিপ্রো নিয়ে পরীক্ষা করা সহজ করে তোলে। একবার ফিক্স ভ্যালিডেট হলে, আপনি সোর্স কোড এক্সপোর্ট বা হোস্ট করে আপডেট করা অ্যাপ ডেপ্লয় করতে পারবেন, প্রয়োজনে কাস্টম ডোমেইনসহ।