PII ছাড়া ডেমো ও QA-এর জন্য ডাটাবেস সিডিং

কেন সিডড ডেটা ডেমো ও QA-র জন্য জরুরি

ফাঁকা অ্যাপগুলো বিচার করা কঠিন। একটি ডেমোতে খালি টেবিল এবং কয়েকটি “John Doe” রেকর্ড থাকলে এমনকি শক্তিশালী প্রোডাক্টও অসম্পূর্ণ মনে হয়। মানুষ ওয়ার্কফ্লো, এজ কেস বা ফলাফল দেখতে পারে না।

QA-তেও একই সমস্যা হয়। পাতলা বা অর্থহীন ডেটা থাকলে টেস্টগুলো শুধুই হ্যাপি-পাথেই থাকে এবং বাগগুলো লুকিয়ে থাকে যতক্ষণ না বাস্তব গ্রাহকরা আসেন এবং জটিলতা নিয়ে আসেন।

ক্যাচ: “বাস্তবসম্মত” ডেটা প্রায়ই প্রোডাকশনের কপি থেকেই আসে। সেটাই দলের মধ্যে ব্যক্তিগত তথ্য লিক করার প্রধান পথ।

PII (personally identifiable information) হলো এমন কিছু যা সরাসরি বা পরোক্ষভাবে কাউকে শনাক্ত করতে পারে: পূর্ণ নাম, ইমেইল, ফোন নম্বর, বাড়ির ঠিকানা, সরকারি আইডি, কাস্টমার নোট, IP ঠিকানা, সুনির্দিষ্ট লোকেশন ডেটা, এমনকি জন্মদিন + ZIP-এর মতো অনন্য সংমিশ্রণও।

ভালো ডেমো ও QA সিড ডেটা তিনটি লক্ষ্য ব্যালান্স করে:

• বাস্তবসম্মত: এটি ব্যবসার আসল কেসের মতো লাগে (বিভিন্ন স্ট্যাটাস, টাইমস্ট্যাম্প, ব্যর্থতা, এক্সসেপশন)।
• পুনরাবৃত্তিযোগ্য: আপনি মিনিটের মধ্যে প্রতিটি এনভায়রনমেন্টে একই ডেটাসেট আবার তৈরি করতে পারেন।
• নিরাপদ: কোনো বাস্তব কাস্টমার ডেটা নেই, এবং কোনো “প্রায় অননিমাইজড” অবশিষ্ট নেই।

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

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

ডেমো ও QA ডেটা সাধারণত কোথা থেকে আসে (এবং কেন তা ভুল হয়)

অধিকাংশ টিমই একই কিছু চায়: রিয়েল লাগা ডেটা, দ্রুত লোড হয়, এবং শেয়ার করা নিরাপদ। কিন্তু “বাস্তবসম্মত” পাওয়ার দ্রুততম পথ প্রায়শই সবচেয়ে ঝুঁকিপূর্ণ।

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

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

হার্ড টু-ইউজ্যুয়াল PII সাধারণত সমস্যার মূল কারণ কারণ তা সুসংহত কলামগুলোতে থাকে না। ফ্রি-টেক্সট ফিল্ড (নোট, “description”, চ্যাট ট্রান্সক্রিপ্ট), এটাচমেন্ট (PDF, ইমেজ, এক্সপোর্টেড রিপোর্ট), সাপোর্ট টিকিট ও ইনটার্নাল কমেন্টস, ডাটাবেসে রাখা অডিট ট্রেইল ও লগ, এবং ‘‘অতিরিক্ত’’ JSON ব্লব বা ইমপোর্টেড মেটাডেটা—এগুলোর দিকে খেয়াল রাখুন।

আরেকটি সমস্যা হলো ভুল ধরনের ডেটাসেট ব্যবহার করা। QA-কে এজ কেস এবং ভাঙ্গা স্টেট দরকার। সেলস ডেমোকে পরিষ্কার গল্পের জন্য হ্যাপি-পাথ রেকর্ড দরকার। সাপোর্ট ও অনবোর্ডিংকে পরিচিত ওয়ার্কফ্লো ও লেবেল দরকার। ট্রেনিং দরকার—পুনরাবৃত্ত অনুশীলন যেখানে প্রতিটি শিক্ষার্থী একই ধাপ দেখে।

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

কিছু তৈরি করার আগে আপনার ডেটার নিয়ম নির্ধারণ করুন

টেস্ট ডেটা তৈরির আগে কয়েকটি সহজ নিয়ম লিখে রাখুন। এটি সবচেয়ে সাধারণ ব্যর্থতা প্রতিরোধ করে: কেউ অনায়াসে প্রোডাকশন কপি করে ‘‘শুধু এখন জন্য’’ বলবে, এবং পরে সেটা ছড়িয়ে পড়ে যাবে।

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

একটি বাস্তবসম্মত ন্যূনতম নিয়ম সেট:

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

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

ডেটাসেট সাইজ টিয়ার আগে থেকেই নির্ধারণ করুন যাতে পরে বিতর্ক না হয়। ছোট “স্মোক” ডেটাসেট দ্রুত লোড হবে এবং কোর পাথগুলো কভার করবে। নরমাল QA সেট সাধারণ অবস্থা ও রোলগুলো কভার করবে। হেভি সেট পারফরম্যান্স চেকের জন্য থাকবে এবং সেটি প্রত্যেক বিল্ডে ব্যবহৃত হবে না।

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

AppMaster এর মতো প্ল্যাটফর্ম ব্যবহার করলে এই নিয়মগুলো সিড প্রসেসের পাশে রাখুন যাতে রিজেনারেট করা অ্যাপ ও রিজেনারেট করা ডেটা মডেল বদলানোর সাথে তাল মিলিয়ে থাকে।

অননিমাইজেশন টেকনিকগুলো যা ডেটাকে বাস্তবসম্মত রাখে

লক্ষ্য সরল: ডেটা যেন বাস্তব জীবনের মতো দেখায় ও আচরণ করে, কিন্তু কাউকে কখনো শনাক্ত করা না যায়।

তিনটি শব্দ প্রায় মিলেই যায়:

• Masking: একটি মান কেমন দেখায় তা বদলে দেয় (প্রদর্শনের জন্য অনেক সময়)।
• Pseudonymization: আইডেন্টিফায়ারকে ধারাবাহিক স্ট্যান্ড-ইন দিয়ে প্রতিস্থাপন করে যাতে রেকর্ডগুলো টেবিল জুড়ে যুক্ত থাকে।
• True anonymization: এমনভাবে বদলে দেয় যাতে আবার কোনোভাবে পুনরায় শনাক্ত করা না যায়, এমনকি ডেটা মিলিয়ে দিলেও।

শেপ রেখে মানে বদলান

ফরম্যাট-প্রিজার্ভিং মাস্কিং একই “ফিল” বজায় রাখে যাতে UI এবং ভ্যালিডেশনগুলো কাজ করে। একটি ভালো ফেক ইমেইলে এখনও @ এবং ডোমেইন থাকে, এবং একটি ভালো ফেক ফোন নম্বর আপনার অ্যাপের অনুমোদিত ফরম্যাট মেনে চলে।

উদাহরণঃ

• Email: [email protected] -> [email protected]
• Phone: +1 (415) 555-0199 -> +1 (415) 555-7423
• Address line: 742 Evergreen Terrace -> 615 Pine Street

এটি xxxxxx এর চাইতে ভালো কারণ সার্টিং, সার্চ ও এরর হ্যান্ডলিং প্রোডাকশনের মতো আচরণ করে।

সম্পর্ক বজায় রাখার জন্য টোকেনাইজেশন ব্যবহার করুন

টোকেনাইজেশন হচ্ছে ধারাবাহিক প্রতিস্থাপনের মাধ্যমে টেবিল জুড়ে কনসিস্টেন্ট রিপ্লেসমেন্ট পাওয়ার ব্যবহারিক উপায়। যদি একজন কাস্টমার Orders, Tickets, Messages-এ দেখা যায়, তারা সব জায়গায় একই ফেক কাস্টমার হওয়া উচিত।

সহজ পদ্ধতি: প্রতিটি অরিজিনাল মানের জন্য একটি টোকেন জেনারেট করে সেটি একটি ম্যাপিং টেবিলে স্টোর করুন (অথবা ডিটারমিনিস্টিক ফাংশন ব্যবহার করুন)। এভাবে customer_id=123 সবসময় একই ফেক নাম, ইমেইল ও ফোনে ম্যাপ হবে এবং JOIN কাজ করবে।

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

PII হটস্পটগুলো যা আপনি ভুলে যান (সহ সেগুলো সাফ করার উপায়)

স্পষ্ট ফিল্ডগুলি (name, email) কেবল সমস্যার অর্ধেক। ঝুঁকিপূর্ণ জিনিসগুলো প্রায়শই সেই জায়গাগুলোতে লুকায় যা ‘‘ব্যক্তিগত নয়’’ মনে হয় যতক্ষণ না আপনি সেগুলো জুড়ে দেন।

একটি ব্যবহারিক শুরু হলো সাধারণ PII ফিল্ডগুলোর ম্যাপিং এবং নিরাপদ প্রতিস্থাপনের আইডিয়া। কনসিস্টেন্ট রিপ্লেসমেন্ট ব্যবহার করুন যাতে ডেটা এখনও বাস্তব রেকর্ডের মতো আচরণ করে।

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

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

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

সিড ডেটাকে পুনরাবৃত্তিমূলক ও সহজে পুনর্নির্মাণযোগ্য করুন

আপনার সিড ডেটা যদি প্রতিবার র‍্যান্ডম হয়, তাহলে ডেমো ও QA রানগুলো বিশ্বাসযোগ্য হয় না। একটি বাগ ডেটা বদলে যাওয়ার কারণে অদৃশ্য হতে পারে। একটি ডেমো ফ্লো যা গতকাল কাজ করেছিল আজ ভাঙতে পারে কারণ একটি গুরুত্বপূর্ণ রেকর্ড অনুপস্থিত।

সিড ডেটাকে একটি বিল্ড আর্টিফ্যাক্ট মনে করুন, একটি এক-টাইম স্ক্রিপ্ট নয়।

ডিটারমিনিস্টিক জেনারেশন ব্যবহার করুন (শতভাগ র‍্যান্ডম নয়)

একটি নির্দিষ্ট সিড ও নিয়ম দিয়ে ডেটা জেনারেট করুন যাতে একই আউটপুট প্রতিবার মিলে। এতে স্থিতিশীল আইডি, পূর্বানুমেয় তারিখ এবং সম্পর্ক পায়।

একটি ব্যবহারিক প্যাটার্ন:

• প্রতিটি ডেটাসেট (demo, qa-small, qa-large) এর জন্য একটি নির্দিষ্ট সিড।
• ডিটারমিনিস্টিক জেনারেটর (একই ইনপুট নিয়ম, একই ফলাফল)।
• “গত ৭ দিন” ইত্যাদি মর্মে সময়কে একটি রেফারেন্স ডেটে অ্যানচর করা।

সিড স্ক্রিপ্টগুলোকে আইডেমপটেন্ট বানান

আইডেমপটেন্ট মানে একাধিকবার চালানো নিরাপদ। QA যখন পরিবেশ বারবার পুনর্নির্মাণ করে বা একটি ডেমো ডাটাবেস রিসেট করে তখন এটি জরুরি।

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

আপনার ডেটাসেটকে আপনার অ্যাপের সাথে ভার্সন করুন। QA যখন একটি বাগ রিপোর্ট করে, তাদের বলতে পারা উচিত “app v1.8.3 + seed v12” এবং ঠিক একই রূপে পুনরায় উৎপাদন করা যাবে।

বাস্তব ওয়ার্কফ্লো মেলানো সিনারিও-ভিত্তিক ডেটাসেট বানান

র‍্যান্ডম রো জেনারেট করা সহজ, কিন্তু এগুলো সাধারণত ভালো ডেমো দেয় না। একটি ভালো ডেটাসেট একটা গল্প বলে: ব্যবহারকারীরা কারা, তারা কী করতে চায়, এবং কী ভুল হতে পারে।

প্রথমে আপনার স্কিমা ও সম্পর্কগুলো দিয়ে শুরু করুন, ফেক নাম দিয়ে নয়। যদি আপনি AppMaster-এর Data Designer-এর মতো ভিজ্যুয়াল স্কিমা টুল ব্যবহার করেন, প্রতিটি এন্টিটি দিয়ে হাঁটুন এবং জিজ্ঞাসা করুন: বাস্তবে কি আগে তৈরি হয়, এবং কী তার ওপর নির্ভরশীল?

সহজ ক্রমটি বাস্তবসম্মত রাখে এবং ব্রোকেন রেফারেন্স ঠেকায়:

• প্রথমে organization বা account তৈরি করুন।
• তারপর user ও role যোগ করুন।
• কোর অবজেক্ট (ticket, order, invoice, message) জেনারেট করুন।
• পরে ডিপেন্ডেন্ট রেকর্ড যুক্ত করুন (comment, line items, attachments, events)।
• লগ ও নোটিফিকেশন দিয়ে শেষ করুন।

তারপর এটি সিনারিও-ভিত্তিক করুন। “10,000 অর্ডার” বলার বদলে কয়েকটি সম্পূর্ণ জার্নি তৈরি করুন যা বাস্তব ওয়ার্কফ্লো মেলে। একজন গ্রাহক সাইন আপ করে, আপগ্রেড করে, একটি সাপোর্ট টিকিট খুলে রিফান্ড পায়—আরেকজন অনবোর্ডিং সম্পন্ন করে না—আরেকজন ওভারডিউ পেমেন্টের জন্য ব্লক হয়েছে।

ইনটেনশনাল এজ কেস যুক্ত করুন: মিসিং অপশনাল ফিল্ড, ৫০০ ক্যারেক্টারের লম্বা ভ্যালু, অস্বাভাবিক বড় সংখ্যা, এবং কোন রেকর্ড যা পুরনো ভার্সনের ডেটাকে রেফারেন্স করে।

স্টেট ট্রানজিশনগুলোও জরুরি। বিভিন্ন স্ট্যাটাস জুড়ে এন্টিটি সিড করুন যাতে স্ক্রিন ও ফিল্টারে কিছু দেখায়: New, Active, Suspended, Overdue, Archived।

যখন সিড ডেটা গল্প ও স্টেটে ভিত্তি করে তৈরি হয়, QA সঠিক পাথগুলো টেস্ট করতে পারে এবং ডেমো বাস্তব ফলাফল তুলে ধরতে পারে—কোনো প্রোডাকশন ডেটা ছাড়াই।

উদাহরণ: কাস্টমার সাপোর্ট ডেমোর জন্য বাস্তবসম্মত ডেটাসেট

একটি সিম্পল সাপোর্ট ড্যাশবোর্ড কল্পনা করুন: এজেন্টরা লগ ইন করে, একটি টিকিট কিউ দেখে, একটি টিকিট খুলে উত্তর দেয় এবং ক্লোজ করে। একটি ভালো সিড সেট সেই ফ্লোকে বিশ্বাসযোগ্য করে তুলবে প্রোডাকশন ডেটা টেনে না এনে।

ছোট কাস্ট: 25 জন কাস্টমার, 6 জন এজেন্ট, এবং গত 30 দিনে প্রায় 120 টিকেট। লক্ষ্য পরিমাণ নয়—বৈচিত্র্য, যা বাস্তবে একটি মঙ্গলবার বিকেল কেমন লাগে তা মেলে।

কীটা বাস্তব দেখানো উচিত সেটা প্যাটার্ন, পরিচয় নয়। নাম, ইমেইল, ফোন সিনথেটিক রাখুন, কিন্তু বাকি সবকিছু প্রোডাকশনের মতো আচরণ করবে—ডেটার “শেপ” গল্প বিক্রয় করে।

অন্তর্ভুক্ত করুন:

• টাইমস্ট্যাম্প যা অর্থবোধক: ব্যবসার সময়ে শিখর, রাতগুলো শান্ত, কয়েকটি পুরনো টিকিট এখনও খোলা।
• স্ট্যাটাস প্রগেশন: New -> In Progress -> Waiting on Customer -> Resolved, বাস্তবসম্মত সময় ব্যবধানসহ।
• অ্যাসাইনমেন্ট: নির্দিষ্ট এজেন্ট নির্দিষ্ট ক্যাটাগরি (billing vs technical) handle করে, এবং এক-দুটি হ্যান্ডঅফ।
• কথোপকথনের থ্রেড: প্রতিটি টিকিটে 2-6 কমেন্ট, এটাচমেন্টগুলো ফেক ফাইলনেম দিয়ে উপস্থাপন।
• রিলেটেড রেকর্ড: কাস্টমার প্ল্যান, সর্বশেষ লগইন, এবং প্রসঙ্গের জন্য হালকা অর্ডার/ইনভয়েস টেবিল।

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

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

ডেটাসেট সাইজ নির্ধারণ করা যাতে প্রতিটি বিল্ড ধীর না হয়

সেরা ডেমো ডেটা হচ্ছে যতটুকু ছোট হবে ততটাই যে বৈশিষ্ট্য প্রমাণ করে। প্রতিবার রিবিল্ড 10 মিনিট নিলে মানুষ আর রিবিল্ড করে না। স্টেল ডেটা থেকে যায় এবং ভুলগুলো ডেমোতে এসে পড়ে।

২–৩ ডেটাসেট সাইজ রাখুন যা বিভিন্ন কাজ সারবে। একই স্কিমা ও নিয়ম ব্যবহার করে ভলিউম বদলান। এতে দৈনন্দিন কাজ দ্রুত থাকে অথচ পেজিনেশন ও রিপোর্টও পরীক্ষা করা যায়।

প্র্যাকটিক্যাল ভলিউম চিন্তার উপায়:

• স্মোক/UI সেট (দ্রুত): 1 টেন্যান্ট, 5-10 ব্যবহারকারী, 30-50 কোর রেকর্ড (উদাহরণস্বরূপ 40 টিকেট) — স্ক্রিন লোড ও সাধারণ ফ্লো পরীক্ষা করার জন্য।
• ফাংশনাল সেট (বাস্তবসম্মত): 3-5 টেন্যান্ট, মোট 50-200 ব্যবহারকারী, 500-5,000 কোর রেকর্ড — ফিল্টার, রোল-বেসড এক্সেস ও বেসিক রিপোর্টিং কভার করতে।
• পেজিনেশন/রিপোর্টিং সেট: প্রতি লিস্ট ভিউ অন্তত ৩ পেজ পুশ করার মতো রেকর্ড (অften 200-1,000 রো)।
• পারফরম্যান্স সেট (পৃথক): লোড টেস্টের জন্য 10x-100x বড় ভলিউম, PII ছাড়া জেনারেট করা এবং কখনো ডেমো হিসাবে শেয়ার না করা।

ভ্যারাইটি সাইজের চেয়ে বেশি গুরুত্বপূর্ণ। কাস্টমার সাপোর্ট অ্যাপের জন্য টিকেটগুলো বিভিন্ন স্ট্যাটাস (New, Assigned, Waiting, Resolved) ও চ্যানেলে (email, chat) ছড়িয়ে দেয়াটা 50,000 অনুরূপ টিকেট ডাম্প করার চাইতে বেশি কার্যকর।

বন্টন ডিটারমিনিস্টিক রাখুন। প্রতিটি টেন্যান্ট ও স্ট্যাটাস অনুযায়ী নির্দিষ্ট কাউন্ট ঠিক করুন, তারপর নিয়মে জেনারেট করুন। উদাহরণস্বরূপ: প্রতিটি টেন্যান্টে ঠিক 20 New, 15 Assigned, 10 Waiting, 5 Resolved টিকেট সিড করুন, সঙ্গে 2 overdue ও 1 escalated। ডিটারমিনিস্টিক ডেটা টেস্ট ও ডেমোকে স্থিতিশীল করে।

সিডড ডেটার সাধারণ ভুল ও ফাঁদ

ডেমো দ্রুত চালানো সবচেয়ে ঝুঁকিপূর্ণ উপায়: প্রোডাকশন কপি করা, দ্রুত মাস্ক করা, এবং সেটি নিরাপদ ভাবা। একটি মিস করা ফিল্ড (যেমন নোট কলাম) নাম, ইমেইল বা ইনটার্নাল মন্তব্য লিক করতে পারে, এবং আপনি সেটা টের পাবেন না যতক্ষণ না কেউ স্ক্রিনশট করে।

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

ব্রোকেন রিলেশনশিপগুলো সাধারণ ও অবিশ্বাস্যভাবে কঠিন শনাক্ত করা যায়। একটি সিড যা ফরেন কী উপেক্ষা করে orphan রেকর্ড বা অসম্ভব স্টেট তৈরি করতে পারে। স্ক্রিনগুলো ঠিক দেখলেও একটি বাটন missing related item লোড করার সময় ভেঙে পড়তে পারে।

সবচেয়ে ব্যথাদায়ক ভুলগুলো:

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

সহজ উদাহরণ: সাপোর্ট ডেমোতে 40 খোলা টিকেট আছে, কিন্তু কোনটিই পুনরায় খোলা না, কোনটিই escalate নেই, এবং কারো কোন টিকেট সেই কাস্টমার চর্নের সাথে নেই। এটি পরিষ্কার দেখায় যতক্ষণ না কেউ জিজ্ঞেস করে, “কাস্টমার escalation-এর পর বাতিল করলে কী হয়?”

ডেমো এনভায়রনমেন্ট শেয়ার করার আগে দ্রুত চেকলিস্ট

কোনো প্রস্পেক্টকে ডেমো পাঠানোর আগে বা অন্য টিমকে QA পরিবেশ হস্তান্তর করার আগে একটি দ্রুত পাস করুন যা ধরেই নেয় যে কিছু মিস হতে পারে। ডেটা বাস্তবসম্মত লাগা উচিত, প্রোডাকশনের মত আচরণ করা উচিত, এবং তবুও শেয়ার করা নিরাপদ হওয়া উচিত।

পাঁচটি দ্রুত চেক যা বেশিরভাগ সমস্যা ধরবে

• PII sniff test: ডাটাবেস ও এক্সপোর্ট করা ফাইলগুলোতে @, সাধারণ ফোন নম্বর প্যাটার্ন (10-15 ডিজিট, প্লাস চিহ্ন, ব্র্যাকেট), এবং আপনার টিম যে সাধারণ ফার্স্ট/লাস্ট নামগুলো টেস্টে ব্যবহার করে সেগুলোর একটি ছোট তালিকা খোঁজ করুন। যদি একটা বাস্তব-দৃশ্যমান রেকর্ড পান, ধরে নিন আরও আছে।
• রিলেশনশিপগুলো ঠিক আছে কি না: কয়েকটি কোর স্ক্রীন খুলে নিশ্চিত করুন যে প্রয়োজনীয় লিঙ্কগুলো আছে (প্রতিটি টিকেটের একটি কাস্টমার আছে, প্রতিটি অর্ডারের লাইন আইটেম আছে, প্রতিটি ইনভয়েসে পেমেন্ট স্টেট আছে)।
• টাইম রেঞ্জগুলো বিশ্বাসযোগ্য: নিশ্চিত করুন তারিখগুলো বিভিন্ন সময় ছড়িয়ে আছে (কিছু রেকর্ড আজ, কিছু গত মাসে, কিছু গত বছরে)। সবকিছু যদি “৫ মিনিট আগে” তৈরি হয়ে থাকে তবে চার্ট ও অ্যাক্টিভিটি ফিড নকল দেখাবে।
• পুনরাবৃত্তি ও অঙ্কিত রেকর্ড: দুইবার পুনর্নির্মাণ করুন এবং নিশ্চিত করুন একই কাউন্ট ও একই অ্যাঙ্কর রেকর্ড (একজন VIP কাস্টমার, একটি overdue invoice, একটি হাই-প্রায়োরিটি টিকেট) ফিরে আসে।
• লুকানো ডাটা সোর্সগুলো পরিষ্কার: লগ, ফাইল আপলোড, ইমেইল/SMS টেমপ্লেট, মেসেজ ইতিহাস ও এটাচমেন্ট স্ক্যান করুন। PII প্রায়শই এরর ট্রেস, CSV ইমপোর্ট, PDF ইনভয়েস ও নোটে লুকায়।

AppMaster-এ ডেমো বানালে, এটি রিলিজ রুটিনের সাথে সহজেই মেলে: অ্যাপ রিজেনারেট করুন, রিসিড করুন, তারপর চেকলিস্ট চালান—এরপরই টিম বাইরের কারও কাছে অ্যাক্সেস দিন।

পরবর্তী পদক্ষেপ: অ্যাপ পরিবর্তিত হওয়ার সঙ্গে সঙ্গে ডেমো ডেটা নিরাপদ ও সিঙ্ক রাখুন

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

একটি কার্যকর ওয়ার্কফ্লো:

• কয়েকটি সিনারিও নির্ধারণ করুন (আপনি ঠিক কোন জার্নি দেখাতে বা টেস্ট করতে চান)।
• ঐ সিনারিও থেকে সিড জেনারেট করুন (প্রোডাকশন এক্সপোর্ট নয়)।
• চেক চালান (PII স্ক্যান, স্যানিটি চেক, রেফারেন্সিয়াল ইন্টিগ্রিটি)।
• একটি ডেটাসেট ভার্সন প্রকাশ করুন (একটি অ্যাপ ভার্সনের সঙ্গে ট্যাগ করুন এবং সংক্ষিপ্ত চেঞ্জলগ রাখুন)।
• নিয়মিত বা প্রতিটি রিলিজে পুনর্নির্মাণ করুন যাতে дрিফট আগেই ধরা পড়ে।

স্কিমা, লজিক, এবং সিডসমূহ একসাথে aligned রাখাই টিমগুলোর জন্য সবচেয়ে কঠিন জায়গা। আপনার ডেটা মডেল বদলালে সিড স্ক্রিপ্ট ভেঙে যেতে পারে, অথবা খারাপ কাজ করবে কিন্তু অর্ধেক ভ্যালিড ডেটা তৈরি করবে যা বাগগুলো লুকায়।

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

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

একটি সিনারিও বেছে নিন (যেমন “নতুন কাস্টমার একটি টিকিট তৈরি করে এবং সাপোর্ট তা রেজল্ভ করে”), সেইটির জন্য ছোট PII-নিরাপদ সিড ডেটাসেট বানান, দুবার পুনর্নির্মাণ করে নিশ্চিত করুন এটি পুনরাবৃত্তিমূলক, তারপর অ্যাপ পরিবর্তনের সঙ্গে ধাপে ধাপে সিনারিও বাড়ান।