เมื่อธุรกิจหรือทีมพัฒนาโปรดักต์หนึ่งขึ้นมา ไม่ว่าจะเป็น Physical Product หรือโดยเฉพาะซอฟต์แวร์ แอปพลิเคชั่น เว็บไซต์ ที่มีความซับซ้อน และเกี่ยวข้องกับเรื่องของประสบการณ์ใช้งาน กระบวนการที่จะขาดไม่ได้เลย คือ การทำ User Accecptance Test หรือกระบวนการทดสอบการใช้งานโดยผู้ใช้งานจริง (End users)
ในบทความนี้มาทำความรู้จักกับกระบวนการทดสอบการใช้งานโดยผู้ใช้งานจริง หรือ UAT ให้มากขึ้น ว่าคืออะไร ใช้อย่างไร เพื่อการปล่อยโปรดักต์ที่มีประสิทธิภาพสูงสุด
User Acceptance Test (UAT) คืออะไร
User Acceptance Test (UAT) คือ กระบวนการทดสอบซอฟต์แวร์หรือโปรดักต์โดยผู้ใช้งานจริงหรือลูกค้า (อาจเรียกว่า “End-User Testing”) ซึ่งกระบวนการนี้ เป็นกระบวนการสุดท้ายของการทดสอบระบบและเกิดขึ้นก่อนการปล่อยโปรดักต์ เพื่อตรวจสอบให้แน่ใจว่า ระบบใช้งานได้จริง และผู้ใช้งานก็สามารถใช้งานได้จริง ได้รับประสบการณ์การใช้งานที่ดี
วัตถุประสงค์ของการทำ User Acceptance Test ก็เพื่อตรวจสอบว่าระบบตรงกับความต้องการของผู้ใช้งาน ตรงกับสิ่งที่กำหนดไว้หรือไม่ และสอดคล้องกับเป้าหมายธุรกิจหรือเปล่า โดยผลลัพธ์ภายหลังการทดสอบ คือ ผ่านเกณฑ์ที่เรียกกว่า “Acceptance Criteria” หรือเกณฑ์ที่ยอมรับได้
ในกระบวนการทดสอบ UAT นั้น เพื่อให้ได้ผลลัพธ์ที่แม่นยำ ผู้ใช้งานระบบจริงจะต้องมีส่วนร่วมในการทดสอบ และการทดสอบควรจะต้องจำลองหรือเป็นสภาพแวดล้อมจริงในการใช้งาน ผลลัพธ์ทดสอบจึงจะน่าเชื่อถือ
ทำไมธุรกิจถึงไม่ควรข้ามกระบวนการทำ UAT
เราจะไม่มีทางรู้เลยว่า ชิ้นงานที่เสร็จสมบูรณ์ออกมาจะมีปัญหาในแง่การใช้งานจริงหรือเปล่า ตราบใดที่เราไม่ได้ให้ User ทดสอบ เพราะต่อให้ในมุมของผู้พัฒนา ผู้ผลิต เราจะทดสอบระบบกี่ครั้ง ตรวจแล้วไม่มี Bug ไม่มี Error ไม่มีปัญหาอะไรแล้ว แต่มันอาจจะมีปัญหาบางปัญหาที่ผู้ใช้งานจริงเท่านั้นถึงจะเจอ
UAT ที่ดี จะช่วยให้เรารู้ว่า ชิ้นงานที่เสร็จออกมาตอบสิ่งที่ผู้ใช้งานต้องการจริงๆ หรือไม่ และ UAT ที่ดีจะช่วยให้ธุรกิจและทีมพัฒนามองเห็นปัญหาที่ไม่สามารถค้นหาเจอในช่วงของการติดตั้งระบบ ทดสอบระบบ ซึ่งบทบาทของการทดสอบ User Acceptance คือ ช่วยเติมเต็มการทดสอบโปรดักต์ให้สมบูรณ์
อีกบทบาทของการทดสอบ ก็คือ ช่วยให้เราป้องกันปัญหาเรื่องการให้ Requirement หรือการชี้แจงความต้องการตั้งแต่ขั้นก่อนเริ่มต้นพัฒนา หรือโดยเฉพาะอย่างยิ่งความต้องการที่เปลี่ยนไปเปลี่ยนมาระหว่างพัฒนา …หลายครั้งที่เกิดกรณีผลิตไปแล้ว แต่ได้ไม่ตรงกับ Requirement ก็อาจเป็นได้ทั้งเพราะสื่อสารตกหล่น หรือการตีความและทำความเข้าใจคลาดเคลื่อน และไม่ได้ทำ User Acceptance Test
ยิ่งทดสอบไว ได้คำตอบไว ต้นทุนแก้ไขก็ยิ่งน้อย
แผนภาพข้างต้นนี้ อธิบายค่าใช้จ่ายของการแก้ Bug ในกระบวนการพัฒนาเว็บไซต์หรือโปรดักต์ จะเห็นได้ว่า ยิ่งทดสอบและเจอ Bug เร็วเท่าไหร่ ต้นทุนในการแก้ไขก็ยิ่งน้อย กลับกัน ถ้าหากเราเจอ Bug ภายหลังจากที่เว็บไซต์หรือโปรดักต์ปล่อยออกมาให้ใช้งานแล้ว ต้นทุนในการแก้ไขที่จะต้องจ่ายนั้นเยอะกว่าหลายเท่าตัว เช่นเดียวกับโปรดักต์หรือซอฟต์แวร์อื่นๆ …แล้วเพราะอะไร?
เหตุผลหลักที่ทำให้ค่าใช้จ่ายของการแก้ไขภายหลังช่วงปล่อย (Product Release) น่าจะเป็นเรื่องของ “ชื่อเสียง” (Reputation) ที่เมื่อผู้ใช้งานได้รับประสบการณ์ที่ไม่ดีแล้ว ก็อาจบ่ายหน้าหนีแบรนด์และไม่แนะนำให้คนรู้จักใช้ต่อ ซึ่งเป็นการเสียโอกาสที่ประเมินมูลค่าได้ยาก
ควรเริ่มทำ UAT เมื่อไหร่
UAT คือ กระบวนการสุดท้ายในกระบวนการทดสอบระบบหรือซอฟต์แวร์ ซึ่งไล่เรียงตั้งแต่
1) Unit Testing
2) Integration Testing
3) System Testing และ
4) Acceptance Testing
โดย 3 กระบวนการแรก จะเป็นการทดสอบความเรียบร้อยและความพร้อมของระบบ ซึ่งทดสอบโดยผู้ผลิต แต่กระบวนการ Acceptance Testing จะเป็นการทดสอบโดย End users
อย่างไรก็ตาม นั่นหมายความว่า การที่จะทดสอบ User Acceptance ได้ ระบบจะต้องนิ่ง ทำงานได้ปกติ (ไม่เกิด Error ในมุมของระบบปฏิบัติการ) ฟีเจอร์และฟังก์ชันต่างๆ ต้องพร้อมใช้งาน อย่างที่เกริ่นไปข้างต้นว่า การทดสอบใช้งานจริง ทุกอย่างต้องอยู่ในสภาพแวดล้อมการใช้งานจริงหรือใกล้เคียงที่สุด
ใครที่ต้องทำ UAT
คนที่ควรเป็นคนทดสอบ UAT มากที่สุด ได้แก่
- ลูกค้า
- ผู้ใช้งานจริง (End users)
คนกลุ่มนี้จะเป็นคนที่ตอบได้ว่า เมื่อใช้งานจริงแล้ว พวกเขาเจอปัญหาและได้รับประสบการณ์อย่างไร
นอกจากนี้ สำหรับกลุ่มคนที่ต้องรับผิดชอบดูแลกระบวนการทำ User Acceptance Test นั้น ควรจะมีคนอย่างน้อย 2 กลุ่ม ได้แก่
1. คนที่รู้รายละเอียดเกี่ยวกับฟังชันก์การใช้งานหรือ Requirement ต่างๆ ของสิ่งที่พัฒนา
2. คนที่เข้าใจจุดประสงค์และเป้าหมายของธุรกิจ
โดยคนทั้ง 2 กลุ่ม จะช่วยให้การพัฒนาซอฟต์แวร์หรือโปรดักต์ตอบโจทย์ทั้งในมุมของผู้ใช้งานจริงและมุมของธุรกิจได้ และควรดำเนินงานเป็นทีม
วิธีทำ User Acceptance Test เริ่มต้นทำใน 7 ขั้นตอน
กระบวนการทำ UAT ได้แก่
- วิเคราะห์ Business Requirements
- สร้างแผนการทำ User Acceptance Testing
- ระบุสถานการณ์
- กำหนดกรณีที่จะทดสอบ
- เตรียมจัดเก็บข้อมูล
- ทดสอบและบันทึกข้อมูล
- ประเมินผล
1) วิเคราะห์ Business Requirements
ก่อนที่จะเริ่มต้นทำ UAT ต้องกลับมาทำความเข้าใจกับเป้าหมาย จุดประสงค์ และ Scope of Work ของโปรเจกต์ก่อน เพื่อที่จะได้สามารถนำไปคิดเป็นแผนในการทดสอบต่อไป โดยข้อมูลที่เกี่ยวข้องที่ต้องใช้ในขั้นตอนนี้ คือ เอกสารเกี่ยวกับรายละเอียดโปรเจกต์
ยกตัวอย่างเช่น
- เอกสารโครงการ หรือ Project Charter
- เอกสาร Business Use Cases
- แผนผังกระบวนการหรือ Process Flow Diagrams
- Business Requirements Document (BRD)
- System Requirements Specification(SRS)
2) สร้างแผนการทำ User Acceptance Testing
เขียนแผนการทำ UAT ออกมาเป็นเอกสาร ว่าต้องการทดสอบอะไรบ้าง ใครใช้ แล้วตอบ Business Requirement (และเอกสารในข้อ 1) หรือเปล่า รวมทั้ง ระบุสถานการณ์ในการทดสอบ (ขั้นตอนที่ 3) วิธีการทดสอบ ตลอดจนไทม์ไลน์การทำงาน
3) ระบุสถานการณ์ (Identify Scenarios)
ระบุสถานการณ์ที่จะใช้ทดสอบไว้ก่อน โดยสถานการณ์ควรจะใกล้เคียงกับการใช้งานจริงมากที่สุดเพื่อให้ผลลัพธ์น่าเชื่อถือ ทั้งนี้ หากไม่สามารถทดสอบผู้ใช้งานจริงในสถานที่จริงได้ เราทำผ่านโปรแกรม Live Streaming ได้เช่นกัน ในกรณีทดสอบซอฟต์แวร์ เว็บไซต์ หรือแอปพลิเคชั่น
4) กำหนดกรณีที่จะทดสอบ (Test cases)
กำหนดว่า จะทำการทำสอบอะไรบ้าง อาจให้ User ลองใช้งานในภาพรวม หรือลองมอบหมายโจทย์ให้ User ลองใช้งานอย่างมีเป้าหมาย โดยกรณีต่างๆ ที่จะทดสอบจะมาจากรายละเอียดโปรดักต์ต่างๆ ในข้อ 1 และมี Test case ระบุใน UAT
5) เตรียมจัดเก็บข้อมูล
ไม่ใช่แค่การทำเอกสารและระบบการทำงานสำหรับจัดเก็บข้อมูลเท่านั้น แต่เนื่องจากการทำ UAT จำเป็นที่จะต้องทดสอบการใช้งานจริงจาก User ดังนั้น จึงมีเรื่องของการรักษาความเป็นส่วนตัว (Data Privacy) เข้ามาร่วมด้วย
ในทีมที่ทำการทดสอบควรมีคนที่มีความรู้ในการดำเนินการเกี่ยวกับการใช้ข้อมูลที่ถูกต้อง
6) ทดสอบและบันทึกข้อมูล
ลองให้ผู้ใช้งานจริงเริ่มทดสอบใช้งานตาม Test Cases ที่กำหนดไว้ เก็บข้อมูล สัมภาษณ์ และรับฟีดแบก
7) ประเมินผลและสรุปผล
เมื่อได้ข้อมูลออกมาเป็น UAT ที่เรียบร้อยแล้ว ขั้นตอนสุดท้ายก็คือการประเมินผลและสรุปผลเพื่อพัฒนาต่อ
เราจะมาดูผลการทดสอบว่า มีอะไร มีกรณีไหนที่ผ่านหรือไม่ผ่านตามเกณฑ์ที่เราได้กำหนดไว้ มีปัญหาอะไรเกิดขึ้นบ้าง ถ้ามี ควรแก้ไขอย่างไร แล้วใครเป็นผู้รับผิดชอบต่อ ก็สามารถระบุไว้ได้เลย ทั้งนี้ ในการประเมินผล ควรมองทั้งในเชิงปริมาณและเชิงคุณภาพ เช่น เกิดปัญหาเท่าไหร่ แล้วรายละเอียดของปัญหาที่เกิดขึ้น คืออะไร เป็นต้น
ตัวอย่างคำถามในการประเมิน
- มีคนผ่านการทดสอบทั้งสิ้นกี่รายจากกลุ่มตัวอย่าง คิดเป็นร้อยละเท่าไหร่
- ผู้ใช้งานมีความพึงพอใจกับการทดสอบหรือการใช้งานแค่ไหน
- อารมณ์ของผู้ใช้งานขณะทดสอบใช้งานเป็นอย่างไร หงุดหงิดหรือเปล่า รู้สึกติดขัดกับอะไร
- ฯลฯ
UAT ไม่ใช่แค่การทดสอบ แต่คือกระบวนการในการพัฒนา
ใน 7 ขั้นตอนของการทำ User Acceptance Test กระบวนการสุดท้าย คือ การประเมินผล สรุปผล และแน่นอนว่า ต้องรายงานผลว่ามีอะไรบ้างที่ต้องดำเนินการปรับปรุงพัฒนา เพื่อให้ชิ้นงานสามารถตอบทั้ง User Acceptance และ Business Objective
อย่างไรก็ตาม ไม่ได้หมายความว่า ขั้นตอนที่ 7 คือ กระบวนการสิ้นสุด
หากแต่การที่เราจะพัฒนาซอฟต์แวร์หรือโปรดักต์ให้ตอบโจทย์ที่สุด อาจต้องย้อนกลับไปถึงขึ้นพัฒนาโปรดักต์ ดีไซน์โปรดักต์เลยก็ได้ และ UAT ก็คือหนึ่งกระบวนการในวัฏจักร (Cycle) ของการพัฒนา
จะเห็นได้ว่า ในวัฏจักรการทดสอบดังรูป ซึ่งรวมไปถึงกระบวนการออกแบบด้วย “Acceptance Testing” คือ ส่วนหนึ่งในกระบวนที่นำไปสู่ “การให้ฟีดแบก” (Feedback & Review) และฟีดแบกที่ได้ ก็จะเอามาพิจารณาต่อว่า “Accept” หรือไม่ ซึ่งคือ การรีวิวและประเมินผล UAT
หากประเมินแล้วว่า “ผ่าน” ก็เข้าสู่กระบวนการ “ปล่อย” (Release) โปรดักต์ได้ แต่ถ้า “ไม่” เราก็จะกลับไปที่จุดประสงค์หรือสิ่งที่ลูกค้า/User ต้องการ (User Stories)
ทั้งนี้ กระบวนการดีไซน์โปรดักต์หรือซอฟต์แวร์ อาจแบ่งระยะ (Phase) การทำงานและทดสอบรับฟีดแบกได้ ไม่ได้หมายความว่า การพัฒนาโปรดักต์เป็นที่สิ้นสุดเมื่อทดสอบ Acceptance ผ่านแล้ว รอบหนึ่ง
อาจสรุปได้ว่า User Acceptance Test ไม่ใช่กระบวนการที่ทำแล้วเสร็จสิ้นไป แต่เป็นกระบวนการสำคัญที่ต้องทำอย่างต่อเนื่อง มีทีมงานที่ดูแลรับผิดชอบอยู่ตลอด
เป้าหมายและแนวคิดสำคัญในการรัน UAT ให้ประสบผลสำเร็จ คือ UAT จะต้องสามารถสร้างวัฏจักรของการให้ฟีดแบกได้จริง ซึ่งจะนำมาสู่การพัฒนาให้ดีขึ้นไปอย่างไม่รู้จบ
