আপনি লিখেননি এমন বাগ রিপোর্ট ডিবাগ করার জন্য একটি ব্যবহারিক ওয়ার্কফ্লো: কিভাবে ইস্যুগুলো পুনরুত্পাদন করবেন, UI/API/DB আলাদা করবেন, এবং একটি মিনিমাল, টেস্টেবল AI ফিক্স অনুরোধ করবেন।
আপনি যদি এমন একটি বাগ রিপোর্ট ডিবাগ করেন যা আপনি লিখেননি, তবে তা কঠিন হয়ে যায় কারণ আপনার কাছে মূল নির্মাতার মানসিক মানচিত্র নেই। আপনি জানেন না কোন অংশ দুর্বল, কোনটি "সাধারণ," বা কোন শর্টকাট নেওয়া হয়েছে। একটি ছোট লক্ষণ (একটি বোতাম, একটি টাইপো, একটি ধীর স্ক্রীন) এখনও গভীরতর সমস্যা থেকে আসতে পারে—API, ডাটাবেস, বা ব্যাকগ্রাউন্ড জব থেকে।
একটি কাজে লাগার মতো বাগ রিপোর্ট আপনাকে চারটি জিনিস দেয়:
অধিকাংশ রিপোর্ট শুধু শেষটিই দেয়: "সেভ হচ্ছে না," "ভাঙা আছে," "র্যানডম এরর।" যা মিস হচ্ছে সেটা হল সেই প্রসঙ্গ যা এটিকে পুনরাবৃত্তিযোগ্য করে তোলে: ইউজার রোল, নির্দিষ্ট রেকর্ড, পরিবেশ (প্রোড বনাম স্টেজিং), এবং এটি কি কোনো পরিবর্তনের পর শুরু হয়েছে কিনা।
লক্ষ্য হলো একটি অস্পষ্ট লক্ষণকে নির্ভরযোগ্য পুনরুত্পাদনে পরিণত করা। একবার আপনি এটি ডিমান্ডে ঘটাতে পারলে, তা আর রহস্যময় থাকে না—এটি পরীক্ষার একটি ধারাবাহিকতা।
আপনি যা তৎক্ষণাৎ নিয়ন্ত্রণ করতে পারেন:
"ডান" মানে হচ্ছে "আমি মনে করি ফিক্স করেছি" না। ডান হলো: আপনার রেপ্রো ধাপগুলো একটি ছোট পরিবর্তনের পরে পাস করে, এবং আপনি দ্রুত পার্শ্ববর্তী আচরণগুলো পুনরায় টেস্ট করেন যা আপনি প্রভাবিত করতে পারেন।
বহু জিনিস একই সময়ে বদলে ফেলার ফলে সময় দ্রুত নষ্ট হয়। আপনার শুরু পয়েন্ট ফ্রিজ করে রাখুন যাতে প্রতিটি টেস্ট ফলাফল অর্থপূর্ণ হয়।
একটি পরিবেশ বেছে নিন এবং সমস্যাটি পুনরুত্পাদিত না হওয়া পর্যন্ত সেখানে থাকুন। রিপোর্ট প্রোডাকশন থেকে এসেছে কিনা, আগে সেখানে যাচাই করুন। যদি সেটি ঝুঁকিপূর্ণ হয়, স্টেজিং ব্যবহার করুন। লোকালও ঠিক আছে যদি আপনি ডেটা এবং সেটিংস ঘনিষ্ঠভাবে মেলাতে পারেন।
তারপর কোন কোড আসলে চলছে তা পিন করুন: ভার্সন, বিল্ড তারিখ, এবং যে কোনো ফিচার ফ্ল্যাগ বা কনফিগ যা ফ্লোতে প্রভাব ফেলে। ছোট পার্থক্য (ডিসেবলড ইন্টিগ্রেশন, ভিন্ন API বেস URL, অনুপস্থিত ব্যাকগ্রাউন্ড জব) একটি বাস্তব বাগকে ভূত বানিয়ে দিতে পারে।
একটি পরিষ্কার, পুনরাবৃত্তিযোগ্য টেস্ট সেটআপ তৈরি করুন। নতুন একটি অ্যাকাউন্ট এবং পরিচিত ডেটা ব্যবহার করুন। সম্ভব হলে প্রতিটি প্রচেষ্টার আগে স্টেট রিসেট করুন (লগ আউট, ক্যাশ পরিষ্কার, একই রেকর্ড থেকে শুরু)।
আপনি যতক্ষণ যাচ্ছেন, ধরে নেওয়া অনুমানগুলো লিখে রাখুন। এটা ব্যস্ততার কাজ নয়; পরে নিজের সঙ্গে বিতর্ক থামায়।
একটি বেসলাইন নোট টেমপ্লেট:
যদি রেপ্রো ব্যর্থ হয়, এই নোটগুলো বলে দেবে পরবর্তী কোন কন্ট্রাস্ট পরিবর্তন করবেন—একেকটি নাবল একবারে।
দ্রুততম জয় হলো অস্পষ্ট অভিযোগকে এমন কিছুতে পরিণত করা যা আপনি স্ক্রিপ্টের মত চালাতে পারেন।
রিপোর্টকে ছোট একটি ইউজার স্টোরিতে লিখে শুরু করুন: কে কি করছে, কোথায়, এবং তারা কী আশা করছিল। তারপর দেখা ফলাফলটা যোগ করুন।
উদাহরণ রিরাইট:
"একজন বিলিং অ্যাডমিন হিসেবে, যখন আমি একটি ইনভয়েসের স্ট্যাটাসকে Paid-এ বদল করে ইনভয়েস পেজে Save ক্লিক করি, স্ট্যাটাসটি স্থায়ী হওয়া উচিত। পরিবর্তে পেজ অপরিবর্তিত থাকে এবং রিফ্রেশের পরে স্ট্যাটাস অপরিবর্তিত থাকে।"
পরবর্তীতে, সেই শর্তগুলো ধরুন যা রিপোর্টকে সত্যি করে তোলে। বাগ প্রায়ই একটি অনুপস্থিত বিবরণে নির্ভর করে: রোল, রেকর্ড স্টেট, লোকেল, বা পরিবেশ।
কী ইনপুট আগে লিখে রাখবেন:
মূল আচরণটি যখন এখনও আছে তখন প্রমাণ সংগ্রহ করুন। স্ক্রিনশট সাহায্য করে, কিন্তু একটি সংক্ষিপ্ত রেকর্ডিং আরও ভালো কারণ এতে টাইমিং ও নির্দিষ্ট ক্লিক ক্যাপচার হয়। সর্বদা একটি টাইমস্ট্যাম্প নোট করুন (টাইমজোনসহ) যাতে পরে লগের সাথে ম্যাচ করা যায়।
তিনটি স্পষ্টকরণ প্রশ্ন যা সবচেয়ে বেশি অনুমান দূর করে:
কারণ অনুমান করে শুরু করবেন না। সমস্যাটিকে উদ্দেশ্যমূলকভাবে, একইভাবে, একাধিকবার ঘটান।
প্রথমে রিপোর্টারের ধাপগুলো ঠিক যেমন লেখা আছে তেমন চালান। সেগুলো "উন্নত" করবেন না। যেখানে প্রথম আপনার অভিজ্ঞতা ভিন্ন হয় সেটি নোট করুন, যদিও তা ছোটই হোক—ওই প্রথম মিল ভারীরভাগ ক্ষেত্রেই ক্লু।
সাধারণ একটি ওয়ার্কফ্লো যা বেশিরভাগ অ্যাপে কাজ করে:
পুনরাবৃত্তির পরে, একবারে একটিমাত্র জিনিস পরিবর্তন করে দেখুন। এক-চর পরিবর্তন পরীক্ষা যা সাধারণত ফল দেয়:
শেষে একটি ছোট রেপ্রো স্ক্রিপ্ট দিন যাতে কেউ ২ মিনিটে চালাতে পারে: স্টার্ট স্টেট, ধাপসমূহ, ইনপুট, এবং প্রথম ব্যর্থ পর্যবেক্ষণ।
পূর্ণরূপে কোডবেস পড়া শুরুর আগে কোন লেয়ারটি ব্যর্থ হচ্ছে তা ঠিক করুন।
প্রশ্ন করুন: লক্ষণ কি কেবল UI-তেই আছে, নাকি ডেটা ও API রেসপন্সেও আছে?
উদাহরণ: "আমার প্রোফাইল নাম আপডেট হয়নি।" যদি API নতুন নাম রিটার্ন করে কিন্তু UI এখনও পুরানো দেখায়, UI স্টেট/ক্যাশিং সন্দেহ করুন। যদি API কখনোই সংরক্ষণ না করে, তাহলে API বা DB এলাকায় সমস্যা।
কয়েকটি দ্রুত ট্রায়াজ প্রশ্ন যা মিনিটের মধ্যে উত্তরযোগ্য:
UI চেকগুলো ভিজিবিলিটির ওপর: কনসোল এরর, Network ট্যাব, এবং স্টেল স্টেট (UI সেভের পরে পুনরায় ফেচ না করা অথবা পুরনো ক্যাশ থেকে পড়া)।
API চেকগুলো চুক্তির ওপর: পে-লোড (ফিল্ড, টাইপ, ID), স্ট্যাটাস কোড, এবং এরর বডি। একটি 200 উত্তর যেখানে বডি অবাক করা চাইতেও 400-এর মতই গুরুত্বপূর্ণ হতে পারে।
DB চেকগুলো বাস্তবতার ওপর: অনুপস্থিত সারি, আংশিক রাইট, কন্সট্রেইন্ট ব্যর্থতা, এমন আপডেট যা শূন্য রোকে প্রভাবিত করে কারণ WHERE ক্লজ ম্যাচ করে না।
অবস্থান ধরে রাখতে একটি ছোট মানচিত্র আঁকুন: কোন UI অ্যাকশন কোন এন্ডপয়েন্ট ট্রিগার করে, এবং কোন টেবিল(গুলি) পড়ে বা লেখে।
স্পষ্টতা প্রায়ই আসে যখন আপনি একটি বাস্তব অনুরোধ ক্লিক থেকে ডাটাবেস পর্যন্ত অনুসরণ করেন।
রিপোর্ট বা আপনার রেপ্রো থেকে তিনটি অঙ্ক ধরুন:
যদি আপনার কাছে কোরিলেশন ID না থাকে, গেটওয়ে/ব্যাকেন্ডে একটি যোগ করুন এবং সেটি রেসপন্স হেডার ও লগে অন্তর্ভুক্ত করুন।
শব্দে ক্ষয়ে না যেতে, কেবল সেই তথ্যই ধরুন যা "কোথায় ব্যর্থ এবং কেন" উত্তর দিতে প্রয়োজন:
দ্রষ্টব্যগুলির জন্য দেখুন:
"গতকাল কাজ করছিল" কিন্তু আজ না হলে, পরিবেশ ড্রিফট সন্দেহ করুন: বদলে যাওয়া ফ্ল্যাগ, রোটেটেড সিক্রেট, অনুপস্থিত মাইগ্রেশন, বা বন্ধ হয়ে যাওয়া জব।
সবচেয়ে সহজ বাগ হলো একটি ছোট, পুনরাবৃত্তিযোগ্য এক্সপেরিমেন্ট।
সবকিছু সংকুচিত করুন: কম ক্লিক, কম ফিল্ড, সর্বনিম্ন ডেটাসেট যা এখনও ব্যর্থ করে। যদি এটা কেবল "অনেকে রেকর্ড থাকা কাস্টমারের ক্ষেত্রে" ঘটে, তাহলে এমন একটি মিনিমাল কেস তৈরির চেষ্টা করুন যা এখনও ট্রিগার করে। না পারলে, এটা ইঙ্গিত করে যে বাগটি ডেটা-ভলিউম সম্পর্কিত।
"বেড স্টেট" এবং "বেড কোড" আলাদা করতে ইচ্ছাকৃতভাবে স্টেট রিসেট করুন: ক্লিন অ্যাকাউন্ট, ফ্রেশ টেন্যান্ট বা ডেটাসেট, পরিচিত বিল্ড।
রেপ্রো পরিষ্কার রাখার একটি ব্যবহারিক উপায় হল একটি কমপ্যাক্ট ইনপুট টেবিল:
| Given (setup) | When (action) | Expect | Got |
|---|---|---|---|
| User role: Editor; one record with Status=Draft | Click Save | Toast "Saved" + updated timestamp | Button shows spinner then stops; no change |
রেপ্রো পোর্টেবল করে রাখুন যাতে অন্য কেউ দ্রুত চালাতে পারে:
দ্রুততম পথ সাধারণত ক্লান্তিকর: একবারে একটি জিনিস বদলান, পর্যবেক্ষণ করুন, নোট রাখুন।
সাধারণ ভুলগুলো:
বাস্তব উদাহরণ: একটি টিকিট বলে "Export CSV খালি।" আপনি অ্যাডমিন অ্যাকাউন্ট দিয়ে পরীক্ষা করে ডেটা দেখতে পান। ব্যবহারকারীর রোল সীমিত ছিল, এবং API পারমিশন ফিল্টারের কারণে খালি লিস্ট রিটার্ন করেছিল। যদি আপনি কেবল UI প্যাচ করে "No rows" দেখান, আপনি আসল প্রশ্ন মিস করছেন: ওই রোলটি এক্সপোর্ট করার অনুমতি থাকা উচিত, নাকি প্রোডাক্টটি বলতে হবে কেন ফিল্টার করা হচ্ছে?
কোনো ফিক্সের পরে, একই রেপ্রো ধাপগুলো পুনরায় চালান, তারপর একটি পার্শ্ববর্তী সিনারিও টেস্ট করুন যা এখনও কাজ করা উচিত।
আপনি যদি একটি টাইট প্যাকেজ নিয়ে আসেন—রিপ্রোডিউসযোগ্য ধাপ, একটি সম্ভাব্য ব্যর্থ লেয়ার, এবং প্রমাণ—তাহলে সহকর্মী (বা একটি টুল) থেকে ভালো উত্তর পাবেন।
কোড পরিবর্তন-এর আগে নিশ্চিত করুন:
তারপর দ্রুত রিগ্রেশন পাস করুন: একটি ভিন্ন রোল, একটি দ্বিতীয় ব্রাউজার/প্রাইভেট উইন্ডো, একই এন্ডপয়েন্ট/টেবিল ব্যবহার করে একটি পার্শ্ববর্তী ফিচার, এবং একটি এজ-কেস ইনপুট (খালি, লম্বা টেক্সট, বিশেষ অক্ষর)।
সাপোর্ট মেসেজ বলে: "Edit Customer ফর্মে Save বোতাম কিছুই করে না।" ফলো-আপে জানা যায় এটি কেবল গত মাসের আগে তৈরি হওয়া কাস্টমারের ক্ষেত্রে এবং কেবল বিলিং ইমেইল বদলালে ঘটে।
UI থেকে শুরু করে সবচেয়ে সোজা ব্যর্থতা ধরে নিন। রেকর্ড খুলুন, এডিট করুন, এবং দেখুন "কিছুই না" আসলে কিছু কি: ডিসেবলড বোতাম, লুকিয়ে থাকা টোস্ট, রেন্ডার না হওয়া ভ্যালিডেশন মেসেজ। পরে ব্রাউজার কনসোল ও Network ট্যাব খুলুন।
এই ক্ষেত্রে, Save ক্লিক করলে একটি অনুরোধ ট্রিগার হয়, কিন্তু UI রেজাল্ট দেখায় না কারণ ফ্রন্টএন্ড কেবল 200-কে সাফল্য হিসেবে ধরে এবং 400 এররকে উপেক্ষা করে। Network ট্যাব দেখায় 400 রেসপন্স এবং একটি JSON বডি এর মতো: {"error":"billingEmail must be unique"}.
এখন নিশ্চিত করুন API সত্যিই ব্যর্থ হচ্ছে: অনুরোধ থেকে এক্স্যাক্ট পে-লোড নিয়ে তা বাইরে পুনরায় চালান। যদি UI-এর বাইরে ও ব্যর্থ করে, তবে ফ্রন্টএন্ড স্টেট বাগের পিছনে সময় নষ্ট করা বন্ধ করুন।
তারপর ডাটাবেস চেক করুন: কেন ইউনিকনেস শুধু পুরনো রেকর্ডগুলোতেই ব্যর্থ হচ্ছে? আপনি দেখতে পাবেন লেগ্যাসি কাস্টমারদের একটি প্লেসহোল্ডার billing_email বছরগুলো আগে ভাগ করে নিত। একটি নতুন ইউনিকনেস চেক এখন সেই প্লেসহোল্ডার থাকা যেকোনো কাস্টমারকে সেভ করতে বাধা দিচ্ছে।
আপনি হ্যান্ড-অফ দিতে পারবেন এমন একটি মিনিমাল রেপ্রো:
billing_email = [email protected].billingEmail must be unique.Acceptance টেস্ট: যখন API একটি ভ্যালিডেশন এরর রিটার্ন করে, UI মেসেজ দেখায়, ব্যবহারকারীর এডিট সংরক্ষণ করে রাখে, এবং এরর ঠিক যে ফিল্ডটি ব্যর্থ করেছে তা বলবে।
একবার বাগটি পুনরুত্পাদনযোগ্য এবং আপনি সম্ভাব্য লেয়ার নির্ধারণ করে ফেলেছেন, সাহায্য চাইবেন এমনভাবে যাতে একটি ছোট, নিরাপদ প্যাচ আসে।
একটি সিম্পল "কেস ফাইল" প্যাক করুন: মিনিমাল রেপ্রো ধাপ (ইনপুট, পরিবেশ, রোল সহ), প্রত্যাশিত বনাম বাস্তব, আপনি কেন মনে করেন এটা UI/API/DB, এবং ব্যর্থতা দেখানো সবচেয়ে ছোট লগ স্নিপেট।
তারপর অনুরোধটাকে সংকীর্ণ করুন:
আপনি যদি Koder.ai (koder.ai) মত ভিব-কোডিং প্ল্যাটফর্ম ব্যবহার করেন, এই কেস-ফাইল পদ্ধতিই সাজেশনের ফোকাস ধরে রাখতে সাহায্য করে। এর স্ন্যাপশট এবং রোলব্যাক আপনাকে ছোট পরিবর্তন নিরাপদে পরীক্ষা করতে এবংKNOWN বেসলাইনে ফিরে যেতে সাহায্য করে।
যদি ফিক্স সিকিউরিটি, পেমেন্ট, ডেটা মাইগ্রেশন বা এমন কিছু নিংড়ে ফেলে যা প্রোডাকশন ডেটা দুর্নশ্চিতি করতে পারে, তখন অভিজ্ঞ ডেভেলপারকে হ্যান্ড-অফ করুন। এছাড়াও হ্যান্ড-অফ করুন যদি চেঞ্জটি ছোট প্যাচের বাইরে বাড়তে থাকে বা আপনি ঝুঁকি সোজা কথায় ব্যাখ্যা করতে না পারেন।
প্রতিটা অদ্বিতীয় বাগ রিপোর্টকে একটি পুনরুত্পাদনযোগ্য স্ক্রিপ্টে রূপান্তর করুন: কে (রোল), কোথায় (পেজ/ফ্লো), কোন নির্দিষ্ট ইনপুট (ID, ফিল্টার, পে-লোড), আপনি কী আশা করেছিলেন, এবং আপনি কী দেখেছেন। যদি কোনো অংশ অনুপস্থিত থাকে, একটি উদাহরণ অ্যাকাউন্ট এবং একটি উদাহরণ রেকর্ড ID চেয়ে নিন যাতে আপনি একই পরিস্থিতি সম্পূর্ণভাবে চালাতে পারেন।
একটি পরিবেশ বেছে নিন এবং সমস্যাটি পুনরুত্পাদিত না হওয়া পর্যন্ত সেখানে টেকুন। পরে ব্যবহারকারীর সেটআপ মেলে কিনা নিশ্চিত করার জন্য বিল্ড/ভার্সন, ফিচার ফ্ল্যাগ, কনফিগ, টেস্ট অ্যাকাউন্ট/রোল এবং আপনি যে ডেটা ব্যবহার করছেন তা নোট করুন। এতে করে আপনি এমন একটি "সমাধান" করবেন না যা কেবল আপনার আলাদা সেটআপের কারণে কাজ করছে।
একই ধাপে এবং ইনপুটে দুইবার ঘটাচ্ছেন তা নিশ্চিত করুন, তারপর যা বাধ্যতামূলক নয় তা সরিয়ে ফেলুন। লক্ষ্য রাখুন ৩–৬টি ধাপ একটি ক্লিয়ান স্টার্ট স্টেট থেকে এবং একটি পুনঃব্যবহারযোগ্য রেকর্ড বা রিকোয়েস্ট বডি। যদি ছোটানো না যায়, তাইলে সাধারনত ডেটা-ভলিউম, টাইমিং, বা ব্যাকগ্রাউন্ড জব নির্ভরতার ইঙ্গিত।
কাঙ্খিত কারণ অনুমান করে শুরু করবেন না। প্রথমে রিপোর্টারের ধাপগুলো একেবারে ঠিকভাবে চালান এবং লক্ষ্য করুন প্রথম কোথায় আপনার অভিজ্ঞতা ভিন্ন হচ্ছে (ভিন্ন বোতাম লেবেল, অনুপস্থিত ফিল্ড, ভিন্ন এরর টেক্সট)। ওই প্রথম মিলের ভেদাভেদই প্রায়ই বাগ ট্রিগার করার মূল শর্ত বলে জানায়।
ডেটা কি আসলে পরিবর্তিত হয়েছে তা পরীক্ষা করুন। যদি API নতুন মান রিটার্ন করে কিন্তু UI পুরানো দেখায়, তখন UI স্টেট/ক্যাশিং সমস্যার দিকে তাকান। যদি API রেসপন্সই ভুল বা সেভ হচ্ছেনা, তখন API বা DB-এ সমস্যা খুঁজুন। যদি DB-রোওয়ার আপডেট না হয় (বা শূন্য সারি আপডেট হয়), তখন পERSISTENCE লেয়ার বা কুয়েরি কন্ডিশন-ই সমস্যা।
নেটওয়ার্ক অনুরোধটি চলছে কি না দেখুন যখন আপনি বোতামে ক্লিক করেন; তারপর রিকোয়েস্ট পে-লোড এবং রেসপন্স বডি পরীক্ষা করুন—শুধু স্ট্যাটাস কোড নয়। লগ ম্যাচ করার জন্য টাইমস্ট্যাম্প (টাইমজোনসহ) এবং ইউজার আইডেন্টিফায়ার ধরুন। একটি “সফল” 200 রেসপন্সে অপ্রত্যাশিত বডিও 400/500-এর মতোই গুরুত্বপূর্ণ হতে পারে।
একই সময়ে কেবল একটি ব্যাপার বদলে দেখুন: রোল, রেকর্ড (নতুন বনাম লেগ্যাসি), ব্রাউজার/ডিভাইস, ক্লিন সেশন (ইনকগনিটো/ক্যাশ ক্লিয়ার), এবং নেটওয়ার্ক। একচেটিয়া পরীক্ষা আপনাকে কোন কন্ডিশনটি গুরুত্ব রাখে তা বলবে এবং একাধিক পরিবর্তন করার ফলে সৃষ্টি হওয়া ঘটনার পিছনে ছুড়ি মারতে বাধা দেবে।
একসাথে একাধিক ভ্যারিয়েবল পরিবর্তন করা, রিপোর্টারের থেকে আলাদা পরিবেশে পরীক্ষা করা, এবং রোল/পারমিশন উপেক্ষা করাই সবচেয়ে সময় নষ্ট করে। আরেকটি ফাঁদ হলো UI-তে কেবল সিফেস সিম্পটম ঠিক করে ফেলা যখন আসলে API/DB ভ্যালিডেশন এরর চলছে। পরিবর্তন করার পরে অবশ্যই একই রেপ্রো আবার চালান এবং একটি নিকটবর্তী সিনারিওও পরীক্ষা করুন।
"ডানভাবে কাজ করছে আমার মেশিনে" থেকে এগিয়ে দেখার অর্থ: মূল মিনিমাল রেপ্রো এখন পাস করে, এবং আপনি অনওরে একটি নিকটবর্তী ফ্লো পুনরায় পরীক্ষা করেছেন যা প্রভাবিত হতে পারে। একটি নির্দিষ্ট চেক রাখুন—যেমন দৃশ্যমান সাফল্য সিগন্যাল, সঠিক HTTP রেসপন্স, বা প্রত্যাশিত DB রো পরিবর্তন। "মনে হচ্ছে ঠিক আছে" বলে কাটাছেঁড়া করবেন না—একই ইনপুট একই বেসলাইনে চালান।
একটি টাইট কেস ফাইল দিন: মিনিমাল ধাপ ও এক্স্যাক্ট ইনপুট, পরিবেশ/বিল্ড/ফ্ল্যাগ, টেস্ট অ্যাকাউন্ট ও রোল, প্রত্যাশিত বনাম বাস্তব ফলাফল, এবং একটি প্রমাণ (রিকোয়েস্ট/রেসপন্স, এরর টেক্সট, বা টাইমস্ট্যাম্প সহ লগ স্নিপেট)। তারপর বলুন সবচেয়ে ছোট প্যাচ কী হবে যাতে রেপ্রো পাস করে এবং একটি ছোট টেস্ট প্ল্যান যোগ করুন। Koder.ai ব্যবহার করলে, স্ন্যাপশট/রোলব্যাক সহ এই কেস-ফাইল ছোট পরিবর্তন নিরাপদে পরীক্ষা করতে সাহায্য করে।