“What is User Acceptance Test” “มาทำความรู้จัก กับ User Acceptance Test กันเถอะ”
หลังจากที่ทิ้งท้ายกันไว้คราวก่อน ก็ถึงเวลาแล้วที่จะมารู้จักความหมายของ User Acceptance Test รวมถึงประเด็นสำคัญที่น่าสนใจอะไรบ้าง
What is “User Acceptance Test”
จากประสบการณ์การทำงานของผู้เขียนโดยตรงในงาน UAT ผู้เขียนจึงได้กลั่นกรองและขอนำเสนอความหมายของ UAT ว่าเป็นอย่างนี้ค่ะ
“User Acceptance Test” เป็นกระบวนการทดสอบระบบขั้นตอนสุดท้ายเพื่อให้แน่ใจว่า ระบบที่พัฒนาพร้อมที่จะใช้งานได้จริง ตรงตามกระบวนการทาง ธุรกิจ (Business Process) และความต้องการของผู้ใช้งานที่ได้กำหนดไว้ (Software Requirements) โดยผลลัพธ์การทดสอบจะต้องเป็นไปตามเงื่อนไขความสมบูรณ์ของระบบที่ควรจะเป็นและสามารถยอมรับได้(Acceptance Criteria) ซึ่งได้ร่วมกันกำหนดขึ้นระหว่างผู้ใช้งานระบบกับทีมงานพัฒนาระบบรวมถึงส่วนงานอื่นๆ ที่เกี่ยวข้อง
การทดสอบระบบในขั้นตอนนี้มีจุดที่สำคัญซึ่งแตกต่างจากการทดสอบขั้นตอนอื่นคือ ผู้ใช้งานระบบจริงจะต้องเข้ามามีส่วนร่วมในกระบวนการทดสอบโดยเริ่มตั้งแต่ กำหนดกรณีทดสอบ(Test Case/Scenario) ร่วมทดสอบระบบ(Executes Test) จนถึง การประเมินและสรุปผลการทดสอบ(UAT Result and Evaluation) และตัดสินใจว่าระบบดังกล่าวจะสามารถนำไปใช้งานจริงได้หรือไม่ ถ้าได้ก็จะมีการลงนามอนุมัติจากผู้ใช้งานเป็นลายลักษณ์อักษร(UAT Sign Off) เพื่อนำระบบไปใช้งานจริง แต่ถ้าไม่ได้ ระบบจะถูกนำไปปรับปรุงแก้ไข แล้วจะกลับเข้าสู่กระบวนการ UAT อีกครั้ง จนกระทั่งเป็นที่ยอมรับของทุกฝ่ายว่าสามารถนำระบบใช้งานจริงได้
โดยที่สภาพแวดล้อมในการทำ UAT (UAT/Test Environment) จะต้องเป็นสภาพแวดล้อมที่เหมือนหรือใกล้เคียงมากที่สุด กับสภาพแวดของการใช้งานจริง (Hardware/Software/Data on Production Environment) เพื่อให้การทดสอบใกล้เคียงกับการทำงานจริงมากที่สุดและได้ผลผลการทดสอบที่น่าเชื่อถือ
ผู้เขียนจะขอขยายความและพูดถึงรายละเอียดในส่วนต่างๆ ที่กล่าวมา ในตอนต่อๆ ไปนะค๊า :flirty:
“A journey of a thousand miles begins with a single step”
A good start is half of the success
LeeFong…
บทความที่เกี่ยวข้อง
พี่โอมก็เซ็งเป็นด้วยหรา
ขอบคุณ คุณ Nick ครับ สำหรับคำแนะนำดีดีครับ
มาช่วยตอบ คุณ QH จากประสบการณ์ ครับผม
โดย ทั่วไป ทุกการทำ Testing ที่ดี ในแต่ ละ Level ของ Testing (Entrie Test Life Cycle)
เอกสาร หลัก ที่ควร จะ ทำขึ้นมา (แต่ก็ขึ้นอยู่ กับ Size ของโปรเจคด้วยครับ)
เช่น โครงการใหญ่ และ Complex มาก พวก Work Product อาจจะมาก ที่จะต้อง Develop
ตัวอย่าง โครงการ ใหญ่ และ Complex
1. Test Plan (ซึ่ง ควร ถูกพัฒนา ตั้งแต่ ช่วง Design Phase) เพื่อวาง Test Approach ว่า เราจะทำ Test ในทิศทางไหน ใช้คน กี่คน บริหาร จัดการ Defect อย่างไร communicate แพลน อย่างไร จะ report อย่างไร, prepare test case อย่างไร นานเท่าไหร่ Execute test case ยังไง (กี่ Cycle), ใช้เวลา นานเท่าไหร่
2. Test Spec (Test Scenario, Test Case/Script) ensure test coverage and traceability perspective.
3. Test Report (Daily, Weekly and end phase report)
ตัวอย่างข้างต้น จะ ออกมามีุคุณภาพ ได้ ก็ขึ้นอยู่ กับ Input document และ BRD ที่เราได้รับมา จาก Phase ก่อน ๆ ของ SDLC.
ถ้า โปรเจค เล็ก ๆ อาจจะ มากำหนด กันอีกที ว่า ควรมี Deliverable อะไรบ้าง ขึ้นอยู่กับหลายปัจจัย ครับ
รบกวนช่วยอธิบายนิดนึงได้ไหมคะว่า กระบวนการทำ UAT มีเอกสารชนิดใดบ้างค่ะ และแต่ละชนิดใช้เพื่ออะไรค่ะ รบกวนท่านผู้รู้ด้วยนะคะ
ฟอร์มทำ UAT ที่ต้องการนี่คือ เอกสารประเภทไหนคะ รบกวนระบุเอกสารที่อยากให้แชร์ด้วยก็ดีนะคะ เพราะว่า ในกระบวนการทำ UAT ก็มีเอกสารอยู่หลายชนิดเหมือนกันอ่ะค่ะ
ขอเป็นภาษาไทยด้วยก็ดีนะค่ะ
อยากได้ฟอร์มทำ UAT ค่ะว่าทำไง
ไม่เคยทำหนะค่ะ
ตอบคุณ YUI ค่ะ “การเขียนเอกสาร UAT” นี้ขอเดาว่าคงหมายถึง test case/scenario ส่วน”เคสที่ผิด”นี่คงหมายถึง บรรดา negative case ที่ไม่ได้ระบุไว้ในเอกสาร requirement หรือในส่วน acceptance criteria
ผู้เขียนขอแนะนำว่า สมควรอย่างยิ่งในการทดสอบระบบ ไม่ว่าจะเป็น testing ประเภทใดก็ตาม ที่ควรจะมีทั้งเคสที่ผิด(unsuccess case) และเคสที่ถูก(success case) UAT phase ก็เช่นเดียวกัน ที่ควรจะกำหนดหรือออกแบบเคสที่มีความเป็นไปได้ว่าอาจจะไม่ผ่าน เพื่อ ช่วยกันยืนยันการทำงานของระบบว่าได้ครอบคลุมความผิดพลาดที่อาจจะเกิดขึ้นในส่วนนี้แล้วหรือยัง
อยากทราบว่าการเขียนเอกสาร UAT นั้นควรใส่เคสที่ผิดเข้าไปในเอกสารหรือไม่คะ หรือว่าควรใส่เคสที่ถูกตาม req ตาม SRS เท่านั้นเพียงพอคะ
UAT เป็นการเทสที่ไม่สิ้นสุดซักที เพราะ user ไม่เคย accept ตามที่ตกลงไว้ เปลี่ยนตลอดเวลาเลน้อ
ผ่านมาเจอคนเขียนน่ารักเลยแวะมาคอมเม๊น 555
:8: เทสไปเทสมา พบว่ามีหลายอย่างที่ทาง developer ยังทำไม่เรียบร้อยเลยครับ ส่งมาได้ไง :eyepopping:
:blah: :blah: :blah:
ปัญหาเรื่อง requirment ที่มาพบใน phase UAT นี้ก็เป็นอีกหัวข้อหนึ่งที่ทางผู้เขียนและทีมงานกำลัง รวบรวมเรียบเรียง ความรู้และประสบการณ์การจัดการกับเรื่องนี้ มาแชร์ให้สมาชิกทุกท่านอยู่นะคะ :reading: :writersblock:
เห็นด้วยกับคุณ NANAJANG ครับ ปัญหานี้เกิดขึ้นบ่อยมากครับ :#1:
ความหมายใช่เลย..แต่บางทีใน software requirement อาจจะระบุไม่ละเอียดมาก เลยทำให้พอถึงช่วง UAT ที่
ผู้ใช้งานระบบ(ที่ละเอียดหน่อย) เข้ามาทดสอบแล้วบอกว่ายังขาดโน่น ขาดนี่ ทำงานไม่ได้ตาม business ต้องการ
ก็ต้องกลับไปเริ่มต้นใหม่อีก :juggle:
ติดตามมา 2 บทความแล้วครับ ก็รู้สึกน่าสนใจและดูมีสาระนะ แต่อยากให้ยกตัวอย่างจากประสบการณ์ด้วย เพื่อให้สามารถมองภาพการนำเอาแนวความคิดและทฤษฎีไปประยุกต์ใช้งานจริง ยังไงก็ขอเป็นกำลังใจให้นะครับ สู้สู้