Thanawat Wongchai

Posted on May 22 • Originally published at apidog.com

ประเภทของ Automation Testing Framework และวิธีเลือกให้เหมาะกับทีม

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

ลองใช้ Apidog วันนี้

บทความนี้สรุปเฟรมเวิร์กการทดสอบอัตโนมัติ 6 ประเภทที่ใช้บ่อย ได้แก่ linear, modular, data-driven, keyword-driven, hybrid และ behavior-driven หรือ BDD พร้อมวิธีคิดเชิงปฏิบัติว่าแต่ละแบบเหมาะกับสถานการณ์ใด ควรเริ่มอย่างไร และต้องระวังอะไร แนวคิดเหล่านี้ใช้ได้กับ UI testing, API testing และ unit testing

เฟรมเวิร์กการทดสอบระบบอัตโนมัติคืออะไร

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

เฟรมเวิร์กควรตอบคำถามเหล่านี้ก่อนเริ่มเขียนเทสต์:

ข้อมูลทดสอบเก็บไว้ที่ไหน
ขั้นตอนที่ใช้ซ้ำ เช่น login หรือ create user แชร์กันอย่างไร
ใครเขียนเทสต์ได้บ้าง เฉพาะวิศวกรหรือรวม QA/business analyst
จะรันเทสต์อย่างไรใน CI
รายงานผลและ debug failure อย่างไร

ถ้าคุณยังใหม่กับภาพรวมของ automation testing อ่านพื้นฐานเพิ่มเติมได้ที่ การทดสอบอัตโนมัติคืออะไร

เหตุผลที่เรื่องนี้สำคัญคือ “การบำรุงรักษา” การเขียนเทสต์อัตโนมัติ 100 รายการแรกมักไม่ยาก แต่การดูแลเทสต์ 1,000 รายการในระบบที่เปลี่ยนทุกสัปดาห์คือปัญหาจริง ประเภทเฟรมเวิร์กเป็นปัจจัยหลักที่กำหนดต้นทุนนี้

ตัวอย่างง่าย ๆ: ถ้าหน้า login เปลี่ยนชื่อ field จาก username เป็น email

เฟรมเวิร์กที่ดี: แก้ selector หรือ helper เดียว เทสต์ทั้งหมดกลับมาผ่าน
เฟรมเวิร์กที่ไม่ดี: ต้องแก้สคริปต์ 200 ไฟล์ที่ copy-paste ขั้นตอน login ไว้

แอปพลิเคชันเดียวกัน แต่ต้นทุนต่างกันเพราะโครงสร้างเฟรมเวิร์กต่างกัน

หกประเภทของเฟรมเวิร์ก

1. Linear หรือเชิงเส้น

Linear framework คือการบันทึกและเล่นซ้ำขั้นตอนแบบตรงไปตรงมา เทสต์แต่ละรายการเป็นสคริปต์เดี่ยว ไม่มี shared function ไม่มี test data แยกออกจาก logic และมักเกิดจาก record-and-playback tool

ตัวอย่างลักษณะสคริปต์:

await page.goto('/login')
await page.fill('#email', 'user@example.com')
await page.fill('#password', 'password')
await page.click('#login')
await expect(page.locator('#dashboard')).toBeVisible()

ถ้าต้องทดสอบอีก workflow หนึ่ง ก็มัก copy ขั้นตอนเดิมไปวางใหม่

ใช้เมื่อไหร่

เหมาะกับ:

demo สั้น ๆ
proof of concept
script ที่ใช้ครั้งเดียว
โปรเจกต์เล็กมากและอายุสั้น

ข้อดี

เริ่มเร็ว
ไม่ต้องออกแบบโครงสร้างมาก
เหมาะกับผู้เริ่มต้นหรือการทดลอง tool

ข้อเสีย

reuse แทบไม่มี
แก้ UI หนึ่งจุดอาจต้องแก้หลายไฟล์
scale ไม่ดี
test suite โตแล้ว maintenance cost สูงมาก

แนวทางปฏิบัติ: ถ้าเทสต์เริ่มมีขั้นตอนซ้ำเกิน 3–5 จุด เช่น login, search, checkout ให้เริ่มย้ายไป modular framework

2. Modular หรือแบบโมดูล

Modular framework แบ่งแอปออกเป็น module หรือ reusable function เช่น login, search product, add to cart, checkout แล้วให้เทสต์ประกอบจากฟังก์ชันเหล่านั้น

ตัวอย่าง:

async function login(page, email, password) {
  await page.goto('/login')
  await page.fill('#email', email)
  await page.fill('#password', password)
  await page.click('#login')
}

async function searchProduct(page, keyword) {
  await page.fill('#search', keyword)
  await page.click('#search-button')
}

เทสต์จริงจะอ่านง่ายขึ้น:

test('user can search product after login', async ({ page }) => {
  await login(page, 'user@example.com', 'password')
  await searchProduct(page, 'keyboard')
  await expect(page.locator('.product-list')).toBeVisible()
})

เมื่อหน้า login เปลี่ยน คุณแก้ที่ login() ที่เดียว

ใช้เมื่อไหร่

เหมาะกับทีมวิศวกรส่วนใหญ่ โดยเฉพาะเมื่อ:

เทสต์ต้องอยู่มากกว่าหนึ่งไตรมาส
มี workflow ซ้ำหลายจุด
ต้องการลด copy-paste
ทีมมีคนเขียนโค้ดดูแลเทสต์ได้

ข้อดี

reuse สูง
maintain ง่ายกว่า linear
เป็นฐานที่ดีสำหรับ hybrid framework
debug ง่ายถ้าออกแบบ module ดี

ข้อเสีย

ต้องออกแบบ abstraction ตั้งแต่ต้น
ต้องตกลง naming และ module boundary
ถ้าแยก module ผิด อาจกลายเป็น abstraction ที่สับสน

สำหรับแนวทางเขียนสคริปต์ให้ maintain ได้ อ่านเพิ่มที่ วิธีการเขียนสคริปต์ทดสอบอัตโนมัติ

3. Data-driven หรือขับเคลื่อนด้วยข้อมูล

Data-driven framework แยก test logic ออกจาก test data เทสต์หนึ่งชุดสามารถรันซ้ำกับข้อมูลหลายแถวจาก CSV, JSON, spreadsheet หรือ database

ตัวอย่างข้อมูล login-cases.json:

[
  {
    "email": "valid@example.com",
    "password": "correct-password",
    "expected": "success"
  },
  {
    "email": "invalid@example.com",
    "password": "wrong-password",
    "expected": "error"
  }
]

ตัวอย่าง test logic:

import cases from './login-cases.json'

for (const item of cases) {
  test(`login case: ${item.email}`, async ({ page }) => {
    await page.goto('/login')
    await page.fill('#email', item.email)
    await page.fill('#password', item.password)
    await page.click('#login')

    if (item.expected === 'success') {
      await expect(page.locator('#dashboard')).toBeVisible()
    } else {
      await expect(page.locator('.error')).toBeVisible()
    }
  })
}

ใช้เมื่อไหร่

เหมาะกับกรณีที่ workflow เดิมต้องทดสอบกับ input หลายแบบ เช่น:

valid/invalid login
boundary values
หลายภาษา หลาย locale
API request เดียวแต่ payload หลายชุด
form validation

สำหรับ API testing โดยเฉพาะ แนวทาง การทดสอบที่ขับเคลื่อนด้วยข้อมูลโดยใช้ CSV และ JSON ช่วยเปลี่ยน request เดียวให้กลายเป็น test case จำนวนมากได้

ข้อดี

เพิ่ม coverage ด้วยการเพิ่มข้อมูล ไม่ใช่เพิ่มโค้ด
ลด duplication
เหมาะกับ API และ validation-heavy workflow
QA ที่ไม่ถนัดโค้ดอาจช่วยเพิ่ม test data ได้

ข้อเสีย

test logic มักค่อนข้างคงที่
ไม่เหมาะกับ workflow ที่แตกต่างกันมาก
test data ต้องมี schema และ naming ที่ชัดเจน
ข้อมูลจำนวนมากอาจทำให้ debug ยากถ้าไม่มี report ที่ดี

แนวทางปฏิบัติ: เริ่มจาก data-driven เฉพาะจุดที่ input หลากหลายจริง ๆ อย่าเปลี่ยนทุกเทสต์ให้เป็น data table โดยไม่จำเป็น

4. Keyword-driven หรือขับเคลื่อนด้วยคีย์เวิร์ด

Keyword-driven framework แปลง action เป็น keyword เช่น Login, SearchProduct, VerifyTotal แล้วให้ผู้ใช้สร้าง test case ด้วยตาราง keyword พร้อม argument

ตัวอย่างตาราง:

Step	Keyword	Argument 1	Argument 2
1	Login	user@example.com	password
2	SearchProduct	keyboard
3	AddToCart	SKU-001
4	VerifyTotal	1200

เบื้องหลัง วิศวกรต้อง implement keyword เหล่านี้:

const keywords = {
  Login: async (page, email, password) => {
    await page.goto('/login')
    await page.fill('#email', email)
    await page.fill('#password', password)
    await page.click('#login')
  },

  SearchProduct: async (page, keyword) => {
    await page.fill('#search', keyword)
    await page.click('#search-button')
  }
}

ใช้เมื่อไหร่

เหมาะกับทีมที่:

QA analyst หรือ business user ต้องช่วยสร้างเทสต์
ต้องการให้ test case อ่านเป็นขั้นตอนเชิงธุรกิจ
มีวิศวกรคอยดูแล keyword library

ข้อดี

คนที่ไม่ใช่โปรแกรมเมอร์อ่านและสร้างเทสต์ได้ง่ายขึ้น
standardize ขั้นตอนซ้ำ ๆ ได้ดี
เหมาะกับองค์กรที่แยกบทบาท test design กับ test implementation

ข้อเสีย

ต้องสร้างและดูแล keyword library
keyword ที่ออกแบบไม่ดีจะกลายเป็นภาระ
ถ้ามี keyword เยอะเกินไป จะค้นหาและ reuse ยาก
debug failure อาจต้องไล่จากตารางไป implementation

แนวทางปฏิบัติ: จำกัด keyword ให้เป็น business-level action เช่น CreateOrder แทน keyword ระดับเล็กเกินไปอย่าง ClickButton หรือ TypeText เพราะจะทำให้ตารางยาวและ maintain ยาก

5. Hybrid หรือแบบไฮบริด

Hybrid framework คือการผสมหลายแนวทางเข้าด้วยกัน เช่น:

modular เป็นแกนหลัก
data-driven สำหรับ input หลายชุด
keyword-driven สำหรับบาง workflow ที่ QA ต้องเขียนเอง
BDD สำหรับ requirement ที่ต้องให้ product และ engineering เข้าใจร่วมกัน

ตัวอย่างโครงสร้าง hybrid สำหรับ API testing:

tests/
  auth/
    login.spec.js
  orders/
    create-order.spec.js
data/
  login-cases.json
  order-cases.csv
helpers/
  auth.js
  orders.js
reports/

ใช้เมื่อไหร่

เหมาะกับ test suite ที่โตแล้ว มีหลายทีม หรือมีหลายประเภทการทดสอบ เช่น UI, API, integration และ regression

ข้อดี

ยืดหยุ่นที่สุด
เลือก pattern ให้เหมาะกับแต่ละปัญหา
scale ได้ดีเมื่อมี convention ชัดเจน

ข้อเสีย

ถ้าไม่มี design guideline จะไม่สอดคล้องกัน
อาจแบกต้นทุนของทุกแบบพร้อมกัน
onboarding ยากถ้าไม่มีเอกสาร

แนวทางปฏิบัติ: เขียน testing-guidelines.md ระบุให้ชัดว่าเมื่อใดควรใช้ modular, data-driven, keyword หรือ BDD เพื่อป้องกันแต่ละทีมออกแบบคนละทาง

6. Behavior-driven หรือ BDD

BDD framework แสดง test scenario ด้วยภาษาที่ใกล้เคียงภาษาธรรมชาติ โดยใช้รูปแบบ Given-When-Then มักเขียนด้วย Gherkin และรันด้วยเครื่องมือเช่น Cucumber

ตัวอย่าง:

Feature: Login

  Scenario: Registered user logs in successfully
    Given a registered user exists
    When the user submits valid credentials
    Then the user should see the dashboard

เบื้องหลังยังต้องมี step definition:

Given('a registered user exists', async function () {
  // create or prepare user
})

When('the user submits valid credentials', async function () {
  // submit login form or API request
})

Then('the user should see the dashboard', async function () {
  // assertion
})

ใช้เมื่อไหร่

เหมาะเมื่อ:

product, QA และ engineering ต้องใช้ requirement ร่วมกัน
มี misunderstanding ระหว่างสิ่งที่ขอและสิ่งที่สร้างบ่อย
scenario ต้องอ่านได้โดยคนที่ไม่ใช่วิศวกร
acceptance criteria สำคัญมาก

อ่านตัวอย่างกับ API ได้ที่ คู่มือ Gherkin สำหรับการทดสอบ API แบบ BDD

ข้อดี

ช่วยสร้าง shared understanding
scenario อ่านง่าย
เชื่อม requirement กับ automation ได้ดี
เหมาะกับ acceptance test

ข้อเสีย

มีสองชั้นที่ต้องดูแล: Gherkin และ step definition
ถ้า product หรือ QA ไม่อ่าน scenario จริง BDD จะไม่คุ้ม
step definition ซ้ำหรือคลุมเครือทำให้ maintain ยาก

แนวทางปฏิบัติ: ใช้ BDD เฉพาะ workflow ที่ต้องการ alignment ระหว่างหลายบทบาท ไม่จำเป็นต้องเขียนทุก unit test หรือทุก API test เป็น Gherkin

การเปรียบเทียบประเภทของเฟรมเวิร์ก

ประเภทเฟรมเวิร์ก	การนำกลับมาใช้ซ้ำ	ผู้ที่ไม่ใช่โปรแกรมเมอร์สร้างได้	ค่าใช้จ่ายในการติดตั้ง	การปรับขนาด
Linear	ต่ำมาก	ได้ ผ่าน record/playback	ต่ำมาก	ไม่ดี
Modular	สูง	โดยทั่วไปไม่ได้	ปานกลาง	ดี
Data-driven	ปานกลาง	บางส่วน ผ่าน test data	ปานกลาง	ดีสำหรับ input หลากหลาย
Keyword-driven	สูง	ได้	สูง	ดี
Hybrid	สูง	แล้วแต่การออกแบบ	สูง	ดีมาก
BDD	สูง	ได้ สำหรับอ่านและเขียน scenario	สูง	ดี

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

ข้อผิดพลาดทั่วไปของเฟรมเวิร์ก

1. สร้าง abstraction เร็วเกินไป

บางทีมเริ่มด้วย keyword-driven หรือ hybrid ตั้งแต่มีเทสต์แค่ 10–15 รายการ ทำให้ต้นทุนการสร้าง abstraction สูงกว่า benefit ที่ได้

แนวทางแก้:

เริ่มจาก modular แบบเบา ๆ
รอให้มี duplication จริงก่อนดึงเป็น reusable layer
ใช้กฎง่าย ๆ: ถ้าขั้นตอนซ้ำ 3 ครั้งขึ้นไป ค่อยพิจารณาแยก helper

2. ไม่ยอมพัฒนาออกจาก linear

Linear script ที่เคยดีตอนมี 20 รายการจะกลายเป็นภาระเมื่อโตเป็น 400 รายการ การเปลี่ยน product เล็กน้อยอาจทำให้ต้องแก้ script ซ้ำ ๆ ทั้งวัน

สัญญาณที่ควร refactor:

แก้ product หนึ่งจุด แต่เทสต์พังหลายสิบไฟล์
login, setup, teardown ถูก copy-paste ทุกที่
failure debug ยากเพราะแต่ละ script ทำคล้ายกันแต่ไม่เหมือนกัน

แนวทางแก้คือย้ายขั้นตอนซ้ำไป helper/module ก่อนที่ suite จะใหญ่เกินไป

3. เลือก framework เพื่อ audience ที่ไม่มีอยู่จริง

BDD จะคุ้มเมื่อ product หรือ QA อ่าน Gherkin จริง Keyword-driven จะคุ้มเมื่อ analyst สร้าง test case จริง ถ้าคนเหล่านั้นไม่แตะ test suite เลย คุณจะได้แต่ต้นทุนของ layer เพิ่มเติมโดยไม่มีประโยชน์

ก่อนเลือก ให้ถามตรง ๆ:

ใครจะเขียนเทสต์จริง
ใครจะอ่านผลลัพธ์จริง
ใครจะ maintain เมื่อ failure
ใครจะเพิ่ม test data หรือ scenario

เลือก framework ให้ตรงกับคนที่มีส่วนร่วมจริง ไม่ใช่คนที่ “อาจจะ” มีส่วนร่วมในอนาคต

วิธีเลือกประเภทเฟรมเวิร์ก

ใช้ checklist นี้ก่อนเริ่มออกแบบ:

ขนาดและอายุของโปรเจกต์

ถ้าเป็น script ใช้ครั้งเดียว Linear พอได้ แต่ถ้าต้องดูแลนานกว่าหนึ่งไตรมาส ควรเริ่มอย่างน้อยที่ Modular
ใครเป็นคนเขียนเทสต์

ถ้าเป็นวิศวกรทั้งหมด Modular หรือ Hybrid มักเหมาะกว่า ถ้ามี QA analyst หรือ business user ร่วมเขียน ให้พิจารณา Keyword-driven หรือ BDD
input หลากหลายแค่ไหน

ถ้า workflow เดิมต้องรันกับข้อมูลหลายสิบหรือหลายร้อยชุด ให้ใช้ Data-driven
มีช่องว่างการสื่อสารหรือไม่

ถ้า product และ engineering เข้าใจ requirement ไม่ตรงกันบ่อย BDD อาจช่วยได้ เพราะ scenario กลายเป็นภาษากลาง
ทีม maintain อะไรได้จริง

Framework ที่ดีที่สุดคือ framework ที่ทีมเข้าใจและดูแลได้ โครงสร้างสวยแต่ไม่มีใคร debug ได้จะล้มเหลวเร็วกว่าโครงสร้างธรรมดาที่ทุกคนเข้าใจ

ทีมจำนวนมากมักจบที่ Hybrid โดยมี Modular เป็นแกน ใช้ Data-driven กับกรณี input เยอะ และใช้ BDD เฉพาะจุดที่ต้องการความเข้าใจร่วมกันสูง เริ่มเรียบง่าย แล้วเพิ่มโครงสร้างจาก pain point จริง ไม่ใช่จากทฤษฎี

ถ้าต้องการวางขอบเขตการทดสอบให้ชัดขึ้น อ่านเพิ่มเรื่อง สถานการณ์ทดสอบเทียบกับกรณีทดสอบ

แพลตฟอร์มช่วยได้อย่างไร

การเลือกประเภทเฟรมเวิร์กคือการตัดสินใจด้านสถาปัตยกรรม แต่การทำให้ใช้งานได้จริงต้องมีเครื่องมือที่ช่วยให้ทีมทำตามโครงสร้างได้สม่ำเสมอ โดยเฉพาะ API testing

Apidog ช่วยรองรับแนวทางเหล่านี้ เช่น การนำ request ที่ใช้ร่วมกันกลับมาใช้ซ้ำ การใส่ parameter การรันแบบ data-driven จาก CSV และ JSON รวมถึงตัวสร้างการทดสอบแบบ visual ที่ช่วยให้ผู้ที่ไม่ใช่โปรแกรมเมอร์ประกอบ test flow ได้ง่ายขึ้น

สิ่งนี้สำคัญเพราะ framework จะดีได้ก็ต่อเมื่อทีมใช้มันได้อย่างสม่ำเสมอ เมื่อ suite โตขึ้นหรือมีคนเข้าออก เครื่องมือที่มีโครงสร้างในตัวจะช่วยลดความแตกต่างของ style และลดงานที่ต้องเขียน framework เองซ้ำ ๆ

คุณสามารถ ดาวน์โหลด Apidog เพื่อดูว่ารูปแบบ modular, data-driven และ visual test building ทำงานจริงอย่างไร จากนั้นค่อยตัดสินใจว่าทีมยังต้องเขียน custom framework เพิ่มมากน้อยแค่ไหน ในหลายกรณี Apidog จัดการ layer อย่าง request, data และ report ให้แล้ว ทำให้ทีมโฟกัสกับ test coverage และ quality ได้มากขึ้น

คำถามที่พบบ่อย

เครื่องมืออัตโนมัติกับเฟรมเวิร์กการทดสอบอัตโนมัติต่างกันอย่างไร

เครื่องมืออัตโนมัติคือสิ่งที่ใช้รันการทดสอบ เช่น browser driver หรือ HTTP client ส่วนเฟรมเวิร์กคือโครงสร้างรอบเครื่องมือนั้น เช่น วิธีจัดไฟล์ วิธีแชร์ logic วิธีจัดการข้อมูล และวิธีรายงานผล คุณมีเครื่องมือได้โดยไม่มีเฟรมเวิร์ก แต่เมื่อเทสต์โตขึ้นจะ maintain ยากมาก

เฟรมเวิร์กการทดสอบอัตโนมัติประเภทใดดีที่สุด

ไม่มีประเภทที่ดีที่สุดสำหรับทุกกรณี Linear เหมาะกับ script ใช้ครั้งเดียว Modular เหมาะกับทีมวิศวกรส่วนใหญ่ Data-driven เหมาะกับ input หลากหลาย Keyword-driven และ BDD เหมาะกับทีมที่มีหลายบทบาท ส่วน Hybrid เหมาะกับ suite ขนาดใหญ่ที่โตแล้ว

BDD ใช้ได้เฉพาะ API หรือ UI testing หรือไม่

ไม่ใช่ BDD เป็นรูปแบบการจัดโครงสร้าง scenario ไม่ใช่ test layer รูปแบบ Given-When-Then ใช้ได้กับ unit, API และ UI test สิ่งสำคัญคือมีคนที่ไม่ใช่วิศวกรอ่านหรือเขียน scenario จริงหรือไม่

เปลี่ยนประเภทเฟรมเวิร์กหลังสร้างชุดทดสอบแล้วได้ไหม

ได้ แต่มีต้นทุนตามขนาดของ test suite การย้ายจาก Linear ไป Modular หมายถึงต้องดึง logic ซ้ำออกจาก script ที่ copy-paste ไว้จำนวนมาก ยิ่งเริ่ม refactor เร็ว ต้นทุนยิ่งต่ำ

โปรเจกต์ขนาดเล็กจำเป็นต้องมีเฟรมเวิร์กไหม

ถ้าเป็นโปรเจกต์สั้นมากและใช้ script เพียงไม่กี่ครั้ง Linear อาจพอได้ แต่โปรเจกต์ขนาดเล็กมักโตขึ้นเสมอ ถ้า test suite จะอยู่เกินสองสามสัปดาห์ หรือมีมากกว่าหนึ่งคนดูแล โครงสร้างแบบ Modular ที่เรียบง่ายมักคุ้มค่าตั้งแต่แรก