প্রম্পট থেকে গ্রহণযোগ্য টেস্ট: ফিচারগুলোকে দৃশ্যপটে পরিণত করুন

কেন ফিচার প্রম্পটগুলো অনিচ্ছাকৃতভাবে দাবিগুলো মিস করে

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

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

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

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

প্রম্পট-নির্মিত ফিচারের জন্য গুণমানের একটি বাস্তবসম্মত সংজ্ঞা:

• প্রধান ব্যবহারকারীর লক্ষ্য end-to-end কাজ করে (হ্যাপি পাথ)।
• প্রধান ব্যর্থতার মোডগুলো পরিষ্কারভাবে সামলানো আছে (স্পষ্ট ত্রুটি, নীরব ক্ষতি নেই)।
• ফিচার কনসিস্টেন্ট আচরণ করে (একই ইনপুট, একই আউটকাম)।
• ভুল করে কোনো বিপজ্জনক ঘটনা ঘটে না (ভুল-ব্যবহারকারীর অ্যাক্সেস, ডুপ্লিকেট অ্যাকশন)।

এটিই প্রম্পটকে গ্রহণযোগ্য দৃশ্যপটে রূপান্তর করার উদ্দেশ্য: একটি অস্পষ্ট অনুরোধকে ৫–১০টি চেক-এ বদলে ফেলা যা লুকানো নিয়মগুলোকে আগেভাগেই প্রকাশ করে। আপনি সবকিছু পরীক্ষা করতে চাইছেন না। আপনি সেই ব্যর্থতাগুলো ধরতে চাইছেন যা প্রকৃতপক্ষে ঘটে।

যদি আপনি 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-এ ডাবল-ক্লিক করা, এবং পেমেন্ট প্রোভাইডার টাইমআউট যা প্ল্যান পরিবর্তন করে না কিন্তু স্পষ্ট বার্তা দেখায়।

কাজ করা উদাহরণ: একটি ফিচার প্রম্পটকে টাইট দৃশ্যপট সেটে রূপান্তর

উদাহরণ ফিচার প্রম্পট (সরল ভাষায়):

"যখন কিছু ভেঙে যায়, আমি চাই আমার অ্যাপকে একটি পূর্ববর্তী স্ন্যাপশটে রোলব্যাক করতে যাতে শেষ কাজ করা সংস্করণ আবার লাইভ থাকে।"

নীচে একটি কম্প্যাক্ট দৃশ্যপট সেট দেওয়া হল। প্রতিটি দৃশ্যপট সংক্ষিপ্ত হলেও একটি আউটকাম নির্দিষ্ট করে।

হ্যাপি পাথ (2)

S1 [Must-have] সর্বশেষ স্ন্যাপশটে রোলব্যাক করুন

Given আমি লগইন করা আছি এবং আমি অ্যাপটির মালিক

When আমি “Rollback” নির্বাচন করে কনফার্ম করি

Then অ্যাপটি পূর্ববর্তী স্ন্যাপশট ডেপ্লয় করে এবং অ্যাপ স্ট্যাটাসে নতুন ভার্সন active হিসেবে দেখায়

S2 [Must-have] নির্দিষ্ট একটি স্ন্যাপশটে রোলব্যাক করুন

Given আমি আমার অ্যাপের স্ন্যাপশট তালিকা দেখছি

When আমি স্ন্যাপশট “A” নির্বাচন করে রোলব্যাক কনফার্ম করি

Then স্ন্যাপশট “A” active ভার্সন হয়ে ওঠে এবং আমি দেখতে পারি এটা কবে তৈরি হয়েছিল

এজ কেস (6)

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 আমাকে বলা হবে কিছুই বদলায়নি এবং কোন নতুন ডেপ্লয় শুরু হবে না

প্রতিটি দৃশ্যপট তিনটি প্রশ্নের উত্তর দেয়: কে এটি করছে, তারা কী করে, এবং পরে কী সত্য হওয়া উচিত।

কিভাবে কভারেজ বেশি রাখবেন এবং সুইটগুলো ছোট রাখবেন

লক্ষ্য “সবকিছু পরীক্ষা করা” নয়। লক্ষ্য হলো সেই ঝুঁকিগুলো কভার করা যেগুলো ব্যবহারকারীদের ক্ষতিগ্রস্ত করবে, এমনকি এমনভাবে যে কেউই চালায় না এমন দৃশ্যপটগুলো তৈরি না করে।

একটি বাস্তবিক কৌশল হলো দৃশ্যপটগুলোকে লেবেল করা কিভাবে আপনি এগুলো ব্যবহার করবেন বলে ভাবেন:

• Smoke: ১–২টি দৃশ্যপট যা প্রমাণ করে ফিচার end-to-end কাজ করে।
• Regression: ২–৬টি দৃশ্যপট গুরুত্বপূর্ণ নিয়ম ও পূর্ব বাগের জন্য।
• Exploratory: কয়েকটি “এগুলো চেষ্টা করুন” পরীক্ষা অদ্ভুত কেস ও UX বিচারবোধের জন্য।

নিজেকে সীমাবদ্ধ করুন প্রতিটি আলাদা ঝুঁকির জন্য একটি দৃশ্যপট। যদি দুটি দৃশ্যপট একই কারণে ফেল করে, সম্ভবত আপনাকে একটি করেই হবে। “অবৈধ ইমেল ফরম্যাট” এবং “ইমেইল অনুপস্থিত” আলাদা ঝুঁকি। কিন্তু “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-এ রেখলে প্রতিটি দৃশ্যপটকে স্ক্রীন, ডেটা নিয়ম, এবং ব্যবহারকারী-দৃশ্যমান আউটকামের সাথে মানচিত্র করা সহজ হয়, তারপরে কোড জেনারেট বা এডিট করা যায়।

ঝুঁকিপূর্ণ পরিবর্তনের জন্য, ইটারেশনের আগে একটি স্ন্যাপশট নিন। যদি কোনো নতুন এজ কেস কাজ করা ফ্লো ভেঙে দেয়, রোলব্যাক আপনাকে একটি দিন তাদের সাইড-ইফেক্ট সরিয়ে রাখতে সময় বাঁচাতে পারে।

দৃশ্যপটগুলোকে ফিচার রিকোয়েস্টের পাশে (অথবা একই টিকেটে) রাখুন এবং সেগুলোকে সংস্করণযোগ্য অনুরোধ হিসেবে আচরণ করুন। যখন প্রম্পটগুলো বিকশিত হয়, দৃশ্যপট সেটও একসাথে বিকশিত হওয়া উচিত, নইলে আপনার “ডান” ধীরে ধীরে বিচলিত হবে।