আপনি লিখেননি এমন বাগ রিপোর্ট ডিবাগ করুন: একটি ব্যবহারিক ওয়ার্কফ্লো
আপনি লিখেননি এমন বাগ রিপোর্ট ডিবাগ করার জন্য একটি ব্যবহারিক ওয়ার্কফ্লো: কিভাবে ইস্যুগুলো পুনরুত্পাদন করবেন, UI/API/DB আলাদা করবেন, এবং একটি মিনিমাল, টেস্টেবল AI ফিক্স অনুরোধ করবেন।
কি কারণে এসব বাগ রিপোর্ট কঠিন (এবং আপনি কী নিয়ন্ত্রণ করতে পারেন)
আপনি যদি এমন একটি বাগ রিপোর্ট ডিবাগ করেন যা আপনি লিখেননি, তবে তা কঠিন হয়ে যায় কারণ আপনার কাছে মূল নির্মাতার মানসিক মানচিত্র নেই। আপনি জানেন না কোন অংশ দুর্বল, কোনটি "সাধারণ," বা কোন শর্টকাট নেওয়া হয়েছে। একটি ছোট লক্ষণ (একটি বোতাম, একটি টাইপো, একটি ধীর স্ক্রীন) এখনও গভীরতর সমস্যা থেকে আসতে পারে—API, ডাটাবেস, বা ব্যাকগ্রাউন্ড জব থেকে।
একটি কাজে লাগার মতো বাগ রিপোর্ট আপনাকে চারটি জিনিস দেয়:
- সঠিক অ্যাকশন
- সঠিক ডেটা
- প্রত্যাশিত ফলাফল
- বাস্তব ফলাফল
অধিকাংশ রিপোর্ট শুধু শেষটিই দেয়: "সেভ হচ্ছে না," "ভাঙা আছে," "র্যানডম এরর।" যা মিস হচ্ছে সেটা হল সেই প্রসঙ্গ যা এটিকে পুনরাবৃত্তিযোগ্য করে তোলে: ইউজার রোল, নির্দিষ্ট রেকর্ড, পরিবেশ (প্রোড বনাম স্টেজিং), এবং এটি কি কোনো পরিবর্তনের পর শুরু হয়েছে কিনা।
লক্ষ্য হলো একটি অস্পষ্ট লক্ষণকে নির্ভরযোগ্য পুনরুত্পাদনে পরিণত করা। একবার আপনি এটি ডিমান্ডে ঘটাতে পারলে, তা আর রহস্যময় থাকে না—এটি পরীক্ষার একটি ধারাবাহিকতা।
আপনি যা তৎক্ষণাৎ নিয়ন্ত্রণ করতে পারেন:
- সমস্যাটি ট্রিগার করার সবচেয়ে ছোট ধাপসমূহ
- সঠিক টেস্ট ডেটা (ID, ইমেইল, পে-লোড, ফিল্টার)
- পরিবেশ এবং সংস্করণ (বিল্ড, ফিচার ফ্ল্যাগ, ব্রাউজার/ডিভাইস)
- ঘটার প্রমাণ (টাইমস্ট্যাম্প, স্ক্রিনশট, এরর টেক্সট, লগ স্নিপেট)
- একটি স্পষ্ট পাস/ফেইল ফলাফল যা আপনি পুনরায় চালাতে পারেন
"ডান" মানে হচ্ছে "আমি মনে করি ফিক্স করেছি" না। ডান হলো: আপনার রেপ্রো ধাপগুলো একটি ছোট পরিবর্তনের পরে পাস করে, এবং আপনি দ্রুত পার্শ্ববর্তী আচরণগুলো পুনরায় টেস্ট করেন যা আপনি প্রভাবিত করতে পারেন।
কোনও কিছু ছোঁয়ার আগে একটি স্থিতিশীল বেসলাইন তৈরি করুন
বহু জিনিস একই সময়ে বদলে ফেলার ফলে সময় দ্রুত নষ্ট হয়। আপনার শুরু পয়েন্ট ফ্রিজ করে রাখুন যাতে প্রতিটি টেস্ট ফলাফল অর্থপূর্ণ হয়।
একটি পরিবেশ বেছে নিন এবং সমস্যাটি পুনরুত্পাদিত না হওয়া পর্যন্ত সেখানে থাকুন। রিপোর্ট প্রোডাকশন থেকে এসেছে কিনা, আগে সেখানে যাচাই করুন। যদি সেটি ঝুঁকিপূর্ণ হয়, স্টেজিং ব্যবহার করুন। লোকালও ঠিক আছে যদি আপনি ডেটা এবং সেটিংস ঘনিষ্ঠভাবে মেলাতে পারেন।
তারপর কোন কোড আসলে চলছে তা পিন করুন: ভার্সন, বিল্ড তারিখ, এবং যে কোনো ফিচার ফ্ল্যাগ বা কনফিগ যা ফ্লোতে প্রভাব ফেলে। ছোট পার্থক্য (ডিসেবলড ইন্টিগ্রেশন, ভিন্ন API বেস URL, অনুপস্থিত ব্যাকগ্রাউন্ড জব) একটি বাস্তব বাগকে ভূত বানিয়ে দিতে পারে।
একটি পরিষ্কার, পুনরাবৃত্তিযোগ্য টেস্ট সেটআপ তৈরি করুন। নতুন একটি অ্যাকাউন্ট এবং পরিচিত ডেটা ব্যবহার করুন। সম্ভব হলে প্রতিটি প্রচেষ্টার আগে স্টেট রিসেট করুন (লগ আউট, ক্যাশ পরিষ্কার, একই রেকর্ড থেকে শুরু)।
আপনি যতক্ষণ যাচ্ছেন, ধরে নেওয়া অনুমানগুলো লিখে রাখুন। এটা ব্যস্ততার কাজ নয়; পরে নিজের সঙ্গে বিতর্ক থামায়।
একটি বেসলাইন নোট টেমপ্লেট:
- পরিবেশ: prod, staging, বা local
- ভার্সন/বিল্ড: কমিট, ট্যাগ, বা বিল্ড টাইমস্ট্যাম্প
- কনফিগ: ফিচার ফ্ল্যাগ, ইন্টিগ্রেশন, টেস্ট কিজ
- টেস্ট পরিচয়: অ্যাকাউন্ট ইমেইল/রোল, পারমিশন
- ডেটা: রেকর্ড ID, সিড করা আইটেম, প্রত্যাশিত স্টার্টিং স্টেট
যদি রেপ্রো ব্যর্থ হয়, এই নোটগুলো বলে দেবে পরবর্তী কোন কন্ট্রাস্ট পরিবর্তন করবেন—একেকটি নাবল একবারে।
রিপোর্টকে টেস্টেবল ধাপে ও ইনপুটে অনুবাদ করুন
দ্রুততম জয় হলো অস্পষ্ট অভিযোগকে এমন কিছুতে পরিণত করা যা আপনি স্ক্রিপ্টের মত চালাতে পারেন।
রিপোর্টকে ছোট একটি ইউজার স্টোরিতে লিখে শুরু করুন: কে কি করছে, কোথায়, এবং তারা কী আশা করছিল। তারপর দেখা ফলাফলটা যোগ করুন।
উদাহরণ রিরাইট:
"একজন বিলিং অ্যাডমিন হিসেবে, যখন আমি একটি ইনভয়েসের স্ট্যাটাসকে Paid-এ বদল করে ইনভয়েস পেজে Save ক্লিক করি, স্ট্যাটাসটি স্থায়ী হওয়া উচিত। পরিবর্তে পেজ অপরিবর্তিত থাকে এবং রিফ্রেশের পরে স্ট্যাটাস অপরিবর্তিত থাকে।"
পরবর্তীতে, সেই শর্তগুলো ধরুন যা রিপোর্টকে সত্যি করে তোলে। বাগ প্রায়ই একটি অনুপস্থিত বিবরণে নির্ভর করে: রোল, রেকর্ড স্টেট, লোকেল, বা পরিবেশ।
কী ইনপুট আগে লিখে রাখবেন:
- ইউজার রোল এবং অ্যাকাউন্ট টাইপ (অ্যাডমিন বনাম স্ট্যান্ডার্ড, ট্রায়াল বনাম পেইড)
- ডেটার অবস্থা (রেকর্ড ID, স্ট্যাটাস, প্রয়োজনীয় সম্পর্কিত ডেটা)
- ক্লায়েন্ট বিশদ (OS, ব্রাউজার/অ্যাপ সংস্করণ)
- লোকেল ও সময় সেটিংস (ভাষা, টাইমজোন, তারিখ রেন্জ)
- পরিবেশ ও বিল্ড (prod বনাম staging, রিলিজ ভার্সন, ফিচার ফ্ল্যাগ)
মূল আচরণটি যখন এখনও আছে তখন প্রমাণ সংগ্রহ করুন। স্ক্রিনশট সাহায্য করে, কিন্তু একটি সংক্ষিপ্ত রেকর্ডিং আরও ভালো কারণ এতে টাইমিং ও নির্দিষ্ট ক্লিক ক্যাপচার হয়। সর্বদা একটি টাইমস্ট্যাম্প নোট করুন (টাইমজোনসহ) যাতে পরে লগের সাথে ম্যাচ করা যায়।
তিনটি স্পষ্টকরণ প্রশ্ন যা সবচেয়ে বেশি অনুমান দূর করে:
- কোন নির্দিষ্ট ইউজার অ্যাকাউন্ট ও রোল এ এটি ঘটেছে, এবং আপনি কি একটি উদাহরণ রেকর্ড ID শেয়ার করতে পারবেন?
- আপনি অ্যাকশনের পরে তাত্ক্ষণিক কি দেখা আশা করেছিলেন, এবং আপনি আসলতে কি দেখেছেন?
- একই ধাপে কি প্রতিবারই হয়, নাকি কেবল নির্দিষ্ট ডেটা (স্ট্যাটাস, তারিখ রেঞ্জ, লোকেল, বড় ইনপুট) সহ হয়?
সমস্যা নির্ভরযোগ্যভাবে পুনরুত্পাদন করুন
কারণ অনুমান করে শুরু করবেন না। সমস্যাটিকে উদ্দেশ্যমূলকভাবে, একইভাবে, একাধিকবার ঘটান।
প্রথমে রিপোর্টারের ধাপগুলো ঠিক যেমন লেখা আছে তেমন চালান। সেগুলো "উন্নত" করবেন না। যেখানে প্রথম আপনার অভিজ্ঞতা ভিন্ন হয় সেটি নোট করুন, যদিও তা ছোটই হোক—ওই প্রথম মিল ভারীরভাগ ক্ষেত্রেই ক্লু।
সাধারণ একটি ওয়ার্কফ্লো যা বেশিরভাগ অ্যাপে কাজ করে:
- একটি পরিচিত শুরুর অবস্থা রিসেট করুন (ফ্রেশ লোড, একই অ্যাকাউন্ট, একই পারমিশন, একই ফ্ল্যাগ)
- ধাপগুলো এক এক করে অনুসরণ করে আপনি ব্যবহার করা এক্স্যাক্ট ইনপুট নোট করুন (ID, তারিখ, ফিল্টার)
- যেখানে ভেঙে যায় সেই ধাপে প্রত্যাশিত বনাম বাস্তব লিখে রাখুন
- একবার পুনরায় চালান যাতে রিপিটেবল কিনা নিশ্চিত হয়
- তারপর সবচেয়ে ছোট ধাপসমূহে সংকোচন করুন যা এখনও ট্রিগার করে
পুনরাবৃত্তির পরে, একবারে একটিমাত্র জিনিস পরিবর্তন করে দেখুন। এক-চর পরিবর্তন পরীক্ষা যা সাধারণত ফল দেয়:
- একই ধাপ, ভিন্ন রোল
- একই ধাপ, ভিন্ন রেকর্ড (নতুন বনাম লেগ্যাসি)
- একই ধাপ, ভিন্ন ব্রাউজার/ডিভাইস
- একই ধাপ, পরিষ্কার সেশন (ইনকগনিটো, ক্যাশ ক্লিয়ার)
- একই ধাপ, ভিন্ন নেটওয়ার্ক
শেষে একটি ছোট রেপ্রো স্ক্রিপ্ট দিন যাতে কেউ ২ মিনিটে চালাতে পারে: স্টার্ট স্টেট, ধাপসমূহ, ইনপুট, এবং প্রথম ব্যর্থ পর্যবেক্ষণ।
ব্যর্থ লেয়ার আলাদা করুন: UI, API, বা DB
পূর্ণরূপে কোডবেস পড়া শুরুর আগে কোন লেয়ারটি ব্যর্থ হচ্ছে তা ঠিক করুন।
প্রশ্ন করুন: লক্ষণ কি কেবল UI-তেই আছে, নাকি ডেটা ও API রেসপন্সেও আছে?
উদাহরণ: "আমার প্রোফাইল নাম আপডেট হয়নি।" যদি API নতুন নাম রিটার্ন করে কিন্তু UI এখনও পুরানো দেখায়, UI স্টেট/ক্যাশিং সন্দেহ করুন। যদি API কখনোই সংরক্ষণ না করে, তাহলে API বা DB এলাকায় সমস্যা।
কয়েকটি দ্রুত ট্রায়াজ প্রশ্ন যা মিনিটের মধ্যে উত্তরযোগ্য:
- আপনি কি একাধিক ব্রাউজার/ডিভাইসে এটি পুনরুত্পাদন করতে পারেন?
- একটি হার্ড রিফ্রেশ কিছু পরিবর্তন করে?
- বোতামে ক্লিক করলে একটি নেটওয়ার্ক অনুরোধ_fire করে?
- কি API রেসপন্সই ইতিমধ্যেই ভুল দেখায়?
- কাজটি করার পরে ডাটাবেসে প্রত্যাশিত রো দেখা যায়?
UI চেকগুলো ভিজিবিলিটির ওপর: কনসোল এরর, Network ট্যাব, এবং স্টেল স্টেট (UI সেভের পরে পুনরায় ফেচ না করা অথবা পুরনো ক্যাশ থেকে পড়া)।
API চেকগুলো চুক্তির ওপর: পে-লোড (ফিল্ড, টাইপ, ID), স্ট্যাটাস কোড, এবং এরর বডি। একটি 200 উত্তর যেখানে বডি অবাক করা চাইতেও 400-এর মতই গুরুত্বপূর্ণ হতে পারে।
DB চেকগুলো বাস্তবতার ওপর: অনুপস্থিত সারি, আংশিক রাইট, কন্সট্রেইন্ট ব্যর্থতা, এমন আপডেট যা শূন্য রোকে প্রভাবিত করে কারণ WHERE ক্লজ ম্যাচ করে না।
অবস্থান ধরে রাখতে একটি ছোট মানচিত্র আঁকুন: কোন UI অ্যাকশন কোন এন্ডপয়েন্ট ট্রিগার করে, এবং কোন টেবিল(গুলি) পড়ে বা লেখে।
লগ ও টাইমস্ট্যাম্প দিয়ে অনুরোধটি শুরু থেকে শেষ পর্যন্ত অনুসরণ করুন
স্পষ্টতা প্রায়ই আসে যখন আপনি একটি বাস্তব অনুরোধ ক্লিক থেকে ডাটাবেস পর্যন্ত অনুসরণ করেন।
রিপোর্ট বা আপনার রেপ্রো থেকে তিনটি অঙ্ক ধরুন:
- সঠিক সময় (টাইমজোনসহ)
- ইউজার আইডেন্টিফায়ার (অ্যাকাউন্ট/ইমেইল/ইন্টারনাল ID)
- কোরিলেশন ID (রিকোয়েস্ট ID/ট্রেস ID/সেশন ID)
যদি আপনার কাছে কোরিলেশন ID না থাকে, গেটওয়ে/ব্যাকেন্ডে একটি যোগ করুন এবং সেটি রেসপন্স হেডার ও লগে অন্তর্ভুক্ত করুন।
শব্দে ক্ষয়ে না যেতে, কেবল সেই তথ্যই ধরুন যা "কোথায় ব্যর্থ এবং কেন" উত্তর দিতে প্রয়োজন:
- টাইমস্ট্যাম্প রেঞ্জ (উদাহরণ: ঘটনার ১ মিনিট আগে থেকে ১ মিনিট পরে)
- একটি ইউজার ID (এবং টেন্যান্ট/অর্গ ID যদি প্রাসঙ্গিক)
- কোরিলেশন ID
- মেথড, পাথ, স্ট্যাটাস কোড, লেটেন্সি
- প্রথম অর্থবোধক এরর মেসেজ (পুরো স্ট্যাক ট্রেস নয়)
দ্রষ্টব্যগুলির জন্য দেখুন:
- টাইমআউট/দীর্ঘ লেটেন্সি: ধীর কুয়েরি, বাইরের কল, লক
- 401/403: পারমিশন বা টেন্যান্ট কনটেক্সট ইস্যু
- 400 ভ্যালিডেশন এরর: প্রায়ই UI পে-লোড মিসম্যাচ
"গতকাল কাজ করছিল" কিন্তু আজ না হলে, পরিবেশ ড্রিফট সন্দেহ করুন: বদলে যাওয়া ফ্ল্যাগ, রোটেটেড সিক্রেট, অনুপস্থিত মাইগ্রেশন, বা বন্ধ হয়ে যাওয়া জব।
একটি মিনিমাল পুনরুত্পাদনযোগ্য কেস তৈরি করুন (এতে ফিক্স ছোট থাকবে)
সবচেয়ে সহজ বাগ হলো একটি ছোট, পুনরাবৃত্তিযোগ্য এক্সপেরিমেন্ট।
সবকিছু সংকুচিত করুন: কম ক্লিক, কম ফিল্ড, সর্বনিম্ন ডেটাসেট যা এখনও ব্যর্থ করে। যদি এটা কেবল "অনেকে রেকর্ড থাকা কাস্টমারের ক্ষেত্রে" ঘটে, তাহলে এমন একটি মিনিমাল কেস তৈরির চেষ্টা করুন যা এখনও ট্রিগার করে। না পারলে, এটা ইঙ্গিত করে যে বাগটি ডেটা-ভলিউম সম্পর্কিত।
"বেড স্টেট" এবং "বেড কোড" আলাদা করতে ইচ্ছাকৃতভাবে স্টেট রিসেট করুন: ক্লিন অ্যাকাউন্ট, ফ্রেশ টেন্যান্ট বা ডেটাসেট, পরিচিত বিল্ড।
রেপ্রো পরিষ্কার রাখার একটি ব্যবহারিক উপায় হল একটি কমপ্যাক্ট ইনপুট টেবিল:
| 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 |
রেপ্রো পোর্টেবল করে রাখুন যাতে অন্য কেউ দ্রুত চালাতে পারে:
- ক্লিন স্টার্ট থেকে ৩ থেকে ৬ ধাপ
- একটি টেস্ট রেকর্ড (বা একটি রিকোয়েস্ট বডি) আপনি পুনরায় ব্যবহার করতে পারেন
- একটি পরিষ্কার সাফল্য সিগন্যাল (UI মেসেজ, HTTP কোড, DB রো কাউন্ট)
- সঠিক পরিবেশ বিবরণ (বিল্ড/ভার্সন, রোল, ফ্ল্যাগ)
সময় নষ্ট করা সাধারণ ফাঁদ
দ্রুততম পথ সাধারণত ক্লান্তিকর: একবারে একটি জিনিস বদলান, পর্যবেক্ষণ করুন, নোট রাখুন।
সাধারণ ভুলগুলো:
- সারফেস সিম্পটম ঠিক করে ফেলা (কোনো বাস্তব API/DB এররকে ঢেকে রাখা)
- একসঙ্গে বহু ভ্যারিয়েবল পরিবর্তন করা (ডিপেন্ডেন্সি আপডেট + কনফিগ টুইক + রিফ্যাক্টর)
- রিপোর্টারের থেকে আলাদা বেসলাইন-এ পরীক্ষা করা (env, data, build, browser)
- পারমিশন ও রোল ভুলে যাওয়া (অ্যাডমিন বনাম রেগুলার ইউজার)
- ফিচার ফ্ল্যাগ বা এক্সপেরিমেন্ট মিস করা যা ফ্লো বদলায়
- যাচাই ছাড়া বিজয় ঘোষণা করা (রেপ্রো রিরান না করা, পাশের আচরণ না চেক করা)
বাস্তব উদাহরণ: একটি টিকিট বলে "Export CSV খালি।" আপনি অ্যাডমিন অ্যাকাউন্ট দিয়ে পরীক্ষা করে ডেটা দেখতে পান। ব্যবহারকারীর রোল সীমিত ছিল, এবং API পারমিশন ফিল্টারের কারণে খালি লিস্ট রিটার্ন করেছিল। যদি আপনি কেবল UI প্যাচ করে "No rows" দেখান, আপনি আসল প্রশ্ন মিস করছেন: ওই রোলটি এক্সপোর্ট করার অনুমতি থাকা উচিত, নাকি প্রোডাক্টটি বলতে হবে কেন ফিল্টার করা হচ্ছে?
কোনো ফিক্সের পরে, একই রেপ্রো ধাপগুলো পুনরায় চালান, তারপর একটি পার্শ্ববর্তী সিনারিও টেস্ট করুন যা এখনও কাজ করা উচিত।
কোয়ালিটি চেকলিস্ট: ফিক্স চাইবার আগে দ্রুত লিস্ট
আপনি যদি একটি টাইট প্যাকেজ নিয়ে আসেন—রিপ্রোডিউসযোগ্য ধাপ, একটি সম্ভাব্য ব্যর্থ লেয়ার, এবং প্রমাণ—তাহলে সহকর্মী (বা একটি টুল) থেকে ভালো উত্তর পাবেন।
কোড পরিবর্তন-এর আগে নিশ্চিত করুন:
- আপনি একই ইনপুট ব্যবহার করে দুইবার পুনরুত্পাদন করতে পারেন (একই ইউজার, একই ডেটা, একই পরিবেশ)।
- আপনি ব্যর্থ লেয়ারটি (UI, API, অথবা DB) নাম করতে পারেন এবং একটি কারণ দিতে পারেন।
- আপনি প্রমাণ সংগ্রহ করেছেন: রিকোয়েস্ট, রেসপন্স/এরর, প্রাসঙ্গিক লগ, এবং মিল করা টাইমস্ট্যাম্প।
- আপনি রেপ্রোকে যতটা সম্ভব ছোট করেছেন।
- আপনি এক বাক্যে গ্রহণযোগ্যতার শর্ত লিখেছেন (উদাহরণ: "Saving updates the record and shows success within 2 seconds").
তারপর দ্রুত রিগ্রেশন পাস করুন: একটি ভিন্ন রোল, একটি দ্বিতীয় ব্রাউজার/প্রাইভেট উইন্ডো, একই এন্ডপয়েন্ট/টেবিল ব্যবহার করে একটি পার্শ্ববর্তী ফিচার, এবং একটি এজ-কেস ইনপুট (খালি, লম্বা টেক্সট, বিশেষ অক্ষর)।
একটি বাস্তব উদাহরণ: "Save বোতাম কিছুই করে না" বাগ সংকোচন
সাপোর্ট মেসেজ বলে: "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]. - যেকোনো ফিল্ড পরিবর্তন করুন এবং Save ক্লিক করুন.
- লক্ষ্য করুন API 400 রিটার্ন করে
billingEmail must be unique. - লক্ষ্য করুন UI কোনো এরর দেখায় না এবং ফর্ম অপরিবর্তিত থাকে।
Acceptance টেস্ট: যখন API একটি ভ্যালিডেশন এরর রিটার্ন করে, UI মেসেজ দেখায়, ব্যবহারকারীর এডিট সংরক্ষণ করে রাখে, এবং এরর ঠিক যে ফিল্ডটি ব্যর্থ করেছে তা বলবে।
পরবর্তী ধাপ: এমন একটি ছোট ফিক্স চাইুন যা আপনি পরীক্ষা করতে পারবেন
একবার বাগটি পুনরুত্পাদনযোগ্য এবং আপনি সম্ভাব্য লেয়ার নির্ধারণ করে ফেলেছেন, সাহায্য চাইবেন এমনভাবে যাতে একটি ছোট, নিরাপদ প্যাচ আসে।
একটি সিম্পল "কেস ফাইল" প্যাক করুন: মিনিমাল রেপ্রো ধাপ (ইনপুট, পরিবেশ, রোল সহ), প্রত্যাশিত বনাম বাস্তব, আপনি কেন মনে করেন এটা UI/API/DB, এবং ব্যর্থতা দেখানো সবচেয়ে ছোট লগ স্নিপেট।
তারপর অনুরোধটাকে সংকীর্ণ করুন:
- প্রস্তাব করুন সবচেয়ে ছোট কোড পরিবর্তন যা রেপ্রো পাস করাবে
- রিফ্যাক্টরের প্রয়োজন না হলে তা এড়িয়ে চলুন
- কারণটা সরল কথায় ব্যাখ্যা করুন
- একটি ছোট টেস্ট প্ল্যান যোগ করুন (কীভাবে ফিক্সটি নিশ্চিত করবেন এবং পাশের কি ভাঙতে পারে)
আপনি যদি Koder.ai (koder.ai) মত ভিব-কোডিং প্ল্যাটফর্ম ব্যবহার করেন, এই কেস-ফাইল পদ্ধতিই সাজেশনের ফোকাস ধরে রাখতে সাহায্য করে। এর স্ন্যাপশট এবং রোলব্যাক আপনাকে ছোট পরিবর্তন নিরাপদে পরীক্ষা করতে এবংKNOWN বেসলাইনে ফিরে যেতে সাহায্য করে।
যদি ফিক্স সিকিউরিটি, পেমেন্ট, ডেটা মাইগ্রেশন বা এমন কিছু নিংড়ে ফেলে যা প্রোডাকশন ডেটা দুর্নশ্চিতি করতে পারে, তখন অভিজ্ঞ ডেভেলপারকে হ্যান্ড-অফ করুন। এছাড়াও হ্যান্ড-অফ করুন যদি চেঞ্জটি ছোট প্যাচের বাইরে বাড়তে থাকে বা আপনি ঝুঁকি সোজা কথায় ব্যাখ্যা করতে না পারেন।
সাধারণ প্রশ্ন
What’s the first thing I should do with a vague bug report like “it’s broken”?
প্রতিটা অদ্বিতীয় বাগ রিপোর্টকে একটি পুনরুত্পাদনযোগ্য স্ক্রিপ্টে রূপান্তর করুন: কে (রোল), কোথায় (পেজ/ফ্লো), কোন নির্দিষ্ট ইনপুট (ID, ফিল্টার, পে-লোড), আপনি কী আশা করেছিলেন, এবং আপনি কী দেখেছেন। যদি কোনো অংশ অনুপস্থিত থাকে, একটি উদাহরণ অ্যাকাউন্ট এবং একটি উদাহরণ রেকর্ড ID চেয়ে নিন যাতে আপনি একই পরিস্থিতি সম্পূর্ণভাবে চালাতে পারেন।
How do I set a baseline so my tests actually mean something?
একটি পরিবেশ বেছে নিন এবং সমস্যাটি পুনরুত্পাদিত না হওয়া পর্যন্ত সেখানে টেকুন। পরে ব্যবহারকারীর সেটআপ মেলে কিনা নিশ্চিত করার জন্য বিল্ড/ভার্সন, ফিচার ফ্ল্যাগ, কনফিগ, টেস্ট অ্যাকাউন্ট/রোল এবং আপনি যে ডেটা ব্যবহার করছেন তা নোট করুন। এতে করে আপনি এমন একটি "সমাধান" করবেন না যা কেবল আপনার আলাদা সেটআপের কারণে কাজ করছে।
How do I turn the report into a minimal reproduction that someone else can run fast?
একই ধাপে এবং ইনপুটে দুইবার ঘটাচ্ছেন তা নিশ্চিত করুন, তারপর যা বাধ্যতামূলক নয় তা সরিয়ে ফেলুন। লক্ষ্য রাখুন ৩–৬টি ধাপ একটি ক্লিয়ান স্টার্ট স্টেট থেকে এবং একটি পুনঃব্যবহারযোগ্য রেকর্ড বা রিকোয়েস্ট বডি। যদি ছোটানো না যায়, তাইলে সাধারনত ডেটা-ভলিউম, টাইমিং, বা ব্যাকগ্রাউন্ড জব নির্ভরতার ইঙ্গিত।
Should I start by guessing the cause or by reproducing it?
কাঙ্খিত কারণ অনুমান করে শুরু করবেন না। প্রথমে রিপোর্টারের ধাপগুলো একেবারে ঠিকভাবে চালান এবং লক্ষ্য করুন প্রথম কোথায় আপনার অভিজ্ঞতা ভিন্ন হচ্ছে (ভিন্ন বোতাম লেবেল, অনুপস্থিত ফিল্ড, ভিন্ন এরর টেক্সট)। ওই প্রথম মিলের ভেদাভেদই প্রায়ই বাগ ট্রিগার করার মূল শর্ত বলে জানায়।
How can I quickly tell if the bug is in the UI, API, or database?
ডেটা কি আসলে পরিবর্তিত হয়েছে তা পরীক্ষা করুন। যদি API নতুন মান রিটার্ন করে কিন্তু UI পুরানো দেখায়, তখন UI স্টেট/ক্যাশিং সমস্যার দিকে তাকান। যদি API রেসপন্সই ভুল বা সেভ হচ্ছেনা, তখন API বা DB-এ সমস্যা খুঁজুন। যদি DB-রোওয়ার আপডেট না হয় (বা শূন্য সারি আপডেট হয়), তখন পERSISTENCE লেয়ার বা কুয়েরি কন্ডিশন-ই সমস্যা।
What evidence should I capture while reproducing the bug?
নেটওয়ার্ক অনুরোধটি চলছে কি না দেখুন যখন আপনি বোতামে ক্লিক করেন; তারপর রিকোয়েস্ট পে-লোড এবং রেসপন্স বডি পরীক্ষা করুন—শুধু স্ট্যাটাস কোড নয়। লগ ম্যাচ করার জন্য টাইমস্ট্যাম্প (টাইমজোনসহ) এবং ইউজার আইডেন্টিফায়ার ধরুন। একটি “সফল” 200 রেসপন্সে অপ্রত্যাশিত বডিও 400/500-এর মতোই গুরুত্বপূর্ণ হতে পারে।
What’s the best way to test “it only happens sometimes” bugs?
একই সময়ে কেবল একটি ব্যাপার বদলে দেখুন: রোল, রেকর্ড (নতুন বনাম লেগ্যাসি), ব্রাউজার/ডিভাইস, ক্লিন সেশন (ইনকগনিটো/ক্যাশ ক্লিয়ার), এবং নেটওয়ার্ক। একচেটিয়া পরীক্ষা আপনাকে কোন কন্ডিশনটি গুরুত্ব রাখে তা বলবে এবং একাধিক পরিবর্তন করার ফলে সৃষ্টি হওয়া ঘটনার পিছনে ছুড়ি মারতে বাধা দেবে।
What are the most common mistakes that waste time during debugging?
একসাথে একাধিক ভ্যারিয়েবল পরিবর্তন করা, রিপোর্টারের থেকে আলাদা পরিবেশে পরীক্ষা করা, এবং রোল/পারমিশন উপেক্ষা করাই সবচেয়ে সময় নষ্ট করে। আরেকটি ফাঁদ হলো UI-তে কেবল সিফেস সিম্পটম ঠিক করে ফেলা যখন আসলে API/DB ভ্যালিডেশন এরর চলছে। পরিবর্তন করার পরে অবশ্যই একই রেপ্রো আবার চালান এবং একটি নিকটবর্তী সিনারিওও পরীক্ষা করুন।
What does “done” look like for a bug fix, beyond “it works on my machine”?
"ডানভাবে কাজ করছে আমার মেশিনে" থেকে এগিয়ে দেখার অর্থ: মূল মিনিমাল রেপ্রো এখন পাস করে, এবং আপনি অনওরে একটি নিকটবর্তী ফ্লো পুনরায় পরীক্ষা করেছেন যা প্রভাবিত হতে পারে। একটি নির্দিষ্ট চেক রাখুন—যেমন দৃশ্যমান সাফল্য সিগন্যাল, সঠিক HTTP রেসপন্স, বা প্রত্যাশিত DB রো পরিবর্তন। "মনে হচ্ছে ঠিক আছে" বলে কাটাছেঁড়া করবেন না—একই ইনপুট একই বেসলাইনে চালান।
How should I ask an AI builder (or a teammate) for a small, testable fix?
একটি টাইট কেস ফাইল দিন: মিনিমাল ধাপ ও এক্স্যাক্ট ইনপুট, পরিবেশ/বিল্ড/ফ্ল্যাগ, টেস্ট অ্যাকাউন্ট ও রোল, প্রত্যাশিত বনাম বাস্তব ফলাফল, এবং একটি প্রমাণ (রিকোয়েস্ট/রেসপন্স, এরর টেক্সট, বা টাইমস্ট্যাম্প সহ লগ স্নিপেট)। তারপর বলুন সবচেয়ে ছোট প্যাচ কী হবে যাতে রেপ্রো পাস করে এবং একটি ছোট টেস্ট প্ল্যান যোগ করুন। Koder.ai ব্যবহার করলে, স্ন্যাপশট/রোলব্যাক সহ এই কেস-ফাইল ছোট পরিবর্তন নিরাপদে পরীক্ষা করতে সাহায্য করে।