UAT รอบแรก คำแนะนำ ตรวจซ้ำรอบ 2 ตรวจระบบจริง · 12 กันยายน 2569
ผลตรวจรอบ 2 UX/UI, Technical, Performance และการใช้คำ — แยกสิ่งที่พบจริงออกจากแนวทางพัฒนาต่อ
20 จุดปรับปรุง4 ข้อควรแก้ก่อนเปิดใช้6 เทคนิคให้ประเมินต่อ
เริ่มที่ความน่าเชื่อถือของข้อมูล แก้ยอดงานเปิด, ความหมายของกำไร, ข้อความ AI ตายตัว และสถานะสำเร็จ ก่อนเพิ่มความเร็วหรือรายละเอียดตกแต่ง
Technical6 ข้อเสนอ UX/UI6 ข้อเสนอ Performance5 ข้อเสนอ การใช้คำ3 ข้อเสนอ ตรวจหน้าหลักฝั่ง Admin · Sales/Delivery workspace ยังติดการเข้าสู่ระบบ
Technical ความถูกต้องและความน่าเชื่อถือ · 6 ข้อ
R2-01 ใช้ขอบเขตเดียวกันสำหรับจำนวนงานเปิด Dashboard · งานขาย · Reports P1 + ยืนยันจาก UI และ frontend
พบอะไร หน้างานขายระบุ 67 งานที่เปิดอยู่ แต่ผลรวม 8 ขั้นและ Reports ระบุ 65 งาน; รายการมีทั้งสถานะเสร็จสิ้นและยกเลิก ใน frontend หัวข้อใช้จำนวนรายการทั้งหมด
ควรปรับอย่างไร แยกทั้งหมด / เปิดอยู่ / เสร็จสิ้น / ยกเลิก ใช้กติกา active เดียวกันใน API และทุกหน้าจอ พร้อมระบุขอบเขตของตัวกรอง
เกณฑ์รับงาน ข้อมูลชุดเดียวกันและ filter เดียวกันต้องได้ยอดตรงกัน; เคส completed/cancelled ไม่เพิ่มตัวนับ active
ผู้รับผิดชอบที่เสนอ Backend + Frontend + QA
หลักฐานภายใน: R2-E01, E02, E07 · ต่อเนื่องจาก D04
Prompt พร้อมใช้ R2-01 · แก้ข้อความก่อนใช้ได้ R2-02 คอลัมน์กำไรแสดงค่าคอมมิชชัน และซ่อนค่า 0 งานขาย · ตัวเลขค่าตอบแทน P1 + ยืนยันจาก frontend ที่เผยแพร่
พบอะไร คอลัมน์ “กำไร (สด)” render จาก commission_amount และใช้เงื่อนไข truthy ทำให้ 0 แสดงเป็นขีด ไม่ได้เป็นเพียงปัญหาถ้อยคำ
ควรปรับอย่างไร ตกลงนิยามกำไรกับค่าคอมมิชชัน แล้วผูกแต่ละคอลัมน์กับฟิลด์ที่ถูกต้อง ใช้ null/undefined แทนกรณีไม่มีข้อมูล และแสดง 0 เป็น 0 บาท
เกณฑ์รับงาน fixture กำไรและคอมมิชชันคนละค่า, ศูนย์, null และค่าติดลบ แสดงความหมายถูกต้องทั้ง list/detail/report
ผู้รับผิดชอบที่เสนอ Finance owner + Backend + Frontend
หลักฐานภายใน: R2-E02 · source-notes · เกี่ยวข้อง D14
Prompt พร้อมใช้ R2-02 · แก้ข้อความก่อนใช้ได้ R2-03 แยกข้อความตัวอย่างออกจากข้อมูลวิเคราะห์จริง งานขาย · AI summary P1 + ยืนยันจาก UI และ frontend
พบอะไร ข้อความ AI เรื่องคอขวด ค่าเฉลี่ย 1.1/2.4 วัน และปิดเร็วกว่า 1.8 วันเป็น literal ในไฟล์หน้า Sales; ข้อความ AI แสดงแม้ข้อมูลรายการยังโหลดไม่เสร็จ
ควรปรับอย่างไร นำข้อความตายตัวออกจาก insight จริง หรือระบุ “ตัวอย่างการวิเคราะห์” ให้ชัด ก่อนเปิดใช้จริงต้องมีข้อมูลอ้างอิง ช่วงเวลา จำนวนตัวอย่าง เวลาอัปเดต และลิงก์ดูรายการที่เกี่ยวข้อง
เกณฑ์รับงาน เปลี่ยน dataset/ช่วงเวลาแล้ว insight เปลี่ยนตาม; ไม่มีข้อมูลหรือโหลดผิดพลาดต้องไม่สร้างข้อสรุปเชิงข้อเท็จจริง
ผู้รับผิดชอบที่เสนอ Product + Data + Frontend
หลักฐานภายใน: R2-E02, E04 · source-notes
หลักการ: Carbon · Data table
Prompt พร้อมใช้ R2-03 · แก้ข้อความก่อนใช้ได้ R2-04 เครื่องหมายถูกต้องหมายถึงผ่านเงื่อนไขจริง รายละเอียดงานขาย · เอกสาร P1 + ยืนยันจาก UI; กติกาต้องตรวจต่อใน backend
พบอะไร งานทดสอบเดิมที่ยังไม่มี VIN แสดงเครื่องหมายถูกครบ 7 ขั้น และสถานะภายใน delivery; ส่วนเอกสารมีทั้งสร้างแล้ว/ยืนยันแล้ว จึงอาจถูกอ่านว่าเสร็จสมบูรณ์ทั้งกระบวนการ
ควรปรับอย่างไร ใช้ progress indicator ที่แยกเสร็จแล้ว / ขั้นปัจจุบัน / ยังไม่เริ่ม / ติดเงื่อนไข โดยอ้างอิงสถานะและหลักฐานรายขั้น แยกเอกสารร่างออกจากฉบับออกจริง
เกณฑ์รับงาน fixture ไม่ครบ prerequisite ต้องไม่เห็นเครื่องหมายสำเร็จ; การแก้ UI ต้องไม่ข้าม validation ฝั่ง server
ผู้รับผิดชอบที่เสนอ Product + Backend + Frontend
หลักฐานภายใน: R2-E05 · ต่อเนื่อง D09/D10
Prompt พร้อมใช้ R2-04 · แก้ข้อความก่อนใช้ได้ R2-05 ตัวกรองสาขาไม่ตรงกับรายการจริง งานขาย · ตัวกรองสาขา P2 + ทดสอบ UI และตรวจ frontend
พบอะไร เลือกบางนาแล้วไม่พบรายการ ทั้งที่รายการทั้งหมดมีสาขาบางนา; ไม่มีรังสิตใน dropdown ใน frontend ตัวเลือกเขียนตายตัวและเทียบ branch_name กับข้อความที่เลือกโดยตรง
ควรปรับอย่างไร ใช้ branch_id เป็น value และใช้ชื่อเพื่อแสดงผล ดึงตัวเลือกจาก master data ตามสิทธิ์ เพิ่มจำนวนผลลัพธ์และปุ่มล้างตัวกรอง
เกณฑ์รับงาน ทุกสาขาที่มีข้อมูลกรองได้ครบ; เปลี่ยนชื่อสาขาไม่ทำให้กรองเสีย; สาขาที่ไม่มีสิทธิ์ไม่ปรากฏหรือเรียกข้อมูลได้
ผู้รับผิดชอบที่เสนอ Frontend + Backend + QA
หลักฐานภายใน: R2-E02, E14 · ต่อเนื่อง D05
หลักการ: Carbon · Data table
Prompt พร้อมใช้ R2-05 · แก้ข้อความก่อนใช้ได้ R2-11 แยก error ออกจากไม่มีรายการ งานขาย · กรณีโหลดผิดพลาด P2 + ตรวจเส้นทาง error ใน frontend; ยังไม่ได้จำลอง API ล่ม
พบอะไร getAdminSales ถูกเรียกใน useEffect; catch เขียน console.error แล้ว finally ปิด loading โดยไม่มี error state จึงมีเส้นทางที่แสดงตารางว่างเมื่อเรียกข้อมูลไม่สำเร็จ
ควรปรับอย่างไร เพิ่ม error state พร้อมลองใหม่ เก็บข้อมูลล่าสุดถ้ามี และแยก no data / no match / no permission / session expired ออกจากกัน
เกณฑ์รับงาน ทดสอบ 500, timeout, 401/403 และ empty response ในสภาพแวดล้อมทดสอบ; error ต้องไม่แสดงเป็นไม่มีงานขาย และ retry กลับมาทำงานได้
ผู้รับผิดชอบที่เสนอ Frontend + Backend + QA
หลักฐานภายใน: source-notes · R2-E03 สำหรับ empty state
หลักการ: W3C · Status messages
Prompt พร้อมใช้ R2-11 · แก้ข้อความก่อนใช้ได้ UX/UI อ่านง่าย เลือกและทำงานได้ชัดเจน · 6 ข้อ
R2-06 ใช้ link/button จริงกับสิ่งที่กดได้ งานขาย · รายละเอียด · แถบเครื่องมือ P2 + ยืนยันจาก DOM และ frontend
พบอะไร การ์ดขั้นเป็น div onClick, แถวเป็น tr onClick, “เปิด →” และ “ดู PDF” เป็น a ไม่มี href; ช่องค้นหา Sales ไม่มี label หรือ aria-label ใน DOM
ควรปรับอย่างไร ใช้ button พร้อม aria-pressed สำหรับกรองขั้น และ link href จริงสำหรับเปิดงาน/PDF ใส่ชื่อ action ที่สื่อความหมายและชื่อช่องค้นหา รองรับ Tab, Enter/Space และ focus ที่เห็นชัด
เกณฑ์รับงาน ทำ flow ค้นหา → กรองขั้น → เปิดงานได้ด้วย keyboard; ชื่อ control อ่านรู้เรื่อง; action ที่ยังใช้ไม่ได้บอกเหตุผล
ผู้รับผิดชอบที่เสนอ Frontend + QA accessibility
หลักฐานภายใน: R2-E02, E05 · source-notes
หลักการ: Carbon · Data table
Prompt พร้อมใช้ R2-06 · แก้ข้อความก่อนใช้ได้ R2-07 ยกระดับตัวอักษรที่ใช้ตัดสินใจให้อ่านง่าย Dashboard · ตารางและข้อความรอง P2 + วัด computed style จาก DOM
พบอะไร พบข้อความรอง 10–11px หลายตำแหน่งและหัวข้อ panel 14px ทำให้ข้อมูลหนาแน่นแม้จอ desktop 1280px; ขนาดเล็กเพียงอย่างเดียวไม่ใช่ข้อสรุปว่าไม่ผ่าน WCAG
ควรปรับอย่างไร กำหนด type tokens: เนื้อหา 16px, ตาราง/label ประจำ 14px, metadata 12–13px, หัวข้อหน้า 24–28px ใช้ line-height ที่อ่านภาษาไทยชัดและ tabular numbers สำหรับยอดเงิน
เกณฑ์รับงาน อ่านข้อความสำคัญได้ที่ขนาดปกติและขยาย 200%; ไม่ตัดหน่วยเงิน สถานะ หรือวันครบกำหนด; ตรวจ contrast ของคู่สีจริง
ผู้รับผิดชอบที่เสนอ Design + Frontend
หลักฐานภายใน: R2-E01
หลักการ: Carbon · Typography
Prompt พร้อมใช้ R2-07 · แก้ข้อความก่อนใช้ได้ R2-08 ทำ icon และสีให้สื่อความหมายชุดเดียวกัน Dashboard · Sales · Settings P3 + สังเกต UI และแนวทางออกแบบ
พบอะไร มี Carbon outline icons ปน ⏱, ⭐, ⚠, 🛈, 🧪; สถานะเริ่มงานบางขั้นใช้ tag สีเหลือง แม้ไม่ได้ระบุความเสี่ยงหรือเกินกำหนด
ควรปรับอย่างไร คง mood เรียบ ชัด น่าเชื่อถือ ใช้ icon ชุดเดียวขนาด 16/20px; สีฟ้าสำหรับ action/กำลังทำ สีเขียวสำหรับสำเร็จ สีเหลืองเมื่อควรระวัง สีแดงเมื่อผิดพลาดหรืออันตราย ใช้ข้อความกำกับทุกสถานะ; ดาวใช้กับคะแนนได้
เกณฑ์รับงาน สถานะเดียวกันใช้สีและคำเดียวกันทุกหน้า; แยกสถานะได้เมื่อมองแบบ grayscale; icon-only มี accessible name และเป้ากดเหมาะกับอุปกรณ์
ผู้รับผิดชอบที่เสนอ Design system + Frontend
หลักฐานภายใน: R2-E01, E02, E11
หลักการ: Carbon · Color · Carbon · Typography
Prompt พร้อมใช้ R2-08 · แก้ข้อความก่อนใช้ได้ R2-09 หยุดการล้นแนวนอนของทั้งหน้า งานขาย · mobile 390px P2 + ทดสอบ viewport และวัด DOM
พบอะไร ที่ viewport 390px เมื่อปิดเมนูแล้ว document scrollWidth ยังเป็น 661px; เนื้อหาตารางและชุด Funnel ไม่พอดีกับพื้นที่ใช้งาน
ควรปรับอย่างไร ให้ page layout ยุบตามจอ จัด Funnel เป็นชุดที่อ่านได้และใช้ card/list รายงานขายบนมือถือ หรือให้เลื่อนเฉพาะกรอบตารางที่มีชื่อกำกับ เก็บ action หลักให้เห็น
เกณฑ์รับงาน 320/390/768px ไม่มีการเลื่อนทั้งหน้าแนวนอน; เปิดงานและกรองได้ด้วย touch; ข้อยกเว้นตาราง 2 มิติใช้เฉพาะบริเวณตาราง
ผู้รับผิดชอบที่เสนอ Frontend + Design + QA
หลักฐานภายใน: R2-E12 · ต่อเนื่อง D13
หลักการ: W3C · Reflow · Carbon · Data table
Prompt พร้อมใช้ R2-09 · แก้ข้อความก่อนใช้ได้ R2-17 เปลี่ยนคิวส่งมอบให้เห็นสิ่งที่ต้องทำก่อน Admin · คิวส่งมอบ P2 + ยืนยันจาก UI; เป็นข้อเสนอการจัดงาน
พบอะไร ตารางที่เรียงตามกำหนดแสดงงานส่งมอบแล้วก่อนงานค้าง และมีงานค้างที่วันกำหนดผ่านมาแล้วโดยไม่มีป้ายเกินกำหนด; คะแนนทีมไม่มีจำนวนผู้ประเมินให้เห็นในตาราง
ควรปรับอย่างไร default เป็นคิวต้องทำ แบ่งเกินกำหนด/วันนี้/ถัดไป มี filter ดูงานเสร็จแล้ว; เพิ่ม next action, owner และเหตุที่ติด พร้อมจำนวนรีวิว/ช่วงเวลาของคะแนน
เกณฑ์รับงาน หางานเร่งด่วนได้โดยไม่ไล่อ่านทั้งตาราง; งานเสร็จไม่ปะปนในคิวที่ต้องทำ; สีแดง/เหลืองเกิดจากเงื่อนไขที่นิยามไว้
ผู้รับผิดชอบที่เสนอ Delivery lead + Design + Frontend
หลักฐานภายใน: R2-E06
หลักการ: Carbon · Data table · Carbon · Color
Prompt พร้อมใช้ R2-17 · แก้ข้อความก่อนใช้ได้ R2-18 เลือก component ให้เหมาะกับข้อมูลรถที่มีหลายรุ่น Inventory · ฟอร์มเพิ่มสต็อก P3 + ตรวจฟอร์มโดยไม่บันทึก
พบอะไร รายการรุ่นย่อยใน native select มีประมาณ 30 ตัวเลือก หลายรายการซ้ำชื่อแบรนด์/รุ่น; สถานะ in_production แสดงเป็นรหัสภายในในตาราง และข้อความ VIN ใช้ “17 หลัก”
ควรปรับอย่างไร ใช้ searchable ComboBox เมื่อรายการยาว แสดงแบรนด์/รุ่น/รุ่นย่อยแบบไม่ซ้ำ; branch ใช้ select สั้นได้ ใส่ required/optional ชัดเจน และเปลี่ยน VIN เป็น “เลขตัวถัง 17 ตัวอักษร”
เกณฑ์รับงาน เลือกด้วยการพิมพ์ค้นและ keyboard ได้; label เชื่อม field; รหัสสถานะมีคำแปลและ fallback; ทดสอบฟอร์มแคบโดยไม่ซ่อนปุ่มยกเลิก
ผู้รับผิดชอบที่เสนอ Design + Frontend
หลักฐานภายใน: R2-E09, E10
หลักการ: Carbon · Data table
Prompt พร้อมใช้ R2-18 · แก้ข้อความก่อนใช้ได้ การใช้คำ บอกความหมายและสถานะให้ตรงข้อมูล · 3 ข้อ
R2-16 บอกช่วงเวลาและนิยามตัวเลขให้ครบ Dashboard · Reports P2 + ยืนยันจาก UI
พบอะไร หัวข้อ Dashboard ใช้ “วันนี้” แต่มีเดือนนี้และ YTD ปนกัน; Pipeline เรียง 1,8,4,6,7,5,2,3; Reports ใช้ “ยอดจัด/มูลค่า” ซึ่งรวมสองความหมายไว้ในหัวข้อเดียว
ควรปรับอย่างไร เรียกหน้าว่า “ภาพรวมการขาย” แสดงช่วงเวลาแต่ละ metric และ data as-of; เรียงขั้นธุรกิจ 1–8 แยกสถานะปลายทาง; แยกยอดขาย/ยอดจัดไฟแนนซ์และแสดงนิยามใน tooltip หรือรายละเอียด
เกณฑ์รับงาน ผู้อ่านระบุช่วงเวลา ฐานนับ และหน่วยได้โดยไม่เดา; Dashboard/Reports ใช้ stage ordering และนิยามชุดเดียวกัน
ผู้รับผิดชอบที่เสนอ Product + Data + Content design
หลักฐานภายใน: R2-E01, E07
หลักการ: Carbon · Data table
Prompt พร้อมใช้ R2-16 · แก้ข้อความก่อนใช้ได้ R2-19 ใช้คำที่ตรวจสอบได้แทนคำรับรองเชิงโฆษณา ค่าตอบแทน · หน้าว่าง P2 + ยืนยันจาก UI; นโยบายการจ่ายยังไม่ได้รับรอง
พบอะไร มีคำว่า “โปร่งใส ไม่ต้องทวง”, “โอนภายใน 2 วันทำการ” และ “กำไรสุทธิเสร็จสิ้นแล้ว”; ตารางที่ไม่มีรายการยังไม่มีข้อความอธิบายสถานะว่างในหน้าที่ตรวจ
ควรปรับอย่างไร แสดงสถานะจริงและกำหนดโอนของแต่ละรายการ ถ้าเป็น SLA ให้ระบุเงื่อนไขและวันเริ่มนับ; หน้าว่างใช้ “ยังไม่มีรายการค่าตอบแทนในช่วงนี้” พร้อมช่วงเวลาที่เลือก
เกณฑ์รับงาน ผู้ใช้แยกยอดประมาณการ/อนุมัติ/จ่ายแล้วได้; ไม่แสดงคำรับรองที่ไม่มี business rule รองรับ; กรณีไม่มีข้อมูลไม่คล้ายโหลดค้าง
ผู้รับผิดชอบที่เสนอ Finance owner + Content design
หลักฐานภายใน: R2-E08
หลักการ: W3C · Status messages
Prompt พร้อมใช้ R2-19 · แก้ข้อความก่อนใช้ได้ R2-20 ใช้คำไทยชุดเดียวและแยกรหัสออกจากข้อความผู้ใช้ ทุกหน้า · ภาษาและคำศัพท์ P3 + ยืนยันจาก UI
พบอะไร พบ walk_in, referral, delivery, in_production, N/A, Active และคำ Sale/เซลล์/ผู้ขาย รวมถึงข้อความ login error ภาษาอังกฤษใน UI ภาษาไทย
ควรปรับอย่างไร สร้าง glossary และตัวแปลง enum กลาง แยกไม่ทราบ/ยังไม่ระบุ/ไม่เกี่ยวข้อง/0 ให้ชัด ใช้ชื่อ action ภาษาไทยที่บอกผล เช่น “ดูรายละเอียดงานขาย” และ “กำลังโหลดรายการงานขาย…”
เกณฑ์รับงาน สำรวจข้อความทุกหน้าแล้วไม่หลุดรหัสภายใน; คำเดียวกันหมายถึงสิ่งเดียวกัน; error บอกสิ่งที่เกิดและทางแก้โดยไม่เปิดเผยข้อมูลบัญชี
ผู้รับผิดชอบที่เสนอ Content design + Frontend + QA
หลักฐานภายใน: R2-E01, E05, E09, E11, E13
Prompt พร้อมใช้ R2-20 · แก้ข้อความก่อนใช้ได้ เทคนิคสำหรับ data platform เลือกจากปัญหาที่วัดได้ และใช้ความสามารถของ stack ปัจจุบันก่อนเพิ่มระบบใหม่
แสดงข้อมูลหลักจาก server ก่อนDashboard และการเปิดรายการครั้งแรก ส่ง summary/หน้าแรกพร้อม route แล้วค่อยเติม panel รองด้วย streaming หรือโหลดแยกส่วน ลดการรอ client mount ก่อนเริ่มเรียกข้อมูล เลือกใช้ตาม runtime ที่ deploy จริง
ยังต้องตรวจสิทธิ์ทุก request; ไม่ย้ายข้อมูลส่วนบุคคลไป shared cache
วัดผล: วัด click → data-ready และ waterfall ก่อน/หลัง
Next.js · Navigation & prefetch
cache ตามข้อมูลและสิทธิ์รายการงานขายและ master data ตัวอย่าง query key: [sales, organization, permissionVersion, branch, status, dateRange, page] ทดลอง stale window สั้น 30–60 วินาทีสำหรับ read list; master data ที่เปลี่ยนไม่บ่อยอาจนานกว่า
ช่วงเวลาเป็นค่าทดลอง; ราคา สต็อก สิทธิ์ และเงินต้องตรวจล่าสุดก่อนยืนยัน การออกจากระบบต้องล้าง cache ของผู้ใช้
วัดผล: จำนวน request ซ้ำ, cache-hit และอายุข้อมูลสูงสุด
TanStack Query · Cache defaults
prefetch เมื่อเห็นเจตนาจะเปิดลิงก์รายละเอียดและหน้าถัดไป อุ่น route/data เมื่อ hover, keyboard focus หรือใกล้เลื่อนถึงหน้าถัดไป จำกัดจำนวนและอายุ ใช้ prefetch ของ framework ที่มีอยู่ก่อนเพิ่มระบบใหม่
ไม่ prefetch ทุกดีลหรือเอกสารลูกค้า และไม่ trigger mutation; เคารพการประหยัดข้อมูล/เครือข่ายช้าเมื่อรองรับ
วัดผล: detail data-ready เทียบ bandwidth ที่เพิ่ม
Next.js · Navigation & prefetch
invalidate เฉพาะข้อมูลที่ได้รับผลหลังแก้ดีล จองรถ หรือเปลี่ยนสถานะ ใช้ผลบันทึกอัปเดต detail แล้ว invalidate list/summary ที่เกี่ยวข้อง Deduplicate request ที่พร้อมกันด้วย query key เดียว และยกเลิกคำค้นเก่าที่ไม่ต้องใช้
ไม่แสดงสำเร็จก่อน server ยืนยันเรื่องเงิน/สิทธิ์/VIN; ถ้า optimistic UI ใช้กับงานเสี่ยงต่ำต้องมี rollback
วัดผล: request ต่อหนึ่ง action และจำนวนข้อมูลเก่าหลังบันทึก
TanStack Query · Cache defaults
summary query แยกจากรายละเอียดKPI, Funnel และตารางหลายพันงาน คืนเฉพาะ count/sum ที่ dashboard ต้องใช้; list ส่งเฉพาะคอลัมน์ที่แสดงพร้อม cursor/page โหลดรายละเอียดเมื่อเปิดจริง ตรวจ query plan และ index จากเงื่อนไขจริงก่อนเพิ่ม
ยังไม่พบหลักฐานว่า backend ปัจจุบัน query ช้า; ต้อง profile ก่อน ไม่เพิ่ม index หรือ materialized view โดยเดา
วัดผล: query latency p95, response bytes, จำนวนแถวที่อ่าน
อัปเดตเฉพาะสิ่งที่เปลี่ยนคิวส่งมอบและสถานะงานร่วมกันหลายคน เริ่ม polling เฉพาะตอน tab visible; ถ้าความสดจำเป็นค่อยพิจารณา SSE พร้อม event/version เพื่อ invalidate cache แทนโหลดทั้งหน้า
เป็นทางเลือกต่อยอดหลังวัดความต้องการ ไม่ใช่ข้อกำหนดว่าต้องใช้ WebSocket; event ต้องผูกสิทธิ์และ reconnect ได้
วัดผล: ความสดของสถานะ, request/นาที และ reconnect failures
คำที่แนะนำ ตัวอย่างสำหรับ glossary กลางของทีม
คำเดิม คำหรือแนวทางที่เสนอ walk_in เข้าชมหน้าร้าน referral ลูกค้าแนะนำ delivery ขั้นตอนส่งมอบรถ in_production อยู่ระหว่างผลิต กำไร (สด) ค่าคอมมิชชัน (หากใช้ commission_amount) หรือแก้ให้แสดงกำไรตามนิยามที่รับรอง ยอดจัด/มูลค่า แยก “ยอดจัดไฟแนนซ์” และ “มูลค่างานขาย” ยังไม่มีข้อมูล / — / 0 ปะปนกัน 0 บาท · ยังไม่คำนวณ · ยังไม่ระบุ · ไม่เกี่ยวข้อง ตามแต่ละกรณี กำลังโหลดข้อมูล... กำลังโหลดรายการงานขาย… / กำลังอัปเดตยอดขาย… เปิด → ดูรายละเอียดงานขาย VIN 17 หลัก เลขตัวถัง 17 ตัวอักษร ไม่มีรายการที่ตรงกับเงื่อนไข ไม่พบงานขายตามตัวกรองนี้ · ล้างตัวกรอง Invalid email or password อีเมลหรือรหัสผ่านไม่ถูกต้อง กรุณาตรวจสอบแล้วลองอีกครั้ง
ผลวัดและขอบเขต ตัวอย่าง local บนเครื่องเดียว · ไม่ใช่ผลทดสอบโหลดหรือ p75 ของผู้ใช้จริง
Chrome DevTools · cache ปกติ · ไม่มี network/CPU throttling · Energy Saver เปิดอยู่ สถานการณ์ ค่าที่อ่านได้ ความหมายและข้อจำกัด Sales · warm reload 32 requests มี cache อยู่ก่อนแล้ว; resource size เป็นขนาดคลายบีบอัดรวม ไม่ใช่ bytes ดาวน์โหลดครั้งนี้; Load ไม่ใช่เวลาข้อมูลพร้อมใช้งาน Dashboard → Sales กลับหน้าที่เคยเปิด 30 requests รายการ Network รอบนี้มี static asset revalidation จำนวนมาก พร้อม loading ใหม่; ไม่สรุปว่าทุก request เป็น API หรือดาวน์โหลดไฟล์เต็มซ้ำ Dashboard · local reload LCP 0.26s หนึ่งตัวอย่างจาก Live Metrics; CLS ถูกปัดทศนิยมตาม UI; ยังไม่ครอบคลุม slow network, cold load หรือผู้ใช้จริง Sales · mobile viewport 390px วัดหลังปิดเมนู; พบ overflow ทั้งหน้า
เกณฑ์ Core Web Vitals ที่ใช้วางแผน: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 ที่ percentile 75 ของผู้ใช้จริง แยก mobile/desktop ผล local ข้างบนยังใช้ตัดสินผ่านเกณฑ์นี้ไม่ได้ — web.dev · Core Web Vitals
วิธีตรวจ ขอบเขต และหลักฐาน เวลา: 08:00–08:25 น. (Asia/Bangkok) · ตรวจซ้ำฝั่ง Admin: Dashboard, งานขาย, รายละเอียดงานขาย, ส่งมอบ, Reports, ค่าตอบแทน, สต็อก, ฟอร์มเพิ่มสต็อก และ Settings รวมถึงหน้า Login
รอบนี้เน้นการอ่านข้อมูลและปฏิสัมพันธ์ที่ย้อนกลับได้ ไม่มีการบันทึกธุรกรรม ตรวจเฉพาะ DOM, ไฟล์ frontend ที่เผยแพร่ และ Chrome DevTools ไม่ได้ตรวจ backend/database หรือทดสอบโหลดพร้อมกันหลายคน บัญชี Sales Demo เข้าระบบไม่สำเร็จ จึงยังไม่รับรองหน้าทำงาน Sales/Delivery และห้องลูกค้าในรอบนี้ ผล UAT 65 เคสเดิมคงเป็นผลรอบแรก
หลักฐาน: ภาพหน้าจอและ accessibility snapshots อยู่ในชุดภายใน R2-E01–E14; Network R2-N01/N02; Local metrics R2-P01; เก็บ hash ของ frontend ที่อ่านเพื่ออ้างอิง build รายงานสาธารณะนี้แสดงเฉพาะข้อมูลที่จำเป็น ไม่มีชื่อบุคคล เลขดีลจริง ภาพเต็ม ข้อมูลบัญชี หรือ response payload
ยังต้องทำต่อ: ทดสอบ Sales/Delivery และห้องลูกค้าจาก session ที่เข้าได้, cold/slow-network benchmark, keyboard end-to-end, screen reader, API failure simulation, ข้อมูล 1k/10k และการใช้งานพร้อมกัน
ข้อควรระวังในการอ่านผล: ไฟล์ static เก่าบางชื่อที่หน้าเคยอ้างอิงตอบ 404 ระหว่างตรวจ แต่ยังแยกไม่ได้ว่าเป็นการเปลี่ยน build หรือปัญหา asset retention จึงไม่เพิ่มเป็นข้อบกพร่องที่ยืนยัน ควร retest การเปิด tab ค้างข้าม deployment
Prompt รวมพร้อมใช้ รวม R2-01–20, เทคนิคที่ต้องประเมิน และรายการ D01–D14 เดิม พร้อมเงื่อนไขการทดสอบ
ความถูกต้อง: ยอดรวม ฟิลด์ตัวเลข AI สถานะ และสาขา การทำงาน: keyboard, mobile, loading/error และ component ประสิทธิภาพ: วัด baseline → ลด revalidation/โหลดซ้ำ → วัดซ้ำด้วยเงื่อนไขเดิม เปิด prompt สำหรับตรวจและแก้รวม R2-MASTER · แก้ข้อความก่อนใช้ได้