What is UAT?

สวัสดียามเช้าวันอังคารเดือนตุลาคมครับ เช้าที่ท้องฟ้ามีทั้งเมฆฝน และแสงพระอาทิตย์ในเวลาเดียวกัน ในขณะที่น้องในทีมกำลัง ยิง programmer ตับแตก (Performance Testing) อยู่ ผมก็เลยมานั่งเขียนเรื่อง UAT หรือที่มีชื่อเต็มๆ อย่างเป็นทางการว่า User Acceptance Testing

รูปจาก http://geekandpoke.typepad.com

ในช่วงปีกว่าๆ มานี้กระแสเรื่องของ Software Testing มา แรงขึ้น แรงขึ้น และจากผลของตัวเก็บ Stat การเข้ามายัง welovebug ก็พบว่า หนึ่ง ใน keyword การค้นหาก็คือคำว่า UAT ก็เลยมาแนะนำเจ้า UAT ให้รู้จักกันก่อนว่า เขาคือใครคุณ UAT ?

UAT คืออะไร?

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

มาเข้าเรื่องกันเลยละกันนะครับ

UAT หรือชื่ออย่างเป็นทางการคือ User Acceptance Testing ส่วนใหญ่จะพบเจอกันในขั้นตอนสุดท้ายของการพัฒนา Software ก่อนที่จะประกาศเปิดใช้งานจริงๆ บนระบบ Production

ในขั้นตอนการทำ UAT จะดำเนินการทดสอบโดย User ซึ่งผมขอสรุปสั้นๆ ง่ายๆ เพื่อความเข้าใจว่า User ของผมหมายถึงใคร

• ผู้ที่ให้ หรือเป็นเจ้าของ Requirement ของ Software
• ผู้ที่ใช้งาน Software

การทำ UAT เพื่อช่วยเพิ่มความมั่นใจ และตรวจสอบว่า Software ถูกพัฒนาออกมาตรงตาม Requirement หรือไม่

อาจจะพูดไ้ด้ว่า UAT วัดความ พึงพอใจของผู้ใช้ ก็ว่าได้ (ความคิดเห็นส่วนตัว) :)

จะต้องทำอะไรก่อน UAT ?

Software จะต้องผ่าน Unit Testing, Integration Testing, System Testing และ Regression Testing มาก่อน พร้อมทั้งดำเนินการแก้ไข Bug หรือ Defect ให้เรียบร้อยก่อนที่จะเริ่มส่งเข้ามาทำ UAT

ในทางปฏิบัติจริงๆ Bug หรือ Defect ที่ควรจะต้องแก้ไขให้หมดก่อนส่งเข้า UAT คือจำพวกที่เกี่ยวข้องกับทาง Technical และ Logic ของ Software ส่วนจำพวกที่เกี่ยวข้องกับการแก้ไขเล็กๆ น้อยๆ เช่น รูปร่างหน้าตา, สี, Link หรือ รูปภาพ สามารถนำมารวมไว้ในแผนงานการแก้ไข Bug หรือ Defect ในช่วงของ UAT ได้ ขึ้นอยู่กับการตกลงของทีมงาน

Test Case เป็นสิ่งที่จำเป็น และจะช่วยทำให้การทำ UAT มีประสิทธิภาพมากยิ่งขึ้น โดยการออกแบบ Test Case ของ UAT แนะนำให้ออกแบบในมุมของ Business Flow และ Business Logic ตาม Requirement เป็นหลัก เน้นการทดสอบแบบการใช้งานจริงของ User ที่จะต้องเข้ามาใช้งาน Software

ขั้นตอนการทำ UAT

จุดประสงค์หลักของการทำ UAT คือเรื่องของ Function และ Usability ของ Software ในมุมของการใช้งานจริงของ User ที่จะเกิดขึ้น ดังนั้นขอเน้นย้ำอีกครั้งว่า

จะต้องทำ Unit Testing, Integration Testing, System Testing และ Regression Testing มาก่อน พร้อมทั้งดำเนินการแก้ไข Bug หรือ Defect ที่เกี่ยวข้องกับทาง Technical และ Logic ของ Softwareให้เรียบร้อยก่อนที่จะเริ่มส่งเข้ามาทำ UAT

อีกหนึ่งปัจจัยที่ควรจะต้องเน้นเป็นอย่างมากในการทำ UAT ก็คือ Test Environment ซึ่งควรจะต้องใกล้เคียงกับ Production Environment มากที่สุด

7 ขั้นตอนในการทำ UAT

ผมขอแนะนำ 7 ขั้นตอน (เบื้องต้น) ในการทำ UAT ดังนี้

1. จัดทำแผนการทำ UAT (User Acceptance Testing Planning)
2. ออกแบบ Test Cases สำหรับ UAT
3. จัดตั้งทีมงานในการดำเนินการทำ UAT ตาม Test Cases
4. ดำเนินการทำ UAT
5. บันทึก Bug หรือ Defect ที่พบในการทำ UAT และประชุม Review เพื่อสรุปสิ่งที่จะแก้ไข
6. แก้ไข Bug หรือ Defect ที่ตกลงจะแก้ไข และทำ Regression Testing
7. Sign off จบงาน

จัดทำแผนการทำ UAT (User Acceptance Testing Planning)

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

ที่จะลืมไปเสียไม่ได้เลยก็คือ

• Entry Criteria, ข้อกำหนด หรือข้อตกลง ก่อนที่จะเริ่มการทำ UAT
• Exit Criteria, ข้อกำหนด หรือข้อตกลง การจบการทำ UAT เพื่อ Sign off

ส่วนใหญ่จะ ละเลย ในเรื่องของการทำแผน และกำหนด Entry Criteria และ Exit Criteria

ออกแบบ Test Cases สำหรับ UAT

ผมจะเจอคำขอ “ขอตัวอย่าง Test Cases สำหรับทำ UAT” อยู่เนืองๆ บน welovebug ซึ่งจริงๆ แล้วอยากให้มองกลับไปถึงการออกแบบ Test Cases ก่อนครับ

UAT อยู่ในประเภทของ Black box Testing ซึ่งตามตำรา Software Testing จะแนะนำเทคนิคการออกแบบไว้อยู่ แต่ผมไม่ขอกล่าว ณ ตอนนี้

การออกแบบ Test Cases สำหรับ UAT ควรจะต้องเริ่มดำเนินการเมื่อสรุปเรื่องของ Requirement จบ ข้อย้ำ เน้นๆ เลยนะครับ ถ้าเทียบกับ Phase ของฝั่ง Development ก็คือทำงานไปพร้อมๆ กับทีม SA หรือ BA ดำเนินการวิเคราะห์ และออกแบบระบบ เพื่อส่้งไปให้ทีม Developer ดำเนินการ Coding และถ้าได้เอกสารการวิเคราะห์ และออกแบบระบบของ SA หรือ BA มาประกอบด้วยจะดียิ่ง แต่เป็น Optional นะครับ ไม่ได้เป็นสูตรตายตัว :)

ภาษาที่ใช้ในการเขียน Test Cases ขอแนะนำให้ใช้ภาษาง่ายๆ อย่ามี Technical Terms ใดๆ เพราะผู้ที่ถูกเชิญเข้ามาทำ UAT ส่วนใหญ่จะไม่มีความรู้พื้นฐานทางด้าน Technical เลย ดังนั้น ควรใช้ภาษาที่เข้าใจง่าย เปรียบเทียบง่ายๆ ถ้า คนที่โง่ที่สุดในจักรวาลอ่านแล้วทำตามขั้นตอนได้ นันแหละ แจ่มมากครับ

แนะนำเพิ่มเติม SA, BA และผู้ที่อยู่ในทีมพัฒนา ควรจะร่วมด้วยช่วยกันในการ Review Test Cases เพื่อเพิ่มความมั่นใจว่า Test Cases ที่จะถูกนำไปดำเนินการทดสอบ มีความถูกต้องตรงตาม Requirement มากที่สุด

จัดตั้งทีมงานในการดำเนินการทำ UAT ตาม Test Cases

ขั้นตอนนี้ก็เป็นอีกหนึ่งจุดที่สำคัญไม่ิหยิ่งหย่อนไปกว่ากันเลยทีเดียว ดังนั้นขอแนะนำว่า

ผู้ที่จะถูกเลือกเข้ามาทำ UAT จะต้องเป็นตัวแทนของแต่ละกลุ่มผู้ใช้ Software นั้นจริงๆ

ถ้าได้ผู้ที่เป็นผู้ใช้งาน Software นั้นจริงๆ มา ก็จะทำให้การทำ UAT มีประสิทธิภาพมากขึ้น

ดำเนินการทำ UAT

หลังจากทำ Test Cases เรียบร้อย เตรียม, Test Environment เรียบร้อย และได้ทีมที่จะเข้ามาทำ UAT แล้ว (ตาม Entry Criteria ที่ตกลงกันไว้) ก็ถึงขั้นตอนของการดำเนินการทำ UAT

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

บันทึก Bug หรือ Defect ที่พบในการทำ UAT และประชุม Review เพื่อสรุปสิ่งที่จะแก้ไข

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

ที่ผมเน้นตรงจุดนี้เพราะว่าจากประสบการณ์ส่วนตัวที่ผ่านมา ทีม Test ของผมใช้ระบบ Bug Tracking เจ้า Mantis แต่ปรากฏว่าทีม UAT ไม่คุ้นชิน และขอใช้การแจ้งผลมากทาง MS Word แบบที่เขาคุ้นเคย

หากเจอทีมที่เข้ามาทำ UAT ที่มี skill ในระดับหนึ่ง ขอให้นำเสนอระบบ Bug Tracking เข้าไปเลยครับ

แต่ถ้าเจอแบบ skill ไม่มาก ขอให้ตกลงกันว่าจะบันทึก, รวบรวม และแจ้งผล Bug หรือ Defect ที่พบ ด้วยวิธีการใด

ขอแนะนำว่า Test Team ควรจะต้องเข้ามาช่วยในเรื่องพวกนี้ครับ ในการทำ Defect Management

หลังจากได้ Bug หรือ Defect ทั้งหมดจากการดำเนินการทำ UAT แล้วนั้น ควรจะต้องเรียกประชุมทีมงานทั้งหมด เพื่อ

• สรปุผลการดำเนินการทำ UAT
• Review Bug หรือ Defect ที่พบ
• สรุป Bug หรือ Defect ที่ยอมรับ และจำถูกดำเนินการแก้ไข
• กำหนดแผนสำหรับการแก้ไข Bug หรือ Defect
• กำหนดแผนสำหรับการทำ Regression Testing

แก้ไข Bug หรือ Defect ที่ตกลงจะแก้ไข และทำ Regression Testing

ดำเนินการแก้ไข Bug และ Defect ตามแผนที่ได้กำหนด และตกลงกันไว้โดยทีม Development

เมื่อเสร็จสิ้นการแก้ไข ทีม UAT ก็ดำเนินการ Regression Testing เพื่อ

• ตรวจสอบว่า Bug หรือ Defect ได้ถูกแก้ไข
• ไม่ไปสร้าง Bug หรือ Defect ใหม่
• Bug หรือ Defect ที่เคยถูกแก้ไขไปแล้ว ไม่ฟื้นคืนชีพกลับมา

Sign off จบงาน

ประชุมสรุปกันในทีมพัฒนา Software ทั้งหมด รวมทั้งทีมดำเนินการทำ UAT เพื่อสรุปว่าเป็นไปตาม Exit Criteria และข้อตกลงต่างๆ หรือไม่

หา่กทุกอย่างจบลงตัว ก็ดำเนินการ Sign off ปิดงาน และ รับตังค์ (สำหรับ vendor) :)

สรุปปิดท้ายเรื่อง UAT

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

สรุปปิดท้ายสั้นๆ สำหรับ UAT

• UAT Planning เป็นสิ่งที่สำคัญยิ่งในการดำเนินการ
• Entry Criteria และ Exit Criteria กำหนดกันให้ชัดเจน และเข้าใจตรงกัน
• ออกแบบ Test Cases ตาม Flow การทำงานจริงของ Software และใช้ภาษาที่อ่านเข้าใจง่าย
• จัดตั้งทีมดำเนินการทีม UAT โดยเลือกตัวแทนของผู้ที่จะใช้งาน Software นั้น มาอยู่ในทีม
• บันทึก, Review และกำหนดแผนการแก้ไข Bug หรือ Defect ที่พบ
• ดำเนินการ Regression Testing เพื่อตรวจสอบว่า Bug หรือ Defect ถูกแก้ไขถูกต้อง, ไม่เกิด Bug หรือ Defect ใหม่ และ Bug หรือ Defect เก่า ไม่ฟื้นคืนชีพ
• ประชุมสรุป Sign off และรับตังค์

ขอเน้นย้ำปิดท้ายไว้นะครับว่า Software Testing ช่วย

• ลด Bug หรือ Defect ที่จะเกิดขึ้นบน Production
• ลดความเสี่ยง
• เพิ่มความมั่นใจ
• No Bug Free

[ad#adsense-468x60]