দলগত ব্রাউজার কীভাবে মূল্যায়ন করবেন: ব্যবহারিক চেকলিস্ট

মূল্য নির্ধারণের পৃষ্ঠা খোলার আগে সিদ্ধান্ত নির্ধারণ করুন

ভালো মূল্যায়ন বিক্রেতার তালিকা দিয়ে নয়, কাজ দিয়ে শুরু হয়। আগে লিখে রাখুন:

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

রিসোর্সের ধরন আলাদা হিসাব করুন। ৫০০টি সংরক্ষিত প্রোফাইল, ১০০টি ক্লাউড-সিঙ্ক করা প্রোফাইল, পাঁচটি সিট এবং একই সময়ে চলা দশটি সেশনের পরিকল্পনা ৫০০টি একসঙ্গে চলা দলীয় সেশন দেয় না। আপনার কাজের ধারা যে এককে সীমা ব্যবহার করে, প্রতিটি সীমা সেই এককে লিখুন।

এরপর এমন বাধ্যতামূলক শর্ত চিহ্নিত করুন, যেগুলো কোনোভাবেই শিথিল করা যাবে না। সাধারণ একটি তালিকা হলো:

1. সমর্থিত ও বর্তমান ব্রাউজার বিল্ড;
2. অজান্তে প্রোফাইল নষ্ট না হওয়া এবং একই সময়ে লিখতে থাকা একাধিক প্রসেস না থাকা;
3. প্রত্যাহারযোগ্য, ন্যূনতম-অধিকার অ্যাক্সেসসহ আলাদা পরিচয়;
4. সাধারণ লগ বা অটোমেশন আউটপুটে কাঁচা গোপন তথ্য না থাকা;
5. ব্যবহারযোগ্য অডিট প্রমাণ;
6. পরীক্ষিত পুনরুদ্ধার ও পরিষেবা ছাড়ার পথ; এবং
7. প্রযোজ্য পরিষেবার শর্ত মেনে আইনসম্মত ও অনুমোদিত ব্যবহার।

ব্যর্থ কোনো শর্তকে অন্য শর্তের সঙ্গে গড় করে সংখ্যাগত স্কোর বানাবেন না। ঝকঝকে ইন্টারফেস অযাচাইকৃত আপডেটার বা অবস্থা হারায় এমন পুনরুদ্ধার প্রক্রিয়ার ক্ষতিপূরণ করতে পারে না।

সহজ প্রমাণের স্কেল ব্যবহার করুন

প্রতিটি চেকলিস্ট আইটেমের ফলাফল এবং পাওয়া সবচেয়ে শক্তিশালী প্রমাণ—দুটিই লিখুন।

ফলাফল

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

প্রমাণ

1. প্রকাশিত দাবি: বিপণন বা বিক্রয়-লেখা।
2. প্রযুক্তিগত ডকুমেন্টেশন: সংস্করণযুক্ত পণ্য, নিরাপত্তা, API বা সহায়তা ডকুমেন্টেশন।
3. পর্যবেক্ষিত প্রদর্শন: আপনার পরিস্থিতি ব্যবহার করে বিক্রেতার সরাসরি প্রদর্শন।
4. নিয়ন্ত্রিত ট্রায়াল: দলটি পরীক্ষার জন্য আলাদা রাখা ডেটা দিয়ে আচরণ পুনরায় চালিয়েছে এবং সংস্করণ ও ফলাফল লিখেছে।
5. স্বাধীন বা চুক্তিভিত্তিক প্রমাণ: প্রয়োজনটি কভার করে এমন সীমিত মূল্যায়ন, স্বাক্ষরিত প্রতিশ্রুতি বা সহায়তার শর্ত।

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

১. পণ্যের অবস্থা ও দাবির সীমা

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

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

২. প্রোফাইল বিচ্ছিন্নতা ও অখণ্ডতা

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

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

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

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

৩. ব্রাউজারের সতেজতা, স্যান্ডবক্স ও আপডেট

ব্রাউজার এমন একটি সফটওয়্যার উপাদান যার ওপর নিরাপত্তা নির্ভর করে, তাই এর নিয়মিত রক্ষণাবেক্ষণ জরুরি। ৮ সেপ্টেম্বর ২০২৬-এ Chrome 153 প্রকাশের সঙ্গে Chrome প্রতি দুই সপ্তাহে নতুন Stable সংস্করণ প্রকাশ করা শুরু করে। এই প্রকাশসূচি কোনো সরবরাহকারীর সেবার সুনির্দিষ্ট প্রতিশ্রুতি ঠিক করে দেয় না। তবে এটি বোঝায়, সংস্করণ ও আপডেটের প্রমাণ ছাড়া শুধু ‘Chromium-ভিত্তিক’ বলা যথেষ্ট নয়।

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

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

আপডেটের অখণ্ডতার জন্য The Update Framework কার্যকর রেফারেন্স, কারণ এটি রিপোজিটরি ও স্বাক্ষর-চাবি দখল হয়ে যাওয়ার ঝুঁকি স্পষ্টভাবে বিবেচনা করে। SLSA provenance আর্টিফ্যাক্ট কোথায়, কখন ও কীভাবে তৈরি হয়েছে তার যাচাইযোগ্য তথ্য সংজ্ঞায়িত করে। বিক্রেতাকে ওই প্রকল্পগুলোই ব্যবহার করতে হবে এমন নয়, কিন্তু আর্টিফ্যাক্টের পরিচয়, দখল হয়ে যাওয়া চাবি, রোলব্যাক, ফ্রিজ এবং বিল্ডের প্রোভেন্যান্স কীভাবে সামলায় তা ব্যাখ্যা করতে হবে।

৪. পরিচয়, ডিভাইস ও ন্যূনতম অধিকার

NIST SP 800-53 Rev. 5 অ্যাক্সেস নিয়ন্ত্রণ, অডিট, প্রমাণীকরণ, আকস্মিকতা পরিকল্পনা, ঘটনা-প্রতিক্রিয়া এবং সরবরাহ-শৃঙ্খল ঝুঁকি জুড়ে নিয়ন্ত্রণ সাজায়। ফ্রেমওয়ার্কের সঙ্গে সামঞ্জস্যকে বাস্তবায়নের প্রমাণ না ধরে এসব ক্ষেত্রকে প্রশ্নের সূত্র হিসেবে ব্যবহার করুন।

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

বর্তমান প্রমাণীকরণ-পরিভাষা ও নিশ্চয়তার নির্দেশনার জন্য ৩১ জুলাই ২০২৫-এ চূড়ান্ত হওয়া NIST SP 800-63B-4 দেখুন। বিক্রেতার প্রমাণীকরণ-সংক্রান্ত দাবি পণ্যের কোন অংশে প্রযোজ্য তা নিশ্চিত করুন: ওয়েবসাইট লগইন, ডেস্কটপ আনলক, স্থানীয় API, ক্লাউড API, পুনরুদ্ধার এবং সহায়তা-অ্যাক্সেসে আলাদা পদ্ধতি থাকতে পারে।

৫. সংবেদনশীল ডেটা ও আস্থার সীমা

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

• □ কোন প্রোফাইলের বিষয়বস্তু ডিফল্টভাবে স্থানীয় থাকে?
• □ সিঙ্ক্রোনাইজেশন চালু করলে কোন মেটাডেটা ও সংবেদনশীল বিষয়বস্তু আপলোড হয়?
• □ এনক্রিপশন কোথায় হয় এবং কোন পক্ষ ডিক্রিপশন কী পেতে পারে?
• □ স্থানীয় কীগুলো কীভাবে সুরক্ষিত, ব্যাকআপ নেওয়া, পর্যায়ক্রমে বদলানো ও পুনরুদ্ধার করা হয়?
• □ প্রতিষ্ঠানের প্রশাসক, বিক্রেতার সহায়তা, অবকাঠামোর অপারেটর ও অটোমেশন ক্লায়েন্ট কী পড়তে পারে?
• □ কুকি, পাসওয়ার্ড, প্রক্সি-শংসাপত্র, দুই-ধাপের গোপন তথ্য এবং এনক্রিপশন কী কি সাধারণ UI, লগ, টেলিমেট্রি, API ও এজেন্ট আউটপুট থেকে বাদ থাকে?
• □ ক্র্যাশ রিপোর্ট ও ডায়াগনস্টিক কি পাঠানোর আগে দেখা যায়, গোপন তথ্য মুছে দেওয়া থাকে, সম্মতিনির্ভর এবং সীমিত সময়ে রাখা হয়?
• □ কাঁচা প্রোফাইল আর্কাইভ বা শংসাপত্র না চেয়ে সহায়তা কি কাজ করতে পারে?
• □ আমদানি করা এক্সটেনশন, আর্কাইভ, ব্রাউজার ডাউনলোড ও আপডেটের মেটাডেটাকে কি অবিশ্বস্ত ধরা হয়?
• □ স্থানীয় কপি, ক্লাউড অবজেক্ট, ব্যাকআপ, লগ ও সহায়তার ফাইল—সব জায়গায় মুছে ফেলার নিয়ম কি সংজ্ঞায়িত?

‘এনক্রিপ্টেড’ কথাটিকে সম্পূর্ণ উত্তর হিসেবে গ্রহণ করবেন না। ডেটার শ্রেণি, অবস্থান, এনক্রিপশনের সীমা, কী-রক্ষক, পুনরুদ্ধারের পথ এবং কোন অবস্থায় ডেটা খোলা অবস্থায় থাকে—সব লিখুন।

৬. সহযোগিতা ও অডিটযোগ্যতা

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

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

৭. পুনরুদ্ধার, বিঘ্ন ও পরিষেবা ছাড়ার পথ

পুনরুদ্ধার পরীক্ষা না হওয়া পর্যন্ত ব্যাকআপের দাবি অসম্পূর্ণ। NIST Cybersecurity Framework 2.0-তে ব্যাকআপ তৈরি, সুরক্ষা, রক্ষণাবেক্ষণ ও পরীক্ষা এবং পুনরুদ্ধারের সম্পদ ও পুনরুদ্ধার করা সিস্টেম যাচাইয়ের ফলাফল অন্তর্ভুক্ত আছে।

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

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

৮. অটোমেশন ও ডেভেলপার নিয়ন্ত্রণ

• □ পণ্য কি সীমাহীন ফাইল-সিস্টেম বা প্রসেস-অ্যাক্সেসের বদলে সংস্করণযুক্ত ডোমেইন-অপারেশন প্রকাশ করে?
• □ API, CLI, SDK, Playwright, CDP, WebDriver, webhook ও এজেন্টের সক্ষমতা কি আলাদা করে নথিবদ্ধ?
• □ ব্রাউজার ও ক্লায়েন্টের সঠিক সামঞ্জস্যের ম্যাট্রিক্স আছে?
• □ টেন্যান্ট, প্রোফাইল, অপারেশন, অডিয়েন্স, মেয়াদ, হার ও খরচ অনুযায়ী শংসাপত্রের পরিসর কি সীমিত করা যায়?
• □ ধ্বংসাত্মক, একসঙ্গে অনেক কিছুর ওপর প্রয়োগ করা, বাইরে দৃশ্যমান, গোপন তথ্য বহনকারী বা খরচ তৈরি করা কাজের ক্ষেত্রে কি শক্তিশালী নীতি বা প্রতিটি কাজের আলাদা অনুমোদন দরকার?
• □ প্রিভিউ কি ঠিক যে অনুরোধটি কার্যকর হবে, তার সঙ্গেই বাঁধা?
• □ পরিবর্তনকারী কমান্ড কি একই অনুরোধ পুনরায় চালালেও একই ফল দেয়, অথবা ফলাফল অজানা হতে পারে—এ কথা স্পষ্ট করে?
• □ দীর্ঘ কাজ কি বাতিল এবং নিরাপদে পুনরায় চালু করা যায়?
• □ কাজ চলার সময় অ্যাক্সেস প্রত্যাহার কার্যকর হয়?
• □ মানব-কাজের মতো একই অডিট ট্রেইলে অটোমেশনের সিদ্ধান্তের দায়িত্ব কি দেখা যায়?
• □ কাঁচা সেশন-অবস্থা ফেরত না দিয়েও সাধারণ অটোমেশন আউটপুট কি কাজে লাগে?
• □ গোপন তথ্য ফাঁস না করে পুনরুদ্ধারের জন্য ত্রুটি-বার্তা কি যথেষ্ট নির্দিষ্ট?

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

৯. অপারেটরের অভিজ্ঞতা ও অ্যাক্সেসিবিলিটি

• □ কীবোর্ড ব্যবহারকারী কি প্রতিটি নিয়ন্ত্রণ, ডায়ালগ, টেবিল, মেনু এবং প্রোফাইল-সংক্রান্ত কাজে পৌঁছে তা চালিয়ে বের হতে পারেন?
• □ নেভিগেশন, ত্রুটি ও মডাল পরিবর্তনের পর ফোকাস কি দৃশ্যমান এবং যৌক্তিক ক্রমে থাকে?
• □ লেবেল, ত্রুটি, অবস্থার পরিবর্তন ও ধ্বংসাত্মক কাজের নিশ্চিতকরণ কি স্ক্রিন-রিডারে কাজ করে?
• □ জুম করে বা বড় অক্ষরের মাপ ব্যবহার করলেও কি ইন্টারফেস ব্যবহারযোগ্য থাকে?
• □ রং, নড়াচড়া ও সময়সীমা কি সামঞ্জস্য করা যায়, অথবা সেগুলো কি অপরিহার্য নয়?
• □ শুধু রঙের ওপর নির্ভর না করে অপারেটর কি নির্বাচিত প্রতিষ্ঠান, প্রোফাইল, প্রক্সি, পরিবেশ ও ঝুঁকির অবস্থা আলাদা করতে পারেন?
• □ ব্যবহারকারীকে অ্যাক্সেসিবিলিটিতে সমস্যাযুক্ত ঘন টেবিলের মধ্য দিয়ে না ঠেলে কি একসঙ্গে অনেক কাজ পর্যালোচনা করা যায়?
• □ প্রতিটি সমর্থিত অপারেটিং সিস্টেমে কি নেটিভ প্ল্যাটফর্ম আচরণ, বিজ্ঞপ্তি, ফাইল নির্বাচক, শংসাপত্রের প্রম্পট এবং আপডেট ডায়ালগ একইভাবে কাজ করে?

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

১০. বাণিজ্যিক ও অপারেশনাল উপযোগিতা

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

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

নিয়ন্ত্রিত ট্রায়ালের পরিকল্পনা

মূল্যায়নের জন্য তৈরি পরীক্ষার অ্যাকাউন্ট, কৃত্রিম ক্রেডেনশিয়াল এবং প্রোফাইল ব্যবহার করুন। ট্রায়ালকে বাস্তব দেখানোর জন্য উৎপাদন পরিবেশের কুকি আমদানি করবেন না।

1. পরিবেশ লিখুন। অ্যাপ ও ব্রাউজারের সংস্করণ, অপারেটিং সিস্টেম, হার্ডওয়্যার, নেটওয়ার্ক, প্রক্সির ধরন, এক্সটেনশনের সেট, অ্যাকাউন্টের প্ল্যান এবং পরীক্ষার তারিখ লিখুন।
2. দুটি ভূমিকা ও কয়েকটি প্রোফাইল তৈরি করুন। একজন প্রশাসক, সীমিত অধিকার-সম্পন্ন একজন অপারেটর, আলাদা ফোল্ডার এবং অন্তত একটি এমন প্রোফাইল রাখুন যাতে অপারেটর প্রবেশ করতে না পারেন।
3. স্বাভাবিক কাজের ধারা চালান। প্রোফাইল চালু, ব্যবহার, থামানো, অন্যের কাছে হস্তান্তর এবং আবার চালু করুন। প্রত্যাশিত ও বাস্তব অবস্থা লিখুন।
4. অস্বীকৃতির পথ পরীক্ষা করুন। সীমিত পরিচয় ব্যবহার করে নির্ধারিত পরিসরের বাইরে কোনো প্রোফাইল, রপ্তানি, ভূমিকা পরিবর্তন এবং অটোমেশন কমান্ড চালানোর চেষ্টা করুন।
5. বিঘ্ন পরীক্ষা করুন। পরীক্ষার জন্য আলাদা রাখা ডেটা দিয়ে বিক্রেতা-সমর্থিত বা অন্য কোনো নিরাপদ পদ্ধতিতে ব্রাউজার থামানো বা সিঙ্ক্রোনাইজেশনের ধাপ মাঝপথে থামান। পুনরুদ্ধারের পথ যাচাই করুন।
6. পুনরুদ্ধার করে তুলনা করুন। পরিচিত একটি স্ন্যাপশট নতুন কপিতে পুনরুদ্ধার করুন, তার অখণ্ডতা যাচাই করুন এবং গ্রহণযোগ্যতা নিশ্চিত না হওয়া পর্যন্ত বর্তমান কপি রেখে দিন।
7. অ্যাক্সেস প্রত্যাহার করুন। একজন ব্যবহারকারী, ডিভাইস, সেশন ও সার্ভিস ক্রেডেনশিয়াল সরান; UI ও API—দুই জায়গায় অস্বীকৃতি নিশ্চিত করুন এবং অডিট ইভেন্ট দেখুন।
8. স্থানান্তরযোগ্যতা পরীক্ষা করুন। অনুমোদিত ডেটা রপ্তানি করুন, নথিবদ্ধ ফরম্যাট পরীক্ষা করুন, সমর্থিত হলে পরীক্ষার জন্য আলাদা রাখা গন্তব্যে আবার আমদানি করুন এবং কী বাদ গেছে তা লিখুন।
9. অ্যাক্সেসিবিলিটি পর্যালোচনা করুন। প্রতিটি প্রয়োজনীয় প্ল্যাটফর্মে কীবোর্ড ও প্রাসঙ্গিক সহায়ক প্রযুক্তি ব্যবহার করে মূল কাজ শেষ করুন।
10. খরচ ও দাবি মিলিয়ে নিন। বাস্তবে ব্যবহৃত রিসোর্স এবং সহায়তার প্রতিক্রিয়া প্রস্তাব ও চুক্তির সঙ্গে তুলনা করুন।

সিদ্ধান্ত-রেকর্ডের টেমপ্লেট

প্রয়োজন	অগ্রাধিকার	ফলাফল	প্রমাণ ও তারিখ	সীমাবদ্ধতা বা ঝুঁকি	মালিক ও পরের কাজ
উদাহরণ: অপারেটর সেশনের অবস্থা রপ্তানি করতে পারবে না	বাধ্যতামূলক শর্ত	উত্তীর্ণ	নিয়ন্ত্রিত ট্রায়াল, সংস্করণ X, YYYY-MM-DD	শুধু API দেখা হয়েছে; CLI পরীক্ষা হয়নি	নিরাপত্তা-দায়িত্বশীল ব্যক্তি CLI পরীক্ষা করবেন

মূল্যায়ন চারটি স্পষ্ট তালিকা দিয়ে শেষ করুন:

• যথেষ্ট প্রমাণসহ উত্তীর্ণ বাধ্যতামূলক শর্ত;
• নামধারী মালিক ও পর্যালোচনার তারিখসহ গৃহীত উদ্বেগ;
• যে বিষয়গুলো এখনও যাচাই হয়নি;
• নতুন ব্রাউজার ইঞ্জিন, পরিচয় প্রদানকারী, আপডেটার, মূল্য-নির্ধারণের মডেল বা প্রোফাইল-ফরম্যাট এলে পুনর্মূল্যায়ন শুরু হবে—এমন শর্ত।

সাধারণ সতর্ক সংকেত

এই অবস্থাগুলো দেখলে সিদ্ধান্ত থামান:

• ব্রাউজারের সংস্করণ শনাক্ত করা যায় না;
• স্বাভাবিক ব্যবহারের জন্য স্যান্ডবক্স বন্ধ করতে হয়;
• প্রশাসক ও অটোমেশন একই স্থায়ী ক্রেডেনশিয়াল ভাগ করে;
• দলের কাজ হস্তান্তরের জন্য পণ্যটি কাঁচা কুকি বা পাসওয়ার্ড ভাগ করার ওপর নির্ভর করে;
• UI যে গোপন তথ্য সুরক্ষিত রাখার দাবি করে API সেটি রপ্তানি করতে পারে;
• অডিট ইভেন্টে কার্যকারী নেই বা সেগুলো রপ্তানি করা যায় না;
• ‘ব্যাকআপ’ বলতে শুধু ক্লাউডে একটি কপি থাকা বোঝায়, পুনরুদ্ধার দেখানো হয়নি;
• বিঘ্নিত লেখা বা একই সময়ে প্রোফাইল ব্যবহারের ব্যাখ্যা বিক্রেতা দিতে পারে না;
• গুরুত্বপূর্ণ কোনো কাজ অ্যাক্সেসিবল নয় এবং তার কোনো বিকল্পও নেই;
• নিরাপত্তা প্রতিবেদন পাঠাতে সাধারণ ইমেইলে গোপন তথ্য পাঠাতে হয়; অথবা
• পণ্যের দাবি অদৃশ্য থাকার, অ্যাকাউন্টে নিশ্চিত অ্যাক্সেস বা প্ল্যাটফর্মের বিধি-প্রয়োগ এড়ানোর প্রতিশ্রুতি দেয়।

‘যাচাই হয়নি’ ফলাফল কোনো অভিযোগ নয়। এটি অনুপস্থিত প্রমাণের নির্দিষ্ট বিবরণ। বিক্রেতা প্রমাণ না দেওয়া, আপনার দল আচরণ পরীক্ষা না করা বা সিদ্ধান্তের মালিক ঝুঁকি গ্রহণ না করা পর্যন্ত সেটি দৃশ্যমান রাখুন।