অ-টেকনিকাল টিমের জন্য ৩০ মিনিটে প্রি-লঞ্চ টেস্ট প্ল্যান

কেন একটি সংক্ষিপ্ত প্রি-লঞ্চ টেস্ট পরে কষ্ট বাঁচায়

বেশিরভাগ লঞ্চ বাগ গভীর প্রযুক্তিগত ত্রুটি নয়। এগুলো ছোট ছোট ফাঁক যা কেবল যখন কেউ অ্যাপটি বাস্তব গ্রাহকের মতো ব্যবহার করে তখনই দেখা যায়। নির্মাতা প্রায়ই পারফেক্ট ডেটা, অ্যাডমিন অ্যাকাউন্ট এবং সিস্টেম কিভাবে কাজ করা উচিত তার একটি স্পষ্ট মানসিক মডেলের সঙ্গে পরীক্ষা করে। বাস্তব ব্যবহারকারীরা তা করে না। এর ফলে ভাঙা পারমিশন, অস্পষ্ট এরর মেসেজ বা মোবাইলে এমন একটি বোতাম যা কিছুই করে না—এগুলো দেখা যায়।

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

একটি সংক্ষিপ্ত প্রি-লঞ্চ টেস্ট প্ল্যান ওই মুহূর্তগুলোকে টার্গেট করে। ৩০ মিনিটে আপনি পুরো সিস্টেম নিখুঁত প্রমাণ করছেন না। আপনি সেই সমস্যা ধরছেন যেগুলো প্রথম দিনেই সাপোর্ট টিকেট, রিফান্ড এবং চাঁর্ন সৃষ্টি করে।

এই দ্রুত পাসটি মূল যাত্রাপথ end-to-end যাচাই করার, একটি ফোন ও একটি ডেস্কটপ পরীক্ষা করার, মূল মেসেজগুলো পৌঁছায় এবং বিশ্বাসযোগ্য দেখায় কিনা নিশ্চিত করার, এবং বিভ্রান্তিকর কপি, অনুপস্থিত লোডিং স্টেট এবং ডেড এন্ড খুঁজে বের করার জন্য বেশ ভালো। এটি লোড টেস্টিং, গভীর সিকিউরিটি টেস্টিং, বা প্রতিটি এজ কেস কভার করবে না—সেগুলো আলাদা কাজে লাগবে।

সেরা ব্যক্তি এই পরীক্ষা চালাবেন এমন কেউ যিনি বিল্ড টিমের বাইরে: অপারেশনস, সাপোর্ট বা একটি প্রোডাক্ট ম্যানেজার। আপনি যদি AppMaster-এর মতো নো-কোড টুলে তৈরি করে থাকেন, অ-টেকনিকাল স্টাফদের জন্য গ্রাহকের মতোই ফ্লো মেনে চলা আরও সহজ হয়। প্রতিটি রিলিজের আগে এটি চালান, এমনকি ছোটগুলোও, কারণ ছোট পরিবর্তনগুলো বড় মুহূর্তগুলো ভাঙ্গে।

সেটআপ: অ্যাকাউন্ট, টেস্ট ডেটা, ডিভাইস, এবং কঠোর টাইমবক্স

৩০-মিনিটের পরীক্ষা কাজ করবে যদি আপনি আগে থেকেই মৌলিক প্রস্তুতি নেন। লক্ষ্য ব্যাপকতা নয়। লক্ষ্য হলো ফোকাস।

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

টাইমার শুরু করার আগে এগুলো প্রস্তুত রাখুন:

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

টাইমবক্স ঠিক করুন যাতে এটি “আরেকটি জিনিস” হয়ে না ওঠে। একটি সহজ বিভাজন যা কার্যকর:

• ৫ মিনিট: যাত্রাপথ, অ্যাকাউন্ট এবং ডিভাইস নিশ্চিত করা
• ২০ মিনিট: বাধাহীনভাবে ওয়াকথ্রু চালানো
• ৫ মিনিট: সমস্যা লিখে কী লঞ্চ ব্লক করে তা নির্ধারণ করা

আপনি যদি AppMaster ব্যবহার করে থাকেন, টেস্ট ইউজারগুলো আগে থেকে সেট করুন, আপনার Stripe মডিউলটি প্রত্যাশিত মোডে আছে কিনা (test বা live) নিশ্চিত করুন, এবং ইমেইল/SMS/Telegram নোটিফিকেশন নিরাপদ টেস্ট রিসিপিয়েন্টের দিকে নির্দেশ করান। টাইমার শুরু হলে আপনাকে অভিজ্ঞতা পরীক্ষা করতে হবে, না ক্রেডেনশিয়াল খোঁজ করতে।

ধাপে ধাপে: ৩০-মিনিট ওয়াকথ্রু

টাইমার সেট করুন। একটি সাধারণ ইউজার অ্যাকাউন্ট ব্যবহার করুন (অ্যাডমিন নয়)। যা কিছু বিভ্রান্তিকর লাগে তা লিখে রাখুন, এমনকি যদি তা প্রযুক্তিগতভাবে কাজ করে।

একটি বাস্তবসম্মত যাত্রাপথ end to end চালান: অ্যাপ খুলুন, সাইন ইন করুন, কিছু তৈরি করুন, পে করুন (যদি প্রাসঙ্গিক), এবং নিশ্চিত করুন আপনি সঠিক মেসেজ পেয়েছেন। যে পরিবেশে আপনার ব্যবহারকারীরা লঞ্চে প্রবেশ করবে সেটিই ব্যবহার করুন, কোনো স্পেশাল প্রিভিউ না।

এই সময় বিভাজনকে গাইড হিসেবে ব্যবহার করুন:

• প্রথম ৩ মিনিট: নিশ্চিত করুন অ্যাপ লোড হয়, মূল পেজগুলো খোলে, এবং লেআউট স্পষ্টভাবে ভেঙে নেই।
• পরের ৭ মিনিট: দুইটি পার্সোনার মতো অ্যাক্সেস পরীক্ষা করুন (নতুন ব্যবহারকারী ও রিটার্নিং ব্যবহারকারী)। চেক করুন সাইন আপ, সাইন ইন, লগ আউট এবং ফর্গট পাসওয়ার্ড।
• পরের ৮ মিনিট: একটি গুরুত্বপূর্ণ ফর্ম পূরণ করুন। সেভ, এডিট, রিফ্রেশ করে নিশ্চিত করুন পরিবর্তনটি সত্যিই স্থায়ী হয়েছে।
• পরের ৭ মিনিট: একটি পেমেন্ট শুরু থেকে শেষ করুন। নিশ্চিত করুন অ্যাপ-এ “paid” স্ট্যাটাস আপডেট হয়েছে এবং গ্রাহক স্পষ্ট প্রমাণ দেখে।
• শেষ ৫ মিনিট: নোটিফিকেশন ট্রিগার করুন এবং ডেলিভারি যাচাই করুন। আপনি যা আশা করেছিলেন বনাম যা ঘটেছে তা ক্যাপচার করুন।

যদি কোনো টিমমেট সাহায্য না নিয়ে যাত্রা শেষ করতে না পারে, এটাকে লঞ্চ বাগ হিসেবে গণ্য করুন। উদ্দেশ্য হলো আপনার প্রথম গ্রাহকদের টেস্টার বানানো এড়ানো।

লগইন ও অ্যাক্সেস চেক (দ্রুত, কিন্তু ঢিলেমলে নয়)

লঞ্চ-ডে সমস্যাগুলো প্রায়ই সামনে দরজা থেকে শুরু হয়। যদি মানুষ সাইন ইন করতে না পারে, বাকিটা বীক্ষণ করার কিছুই থাকে না।

একটি পরিষ্কার লগইন দিয়ে শুরু করুন সাধারণ একটি টেস্ট অ্যাকাউন্ট ব্যবহার করে যা গ্রাহকের মতো দেখায়। আপনি যদি SSO (Google, Microsoft, Okta) সমর্থন করেন, একবার SSO সাইন-ইনও করে নিন। সামান্য কনফিগারেশন পরিবর্তনের পর এই ফ্লোগুলো আশ্চর্যজনকভাবে ব্যর্থ হয়।

এগুলো অর্ডার অনুযায়ী চালান:

• সঠিক ইমেইল ও পাসওয়ার্ড দিয়ে সাইন ইন করুন, রিফ্রেশ করুন এবং নিশ্চিত করুন আপনি এখনও সাইন ইন আছেন।
• ভুল পাসওয়ার্ড একবার প্রবেশ করান এবং নিশ্চিত করুন মেসেজটি স্পষ্ট ও সহায়ক।
• ফর্গট পাসওয়ার্ড শেষ পর্যন্ত সম্পন্ন করুন: ইমেইল আসে, লিঙ্ক খুলে নতুন পাসওয়ার্ড কাজ করে।
• লগ আউট করুন, তারপর আবার সাইন ইন করুন। যদি “Remember me” অফার করে থাকে, উভয় স্টেট পরীক্ষা করুন।
• একটি অ্যাডমিন-অনলি পেজ একটি সাধারণ ব্যবহারকারী হিসেবে খুলতে চেষ্টা করুন এবং নিশ্চিত হন আপনি বন্ধ বা একটি বন্ধুসুলভ বার্তা/রিডাইরেক্ট পাচ্ছেন।

টিকিট তৈরি করে এমন ডিটেইলগুলোর দিকে মনোযোগ দিন। রিসেট ইমেইল কি এক মিনিটের মধ্যে আসে? রিসেট লিংক কি প্রাইভেট উইন্ডোতে সাফভাবে খোলে? লগ আউট করার পরে কি ব্যাক বাটন ব্যবহার করেও প্রাইভেট স্ক্রিন দেখা যায়?

আপনি যদি AppMaster-এ তৈরি করে থাকেন, এটি একই সময়ে নিশ্চিত করার ভাল সময় যে আপনার অথেনটিকেশন সেটআপ এবং রোল নিয়মগুলি আপনি যা আশা করেন তার সঙ্গে মিলছে।

ফর্ম: ভ্যালিডেশন, সেভিং, এবং ব্যবহারকারীরা বুঝতে পারার মতো এরর মেসেজ

ফর্মগুলো ছোটখাট সমস্যা থেকে হারানো সাইনআপ এবং সাপোর্ট কাজের সৃষ্টি করে।

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

এরপর বাস্তবসম্মত উপায়ে ফর্ম ভেঙে দেখতে চেষ্টা করুন। আপনার লক্ষ্য “হ্যাক” করা নয়। আপনি পরীক্ষা করছেন যে অ্যাপটি একজন সাধারণ মানুষকে কীভাবে পুনরুদ্ধার করতে সাহায্য করে।

একটি দ্রুত ফর্ম চেক লিস্ট:

• একটি অনিবার্য ফিল্ড ফাঁকা রেখে জমা করুন। এররটি ফিল্ডের কাছাকাছি দেখা উচিত এবং কি করতে হবে তা ব্যাখ্যা করা উচিত।
• ভুল ফরম্যাট ঢোকান (e-mail এ @ নেই, ফোনে অক্ষর) এবং নিশ্চিত করুন এটি ধরা পড়ে।
• অতিরিক্ত স্পেস যোগ করুন (যেমন " Jane ") এবং নিশ্চিত করুন সেভ করা মান পরিষ্কার দেখায়।
• আপলোডের ক্ষেত্রে খুব বড় ফাইল এবং ভুল টাইপ চেষ্টা করুন। মেসেজে কি কী অনুমোদিত তা বলা আছে।
• দ্রুত দুইবার সাবমিট ক্লিক করুন। আপনার নকল তৈরি হওয়া উচিত নয়।

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

পেমেন্ট: অর্থ প্রবাহ এবং গ্রাহক প্রমাণ নিশ্চিত করুন

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

একটি ক্রয় শুরু থেকে শেষ করুন: একটি প্ল্যান বেছে নিন (বা কার্টে যোগ করুন), চেকআউট সম্পন্ন করুন, স্পষ্ট কনফার্মেশন স্ক্রিনে পৌঁছান। এমন একটি মূল্য বেছে নিন যা সহজেই চিহ্নিত করা যায় যাতে ভুলগুলো স্পষ্ট হয়।

গ্রাহকরা যা চেক করে তা পরীক্ষা করুন: পরিমাণ, মুদ্রা, ট্যাক্স, এবং ডিসকাউন্ট। তারপর আপনার টিম যা নির্ভর করে তা চেক করুন: অভ্যন্তরীণ স্ট্যাটাস এবং পেমেন্ট প্রোভাইডারের স্ট্যাটাস একে অপরের সঙ্গে মিলতে হবে।

সর্বনিম্ন পেমেন্ট চেক:

• মোট এবং মুদ্রা সঠিক
• পেমেন্ট সফল হওয়ার পরেই অর্ডারটি "paid" দেখায়
• ব্যর্থতা হলে স্পষ্ট মেসেজ এবং নিরাপদ পুনরায় চেষ্টা পথ থাকে
• রিফান্ড (আপনি যদি সাপোর্ট করে থাকেন) অর্ডার ও গ্রাহক রেকর্ড আপডেট করে

উদ্দেশ্যমূলকভাবে একটি ব্যর্থতা পরীক্ষা করুন একটি পরিচিত ফেইলিং টেস্ট কার্ড বা বাতিল করা পেমেন্ট ব্যবহার করে। নিশ্চিত করুন অর্ডারটি paid হিসেবে চিহ্নিত হয়নি, মেসেজ বুঝতে সুবিধাজনক, এবং পুনরায় চেষ্টা ডুপ্লিকেট তৈরি করে না।

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

নোটিফিকেশন: ইমেইল, SMS এবং পুশ চেক

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

প্রতিটি মেসেজ ট্রিগার করুন সেভাবে যেভাবে একটি বাস্তব গ্রাহক এটি করবে। অ্যাডমিন-অনলি শর্টকাট থেকে টেস্ট মেসেজ পাঠানো এড়িয়ে চলুন যদি গ্রাহকরা সেই একই পথ ব্যবহার না করে।

প্রতিটি মেসেজের জন্য যাচাই করুন:

• সময়: এটি দ্রুত এবং ধারাবাহিকভাবে পৌঁছায়
• ট্রাস্ট সিগন্যাল: প্রেরক নাম, প্রেরক ঠিকানা/নম্বর, সাবজেক্ট এবং প্রিভিউ টেক্সট ঠিক আছে
• বিষয়বস্তু: এটি সাম্প্রতিক ঘটনার সাথে মিলছে এবং সঠিক নাম ও অর্ডার বিবরণ ব্যবহার করছে
• লিংক: বোতামগুলি সঠিক স্ক্রিন খুলে এবং লগআউট অবস্থায় ও কাজ করে

একটি লিঙ্ক ক্লিক করার পর, প্রাইভেট উইন্ডোতে পুনরায় পরীক্ষা করুন। অনেক টিম মিস করে যে একটি ম্যাজিক লিংক বা রিসেট লিংক তখনই কাজ করে যদি আপনি ইতিমধ্যেই সাইন ইন করে থাকেন।

স্টাফ নোটিফিকেশন ভুলে যাবেন না। একটি নতুন অর্ডার বা একটি নতুন টিকেট ট্রিগার করুন এবং নিশ্চিত করুন সঠিক মানুষগুলো বিজ্ঞপ্তি পায়। এছাড়া নিশ্চিত করুন এটি নয়েজি নয়: একটি অ্যাকশন তিনটি ইমেইল এবং দুইটি চ্যাট মেসেজ তৈরি করা উচিত নয়।

আপনি যদি AppMaster ব্যবহার করেন, অথেনটিকেশন, পেমেন্ট বা মেসেজ টেমপ্লেটে পরিবর্তন করার পরে এই অংশটি পুনরায় চালান। এগুলোই সেই এলাকা যেখানে "ছোট" সম্পাদনাগুলো প্রায়ই ডেলিভারিতে বিঘ্ন ঘটায়।

অতিরিক্ত চেক যা বাস্তব গ্রাহকের কষ্ট ধরা দেয়

বাস্তব ব্যবহারকারীরা পুরনো ফোনে, দুর্বল কানেকশনে এবং খালি অ্যাকাউন্ট নিয়ে আসে।

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

তারপর খালি স্টেটগুলো পরীক্ষা করুন। নতুন ব্যবহারকারীদের কোন অর্ডার নেই, কোন সেভড কার্ড নেই, কোন হিস্টরি নেই। খালি স্ক্রিনগুলো কি পরবর্তী কী করতে হবে তা বোঝায়, ভাঙা মনে করে না।

কয়েকটি দ্রুত অতিরিক্ত যা পাঁচ মিনিটের মতো সময় নেবে:

• ডিভাইস পরিবর্তন করুন (একটি ফোন, একটি ডেস্কটপ) এবং কোর ফ্লো পুনরায় চালান
• রসিদ, বুকিং এবং "last updated" লেবেলে তারিখ ও সময় চেক করুন
• বোতাম টেক্সট এবং এরর মেসেজগুলি জোরে পড়ে দেখুন তারা পরিষ্কার কিনা
• সাফল্য স্পষ্ট কিনা নিশ্চিত করুন (স্ক্রিন, ইমেইল, রসিদ)

টাইম জোন একটি সাধারণ ফাঁদ। যদিও আপনার টিম একটি অঞ্চলে থাকলেও, অন্য একটি টাইম জোনের একটি টেস্ট অ্যাকাউন্ট ব্যবহার করে দেখুন ব্যবহারকারী যা দেখে তা আপনি ইচ্ছা করা অনুযায়ী মেলে কিনা।

অ-টেকনিকাল টিমের সাধারণ ভুলগুলো

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

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

টিমরা প্রায়ই ব্যাক-অফিস ফলাফল নিশ্চিত করা ভুলে যায়। স্ক্রিনে শুধু "Success" লেখা থাকলেই হবে না। নিশ্চিত করুন রেকর্ডটি আছে, স্ট্যাটাস সঠিক (paid বনাম pending), এবং আপনার অভ্যন্তরীন ভিউ গ্রাহক যা করল তার সঙ্গে মেলে।

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

সবশেষে, টেস্টগুলোর কার্যকারিতা ঘোরে। টাইমার ও লিখিত নোট ছাড়া, মানুষ ক্লিক করে ঘুরে বেড়ায় এবং "ঠিক মনে হচ্ছে" নিয়ে বেরিয়ে পড়ে। সেটিকে টাইট রাখুন এবং সঠিক ধাপ লিপিবদ্ধ করুন।

একটি সহজ উপায় এই ফাঁদগুলো এড়াতে:

• প্রতিটি মূল ধাপের (লগইন, ফর্ম, পেমেন্ট, নোটিফিকেশন) জন্য একটি সফল এবং একটি ব্যর্থ পরীক্ষা করুন।
• একটি সম্পূর্ণ নতুন ব্যবহারকারী এবং একটি সাধারণ রিটার্নিং ব্যবহারকারী ব্যবহার করুন (অ্যাডমিন নয়)।
• প্রতিটি অ্যাকশনের পরে নিশ্চিত করুন অ্যাডমিন/ব্যাক অফিস ভিউ সঠিক রেকর্ড ও স্ট্যাটাস দেখায়।
• দ্রুত 모바일 পাস করুন: সাইন আপ, প্রধান ফর্ম পূরণ, পে করুন।

আপনি যদি AppMaster দিয়ে বিল্ড করেন, Stripe পেমেন্ট এবং মেসেজিং মডিউলে অতিরিক্ত মনোযোগ দিন: নিশ্চিত করুন গ্রাহক সঠিক প্রমাণ দেখেন এবং আপনার অভ্যন্তরীণ স্ট্যাটাসগুলি প্রকৃতপক্ষে প্রক্রিয়াকৃত জিনিসগুলোর সঙ্গে মেলে।

প্রতিটি রিলিজের আগে চালানোর দ্রুত চেকলিস্ট

এটিকে আপনার শিপ করার ঠিক আগে শেষ ১০-৩০ মিনিট হিসেবে রাখুন। এটি গভীর QA নয়। এটি গ্রাহকরা প্রথম লক্ষ্য করে এমন সমস্যাগুলোর দ্রুত পরীক্ষা।

একটি “হ্যাপি পাথ” যাত্রা (সবচেয়ে সাধারণ ব্যবহারকারীর লক্ষ্য) এবং একটি “কিছু ভুল হয়েছে” মুহূর্ত (ভুল পাসওয়ার্ড, অনুপস্থিত ফিল্ড, ব্যর্থ পেমেন্ট) বাছুন। বাস্তবসম্মত টেস্ট ডেটা ব্যবহার করুন যাতে স্ক্রিনগুলো বাস্তব মনে হয়।

পাঁচটি চেক:

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

যদি কিছু বিভ্রান্তিকর, ধীর, বা অমিল করে, এটি একটা বাগ হিসেবে গণ্য করুন যদিও "কাজ করছে" মনে হচ্ছে।

আপনি যদি নো-কোড টুলের মতো AppMaster ব্যবহার করেন, একই ধরনের ডিপ্লয়মেন্ট (ক্লাউড বনাম self-hosted) বিরুদ্ধে এই চেকলিস্ট চালান যাতে লাস্ট মাইল একই রকম আচরণ করে।

উদাহরণ দৃশ্য: সাইনআপ থেকে পেমেন্ট পর্যন্ত সহজ যাত্রা টেস্ট করা

একজন গ্রাহক কিভাবে আচরণ করবে তেমন একটি বাস্তব পণ্য পাথ নকল করুন। তিনজন থাকলে এটি বেশি নির্ঝঞ্ঝাট হয়: একজন গ্রাহক হিসেবে একটি সাধারণ ডিভাইসে, একজন অ্যাডমিন সাইড দেখছে (ইউজার, অর্ডার, স্ট্যাটাস পরিবর্তন), এবং একজন নোট নিচ্ছে।

এটি পাঁচ ধাপে চালান:

• একটি নতুন অ্যাকাউন্ট তৈরি করুন (তাজা ইমেইল) এবং লগ আউট করার পরে আবার লগ ইন করা যাচ্ছিল কি না তা নিশ্চিত করুন।
• মূল রিকোয়েস্ট ফর্মটি সাধারণ ডেটা দিয়ে জমা করুন, তারপর একটি ভুল ফিল্ড জমা দিয়ে এরর মেসেজ দেখুন।
• আপনার টেস্ট পদ্ধতি ব্যবহার করে পেমেন্ট করুন এবং নিশ্চিত করুন আপনি সাফল্যের স্ক্রিনে পৌঁছেছেন।
• গ্রাহক প্রমাণ চেক করুন: রসিদ পৃষ্ঠা, অর্ডার আইডি, এবং পরিষ্কার "আমরা পেয়েছি" কনফার্মেশন।
• ব্যাক অফিস যাচাই করুন: ইউজার আছে, রিকোয়েস্টটি সেভ আছে, এবং পেমেন্ট সঠিক স্ট্যাটাস দেখায়।

ভালো নোট বিল্ডারদের দ্রুত রিপ্রোডিউস করতে সাহায্য করে। ধাপ নম্বর, আপনি কি ক্লিক বা টাইপ করেছেন, স্ক্রিন ও ডিভাইস/ব্রাউজার, প্রত্যাশিত বনাম প্রকৃত ফলাফল, সঠিক এরর টেক্সট এবং কী সময়ে ঘটেছে—এসব রেকর্ড করুন।

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

পরবর্তী ধাপ: এটাকে পুনরাবৃত্তিযোগ্য করুন

এই টেস্টের আসল সুবিধা তখনই যখন এটি রুটিনে পরিণত হয়।

ওয়াকথ্রুর পরপরই ১০ মিনিট ব্যয় করে যা আপনি পেয়েছেন তা ছোট একটি পুনরাবৃত্তিযোগ্য চেকগুলিতে পরিণত করুন যা প্রতিটি রিলিজের আগে চালানো যায়। সেগুলো সংক্ষিপ্ত এবং সাধারণ ভাষায় লিখুন, প্রত্যাশিত ফলাফল সহ। তারপর প্রতিটি এলাকায় একটি অউনার নির্ধারণ করুন (অউনারদের প্রযুক্তিগত হওয়া লাগবে না, কেবল ধারাবাহিক হতে হবে): লগইন/অ্যাক্সেস, ফর্ম/ডেটা সেভিং, পেমেন্ট/রিফান্ড, নোটিফিকেশন, এবং অ্যাডমিন/সাপোর্ট টুল।

কি লঞ্চের আগে ঠিক করা আবশ্যক এবং কি পরে করা যাবে তা সিদ্ধান্ত নিন। যা কিছু সাইন আপ, পেমেন্ট বা মূল টাস্ক ব্লক করে তা লঞ্চ রোধকারী। বিভ্রান্তিকর কপি বা ছোট লেআউট সমস্যা সাধারণত পরে নির্ধারিত করা যায়, যতক্ষণ সাপোর্ট প্রস্তুত।

আপনার টিম যদি AppMaster ব্যবহার করে, আপনি এই রিটেস্টগুলোকে ব্যবহারিক করে রাখতে পারবেন প্রধান ফ্লোগুলো (signup, checkout, password reset) স্ট্যান্ডার্ডাইজ করে এবং পরিবর্তনের পরে এগুলো পুনরায় চালিয়ে। যখন রিকোয়ারমেন্ট বদলে, অ্যাপ্লিকেশনকে পুনরায় জেনারেট করা সাহায্য করে উৎপন্ন সোর্স কোড পরিষ্কার ও ধারাবাহিক রাখতে, যা পুরনো ফিক্সগুলোর নতুন রিলিজে থেকে যাওয়া কমায়।

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