# QA & Tester ในเอเจนซี: ตรวจอะไรก่อนปล่อยแคมเปญ

> ที่มา: https://phygital.co.th/insights/what-is-qa-tester-advertising-agency · เผยแพร่ 30 ตุลาคม 2563 · อ่าน 17 นาที · โดย PARANATH PANARATANA

QA & Tester ในเอเจนซีตรวจอะไรก่อนปล่อยแคมเปญ หลักการทดสอบที่วิชาชีพนี้ยึด และเหตุใดบั๊กในระบบเก็บข้อมูลลูกค้าจึงกลายเป็นเรื่องที่ต้องแจ้งหน่วยงานรัฐ

## Key Takeaways

- **การทดสอบทั้งหมดทุกกรณีเป็นไปไม่ได้ จึงต้องเลือกว่าจะตรวจอะไรก่อน** — หลักการทดสอบซอฟต์แวร์ที่ ISTQB รวบรวมไว้ระบุไว้ตรงตัวว่าการทดสอบทุกความเป็นไปได้ทำไม่ได้จริง สิ่งที่ทำได้คือจัดลำดับตามความเสี่ยง ไม่ใช่ตรวจให้ครบทุกช่อง
- **บั๊กที่กระทบข้อมูลลูกค้ามีกำหนดเวลาตามกฎหมายกำกับไว้** — ประกาศของคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2565 นับ "ข้อผิดพลาดบกพร่องหรืออุบัติเหตุ" เป็นเหตุละเมิดข้อมูลได้เช่นกัน และให้แจ้งสำนักงานภายใน 72 ชั่วโมงนับแต่ทราบเหตุ
- **ฟอร์มที่บอกไม่ได้ว่าผู้ใช้กรอกผิดตรงไหนคือข้อบกพร่องที่มีเกณฑ์วัด** — เกณฑ์ WCAG 2.2 ข้อ 3.3.1 ระดับ A กำหนดว่าเมื่อระบบตรวจพบข้อผิดพลาดในการป้อนข้อมูล ต้องระบุรายการที่ผิดและอธิบายเป็นข้อความ ไม่ใช่เปลี่ยนแค่สีกรอบ

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

QA & Tester คือผู้รับผิดชอบการตรวจว่าสิ่งที่ทีมสร้างขึ้นทำงานได้ตรงตามที่ตกลงไว้ก่อนส่งถึงผู้ใช้จริง ทั้งข้อความบนงานโฆษณา ฟังก์ชันของหน้าเว็บและแอป การเชื่อมต่อระหว่างระบบ และการรับมือกับผู้ใช้จำนวนมากในเวลาเดียวกัน บริษัท ฟิจิทัล เอเจนซี จำกัด (PHYGITAL AGENCY) ให้ผู้ตรวจอ่านเงื่อนไขแคมเปญพร้อมกับทีมออกแบบ เพราะรายการที่ต้องตรวจเขียนได้ก็ต่อเมื่อรู้แล้วว่าผลลัพธ์ที่ถูกต้องหน้าตาเป็นอย่างไร

## QA & Tester ในเอเจนซีรับผิดชอบอะไร

งานตรวจในเอเจนซีแยกได้เป็นสามด้านที่ใช้ความรู้คนละชุด แต่ผู้ว่าจ้างมักเรียกรวมกันด้วยคำเดียว ตารางด้านล่างเทียบทั้งสามด้านในมุมที่เจ้าของงานใช้ตัดสินว่าต้องการใครเข้ามาช่วย

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

ด้านที่สามคือด้านที่เลื่อนไม่ได้ เพราะผลของมันปรากฏพร้อมกับเงินค่าสื่อที่จ่ายไปแล้ว ธุรกิจที่รับข้อมูลผู้สนใจผ่านแบบฟอร์มเป็นช่องทางหลัก เป็นตัวอย่างที่ความผิดพลาดด้านที่สองเห็นผลช้าแต่เสียหายสะสม อ่านต่อได้ใน[บริการ B2B Lead Generation และ ABM รายชื่อขั้นต่ำ 300 บริษัท](https://phygital.co.th/insights/b2b-abm-lead-generation-agency)

### ผู้ตรวจต้องเป็นคนละคนกับผู้ทำงานจริงหรือไม่

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

## หลักการทดสอบที่วิชาชีพนี้ยึดเป็นกรอบ

การตรวจงานไม่ใช่เรื่องความละเอียดส่วนตัว แต่มีกรอบที่วงการใช้ร่วมกัน [หลักการทดสอบเจ็ดข้อที่ ISTQB รวบรวมไว้](https://astqb.org/istqb-foundation-level-seven-testing-principles/) เป็นชุดที่ใช้อ้างในหลักสูตรรับรองระดับพื้นฐานทั่วโลก สี่ข้อต่อไปนี้เป็นข้อที่เปลี่ยนวิธีคุยกับผู้ว่าจ้างได้ทันที

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

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

### ควรตรวจอะไรก่อนเมื่อเวลาเหลือไม่ถึงครึ่งของที่วางไว้

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

## งานตรวจหนึ่งรอบเดินอย่างไรก่อนปล่อยแคมเปญ

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

1. **เขียนรายการสิ่งที่ต้องตรวจจากเงื่อนไขที่ตกลงไว้** ทำพร้อมกับตอนออกแบบระบบ ไม่ใช่หลังพัฒนาเสร็จ เพราะรายการนี้ช่วยให้เห็นเงื่อนไขที่ยังไม่ได้ตกลงกันตั้งแต่ก่อนเริ่มเขียนโค้ด
2. **ตกลงเกณฑ์ผ่านเป็นตัวเลขหรือข้อความที่ชี้ขัดแย้งไม่ได้** เช่น ฟอร์มต้องส่งข้อมูลถึงปลายทางครบทุกฟิลด์ หรือระบบต้องรองรับผู้ใช้พร้อมกันตามตัวเลขที่คาดจากแผนสื่อ
3. **ตรวจเส้นทางที่ถูกต้องให้จบก่อน** เพื่อยืนยันว่าโครงหลักทำงานได้ ก่อนไปหาจุดพัง ขั้นนี้สั้นที่สุดแต่ต้องมาก่อน
4. **ตรวจเส้นทางที่ผู้ใช้ทำผิดลำดับ** เช่น กดปุ่มซ้ำ กดย้อนกลับกลางทาง ปิดหน้าจอแล้วเข้ามาใหม่ กรอกตัวอักษรในช่องที่รับเฉพาะตัวเลข และส่งฟอร์มโดยเว้นช่องบังคับ
5. **ตรวจภาระของระบบด้วยตัวเลขที่คาดว่าจะเกิดจริง** อ้างจากแผนซื้อสื่อ ไม่ใช่จากค่าที่คิดว่าเพียงพอ พร้อมดูว่าเมื่อเกินขีดแล้วระบบแจ้งผู้ใช้อย่างไร
6. **สรุปผลเป็นเอกสารที่ทำให้เกิดซ้ำได้** ระบุอุปกรณ์ รุ่นเบราว์เซอร์ ลำดับการกด และผลที่เกิด เพื่อให้ผู้แก้ไขทำซ้ำได้ทันทีโดยไม่ต้องเดา

### ทำไมต้องเขียนรายการสิ่งที่ต้องตรวจตั้งแต่ตอนออกแบบ

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

---

## บั๊กที่กระทบข้อมูลลูกค้ามีกำหนดเวลาตามกฎหมาย

ความผิดพลาดของระบบที่คนมักมองว่าเป็นเรื่องภาพลักษณ์ กลายเป็นเรื่องที่มีกำหนดเวลาตามกฎหมายทันทีเมื่อเกี่ยวกับข้อมูลส่วนบุคคล [ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565](https://www.mdes.go.th/law/detail/6336) ประกาศในราชกิจจานุเบกษาเมื่อ 15 ธันวาคม 2565 และนิยามการละเมิดไว้ครอบคลุมกว่าที่คนทั่วไปเข้าใจ

ข้อ 3 ของประกาศระบุว่าการละเมิดข้อมูลส่วนบุคคลหมายถึงการละเมิดมาตรการรักษาความมั่นคงปลอดภัยที่ทำให้เกิดการสูญหาย เข้าถึง ใช้ เปลี่ยนแปลง แก้ไข หรือเปิดเผยข้อมูลโดยปราศจากอำนาจหรือโดยมิชอบ **ไม่ว่าจะเกิดจากเจตนา ความจงใจ ความประมาทเลินเล่อ หรือข้อผิดพลาดบกพร่องหรืออุบัติเหตุ** ข้อความสุดท้ายนี้คือส่วนที่ผูกกับงานตรวจโดยตรง เพราะบั๊กที่ทำให้ข้อมูลหลุดไม่ได้ถูกยกเว้นเพียงเพราะไม่มีใครตั้งใจ

ข้อ 4 แบ่งประเภทของการละเมิดไว้สามแบบ ซึ่งแปลเป็นสิ่งที่ต้องตรวจได้ตรงตัว

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

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

### ธุรกิจต้องเตรียมอะไรไว้ล่วงหน้าเพื่อให้ทันกรอบเวลานี้

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

## ฟอร์มที่แจ้งข้อผิดพลาดไม่ชัดคือข้อบกพร่องที่วัดได้

ข้อโต้แย้งที่พบบ่อยระหว่างผู้ตรวจกับผู้ออกแบบคือเรื่องข้อความแจ้งเตือนในฟอร์ม ฝ่ายหนึ่งเห็นว่าเป็นความชอบส่วนตัว อีกฝ่ายเห็นว่าเป็นข้อบกพร่อง ข้อนี้มีเกณฑ์ตัดสินอยู่แล้วใน [เกณฑ์ความสำเร็จข้อ 3.3.1 ของ WCAG 2.2](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html) ซึ่งเป็นเกณฑ์ระดับ A คือระดับพื้นฐานที่สุด

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

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

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

## การแก้นาทีสุดท้ายหลังตรวจผ่านแล้วคือช่องโหว่ที่พบบ่อยที่สุด

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

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

กติกาสองข้อทำให้ช่วงนี้ปลอดภัยขึ้น ข้อหนึ่งคือการแก้ทุกครั้งหลังรับรองแล้วต้องตรวจซ้ำเฉพาะจุดที่แก้และจุดที่ดึงค่าเดียวกันไปใช้ อีกข้อคือต้องมีเส้นตายของการแก้ไขที่ระบุไว้ในสัญญา เพื่อให้ยังมีเวลาตรวจซ้ำก่อนเวลาเผยแพร่ ธุรกิจในหมวดที่มีข้อกำหนดกำกับข้อความโฆษณาเป็นการเฉพาะยิ่งต้องมีข้อนี้ เพราะการแก้ข้อความหนึ่งบรรทัดอาจทำให้ชิ้นงานผิดข้อกำหนดทั้งชิ้น อ่านต่อได้ใน[Influencer คลินิกความงาม มาตรา 59 ห้ามรับรองเครื่องมือแพทย์](https://phygital.co.th/insights/influencer-aesthetic-clinic-compliant-agency)

### การแก้เล็กน้อยระดับไหนที่ยังต้องตรวจซ้ำ

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

## สิ่งที่เจ้าของงานตรวจเองได้ก่อนอนุมัติให้ปล่อย

หกข้อนี้ไม่ต้องใช้ความรู้ทางเทคนิค และเป็นจุดที่ปัญหาถูกพบหลังเผยแพร่บ่อยที่สุด

1. **เดินครบทุกขั้นตอนบนโทรศัพท์ของตัวเองด้วยอินเทอร์เน็ตมือถือ** ตั้งแต่จุดที่โฆษณาพาเข้ามาจนถึงหน้ายืนยันผล ไม่ใช่เปิดดูแค่หน้าแรก
2. **ตรวจว่าข้อมูลที่กรอกไปถึงปลายทางครบทุกช่อง** เปิดดูรายการจริงในระบบหลังบ้านแล้วเทียบกับที่กรอก โดยเฉพาะชื่อภาษาไทยที่มีสระบนล่างและเบอร์โทรที่ขึ้นต้นด้วยศูนย์
3. **ทดลองทำผิดอย่างที่ผู้ใช้ทำจริง** กดส่งซ้ำ กดย้อนกลับแล้วส่งอีกครั้ง เว้นช่องบังคับ และกรอกอักษรในช่องที่รับเฉพาะตัวเลข แล้วดูว่าระบบบอกอะไรกลับมา
4. **เทียบข้อความบนงานโฆษณากับเงื่อนไขจริงทุกตัวอักษร** ทั้งตัวเลขส่วนลด วันเริ่มและวันสิ้นสุด จำนวนสิทธิ์ และข้อความกำกับที่หมวดสินค้านั้นบังคับให้แสดง
5. **ขอผลการทดสอบภาระเป็นตัวเลข** ว่าทดสอบด้วยผู้ใช้พร้อมกันกี่คนและผลเป็นอย่างไร พร้อมเทียบกับจำนวนที่แผนสื่อคาดไว้
6. **ขอรายการสิ่งที่ยังไม่ได้ตรวจ** ข้อนี้สำคัญกว่ารายการที่ตรวจแล้ว เพราะหลักการข้อแรกบอกว่าการตรวจบอกไม่ได้ว่าไม่มีข้อบกพร่อง การรู้ขอบเขตที่ยังไม่ครอบคลุมจึงเป็นข้อมูลสำหรับตัดสินใจว่าจะปล่อยหรือเลื่อน

ในหกข้อนี้ ข้อที่สองกับข้อที่หกมักหายไปก่อนเพื่อน ข้อหนึ่งเพราะดูเป็นงานของฝ่ายเทคนิค อีกข้อเพราะไม่มีใครอยากถามคำถามที่คำตอบทำให้ต้องเลื่อนวันเผยแพร่

## ข้อจำกัดของการทดสอบที่ต้องรู้ก่อนตกลงขอบเขตงาน

ห้าเรื่องต่อไปนี้ติดมากับธรรมชาติของการทดสอบเอง ไม่ได้แปลว่าผู้ตรวจทำงานไม่ดีพอ

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

## ทีมที่ไม่มีผู้ตรวจแยกทำอย่างไรให้ยังตรวจได้จริง

สามวิธีนี้ใช้ได้ทันทีโดยไม่ต้องเพิ่มคน และได้ผลมากกว่าการขอให้ทุกคน "ช่วยดูอีกรอบ"

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

ทีมควรเริ่มมองหาผู้ตรวจประจำเมื่อระบบของตัวเองเริ่มรับเงินหรือเก็บข้อมูลส่วนบุคคล เมื่อเงื่อนไขแคมเปญถูกแก้ทุกสัปดาห์ หรือเมื่อข้อบกพร่องเรื่องเดิมโผล่ซ้ำข้ามโครงการ ธุรกิจที่มีระบบสมาชิกผูกกับการเก็บเงินเป็นรอบเข้าข่ายนี้ด้วย อ่านต่อได้ใน[สมาชิกร้านสัตว์เลี้ยงบน LINE OA บัตรแสตมป์กับ CRM 369 บาท](https://phygital.co.th/insights/pet-business-loyalty-program-agency)

## สรุป

งานของผู้ตรวจสอบคุณภาพในเอเจนซีมีกรอบวิชาชีพของตัวเอง ไม่ใช่ความละเอียดส่วนบุคคล หลักการที่ ISTQB รวบรวมไว้ระบุว่าการทดสอบบอกได้แค่ว่ามีข้อบกพร่องแต่บอกไม่ได้ว่าไม่มี และการทดสอบทุกความเป็นไปได้ทำไม่ได้จริง จึงต้องเรียงลำดับตามความเสี่ยง ฝั่งกฎหมาย ประกาศของคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลนับข้อผิดพลาดบกพร่องเป็นเหตุละเมิดข้อมูลได้ และให้แจ้งสำนักงานภายในเจ็ดสิบสองชั่วโมงนับแต่ทราบเหตุ ส่วนข้อโต้แย้งเรื่องข้อความแจ้งข้อผิดพลาดในฟอร์มมีเกณฑ์ WCAG ระดับ A ตัดสินไว้แล้ว และช่วงที่เสี่ยงที่สุดของทุกโครงการคือการแก้ไขเล็กน้อยหลังผู้ตรวจรับรองงานไปแล้ว

## คำถามที่พบบ่อย (FAQ)

### ผู้ตรวจต้องเขียนโค้ดได้หรือไม่

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

### งบสำหรับงานตรวจควรอยู่ที่สัดส่วนเท่าไรของโครงการ

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

### เครื่องมือทดสอบอัตโนมัติแทนคนตรวจได้หรือไม่

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

### ควรตรวจเว็บบนอุปกรณ์กี่รุ่นถึงเรียกว่าพอ

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

### ถ้าพบข้อบกพร่องตอนใกล้เวลาเผยแพร่ ควรตัดสินอย่างไร

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

### ข้อบกพร่องที่พบหลังเผยแพร่ควรบันทึกอะไรไว้

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

## แคมเปญที่รู้ว่าตรวจอะไรไปแล้ว และอะไรที่ยังไม่ได้ตรวจ

บริษัท ฟิจิทัล เอเจนซี จำกัด วางแผนการตรวจไว้ตั้งแต่ขั้นออกแบบระบบ ทดสอบภาระด้วยตัวเลขที่อ้างจากแผนสื่อจริง และส่งมอบรายงานที่ระบุทั้งขอบเขตที่ตรวจแล้วและขอบเขตที่ยังไม่ครอบคลุม เพื่อให้ธุรกิจตัดสินใจวันเผยแพร่บนข้อมูลจริง

- [นัดประชุมผ่าน Google Meet](https://calendar.app.google/DotQdE7Ca8LZG6Us5)
- [เพิ่มเพื่อนใน LINE](https://lin.ee/J8Qq8Do)