TesterArmy e2e: Workshop การทดสอบ Web และ Mobile ด้วย Agentic AI

• 1. แนวคิดและปัญหาที่ e2e ต้องการแก้ไข
• 2. สถาปัตยกรรมการทำงาน
• 3. สิ่งที่ต้องเตรียม
• 4. Workshop A: ติดตั้งและรันเทสต์เว็บครั้งแรก
  • 4.1 เตรียมแอปตัวอย่าง
  • 4.2 สร้างการตั้งค่า e2e
  • 4.3 เขียน Smoke Test แบบ Deterministic
  • 4.4 อ่านผลลัพธ์
• 5. Workshop B: เพิ่มการทดสอบแบบ Agentic AI
  • 5.1 เลือกโมเดล
  • 5.2 ตัวอย่าง Hybrid Test
• 6. Workshop C: API Testing ภายในชุดทดสอบเดียวกัน
• 7. Replay Cache ลดการเรียกโมเดลอย่างไร
• 8. การทำงานร่วมกับ Coding Agent และ MCP
• 9. CI/CD ด้วย GitHub Actions
• 10. Workshop D: Visual Regression Testing ด้วย Screenshot
• 11. ทางเลือกเพิ่มเติม: Decision Models สำหรับ Agentic Testing
• 12. การจัดการข้อมูลลับและข้อจำกัด
• 13. เปรียบเทียบ e2e กับ Playwright
• 14. แนวทางออกแบบการทดลองสำหรับรายวิชา Software Testing
• 15. ปัญหาที่พบบ่อยและแนวทางตรวจสอบ
• 16. สรุป
• แหล่งอ้างอิง

สรุป: e2e เป็นเฟรมเวิร์กทดสอบ End-to-End แบบโอเพนซอร์สจาก TesterArmy เขียนด้วย TypeScript ผสมคำสั่งภาษาธรรมชาติที่ให้ AI Agent ดำเนินการ (agent.act) กับคำสั่งค้นหาองค์ประกอบและตรวจผลที่ระบุเงื่อนไขชัดเจน (locator / expect) ภายในเทสต์เดียว รองรับเว็บ iOS และ Android และมีระบบบันทึก/เล่นซ้ำขั้นตอน Agent ที่ตรวจยืนยันสำเร็จเพื่อลดการเรียกโมเดลในการรันครั้งต่อไป

#1. แนวคิดและปัญหาที่ e2e ต้องการแก้ไข

การทดสอบ E2E แบบสคริปต์ทั่วไปมีจุดแข็งด้านความแม่นยำและตรวจซ้ำได้ แต่ผู้เขียนต้องรู้ขั้นตอนและตำแหน่งองค์ประกอบ UI ส่วนการใช้ AI Agent ทำตามเป้าหมายที่บรรยายเป็นภาษาธรรมชาติมีความยืดหยุ่นเมื่อ UI เปลี่ยน แต่ผลลัพธ์อาจไม่แน่นอนและมีค่าใช้จ่ายโมเดล

TesterArmy e2e ใช้แนวทาง Hybrid Agentic + Deterministic Testing:

1. ผู้ทดสอบระบุ เป้าหมายหนึ่งอย่าง ให้ agent.act(...) ตัดสินใจว่าจะคลิก กรอก หรือเลื่อนอย่างไร
2. ใช้ expect(...) กับ locator หรือ agent.assert(...) ยืนยันผลลัพธ์
3. หากขั้นตอน agent.act ผ่านการตรวจยืนยัน ระบบสามารถบันทึกลำดับการกระทำเพื่อเล่นซ้ำในรอบถัดไป โดยไม่เรียก AI สำหรับขั้นตอนที่เล่นซ้ำได้
4. หาก UI เปลี่ยนจนเล่นซ้ำไม่ได้ ระบบสามารถส่งการควบคุมคืนให้ Agent เพื่อดำเนินการต่อได้

หมายเหตุ: การเล่นซ้ำไม่ได้ทำให้การตรวจผลทั้งหมดไม่เรียกโมเดล: agent.assert, agent.waitFor และ agent.extract ของ Agent ที่มากับระบบยังประเมินผลแบบ live และเรียกโมเดลตามเอกสาร

#2. สถาปัตยกรรมการทำงาน

flowchart TD
  A[TypeScript Test] --> B[e2e Test Runner]
  B --> C{ประเภทขั้นตอน}
  C -->|Exact action / assertion| D[Locator + expect]
  C -->|Natural language goal| E[agent.act]
  E --> F{มี Replay ที่ใช้ได้?}
  F -->|มี| G[Replay recorded actions]
  F -->|ไม่มี / UI เปลี่ยน| H[AI Model / Agent executor]
  H --> I[Web / iOS / Android Engine]
  G --> I
  D --> I
  I --> J[แอปพลิเคชันที่ทดสอบ]
  J --> K[Verification + Report]
  K -->|ยืนยันสำเร็จ| L[Save verified actions]
  L --> F

เครื่องมือสำคัญ:

นอกจากนี้มีการใช้งานร่วมกับ Coding Agents ผ่าน Skill / MCP Server, การทดสอบ API ด้วย fetch, การต่อ GitHub Actions และตัวเลือกผู้ให้บริการโมเดลหลายราย

#3. สิ่งที่ต้องเตรียม

• Node.js 24.8 ขึ้นไป หรือ 22.22.3 ขึ้นไปในสาย Node.js 22 ตาม Quickstart ณ วันที่ตรวจสอบ
• โปรเจกต์ Web ที่รันในเครื่องได้ (ตัวอย่างใช้ http://localhost:3000)
• Terminal และโปรแกรมแก้ไขโค้ด เช่น VS Code
• หากใช้ AI Agent ต้องกำหนดผู้ให้บริการโมเดล/สิทธิ์การใช้งานที่รองรับ; เทสต์ที่ไม่มีขั้นตอน Agent ไม่ต้องเรียก AI
• Windows: เอกสารแนะนำให้ใช้งานภายใน WSL
• หากทดสอบ Mobile: ต้องมี Xcode พร้อม Simulator runtime (iOS) หรือ Android SDK พร้อม Emulator (Android)

เวิร์กช็อปนี้เป็น ตัวอย่างโค้ดสำหรับประยุกต์ใช้กับโปรเจกต์ของผู้อ่าน ไม่ใช่ผลยืนยันจากการรันจริงในสภาพแวดล้อมของผู้เขียน

#4. Workshop A: ติดตั้งและรันเทสต์เว็บครั้งแรก

#4.1 เตรียมแอปตัวอย่าง

เปิด Terminal ที่โฟลเดอร์โปรเจกต์ Web ที่มีคำสั่งเริ่มเซิร์ฟเวอร์แล้ว เช่นโปรเจกต์ Next.js/Vite ที่กำหนดให้รันที่พอร์ต 3000 จากนั้นเริ่มแอปในอีก Terminal:

npm install
npm run dev

ถ้าโปรเจกต์ของคุณใช้พอร์ตอื่น ให้แก้ URL ใน e2e.config.ts ให้ตรงกับแอป

#4.2 สร้างการตั้งค่า e2e

npx e2e init

Wizard ให้เลือก Web หรือ Mobile และให้เลือกการใช้งานโมเดล (หรือ None เพื่อเริ่มด้วยเทสต์ไม่ใช้ AI) แล้วสร้างไฟล์ตั้งค่าและตัวอย่างเทสต์ให้ การติดตั้งตาม Wizard เป็นวิธีหลักที่เอกสารแนะนำ

ตัวอย่าง คอนฟิกแบบไม่ใช้ AI สำหรับเว็บที่กำลังรันอยู่:

// e2e.config.ts
import type { E2EConfig } from 'e2e';
import { web } from '@e2e-dev/web';

export default {
  targets: [
    {
      engine: web(),
      app: { url: 'http://localhost:3000' },
    },
  ],
} satisfies E2EConfig;

#4.3 เขียน Smoke Test แบบ Deterministic

// tests/smoke.e2e.ts
import { test } from '@e2e-dev/web';
import { expect } from 'e2e';

test('หน้าเว็บหลักสามารถเปิดได้', async ({ app, browser }) => {
  await app.open('/');
  await expect(browser.locator('body')).toBeVisible();
});

รันเทสต์:

npx e2e run

หรือระบุไฟล์ที่ต้องการ:

npx e2e run tests/smoke.e2e.ts

ทดสอบแบบเปิดหน้าต่างเบราว์เซอร์ (headed mode):

npx e2e run tests/smoke.e2e.ts --headed

#4.4 อ่านผลลัพธ์

หากผ่าน แสดงว่าการตั้งค่า target, ตัวรัน และการเปิดแอปทำงานได้ตามเงื่อนไข Smoke Test นี้ ยังไม่ได้ยืนยัน Business Logic ควรเพิ่มกรณีทดสอบที่ตรวจผลตามความต้องการของระบบ

#5. Workshop B: เพิ่มการทดสอบแบบ Agentic AI

#5.1 เลือกโมเดล

รัน Wizard อีกครั้งหรือแก้ agents.default.model ให้ตรงกับ Provider ที่รองรับตามเอกสาร Models แทนการคัดลอกชื่อโมเดลสมมติ สำหรับบางแผนสมัครสมาชิก เอกสารแสดงคำสั่งเข้าสู่ระบบ เช่น:

npx e2e login openai

ข้อควรระวัง: ความสามารถล็อกอินด้วย subscription ขึ้นอยู่กับผู้ให้บริการและเงื่อนไขแผนของบัญชี ไม่ใช่ทุกบริการ/โมเดลจะใช้วิธีเดียวกัน อย่าส่ง API key ไปไว้ใน Git Repository

#5.2 ตัวอย่าง Hybrid Test

สมมติแอปมีหน้า /todos โดยมีปุ่มเพิ่มรายการ, ช่องรายการงาน และองค์ประกอบ data-testid="todo" ให้ปรับชื่อปุ่ม/หน้าให้ตรงกับแอปจริง:

// tests/todos.e2e.ts
import { test, expect } from 'e2e';

test('เพิ่มรายการงานด้วย Agent และตรวจผลแบบแม่นยำ', async ({ app, agent, screen }) => {
  await app.open('/todos');

  await agent.act('เพิ่มรายการงานชื่อ Buy milk หนึ่งรายการ');

  // ตรวจด้วย locator: ชัดเจน และไม่ต้องใช้โมเดล
  await expect(screen.getByTestId('todo')).toHaveCount(1);

  await agent.act('ทำเครื่องหมาย Buy milk ว่าเสร็จแล้ว');

  // ตรวจเชิงความหมายเมื่อ UI มีหลายรูปแบบ
  await agent.assert('รายการ Buy milk แสดงสถานะว่าเสร็จแล้ว');
});

เงื่อนไขก่อนรัน: แอปต้องมีเส้นทางและหน้าจอที่สอดคล้องกับข้อความข้างต้น และต้องกำหนด Agent/Model ไว้แล้ว ตัวอย่างนี้ไม่ใช่ชุดทดสอบที่รันได้ทันทีบนเว็บไซต์ใด ๆ

แนวทางออกแบบที่สำคัญ: สั่ง หนึ่งเป้าหมายที่ตรวจยืนยันได้ต่อหนึ่ง agent.act() และตามด้วยการตรวจผล อย่ารวมการเปิดหน้า เลือกสินค้า ชำระเงิน และตรวจใบเสร็จในคำสั่งเดียว

#6. Workshop C: API Testing ภายในชุดทดสอบเดียวกัน

e2e รองรับการทดสอบ API ด้วย fetch และ value matcher ใน test runner เดียวกับ UI โดยไม่จำเป็นต้องใช้ Agent

// tests/health-api.e2e.ts
import { test, expect } from 'e2e';

test('GET /api/health ตอบ HTTP 200', async ({ app }) => {
  const response = await fetch(new URL('/api/health', app.baseUrl));
  expect(response.status).toBe(200);
  expect(response.headers.get('content-type')).toContain('application/json');
});

endpoint /api/health เป็นตัวอย่าง ต้องมีจริงในแอป จึงจะผ่านการทดสอบ

สำหรับการตรวจข้อมูลแบบมีโครงสร้าง e2e ยังรองรับ toMatchSchema(...) กับ Standard Schema เช่น Zod ตามเอกสาร API Testing

#7. Replay Cache ลดการเรียกโมเดลอย่างไร

กระบวนการโดยย่อ:

1. การรันครั้งแรก Agent ปฏิบัติตาม agent.act('...')
2. ขั้นตอนถัดมามีการยืนยันผล เช่น expect(locator).toHaveText(...) หรือ agent.assert(...)
3. เมื่อผลได้รับการยืนยัน และเข้าเงื่อนไขบันทึก ระบบเก็บลำดับการกระทำของ act
4. การรันครั้งถัดไปทดลองเล่นซ้ำการกระทำจาก Cache โดยไม่ใช้โมเดล สำหรับช่วงที่เล่นซ้ำได้
5. ถ้า replay ใช้ไม่ได้เพราะ UI เปลี่ยน Agent อาจรับช่วงทำงานต่อจากสถานะปัจจุบัน

ทดลองข้าม Cache:

npx e2e run --no-cache

รายละเอียดที่ควรจำ:

• ไม่ใช่ทุกการเรียก act จะถูก Cache: ต้องมีการยืนยันผลที่เข้าเงื่อนไข
• agent.assert, agent.waitFor, agent.extract ของ Agent ปกติยังประเมินสด ไม่ใช่คำสั่งที่ Replay Cache ให้ผลโดยอัตโนมัติ
• การใช้ Agent มีทั้ง latency, จำนวน token และความเสี่ยงที่คำสั่งกำกวม ซึ่งควรวัดจริง

#8. การทำงานร่วมกับ Coding Agent และ MCP

เอกสารมีแนวทางให้ Coding Agents เช่น Claude Code, Codex และ Cursor ช่วยติดตั้ง ท่อง UI สร้างเทสต์ และอ่านรายงานข้อผิดพลาด โดยอาศัย Agent Skill และ MCP Server ของโครงการ

แนวทางสอนในห้องปฏิบัติการ:

1. ให้ Coding Agent สำรวจหน้า UI ที่กำหนดก่อน
2. ให้สร้างกรณีทดสอบ 2 แบบสำหรับฟีเจอร์เดียวกัน: แบบ locator ล้วน และแบบ hybrid
3. ตรวจสอบการใช้ getByRole, getByLabel, getByTestId ว่าตรงกับ UI จริง
4. ให้ Agent แก้เทสต์ที่ล้มเหลวโดยอ้างอิงรายงาน ไม่ใช่เพียงเปลี่ยน assertion ให้ผ่าน
5. บันทึกเวลาและจำนวนครั้งที่เรียกโมเดลเมื่อรันซ้ำ

การเปิด MCP ให้ Agent เข้าถึงสภาพแวดล้อมต้องกำหนดสิทธิ์อย่างรอบคอบ และไม่ควรทดสอบงานที่เปลี่ยนข้อมูลจริงโดยไม่มีขอบเขตหรือบัญชีทดสอบ

#9. CI/CD ด้วย GitHub Actions

เอกสารทางการมี workflow สำหรับเว็บและมือถือ รวมทั้งการจัดเก็บ .e2e/report.json และ .e2e/results ตัวอย่างโครงสร้างขั้นตอนสำหรับเว็บ:

name: E2E checks
on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '24'
          cache: 'npm'
      - run: npm ci
      - name: Install Chromium and OS dependencies
        run: npx e2e-web install chromium --with-deps
      - name: Run tests
        run: npx e2e run
      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: e2e-results
          path: |
            .e2e/report.json
            .e2e/results
          if-no-files-found: warn

เงื่อนไขของตัวอย่าง: โปรเจกต์มี package-lock.json, ติดตั้ง e2e และ @e2e-dev/web แล้ว และตั้ง app.command ใน e2e.config.ts ให้ Runner เริ่มแอปเองได้ (หรือเตรียมบริการแอปก่อนขั้น Run tests) หากมี Agent Steps ให้ตั้งค่า credentials ผ่าน GitHub Secrets ตามเอกสารของ Provider ก่อน จึงจะใช้กับ CI จริงได้

#10. Workshop D: Visual Regression Testing ด้วย Screenshot

นอกจากข้อความและสถานะขององค์ประกอบแล้ว e2e รองรับการเปรียบเทียบ ภาพหน้าจอกับ Baseline (Golden Screenshot) ผ่าน toHaveScreenshot() ได้ทั้ง Web, iOS และ Android บนเอนจินที่รองรับการจับภาพ โดยไม่ต้องใช้ Agent ในกรณีปกติ

// tests/visual.e2e.ts
import { test, expect } from 'e2e';

test('หน้าหลักมีหน้าตาตรงกับ baseline', async ({ app, screen }) => {
  await app.open('/');

  // เปรียบเทียบภาพหน้าจอทั้งหน้า
  await expect(screen).toHaveScreenshot('home.png');
});

เมื่อรันครั้งแรก หากยังไม่มีภาพ Baseline เฟรมเวิร์กจะบันทึกภาพและ ถือว่าเทสต์ไม่ผ่าน เพื่อให้ตรวจภาพก่อนยอมรับ จากนั้นอัปเดตภาพที่ต้องการใช้เป็น Baseline ด้วย:

npx e2e run --update-snapshots
npx e2e run

ภาพ Baseline แยกตาม target และระบบปฏิบัติการ เพื่อหลีกเลี่ยงความต่างของฟอนต์หรือการแสดงผล ตัวอย่างการอนุญาตให้ภาพต่างกันไม่เกิน 1% และปิดพื้นที่ที่มีค่าเวลาเปลี่ยนทุกครั้ง:

await expect(screen).toHaveScreenshot('dashboard.png', {
  maxDiffPixelRatio: 0.01,
  mask: [screen.getByTestId('last-updated')],
});

แนวทางที่เหมาะสม: ตรวจ Baseline ก่อนยอมรับทุกครั้ง กำหนดขนาดหน้าจอให้แน่นอน และอย่าตั้ง tolerance สูงเพื่อทำให้ความผิดพลาดที่แท้จริงถูกมองข้าม

อ้างอิง: https://e2e.tester.army/docs/visual-testing

#11. ทางเลือกเพิ่มเติม: Decision Models สำหรับ Agentic Testing

TesterArmy e2e มี @e2e-dev/decision ซึ่งใช้ Decision Model เลือกการกระทำและองค์ประกอบเป้าหมาย แทนการให้ Language Model ตัดสินใจทุกอย่าง โดยใช้ Text Model ขนาดเล็กช่วยสร้างค่าข้อความสำหรับฟิลด์ที่ต้องกรอก วิธีนี้น่าสนใจสำหรับงานวิจัยการเปรียบเทียบ Agent Executors แต่ ไม่ได้รับประกัน ว่าจะเร็วกว่า ถูกกว่า หรือแม่นยำกว่าในทุกกรณี ต้องทดสอบด้วยชุดข้อมูลของตนเอง

ตัวอย่างแนวคิดการติดตั้งโดยใช้ TypeSafe AI (Jev) และ OpenRouter ตามหน้า Decision Models:

npm install -D @e2e-dev/decision @ai-sdk/typesafe-ai @openrouter/ai-sdk-provider

// e2e.config.ts — ตัวอย่างทางเลือก แทนที่ config ของ Agent แบบ LLM
import type { E2EConfig } from 'e2e';
import { web } from '@e2e-dev/web';
import { decisionExecutor } from '@e2e-dev/decision';
import { typeSafeAi } from '@ai-sdk/typesafe-ai';
import { openrouter } from '@openrouter/ai-sdk-provider';

export default {
  targets: [{ engine: web(), app: { url: 'http://localhost:3000' } }],
  agents: {
    default: {
      executor: decisionExecutor({
        model: typeSafeAi.decisionModel('jev-latest'),
        textModel: openrouter('inception/mercury-2.5'),
      }),
    },
  },
} satisfies E2EConfig;

ตัวอย่างนี้ต้องใช้บัญชีและ API credentials ของผู้ให้บริการที่เลือก รวมถึงแพ็กเกจ ai ที่เข้ากันได้ตามข้อกำหนดของเอกสาร และไม่ใช่เส้นทางเริ่มต้นสำหรับผู้ที่เพิ่งเรียนรู้ e2e ครั้งแรก

มุมมองเชิงวิจัยที่น่าสนใจ คือเปรียบเทียบ LLM Agent vs Decision-Model Executor vs Deterministic-Only โดยควบคุมข้อมูลทดสอบและสภาพแวดล้อมให้เหมือนกัน พร้อมรายงานอัตราสำเร็จ ความแปรปรวน ค่าใช้จ่าย และเวลาแยกกัน

อ้างอิง: https://e2e.tester.army/docs/decision-models

#12. การจัดการข้อมูลลับและข้อจำกัด

• ใช้กลไก Secret ที่ e2e มีให้กับรหัสผ่าน ไม่แทรกรหัสผ่านเป็นข้อความตรงในคำสั่งภาษาธรรมชาติ
• เอกสารระบุว่ารันเนอร์ลดโอกาสส่งข้อมูลลับให้โมเดล แต่ ไม่ได้หมายความว่า Artifact ทุกชนิดถูกปิดบัง: วิดีโอ ดาวน์โหลดบางชนิด และ log ของแอปอาจยังมีข้อมูลอ่อนไหว
• ตรวจสอบ screenshots, recordings, logs และรายงานก่อนอัปโหลดหรือเผยแพร่
• ทดสอบบน staging/test environment และใช้ test data ที่ไม่กระทบบัญชีจริง
• AI Agent มีความเสี่ยงเรื่องความไม่แน่นอนและต้นทุนของโมเดล จึงควรใช้ Locator/Assertions ที่แน่นอนตรงจุดที่ทำได้
• โครงการอยู่ระหว่างพัฒนาไปสู่ 1.0: pin dependency version ในโครงการจริงและตรวจ changelog ก่อนอัปเกรด

#13. เปรียบเทียบ e2e กับ Playwright

ข้อสรุปเชิงวิศวกรรม: e2e ไม่จำเป็นต้องมาแทน Playwright ทั้งระบบ เหมาะกับการทดลองใช้ Hybrid Testing ในกรณีที่ flow ของ UI เปลี่ยนบ่อยหรือเขียนสคริปต์ยาก ขณะที่ assertion สำคัญยังควรตรวจแบบกำหนดเงื่อนไขชัดเจน

#14. แนวทางออกแบบการทดลองสำหรับรายวิชา Software Testing

ให้นักศึกษาพัฒนา UI อย่างน้อย 3 ฟังก์ชัน ได้แก่ Login, CRUD Todo และ Checkout แบบจำลอง แล้วสร้างชุดทดสอบสองกลุ่ม: (A) deterministic-only และ (B) hybrid agentic

กำหนดชุดกรณีทดสอบและข้อมูลทดสอบเดียวกัน รันซ้ำหลายรอบภายใต้ UI เดิม และทดลอง UI ที่เปลี่ยนชื่อ/ตำแหน่งปุ่ม จากนั้นเก็บตัวชี้วัด:

ควรแยกผลลัพธ์ ผลผ่านที่ตรวจด้วย assertion จริง ออกจากเพียงการที่ Agent ทำครบขั้นตอน และไม่ถือว่าการลด Model Calls เป็นหลักฐานว่าคุณภาพของระบบดีขึ้นโดยอัตโนมัติ

#15. ปัญหาที่พบบ่อยและแนวทางตรวจสอบ

การแก้ปัญหาควรเริ่มจากอ่าน .e2e/report.json และไฟล์ภายใน .e2e/results/ ไม่ควรแก้ assertion ให้หลวมลงเพียงเพื่อให้สถานะผ่าน

#16. สรุป

TesterArmy e2e เสนอวิธีเขียน E2E Test ที่ให้นักพัฒนา เลือกใช้ AI เฉพาะช่วงที่ต้องการความยืดหยุ่น และใช้ locator กับ assertion ในช่วงที่ต้องการผลแน่นอน โดยมี replay cache ช่วยลดการเรียกโมเดลสำหรับขั้นตอนที่เคยผ่านการยืนยันแล้ว จุดน่าสนใจสำหรับสาย Software Engineering ได้แก่ Hybrid Testing, Multi-platform Testing, Test Automation with Coding Agents, และการทดลองด้านความน่าเชื่อถือกับต้นทุนของ AI-Assisted Testing

#แหล่งอ้างอิง

1. TesterArmy e2e documentation — https://e2e.tester.army/docs
2. Quickstart — https://e2e.tester.army/docs/quickstart
3. Core concepts — https://e2e.tester.army/docs/core-concepts
4. Web engine — https://e2e.tester.army/docs/web
5. Replay caching — https://e2e.tester.army/docs/cache
6. API Testing — https://e2e.tester.army/docs/api-testing
7. Visual Comparison — https://e2e.tester.army/docs/visual-testing
8. Decision Models — https://e2e.tester.army/docs/decision-models
9. GitHub Actions — https://e2e.tester.army/docs/ci/github-actions
10. Security — https://e2e.tester.army/docs/security
11. GitHub repository — https://github.com/tester-army/e2e
12. GitHub Actions — https://e2e.tester.army/docs/ci/github-actions
13. Security — https://e2e.tester.army/docs/security
14. GitHub Repository — https://github.com/tester-army/e2e
15. Introducing e2e (1 October 2026) — https://tester.army/blog/introducing-e2e