STLC: งานรอบตัวการ "รันเทสต์" ที่ถูกมองข้าม
คนจำนวนมากนึกว่างาน QA คือการเปิดหน้าเว็บแล้วคลิกตาม step แต่จริง ๆ แล้วการ execute test เป็นแค่ส่วนหนึ่งของวงจรการทดสอบทั้งหมด บทนี้จะช่วยให้คุณเห็นว่างานก่อนและหลังการรันเทสต์สำคัญไม่แพ้กัน
จบบทนี้แล้วคุณจะ...
- อธิบาย STLC ได้ว่าเป็นวงจรของงานทดสอบ ไม่ใช่แค่ขั้นตอน execute
- แยกงาน planning, analysis, design, execution และ closure ออกจากกันได้ชัดขึ้น
- เข้าใจว่าทำไม QA ใช้เวลาส่วนใหญ่ไปกับการคิดและเตรียม มากกว่าการกดรันเทสต์
- เห็นความสำคัญของ test closure และการสรุปผลเพื่อใช้ตัดสินใจ
- เชื่อม STLC กลับไปหา SDLC ได้ว่ามันซ้อนกันอย่างไร
วงจรของงานทดสอบที่อยู่ภายใน SDLC
ในบทก่อนเราเห็นภาพของ SDLC ซึ่งเป็นวงจรของการพัฒนาซอฟต์แวร์ทั้งหมด ส่วน STLC (Software Testing Lifecycle) คือวงจรย่อยที่โฟกัสเฉพาะงานด้านการทดสอบ
พูดง่าย ๆ:
- SDLC ตอบว่า "ทีมสร้างซอฟต์แวร์อย่างไร"
- STLC ตอบว่า "ทีมวางแผนและดำเนินการทดสอบอย่างไร"
ทำไมต้องแยกออกมา
เพราะถ้าคุณไม่แยก คุณจะหลงคิดง่ายมากว่า:
"งาน testing = ช่วง execute test"
แต่ในโปรเจกต์จริง ถ้าไม่มีการ plan, analyze, design และ close อย่างดี การ execute จะกลายเป็นการกดเช็กไปเรื่อย ๆ โดยไม่รู้ว่าครอบคลุมพอหรือยัง
Planning → Analysis → Design → Execution → Closure
| เฟส | คำถามที่ตอบ | Output ที่มักได้ |
|---|---|---|
| Test Planning | จะทดสอบอะไร เมื่อไร ด้วยทรัพยากรเท่าไร | test strategy, scope, schedule, risk |
| Test Analysis | จาก requirement ต้องพิสูจน์อะไรบ้าง | test conditions, coverage notes |
| Test Design | จะทดสอบแต่ละเงื่อนไขอย่างไร | test cases, checklist, test data |
| Test Execution | รันแล้วผลเป็นอย่างไร | pass/fail status, defect reports |
| Test Closure | พร้อมปล่อยหรือยัง และทีมเรียนรู้อะไร | summary report, residual risk, lessons learned |
ประเด็นสำคัญ
สิ่งที่คนใหม่มักตกใจคือ:
การ execute test เป็นแค่ 1 เฟสใน 5 เฟส
ดังนั้นถ้าใครประเมินคุณค่า QA จากจำนวนเคสที่รันอย่างเดียว เขากำลังเห็นแค่งานปลายทาง ไม่ได้เห็นงานคิดที่อยู่ข้างหลัง
Test Planning
ช่วงนี้ทีมตอบคำถามว่า:
- รอบนี้เราจะทดสอบอะไร
- อะไรอยู่ใน scope / out of scope
- มี risk อะไรที่ต้องระวังเป็นพิเศษ
- ต้องใช้ environment หรือ data อะไร
ตัวอย่าง
ถ้าจะปล่อยฟีเจอร์ payment ใหม่ Planning ที่ดีอาจระบุว่า:
- focus หลักคือ payment success/failure/callback
- out of scope คือ report ฝั่ง back office
- risk คือ gateway timeout และ duplicate charge
Test Analysis
นี่คือช่วงที่ QA ใช้สมองมากที่สุด เพราะต้องแปล requirement เป็นสิ่งที่ต้องพิสูจน์
ตัวอย่าง acceptance criteria เดียว อาจแตกเป็น:
- valid input
- invalid input
- boundary
- state change
- permission
- error handling
ถ้า analysis ไม่ดี design และ execution ต่อจากนั้นก็จะเบี้ยวตามไปด้วย
Test Design
พอรู้แล้วว่าต้องพิสูจน์อะไร ขั้นต่อไปคือเลือกว่าจะออกมาเป็นอะไร:
- detailed test case
- scenario
- checklist
- test data set
นี่คือช่วงที่งาน test artifact จาก Module 07 เริ่มเข้ามาเกี่ยวข้อง
Test Execution
นี่คือช่วงที่คนส่วนใหญ่เห็นชัดที่สุด:
- run tests
- บันทึกผล
- แจ้ง defect
- re-test หลังแก้
แต่งาน execute จะมีคุณภาพได้ก็ต่อเมื่อ 3 เฟสก่อนหน้าแข็งแรง
Test Closure
หลายทีมข้ามช่วงนี้ ทั้งที่มันสำคัญมาก เพราะนี่คือจุดที่ตอบว่า:
- coverage รอบนี้พอไหม
- มี risk อะไรค้างอยู่
- พร้อม release หรือไม่
- รอบหน้าควรปรับอะไร
closure ที่ดีทำให้ทีมไม่ทำผิดซ้ำแบบเดิม
ลองดูฟีเจอร์จริงหนึ่งใบแล้วตามตั้งแต่ต้นจนจบ
สมมติทีมกำลังทำฟีเจอร์:
"ผู้ใช้สามารถรีเซ็ตรหัสผ่านผ่านอีเมลได้"
Planning
- ระบุว่า flow นี้เป็น high-risk เพราะเกี่ยวกับ account access
- ต้องมี test mailbox และ staging email service
Analysis
- ขอ reset ด้วย email ที่มี/ไม่มีในระบบ
- ลิงก์หมดอายุ
- ใช้ลิงก์ซ้ำ
- rate limiting
Design
- เขียน scenario หลัก
- เขียน checklist smoke
- เตรียม test accounts หลายสถานะ
Execution
- run ตาม cases
- พบ defect เรื่องลิงก์เก่ากดย้อนกลับมาใช้ได้
Closure
- สรุปว่า criteria หลักผ่าน แต่มี medium bug 1 ตัว
- แจ้งทีมว่า release ได้ถ้ารับ risk นี้ หรือเลื่อนได้ถ้าอยากปิดก่อน
ตัวอย่างนี้ทำให้เห็นว่า STLC ไม่ใช่เอกสารทฤษฎี แต่คือ sequence ของงานจริง
| ความเชื่อผิด | ความจริง |
|---|---|
| งาน QA = execute test case | execute เป็นแค่ส่วนหนึ่งของ STLC |
| ถ้าไม่มี test case ก็ยังเริ่ม execute ได้ | เริ่มได้ แต่เสี่ยงหลุด coverage สูงมาก |
| closure คือส่งรายงานสวย ๆ | closure คือการสรุป risk และบทเรียนเพื่อใช้ตัดสินใจ |
| planning ทำครั้งเดียวตอนต้นโปรเจกต์ | ใน Agile planning และ reprioritize เกิดได้ทุกรอบ |
anti-pattern ที่เจอบ่อย
- ไม่มี test analysis แยก ทำให้เคสที่เขียนกระโดดข้าม logic สำคัญ
- ไม่มี closure ทำให้ทีมไม่รู้ว่าจริง ๆ พร้อมปล่อยหรือยัง
- ใช้เวลา execute เยอะ เพราะเตรียม data และ environment ช้า
งานทดสอบไม่ได้ลอยเดี่ยว แต่มันซ้อนอยู่ในวงจรพัฒนาหลัก
ถ้าดูภาพใหญ่:
- requirement review ใน SDLC จะไปเชื่อมกับ analysis ใน STLC
- implementation ใน SDLC จะวิ่งคู่กับ design และ preparation ใน STLC
- release ใน SDLC จะใช้ผลจาก execution และ closure ใน STLC
ดังนั้น QA ที่เข้าใจ STLC ดี จะไม่รอ "ช่วง testing" อย่างเดียว แต่จะรู้ว่าตัวเองควรเข้าไปแทรกตรงไหนของ SDLC เพื่อให้ข้อมูลพร้อมก่อน
ลองจัดกิจกรรมให้เข้ากับเฟส STLC ที่ถูกต้อง
"ทีมคุยกันว่ารอบนี้จะไม่ทดสอบ feature report เพราะไม่อยู่ใน scope release"
ดูคำตอบแนะนำ
นี่คือ <strong>Test Planning</strong> เพราะกำลังกำหนด scope และขอบเขตของรอบทดสอบ
"QA อ่าน story แล้วลิสต์ว่า flow นี้ต้องเช็ก empty value, invalid format, duplicate, และ timeout"
ดูคำตอบแนะนำ
นี่คือ <strong>Test Analysis</strong> เพราะเป็นการแตก requirement ออกเป็นรายการสิ่งที่ต้องพิสูจน์
"QA เลือกว่า flow นี้จะใช้ checklist สำหรับ smoke และใช้ test case ละเอียดเฉพาะ payment"
ดูคำตอบแนะนำ
นี่คือ <strong>Test Design</strong> เพราะเป็นการตัดสินรูปแบบของ test artifact และเตรียมการ execute
"QA รันเคส, log ผล, แจ้ง defect, แล้วกลับมาทดสอบซ้ำหลัง dev แก้"
ดูคำตอบแนะนำ
นี่คือ <strong>Test Execution</strong> โดยตรง
"ก่อน release ทีมสรุปว่า test coverage หลักผ่าน, bug ค้าง 2 ตัวเป็น low severity, พร้อมปล่อย"
ดูคำตอบแนะนำ
นี่คือ <strong>Test Closure</strong> เพราะเป็นการสรุปผลและ residual risk เพื่อใช้ตัดสินใจ
สิ่งที่ต้องเอาติดตัวไปจากบทนี้
- STLC คือวงจรของงานทดสอบ ไม่ใช่แค่การ execute
- 5 เฟสหลักคือ Planning → Analysis → Design → Execution → Closure
- ถ้า analysis และ design ไม่ดี execution จะไม่มีทางครอบคลุมได้ดี
- closure ไม่ใช่ของแถม แต่เป็นจุดที่ทีมใช้สรุป risk และบทเรียน
- QA ที่เข้าใจ STLC จะช่วยทีมได้ตั้งแต่ก่อนมี build ไม่ใช่แค่หลัง build มาแล้ว