สร้างข้อมูลทดสอบที่สมจริงสำหรับแอปธุรกิจก่อนให้พนักงานใช้งาน

ทำไมเดโมที่ดูสมบูรณ์จึงมีปัญหาเมื่อพนักงานเริ่มใช้งาน

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

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

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

ข้อมูลที่ใช้ร่วมกันทำให้ขั้นตอนเปลี่ยนไป

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

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

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

แยกข้อมูลทดสอบออกจากข้อมูลจริง

ใช้ชื่อ อีเมล เบอร์โทรศัพท์ และรายละเอียดบริษัทที่สร้างขึ้นระหว่างการทดสอบ ติดป้ายข้อมูลให้ชัดเจน เช่น "TEST - Northside Supplies" เพื่อไม่ให้ใครเข้าใจว่าเป็นลูกค้าจริง ห้ามคัดลอกรายชื่อลูกค้า ข้อมูลพนักงาน รายละเอียดทางการเงิน หรือบันทึกส่วนตัวไปไว้ในสภาพแวดล้อมทดสอบ

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

เริ่มจากงานที่พนักงานทำจริง

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

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

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

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

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

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

หากสร้างแอปด้วย Koder.ai ให้เขียนสถานการณ์เหล่านี้เป็นคำขอโดยตรงในแชตระหว่างพัฒนา ทำซ้ำด้วยข้อมูลที่เตรียมไว้ก่อนเชิญพนักงานเข้ามา และวางผลลัพธ์ที่คาดหวังไว้ข้างแต่ละสถานการณ์

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

สร้างข้อมูลที่คล้ายกับข้อมูลธุรกิจในชีวิตประจำวัน

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

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

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

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

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

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

เขียนหมายเหตุให้เรียบง่ายแต่สมจริง "ลูกค้าขอแบ่งการจัดส่งเป็นสองรอบ" มีประโยชน์มากกว่า "หมายเหตุทดสอบ 14" ห้ามใส่ที่อยู่จริง หมายเลขบัญชี เบอร์โทรศัพท์ หรือความคิดเห็นส่วนตัวลงในแอปทดสอบ แม้จะเป็นการทดสอบภายในก็ตาม

จำลองผู้ใช้และสิทธิ์ก่อนเชิญทีมเข้ามา

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

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

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

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

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

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

ในโหมดวางแผนของ Koder.ai ให้อธิบายบทบาทก่อนเชิญพนักงาน สร้างบัญชีทดสอบแยกกัน แล้วทำงานสั้นๆ เดิมซ้ำภายใต้แต่ละบัญชี ปัญหาสิทธิ์แก้ได้ง่ายกว่าขณะที่แอปยังเปลี่ยนแปลงอย่างรวดเร็ว

ทดสอบกรณีที่ยุ่งยากในขั้นตอนปกติ

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

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

ทดสอบข้อยกเว้นที่เกิดขึ้นจริงในการทำงาน:

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

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

ประวัติสถานะสำคัญเมื่อภายหลังมีคำถามเกิดขึ้น ทดสอบลำดับง่ายๆ: Sam สร้างคำขอเวลา 9:10, Priya อนุมัติเวลา 9:25 และ Sam ยกเลิกเวลา 10:00 หลังลูกค้าโทรมา พนักงานที่มีสิทธิ์เข้าถึงคำขอควรเห็นว่าใครเปลี่ยนอะไร เมื่อไร และเหตุผลที่แอปเก็บไว้ พวกเขาควรเห็นสถานะปัจจุบันได้โดยไม่ต้องอ่านหมายเหตุยาวๆ ทั้งหมด

สำหรับแอป Koder.ai ให้อธิบายสถานการณ์เหล่านี้ด้วยภาษาง่ายๆ ก่อนสร้างเวอร์ชันทดสอบ จากนั้นให้ทดสอบในฐานะงานจริง แทนที่จะตรวจแค่ว่าหน้าจอดูเสร็จสมบูรณ์หรือไม่

ป้อนข้อมูลผิดเข้าไปโดยตั้งใจ

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

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

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

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

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

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

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

ทดลองสถานการณ์การทำงานจริงของพนักงานหนึ่งรายการ

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

Maya ผู้จัดการสำนักงานรับโทรศัพท์จาก Jordan Lee เรื่องหม้อน้ำรั่ว เธอค้นหาชื่อ Jordan แล้วพบข้อมูลลูกค้าสองรายการคือ "Jordan Lee" และ "J. Lee" ซึ่งใช้ที่อยู่เดียวกัน Maya เลือกข้อมูลหนึ่งรายการ สร้างงานในเช้าวันพุธ เพิ่มรายละเอียดปัญหา และมอบหมายให้ช่าง Sam

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

ใช้สถานะที่ชัดเจนกว่า เช่น "รอตรวจสอบจากสำนักงาน" Maya จะเห็นขั้นตอนถัดไปชัดเจน และแอปจะไม่ส่งใบแจ้งหนี้ก่อนมีคนตรวจสอบราคา

Maya สังเกตว่า Jordan มีใบแจ้งหนี้เก่าค้างชำระมาแล้ว 45 วัน เธอตัดสินใจว่างานใหม่ต้องได้รับการอนุมัติจากหัวหน้าก่อนออกใบแจ้งหนี้ Priya หัวหน้าของเธอตรวจสอบหมายเหตุของ Sam และอนุมัติส่วนลด เพราะงานซ่อมครั้งก่อนมีปัญหา

สถานการณ์นี้ช่วยตรวจสอบว่าแอปรองรับการตัดสินใจจริงได้หรือไม่:

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

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

หาก Sam อนุมัติส่วนลดจากโทรศัพท์ได้ ให้แก้กฎสิทธิ์ หาก Maya แยกไม่ออกว่า "งานเสร็จแล้ว" หมายถึงออกใบแจ้งหนี้แล้วหรือเพียงทำงานหน้างานเสร็จ ให้เปลี่ยนชื่อสถานะก่อนที่พนักงานจะเริ่มพึ่งพาสถานะนั้น

จัดเซสชันทดสอบง่ายๆ และบันทึกสิ่งที่เกิดขึ้น

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

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

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

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

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

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

ใช้รายการตรวจสอบนี้ก่อนเปิดให้พนักงานใช้งานครั้งแรก

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

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

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

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

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

สร้างบัญชีทดสอบแยกกันสำหรับแต่ละระดับสิทธิ์แทนการใช้บัญชีเดียวร่วมกัน วิธีนี้ช่วยให้ทำซ้ำและแก้ปัญหาการเข้าถึงได้ง่ายขึ้น

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

เตรียมการทดสอบรอบถัดไป

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

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

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

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

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

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