🗺

Roadmap

Learning path สำหรับ QA Engineer — ทำ checklist แต่ละรายการเพื่อติดตามความคืบหน้า

1
พื้นฐาน IT
1–2 เดือน
  • HTTP & Web Basics
  • API (REST, JSON)
  • Browser DevTools
  • SQL เบื้องต้น
  • Git เบื้องต้น
2
Manual QA
2–3 เดือน
  • Test Case Writing
  • Bug Report
  • Testing Types
  • Exploratory Testing
  • Test Management Tools (Jira, TestRail)
3
Automation QA
3–4 เดือน
  • Python เบื้องต้น
  • Postman API Testing
  • pytest
  • Playwright UI Automation
4
Portfolio & Career
ongoing
  • สร้าง GitHub Portfolio
  • ศึกษา ISTQB Foundation
  • เขียน Resume + Cover Letter
  • ฝึก Interview Questions
💻

พื้นฐาน IT

HTTP & Status Codes

▼

HTTP (HyperText Transfer Protocol) คือ protocol ที่ browser ใช้คุยกับ server ผ่าน request และ response

HTTP Methods
  • GET — ดึงข้อมูล (ไม่เปลี่ยนแปลงข้อมูล)
  • POST — สร้างข้อมูลใหม่
  • PUT — แทนที่ข้อมูลทั้งหมด
  • PATCH — แก้ไขข้อมูลบางส่วน
  • DELETE — ลบข้อมูล
Status Codes สำคัญ
200OK — สำเร็จ
201Created — สร้างข้อมูลสำเร็จ
204No Content — สำเร็จแต่ไม่มี body
301Moved Permanently — redirect ถาวร
302Found — redirect ชั่วคราว
400Bad Request — request ผิด format
401Unauthorized — ไม่ได้ login / token หมดอายุ
403Forbidden — มีสิทธิ์แต่ถูกบล็อก
404Not Found — ไม่พบ resource
409Conflict — ข้อมูลซ้ำ (เช่น email ซ้ำ)
422Unprocessable — ข้อมูลผิด validation
500Internal Server Error — server พัง
502Bad Gateway — upstream ไม่ตอบ
503Service Unavailable — server ไม่พร้อม
ตัวอย่าง Request/Response
// Request POST /api/users HTTP/1.1 Host: api.example.com Content-Type: application/json Authorization: Bearer eyJhbGci... { "name": "สมชาย", "email": "som@example.com" } // Response HTTP/1.1 201 Created Content-Type: application/json { "id": 42, "name": "สมชาย", "email": "som@example.com" }

API คืออะไร

▼

API (Application Programming Interface) คือช่องทางที่ software คุยกันได้ REST API คือรูปแบบที่นิยมที่สุด

ส่วนประกอบของ API Request
  • Endpoint — URL ของ resource เช่น /api/users/42
  • Method — GET, POST, PUT, PATCH, DELETE
  • Headers — metadata เช่น Authorization, Content-Type
  • Query Params — filter ใน URL เช่น ?page=1&limit=10
  • Request Body — ข้อมูลที่ส่งไป (JSON)
JSON Format ตัวอย่าง
{ "id": 1, "name": "สมชาย ใจดี", "email": "somchai@example.com", "roles": ["qa", "tester"], "active": true, "score": 95.5 }
Authentication แบบต่างๆ
  • Bearer Token — Authorization: Bearer <token>
  • API Key — X-API-Key: abc123 หรือใน query param
  • Basic Auth — Authorization: Basic base64(user:pass)
  • OAuth2 — ระบบ token หมดอายุ + refresh token

Browser DevTools

▼

เปิด DevTools ด้วย F12 หรือ Ctrl+Shift+I — เป็นเครื่องมือหลักของ QA

Network Tab
  • ดู request ทั้งหมดที่ browser ส่งออก
  • ดู response body, headers, status code
  • Filter ตาม type: XHR/Fetch = API calls
  • ดู timing: เช็คว่า API ช้าหรือเปล่า
  • Tips: กด Preserve log เพื่อไม่ให้ log หายตอน redirect
Console Tab
  • ดู JavaScript error และ warning
  • รัน JS ได้โดยตรง — ใช้เช็ค state ของหน้า
  • ดู console.log ที่ developer ใส่ไว้
Elements Tab
  • ดูและแก้ DOM แบบ real-time
  • ดู CSS ที่ apply อยู่กับ element
  • ใช้หา selector สำหรับ automation test
Application Tab
  • LocalStorage — ดู/แก้ data ที่เก็บใน browser
  • Cookies — session, auth cookies
  • Session Storage — คล้าย localStorage แต่หายเมื่อปิด tab

SQL เบื้องต้น

▼

QA ใช้ SQL เพื่อ verify ข้อมูลใน database โดยตรง — ยืนยันว่าระบบบันทึกข้อมูลถูกต้อง

Commands ที่ใช้บ่อย
-- เช็ก user ว่า register สำเร็จหรือไม่ SELECT * FROM users WHERE email = 'test@example.com'; -- นับจำนวน order ที่ pending SELECT COUNT(*) FROM orders WHERE status = 'pending'; -- ดู order ล่าสุด 10 รายการ SELECT * FROM orders ORDER BY created_at DESC LIMIT 10; -- JOIN: ดู order พร้อมชื่อ user SELECT o.id, u.name, o.total, o.status FROM orders o JOIN users u ON o.user_id = u.id WHERE o.created_at > '2024-01-01'; -- เช็กว่าข้อมูลที่ลบแล้วหายจริง SELECT * FROM products WHERE id = 42; -- ถ้า empty = ลบสำเร็จ
Clauses สำคัญ
  • WHERE — กรองข้อมูล
  • ORDER BY — เรียงลำดับ (ASC/DESC)
  • LIMIT — จำกัดจำนวนผลลัพธ์
  • JOIN — เชื่อม 2 ตารางด้วย key
  • COUNT(*) — นับจำนวนแถว
  • GROUP BY — grouping ข้อมูล

Git เบื้องต้น

▼

Git ใช้จัดการ version ของ code — QA ต้องรู้เพื่อ checkout branch และดู change ที่ต้องทดสอบ

Commands พื้นฐาน
# clone repo ลงเครื่อง git clone https://github.com/org/project.git # ดู branch ทั้งหมด git branch -a # เปลี่ยน branch ไปทดสอบ feature ใหม่ git checkout feature/new-login # ดูว่ามีอะไรเปลี่ยนบ้างใน branch นี้ git log --oneline # ดึง code ล่าสุดจาก remote git pull origin main # ดู diff ของไฟล์ที่เปลี่ยน git diff HEAD~1
การอ่าน PR (Pull Request)
  • ดู Files changed — เพื่อรู้ว่า code ส่วนไหนเปลี่ยน
  • อ่าน description ว่า feature นี้ทำอะไร
  • เช็ก linked ticket เพื่อดู acceptance criteria
  • QA ต้อง review และ approve ก่อน merge
🧪

Manual QA

Test Case Writing

▼
โครงสร้าง Test Case
TC-001: Login ด้วย email และ password ที่ถูกต้อง Preconditions: User ลงทะเบียนแล้ว, ยังไม่ได้ login Steps: 1. เปิดหน้า /login 2. กรอก email: test@example.com 3. กรอก password: Correct123! 4. กด "เข้าสู่ระบบ" Expected: Redirect ไปหน้า /dashboard, แสดงชื่อ user Actual: [กรอกหลังทดสอบ] Status: Pass / Fail
Happy Path vs Edge vs Negative
  • Happy Path — กรณีที่ทุกอย่างถูกต้องสมบูรณ์
  • Edge Case — ขอบเขตสุดของ input เช่น password ยาวสุด 100 ตัว
  • Negative Case — ตั้งใจส่งข้อมูลผิด เพื่อดูว่าระบบ handle error ได้
Equivalence Partitioning

แบ่ง input ออกเป็น group ที่คาดว่าจะได้ผลลัพธ์เหมือนกัน แล้วทดสอบตัวแทน 1 ค่าจากแต่ละ group

  • Password ต้องมี 8–20 ตัวอักษร → ทดสอบ: 5 ตัว (invalid), 12 ตัว (valid), 25 ตัว (invalid)
Boundary Value Analysis

ทดสอบที่ขอบเขตของ valid range เพราะ bug มักอยู่ตรงนี้

  • Password 8–20 ตัว → ทดสอบ: 7, 8, 9, 19, 20, 21 ตัว

Bug Report

▼
โครงสร้าง Bug Report ที่ดี
Title[Login] กด "ลืมรหัสผ่าน" แล้ว page blank ไม่แสดงฟอร์ม reset
EnvironmentChrome 121, macOS 14, Staging v2.3.1
SeverityHigh
PriorityP2
Steps1. เปิด /login
2. กด "ลืมรหัสผ่าน?"
3. ระบบ redirect ไป /forgot-password
Expectedแสดงฟอร์มให้กรอก email
Actualหน้า blank สีขาว ไม่มี element ใดๆ ปรากฏ
Screenshot[แนบไฟล์]
Severity vs Priority
  • Severity — ผลกระทบต่อการทำงานของระบบ (Critical / High / Medium / Low)
  • Priority — ความเร่งด่วนในการแก้ไข (P1 / P2 / P3)
  • ตัวอย่าง: ปุ่ม "บริจาค" พิมพ์ผิดเป็น "บริจาก" → Severity: Low, Priority: P1 (ลูกค้าเห็น)
  • ตัวอย่าง: ระบบคำนวณ VAT ผิดในกรณีขอคืนเงิน → Severity: Critical, Priority: P2 (ใช้ไม่บ่อย)
Bug Report ดี vs ไม่ดี
  • ❌ "ระบบมีปัญหา กด login ไม่ได้"
  • ✅ "[Login] กดปุ่ม submit ด้วย email ถูก / password ถูก → ได้ error 500, เห็นใน console: TypeError: Cannot read properties of null"

Testing Types

▼
  • Functional Testing — ทดสอบว่าระบบทำงานตาม requirement หรือไม่
  • Regression Testing — ทดสอบซ้ำหลัง fix bug / เพิ่ม feature ใหม่ เพื่อให้แน่ใจว่าของเดิมไม่พัง
  • Smoke Testing — ทดสอบ feature หลักๆ คร่าวๆ ก่อน QA เต็มรูปแบบ ("ระบบยังเปิดได้ไหม?")
  • Sanity Testing — ทดสอบเฉพาะส่วนที่แก้ไขใหม่ หลัง dev fix bug
  • UAT (User Acceptance Testing) — ลูกค้า / business ทดสอบด้วยตัวเองว่าตรง requirement
  • Exploratory Testing — ทดสอบแบบสำรวจ ไม่มี script กำหนด ใช้ความคิดสร้างสรรค์หา bug
  • Performance Testing — ทดสอบความเร็ว/ความสามารถรองรับ load
  • Security Testing — ทดสอบช่องโหว่ด้านความปลอดภัย

Test Management Tools

▼
Jira
  • Bug/Ticket tracking — สร้าง issue, assign, set priority
  • Sprint board — Kanban หรือ Scrum workflow
  • Story → Task → Sub-task hierarchy
  • Filter JQL: project = QA AND status = "In Testing" ORDER BY priority
TestRail
  • Test Case — เก็บ test case ทั้งหมด organize ตาม module
  • Test Plan — กำหนดว่า sprint นี้จะทดสอบอะไรบ้าง
  • Test Run — execute test แล้ว mark Pass/Fail/Skip พร้อม comment
  • Test Result — report ผล ดู pass rate, coverage
⚙️

Automation QA

Python เบื้องต้นสำหรับ QA

▼
# Variables & Types name = "QA Tester" score = 95 is_active = True items = ["login", "register", "checkout"] config = {"env": "staging", "timeout": 30} # If / Else if score >= 80: print("ผ่าน") elif score >= 60: print("ผ่านแบบมีเงื่อนไข") else: print("ไม่ผ่าน") # Loop for item in items: print(f"ทดสอบ: {item}") # Function def calculate_vat(price, rate=0.07): return round(price * rate) # String formatting user = "somchai" print(f"ยินดีต้อนรับ {user.title()}")

Postman — API Testing

▼
การสร้าง Request
  • เลือก Method (GET/POST/etc.) + กรอก URL
  • เพิ่ม Headers: Authorization: Bearer {{token}}
  • เพิ่ม Body: JSON format
  • กด Send และดู Response
การเขียน Tests ใน Postman
// ทดสอบ status code pm.test("Status is 200", () => { pm.response.to.have.status(200); }); // ทดสอบ response body pm.test("มี token ใน response", () => { const json = pm.response.json(); pm.expect(json.token).to.exist; pm.expect(json.token).to.be.a('string'); }); // ทดสอบ response time pm.test("ตอบสนองภายใน 1 วินาที", () => { pm.expect(pm.response.responseTime).to.be.below(1000); }); // เก็บ token ไว้ใช้ต่อ pm.environment.set("token", pm.response.json().token);
Environment Variables
  • สร้าง environment: staging / production
  • เก็บ base_url, token — ใช้ {{variable}} ใน request
  • ทดสอบ environment ต่างๆ โดยไม่ต้องแก้ URL ทีละ request

pytest — Unit & API Testing

▼
# test_calc.py def calculate_vat(price): return round(price * 0.07) def test_calculate_vat(): assert calculate_vat(1000) == 70 assert calculate_vat(0) == 0 assert calculate_vat(100) == 7 # ── Fixtures ───────────────────────────── import pytest import requests @pytest.fixture def api_client(): base = "https://api.staging.example.com" session = requests.Session() session.headers["Authorization"] = "Bearer test-token" return session def test_get_users(api_client): res = api_client.get("/users") assert res.status_code == 200 data = res.json() assert isinstance(data, list) assert len(data) > 0 def test_login_success(api_client): res = api_client.post("/login", json={ "email": "user@test.com", "password": "correct" }) assert res.status_code == 200 assert "token" in res.json() def test_login_wrong_password(api_client): res = api_client.post("/login", json={ "email": "user@test.com", "password": "wrong" }) assert res.status_code == 401
การรัน pytest
pytest # รันทุก test pytest test_login.py # รันไฟล์เดียว pytest -v # verbose mode pytest -k "login" # รันเฉพาะ test ที่ชื่อมี "login" pytest --html=report.html # สร้าง HTML report

Playwright — UI Automation

▼
Install
pip install playwright playwright install chromium
Basic Script
from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch(headless=False) page = browser.new_page() # เปิดหน้า login page.goto("https://example.com/login") # กรอกข้อมูล page.fill("#email", "test@example.com") page.fill("#password", "password123") page.click("button[type=submit]") # รอ redirect page.wait_for_url("**/dashboard") # Assert assert "Dashboard" in page.title() assert page.locator("h1").text_content() == "ยินดีต้อนรับ" # Screenshot page.screenshot(path="dashboard.png") browser.close()
Selectors ที่ใช้บ่อย
# CSS Selector page.click("#submit-btn") page.fill(".input-email", "test@test.com") # Text page.click("text=เข้าสู่ระบบ") # Role (ดีกว่า — semantic) page.get_by_role("button", name="Submit").click() page.get_by_label("Email").fill("test@test.com") page.get_by_placeholder("กรอก email").fill("x@x.com") # Locator assertions expect(page.locator(".success-msg")).to_be_visible() expect(page.locator("h1")).to_have_text("Dashboard")
🛠

Tools & Setup

Postman
API Testing — ส่ง request, เขียน test script, manage collections
postman.com →
VS Code
Code editor หลัก — รองรับ Python, extension เพียบ
code.visualstudio.com →
Git
Version control — clone repo, switch branch เพื่อทดสอบ
git-scm.com →
Python 3
ภาษาหลักสำหรับ automation — pytest, Playwright, requests
python.org →
Playwright
UI automation แบบ modern — fast, reliable, auto-wait
playwright.dev →
DBeaver
ดู Database GUI — รองรับ MySQL, PostgreSQL, SQLite
dbeaver.io →
Jira
Bug/ticket tracking — sprint board, workflow
atlassian.com/jira →
TestRail
Test management — test case, test run, report
testrail.com →
Charles Proxy
ดัก HTTP traffic จาก mobile app — debug API call
charlesproxy.com →

VS Code Extensions แนะนำ

  • Python — Microsoft Python extension
  • Pylance — IntelliSense สำหรับ Python
  • Playwright Test for VSCode — run/debug test ใน editor
  • REST Client — ส่ง HTTP request จากไฟล์ .http
  • GitLens — ดู git history ใน editor
  • Thunder Client — Postman alternative ใน VSCode
🚀

Career Path

🌱
Junior QA
15–30K
🔬
QA Engineer
30–55K
⚡
Senior QA
55–90K
🎯
QA Lead
80–130K
👑
QA Manager
100K+

Skills ตาม Level

  • Junior: Manual testing, test case, bug report, basic SQL
  • Mid: API testing (Postman), basic automation (pytest), Jira/TestRail
  • Senior: Playwright/Selenium, CI/CD integration, performance testing, mentoring
  • Lead: Test strategy, team management, risk-based testing, process improvement

ISTQB Certification

  • Foundation Level (CTFL) — เริ่มต้น, สอบ 40 ข้อ 60 นาที
  • ค่าสอบ: ประมาณ 8,000–12,000 บาท
  • สมัคร: ผ่าน BACS Thailand หรือ partner ใน Thailand
  • เตรียม: อ่าน ISTQB Syllabus 2018 + ทำ mock exam

Portfolio Tips

  • สร้าง GitHub repo: "qa-portfolio" — รวม test scripts
  • Playwright project: automation test สำหรับ web สาธารณะ (เช่น ทดสอบ form บน demo site)
  • API Testing collection: Postman collection + test scripts พร้อม export
  • Bug report samples: fake bug report ที่เขียนดี พร้อม template
  • เขียน blog/README อธิบาย approach และ decision ที่ทำ

Interview Questions ที่เจอบ่อย

อธิบาย SDLC และ QA เข้ามาเกี่ยวข้องตรงไหน?▼
SDLC (Software Development Lifecycle) คือกระบวนการพัฒนา software ตั้งแต่ requirements → design → develop → test → deploy → maintain. QA เข้ามาทุก phase ตั้งแต่ review requirement (ป้องกัน defect ก่อนพัฒนา), review design, test หลัง develop, และ verify หลัง deploy
ถ้าเวลาไม่พอ คุณจะเลือกทดสอบอะไรก่อน?▼
ใช้ Risk-based testing — ทดสอบ feature ที่มีผลกระทบต่อ business หรือ user มากที่สุดก่อน เช่น payment flow, login, data integrity สำคัญกว่า UI ข้อความผิด จากนั้นทำ Smoke test ครอบ happy path ทุก feature หลัก ก่อน regression test
Severity กับ Priority ต่างกันอย่างไร ยกตัวอย่าง▼
Severity = ผลกระทบต่อระบบ, Priority = ความเร่งด่วนในการแก้ไข. ตัวอย่าง: โลโก้บริษัทแสดงผิด Severity ต่ำ (ระบบยังใช้งานได้) แต่ Priority สูง (ลูกค้าเห็น). ระบบคำนวณ VAT ผิดในกรณีพิเศษ Severity สูง แต่ Priority อาจต่ำกว่าถ้า workaround ได้
คุณจะ verify ว่า bug ถูก fix แล้วยังไง?▼
1. อ่าน ticket ว่า dev fix อะไร 2. ทดสอบ exact steps ที่ทำให้ bug เกิด 3. Verify expected behavior ตรง 4. ทดสอบ related areas (regression) — bug fix อาจทำให้ส่วนอื่นพัง 5. ทดสอบ edge cases รอบๆ 6. Close ticket พร้อม comment ว่าทดสอบอะไรบ้าง
คุณเคยหา bug ที่ยากมากไหม? เล่าให้ฟัง▼
ตอบด้วย STAR method: Situation (context), Task (งานที่รับผิดชอบ), Action (สิ่งที่ทำ), Result (ผลลัพธ์). เช่น "ใน project X พบว่า payment บางครั้งถูก charge 2 ครั้ง ซึ่งเกิดขึ้นเฉพาะตอน network ช้า เลยทดสอบด้วย Charles Proxy throttle ความเร็ว จนพบ race condition ใน retry logic"