QA-এর জন্য টেস্ট ইমেল অ্যাকাউন্ট কীভাবে বেছে নেবেন

QA-এর জন্য টেস্ট ইমেল অ্যাকাউন্ট কী?

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

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

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

ম্যানুয়াল বনাম স্বয়ংক্রিয় ইমেল টেস্টিং: একটি সিদ্ধান্ত-বৃক্ষ

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

1. টেস্টে কি ইমেল আসা দরকার? ফরম্যাট যাচাই, UI অবস্থা, ফিক্সচার এবং ইউনিট টেস্টে সাধারণত দরকার হয় না। example.com, example.org বা example.net-এর ঠিকানা ব্যবহার করুন। এই ডোমেইনগুলো ডকুমেন্টেশন ও উদাহরণের জন্য সংরক্ষিত, তাই কোনো প্রকৃত ব্যক্তির কাছে কিছুই পৌঁছায় না। এলোমেলো ডোমেইন বানানো এড়িয়ে চলুন, কারণ সেগুলোর মালিক কেউ হতে পারে।
2. টেস্টের সময় কি একজন ব্যক্তি বার্তাটি পড়বেন? স্মোক টেস্ট, ম্যানুয়াল UAT, ডেমো এবং অন্বেষণমূলক সেশনে একজন মানুষ যুক্ত থাকেন। রিগ্রেশন স্যুট ও CI জব-এ সাধারণত থাকেন না।
3. যদি কেউ এটি পড়েন, তবে এতে কিছু সংবেদনশীল আছে কি? প্রকৃত গ্রাহকের রেকর্ড, ক্রেডেনশিয়াল, নিয়ন্ত্রিত ডেটা বা অডিট প্রমাণ হিসেবে রাখতে হবে এমন বার্তা অস্থায়ী ইনবক্সে রাখা উচিত নয়। বরং কোম্পানির মেলবক্স ব্যবহার করুন। উত্তর যদি না হয়, তবে অস্থায়ী ইনবক্সই যথেষ্ট।
4. যদি কোড এটি পড়ে, তবে টেস্ট পরিবেশ কি তার মেইল একটি টেস্ট SMTP সার্ভারে পাঠাতে পারে? যদি পারে, একটি SMTP ক্যাচার প্রতিটি বার্তা বিতরণ না করেই ধরে রাখে। যদি না পারে, কারণ অ্যাপ্লিকেশনকে তার স্বাভাবিক ইমেল সরবরাহকারীর মাধ্যমে পাঠাতেই হয়, তবে এমন হোস্টেড ইনবক্স ব্যবহার করুন যা আপনার টেস্ট API-এর মাধ্যমে পড়ে।

টেবিলটি পাঁচটি বিকল্প পাশাপাশি তুলনা করে।

একটি ইমেল ফিল্ড কোন ঠিকানাগুলো গ্রহণ বা প্রত্যাখ্যান করবে?

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

কখন একটি টেম্প ইনবক্সই যথেষ্ট

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

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

কখন আপনার SMTP ক্যাচার বা হোস্টেড ইনবক্স API দরকার

একবার টেস্টগুলো মানব-তত্ত্বাবধান ছাড়া চলতে শুরু করলে ইনবক্সটি কোড দিয়ে পড়া যায় এমন হতে হবে। দুই ধরনের টুল এই চাহিদা মেটায়, আর তারা ভিন্ন সমস্যার সমাধান করে।

SMTP ক্যাচার ও স্যান্ডবক্স টেস্ট পরিবেশে আপনার অ্যাপের আউটবাউন্ড মেইল সার্ভারের জায়গা নেয় এবং প্রতিটি বার্তা ডেলিভারি না করে পরিদর্শনের জন্য রেখে দেয়।

• Mailpit একটি বিনামূল্যের ওপেন সোর্স টুল, যা আপনি নিজেই চালাতে পারেন। এটি ডিফল্টভাবে মেইল ক্যাপচার করে এবং ইন্টিগ্রেশন টেস্টের জন্য একটি ওয়েব UI ও একটি REST API দেয়।
• MailHog একইভাবে কাজ করে, তবে এটি পুরোনো। Mailpit-এর রক্ষণাবেক্ষণকারীরা এটিকে আর রক্ষণাবেক্ষণযোগ্য বলে মনে করেন না, তাই এটি ব্যবহার করার আগে এর বর্তমান অবস্থা যাচাই করে নিন।
• Mailtrap Email Sandbox একই ধারণার একটি হোস্টেড সংস্করণ, যাতে SMTP ও API অ্যাক্সেস রয়েছে। এটি Mailtrap-এর প্রোডাকশন ইমেইল পাঠানোর পণ্য থেকে আলাদা।
• Ethereal একটি বিনামূল্যের ফেক SMTP সার্ভিস, যা মূলত Nodemailer-এর সাথে ব্যবহৃত হয়। বার্তাগুলো প্রিভিউয়ের জন্য ধরা হয় এবং কখনো ডেলিভারি হয় না।

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

• Mailosaur টেস্ট ইমেইল ঠিকানা, একটি API এবং ক্লায়েন্ট লাইব্রেরি দেয়, যা Cypress, Playwright ও Selenium-এর মতো ফ্রেমওয়ার্কের সাথে কাজ করে। এটি SMS কোডও কভার করে।
• MailSlurp তার API ও SDK-এর মাধ্যমে চাহিদামতো ইনবক্স তৈরি করে। টেস্টগুলো একটি বার্তার জন্য অপেক্ষা করতে পারে, তারপর কোড, লিঙ্ক ও সংযুক্তি বের করে নিতে পারে।

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

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

প্লাস ট্যাগ একটি কোম্পানির মেইলবক্সকে অনেক ঠিকানার বৈচিত্র্য গ্রহণ করতে দেয়। আপনার কোম্পানির ডোমেইনে qa+signup বা qa+reset-এ পাঠানো মেইল qa মেইলবক্সে পৌঁছায়, যেখানে আপনি ট্যাগ অনুযায়ী ফিল্টার করতে পারেন। Google Workspace এটি সমর্থন করে, আর Microsoft-এর ডকুমেন্ট অনুযায়ী Exchange Online-এ প্লাস অ্যাড্রেসিং ডিফল্টভাবে চালু থাকে, যদি না কোনো অ্যাডমিন এটি বন্ধ করেন।

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

টেম্প ইনবক্স দিয়ে ম্যানুয়াল সাইন-আপ টেস্ট কীভাবে চালাবেন

টেস্টিংয়ের জন্য অস্থায়ী ইমেইল ব্যবহার করা একটি ম্যানুয়াল সাইন-আপ টেস্টের জন্য তিনটি জিনিস দরকার: একটি নতুন ঠিকানা, যে বিল্ডটি আপনি টেস্ট করছেন, এবং কী এসেছে তা রেকর্ড করার জন্য ইনবক্সের বাইরে একটি জায়গা। এটি কেবল আপনার মালিকানাধীন বা টেস্ট করার অনুমতি আছে এমন সিস্টেমে চালান।

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

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

এই ভিউটি এখনও ম্যানুয়াল। ইনবক্সগুলো ব্রাউজারে একজন মানুষ তৈরি করেন, কোড দিয়ে প্রস্তুত করা হয় না, তাই এটি সমান্তরালে মানব-হস্তক্ষেপহীন রানের জন্য হোস্টেড ইনবক্স API-এর বিকল্প নয়।

একটি ইনবক্স নাকি প্রতি টেস্টে একটি ঠিকানা?

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

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

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

সাইন-আপ ও অনবোর্ডিং ইমেলে কী কী যাচাই করবেন

যাত্রাটি যে সব ইমেল পাঠাতে পারে তার একটি তালিকা দিয়ে শুরু করুন, তারপর ঠিক করুন প্রতিটি টেস্টে কী যাচাই করা হবে। দলগুলো প্রায়ই অতিরিক্ত ইমেল খুঁজে পায় কেবল তখনই, যখন টেস্টের মাঝপথে সেগুলো হাজির হয় — কোনো গ্রোথ এক্সপেরিমেন্ট বা নিরাপত্তা পরিবর্তনের পর কেউ না লিখে যোগ করা একটি ইমেল।

একটি সাধারণ সাইন-আপ যাত্রার ইমেল

• যাচাইকরণ লিঙ্ক বা ওয়ান-টাইম কোড
• স্বাগত ইমেল ও যেকোনো কুইক-স্টার্ট সিকোয়েন্স
• ম্যাজিক-লিঙ্ক সাইন-ইন
• পাসওয়ার্ড রিসেট
• ইমেল ঠিকানা পরিবর্তন, পুরোনো ও নতুন উভয় ঠিকানায় পাঠানো হয়
• নতুন ডিভাইস বা নতুন অবস্থানের নিরাপত্তা সতর্কতা
• যে সাইন-আপগুলো কখনো সম্পন্ন হয়নি সেগুলোর জন্য অনুস্মারক

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

প্রতিটি পরীক্ষামূলক ইমেলে কী যাচাই করবেন

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

রেন্ডারিং নিয়ে একটি সতর্কতা। একটি টেম্প ইনবক্স দেখায় একটি ওয়েব ভিউয়ার আপনার HTML কীভাবে প্রদর্শন করে। এটি বলে না একই ইমেল Gmail, Outlook, Apple Mail, ডার্ক মোড বা ছোট ফোনের স্ক্রিনে কেমন দেখায়, তাই এসব গুরুত্বপূর্ণ হলে আলাদা রেন্ডারিং যাচাইয়ের পরিকল্পনা করুন।

ইমেল পরিবর্তন ও অ্যাকাউন্ট পুনরুদ্ধারের ফ্লো

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

OTP ও যাচাইকরণের প্রান্তিক কেস কীভাবে পরীক্ষা করবেন

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

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

কোন কোডগুলো টেম্প ইনবক্সে পৌঁছায় আর কোনগুলো পৌঁছায় না, তার বিস্তারিত ধারণার জন্য ওটিপি কোডগুলির জন্য টেম্প মেইলের এই গাইডটি দেখুন।

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

ইমেল পরীক্ষা যখন মানুষের নজর ছাড়া চলে তখন কী বদলায়

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

যে সরঞ্জামই বেছে নিন না কেন, কয়েকটি অভ্যাস মানুষের নজর ছাড়া চলা ইমেল পরীক্ষা স্থিতিশীল রাখে:

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

এছাড়াও স্পষ্ট থাকুন একটি পাসিং পরীক্ষা কী প্রমাণ করে। "অ্যাপটি ইমেলটি তৈরি করেছে ও হস্তান্তর করেছে," "একটি হোস্টেড টেস্ট ডোমেইন পাবলিক ইমেল অবকাঠামোর মাধ্যমে এটি পেয়েছে," এবং "জিমেইল এটি স্প্যামে নয়, ইনবক্সে রেখেছে" — এগুলো তিনটি ভিন্ন তথ্য। একটি SMTP ক্যাচার প্রথমটি প্রমাণ করে, একটি হোস্টেড ইনবক্স API প্রথম দুটি প্রমাণ করে, এবং কোনোটিই তৃতীয়টি প্রমাণ করে না। GitHub Actions, GitLab CI এবং CircleCI-তে পাইপলাইন সেটআপের জন্য সিআই / সিডি পাইপলাইনগুলিতে ইমেল পরীক্ষার গাইডটি দেখুন।

পরীক্ষার ডেটা নিরাপদ রাখুন এবং নিয়মের মধ্যে থাকুন

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

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

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

যেসব সীমাবদ্ধতা মাথায় রাখতে হবে

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

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

সঠিক টেস্ট ইনবক্স বেছে নেওয়া

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

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