รีวิวสล็อตสาย tech writer ทดสอบ 60 ชื่อ draft A เทียบ draft B
ผมชื่อ ธนวันต์ ชูสังข์ ใช้ชีวิต tech writer มา 6 ปี เขียน spec และ changelog เป็นงานประจำ ก่อนลงมือร่างรีวิวในนามส่วนตัว ตอนนี้ผมทำบน lapdee77 โดยหมุน 60 ชื่อค่าย pg เกมละ 400 สปินแบ่งเป็นสอง draft รวม 24000 สปิน เพื่อตรวจว่า draft A กับ draft B ของเกมเดียวกันจัดชิดกับ spec ภายในของผมหรือไม่ และมีจุดใดที่ผู้อ่านควรรู้ก่อนตัดสินใจเปิด account จริง
ผมร่าง test plan ตามแบบที่เคยใช้ตอนทำ documentation ของทีมเก่า คือเขียน test matrix ไว้ก่อน ระบุ 60 ชื่อ จับคู่สอง draft ให้ยอดสปินเท่ากันทุกฝั่ง เป้าหมายผมไม่ใช่ยอด payout แต่คือพฤติกรรมเกมในสอง draft ว่า animation ตัวนับเครดิต และปุ่มสั่งงานตอบสนองตรง spec ของตอนที่สังกัดหรือเปล่า หากไม่ตรง ผมบันทึก footnote ว่าต่างตรงไหน ซ้ำได้กี่ครั้งใน 200 สปินของ draft นั้น
จาก log รวมของ 10 ตอน ตารางของ figure 3 ให้ค่าเฉลี่ย 1 trigger ต่อ 182 สปิน เมื่อนับรวมสองดราฟต์ ส่วนช่วงไม่มี trigger ที่ยาวสุดคือ 388 สปินติด เกิดใน draft A ของเกมค่าย pg กลุ่มไฮวาไรแอนซ์ ผมอ้างใน section 4.2 ว่าค่านี้คือค่าปกติของเกมกลุ่มดังกล่าว ไม่ใช่หลักฐานว่าดราฟต์ฝั่งใดเพี้ยน แต่คือ reminder สำหรับคนตั้งงบน้อยว่าจะมีสปินหลักร้อยที่ไม่มีอะไรเกิดเลย
เรื่องที่ tech writer ในตัวผมสนใจเป็นพิเศษคือ state ของเกมตอนสลับหน้าต่าง เมื่อผมปิดแท็บแล้วกดเปิดใหม่ มี 11 ชื่อใน draft A ที่ตัวเลขเครดิตฝั่งหน้าจอหลุดจากค่าฝั่ง server ไปชั่วขณะ ก่อน sync กลับมาถูกใน 1 ถึง 2 วิ ไม่กระทบเงินจริงแต่กระทบความมั่นใจของมือใหม่ ในบทบาท tech writer ผมเขียน defect ticket priority กลางให้ทีม dev แก้ เพราะทำให้ user ตกใจและกดปุ่มซ้ำ
รายการที่ผมตรวจเองและมี log ย้อนกลับได้
- ยอดสปินสะสมคือ 24000 สปิน แยกเป็น draft A 12000 สปินและ draft B อีก 12000 สปิน ทุกสปินผมพิมพ์เลขลง spreadsheet พร้อม timestamp และตัวย่อของ draft ที่กดอยู่ รอบปิดงานของแต่ละวัน ผมนับย้อนซ้ำสองรอบก่อนบันทึก revision log
- ค่าเฉลี่ย 1 trigger ต่อ 182 สปิน มาจากการนับรอบ trigger ที่ขึ้นบนจอตอนกด ไม่ได้อ้างจาก help page และไม่ได้อ้างจากข้อมูลที่ operator ปล่อยส่วนตัว
- ช่วงไม่มี trigger ที่ยาวสุดคือ 388 สปินใน draft A ของเกม Dragon Hatch 2 ผมจดเลขทุก 25 สปิน จึงล็อก timestamp เริ่มกับ timestamp จบของช่วงแห้งนั้นได้แน่นอน ไม่มีการประมาณ
- ปุ่ม buy feature พบใน 41 ชื่อสำหรับ draft A และ 44 ชื่อสำหรับ draft B ผมเทียบรายเกมพร้อมภาพหน้าจอก่อนและหลังกดปุ่มเพื่อแนบใน appendix A
- มี 11 ชื่อใน draft A ที่ตัวเลขเครดิตฝั่งหน้าจอเพี้ยนเวลาสลับแท็บแล้วกลับมา ก่อน sync ค่าให้ถูกใน 1 ถึง 2 วิ ผมกดซ้ำสามครั้งต่อเกมเพื่อยืนยันการเกิดซ้ำ
- load time เฉลี่ยของเกมบนเครื่องของผมคือ 2.3 วิสำหรับ draft B และ 2.9 วิสำหรับ draft A ผมจับเวลาด้วยนาฬิกาเครื่องนอก ไม่ใช้ timer ของเพจเองเพราะมันคือ component ที่กำลังทดสอบอยู่
ประเด็นที่ข้อมูลของผมยังยืนยันไม่ได้ (limitation)
- ตัวตนทางกฎหมายของผู้ให้บริการ ผมค้นเลขทะเบียนและที่ตั้งสำนักงานที่ย้อนกลับไปที่หน่วยงานทะเบียนบริษัทไม่ได้จากหน้าสาธารณะในช่วงที่ทำการทดสอบ จึงไม่สามารถระบุใครรับผิดเวลาเกิดกรณีพิพาท ส่วนนี้ผมใส่เป็น limitation ของ appendix B
- แนวทาง payout ก้อนใหญ่ระดับเจ็ดหลักขึ้นไป ยอดชนะที่ผมพบในกรอบ 24000 สปินถอนได้ตามรอบปกติ ยังไม่มี case ที่ยอดใหญ่พอกระตุ้นขั้นตอนตรวจเพิ่ม ผมจึงไม่มีข้อมูลขั้นตอนและเวลาจ่ายสำหรับยอดระดับนั้นมาเล่าให้ผู้อ่าน
- สถานะใบอนุญาตที่โชว์บนเพจ ผมเห็น logo และเลขอ้าง แต่ไม่สามารถโทรเช็กกับหน่วยกำกับที่ถูกอ้างได้ในช่วงทดสอบ จึงบอกไม่ได้ว่าใบอนุญาตนั้นยังมีผลหรือหมดอายุไปแล้ว ส่วนนี้คือจุดสีเทาที่ผมต้องเขียน footnote ติดไว้
- อัลกอริทึมฝั่ง server ของ RNG ผมมองได้จากฝั่ง client เท่านั้น ไม่สามารถเปิด black box ดู seed ที่ใช้งานจริง จึงพูดได้แค่พฤติกรรมปลายทาง ไม่ใช่ logic ภายในที่ควบคุมเลขสุ่ม
- ความทนทานของระบบในสถานการณ์ user หนาแน่น ผมใช้ account เดี่ยวในช่วงเวลาปกติ ไม่สามารถจำลอง session พร้อมกันระดับหลายหมื่น เพื่อยืนยัน SLA ของระบบในสภาพแวดล้อม production จริง
ตารางสปินและ trigger จากการกดเอง
ตารางด้านล่างแยกค่าของแต่ละ draft ให้เทียบเกมต่อเกม พร้อมช่วงไม่มี trigger ที่ยาวสุดของแต่ละเกม ทุกตัวเลข cross-reference ตรงมาจาก spreadsheet ที่ผมเปิดคู่หน้าจอขณะกดสปิน ไม่ได้ถามจาก operator และไม่ได้หยิบจากแหล่งสาธารณะอื่น
| เกม | ยอดฝากสะสม (บาท) | ยอดถอนคืนสะสม (บาท) | ช่วงขาดทุนต่อเนื่องที่ยาวที่สุด | หมายเหตุท้ายตาราง |
|---|---|---|---|---|
| Legendary Monkey King | 2 | 1 | 268 ช่วงติด | ตอน 2 ของ report บันทึก trigger ของ draft แรกไว้ที่สปิน 83 กับ 191 ตรงกับ figure 3.1 |
| Treasures of Aztec | 1 | 2 | 302 ช่วงติด | ตัวนับใน sidebar ของ demo client ขยับช้าหนึ่งเฟรม ผม flag เป็น styleguide note |
| Fortune Mouse | 3 | 2 | 157 ช่วงติด | เป็นเกมที่ cross-reference ไปที่ appendix A บ่อยสุด เพราะ trigger ซ้อนจังหวะที่ 44 และ 61 |
| Dragon Hatch 2 | 1 | 1 | 388 ช่วงติด | section 2.4 ของ report ตั้ง flag ว่าช่วงแห้ง 388 สปินเป็นค่าสูงสุดใน sample |
| Fortune Ox | 2 | 3 | 192 ช่วงติด | ผมเขียน footnote ที่หน้า 11 ว่า draft B ยิง bonus เลย draft A สองรอบ |
| Wild Bandito | 1 | 2 | 274 ช่วงติด | numbered list ใน methodology ของเกมนี้ยาว 7 ข้อเพราะโครงเสียง animation ยาว |
| Prosperity Lion | 2 | 1 | 219 ช่วงติด | revision log บันทึกว่า sprite ของ sidebar แตะขอบ viewport ที่ 1280 px |
| Caishen Wins | 2 | 2 | 243 ช่วงติด | ค่าเฉลี่ยสองดราฟต์ชนกันพอดีในเกมนี้ จึงใช้เป็น control case ใน abstract |
| รายการที่นำมาเปรียบเทียบ | ค่าที่ระบุในรายงาน | ค่าที่แสดงในแอปธนาคาร |
|---|---|---|
| ความชัดของสารบัญ demo client | สารบัญรุ่นแรกใช้ font น้ำหนัก 400 | ปรับเป็น weight 600 ตาม styleguide ภายใน |
| จำนวน cross-reference ต่อ 10 เกม | เขียนไว้เฉลี่ย 3.2 จุด | เขียนไว้เฉลี่ย 4.6 จุดหลังรอบตรวจซ้ำ |
| Oxford comma ใน numbered list | ตก 11 รายการจาก 60 | ตกเหลือ 2 รายการหลัง revision log |
| ความยาว footnote เฉลี่ย | ยาวเฉลี่ย 42 คำ | ย่อลงเหลือ 31 คำโดยไม่ตัด cross-reference |
| appendix A มี figure ประกอบกี่ตัว | มี figure อ้างอิง 4 ตัว | เพิ่มเป็น figure อ้างอิง 7 ตัวหลังรอบปรับ |
| ความแน่นของ bibliography | อ้างอิง 9 รายการจากเวอร์ชัน 1 | เพิ่มเป็น 14 รายการใน revision log ชุด 2 |
ประสบการณ์หน้าเว็บและการตอบของทีม support
ด้านหน้าเว็บของ lapdee77 ทำงานลื่นในสองเบราว์เซอร์หลักที่ผมใช้ประจำคือ chrome กับ edge บน desktop รุ่นกลาง รวมถึงมือถือ android ที่อายุประมาณ 3 ปี ปุ่มสำคัญขนาดโตพอสำหรับนิ้วโป้ง เมนูของหมวดเกมถูกจัดกลุ่มชัด คำไทยบนปุ่มใช้สำนวนที่ user ทั่วไปคุ้นเคย ตลอด 24000 สปินผมไม่พบหน้าค้างหรือ script ที่หยุดการตอบของ UI ที่ควรติดคือหน้าประวัติ transaction โหลดช้ากว่าหน้าอื่นเฉลี่ย 1.5 วิ ซึ่งเป็นจุดที่ผมอยากให้ทีม dev ย่อ bundle ลงอีกเพราะ user กดเข้าหน้านี้บ่อยเวลามีคำถามเรื่องยอด
ด้านทีม support ผมส่งคำถามเข้าช่อง chat ทั้งหมด 4 รอบ กระจายคาบเวลาคือรอบเช้า รอบกลางวัน รอบหัวค่ำ และรอบดึกหลังเที่ยงคืน รอบที่ตอบไวสุดใช้เวลา 1 นาที 50 วิ รอบที่ช้าสุดคือรอบดึกใช้เวลา 14 นาทีเต็ม คำตอบเจาะประเด็นไม่พยายามพาผมไป promotion ที่ไม่ได้ถาม ผมให้คะแนน support ไว้ที่ 7.9 ซึ่งต่ำกว่า 8.2 ของคะแนนรวม เพราะรอบดึกเกินเกณฑ์ของบริการที่ควรรับได้ตลอด 24 ชั่วโมง ส่วนเมนู self-help ยังขาดคำถามพื้นฐานบางข้อ เช่น ขั้นตอนเปลี่ยนบัญชีธนาคารประจำ
สรุปคะแนนและ limitation ของตอนนี้
คะแนนรวมของผมอยู่ที่ 8.2 เต็ม 10 ประกอบจากหมวดย่อย 4 ด้าน ความแม่นของตัวเลขอยู่ที่ 8.1 ความครบของ step อยู่ที่ 8.3 ความชัดของเอกสารอยู่สูงสุดที่ 8.4 ส่วนความอ่านง่ายของผลลงมาที่ 8.0 ค่าในหมวดเอกสารสูงเพราะ styleguide ของผมล็อก format ก่อนลงมือ ส่วนตัวที่ต่ำสุดมาจาก feedback ของผู้อ่าน early draft ที่ขอให้เพิ่ม caption รายคอลัมน์ของ figure 3 ผมเขียน changelog entry ไว้ให้แก้ใน revision ถัดไป ถ้าทีม dev ปิด bug ซิงก์เครดิตได้ ผมพร้อมขยับคะแนนในรอบใหม่
limitation ของตอนนี้คือมันคือมุมของ tech writer คนเดียวที่ลงเงินตัวเองและใช้เวลาส่วนตัวตลอดโครงการ ไม่ใช่การตรวจระดับหน่วยกำกับ ไม่ใช่การตรวจแบบทีม และไม่ใช่การตรวจที่มีสิทธิ์เข้า database ภายใน ผู้อ่านควรหยิบตัวเลขเหล่านี้ไปประกอบการตัดสินใจ ไม่ใช่คำยืนยันว่าทุกคนจะได้ผลเท่ากัน สล็อตคือ random game ที่ไม่มีใครรับประกันผลให้ใครได้ ก่อนลงเล่น ควรวางงบและเวลาให้ตัวเองเรียบร้อย
ทำไมเลือก 60 ชื่อและ 400 สปินต่อเกม ไม่มากกว่านี้
ในฐานะ tech writer ผมประเมินว่า sample ระดับนี้พอเห็น trend ที่ซ้ำได้ แต่ยังไม่กินเวลาจนบันทึกตก หากหมุนเกมละ 600 สปินจะได้ความแม่นเพิ่มเล็กน้อย แต่โอกาสจดผิดก็สูงตามความล้า ผมเลือกจุดที่คุมคุณภาพการจดได้ ซึ่งคือ 400 สปินต่อเกมแยกเป็นสอง draft และย้ำว่า sample นี้เล็กเมื่อเทียบกับฐาน user ทั้งระบบ ไม่ใช่ค่าสถิติที่ยืนยันผลให้ทุกคน
bug ซิงก์เครดิต 11 ชื่อที่คุณเจอน่ากังวลแค่ไหน
ในมุม tech writer ผมให้ severity เป็นระดับกลาง เพราะยอดเงินจริงไม่กระทบ และ sync ของเพจรีเฟรชกลับใน 1 ถึง 2 วิ แต่ priority ควรขยับขึ้นสูงเพราะ user หน้าใหม่จะคิดว่าเครดิตหาย อาจกดปุ่มซ้ำซ้อนหรือทัก chat จนทีมบริการล้นงาน ถ้าผู้อ่านเจออาการนี้ ผมแนะนำว่ารอ 2 วิแล้วค่อย refresh ยอดใหม่ก่อน ส่วนใหญ่ค่าที่ถูกต้องจะกลับมาเอง
draft A หรือ draft B ดีกว่ากันในชุดทดสอบของคุณ
ถ้าดูจากตัวเลขที่ผมมี draft B โหลดเร็วกว่า draft A เฉลี่ย 0.6 วิ และ trigger ใน draft B ขึ้นถี่กว่า draft A 2.3 เปอร์เซ็นต์ ค่านี้เล็กและอาจเกิดจากขนาด sample ส่วน bug ซิงก์เครดิตพบใน draft A เท่านั้น ไม่พบในฝั่ง draft B ผมจึงบอกไม่ได้ว่าฝั่งใดดีกว่าแบบเด็ดขาด แต่ผู้เริ่มใหม่ควรลอง draft B ก่อน เพราะจุดสะดุดน้อยกว่าในมือผม
ทำไมความแม่นของตัวเลขได้ 8.1 ไม่เต็ม
เพราะมีจุดสีเทาหลายอย่างที่ผมอยากเช็กแต่เช็กไม่ได้ ได้แก่ ตัวตน legal entity ที่รับผิด แนวทาง payout ก้อนใหญ่ และสถานะใบอนุญาตที่ cross-check กลับไปต้นทาง ส่วนที่ตรวจได้คือพฤติกรรม client กับการตอบของทีม support ผมจึงให้ 8.1 เพราะส่วนที่เห็นก็สะอาด แต่ส่วนที่อยู่หลัง black box ยังมืดเกินจะให้คะแนนเต็ม
คุณได้รับค่าตอบแทนจาก operator เพื่อเขียนรีวิวหรือไม่
ไม่ได้รับ ผมใช้ account ตัวเองและเวลาส่วนตัวตลอดโครงการ ไม่มีข้อตกลงล่วงหน้าเรื่องเนื้อหา ไม่มี benefit ที่แลกเปลี่ยนไปมา หากในอนาคตมีความสัมพันธ์เชิงพาณิชย์ขึ้นจริง ผมจะพิมพ์ disclosure ติดหัวบทความทันทีก่อนขยับเนื้อหา เพื่อให้คนอ่านเลือกเองได้ว่าจะยังเชื่อถือระดับใด
ค่าเฉลี่ย 1 trigger ต่อ 182 สปินใช้ยืนยัน RTP ได้ไหม
ไม่ได้ ค่าเฉลี่ยนี้คือจำนวนรอบ trigger ต่อสปินในกรอบ 24000 สปินของผม ไม่ใช่ค่า RTP ซึ่งคือเงินคืนเฉลี่ยต่อยอด bet และต้องใช้สปินระดับหลายล้านรอบถึงจะเข้าใกล้สภาพจริง ค่าของผมคือ snapshot ของเกมในช่วงที่ทดสอบเท่านั้น ไม่ใช่คำยืนยันผลที่ผู้อ่านจะเจอ