UI Testing หรือ User Interface Testing
UI คือส่วนที่ผู้ใช้งานเห็น และใช้งาน
ทั้งการ click และ drag & drop ด้วย mouse
ทั้งการกดปุ่มใน keyboard
รูปแบบของ UI จะมี 2 แบบหลัก ๆ คือ
- Command line
- GUI (Graphic User Interface)
กลับมาในส่วนของการพัฒนาระบบ
โดยปกติจะเริ่มตรวจระบบงานตั้งแต่การออกแบบส่วนของ GUI ก่อนว่าเป็นอย่างไร สวยไหม ดูดีไหม และใช้งานง่ายไหม ลองคิดดูว่า ถ้าระบบที่กำลังพัฒนาอยู่นั้น ยังไม่มีส่วนของ GUI ที่ควรจะเป็นหรือตรงตามความต้องการของลูกค้า คำถามที่ตามมาคือ เรากำลังทำอะไรกันอยู่ หรือแค่ mock ๆ มั่ว ๆ ไป แล้วมานั่งแก้ไขในภายหลัง !! แล้วเราจะได้ทำตามความต้องการจริง ๆ หรือ ? ตรงนี้อย่าหลอกตัวเองดังนั้น GUI คือหน้าต่างบานแรกที่สำคัญมาก ๆ
และ UI Testing ก็สำคัญไม่น้อยไปกว่ากัน เนื่องจากถ้าสนใจเพียง GUI อย่างเดียว แต่ไม่ได้ทำการทดสอบเลย ก็จะทำให้เสียเวลาไปแบบไร้ค่ามาก ๆโดยที่ UI Testing นั้น ควรสร้างตั้งแต่เริ่มการพัฒนา เพื่อลดความเสี่ยงที่จะเกิดขึ้นในช่วงท้ายของการพัฒนา แต่เรามักไปทดสอบช่วงท้ายกัน ทำไมนะ ?
มาถึงตรงนี้แล้ว UI Testing คืออะไร ?
หลัก ๆ คือการทำให้มั่นใจว่า การทำงานผ่าน GUI มันถูกต้องตามที่คาดหวัง ระบบงานทำตาม specification ที่เขียนไว้นะ ระบบงานทำตามข้อตกลง เพื่อดูว่ามี defect ตรงไหนบ้าง ? เพื่อตรวจสอบว่าการออกแบบถูกต้องหรือไม่ ? รวมไปถึงหน้าจอ และ element ต่าง ๆ ซึ่งเยอะแยะมากมาย อีกทั้งการรับ event และ แสดงผลตรงตามที่ตกลงไว้หรือไม่ ? ปล. มีบางคนอาจจะถามว่า เราต้องไปตรวจสอบถึง database เลยไหมว่ามีข้อมูลเข้าหรือเปลี่ยนแปลง ก็ตอบง่าย ๆ เลยว่า เรากำลังทำการทดสอบ GUI นะ ดังนั้นไม่ต้องไปสนใจรูปแบบของ UI Testing ประกอบไปด้วย
- Manual testing หรือการทดสอบด้วยคน
- Automation testing หรือการทดสอบแบบอัตโนมัติด้วยโปรแกรม
- Record and Play back หรือ Capture and Replay testing
- Model based testing
- เมื่อมีการเปลี่ยนแปลง GUI จำเป็นต้อง Record ใหม่ทั้งหมด เปลืองมาก ๆ
- ผูกติดกับเครื่องมือมากเกินไป
- ไม่สนใจพฤติกรรมของระบบมากนัก
ดังนั้นสิ่งแนะนำคือ Model based testing
หลัก ๆ เป็นการสร้าง model หรือส่วนอธิบายพฤติกรรมการทำงานของระบบผ่าน GUI ต่าง ๆ ทำให้เราเข้าใจในรายละเอียดของระบบมากขึ้น ทำให้เราเข้าใจ state การทำงานมากขึ้น ในบางครั้งอาจจะลดความสนใจจาก GUI ลงไปได้เยอะ นั่นหมายความว่า ถ้า GUI เปลี่ยนแปลงแต่ state ไม่เปลี่ยน ก็จะไม่ส่งผลต่อ test case มากนักสิ่งที่ควรพิจารณาสำหรับ UI Testing
เนื่องด้วยเป็นการทดสอบส่วน GUI จึงหลายสิ่งอย่างให้คิด มีหลาย test case ที่ควรและไม่ควรทดสอบ บางอย่างอาจจะไม่ใช่ test case แต่น่าจะเป็น checklist ที่ดีได้ ยกตัวอย่างเช่น การตรวจสอบ Font หรือตัวอักษร ว่ามีชนิดตรงตามข้อตกลงหรือไม่ ว่ามีขนาดตรงตามข้อตกลงหรือไม่ รูปแบบของ icon ต่าง ๆ ของระบบว่าตรงตามที่ตกลงหรือไม่ การตรวจสอบสีตรงตาม style guide หรือไม่ ทั้ง background, hyperlink, ปุ่ม การตรวจสอบ look & feel ของระบบ รวมทั้งความเข้ากันได้ของระบบ การตรวจสอบข้อมูลเข้าหรือ input ว่าเป็นอย่างไร ว่าแสดงในรูปแบบเดียวกันทั้งหมดหรือไม่ ทั้ง required field และ optional field อีกทั้งการจัดการ error ต่าง ๆ จะแสดงอย่างไรบ้าง รวมไปถึงความยาวของข้อมูลเข้าในแต่ละ field การยืนยันเมื่อต้องลบหรือแก้ไขข้อมูล เป็นอย่างไร และอื่น ๆ อีกมากมายคำถามที่น่าสนใจคือ สิ่งต่าง ๆ เหล่านี้คือ test case หรือไม่ ? หรือมันเป็นเพียง checklist ที่ควรมี ระหว่างตรวจสอบแบบ manual กับ automation อะไรน่าจะเหมาะสมกว่ากัน ?
ทำไมเราควรทำ UI Testing ?
- ช่วยทำ regression test เพื่อหาข้อผิดพลาดให้
- ทำให้ช่วยลดปัญหาต่าง ๆ ลงไป เน้นว่าช่วยลดปัญหานะ แต่ช่วงแรกปัญหาเพียบ
- ยิ่งถ้าเป็น Automation testing ก็ทำให้เรารู้ผลกระทบได้ดี และที่สำคัญคือมันจะมีความเสถียร
- งานอะไรที่ต้องทำซ้ำ ๆ ก็ลดลงบ้าง ไปให้สิ่งที่ไม่ใช่คนทำบ้างนะ
- ช่วยลดคน นั่นคือลดค่าใช้จ่าย หรือเอาคนไปทำอะไรที่มีคุณค่ามากกว่า
- ช่วยทำให้เราพัฒนาอยู่อย่างเสมอ จากจำนวน test case ที่เพิ่มขึ้น จากข้อผิดพลาดที่พบ ทั้งประสบการณ์และเครื่องมือที่ใช้งาน
- ช่วยเพิ่มคุณภาพของระบบให้ดียิ่งขึ้น นั่นคือผู้ใช้งานและลูกค้าก็จะมีประสบการณ์ที่ดีไปด้วย