KBTG: AUTOMATION TECH THE SERIES

[Automation Tech the Series] Ep.8 M&M Automation Framework

Tawannay Gond
KBTG Life
Published in
5 min readDec 8, 2023

--

Final chapter of Automation Tech the Series, concluding everything and moving forward :)

อีพีนี้จะเป็นอีพีสุดท้ายที่เราจะมาแชร์เกี่ยวกับ Test Automation Framework ที่พวกเราใช้งานใน KBTG ซึ่งจะรวบรายละเอียดต่าง ๆ ที่ได้เล่าไปในอีพีก่อน ซึ่งทุกคนสามารถกลับไปอ่าน Automation Tech the Series เพื่อเป็นการรีแคปก่อนได้ที่นี่ หรือเข้าไปที่ KBTG Life แล้วค้นหาด้วย “KBTG: AUTOMATION TECH THE SERIES”

หรือถ้าพร้อมอยู่แล้ว ก็ไปอ่านกันเลยย 😆

เรามาถึงจุดหมายของเราแล้ว DEADLINE!!

Test Automation Framework คือแนวทางในการกำหนด Standard ที่ทำให้การเขียน Test Script และการจัดการสิ่งต่างๆ ที่ใช้ประกอบการทำ Test Automation ทำได้ง่ายขึ้น (เช่นพวก Test Data, Config) โดยส่วนใหญ่มุ่งเป้าไปที่ลดการเขียนโค้ดซ้ำกับบำรุงรักษาโค้ดได้ง่าย

ซึ่งจากข้อมูลหลาย ๆ แหล่ง เขาก็บอกว่าการสร้าง Framework ไม่ได้มีข้อบังคับว่าต้องมีอะไรเป็นพิเศษ เป็นแค่แนวทางที่ช่วยลดความซับซ้อนและทำให้การเขียน​ Test Script ง่ายขึ้น จึงเป็นเหตุผลที่ว่าไม่มี Framework อะไรที่ดีที่สุด การทำ Test Automation นั้นแตกต่างกันออกไปในแต่ละองค์กร ขึ้นอยู่กับความต้องการของใครของมัน

อย่างใน KBTG เรามี App และทีมเต็มไปหมด เราอยากให้การทำ Test Automation เกิดและเป็นไปในทิศทางเดียวกัน มี Standard เดียวกัน เลยเป็นที่มาของ M&M (Multi-level & Modular Scripting) Automation Framework

เพื่อไม่ให้เสียเวลา ไปดูกันเลยว่าเราทำอะไรใน Framework บ้าง

Standard

อย่างที่บอกว่า KBTG เรามีจำนวน App ภายในที่เยอะ(มาก) ทุกตัวต้องการทำ Test Automation เพื่อเพิ่ม Test Coverage ไม่ให้ Bug หรือ Defect หลุด การที่เราจะดูแลทุกแอปได้ (ปล. ผมเป็นทีมกลาง) เราต้องทำให้การทำ Test Automation เป็นไปในทิศทางเดียวกัน ดังนั้นเรามีการทำ Standard ต่าง ๆ มาครอบในการทำงาน ได้แก่

Project Structure 🏢

เราจะจัดวางโครงสร้างโฟลเดอร์และไฟล์โดยคำนึงถึง Standard Tool ที่ใช้ทำ Test Automation และเอื้อต่อการดึงไฟล์ต่าง ๆ ไปใช้งาน เช่น ดึงไปทำ Documentation หรือใช้ค้นหาเพื่อนำโค้ดพวกนี้กลับมาใช้ใหม่ในอนาคต ซึ่งเรื่อง Project Structure สามารถกลับไปอ่านได้ที่ Ep.1 😉

Tag 💲

การจัดการ Project Structure ยังไม่เพียงพอ เรามีการใช้เรื่อง Tag เพื่อช่วยดูในเรื่อง Classified Information ของ Test Script เพิ่ม เช่น Test Level, Feature, Function เอาไปใช้ทั้งเป็นข้อมูลการทำ Test Automation ของ App ใน องค์กร หรือใช้ในมุมการ Execute อย่างใน Robot Framework ก็จะมีวิธีใส่ Tag แบบตัวอย่างโค้ดด้านล่าง

*** Settings ***
Test Tags requirement: 42 smoke

*** Variables ***
${HOST} 10.0.1.42

*** Test Cases ***
No own tags
[Documentation] This test has tags 'requirement: 42' and 'smoke'.
No Operation

Own tags
[Documentation] This test has tags 'requirement: 42', 'smoke' and 'not ready'.
[Tags] not ready
No Operation

Own tags with variable
[Documentation] This test has tags 'requirement: 42', 'smoke' and 'host: 10.0.1.42'.
[Tags] host: ${HOST}
No Operation

Set Tags and Remove Tags keywords
[Documentation] This test has tags 'smoke', 'example' and 'another'.
Set Tags example another
Remove Tags requirement: *

ซึ่งตัวนี้เป็น Standard ใน Framework เราจะไม่ได้โฟกัสไปที่ Tool เดียว ในเคสนี้ต้องมีวิธีการใส่ Tag ให้กับทุก ๆ Standard Tool ด้วย แต่ Tag ที่ใส่จะต้องเป็น Standard เดียวกัน

Metadata 📜

เพื่อให้ติดตามการทดสอบง่ายขึ้นและเป็นระเบียบ Framework เราจะซัพพอร์ตการจัดเก็บ Metadata หรือ Information อื่นแนบตามเข้าไปด้วย เช่น Commit ID, Application Version, Executor, ฯลฯ

Image Ref: dataedo.com

Versioning 🏷️

เนื่องจากเราไม่ได้ทำ Test Automation ครั้งเดียวแล้วจบ (ยกเว้น Application คุณไม่ได้ไปต่อ) เราจะมีการวาง Standard จัดการเรื่อง Version ของ Test Script ไว้ (แล้วแต่จะตกลงกัน) ซึ่งมันจะถูกนำมาใช้ในการ Execution หรือ Rollback

Image Ref: Simon Maxen

Naming Convention 🔠

กำหนดวิธีการตั้งชื่อสิ่งต่าง ๆ ไม่ว่าจะเป็นตัวแปร Keyword, Test Name ยาวจนถึง Job และ Pipeline เป็น Guideline เพื่อที่จะช่วยจัดให้ทุกคนสามารถเข้าใจสิ่งต่าง ๆ ในการทำ Test Automation ตรงกัน และใช้ประโยชน์ในการจำแนก Test Automation ไปใช้งานต่อ (ซึ่ง Tool บางตัวก็มี แต่ว่ามันไม่เพียงพอ 😩)

อย่างในตัวของ Robot Framework (robotframework-style-guide) เขาก็จะมีการตั้ง Guide สำหรับ Style ในการเขียนกับ Naming Convention สามารถดูตัวอย่างเบื้องต้นแล้วนำไปปรับใช้ได้

Version Control / Source Control 📂

จะพูดในมุมของการทำ Branching (Git Flow) และ Repository ที่เก็บ Test Script เนื่องจากเราอยากจะจัดการทั้งเรื่อง Permission และที่อยู่ให้สอดคล้องกัน เป็นรูปแบบเดียวกันในทุก ๆ แอป เพื่อให้การคุมเรื่องของ Permission จัดการได้ง่าย โยงไปถึงการ Integration กับระบบอื่น ๆ ใน Ecosystem ได้ง่ายขึ้นถ้ามีการจัดการ Permission ที่ดี

Image Ref: siliconangle.com

Standard Tool 🔨

นอกจากการวาง Standard ด้านบน เรามีวาง Standard Tool ที่เป็น Tool พื้นฐานสำหรับการพัฒนา Test Automation ใน KBTG โดยประยุกต์ Standard ด้านบนให้ใช้งานใน Tool เหล่านี้ด้วย เกณฑ์ที่เราใช้ในการเลือก Tool เหล่านี้คือต้องตอบโจทย์ครอบคลุมทุก Application Characteristics ของ KBTG ได้ สามารถซัพพอร์ตได้ทั่วถึง และสุดท้ายคือเหมาะกับคนใหม่ ๆ ที่เพิ่งมาจับ Test Automation

Modular Approach

ส่วนนี้จะถือว่าเป็นหนึ่งใน Standard ก็ได้ แต่ที่แยกออกมาเพราะมันเป็นแกนหลักอีกแกนของ Framework ที่เราโฟกัสเป็นพิเศษ เราอยากให้ Test Script สามารถนำมา Reuse ใช้เป็น RPA (Robotic Process Automation) หรือ Script สำหรับ Prep Data ซึ่งจะต้องวางวิธีการเขียนโค้ดให้แยกออกจากกันเป็นสองส่วน คือ Control (Interact กับ App อย่างเดียว) กับ Verify แล้วดึงเฉพาะส่วนกลับมาใช้

Multi-Level (Extensible)

เราอยากให้ Automated Test Script ที่เราเขียนขึ้นมาสามารถนำกลับมาใช้ใหม่ได้ เช่น Test Script ในระดับ System Test สามารถนำมาประกอบกันกับ Test Script ของ App อื่น เพื่อให้เกิดเป็น SIT Test หรือ End-to-End การทำในส่วนนี้จะถูกเตรียมการมาแล้วใน Standard (Tag) ส่วนถัดมาคือเราต้องจัดการวิธีการ Run Test Automation อยู่ในรูปแบบเดียวกันและแบ่งตาม Application ได้ ซึ่งก็จะดึงความสามารถของ CI/CD เข้ามา

Img Ref: freecodecamp.org

CI/CD 🚀

ใน M&M Automation Framework เราจะให้ทุกโปรเจคที่ทำ Test Automation มารันเทสบน CI/CD (ณ ปัจจุบันเราใช้ Jenkins) ทำให้เราจัดการกับการรัน Test Automation รัน Parallel ได้ สามารถวาง Option ต่าง ๆ ส่วนนึงก็เพื่อ Selective Test Case มารันได้

เราได้มีอธิบายเรื่องของ CI/CD และ Jenkins ไว้ยิบ ๆ ที่ Ep.4 😉

พอได้ภาพด้านบนแล้ว ใน Framework เรามีโปรแกรมตัวนึงมาควบคุมการหยิบภาพด้านบนมาร้อยเรียงเป็น Scenario จาก Test Automation ที่เราเคยทำมา เช่น ถ้าเราจะทำการทดสอบ End-to-End ปรึกษากันแล้วว่า System Test Script ของ App ที่เป็นส่วนประกอบมีของพร้อม และมั่นใจว่า Environment กับ Test Data สอดคล้องกัน เราสามารถให้โปรแกรมปั้น End-to-End Test Automation ขึ้นมาตามภาพด้านล่างได้

แต่การจะทำให้ได้ภาพนี้ต้องทำให้ Support Tool แต่ละตัวสามารถ Passing ข้อมูลข้ามกันได้ มีวิธีจัดการ Test Result ของแต่ละ Tool จัดการการสรุปผลของ Scenario ที่ปั้นขึ้นมาและอื่น ๆ อีกมากมาย

Reporting & Logging

วนกลับไปเรื่องเดิมที่จำนวน App ใน KBTG เรามีเยอะ และเรามีทีมอย่าง SQM (Software Quality Management) ที่คอยดู Quality โดยรวม ทำให้เราจำเป็นต้องเก็บ Report กับ Log ของการทำ Test Automation โดยละเอียดและซัพพอร์ตเป็นข้อมูลที่เอาไปวิเคราะห์ต่อได้ นั่นหมายความว่าข้อมูลเราจะต้องเก็บทั้งหมด การที่จะทำให้ Framework เราเก็บข้อมูลเหล่านั้นได้ จะต้องขยายตัวเองไป Integrate เข้ากับระบบอื่น ๆ ใน Ecosystem ของ KBTG

Documentation

ใกล้เคียงกับ Reporting & Logging ตัว Framework เรามีการจัดเก็บรายละเอียดของ Test Script ที่มีใน KBTG ไว้ทั้งหมดด้วย ซึ่งการที่เราจะเก็บข้อมูลได้ ก็จะมาจากการที่ทุกคนมี Standard เดียวกัน เราสามารถใช้เป็นเอกสารเก็บเป็นข้อมูลไว้ช่วยภาพ Multi-level ด้านบน ซึ่งส่วนหนึ่งของ Documentation ใน Framework คือตัว Automation Catalog ใน Ep3. ถ้าสนใจก็เข้าไปดูกันต่อได้ 😆

Reusable Libraries & Tools

ในบางครั้งที่เราทำ Test Automation แล้วเห็นว่ามีโค้ดบางส่วนที่ถูกเรียกใช้ใน App อื่น ๆ (Common Function) เราจะหยิบโค้ดเหล่านั้นมาเกลา ถ้าเป็นโค้ดที่นำมาเสริมในการทำ Test Script เราจะสร้างเป็น Shared Library แต่ถ้าเป็นโปรแกรมที่รันเพื่อเตรียมการบางอย่างก่อน เราก็จะสร้างเป็น Shared Tool และแชร์กันใช้ในองค์กร

เช่น เราทำ ExtendedDatabaseLibrary ที่เพิ่ม Connection Database อื่นเสริม

ซึ่ง Framework จะคุมเรื่อง Guideline ในการสร้าง และทำให้มัน Compat กับ Standard Tool ที่เราซัพพอร์ต ซึ่งไปอ่านต่อได้ใน Ep.2 เราทิ้งไว้ที่นั่นเกือบหมดแล้ว

จุดที่เราโฟกัสหลัก ๆ ใน Test Automation Framework ของเรามีประมาณนี้ ส่วนที่เหลือ เช่น การจัดการ Test Data Configuration ฯลฯ ลองหาอ่านจากที่อื่นเสริมได้ จะไม่ต่างกันมาก แต่ถ้าใครอยากรู้ว่าเราทำยังไง หรืออยากรู้ละเอียดเพิ่มในจุดไหนเป็นพิเศษ สามารถทิ้งคอมเม้นต์บอกเราได้

ส่งท้าย… อย่างที่บอกไปตอนต้น ไม่มี Framework ไหนดีที่สุด แต่เราสามารถหยิบโน่นจับนี่มาพัฒนา Framework ให้เหมาะสมกับการทำงานขององค์กรเราได้ ถ้ามีจุดผิดพลาดตรงไหนก็ขออภัยมา ณ ที่นี้ 🙇‍ ️หวังว่า Framework นี้จะชี้แนะแนวทางให้กับทุกคนที่เข้ามาอ่านได้นะครับ

เจอกันเมื่อเราเจอกัน กับ Automation Tech the Series ⚓️

สำหรับชาวเทคคนไหนที่สนใจเรื่องราวดีๆแบบนี้ หรืออยากเรียนรู้เกี่ยวกับ Product ใหม่ๆ ของ KBTG สามารถติดตามรายละเอียดกันได้ที่เว็บไซต์ www.kbtg.tech

--

--