অফলাইন সফটওয়্যার পরীক্ষায় তিনটি বিষয় আলাদা করুন: সংযোগ ছাড়া কী দেখা যায়, কী স্থানীয়ভাবে লেখা যায় এবং কোন record server-এ পৌঁছেছে। অনুমোদিত একটি কাজ করে সংযোগ ফিরিয়ে নতুন view থেকে সেভ হওয়া ফল খুঁজে দেখুন। ইন্টারনেট ছাড়াই পুরোনো screen খোলা থাকলে নতুন তথ্য sync হয়েছে প্রমাণ হয় না।
বাংলাদেশের স্কুল প্রশাসকদের জন্য এই acceptance checklist iilmaa প্রকাশ করেছে। এখানে পরীক্ষার দৃশ্যপট দেওয়া হয়েছে; iilmaa-এর সব screen বা device অফলাইনে চলে, এমন দাবি করা হচ্ছে না।
কোন device ও কাজ পরীক্ষা করছেন লিখুন
সংযোগ বন্ধ করার আগে device, app, account-এর দায়িত্ব ও কাজের নাম রাখুন। native mobile app, browser tab এবং installed web app-এর আচরণ আলাদা হতে পারে। হাজিরার একটি কাজ সমর্থিত হলেই fee payment বা সব প্রশাসনিক কাজ সমর্থিত হয়ে যায় না।
সরবরাহকারীকে সমর্থিত কাজ ও সীমা দেখাতে বলুন। version ও পরীক্ষার তারিখ রাখুন। প্রয়োজনীয় কাজ সমর্থিত না হলে কর্মীদের জন্য ব্যবহারযোগ্য fallback পদ্ধতি নির্ধারণ করুন। হাজিরার নির্দেশিকা ও হাজিরা feature দিয়ে প্রশ্ন প্রস্তুত করতে পারেন।
দেখা, স্থানীয় এন্ট্রি ও server confirmation আলাদা
| দেখা অবস্থা | কী প্রমাণ হতে পারে | কী প্রমাণ হয় না |
|---|---|---|
| আগের roster দেখা যায় | কিছু তথ্য স্থানীয়ভাবে আছে | তালিকা হালনাগাদ বা নতুন entry সেভ হবে |
| স্থানীয় entry গ্রহণ | app স্থানীয় action দেখিয়েছে | অন্য device থেকে ফল পাওয়া যাবে |
| sync শুরু | পাঠানোর চেষ্টা হচ্ছে | server গ্রহণ করেছে |
| নতুন view-তে ফল পাওয়া | সেই view-তে record পাওয়া যাচ্ছে | অন্য সব pending কাজ সমাধান হয়েছে |
দায়িত্বপ্রাপ্ত কর্মী যেন pending, failed ও conflict অবস্থার অর্থ বুঝতে পারেন। দৈনন্দিন ব্যবহারকারী শুধু technical log-এর ওপর নির্ভর করে কাজ চালাবেন, এমন ব্যবস্থা ধরে নেবেন না।
নিয়ন্ত্রিত হাজিরার পরীক্ষা
কাল্পনিক ছাত্র ও আলাদা demo environment ব্যবহার করুন। শুরুতে পরিচিত ছোট roster রাখুন। পরীক্ষার বিষয় না হলে তারিখ, শ্রেণি বা account scope বদলাবেন না।
- সংযুক্ত অবস্থায় অনুমোদিত workflow খুলুন।
- সম্মত পদ্ধতিতে সংযোগ বন্ধ করুন।
- কয়েকটি সমর্থিত action করে screen-এর অবস্থা লিখুন।
- সমর্থিত নিয়মে view বন্ধ করে আবার খুলুন।
- সংযোগ ফিরিয়ে অসম্পূর্ণ বা ব্যর্থ item দেখুন।
- নতুন অনুমোদিত view থেকে ফল এনে প্রত্যাশিত register-এর সঙ্গে মেলান।
ব্যর্থ হলে আবার action দেওয়ার আগে কী unsaved আছে নিশ্চিত করুন। save-এ বারবার চাপা কোনো documented recovery পদ্ধতির বিকল্প নয়।
পরিচিতি ও সংশোধনের সীমা
pending কাজ পাঠানোর আগে কর্মী sign out করলে, প্রতিষ্ঠান/শাখা বদলালে বা অনুমতি হারালে কী হয়, জিজ্ঞাসা করুন। record যেন অন্য account-এর context-এ চলে না যায়। ডেমোর জন্য live প্রতিষ্ঠানের permission বদলে ফেলবেন না।
sync-এর পরে অনুমোদিত correction আলাদাভাবে পরীক্ষা করুন। একটি প্রথম entry সফল হলেই conflicting edit-এর সমাধান সহজ হবে প্রমাণ হয় না।
ছোট পরীক্ষার record রাখুন
শুরুর অবস্থা, action, screen-এর বার্তা, প্রত্যাশিত ফল, উদ্ধার করা ফল এবং বাকি প্রশ্ন লিখুন। device/app version ও reviewer রাখুন। “অফলাইন চলে” লেখার চেয়ে এই নির্দিষ্ট প্রমাণ বেশি কাজে আসে।
সাময়িক register, দায়িত্বপ্রাপ্ত কর্মী, পরে মিলিয়ে নেওয়ার ধাপ ও final reviewer নির্ধারণ করুন। স্থানীয় receipt-এর মতো screen দেখেই payment নিশ্চিত হয়েছে ভাববেন না; provider confirmation ও settlement-এর আলাদা প্রমাণ প্রয়োজন। স্কুলের প্রয়োজন ও package-এর শর্ত মিলিয়ে সীমা আলোচনা করুন।
অফলাইন সম্পর্কিত সাধারণ প্রশ্ন
ইন্টারনেট ছাড়া page খুললেই কি app offline চলে?
কিছু তথ্য স্থানীয়ভাবে আছে বোঝা যায়। নতুন entry, sync, correction এবং সেভ হওয়া ফল উদ্ধারের আলাদা প্রমাণ দরকার।
হাজিরা অফলাইনে হলে fee payment-ও হবে?
না। প্রতিটি workflow আলাদাভাবে পরীক্ষা করুন। স্থানীয় action provider authorization বা settlement-এর প্রমাণ নয়।
গ্রহণযোগ্য পরীক্ষার ফল কী?
সম্মত action থেকে প্রত্যাশিত register পাওয়া, নতুন অনুমোদিত view-তে ফল উদ্ধার এবং pending/failed item-এর দৃশ্যমান recovery পদ্ধতি থাকা। আগে দৃশ্যপট নির্ধারণ করে তারপর ফল বিচার করুন।
আপনার device ও সম্ভাব্য সংযোগ পরিস্থিতি নিয়ে iilmaa-এর নির্দিষ্ট workflow demo চাইতে পারেন।