เขียน Test Case ยังไงให้มือใหม่อ่านแล้วทำตามได้จริง

ในบทความที่แล้วเราปูพื้นฐาน Software Testing กันไปแล้ว ตั้งแต่ Unit, Integration, System ไปจน Acceptance test และปิดท้ายไว้ว่า “ลองเริ่มจากการฝึกเขียน test case ให้ครอบคลุมและอ่านง่าย ก่อนจะค่อยขยับไปเรียนรู้เรื่อง automation”

วันนี้มาทำตามสัญญานั้นกัน เพราะการรู้ทฤษฎีว่า testing มีกี่ประเภทเป็นแค่จุดเริ่มต้น สิ่งที่ทำให้คุณ “เป็น QA” จริง ๆ คือการลงมือเขียน test case ที่คนอื่นอ่านแล้วทำตามได้ ไม่ใช่ test case ที่เข้าใจแค่คนเขียนคนเดียว

ทำไม test case ที่ “อ่านไม่รู้เรื่อง” ถึงเป็นปัญหาใหญ่กว่าที่คิด

มือใหม่หลายคนเขียน test case แบบจดสิ่งที่ตัวเองคิดในหัว แล้วข้ามขั้นตอนที่คิดว่า “มันชัดอยู่แล้ว” ไป ผลคือเมื่อคนอื่นต้องมารันตามที่เขียนไว้ อาจเป็นทีม dev, ทีม UAT, หรือแม้แต่ตัวคุณเองในอีก 3 เดือนข้างหน้า จะเจอคำถามว่า “ตอนนี้ระบบควรอยู่ในสถานะไหน” หรือ “ทำตามขั้นตอนนี้แล้วควรเห็นอะไร”

test case ที่ดีต้องทำให้คนที่ไม่รู้ context อะไรเลย สามารถหยิบไปรันแล้วได้ผลเหมือนกับที่คุณรันเอง นั่นคือเกณฑ์วัดความสำเร็จที่ใช้ได้จริง

คิด Test Scenario ก่อนลงมือเขียน Test Case

ก่อนจะไปถึงเรื่องโครงสร้าง มีอีกขั้นที่มือใหม่มักข้ามไปโดยไม่รู้ตัว นั่นคือการคิด Test Scenario ก่อนลงมือเขียน Test Case

สองคำนี้มักถูกใช้สลับกันจนสับสน แต่จริง ๆ แล้วต่างระดับกัน:

• Test Scenario คือ “เรื่องที่ต้องทดสอบ” ระดับภาพรวม ตอบคำถามว่า “อะไรที่ต้องถูกตรวจสอบบ้าง” เช่น “ผู้ใช้เข้าสู่ระบบด้วยรหัสผ่านผิด”
• Test Case คือรายละเอียดของการทดสอบ scenario นั้น ตอบคำถามว่า “ทดสอบยังไง ด้วยข้อมูลอะไร แล้วต้องเห็นผลอะไร”

scenario เดียวสามารถขยายเป็นหลาย test case ได้ เช่น scenario “เข้าสู่ระบบด้วยรหัสผ่านผิด” อาจแตกเป็น test case ย่อยทั้ง “ผิดครั้งแรก”, “ผิดจนครบจำนวนครั้งที่กำหนดจนบัญชีถูกล็อก” หรือ “ผิดแล้วลองใหม่ทันที”

ถ้าข้ามขั้นตอนนี้ไปเขียน test case ทันที มักจะได้ test case ที่ครอบคลุมแค่มุมที่นึกออกตอนนั้น แล้วพลาดมุมสำคัญไปโดยไม่รู้ตัว เพราะไม่ได้มองภาพรวมของ feature ก่อน

วิธีคิด scenario ให้ครอบคลุม

1. เริ่มจาก requirement หรือ user story อ่านแล้วแยกออกมาเป็นประโยคสั้น ๆ ว่า “ผู้ใช้ต้องทำอะไรได้บ้าง” แต่ละประโยคคือ scenario เบื้องต้นหนึ่งตัว
2. ไล่ตาม business flow แบบ end-to-end มองทั้ง flow ตั้งแต่จุดเริ่มต้นจนจบ ไม่ใช่มองแค่ฟีเจอร์เดี่ยว ๆ แยกส่วน เพราะปัญหาจริงมักเกิดตรงรอยต่อระหว่างฟีเจอร์
3. ใช้ mind map หรือ checklist แตกฟีเจอร์ใหญ่เป็นกิ่งย่อย ช่วยให้เห็นมุมที่ซ่อนอยู่ ไม่ใช่แค่ flow หลักที่นึกออกทันที
4. ตั้งคำถามว่า “ใครจะใช้ feature นี้” และ “ในสถานการณ์ไหนได้บ้าง” มองจากมุมผู้ใช้จริง ไม่ใช่มุมของคนพัฒนาที่รู้ flow อยู่แล้ว
5. รีวิว scenario กับคนอื่นในทีมก่อนแตกเป็น test case ทั้ง BA, dev, หรือ Product Owner เพราะแต่ละคนมองเห็นมุมที่ต่างกัน และมักช่วยจับ scenario ที่เรามองข้ามไปได้

ไม่ต้องกดดันตัวเองให้คิด scenario ครบสมบูรณ์ตั้งแต่รอบแรก เขียนออกมาก่อนเท่าที่นึกได้ แล้วค่อย refine เพิ่มทีหลังเมื่อเข้าใจ requirement ลึกขึ้น พอได้ list ของ scenario ที่ครอบคลุมแล้ว ขั้นต่อไปคือแปลงแต่ละ scenario ให้เป็น test case ที่มีโครงสร้างชัดเจน

โครงสร้าง test case ที่ดี มีอะไรบ้าง

ไม่ว่าจะใช้ template แบบไหน test case ที่ใช้งานได้จริงมักมีองค์ประกอบเหล่านี้ครบ

• Test Case ID รหัสอ้างอิงที่ไม่ซ้ำกัน ช่วยให้ track ได้ว่า case นี้เกี่ยวกับ requirement ไหน เจอบั๊กตัวไหน
• Test Case ชื่อสั้น ๆ บอกว่ากำลังทดสอบอะไร เช่น “ทดสอบการ login ด้วยรหัสผ่านผิด”
• Scenario ระบุว่า test case นี้มาจาก scenario ไหน เช่น “ผู้ใช้เข้าสู่ระบบด้วยรหัสผ่านผิด” ช่วยให้ตรวจสอบกลับไปยัง requirement ได้ และเห็นว่า test case นี้เป็นแค่หนึ่งในหลาย case ที่แตกออกมาจาก scenario เดียวกัน
• Precondition สถานะของระบบ/ข้อมูลก่อนเริ่มทดสอบ เช่น “มีบัญชีผู้ใช้ที่ active อยู่แล้วในระบบ” ถ้าข้ามส่วนนี้ คนที่มารันต่อจะไม่รู้ว่าต้องเตรียมอะไรก่อน
• Test Steps ขั้นตอนที่ทำตามได้ทีละสเต็ป เขียนเป็นคำสั่งชัด ๆ ไม่ใช่บรรยายความรู้สึก
• Test Data ข้อมูลที่ใช้ทดสอบจริง เช่น username/password ที่ใช้ ไม่ใช่แค่เขียนว่า “กรอกข้อมูลให้ถูกต้อง”
• Expected Result ผลลัพธ์ที่ควรเกิดขึ้นถ้าระบบทำงานถูกต้อง ต้องเขียนให้ชัดจนวัดผลได้ ไม่ใช่ “ระบบทำงานปกติ”
• Actual Result / Status ผลที่เกิดขึ้นจริงตอน execute และสถานะ pass/fail

หลักการง่าย ๆ คือ: ถ้าคุณลบ context ในหัวตัวเองออกไปทั้งหมด แล้วอ่าน test case นี้ซ้ำ คุณยังรันตามได้ไหม ถ้าตอบว่าไม่ นั่นคือสัญญาณว่าต้องเขียนละเอียดขึ้น

วิธีคิด Happy Path กับ Edge Case ให้ครอบคลุม

มือใหม่ส่วนใหญ่เขียน test case ได้ดีในระดับ “happy path” คือ flow ที่ผู้ใช้ทำทุกอย่างถูกต้องตามที่ออกแบบไว้ แต่บั๊กจริงในงานส่วนใหญ่ไม่โผล่ที่ตรงนั้น

ลองใช้กรอบคิดนี้ในการไล่ scenario:

1. Happy path ก่อนเสมอ flow ปกติที่ผู้ใช้ทำตามขั้นตอนที่ถูกต้อง เพื่อยืนยันว่า core function ใช้งานได้
2. Input ที่ผิดแต่ “เดาได้” เช่น กรอกอีเมลไม่มี @, กรอกตัวเลขในช่องที่ควรเป็นตัวอักษร, ปล่อยช่องว่างที่ required
3. ขอบของค่าที่ยอมรับได้ (boundary) เช่น ถ้าระบบจำกัดความยาวรหัสผ่าน 8–20 ตัวอักษร ให้ลองทดสอบที่ 7, 8, 20, 21 ตัวอักษร เพราะบั๊กมักซ่อนอยู่ตรงขอบพอดี ไม่ใช่ตรงกลาง
4. ลำดับการทำงานที่ไม่ปกติ เช่น กดปุ่ม submit สองครั้งรัว ๆ, กด back แล้วกด submit ซ้ำ, ปิดหน้าต่างกลางที่ทำรายการ
5. สถานะของระบบที่ผิดจากที่คาด เช่น session หมดอายุระหว่างทำรายการ, ข้อมูลที่อ้างอิงถูกลบไปแล้วโดยอีก process

ไม่ต้องไล่ครบทุกข้อในทุก feature แต่การมีกรอบคิดนี้ติดตัว จะช่วยให้คุณตั้งคำถาม “แล้วถ้า…” ได้เป็นธรรมชาติ ซึ่งเป็นทักษะที่แยก QA มือใหม่กับ QA ที่ทำงานมาสักพักออกจากกันชัดที่สุด

ตัวอย่าง Test Case ที่ไม่ดี vs ที่ดี

ลองดูตัวอย่างเปรียบเทียบ สมมุติว่าทดสอบฟอร์ม login

แบบที่อ่านยาก

• Scenario: ทดสอบการ login
• Test Case: ทดสอบ login
• Steps: ลอง login ดูว่าใช้งานได้ไหม
• Expected: ใช้งานได้ปกติ

ปัญหาคือไม่มีใครรู้ว่า “ใช้งานได้ไหม” หมายถึงอะไร ไม่มี test data ไม่มี precondition ถ้าผลออกมาไม่ตรงกัน จะเถียงกันไม่จบว่าใครทำผิด

แบบที่อ่านแล้วทำตามได้

• Test Case ID: TC-LOGIN-002
• Scenario: ผู้ใช้เข้าสู่ระบบด้วยรหัสผ่านผิด
• Test Case: Login ด้วยรหัสผ่านผิด แสดง error message ที่ถูกต้อง
• Precondition: มีบัญชีผู้ใช้ testuser01 ที่ active อยู่ในระบบแล้ว
• Test Steps:

1. เปิดหน้า login
2. กรอก username เป็น ODT19
3. กรอก password เป็น P@ssW0rd
4. กดปุ่ม “เข้าสู่ระบบ”

• Expected Result: ระบบแสดงข้อความ “ชื่อผู้ใช้หรือรหัสผ่านไม่ถูกต้อง” และไม่อนุญาตให้เข้าสู่ระบบ

เห็นความต่างชัดเจนว่าฉบับที่สองทำให้ใครก็ตามที่ไม่รู้ context มาก่อน สามารถรันแล้วเทียบผลได้ทันทีว่า pass หรือ fail

ข้อผิดพลาดที่มือใหม่ QA เจอบ่อยที่สุด

• เขียน expected result แบบกว้างเกินไป เช่น “ระบบทำงานถูกต้อง” ซึ่งวัดผลไม่ได้จริง ต้องเจาะจงว่าเห็นอะไร ข้อความอะไร หรือสถานะไหน
• ลืม precondition ทำให้คนที่มารันต้องเดาว่าต้องเตรียมข้อมูลยังไงก่อน
• เขียน 1 test case ทำหลายอย่างพร้อมกัน ทำให้เมื่อ fail แล้วไม่รู้ว่า fail เพราะจุดไหน ควรแยกเป็นหลาย case ที่แต่ละ case ทดสอบจุดเดียว
• ไม่ระบุ test data ที่ใช้จริง เขียนแค่ “กรอกข้อมูลให้ถูกต้อง” โดยไม่บอกว่าข้อมูลนั้นคืออะไร ทำให้ผลทดสอบไม่ reproduce ซ้ำได้
• ข้ามขั้นตอนคิด scenario แล้วเขียน test case ทันที ทำให้ได้ test case ที่ครอบคลุมแค่มุมที่นึกออกตอนนั้น พลาดมุมสำคัญของ feature ไปโดยไม่รู้ตัว

สรุป

test case ที่ดีไม่ได้วัดจากความยาวหรือความซับซ้อน แต่วัดจากว่า “คนอื่นอ่านแล้วทำตามได้แม่นยำแค่ไหน”

ลองฝึกเขียนตามโครงสร้าง precondition → steps → test data → expected result ให้ครบทุกครั้ง แล้วลองให้เพื่อนในทีมอ่านดูว่าทำตามได้โดยไม่ต้องถามคุณเพิ่มไหม นั่นคือบทพิสูจน์ที่ดีที่สุด

พอเขียน test case ได้แม่นแล้ว ขั้นต่อไปที่ควรฝึกคือการ execute แล้วรายงานผลให้ทีม dev เข้าใจง่ายเมื่อเจอบั๊ก ซึ่งจะเป็นเนื้อหาของบทความต่อไป