วิธีทำการทดสอบเบต้าสำหรับแอปของคุณ

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

เบต้าไม่ใช่ soft launch แต่เป็นการทดลองที่มีโครงสร้าง มีจุดเริ่ม จุดจบ และคำถามที่ต้องตอบ

เบต้าอยู่ตรงไหนในกระบวนการ

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

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

ขั้นตอนที่ 1: เขียนสิ่งที่เบต้าต้องตอบ

เลือกคำถามสองถึงสามข้อ ทุกอย่างในแผนจะตามมาจากคำถามเหล่านี้

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

ขั้นตอนที่ 2: เลือกประเภทของเบต้า

สำหรับผลิตภัณฑ์แรก เบต้าปิดที่มีหลายรอบมักเป็นทางเลือกที่ถูกต้อง

ขั้นตอนที่ 3: คัดเลือกผู้ทดสอบที่เหมาะสม

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

• รายชื่อรอ (waitlist) หรืออีเมลลิสต์ของคุณ ดูวิธีสร้างกลุ่มผู้ติดตามก่อนเปิดตัว
• คนที่คุณสัมภาษณ์ระหว่างการตรวจสอบ
• ชุมชนเฉพาะกลุ่มที่ผู้ใช้ของคุณรวมตัวกัน โดยทำตามกฎของชุมชนเรื่องการโปรโมต
• การเชิญโดยตรงไปยังคนในเครือข่ายของคุณที่ตรงกับโปรไฟล์

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

ตัวอย่างข้อความเชิญ

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

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

ขั้นตอนที่ 4: เตรียมชุดสำหรับเบต้า

ก่อนส่งคำเชิญแรก ให้เตรียมสิ่งเหล่านี้:

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

ขั้นตอนที่ 5: ทำเป็นรอบ

การทำเป็นรอบช่วยให้คุณแก้ปัญหาก่อนที่คนจำนวนมากขึ้นจะเจอ

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

ขั้นตอนที่ 6: เก็บความคิดเห็นตามจังหวะ

ข้อความ “มีความคิดเห็นอะไรไหม” แบบไม่มีโครงสร้างได้คำตอบที่คลุมเครือ ใช้การเช็กอินสั้น ๆ ที่สม่ำเสมอแทน:

การเช็กอินรายสัปดาห์ (คำถามตัวอย่างสมมติ)

1. สัปดาห์นี้คุณใช้ [ผลิตภัณฑ์] ทำอะไร
2. อะไรที่น่าหงุดหงิดหรือสับสน
3. มีอะไรขาดไปจนทำให้คุณทำงานให้เสร็จไม่ได้ไหม
4. หากคุณใช้ไม่ได้อีกต่อไป คุณจะรู้สึกอย่างไร (ผิดหวังมาก / ค่อนข้าง / ไม่เลย)
5. มีอะไรอีกไหม

เทียบสิ่งที่คนพูดกับสิ่งที่พวกเขาทำ คนที่บอกว่าดีมากแต่ไม่เคยล็อกอินก็กำลังบอกคุณบางอย่างเช่นกัน

ขั้นตอนที่ 7: คัดแยกสิ่งที่เข้ามา

รวมความคิดเห็นทั้งหมดไว้ในรายการเดียวและจัดลำดับทุกสัปดาห์

อย่าเพิ่มฟีเจอร์ใหญ่ระหว่างเบต้า แต่ละฟีเจอร์ใหม่ทำให้ยากขึ้นที่จะบอกได้ว่าผลิตภัณฑ์หลักทำงานได้หรือไม่

ขั้นตอนที่ 8: ปิดวงจร

ผู้ทดสอบจะให้ความคิดเห็นต่อไปเมื่อเห็นว่ามันถูกนำไปใช้

• ส่ง changelog สั้น ๆ หลังแต่ละรอบ: “คุณรายงาน X แล้ว และแก้ไขแล้ว”
• ขอบคุณผู้ทดสอบเป็นรายบุคคลแบบส่วนตัวเมื่อรายงานของพวกเขานำไปสู่การแก้ไข
• แจ้งผู้ทดสอบเมื่อเบต้าจบ ข้อมูลและบัญชีของพวกเขาจะเป็นอย่างไร และข้อเสนอก่อตั้งของพวกเขาคืออะไร

ขั้นตอนที่ 9: ตัดสินใจว่าพร้อมหรือยัง

เขียนเกณฑ์การจบไว้ก่อนเบต้าเริ่ม แล้วตรวจสอบอย่างซื่อสัตย์เมื่อจบ ตัวอย่างเทมเพลต:

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

หากส่วนใหญ่ถูกทำเครื่องหมายแล้ว ให้ไปขัดเกลาการ onboarding และเปิดตัวต่อสาธารณะ หากการใช้งานซ้ำน้อย นั่นเป็นคำถามเรื่องผลิตภัณฑ์ ไม่ใช่รายการบั๊ก ให้กลับไปสัมภาษณ์ก่อนเปิดตัว

การทำเบต้ากับ Mythex

หากคุณสร้างด้วย Mythex มีฟีเจอร์บางอย่างที่เข้ากับเบต้าได้พอดี:

• ลิงก์พรีวิวสำหรับรอบ 1 ปุ่ม Share สร้างลิงก์ไปยังพรีวิวสดของคุณที่ใช้ได้โดยไม่ต้องมีบัญชี Mythex ทำให้ผู้ทดสอบต้นทางลองงานที่ยังไม่เสร็จก่อนที่คุณจะเผยแพร่ได้ สร้างหนึ่งลิงก์ต่อกลุ่มและลบเมื่อเสร็จ เอกสารพรีวิว อธิบายว่าลิงก์ปลุกโปรเจกต์และใช้เครดิตอย่างไร
• เผยแพร่สำหรับรอบที่ยาวกว่า แอปที่เผยแพร่แล้วทำงานที่ที่อยู่ของตัวเอง เหมาะกับผู้ทดสอบที่ใช้งานหลายสัปดาห์
• การทดสอบแอป (App Testing) ก่อนแต่ละรอบ พิมพ์ /test ในแชท แล้วเอเจนต์จะคลิกผ่านพรีวิวของคุณและรายงานขั้นตอนที่พัง เป็นการตรวจที่มีประโยชน์ก่อนเชิญใคร (เอกสารการทดสอบแอป)
• เช็คพอยต์ หากการแก้ไขทำให้บางอย่างพังระหว่างเบต้า ให้ย้อนกลับไปยังเช็คพอยต์ก่อนหน้า

วางรายงานบั๊กของผู้ทดสอบลงในแชทโดยตรง แล้วขอให้เอเจนต์ทำซ้ำและแก้ไข จากนั้นแจ้งผู้ทดสอบเมื่อแก้ไขแล้ว

คำถาม