[Test Automation] : บทที่ 3 เทคนิคการพัฒนาเพื่อทำให้เกิดการทดสอบอัตโนมัติ
เราก็เดินทางกันมาถึงบทที่ 3 แล้วนะคะ ก่อนหน้านี้จะเป็นน้อง Netty Chutibuat ที่ได้เขียนเนื้อหาของบทที่ 1 และบทที่ 2 เอาไว้ อ่านกันมาแล้วใช่มั้ยล่ะคะ อิอิ ส่วนใครที่ยังไม่ได้อ่าน ลองกลับไปดูสารบัญของเราได้ที่
[Test Automation] :
การทดสอบอัตโนมัติที่ประสบความสำเร็จ ต้องเตรียมพื้นฐานอะไรบ้าง?
บทที่ 3 เทคนิคการพัฒนาเพื่อทำให้เกิดการทดสอบอัตโนมัติ
มาเริ่มกันค่ะ ในบทความนี้ก็จะยาวหน่อยนึงนะคะ เราจะมาพูดถึงเรื่องเทคนิคต่างที่จะช่วยเพิ่มประสิทธิภาพให้กับ Test Automation Framework ของเรา แต่ก่อนที่จะทำให้เกิดสิ่งนั้นได้ เราจะต้องมีความรู้ ความเข้าใจ และทำให้การทดสอบอัตโนมัติให้เกิดขึ้นตั้งแต่ในใจก่อนนะคะ
สิ่งแรกที่ต้องรู้เลย คือเจ้าพีระมิดนี้ค่ะ..
Test Automation Pyramid
จากหนังสือ Succeeding with Agile: Software Development Using Scrum ของ Mike Cohn ได้อธิบายถึง Test Automation Pyramid เอาไว้เกี่ยวกับการทดสอบแบบอัตโนมัตินั้นสามารถเกิดใน 3 ระดับ คือ UI, Service และ Unit ตรงนี้สำคัญ เราจะต้องรู้และเข้าใจว่าแต่ละระดับแตกต่างกันอย่างไร
Unit Level
หากเหตุผลที่หลายๆ คนนำการทดสอบอัตโนมัติเข้ามาใช้กับการทำงานเป็นเพราะว่าต้องการ Feedback ที่เร็วขึ้น ดังนั้น อาจต้องการออกแบบการทดสอบแบบอัตโนมัติที่สามารถ Run ได้เร็วที่สุดเท่าที่จะเป็นไปได้ วิธีที่จะช่วยทำให้เกิดการทดสอบและได้รับ Feedback ที่เร็วที่สุดก็คือ การทำการทดสอบใกล้กับ Production Code ซึ่งสิ่งนั้นคือการทดสอบที่ระดับ Unit
ซึ่งเป็นการทดสอบในระดับ “ฟังก์ชั่น” ที่เป็นหน่วยการทดสอบที่เล็กที่สุด สามารถเขียนได้ง่ายและได้ผลการทดสอบที่รวดเร็ว การทดสอบชนิดนี้เรียกว่า Unit Test โดยจะตรวจสอบโลจิคการทำงานของฟังก์ชั่นนั้นโดยเฉพาะ ไม่มีการเชื่อมต่อกับส่วนอื่น เช่น ฟังก์ชั่นอื่น, ฐานข้อมูล, หน้าจอใดๆ ตรงนี้หากทีมได้ทำได้ทำการวิเคราะห์แล้วว่า Bug เกิดขึ้นที่ฟังก์ชั่นไหน เราสามารถโฟกัสไปจุดนั้นได้เลย
เราควรจะเขียนการทดสอบอัตโนมัติที่ระดับนี้ให้มากที่สุด เพื่อให้ได้รับ Feedback ที่เร็วที่สุด
Service Level
เป็นการทดสอบการทำงานของ Service ที่ไม่ได้มีส่วนของหน้าจอมาเกี่ยวข้อง โดยการทดสอบอัตโนมัติที่ระดับนี้จะมีการเรียกใช้ APIs และฟังก์ชั่นที่เกี่ยวกับ Business Logic ต่างๆ เพื่อตรวจสอบว่าแต่ละส่วนสามารถทำงานด้วยกันได้อย่างถูกต้อง
เราควรจะเขียนการทดสอบอัตโนมัติที่ระดับนี้ให้มากรองลงมาจาก Unit Level
UI Level
ระดับถัดมาจะเป็นระดับ UI การเขียนชุดการทดสอบอัตโนมัติจะใช้เวลาในการเขียนและทดสอบมากหรือน้อยขึ้นอยู่กับหน้าจอ หากหน้าจอมีการเปลี่ยนแปลงบ่อย ชุดการทดสอบที่ทำไว้ก็จะไม่สามารถใช้งานได้ ต้องทำการปรับแก้ก่อนทำการทดสอบอีกครั้ง การทดสอบอัตโนมัติในส่วนนี้จึงควรมีให้น้อยที่สุด เพราะชได้รับผลการทดสอบช้าที่สุด และมีค่าใช้จ่ายสูง
จากทฤษฎีที่ว่ามาทั้งหมด คราวนี้เราลองมาดูการใช้งานกันบ้างว่า จะเป็นเช่นไร
เมื่อทีมทำการพัฒนาฟีเจอร์ต่างๆในระดับ UI ซึ่งอาจทำให้เข้าใจว่าจะเป็นการทดสอบอัตโนมัติที่ระดับ UI เท่านั้น ในส่วนนี้เราจะต้องดูก่อนว่าอันที่จริงแล้วสิ่งที่เราต้องการทดสอบคืออะไร เราต้องการทดสอบว่าจริงๆแล้ว “ระบบทำงานอย่างไร และแสดงผลอย่างไร” ใช่มั้ย??
เราจะทำชุดการทดสอบอัตโนมัติที่ระดับ UI ให้กับ Main Scenario เพียงหนึ่งเส้นเท่านั้น สำหรับ Scenario ที่เราต้องการทดสอบ อ้อ..อธิบายเพิ่มเติมเพื่อความเข้าใจตรงกัน คำว่า Main Scenario ในที่นี้หมายถึง กระบวนการทำงานที่ประกอบด้วยขั้นตอนต่างๆ ตั้งแต่ต้นจนจบที่สามารถทำงานได้สำเร็จ นะคะ
เมื่อเราต้องทำการทดสอบการค้นหาสินค้าที่เป็นกระบวนการทำงานหลัก หรือ Main Scenario ในระดับ UI การทดสอบอัตโนมัติในระดับนี้จะตรวจสอบว่าเมื่อทำการค้นหา ผลลัพธ์ที่แสดงถูกต้องหรือไม่ การแสดผลตามที่ควรจะเป็นหรือไม่ รวมถึงส่วนประกอบอื่นๆ ของหน้าจอสามารถทำงานได้หรือไม่ เช่น การ Filter ข้อมูล, การเรียงลำดับข้อมูล เป็นต้น
แต่เมื่อต้องการทดสอบการค้นหาสินค้าที่เป็นกระบวนการอื่นๆ เป็นทางเลือกเพิ่มเติม ที่มีกระบวนการทำงานไม่ต่างเลย แต่ต่างกันที่ข้อมูลที่ใช้ทดสอบ แสดงว่าในส่วนนี้เราต้องการทดสอบการทำงานของ Algorithm ของฟังก์ชั่นนั้น ดังนั้น เราจะไม่ทำการทดสอบนี้ในระดับ UI และควรดันให้เกิดการทดสอบในระดับที่ต่ำกว่า เช่น ระดับ Service หรือ Unit
นอกจากนี้ หากต้องการทดสอบการเพิ่มสินค้าใส่ตะกร้าสินค้า ซึ่งถ้าเริ่มตั้งแต่ขั้นตอนแรก จนถึงเพิ่มสินค้าลงตะกร้าสำเร็จ จะประกอบไปด้วยขั้นตอนต่างๆมากมาย เช่น
- ค้นหาสินค้า
- ดูผลการค้นหา เพื่อหาสินค้าที่ต้องการ
- กดเลือกสินค้านั้น
- กดปุ่มเพิ่มสินค้าใส่ตะกร้า
- กดปุ่มตะกร้าสินค้า
- ตรวจสอบสินค้าที่มีในตะกร้า
หากเราทำการทดสอบขั้นตอนเหล่านี้ที่ระดับ UI จะมีความเสี่ยงสูง เนื่องจากหน้าจออาจเกิดการเปลี่ยนแปลงบ่อย หรือหากจุดใดจุดหนึ่งเกิดปัญหารันไม่ผ่าน ก็จะทำให้การทดสอบหยุดชะงัก จนเราไม่สามารถทดสอบไปถึงจุดที่เราต้องการได้
ดังนั้น เราจึงจำเป็นต้องแยกการทดสอบให้เป็นอิสระ และมองหา Seam หรือ รอยต่อของขั้นตอนของการทดสอบ และข้ามมาทดสอบมาทดสอบในสุดที่เราสนใจ จากตัวอย่างดังกล่าวเราสามารถข้ามขั้นตอนที่ 1 และ 2 ได้เลย โดยวิ่งตรงมาที่ URL ของสินค้านั้น เทคนิคนี้จะช่วยให้การทดสอบอัตโนมัติสามารถทำได้เร็วขึ้น และได้ทดสอบในจุดที่เราสนใจจริงๆ คือการเพิ่มสินค้าลงตะกร้า อีกทั้งยังช่วยลดความเสี่ยงที่จะเกิดขึ้นในหาก UI ได้รับผลกระทบใดๆ จากการเปลี่ยนแปลงของระบบ
UI Locators
เทคนิคเพิ่มเติมที่จำเป็นสำหรับใครที่เขียนชุดการทดสอบอัตโนมัติ ในระดับ UI ต้องทำการเข้าถึง HTML elements ดังนั้น จึงมีความจำเป็นอย่างมากที่จะต้องตั้งชื่อองค์ประกอบของหน้าจอแต่ละจุด ทีมไหนที่เจอปัญหานี้อยู่คงต้องตีฆ้องแล้วตะโกนดังๆ ว่า มาค่ะมา เรามาคุยกันเถอะ! ทีมพัฒนาทุกจะต้องมาวางข้อตกลงร่วมกันว่าเราจะมีรูปแบบการกำหนดชื่อ Attribute ต่างๆ ของเราจะเป็นอย่างไรค่ะ
ทั้งหมดที่กล่าวมานี้ เป็นหัวใจหลักและมีความสำคัญมากกก สำหรับทีมที่ต้องการจะทำให้การทดสอบอัตโนมัติเกิดขึ้นนะคะ หากอ่านแล้วมีข้อเสนอแนะส่วนไหนทักกันมาได้ค่ะ :)
ในบทต่อไปจะเป็นเรื่อง วิธีเลือกเครื่องมือที่เหมาะสมสำหรับการทดสอบอัตโนมัติ เขียนโดย Netty Chutibuat ฝากติดตามให้ครบทุกซีรีส์นะคะ :)
ขอขอบคุณข้อมูลดีๆ ที่ให้เราได้นำมาแบ่งปันกันในวันนี้
แหล่งที่มาของข้อมูล:
ชั้นเรียนออนไลน์ในหัวข้อ Chapter 3: Developing for Test Automation
จากเว็บไซต์ Test Automation University
URL: https://testautomationu.applitools.com/setting-a-foundation-for-successful-test-automation/chapter3.html
