অ্যাপ্লিকেশন ডেভেলপমেন্টে E2E টেস্টিং — এটি কী, পরিস্থিতি এবং টুলস

E2E টেস্টিং কী?

E2E টেস্টিং (End-to-End) একটি সফটওয়্যার টেস্টিং পদ্ধতি যেখানে টেস্ট সমস্ত সিস্টেম কম্পোনেন্টের মাধ্যমে একটি সম্পূর্ণ ব্যবহারকারীর পথ নির্বাহ করে। একটি মোবাইল অ্যাপ্লিকেশনের জন্য একটি সাধারণ E2E পরিস্থিতির মধ্যে রয়েছে: অ্যাপ চালু করা, নতুন ব্যবহারকারী নিবন্ধন, ইমেল নিশ্চিতকরণ, লক্ষ্য কর্ম সম্পাদন (অর্ডার দেওয়া, বার্তা পাঠানো) এবং ইন্টারফেসে ফলাফল যাচাই করা। প্রতিটি ধাপ বাস্তব কম্পোনেন্ট ব্যবহার করে — stubs বা mocks ছাড়া।

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

World Quality Report 2023 অনুসারে, যে টিমগুলি তাদের CI/CD পাইপলাইনে E2E টেস্টিং বাস্তবায়ন করেছে তারা রিলিজে গুরুত্বপূর্ণ ত্রুটির সংখ্যা 45% কমায়। তবে, সম্পূর্ণ E2E স্যুটের নির্বাহ সময় পরিস্থিতির সংখ্যার উপর নির্ভর করে 20 মিনিট থেকে 2 ঘন্টা পর্যন্ত হয়, যার জন্য একটি সুচিন্তিত সমান্তরাল নির্বাহ কৌশল প্রয়োজন।

কীভাবে E2E টেস্টিং ইন্টিগ্রেশন টেস্টিং থেকে আলাদা

প্রধান পার্থক্য যাচাইয়ের পরিধির মধ্যে রয়েছে। ইন্টিগ্রেশন টেস্ট অ্যাপ্লিকেশনের মধ্যে দুটি বা তিনটি কম্পোনেন্টের মিথস্ক্রিয়া যাচাই করে: রিপোজিটরির সাথে নেটওয়ার্ক স্তর, ViewModel-এর সাথে ডেটাবেস। E2E টেস্ট সম্পূর্ণ চেইন যাচাই করে: UI থেকে বাহ্যিক ব্যাকএন্ড এবং ফিরে। যদি একটি ইন্টিগ্রেশন টেস্ট যাচাই করে যে একটি API রিকোয়েস্ট সঠিক JSON ফেরত দেয়, তবে একটি E2E টেস্ট যাচাই করে যে ব্যবহারকারী সম্পূর্ণ লোডিং চক্রের পরে স্ক্রিনে সেই ডেটা দেখতে পায়।

রক্ষণাবেক্ষণ খরচও ভিন্ন। ইন্টিগ্রেশন টেস্ট নিয়ন্ত্রিত পরিবেশ — টেস্ট stubs এবং ইন-মেমরি ডেটাবেস নিয়ে কাজ করে, যা এগুলিকে স্থিতিশীল এবং দ্রুত করে তোলে। E2E টেস্ট বাহ্যিক সিস্টেমের অবস্থা, নেটওয়ার্ক প্রাপ্যতা এবং ব্যাকএন্ড সংস্করণের উপর নির্ভর করে, যা মিথ্যা ব্যর্থতার (flakiness) সম্ভাবনা বাড়ায়। Google Testing Blog (2021) অনুসারে, E2E টেস্ট ইন্টিগ্রেশন টেস্টের তুলনায় গড়ে 3–5 গুণ বেশি ভঙ্গুর, যার জন্য পুনরায় চেষ্টা ব্যবস্থা এবং স্থিতিশীলতা বিশ্লেষণ বাস্তবায়নের প্রয়োজন।

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

কোন পরিস্থিতি E2E টেস্ট দিয়ে কভার করতে হবে

প্রত্যেক ব্যবহারকারীর পরিস্থিতির E2E টেস্টের প্রয়োজন হয় না। নির্বাচনের মানদণ্ড তিনটি বিষয় অন্তর্ভুক্ত করে: পথ ব্যবহারের ফ্রিকোয়েন্সি, উৎপাদনে ব্যর্থতার খরচ এবং জড়িত সিস্টেমের সংখ্যা। একটি পরিস্থিতি যা প্রতিটি ব্যবহারকারী প্রথম লঞ্চে করে (অনবোর্ডিং, নিবন্ধন) একটি স্পষ্ট প্রার্থী। 5% ব্যবহারকারীর দ্বারা অ্যাক্সেস করা একটি অ্যাডমিন প্যানেল পরিস্থিতি ইন্টিগ্রেশন টেস্টিংয়ের জন্য প্রার্থী।

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

প্রতিটি পরিস্থিতির জন্য E2E টেস্টের একটি ন্যূনতম সেট নির্ধারণ করা হয় — একটি happy path এবং একটি error path (যেমন, মেয়াদোত্তীর্ণ টোকেন বা অনুপলব্ধ সার্ভার)। মৌলিক পরিস্থিতির বাইরে E2E কভারেজ সম্প্রসারণ অর্থনৈতিকভাবে ন্যায়সঙ্গত হওয়া উচিত: E2E টেস্টের ROI 10–15টি মূল পথ কভার করার পরে হ্রাস পায়, কারণ অতিরিক্ত E2E টেস্ট গুণমান আস্থায় আনুপাতিক উন্নতি প্রদান করে না।

E2E টেস্টিংয়ের জন্য টুলস

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

প্ল্যাটফর্ম-নির্দিষ্ট ফ্রেমওয়ার্ক

XCUITest — iOS-এর জন্য Apple-এর নেটিভ টুল, Xcode-এর অংশ। iOS-এর জন্য সবচেয়ে স্থিতিশীল এবং পারফরম্যান্ট অপশন, যা সিস্টেমের অ্যাক্সেসিবিলিটি স্তরে সরাসরি অ্যাক্সেস প্রদান করে। Espresso — Android-এর জন্য Google-এর নেটিভ ফ্রেমওয়ার্ক, AndroidX Test-এর অংশ। E2E পরিস্থিতির জন্য, Espresso AndroidX Test Orchestrator-এর সাথে টেস্ট বিচ্ছিন্নতা এবং পারস্পরিক হস্তক্ষেপ প্রতিরোধের জন্য ব্যবহৃত হয়। প্ল্যাটফর্ম-নির্দিষ্ট ফ্রেমওয়ার্কের অসুবিধা হল প্রতিটি প্ল্যাটফর্মের জন্য আলাদাভাবে টেস্ট লিখতে হবে।

ক্রস-প্ল্যাটফর্ম সমাধান

Appium — একটি WebDriver-ভিত্তিক টুল যা Java, Python, JavaScript এবং অন্যান্য ভাষা সমর্থন করে। Appium আর্কিটেকচারে একটি সার্ভার অন্তর্ভুক্ত যা কমান্ডগুলিকে প্ল্যাটফর্ম API-তে প্রক্সি করে — Android-এর জন্য UIAutomator এবং iOS-এর জন্য XCUITest। প্রতিটি ডিভাইসের জন্য Desired Capabilities কনফিগারেশন প্রয়োজন। Detox Wix-এর — React Native-এর জন্য একটি ফ্রেমওয়ার্ক যা JS থ্রেডের সাথে সিঙ্ক্রোনাইজ হয় এবং স্বয়ংক্রিয়ভাবে অ্যানিমেশন এবং নেটওয়ার্ক রিকোয়েস্ট সম্পূর্ণ হওয়ার জন্য অপেক্ষা করে। Detox Jest বা Mocha-এর সাথে ইন্টিগ্রেট হয় এবং সার্ভার সেটআপের প্রয়োজন নেই।

পরবর্তী প্রজন্মের টুলস

Maestro — একটি আধুনিক ফ্রেমওয়ার্ক যা পরিস্থিতি বর্ণনা করতে YAML ফাইল ব্যবহার করে। Maestro-র কম্পাইলেশনের প্রয়োজন নেই, হট রিলোড সমর্থন করে এবং ফলাফল বিশ্লেষণের জন্য একটি অন্তর্নির্মিত Flow Report প্রদান করে। টুলটি 10 মিনিটে CI-তে ইন্টিগ্রেট হয় এবং স্বয়ংক্রিয়ভাবে অ্যাপ্লিকেশন অবস্থার সাথে সিঙ্ক্রোনাইজ হয়, যা Appium-এর তুলনায় টেস্ট flakiness উল্লেখযোগ্যভাবে হ্রাস করে।

• Detox (Wix) — React Native-এর জন্য একটি ফ্রেমওয়ার্ক যা JS থ্রেডের সাথে সিঙ্ক্রোনাইজ হয়। Android এবং iOS সমর্থন করে, স্বয়ংক্রিয়ভাবে অ্যানিমেশন এবং নেটওয়ার্ক রিকোয়েস্ট সম্পূর্ণ হওয়ার জন্য অপেক্ষা করে।
• Appium — একটি ক্রস-প্ল্যাটফর্ম WebDriver-ভিত্তিক টুল যা যেকোনো প্রোগ্রামিং ভাষা সমর্থন করে।
• Maestro — YAML পরিস্থিতি সহ একটি আধুনিক ফ্রেমওয়ার্ক যার কম্পাইলেশনের প্রয়োজন নেই এবং 10 মিনিটে CI-তে ইন্টিগ্রেট হয়।

E2E টেস্টের জন্য কোড উদাহরণ

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

Maestro: YAML প্রমাণীকরণ পরিস্থিতি

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

# E2E: ব্যবহারকারী লগইন
appId: com.example.myapp
---
- launchApp
- waitForVisibile:
    text: "Email"
- tapOn:
    text: "Email"
- inputText:
    text: "user@example.com"
- tapOn:
    text: "Password"
- inputText:
    text: "secret123"
- tapOn:
    id: "loginButton"
- waitForVisibile:
    text: "Welcome back!"
- assertVisible:
    text: "Welcome back!"

Detox: React Native-এর জন্য E2E টেস্ট

Detox Wix-এর JS থ্রেডের সাথে স্বয়ংক্রিয় সিঙ্ক্রোনাইজেশনের মাধ্যমে টেস্ট স্থিতিশীলতা নিশ্চিত করে। টেস্ট sleep ব্যবহার করে না — Detox চেক করার আগে সমস্ত অ্যাসিঙ্ক্রোনাস অপারেশন সম্পূর্ণ হওয়ার জন্য অপেক্ষা করে।

describe('Login flow', () => {
    beforeEach(async () => {
        await device.reloadReactNative()
    })

    it('should login successfully', async () => {
        await expect(element(by.id('emailInput'))).toBeVisible()
        await element(by.id('emailInput')).typeText('user@example.com')
        await element(by.id('passwordInput')).typeText('secret123')
        await element(by.id('loginButton')).tap()
        await expect(element(by.text('ফিরে আসায় স্বাগতম!'))).toBeVisible()
    })
})

CI/CD পাইপলাইনে E2E টেস্টিং

CI/CD-তে E2E টেস্ট ইন্টিগ্রেট করা তাদের কার্যকারিতার একটি মূল কারণ। প্রস্তাবিত কৌশল হল একটি দ্বি-স্তরের পাইপলাইন: প্রতিটি পুল রিকোয়েস্টে 3–5টি গুরুত্বপূর্ণ E2E পরিস্থিতির একটি ন্যূনতম স্মোক স্যুট চালানো হয়, এবং সম্পূর্ণ রিগ্রেশন স্যুট রাতে (nightly build) বা রিলিজের আগে চলে। এই পদ্ধতি ফিডব্যাক গতি এবং যাচাইয়ের গভীরতার মধ্যে ভারসাম্য রাখে।

CI-তে E2E টেস্টের জন্য তিনটি দিক গুরুত্বপূর্ণ: সমান্তরালকরণ — Firebase Test Lab বা AWS Device Farm-এর মাধ্যমে একাধিক ডিভাইসে একই সাথে টেস্ট চালানো নির্বাহ সময় ঘন্টা থেকে মিনিটে কমিয়ে আনে; পরিবেশ কন্টেইনারাইজেশন — ব্যাকএন্ড এবং টেস্ট সার্ভারের জন্য Docker ব্যবহার পুনরুৎপাদনযোগ্যতা নিশ্চিত করে; রিপোর্টিং এবং পুনরায় চেষ্টা — ব্যর্থ টেস্টের স্বয়ংক্রিয় পুনরারম্ভ (2টি প্রচেষ্টা পর্যন্ত) এবং প্রতিটি পরিস্থিতি নির্বাহের ভিডিও সহ HTML রিপোর্ট তৈরি।

Google Testing Blog (2022) অনুসারে, সমান্তরাল নির্বাহ সহ একটি ডেডিকেটেড E2E CI পাইপলাইন ব্যবহারকারী টিমগুলি রিগ্রেশন সনাক্তকরণ সময় 60% কমায়। E2E টেস্ট কার্যকারিতার মূল মেট্রিক টেস্টের সংখ্যা নয়, বরং মিথ্যা ব্যর্থতা ছাড়া সফল CI রানের শতাংশ। লক্ষ্য সূচক হল গুরুত্বপূর্ণ পথের সম্পূর্ণ কভারেজ সহ 95% এর উপরে E2E স্যুট স্থিতিশীলতা।