কর্মীরা ব্যবহারের আগে ব্যবসায়িক অ্যাপের জন্য বাস্তবসম্মত টেস্ট ডেটা

কর্মীরা অ্যাপ ব্যবহার শুরু করলে ঝকঝকে ডেমো কেন ব্যর্থ হয়

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

বাস্তব কাজ অনেক বেশি এলোমেলো। একজন সেলস অ্যাসিস্ট্যান্ট ফোন নম্বর ছাড়াই কোনো কন্টাক্ট সংরক্ষণ করতে পারেন, পরে সংশোধিত ইমেইল ঠিকানা নিয়ে ফিরে আসতে পারেন। একজন অপারেশনস ম্যানেজার «Acme» লিখে খুঁজে ছয়টি কাছাকাছি রেকর্ড পেতে পারেন। কোনো কাস্টমার মত বদলালে বন্ধ করা অনুরোধ আবার খুলতে হতে পারে। বাস্তবসম্মত টেস্ট ডেটা এসব পরিস্থিতি প্রোডাকশনে বিভ্রান্তি তৈরির আগেই দেখিয়ে দেয়।

খালি স্ক্রিন ব্যবহারিক প্রশ্নও আড়াল করে। কর্মী কি বুঝতে পারবেন প্রথমে কী লিখতে হবে? ড্রাফট আর জমা দেওয়া অনুরোধের পার্থক্য কি বোঝা যাবে? কোনো বাধ্যতামূলক ফিল্ড খালি থাকলে অ্যাপ কি জানাবে কী অনুপস্থিত? উপস্থাপক এসব ঘাটতি এড়িয়ে যেতে পারেন, কারণ তিনি আগে থেকেই প্রতিটি ধাপ জানেন।

শেয়ার করা রেকর্ড ওয়ার্কফ্লো বদলে দেয়

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

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

Koder.ai চ্যাটের মাধ্যমে দলকে ওয়েব, সার্ভার এবং মোবাইল অ্যাপ তৈরি করতে দেয়। তবে দ্রুত ডেভেলপমেন্ট সাধারণ মানুষের স্বাভাবিক আচরণ পরীক্ষা করার প্রয়োজনীয়তা দূর করে না। পুরো দল নির্ভর করার আগে বাস্তব কাজের অভ্যাস দিয়ে প্রথম সংস্করণ পরীক্ষা করুন।

টেস্ট ডেটা বাস্তব তথ্য থেকে আলাদা রাখুন

পরীক্ষার সময় বানানো নাম, ইমেইল ঠিকানা, ফোন নম্বর এবং কোম্পানির তথ্য ব্যবহার করুন। রেকর্ডে পরিষ্কার লেবেল দিন, যেমন «TEST - Northside Supplies», যাতে কেউ এগুলোকে বাস্তব কাস্টমার মনে না করেন। কাস্টমার তালিকা, কর্মীদের রেকর্ড, আর্থিক তথ্য বা ব্যক্তিগত নোট টেস্ট পরিবেশে কপি করবেন না।

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

কর্মীরা বাস্তবে যে কাজ করেন, সেখান থেকে শুরু করুন

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

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

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

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

কম ঘটা কাজও পরীক্ষা করুন। কর্মীরা ধাপ ভুলে যেতে পারেন, আর মূল নির্মাতা হয়তো কখনো সেগুলো চেষ্টা করেননি। যেমন:

• মাসের হিসাব বন্ধ করে বকেয়া ইনভয়েস পরীক্ষা করা
• ভুল কাস্টমারের নামে দেওয়া অর্ডার সংশোধন করা
• ম্যানেজারের অনুমোদনের পর রিফান্ড প্রক্রিয়া করা
• চাকরি ছেড়ে যাওয়া কর্মীর খোলা কাজ অন্য কাউকে দেওয়া
• ফাইন্যান্স টিম বা অডিটরের জন্য রিপোর্ট এক্সপোর্ট করা

আপনি যদি Koder.ai-তে অ্যাপ তৈরি করে থাকেন, ডেভেলপমেন্টের সময় সরাসরি চ্যাট রিকোয়েস্ট হিসেবে এসব পরিস্থিতি লিখুন। কর্মীদের আমন্ত্রণ জানানোর আগে প্রস্তুত করা রেকর্ড দিয়ে এগুলো আবার চালান এবং প্রতিটি পরিস্থিতির পাশে প্রত্যাশিত ফল লিখে রাখুন।

একটি কার্যকর পরিস্থিতির শেষ সীমা থাকে। «ক্লায়েন্টের তথ্য আপডেট করুন» খুব অস্পষ্ট। «ক্লায়েন্টের বিলিং ইমেইল বদলান, রেকর্ড সংরক্ষণ করুন এবং পরের ইনভয়েসে সেই ইমেইল ব্যবহার হচ্ছে কি না নিশ্চিত করুন» পরীক্ষককে যাচাই করার মতো নির্দিষ্ট বিষয় দেয়।

প্রতিদিনের ব্যবসায়িক ডেটার মতো রেকর্ড তৈরি করুন

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

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

তারিখ, পরিমাণ এবং স্ট্যাটাসে বৈচিত্র্য থাকা দরকার। প্রতিটি ইনভয়েসের মোট একই এবং প্রতিটি অনুরোধের স্ট্যাটাস «Open» হলে সর্টিং, ফিল্টারিং ও রিপোর্ট ঠিকমতো কাজ করছে কি না বোঝা যাবে না। কয়েক মাসজুড়ে বিভিন্ন তারিখের রেকর্ড তৈরি করুন। আপনার অ্যাপের জন্য উপযুক্ত হলে ড্রাফট, পাঠানো, পরিশোধিত, বিলম্বিত, বাতিল বা আর্কাইভ করা স্ট্যাটাস ব্যবহার করুন।

শত শত একই ধরনের এন্ট্রির চেয়ে বাস্তবসম্মত কয়েকটি প্যাটার্ন বেশি কিছু দেখাতে পারে:

• একই কাস্টমারের একই দিনে দুটি অর্ডার আছে।
• একজন সরবরাহকারীর পুরোনো ফোন নম্বর এবং পরিবর্তনটি ব্যাখ্যা করা সাম্প্রতিক নোট আছে।
• সাবেক কর্মী ঐতিহাসিক রেকর্ডে আছেন, কিন্তু নতুন কাজ পেতে পারেন না।
• কয়েকজন কাস্টমারের পদবি বা কোম্পানির নাম এক।
• অনেক ছোট নিয়মিত লেনদেনের পাশে একটি বড় অঙ্ক আছে।

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

নোট সহজ কিন্তু বিশ্বাসযোগ্য রাখুন। «কাস্টমার ডেলিভারি দুইবারে ভাগ করতে বলেছেন» নোটটি «Test note 14.»-এর চেয়ে বেশি কার্যকর। অভ্যন্তরীণ পরীক্ষার জন্য হলেও টেস্ট অ্যাপে বাস্তব ঠিকানা, অ্যাকাউন্ট নম্বর, ফোন নম্বর বা ব্যক্তিগত মন্তব্য যোগ করবেন না।

দলকে আমন্ত্রণ জানানোর আগে ব্যবহারকারী ও অনুমতির মডেল তৈরি করুন

সবাই একই স্ক্রিন ও বোতাম দেখলে অ্যাপ সমস্যা তৈরি করে। বাস্তবসম্মত পরীক্ষায় বাস্তবসম্মত মানুষও থাকতে হবে: যিনি রেকর্ড লেখেন, যিনি তা অনুমোদন করেন এবং যিনি শুধু অগ্রগতি দেখেন।

শুধু পদবির ভিত্তিতে নয়, প্রতিদিনের কাজের ভিত্তিতে ভূমিকা নির্ধারণ করুন। «ম্যানেজার» নামে পরিচিত দুজনের আলাদা অ্যাক্সেসের প্রয়োজন হতে পারে। একজন সেলস ম্যানেজার ডিসকাউন্ট অনুমোদন করতে পারেন, কিন্তু তার পে-রোল তথ্য দেখা উচিত নয়। একজন অ্যাকাউন্টস ক্লার্ক ইনভয়েস তৈরি করতে পারেন, কিন্তু কাস্টমারের ক্রেডিট লিমিট বদলাতে পারবেন না।

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

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

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

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

Koder.ai-এর পরিকল্পনা মোডে কর্মীদের আমন্ত্রণ জানানোর আগে ভূমিকা বর্ণনা করুন। আলাদা টেস্ট অ্যাকাউন্ট তৈরি করে প্রতিটি অ্যাকাউন্টে একই ছোট কাজগুলো করুন। অ্যাপ দ্রুত বদলানোর সময় অনুমতির সমস্যা সমাধান করা সহজ।

স্বাভাবিক ওয়ার্কফ্লোর অস্বস্তিকর পরিস্থিতি পরীক্ষা করুন

অ্যাপের বেশিরভাগ সমস্যা পরিষ্কার ডেমোতে নয়, স্বাভাবিক কাজের মাঝখানে দেখা দেয়। ওয়ার্কফ্লোর প্রতিটি ধাপে থাকা রেকর্ড তৈরি করুন, যেখানে দৈনন্দিন কাজের মতো তারিখ, নাম, নোট ও পরিমাণ থাকবে।

অর্ডার অ্যাপের জন্য এমন একটি নতুন অর্ডার তৈরি করুন, যেটিতে কেউ কাজ করেনি, একটি কর্মী প্রস্তুত করছেন, একটি ম্যানেজার অনুমোদন করেছেন এবং একটি দল গত মাসে বন্ধ করেছে। প্রতিটি ধাপে কর্মীরা কোন ফিল্ড বদলাতে পারেন দেখুন। কেউ ডেলিভারি ঠিকানা সম্পাদনা করলেই বন্ধ অর্ডার যেন চুপিচুপি «in progress» হয়ে না যায়।

বাস্তব কাজে ঘটা ব্যতিক্রমগুলো পরীক্ষা করুন:

• কোনো কর্মী কাজ শুরু করার পর অর্ডার বাতিল করুন।
• অ্যাপ পেমেন্ট সম্পূর্ণ হিসেবে রাখার পর সেটি ফেরত দেখান।
• মেয়াদ শেষ হওয়ার পর কোনো অনুরোধ খুলুন।
• ওয়ার্কফ্লোতে প্রত্যাশিত অ্যাটাচমেন্ট ছাড়া রেকর্ড জমা দিন।
• এখনো অসম্পূর্ণ তথ্য থাকা কোনো আইটেম অনুমোদনের চেষ্টা করুন।

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

পরে কোনো প্রশ্ন উঠলে স্ট্যাটাসের ইতিহাস গুরুত্বপূর্ণ। একটি সহজ ধাপ পরীক্ষা করুন: Sam সকাল ৯:১০-এ অনুরোধ তৈরি করলেন, Priya ৯:২৫-এ অনুমোদন করলেন এবং কাস্টমার ফোন করার পর Sam ১০:০০টায় তা বাতিল করলেন। যেসব কর্মীর অনুরোধটি দেখার অনুমতি আছে, তারা যেন প্রতিটি পরিবর্তন কে করেছেন, কখন করেছেন এবং অ্যাপ কোনো কারণ সংগ্রহ করলে সেটি দেখতে পান। একই সঙ্গে দীর্ঘ নোটের তালিকা না পড়েও বর্তমান স্ট্যাটাস বোঝা উচিত।

Koder.ai অ্যাপের ক্ষেত্রে টেস্ট ভার্সন তৈরি করার আগে এসব পরিস্থিতি সহজ ভাষায় বর্ণনা করুন। এরপর স্ক্রিন শেষ দেখাচ্ছে কি না না দেখে, কাজ হিসেবে এগুলো সম্পন্ন করুন।

ইচ্ছা করে ভুল ইনপুট দিন

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

একই ফর্ম কয়েকবার ব্যবহার করুন এবং প্রতিবার একটি করে বিষয় বদলান। এতে কোন যাচাই ব্যর্থ হয়েছে এবং বার্তাটি ব্যবহারকারীকে সাহায্য করছে কি না বোঝা সহজ হবে।

• শর্তসাপেক্ষ ফিল্ডসহ বাধ্যতামূলক ফিল্ড খালি রাখুন।
• দীর্ঘ কাস্টমার নোট এবং প্রতীক, অ্যাকসেন্ট, লাইন ব্রেক বা ইমোজিসহ লেখা পেস্ট করুন।
• ভবিষ্যৎ অ্যাপয়েন্টমেন্টের জন্য অতীতের তারিখ, ঋণাত্মক ইনভয়েসের পরিমাণ বা অতিরিক্ত দশমিক স্থান লিখুন।
• অন্য রেকর্ডে ইতিমধ্যে ব্যবহৃত ইমেইল ঠিকানা জমা দিন।
• স্পেস, কমা বা কারেন্সি চিহ্নসহ কোনো সংখ্যা পেস্ট করুন।

অ্যাপের সহজ ভাষায় বোঝানো উচিত কী ঠিক করতে হবে। «কমপক্ষে ১০টি সংখ্যা থাকা ফোন নম্বর লিখুন» কর্মীকে পরবর্তী পদক্ষেপ জানায়। «Validation error» জানায় না। সম্ভব হলে বার্তাটি ফিল্ডের পাশে রাখুন এবং ব্যবহারকারী জমা দেওয়ার চেষ্টা করার পরও এটি দৃশ্যমান রাখুন।

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

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

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

একটি বাস্তবসম্মত কর্মী পরিস্থিতি অনুসরণ করুন

ভাবুন, ১২ জন কর্মীর একটি হিটিং ও প্লাম্বিং কোম্পানি আছে। তারা এক অ্যাপে কাস্টমার, সার্ভিস জব, ইনভয়েস ও পেমেন্ট ট্র্যাক করে।

অফিস ম্যানেজার Maya লিক হওয়া রেডিয়েটর নিয়ে Jordan Lee-এর ফোন পান। তিনি Jordan লিখে সার্চ করে দুটি কাস্টমার রেকর্ড পান: «Jordan Lee» এবং একই ঠিকানার «J. Lee»। Maya একটি রেকর্ড বেছে নিয়ে বুধবার সকালের জন্য একটি জব তৈরি করেন, সমস্যার বিবরণ যোগ করেন এবং টেকনিশিয়ান Sam-কে দায়িত্ব দেন।

জবের শুরুতে স্ট্যাটাস থাকে «Booked»। Sam সম্পত্তিতে গিয়ে ফোনে অ্যাপ খোলেন। তিনি একটি ছবি যোগ করেন, স্ট্যাটাস «Work complete» করেন এবং যন্ত্রাংশ ও শ্রমের তথ্য লেখেন। নামটি চূড়ান্ত মনে হলেও ইনভয়েস তৈরির আগে Maya-কে এখনো চার্জ পরীক্ষা করতে হবে। কর্মীরা «Work complete» বলতে বিল করার জন্য প্রস্তুত বুঝতে পারেন, আবার Sam হয়তো শুধু সাইট থেকে বের হওয়া বোঝাতে পারেন।

আরও পরিষ্কার স্ট্যাটাস ব্যবহার করুন, যেমন «Awaiting office review»। এতে Maya-র পরবর্তী কাজ স্পষ্ট হয় এবং কেউ দাম পরীক্ষা করার আগে অ্যাপ ইনভয়েস পাঠায় না।

Maya দেখলেন Jordan-এর ৪৫ দিন ধরে বকেয়া একটি পুরোনো ইনভয়েস আছে। তিনি সিদ্ধান্ত নিলেন, বিল করার আগে নতুন জবটির সুপারভাইজারের অনুমোদন দরকার। Sam-এর নোট দেখে সুপারভাইজার Priya আগের মেরামত ব্যর্থ হওয়ায় একটি ডিসকাউন্ট অনুমোদন করলেন।

এই পরিস্থিতি পরীক্ষা করে অ্যাপ বাস্তব সিদ্ধান্ত সামলাতে পারে কি না:

• Maya-র সম্ভাব্য ডুপ্লিকেট কাস্টমার দেখা উচিত এবং সেটি একত্র করা বা পর্যালোচনার জন্য চিহ্নিত করার সুযোগ থাকা উচিত।
• Sam তার দায়িত্বে থাকা জব আপডেট করতে পারবেন, কিন্তু ইনভয়েসের পরিমাণ সম্পাদনা বা ডিসকাউন্ট অনুমোদন করতে পারবেন না।
• Priya-র জব অনুমোদন করা উচিত, কিন্তু সম্পর্কহীন পে-রোল বা কোম্পানির সেটিংস দেখা উচিত নয়।
• নতুন বিল পাঠানোর আগে বকেয়া ইনভয়েস Maya-র সামনে আসা উচিত, তবে জরুরি মেরামতের কাজ আটকে দেওয়া উচিত নয়।
• প্রতিটি স্ট্যাটাসে কে পরবর্তী কাজ করবেন এবং কোন অ্যাকশন এখনো খোলা আছে, তা বোঝা উচিত।

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

Sam যদি ফোন থেকে ডিসকাউন্ট অনুমোদন করতে পারেন, অনুমতির নিয়ম ঠিক করুন। Maya যদি «Work complete» বলতে বিল করা বোঝায় নাকি শুধু সাইটের কাজ শেষ বোঝায় তা বুঝতে না পারেন, কর্মীরা নির্ভর করার আগে স্ট্যাটাসের নাম বদলান।

একটি সহজ টেস্ট সেশন চালান এবং কী ঘটছে লিখে রাখুন

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

তারা থেমে গেলে, ভুল মেনু বাছলে বা কোনো লেবেলের অর্থ জিজ্ঞেস করলে তা লিখে রাখুন। এসব মুহূর্ত দেখায় কোথায় অ্যাপের ভাষা পরিষ্কার করা বা পথ সরল করা দরকার।

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

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

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

Koder.ai স্ন্যাপশট ও রোলব্যাক সমর্থন করে, যা বড় পরিবর্তনের আগে দলকে পরিচিত কাজ করা সংস্করণ রাখতে সাহায্য করতে পারে। নতুন ভূমিকা ও ওয়ার্কফ্লো এলে যাতে কাজে লাগে, সমস্যা লগটি প্রজেক্টের সঙ্গে রাখুন।

প্রথমবার কর্মীদের রোলআউটের আগে এই তালিকা দেখুন

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

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

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

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

ডুপ্লিকেট কাস্টমারের নাম, পুরোনো বন্ধ রেকর্ড, খালি ঐচ্ছিক ফিল্ড, কয়েক মাসজুড়ে ছড়ানো তারিখ এবং দীর্ঘ নোট যোগ করুন। «Smith» লিখে সার্চ করুন, স্ট্যাটাস দিয়ে ফিল্টার করুন, রিপোর্ট সর্ট করুন এবং একই ফল ফোনে খুলুন। ছোট নমুনা সেট প্রায়ই ধীর পেজ, বিভ্রান্তিকর লেবেল এবং অনেক রেকর্ড জমলে ব্যর্থ ফিল্টার আড়াল করে।

প্রতিটি অনুমতি স্তরের জন্য আলাদা টেস্ট অ্যাকাউন্ট তৈরি করুন, একটি লগইন ভাগাভাগি করবেন না। এতে অ্যাক্সেসের সমস্যা আবার ঘটানো ও ঠিক করা সহজ হয়।

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

পরবর্তী টেস্ট রাউন্ডের প্রস্তুতি নিন

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

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

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

পরবর্তী সংস্করণ তৈরির আগে Koder.ai-এর পরিকল্পনা মোড ব্যবহার করুন। কর্মীর ভূমিকা, নির্দিষ্ট কাজ, সম্পাদনাযোগ্য ফিল্ড এবং যাচাইয়ের নিয়ম বর্ণনা করুন। উদাহরণ: «একজন সাপোর্ট এজেন্ট টিকিট তৈরি করতে, কাস্টমার বাছতে, একটি নোট যোগ করতে এবং অগ্রাধিকার নির্ধারণ করতে পারবেন। অন্য দলের কাছে থাকা টিকিট এজেন্ট বন্ধ করতে পারবেন না। একটি বিষয়ের নাম বাধ্যতামূলক করুন এবং ফলো-আপ কলের জন্য অতীতের তারিখ বাতিল করুন।»

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

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