วิธีทดสอบแอปก่อนเปิดตัว: แผนทดสอบก่อนเปิดตัวแบบปฏิบัติ

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

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

ขั้นตอนที่ 1: จดเส้นทางที่สำคัญ

เส้นทาง (journey) คืองานตั้งแต่ต้นจนจบที่ผู้ใช้เข้ามาทำ แอปส่วนใหญ่มีสามถึงหกเส้นทางที่สำคัญจริงๆ เช่น แอปจองคลาส:

1. สมัครสมาชิกและยืนยันบัญชี
2. ค้นหาคลาสและจอง
3. ยกเลิกการจอง
4. ชำระเงินซื้อบัตรเข้าเรียน
5. เจ้าหน้าที่: ดูการจองของวันนี้

หากคุณเขียนเรื่องราวของผู้ใช้ (user stories) เกณฑ์การยอมรับของมันคือกรณีทดสอบของคุณอยู่แล้ว หากยังไม่มี ให้เขียนหนึ่งบรรทัดต่อเส้นทางว่า “สำเร็จ” หน้าตาเป็นอย่างไร

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

ขั้นตอนที่ 2: ทดสอบเส้นทางปกติในฐานะผู้ใช้ใหม่

“เส้นทางปกติ” (happy path) คือเส้นทางที่ทำงานตามที่ตั้งใจไว้ ทดสอบโดยทำตัวเหมือนคนแปลกหน้าที่เข้ามาใช้:

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

ผู้ใช้ใหม่ไม่มีข้อมูลใดๆ บั๊กหลายตัวจะปรากฏเมื่อรายการว่างเปล่า โปรไฟล์ไม่มีรูป หรือยังไม่มีการซื้อใดๆ บัญชีของคุณเองที่เต็มไปด้วยข้อมูลทดสอบจะซ่อนบั๊กเหล่านี้ไว้

ขั้นตอนที่ 3: พยายามทำให้มันพัง

ตอนนี้ทำซ้ำแต่ละเส้นทาง และทำสิ่งที่ผิดโดยตั้งใจ

การรีเฟรชควรให้ความสำคัญเป็นพิเศษ: หากแอปทำงานเมื่อคุณคลิกผ่าน แต่การรีเฟรชหน้าลึกแสดง 404 ให้ดูวิธีแก้ข้อผิดพลาด 404 หลังเผยแพร่

ขั้นตอนที่ 4: ทดสอบสิทธิ์การเข้าถึงด้วยสองบัญชี

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

สร้างผู้ใช้ปกติสองคน A และ B และแอดมินหนึ่งคน (หากแอปของคุณมี)

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

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

ขั้นตอนที่ 5: ทดสอบบนอุปกรณ์จริง

เปิดแอปบนโทรศัพท์จริง ไม่ใช่แค่หน้าต่างเบราว์เซอร์แคบๆ

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

ลองใช้อย่างน้อย iPhone หนึ่งเครื่อง (Safari) และโทรศัพท์ Android หนึ่งเครื่อง (Chrome) หากยืมได้ โดยเฉพาะ Safari มีปัญหาเฉพาะตัวเรื่องวันที่ วิดีโอ และองค์ประกอบที่ตรึงตำแหน่ง (fixed-position)

ขั้นตอนที่ 6: ทดสอบเงินและอีเมลตั้งแต่ต้นจนจบ

สิ่งใดก็ตามที่เรียกเก็บเงินจากบัตรหรือส่งอีเมลต้องผ่านการทดสอบเต็มรูปแบบ

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

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

ขั้นตอนที่ 7: ตรวจความเร็วและข้อผิดพลาด

• เปิดเครื่องมือนักพัฒนาของเบราว์เซอร์ (คลิกขวา → Inspect) และดูแท็บ Console ในแต่ละหน้าหลัก ข้อความสีแดงควรแก้ไข แม้ดูเหมือนไม่มีอะไรพัง
• โหลดเว็บบนโทรศัพท์โดยใช้มือถือ (ไม่ใช่ Wi-Fi) หากหน้าแรกใช้เวลาหลายวินาที ให้ดูขนาดรูปภาพก่อน
• รันการตรวจสอบฟรีอย่าง Lighthouse ในเครื่องมือนักพัฒนาของ Chrome เพื่อดูประสิทธิภาพและการเข้าถึงอย่างรวดเร็ว

ขั้นตอนที่ 8: ทดสอบแอปที่เผยแพร่แล้ว ไม่ใช่แค่พรีวิว

พรีวิวกับแอปที่เผยแพร่แล้วไม่ใช่สภาพแวดล้อมเดียวกัน ก่อนบอกใครเกี่ยวกับการเปิดตัว ให้ทำเส้นทางหลักซ้ำบน URL จริง:

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

ขั้นตอนที่ 9: ดูคนอื่นใช้งาน

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

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

ใช้ AI ช่วยทดสอบ

หากคุณสร้างด้วย AI คุณขอให้มันช่วยวางแผนและรันการทดสอบได้:

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

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

ให้ถือว่ารายงานการทดสอบของ AI เป็นการผ่านรอบแรก และยังต้องคลิกผ่านเส้นทางเรื่องเงินและสิทธิ์การเข้าถึงด้วยตัวเอง

การทดสอบใน Mythex

ใน Mythex คำสั่ง /test จะรัน App Testing: เอเจนต์ควบคุมเบราว์เซอร์กับพรีวิวสดของคุณ คลิกผ่านหน้าต่างๆ ถ่ายภาพหน้าจอ และรายงานเส้นทางที่พังในแชต ได้ผลดีที่สุดเมื่อระบุเส้นทางที่เจาะจง เช่น “ทดสอบการสมัครและการจองคลาส” แก้สิ่งที่พบด้วย /fix หรือข้อความปกติ แล้วรัน /test อีกครั้ง App Testing ใช้พรีวิว ดังนั้นหลังเผยแพร่ ให้ตรวจเส้นทางหลักบน URL ที่เผยแพร่แล้วด้วยตัวเอง ดู App Testing ในเอกสาร และวิธีดีบักแอปที่สร้างด้วย AI เมื่อมีอะไรล้มเหลว

ความผิดพลาดที่พบบ่อย

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

เช็กลิสต์ก่อนเปิดตัว

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

คำถาม