การจัดการ Test Environment
จบบทนี้แล้วคุณจะ...
- อธิบายความแตกต่างระหว่าง dev, staging, และ production environment
- เข้าใจปัญหา environment parity และผลกระทบต่อ testing
- รู้หลักการ configuration management สำหรับ test environment
- เข้าใจแนวคิด containers ในระดับ concept
- ออกแบบ environment setup ที่เหมาะสมกับการทดสอบได้
1 · เรื่องเล่า: test ผ่านบน staging แต่พังบน production
ทีม QA ของระบบ e-commerce ผ่าน test ทุกเคสบน staging environment ก่อน release ตัดสินใจ deploy ขึ้น production ด้วยความมั่นใจ
ภายใน 30 นาทีหลัง deploy:
- ปัญหาที่ 1: ระบบค้นหาสินค้า timeout เพราะ staging มีข้อมูลสินค้า 500 รายการ แต่ production มี 50,000 รายการ — query ที่เร็วบน staging ช้ามากบน production
- ปัญหาที่ 2: การอัปโหลดรูปสินค้า fail เพราะ staging ใช้ local file storage แต่ production ใช้ cloud storage (S3) — configuration ต่างกัน
- ปัญหาที่ 3: email confirmation ส่งไม่ออก เพราะ staging ใช้ mock email service แต่ production ต้องใช้ SMTP จริง ที่ firewall rule ยังไม่ได้เปิด
บทเรียน: environment ที่ต่างกันมากเกินไป ทำให้ test ที่ผ่านไม่ได้หมายความว่าจะทำงานได้จริง
2 · Environment แต่ละประเภท
Development (Dev)
- เครื่อง local ของ developer
- ข้อมูลน้อย, services อาจ mock
- ใช้สำหรับ: unit test, ทดสอบ feature ที่กำลังพัฒนา
Staging / QA
- เซิร์ฟเวอร์ที่ simulate production
- ข้อมูลใกล้เคียง production (ในอุดมคติ)
- ใช้สำหรับ: integration test, regression test, UAT
Production
- ระบบจริงที่ผู้ใช้ใช้งาน
- ข้อมูลจริง, traffic จริง, scale จริง
- ใช้สำหรับ: smoke test หลัง deploy, monitoring, canary testing
เปรียบเทียบ
| มิติ | Dev | Staging | Production |
|---|---|---|---|
| ข้อมูล | น้อย / mock | ปานกลาง | เยอะมาก |
| Services | mock / local | เกือบจริง | จริงทั้งหมด |
| Performance | ไม่สะท้อนจริง | ใกล้เคียง | จริง |
| Access | ทุกคน | จำกัด | เข้มงวด |
| ค่าใช้จ่าย | ต่ำ | ปานกลาง | สูง |
3 · Environment Parity
Environment parity คือระดับความเหมือนกันระหว่าง environments
ปัญหาเมื่อ parity ต่ำ
- Data volume ต่างกัน — query เร็วบน staging (500 rows) แต่ช้าบน production (500,000 rows)
- Services ต่างกัน — staging ใช้ mock payment แต่ production ใช้ payment gateway จริง
- Configuration ต่างกัน — staging ใช้ HTTP แต่ production ใช้ HTTPS
- Infrastructure ต่างกัน — staging เป็น single server แต่ production เป็น load-balanced cluster
- Timezone/Locale ต่างกัน — staging อยู่ UTC แต่ production อยู่ Asia/Bangkok
วิธีปรับปรุง parity
- ใช้ infrastructure as code (Terraform, CloudFormation) — สร้าง environment เหมือนกันอัตโนมัติ
- Sync database schema — staging ต้องมี schema เหมือน production เสมอ
- ใช้ realistic data volume — อย่างน้อยให้มี data ที่ representative
- ใช้ services จริง (หรือ sandbox) แทน mock ให้มากที่สุด
- ตรวจสอบ configuration drift เป็นประจำ
4 · Configuration Management
หลักการ
- Environment variables — ใช้ env vars สำหรับ config ที่ต่างกันในแต่ละ environment
- Config files แยกตาม environment — dev.config, staging.config, production.config
- Secret management — ใช้ vault หรือ secret manager ไม่เก็บ secrets ใน code
- Version control — config ต้องอยู่ใน version control (ยกเว้น secrets)
ตัวอย่าง config ที่ต่างกัน
| Config | Dev | Staging | Production |
|---|---|---|---|
| Database URL | localhost:5432 | staging-db.internal:5432 | prod-db.internal:5432 |
| API Base URL | http://localhost:3000 | https://staging-api.example.com | https://api.example.com |
| Email Service | mock (log to console) | sandbox (Mailhog) | SMTP จริง (SendGrid) |
| Payment Gateway | mock | sandbox mode | live mode |
| Log Level | debug | info | warn |
5 · Containers (Concept Level)
ปัญหาที่ container แก้
"It works on my machine" — ประโยคที่ทีม dev พูดบ่อยที่สุด
Container คือ "กล่อง" ที่บรรจุ application + dependencies ทั้งหมด ไว้ด้วยกัน ทำให้:
- รันบนเครื่องไหนก็ได้ผลเหมือนกัน
- ไม่ conflict กับ software อื่นบนเครื่อง
- สร้างและทำลายได้เร็วมาก
ประโยชน์สำหรับ testing
- Environment consistency — ทุกคนในทีมใช้ environment เดียวกัน
- Easy setup — developer ใหม่ไม่ต้อง install dependencies เอง
- Parallel testing — สร้าง container หลายตัวพร้อมกันเพื่อรัน test parallel
- Clean state — ทุกรอบเริ่มจาก state ที่สะอาด
- Reproducibility — ถ้า test fail สามารถ reproduce ได้ง่าย
สิ่งที่ QA ควรรู้
คุณไม่จำเป็นต้องเป็น expert เรื่อง container แต่ควรเข้าใจว่า:
- มันช่วยให้ test environment เสถียรขึ้น
- มันทำให้ "test ผ่านบนเครื่องฉัน" กลายเป็น "test ผ่านทุกที่"
- การขอให้ทีม dev ทำ containerized test environment เป็นเรื่องที่สมเหตุสมผล
6 · Environment-Specific Test Data
ข้อมูลทดสอบอาจต้องปรับตาม environment:
| Environment | Test Data Approach |
|---|---|
| Dev | Mock data, minimal dataset |
| Staging | Realistic data volume, sanitized production data |
| Production | Smoke test only, ใช้ test accounts ที่กำหนดไว้ |
Production Testing Considerations
- ห้าม สร้าง test data ที่ปะปนกับข้อมูลจริง
- ใช้ dedicated test accounts ที่ flag ว่าเป็น test
- ใช้ feature flags เพื่อ isolate test traffic
- ทำ smoke test เฉพาะ critical paths
- ลบ test data ทันทีหลังทดสอบเสร็จ
แบบฝึก: วิเคราะห์ Environment Setup ที่มีปัญหา
โจทย์
ทีม QA ของระบบ banking ส่ง report มาว่ามีปัญหาดังนี้:
Staging Environment Setup:
- Server: 1 เครื่อง (CPU 2 cores, RAM 4GB)
- Database: MySQL 5.7 กับข้อมูล 100 accounts
- Payment Gateway: mock service ที่ return success เสมอ
- SSL: ไม่มี (HTTP only)
- Timezone: UTC
- Email: ปิด (disabled)
Production Environment:
- Server: 3 เครื่อง behind load balancer (CPU 8 cores, RAM 32GB each)
- Database: MySQL 8.0 กับข้อมูล 2 ล้าน accounts
- Payment Gateway: connected to real bank API
- SSL: ใช้ HTTPS ทั้งหมด
- Timezone: Asia/Bangkok
- Email: SendGrid
คำถาม:
- ระบุปัญหา environment parity ที่พบทั้งหมด
- ปัญหาไหนมีความเสี่ยงสูงที่สุด? เพราะอะไร?
- แนะนำวิธีปรับปรุง staging ให้ใกล้เคียง production มากขึ้น
- มีอะไรบ้างที่ test บน staging จะไม่สามารถจับได้ แม้จะปรับปรุงแล้ว?
ดูคำตอบแนะนำ
1. ปัญหา parity:
- MySQL version ต่างกัน (5.7 vs 8.0) — อาจมี syntax/behavior ที่ต่างกัน
- Data volume ต่างกันมาก (100 vs 2,000,000) — performance ไม่สะท้อนจริง
- Payment gateway เป็น mock vs real — ไม่เจอ error จริงจาก bank
- ไม่มี SSL บน staging — ไม่เจอ mixed content, certificate issues
- Timezone ต่างกัน — อาจทำให้ date/time calculation ผิด
- Email disabled vs enabled — ไม่ได้ test email flow จริง
- Infrastructure ต่างกัน (1 server vs 3 + LB) — ไม่เจอ issues เกี่ยวกับ load balancing, session management
2. ความเสี่ยงสูงที่สุด:
- Payment gateway (mock vs real) — ระบบ banking ที่ payment ผิดพลาดมีผลกระทบรุนแรงมาก (เงินหาย, ทำรายการซ้ำ, ไม่ได้รับเงิน) ถ้า mock return success เสมอ จะไม่เจอ cases ที่ bank decline, timeout, หรือ partial failure
- MySQL version — เป็นอันดับสอง เพราะ banking queries ที่ซับซ้อน อาจทำงานต่างกันใน version ที่ต่างกัน
3. วิธีปรับปรุง:
- อัปเกรด staging เป็น MySQL 8.0 ให้ตรงกับ production
- เพิ่ม data volume เป็นอย่างน้อย 100,000 accounts (sanitized from production)
- ใช้ payment gateway sandbox mode แทน mock (ธนาคารส่วนใหญ่มี sandbox)
- เปิด HTTPS บน staging
- ตั้ง timezone เป็น Asia/Bangkok
- ใช้ email sandbox (เช่น Mailhog) แทนการปิด
- เพิ่มเป็น 2 servers + load balancer (ไม่จำเป็นต้อง spec เท่า production)
4. สิ่งที่ staging จับไม่ได้แม้ปรับปรุงแล้ว:
- Real user traffic patterns (concurrent users, peak hours)
- Real bank API behavior ภายใต้ load จริง
- Network latency ระหว่าง production infrastructure
- Production-only configurations ที่อาจลืมอัปเดตบน staging
สิ่งที่ต้องเอาติดตัวไปจากบทนี้
- Environment parity ยิ่งต่ำ ยิ่งมีโอกาสที่ test จะผ่านแต่ production จะพัง
- Dev, Staging, Production แต่ละ environment มีจุดประสงค์ต่างกัน — test ที่รันบน staging ไม่ได้รับประกัน production
- Configuration management ต้องเป็นระบบ — ใช้ env vars, config files, secret manager
- Containers ช่วยให้ environment เหมือนกันทุกที่ — เป็นเรื่องที่ QA ควรผลักดันให้ทีมใช้
- Production testing ต้องระวังเป็นพิเศษ — ห้ามสร้าง data ปลอมปะปนกับข้อมูลจริง