৩১ ডিসে, ২০২৫·7 মিনিট
প্রম্পট থেকে গ্রহণযোগ্য টেস্ট: ফিচারগুলোকে দৃশ্যপটে পরিণত করুন
প্রতিটি ফিচার প্রম্পটকে ৫–১০টি পরিষ্কার দৃশ্যপটে বদলে নিয়ে নিন — হ্যাপি পাথ ও এজ কেস কভার করে, অতিরিক্ত বড় টেস্ট সুইট ছাড়াই গ্রহণযোগ্যতা নিশ্চিত করুন।
প্রতিটি ফিচার প্রম্পটকে ৫–১০টি পরিষ্কার দৃশ্যপটে বদলে নিয়ে নিন — হ্যাপি পাথ ও এজ কেস কভার করে, অতিরিক্ত বড় টেস্ট সুইট ছাড়াই গ্রহণযোগ্যতা নিশ্চিত করুন।
চ্যাট-স্টাইলের ফিচার প্রম্পটগুলি কথোপকথনের মতো পড়ায় পরিষ্কার মনে হয়। কিন্তু সাধারণত তারা কয়েকটি বন্ধুসুলভ বাক্যে অপশন, নিয়ম এবং ব্যতিক্রম মিশিয়ে দেয়। ফাঁকগুলো তখনই বেরিয়ে আসে যখন কেউ ফিচারটি বাস্তবে ব্যবহার করে।
বেশিরভাগ প্রম্পট নীরবে অনুমানের উপর নির্ভর করে: কে এই অ্যাকশনটি করতে পারবে, “সাফল্য” কী মানে (সংরক্ষিত, পাঠানো, প্রকাশিত, পেইড), ডেটা অনুপস্থিত হলে কী হবে, এবং কিছু ব্যর্থ হলে ব্যবহারকারী কী দেখতে পাবেন। এছাড়া অস্পষ্ট মানদণ্ডগুলোও লুকিয়ে থাকে, যেমন “পর্যাপ্ত দ্রুত” বা “পর্যাপ্ত সিকিউর” মানে কি।
অস্পষ্টতা সাধারণত পরে বাগ ও রিকোড হিসেবে প্রকাশ পায়। একজন ডেভেলপার যা ভাববে প্রম্পটটা ঠিক তা বানিয়ে ফেলবে, একজন রিভিউয়ার অনুমোদন করে দেবে কারণ তা ঠিক দেখাচ্ছে, এবং তারপর ব্যবহারকারীরা অদ্ভুত কেসগুলোতে আঘাত পাবে: ডুপ্লিকেট সাবমিশন, টাইমজোন ইস্যু, আংশিক ডেটা, বা পারমিশন মিসম্যাচ। পরে এইগুলো ঠিক করা বেশি খরচ করে কারণ প্রায়ই কোড, UI টেক্সট, এবং কখনও কখনও ডেটা মডেলও স্পর্শ করতে হয়।
গুণমানের জন্য বিশাল টেস্ট সুইট দরকার হয় না। এর মানে হলো আপনি স্বাভাবিক ব্যবহারে এবং পূর্বানুমিত চাপের নিচে ফিচারটিকে বিশ্বাস করতে পারবেন। কিছু ভালভাবে নির্বাচিত দৃশ্যপট আপনাকে সেই বিশ্বাস দেয়, শতাধিক টেস্ট ছাড়াই।
প্রম্পট-নির্মিত ফিচারের জন্য গুণমানের একটি বাস্তবসম্মত সংজ্ঞা:
এটিই প্রম্পটকে গ্রহণযোগ্য দৃশ্যপটে রূপান্তর করার উদ্দেশ্য: একটি অস্পষ্ট অনুরোধকে ৫–১০টি চেক-এ বদলে ফেলা যা লুকানো নিয়মগুলোকে আগেভাগেই প্রকাশ করে। আপনি সবকিছু পরীক্ষা করতে চাইছেন না। আপনি সেই ব্যর্থতাগুলো ধরতে চাইছেন যা প্রকৃতপক্ষে ঘটে।
যদি আপনি Koder.ai-এর মতো দ্রুত প্রম্পট-ভিত্তিক টুলে একটি তাড়াহুড়োপূর্ণ প্রম্পট থেকে শুরু করে থাকেন, আউটপুট সম্পূর্ণ মনে হতে পারে কিন্তু এজ রুলগুলো ছেড়ে দিতে পারে। একটি কড়া দৃশ্যপট সেট সেই নিয়মগুলোকে নাম দিতে বাধ্য করে যখন পরিবর্তনগুলো এখনও সস্তায় করা যায়।
একটি গ্রহণযোগ্য টেস্ট দৃশ্যপট হলো ব্যবহারকারীর একটি সংক্ষিপ্ত, সাধারণ ভাষার বর্ণনা যে তারা কী করে এবং কী ফলাফল তারা দেখতে পারবে।
পৃষ্ঠে থাকুন: ব্যবহারকারী কী করতে পারে, এবং প্রোডাক্ট কী দেখায় বা পরিবর্তন করে। ডেটা-বেস টেবিল, API কল, ব্যাকগ্রাউন্ড জব, বা কোন ফ্রেমওয়ার্ক ব্যবহার হচ্ছে—এর মতো অভ্যন্তরীণ বিবরণগুলি এড়িয়ে চলুন। এই বিবরণগুলো পরে গুরুত্বপূর্ণ হতে পারে, তবে সেগুলো দৃশ্যপটকে ভঙ্গুর করে এবং অ্যাগ্রী করতে কঠিন করে তোলে।
একটি ভাল দৃশ্যপটও স্বাধীন হওয়া উচিত। এটি আগামীকাল একটি ক্লিন পরিবেশে সহজে চালানো যাবে, অন্য কোনো দৃশ্যপট চালানোর ওপর নির্ভর না করেই। যদি একটি দৃশ্যপট পূর্বস্থিতির উপর নির্ভর করে, সেটি সাফভাবে সেটআপে বলুন (উদাহরণ: “ব্যবহারকারীর ইতোমধ্যে একটি সক্রিয় সাবস্ক্রিপশন আছে”)।
অনেক দল Given–When–Then ব্যবহার করে কারণ এটি স্পষ্টতা জোর দেয়, দৃশ্যপটকে পূর্ণ স্পেসিফিকেশনে পরিণত না করেই।
একটি দৃশ্যপট সাধারণত তখন “ডান” ধরা হয় যখন এর একটি লক্ষ্য, একটি পরিষ্কার শুরু অবস্থা, একটি কংক্রিট অ্যাকশন, এবং একটি দৃশ্যমান ফলাফল থাকে। এটি বাইনারি হওয়া উচিত: দলের কেউই চালানোর পরে “পাস” বা “ফেইল” বলতে পারবে।
উদাহরণ: “Given একটি সাইন-ইন করা ব্যবহারকারী যার কোন সেভ করা পেমেন্ট মেথড নেই, when তারা Pro নির্বাচন করে এবং পেমেন্ট কনফার্ম করে, then তারা একটি সফলতা বার্তাটি দেখতে পায় এবং অ্যাকাউন্টে প্ল্যানটি Pro হিসেবে দেখা যায়।”
যদি আপনি Koder.ai-এর মতো চ্যাট-ফার্স্ট বিল্ডারে তৈরি করে থাকেন, একই নিয়ম রাখুন: জেনারেট করা অ্যাপের আচরণ (ব্যবহারকারী কী অভিজ্ঞতা পায়) পরীক্ষা করুন, প্ল্যাটফর্ম কীভাবে কোড তৈরি করেছে তা নয়।
সবচেয়ে ভালো ফরম্যাট হল যেটি মানুষ লিখবে এবং পড়বে। যদি দলের অর্ধেক লম্বা বর্ণনা ব্যবহার করে এবং অন্য অর্ধেক সংক্ষিপ্ত বুলেটসে লেখে, তাহলে আপনি গ্যাপ, ডুপ্লিকেট এবং শব্দচর্চা নিয়ে জ্বালাও-পোড়া নিয়ে পড়বেন, গুণমান সম্পর্কে নয়।
Given–When–Then ভালো কাজ করে যখন ফিচার ইন্টারঅ্যাকটিভ এবং স্টেটফুল। একটি সরল টেবিল ভালো কাজ করে যখন আপনার ইনপুট-আউটপুট রুল অনেক এবং একই ধরনের।
যদি আপনার দল বিভক্ত থাকে, ৩০ দিন ধরে একটি ফরম্যাট বেছে নিন এবং পরে সামঞ্জস্য করুন। যদি রিভিউয়াররা বারবার “সাফল্য কি বলছে?” জিজ্ঞেস করে, সেটি সাধারণত Given–When–Then-এর দিকে যাওয়ার সংকেত। যদি দৃশ্যপটগুলো দৈর্ঘ্য বাড়ছে, একটি টেবিল দ্রুত স্ক্যান করা সহজ করে।
আপনি যা নির্বাচন করেন, সেটিকে স্ট্যান্ডার্ড করুন। একই শিরোনাম, একই টেন্স, এবং একই স্তরের বিবরণ রাখুন। এছাড়া কি রাখা হবে না তাও সম্মত হন: পিক্সেল-পারফেক্ট UI ডিটেইল, ইমপ্লিমেন্টেশন, এবং ডেটাবেস কথোপকথন। দৃশ্যপটগুলো ব্যবহারকারী কী দেখে এবং সিস্টেম কী গ্যারান্টি দেয় তা বর্ণনা করা উচিত।
দৃশ্যপটগুলো রাখুন যেখানে কাজ ইতিমধ্যেই হচ্ছে এবং ফিচারের কাছাকাছি রাখুন।
সাধারণ অপশনগুলোর মধ্যে আছে: প্রোডাক্ট কোডের পাশেই রাখানো, টিকিটে “Acceptance scenarios” সেকশনে রাখা, বা প্রতিটি ফিচারের জন্য শেয়ার করা ডক স্পেসে একটি পৃষ্ঠা রাখা। যদি আপনি Koder.ai ব্যবহার করেন, Planning Mode-এ দৃশ্যপট রাখলেও পারেন যাতে সেগুলো বিল্ড ইতিহাসের সাথে স্ন্যাপশট এবং রোলব্যাক পয়েন্টের পাশে থাকে।
কী গুরুত্বপূর্ণ তা হলো: সেগুলো সার্চযোগ্য করা, একটি সোর্স অফ ট্রুথ রাখা, এবং ডেভেলপমেন্ট শুরু হওয়ার আগে দৃশ্যপট থাকা বাধ্যতামূলক করা।
প্রথমে প্রম্পটকে পুনরায় লিখুন একটি ব্যবহারকারীর লক্ষ্য এবং একটি পরিষ্কার ফিনিশ লাইনে। একটি বাক্য ব্যবহার করে লক্ষ্য (কে কি চায়), তারপর ২–৪টি সাফল্য মানদণ্ড যেগুলো আপনি ঝামেলা ছাড়াই যাচাই করতে পারবেন। যদি আপনি কোনও দৃশ্যমান আউটকাম নির্দেশ করতে না পারেন, তাহলে আপনার কাছে এখনও একটি টেস্ট নেই।
পরবর্তী ধাপে প্রম্পটকে ইনপুট, আউটপুট, এবং নিয়মে ভাঙ্গুন। ইনপুট হলো ব্যবহারকারী যা দেয় বা নির্বাচন করে। আউটপুট হলো সিস্টেম যা দেখায়, সংরক্ষণ করে, পাঠায়, বা ব্লক করে। নিয়মগুলো হলো লাইনে লুকানো “শুধুমাত্র যদি” এবং “অবশ্যই” বিবৃতিগুলো।
তারপর দেখুন ফিচারটি কাজ করার আগে কি কি উপরে নির্ভরশীল। এখানেই দৃশ্যপটের ফাঁক লুকিয়ে থাকে: প্রয়োজনীয় ডেটা, ব্যবহারকারী ভূমি, পারমিশন, ইন্টিগ্রেশন, এবং সিস্টেম অবস্থা। উদাহরণস্বরূপ, যদি আপনি Koder.ai-এ একটি অ্যাপ তৈরি করছেন, উল্লিখিত করুন ব্যবহারকারীকে লগইন করতে হবে কি না, কোনো প্রজেক্ট তৈরি থাকতে হবে কি না, বা কোনো প্ল্যান/অ্যাক্সেস শর্ত পূরণ করতে হবে কি না।
এখন সেই ছোট সেটের দৃশ্যপটগুলো লিখুন যা প্রমাণ করবে ফিচারটি কাজ করে: সাধারণত ১–২টি হ্যাপি-পাথ, তারপর ৪–৮টি এজ কেস। প্রতিটি দৃশ্যপটকে একটি কারণে ব্যর্থ হওয়ার দিকে ফোকাস রাখুন।
ভাল এজ কেসগুলো বাছাই করার উদাহরণ (শুধুমাত্র প্রম্পটের সাথে মিলিয়ে যা ফিট করে): ইনপুট অনুপস্থিত বা অবৈধ, পারমিশন মিসম্যাচ, স্টেট কনফ্লিক্ট যেমন “ইতিমধ্যেই সাবমিট করা”, বাহ্যিক নির্ভরশীলতার সমস্যা যেমন টাইমআউট, এবং পুনরুদ্ধার আচরণ (স্পষ্ট ত্রুটি, নিরাপদ রিট্রাই, কোনো আংশিক সেভ নেই)।
শেষ করুন একটি দ্রুত “কি ভুল হতে পারে?” পাস দিয়ে। নীরব ব্যর্থতা, বিভ্রান্তিকর মেসেজ, এবং যেখানে সিস্টেম ভুল ডেটা তৈরি করতে পারে সেগুলো খুঁজুন।
একটি হ্যাপি-পাথ দৃশ্যপট হলো সংক্ষিপ্ত, সবচেয়ে সাধারণ রুট যেখানে সব কিছু ঠিকঠাক চলে। ইচ্ছাকৃতভাবে এটিকে সাধারণ রাখলে এটি একটি নির্ভরযোগ্য বেসলাইন হয়ে ওঠে যা পরে এজ কেসগুলোকে সহজে চিহ্নিত করে।
ডিফল্ট ব্যবহারকারী এবং ডিফল্ট ডেটা নাম দিন। বাস্তব ভূমি ব্যবহার করুন, “User” না বলেই: “Signed-in customer with a verified email” বা “Admin with permission to edit billing”। তারপর সবচেয়ে ছোট নমুনা ডেটা নির্ধারণ করুন: একটি প্রজেক্ট, তালিকার একটি আইটেম, একটি সেভ করা পেমেন্ট মেথড। এতে দৃশ্যপটগুলো কংক্রিট হয় এবং লুকানো অনুমান কমে।
প্রথমে সবচেয়ে সংক্ষিপ্ত সফল পথ লিখুন। অপশনাল ধাপ এবং বিকল্প ফ্লো বাদ দিন। উদাহরণ: যদি ফিচারটি “Create a task”, হ্যাপি-পাথে সৃষ্টি করার পর ফিল্টারিং, সোর্টিং, বা এডিট করা থাকা উচিত না।
টাইট রাখতে একটি সহজ উপায় হলো চারটি বিষয় নিশ্চিত করা:
তারপর একটি ভেরিয়েন্ট যোগ করুন যা কেবল একটি ভেরিয়েবল পরিবর্তন করে। সেই ভেরিয়েবলটি বেছে নিন যেটি পরে ভাঙার সম্ভাবনা বেশি, যেমন “টাইটেল লম্বা” বা “ব্যবহারকারীর পূর্বে কোনো আইটেম নেই”, এবং সবকিছু অপরিবর্তিত রাখুন।
উদাহরণ: যদি আপনার প্রম্পট বলে, “সংরক্ষণ করার পর একটি ‘Snapshot created’ টোস্ট দেখান,” হ্যাপি-পাথ হবে: ব্যবহারকারী Create Snapshot ক্লিক করে, লোডিং স্টেট দেখেন, “Snapshot created” পেয়ে যায়, এবং তালিকায় স্ন্যাপশটটি সঠিক টাইমস্ট্যাম্পসহ প্রদর্শিত হয়। একটি ভেরিয়েবল ভ্যারিয়েন্ট হতে পারে একই ধাপগুলো কিন্তু নাম ফাঁকা থাকলে ডিফল্ট নামকরণ নীতির স্বচ্ছ ব্যাখ্যা থাকে।
এজ কেসগুলোতেই বেশি বাগ লুকিয়ে থাকে, এবং আপনাকে বিশাল সুইট দরকার নেই। প্রতিটি ফিচার প্রম্পটের জন্য এমন একটি ছোট সেট বেছে নিন যা বাস্তব আচরণ এবং বাস্তব ব্যর্থতার মোডকে প্রতিফলিত করে।
সাধারণ ক্যাটেগরিগুলো:
প্রতিটি ফিচারের জন্য সব ক্যাটেগরি দরকার নেই। একটি সার্চ বক্স ইনপুটকে বেশি গুরুত্ব দেয়; একটি পেমেন্ট ফ্লো ইন্টিগ্রেশন ও ডেটা সমস্যাকে বেশি গুরুত্ব দেয়।
ঝুঁকি অনুযায়ী এজ কেস বেছে নিন: ব্যর্থতার উচ্চ খরচ (টাকা, সিকিউরিটি, প্রাইভেসি), ঘনঘন হওয়া, সহজে ভাঙা ফ্লো, পূর্বের বাগ ইত্যাদি।
উদাহরণ: “ব্যবহারকারী সাবস্ক্রিপশন প্ল্যান পরিবর্তন করে” জন্য সাধারণভাবে মূল্যবান দৃশ্যপটগুলো হতে পারে: চেকআউটের সময় সেশন এক্সপায়ার হওয়া, Confirm-এ ডাবল-ক্লিক করা, এবং পেমেন্ট প্রোভাইডার টাইমআউট যা প্ল্যান পরিবর্তন করে না কিন্তু স্পষ্ট বার্তা দেখায়।
উদাহরণ ফিচার প্রম্পট (সরল ভাষায়):
"যখন কিছু ভেঙে যায়, আমি চাই আমার অ্যাপকে একটি পূর্ববর্তী স্ন্যাপশটে রোলব্যাক করতে যাতে শেষ কাজ করা সংস্করণ আবার লাইভ থাকে।"
নীচে একটি কম্প্যাক্ট দৃশ্যপট সেট দেওয়া হল। প্রতিটি দৃশ্যপট সংক্ষিপ্ত হলেও একটি আউটকাম নির্দিষ্ট করে।
S1 [Must-have] সর্বশেষ স্ন্যাপশটে রোলব্যাক করুন
Given আমি লগইন করা আছি এবং আমি অ্যাপটির মালিক
When আমি “Rollback” নির্বাচন করে কনফার্ম করি
Then অ্যাপটি পূর্ববর্তী স্ন্যাপশট ডেপ্লয় করে এবং অ্যাপ স্ট্যাটাসে নতুন ভার্সন active হিসেবে দেখায়
S2 [Must-have] নির্দিষ্ট একটি স্ন্যাপশটে রোলব্যাক করুন
Given আমি আমার অ্যাপের স্ন্যাপশট তালিকা দেখছি
When আমি স্ন্যাপশট “A” নির্বাচন করে রোলব্যাক কনফার্ম করি
Then স্ন্যাপশট “A” active ভার্সন হয়ে ওঠে এবং আমি দেখতে পারি এটা কবে তৈরি হয়েছিল
S3 [Must-have] অনুমতি নেই (auth)
Given আমি লগইন করা আছি কিন্তু এই অ্যাপে আমার অ্যাক্সেস নেই
When আমি রোলব্যাক করার চেষ্টা করি
Then আমি একটি অ্যাক্সেস ত্রুটি দেখি এবং কোন রোলব্যাক শুরু হয় না
S4 [Must-have] স্ন্যাপশট পাওয়া যায় না (validation)
Given একটি স্ন্যাপশট ID নেই (অথবা মুছে ফেলা হয়েছে)
When আমি সেটিতে রোলব্যাক করার চেষ্টা করি
Then আমি একটি স্পষ্ট “snapshot not found” বার্তা পাই
S5 [Must-have] ডাবল সাবমিট (ডুপ্লিকেট)
Given আমি দ্রুতবার “Confirm rollback” দুইবার ক্লিক করি
When দ্বিতীয় অনুরোধটি পাঠানো হয়
Then কেবল একটি রোলব্যাকই চলে এবং আমি একক ফলাফল দেখতে পাই
S6 [Must-have] ডেপ্লয়মেন্ট ব্যর্থতা (ফেইলিউর)
Given রোলব্যাক শুরু হয়েছে
When ডেপ্লয়মেন্ট ব্যর্থ হয়
Then বর্তমানে active ভার্সন লাইভ থাকে এবং ত্রুটি দেখানো হয়
S7 [Nice-to-have] টাইমআউট বা সংযোগ হারানো
Given আমার সংযোগ রোলব্যাক চলাকালীন ড্রপ করে
When আমি পেজ রিফ্রেশ করি
Then আমি দেখতে পারি রোলব্যাক এখনও চলছে নাকি শেষ হয়েছে
S8 [Nice-to-have] ইতিমধ্যেই সেই স্ন্যাপশটেই আছি
Given স্ন্যাপশট “A” ইতিমধ্যেই active
When আমি স্ন্যাপশট “A” তে রোলব্যাক করার চেষ্টা করি
Then আমাকে বলা হবে কিছুই বদলায়নি এবং কোন নতুন ডেপ্লয় শুরু হবে না
প্রতিটি দৃশ্যপট তিনটি প্রশ্নের উত্তর দেয়: কে এটি করছে, তারা কী করে, এবং পরে কী সত্য হওয়া উচিত।
লক্ষ্য “সবকিছু পরীক্ষা করা” নয়। লক্ষ্য হলো সেই ঝুঁকিগুলো কভার করা যেগুলো ব্যবহারকারীদের ক্ষতিগ্রস্ত করবে, এমনকি এমনভাবে যে কেউই চালায় না এমন দৃশ্যপটগুলো তৈরি না করে।
একটি বাস্তবিক কৌশল হলো দৃশ্যপটগুলোকে লেবেল করা কিভাবে আপনি এগুলো ব্যবহার করবেন বলে ভাবেন:
নিজেকে সীমাবদ্ধ করুন প্রতিটি আলাদা ঝুঁকির জন্য একটি দৃশ্যপট। যদি দুটি দৃশ্যপট একই কারণে ফেল করে, সম্ভবত আপনাকে একটি করেই হবে। “অবৈধ ইমেল ফরম্যাট” এবং “ইমেইল অনুপস্থিত” আলাদা ঝুঁকি। কিন্তু “Step 1-এ ইমেল অনুপস্থিত” এবং “Step 2-এ ইমেল অনুপস্থিত” একই ঝুঁকি হতে পারে যদি নিয়মটি একই হয়।
প্রচুর দৃশ্যপট জুড়ে একই UI ধাপগুলো বারবার করা এড়িয়ে চলুন। পুনরাবৃত্ত অংশগুলো সংক্ষিপ্ত রাখুন এবং যা বদলায় সেখানেই ফোকাস করুন। যখন আপনি চ্যাট-ভিত্তিক টুলে নির্মাণ করছেন (যেমন Koder.ai), UI বদলে যাওয়ার সময় ব্যবসায়িক নিয়ম অপরিবর্তিত থাকতে পারে—এর ফলে এটিই আরও গুরুত্বপূর্ণ।
শেষে, সিদ্ধান্ত নিন কোনগুলো এখন চেক করবেন বনাম পরে: কিছু চেক প্রথমে ম্যানুয়াল রাখাই ভালো, পরে অটোমেট করুন যখন ফিচার স্থিতিশীল হবে।
একটি দৃশ্যপট আপনাকে অপ্রত্যাশিততা থেকে রক্ষা করা উচিত, দলের নির্মাণ পরিকল্পনা বর্ণনা করা নয়।
সর্বাধিক সাধারণ ভুল হলো ব্যবহারকারীর লক্ষ্যকে একটি টেক চেকলিস্টে পরিণত করা। যদি দৃশ্যপট বলে “API returns 200” বা “table X-এ column Y আছে”, এটি একটি ডিজাইন-লক করে দেয় এবং তবু প্রমাণ করে না যে ব্যবহারকারী যা চেয়েছিল তা পেয়েছে।
আরেকটি সমস্যা হলো একাধিক লক্ষ্য একক দীর্ঘ দৃশ্যপটে একত্র করা। এটা একটি পূর্ণ জার্নি মনে হয়, কিন্তু ব্যর্থ হলে কেউ জানে না কেন ব্যর্থ হল। একটি দৃশ্যপটকে এক প্রশ্নের উত্তর দেতেই হবে।
ভান্দরকৃত এজ কেস থেকে সতর্ক থাকুন যা চমত্কার শোনালেও বাস্তবে নেই। “ব্যবহারকারীর ১০ মিলিয়ন প্রজেক্ট আছে” বা “নেটওয়ার্ক প্রতি ২ সেকেন্ডে ড্রপ করে” প্রায়ই প্রোডাকশনের সাথে মেলে না এবং পুনরুৎপাদন কঠিন। এমন এজ কেস বাছুন যা মিনিটে সেটআপ করা যায়।
ওপরন্তু, “কাজ করে”, “ত্রুটি নেই”, বা “সফলভাবে সম্পন্ন” মত অস্পষ্ট ফলাফলগুলি এড়ান—ওগুলো গোপন করে রাখে ঠিক কি যাচাই করতে হবে।
যদি আপনি Koder.ai-এর “export source code” ফিচারের মত কিছু তৈরি করেন, একটা দুর্বল দৃশ্যপট হবে: “When user clicks export, the system zips the repo and returns 200.” এটা ইমপ্লিমেন্টেশন পরীক্ষা করে, প্রমিস প্রমাণ করে না।
একটি ভালো দৃশ্যপট হবে: “Given একটি প্রজেক্টের দুইটি স্ন্যাপশট আছে, when ব্যবহারকারী export করে, then ডাউনলোডে বর্তমান স্ন্যাপশটের কোড থাকবে এবং এক্সপোর্ট লগে কারা কখন এক্সপোর্ট করেছে তা রেকর্ড হবে।”
“না” পথগুলো ভুলে যাওয়া যাবে না: “Given export পারমিশন নেই এমন ব্যবহারকারী, when তারা export করার চেষ্টা করে, then অপশনটি লুকানো বা ব্লক করা আছে, এবং কোন এক্সপোর্ট রেকর্ড তৈরি হয়নি।” এক লাইনে নিরাপত্তা ও ডেটা ইন্টিগ্রিটি—দুটোই রক্ষা পায়।
একটি দৃশ্যপট সেটকে “ডান” ধরবার আগে, এটি ব্যবহারকারী এবং ডেটাবেস-দৃষ্টিকোণ থেকে পড়ুন। যদি আপনি শুরু হওয়ার আগে কি সত্য হওয়া উচিত বা “সাফল্য” মানে কী বুঝে পাচ্ছেন না, তাহলে সেটি প্রস্তুত নয়।
একটি ভাল সেট ছোট কিন্তু নির্দিষ্ট। আপনি এটি এমন কারো হাতে দিতে পারবেন যে ফিচারটি লিখেনি এবং একই ফলাফল পাবেন।
এই দ্রুত পাসটি ব্যবহার করুন অনুমোদন (বা ফিরিয়ে দেওয়ার) জন্য:
যদি আপনি চ্যাট-ভিত্তিক বিল্ডারে দৃশ্যপট জেনারেট করে থাকেন (যেমন Koder.ai), একই মানক ধরুন: “works as expected” ধরনের অস্পষ্টতা গ্রহণ করবেন না। দৃশ্যমান আউটপুট ও সংরক্ষিত পরিবর্তনের জন্য অনুরোধ করুন, তারপর কেবল সেইগুলোই অনুমোদন করুন যেগুলো আপনি যাচাই করতে পারবেন।
দৃশ্যপট লেখাকে রক্ষা কাজের শেষে একটি ক্লিন-আপ টাস্ক হিসেবে নয়, বরং প্রকৃত ধাপ হিসেবে নির্ধারণ করুন।
বাস্তবায়ন শুরু হওয়ার আগে দৃশ্যপট লিখুন, যখন ফিচারটি এখনও সস্তা পরিবর্তন করা যায়। এটি দলের সদস্যদের পাগলপ্রশ্নগুলো আগে থেকেই উত্তর দিতে বাধ্য করে: “সাফল্য” মানে কী, খারাপ ইনপুটে কী হবে, এবং এখন কি সমর্থন করা হবে না।
দৃশ্যপটগুলোকে আপনার “ডান” সংজ্ঞা হিসেবে ব্যবহার করুন। Product উদ্দেশ্য own করে, QA ঝুঁকি চিন্তা own করে, এবং Engineering feasibility own করে। যখন তিন-পক্ষ একই দৃশ্যপট সেট পড়ে সম্মত হতে পারে, আপনি এমন কিছু শিপ করা এড়াবেন যা “সম্পন্ন” কিন্তু গ্রহণযোগ্য নয়।
একটি ওয়ার্কফ্লো যা বেশিরভাগ দলে টিকে যায়:
আপনি যদি Koder.ai (koder.ai) এ নির্মাণ করেন, প্রথমে দৃশ্যপট ড্রাফট করে Planning Mode-এ রেখলে প্রতিটি দৃশ্যপটকে স্ক্রীন, ডেটা নিয়ম, এবং ব্যবহারকারী-দৃশ্যমান আউটকামের সাথে মানচিত্র করা সহজ হয়, তারপরে কোড জেনারেট বা এডিট করা যায়।
ঝুঁকিপূর্ণ পরিবর্তনের জন্য, ইটারেশনের আগে একটি স্ন্যাপশট নিন। যদি কোনো নতুন এজ কেস কাজ করা ফ্লো ভেঙে দেয়, রোলব্যাক আপনাকে একটি দিন তাদের সাইড-ইফেক্ট সরিয়ে রাখতে সময় বাঁচাতে পারে।
দৃশ্যপটগুলোকে ফিচার রিকোয়েস্টের পাশে (অথবা একই টিকেটে) রাখুন এবং সেগুলোকে সংস্করণযোগ্য অনুরোধ হিসেবে আচরণ করুন। যখন প্রম্পটগুলো বিকশিত হয়, দৃশ্যপট সেটও একসাথে বিকশিত হওয়া উচিত, নইলে আপনার “ডান” ধীরে ধীরে বিচলিত হবে।
শুরু করুন একটি বাক্যে যেটা ব্যবহারকারীর লক্ষ্য এবং শেষ লাইনের কথা বলে।
তারপর প্রম্পটকে ভাঙ্গুন:
তারপর লিখুন ১–২টি হ্যাপি-পাথ এবং ৪–৮টি এজ কেস যেগুলো বাস্তব ঝুঁকির সাথে মেলে (পারমিশন, ডুপ্লিকেট, টাইমআউট, ডেটা অনুপস্থিতি)।
কারণ প্রম্পটে অনেক ধরণের অনুমান লুকিয়ে থাকে। একটি প্রম্পট বলে “সংরক্ষণ কর”, কিন্তু সেটা হতে পারে ড্রাফট বনাম প্রকাশিত — এটা স্পষ্ট না থাকে, ব্যর্থ হলে কী হবে বা কোন ব্যক্তি এটা করতে পারবে তাও নির্দিষ্ট থাকে না।
দৃশ্যপটগুলো আপনাকে শুরুতেই সেই নিয়মগুলো নাম দিতে বাধ্য করে, যাতে ডুপ্লিকেট সাবমিশন, পারমিশন মিসম্যাচ বা অসামঞ্জস্যপূর্ণ ফলাফল মতো বাগগুলি আগে থেকেই ধরা যায়।
যখন ফিচারে state এবং ইউজার ইন্টারঅ্যাকশন থাকে তখন Given–When–Then ব্যবহার করুন।
যখন আপনার কাছে অনেক একই রকম রুল চেক থাকে তখন একটি সরল ইনপুট/আউটপুট টেবিল ভালো কাজ করে।
এক মাসের জন্য একটি ফরম্যাট বেছে নিন এবং এটাকে স্ট্যান্ডার্ড করুন (একই টেন্স, একই বিশদ)। সবচেয়ে ভাল ফরম্যাট হল যা আপনার দল আসলেই ব্যবহার করবে।
একটি ভাল দৃশ্যপট:
এটি “পুরো” তখনই যখন কেউ এটি চালিয়ে একই ফলাফল পাবে এবং বিরোধ ছাড়াই সম্মত হবে।
দৃষ্টি নিবদ্ধ রাখুন দেখার যোগ্য আচরণ-এ:
বর্জন করুন ইমপ্লিমেন্টেশন ডিটেইল: ডেটাবেস টেবিল, API কোড, ব্যাকগ্রাউন্ড জব বা ফ্রেমওয়ার্কের কথা। এগুলো প্রায়ই বদলে যায় এবং ব্যবহারকারী পাবলিশড আউটকাম প্রমাণ করে না।
লেখুন সবচেয়ে সাধারণ, স্বাভাবিক পথটি যেখানে সবকিছু ঠিকঠাক হয়:
তারপর চারটি জিনিস নিশ্চিত করুন: সঠিক স্ক্রিন/স্টেট, স্পষ্ট সফল বার্তা, ডেটা সংরক্ষণ এবং ব্যবহারকারী পরবর্তী যুক্তিসঙ্গত কাজটি করতে পারে।
ঝুঁকি ও ঘনত্বের ভিত্তিতে বেছে নিন:
প্রতিটি আলাদা ঝুঁকির জন্য সাধারণত এক দৃশ্যপট রাখুন, সব ভ্যারিয়েশন নয়।
নিরাপদ ও পরিষ্কার রাখুন:
একটি ব্যর্থতা দৃশ্যপট প্রমাণ করবে সিস্টেম ডেটা নষ্ট করে না বা ব্যবহারকারীকে বিভ্রান্ত করে না।
Koder.ai-এ তৈরি করা আউটপুটকে অন্য কোনো অ্যাপের মতোই দেখুন: কিভাবে ব্যবহারকারী অভিজ্ঞতা দেখছে তা পরীক্ষা করুন, কি করে প্ল্যাটফর্ম কোড উত্পাদন করেছে তা নয়।
প্রায়োগিক দৃষ্টিভঙ্গি:
সেগুলিকে যেখানে কাজ হয় সেখানেই সংরক্ষণ করুন এবং একটি উৎস রাখুন:
Koder.ai ব্যবহার করলে Planning Mode-এ দৃশ্যপট রাখুন যাতে সেগুলো বিল্ডের ইতিহাসের সাথে যুক্ত থাকে। সবচেয়ে গুরুত্বপূর্ণ: ডেভেলপমেন্ট শুরু হওয়ার আগে দৃশ্যপট অবশ্যই থাকা চাই।