สวัสดีครับ บทความนี้อยากจะมาแชร์ไอเดียซึ่งหลายๆ คนอาจจะมีประสบการณ์กับอะไรพวกนี้มาอยู่แล้ว แต่มือใหม่ในด้าน Automation หลายๆ คน อาจจะยังไม่รู้จัก หรือยังไม่เข้าใจว่ามันคืออะไร บทความนี้ผมจะมาอธิบายให้ฟังกันครับ
จุดเริ่มต้น
หลายๆ คนที่ทำ automation อาจจะเคยประสบพบเจอกับเหตุการณ์ว่า พอเราย้ายไปทำโปรเจค automation อันใหม่แล้วบางทีเราก็มักจะเจอกับสิ่งที่เราเคยทำไปแล้ว ยกตัวอย่างเช่น
- ตอนอยู่โปรเจค A ฉันก็ต้องทำเรื่องการ download PDF ลงมาจากหน้าเว็บ แล้วก็ทำการ verify ว่าใน PDF มีข้อความที่ระบุหรือไม่
- ตอนอยู่โปรเจค X ฉันก็เคยต้องทำการตรวจสอบว่า บนหน้าเว็บหรือหน้าแอพที่ฉันเปิดอยู่ มันมีรูปนี้แสดงอยู่หรือเปล่า (Image processing)
และเหตุการณ์อื่นๆ ในลักษณะคล้ายกัน คือ เรา หรือเพื่อนร่วมทีมของเราที่อาจจะอยู่คนละโปรเจคหรือคนละทีม ได้เจอโจทย์คล้ายๆกันมาบ้างแล้ว และสิ่งที่เราต้องการในสถานการณ์นี้ก็คือ ทำยังไงให้เราสามารถสิ่งที่เราหรือใครสักคนในองค์กรเราเคยทำมาแล้ว ให้ได้เร็ว ไม่ต้องไปเสียเวลาเหมือนทำใหม่อีกรอบ ณ จุดเริ่มต้น (แบบตั้งไข่เลยนะ) เรามักจะมีประโยคคลาสสิคที่เราส่งไปให้เพื่อน “เฮ้ยๆ ขอโค้ดหน่อยดิ” , “เฮ้ยๆ ไป copy ได้ที่ repo ไหนบ้าง” ประมาณนี้ ทีนี้ถามว่ามันก็ตอบโจทย์ที่เราต้องการได้นะ ก็คือ ไม่ต้องเสียเวลาไปทำใหม่ แต่มันก็มีข้อเสียที่ยิ่งใหญ่อยู่ก็คือ
การที่เราจะต้อง copy กันต่อๆ ไปเรื่อยๆ มันจะมีปัญหาว่า
- โค้ดมีบั้ก แล้วก็ copy ไปใช้ต่อๆ กันไปจน track กันไม่ได้ว่า ใครใช้เวอร์ชั่นมีบัค ใครใช้เวอร์ชั่นปรับปรุงแล้ว และ version ปรับปรุงแล้วก็อาจจะแตกแขนงออกไปเป็น ปรับปรุงแบบ A , ปรับปรุงแบบ B , ปรับปรุงแบบ C
- ไม่มี standard ของ feature นั้นๆ เช่น มี keyword หรือ function ที่เอาไว้ตรวจสอบ pdf พอไม่มี standard กลายเป็นในทีมหรือในองค์กรอาจจะมี คีย์เวิดที่ทำหน้าที่เดียวกัน 5–6 แบบ แต่ละแบบเขียนต่างกัน รับ argument ต่างกัน พอคนย้ายโปรเจ็คสลับที่กัน ก็จะไม่สามารถทำงานได้ต่อเนื่อง เพราะต้องเสียเวลาเรียนรู้ว่า ของทีมนี้เค้าทำยังไงนะ ไม่เห็นเหมือนตอนทีมชั้นทำ PDF เลย
Solution
จากปัญหาข้างต้นของการ copy โค้ดไปมา มันก็เลยมีไอเดียที่ใช้ได้ดีและแพร่หลาย นั่นก็คือ การทำ “Shared Library” หรือ “Shared Module” ขึ้นมาไว้ใช้ตรงกลาง ใครที่มาจากสายพวก Development จะคุ้นเคยดีกับคำว่า Don’t reinvent the wheel ก็คือ ถ้ามันมีคนสร้างล้อรถเอาไว้แล้ว พวกแกก็จงอย่าเสียเวลาไปสร้างล้อรถอีก ไปเอาล้อรถที่คนอื่นเค้าทำไว้แล้วมาใช้ประกอบเป็นรถไปเลย ถ้าให้ยกตัวอย่างก็เหมือนการที่คุณทำ Automate web โดยใช้ SeleniumLibrary แล้วมันก็มีคนทำ Keyword พร้อมใช้ในการ Click , Input Text อะไรมาไว้ให้แล้ว คุณก็แค่ไปหยิบมาใช้ประกอบร่างทำเป็น testcases ซึ่งสิ่งที่เราจะพูดถึงวันนี้มันก็คือการทำ Library ขึ้นมาไว้ใช้ตรงกลางแล้วแชร์กันระหว่างทีมภายในบริษัท ใน Doppio เราเรียก Library นี้ว่า Doppio Common Library (แต่ในบริษัทไม่มีใครเรียกชื่อนี้เลย เพราะมันยาว มันจะถูกเรียกติดปากว่า “Dobby”) , สำหรับ concept ของ Dobby นั้นก็ simple เรียบง่ายมากก็คือ มันจะเป็น Library ที่คนในบริษัท สามารถทำการ pip install ลงมาในเครื่องได้ง่ายๆ เหมือนพวก SeleniumLibrary และข้างในก็จะมี keyword ที่จะต้องใช้กันบ่อยๆไว้มากมาย เพื่อให้คนที่เอาไปใช้ ใช้งานได้เลยไม่ต้องเสียเวลาไปทำเอง
หลักการทำงานของมันคือยังไง
จริงๆ หลักการทำงานของมันก็ง่ายๆ เพราะมันก็เป็นแค่ Code ชุดนึง ที่ประกอบไปด้วย Python กับ Robot framework และเอาไปไว้บน repository ที่ใดที่หนึ่งเอาไว้เก็บชุดของโค้ด สิ่งที่อาจจะยากขึ้นมาหน่อยคือพยายามทำให้มี workflow ในการทำงานที่เมื่อมีการออกเวอร์ชั่นใหม่ ไม่ว่าจะเป็นการแก้บัค หรือเพิ่มฟีเจอร์ใหม่ๆ แล้วเราสามารถจัดการมันได้อย่างเป็นระเบียบและใช้เวลาน้อยที่สุด จึงได้ออกมาตาม workflow การทำงานด้านล่าง
- เริ่มต้นจากสมาชิกคนใดก็ได้ของ Doppio เกิดไอเดียขึ้นมาว่า อยากจะเพิ่มฟีเจอร์นี้ลงไปใน Dobby project หรือ ไปเจอว่ามีบัค และอยาก contribute เพื่อแก้บัคนั้น สมาชิกคนนั้นก็ clone source code ทำการแก้ไข แล้วเปิด Merge request มาเหมือนการทำ automation ทั่วไป
- ตัว Automated unit test จะทำการรันเทสโดยอัตโนมัติเพื่อตรวจสอบว่า changes ที่ทำการเพิ่มลงไปนั้นไม่ได้ไปทำให้ฟีเจอร์ใดๆ มีปัญหา
- หลังจากนั้นโค้ดจะถูกรีวิวโดย Tech lead ทั้งในแง่ของการตั้งชื่อ keyword การใส่ Unit test รวมถึง Description ที่จะถูกเอาไป Gen เป็น keyword documentation
- เมื่อ Code review ผ่าน โค้ดจะถูก merge เข้าสู่ branch หลักและหลังจากนั้น Jenkins จะทำการ trigger การ auto build bundle package โดยอัตโนมัติ (ถ้าใครไม่เข้าใจคำว่า bundle package ให้คิดง่ายๆ ว่า คือ package ที่พร้อมให้คน pip install ลงไปใช้)
- หลังจากที่ตัว bundle package ถูก build แล้ว จะถูกนำไปวางไว้ที่ private central repository โดยมีเลข version ที่ถูก auto increase และรอการดาวน์โหลดไปใช้งาน
- นอกจากนี้ตัว Jenkins จะทำการส่ง Slack notification ไปเพื่อประกาศให้ทุกคนในทีม /บริษัทรู้ว่า มี Dobby version ใหม่แล้วน้า มีฟีเจอร์อะไรใหม่ เพื่อให้ทุกคนมี visibility ร่วมกัน
- และตัว Jenkins ยังจะมีการทำ Keyword document โดยอัตโนมัติ และ publish ขึ้นสู่หน้าเว็บเพื่อเป็น Reference สำหรับคนใช้งาน ถ้าใครอยากดูว่าตัว Document หน้าตาเป็นยังไง ก็ลองไปดูได้ที่ https://doppiotech.gitlab.io/dobbycommonlibrary/
ปล: ตอนนี้เรายังไม่ได้เปิดรับ contributor จากข้างนอก และ ยังไม่ได้เปิดให้บุคคลทั่วไปสามารถ download dobby ได้นะครับ แต่ก็มีโอกาสในอนาคต
ข้อดี / ข้อควรระวัง
ข้อดี
- แก้ปัญหาโค้ดกระจัดกระจาย copy โค้ดกันไปมา โค้ดบินว่อนทั่วบริษัทได้เป็นอย่างดี
- มี Process ในการ release version ใหม่ เพื่อช่วยสร้าง visibility ให้กับทั้งทีม/องค์กร พร้อมทั้ง Document ที่ช่วยให้ผู้ใช้นำไปใช้งานได้อย่างสะดวกและเป็นระเบียบ
- เพิ่ม Speed ในการทำงาน โดยเอาเวลาไปทำงานอย่างอื่นที่สร้าง Value มากกว่าการทำงานซ้ำซ้อนกับสิ่งที่เคยมีคนในทีม/องค์กรได้ทำไปแล้ว ★
ข้อควรระวัง
- Process การทำ Automated unit test / การรีวิวโค้ดควรจะต้องถูกออกแบบมาอย่างดีและมีคุณภาพ เพราะการที่มีโค้ดที่เสียหายหลุดเข้าไปใน main branch สามารถกระทบกับหลายโปรเจคได้ในวงกว้าง
- ควรต้องมีการพยายามกระจายและให้หลายๆ คนได้มีโอกาสเป็น contributor เพื่อฝึกฝน skill และหลีกเลี่ยงการที่คนในทีมไม่ได้เรียนรู้และหยิบของสำเร็จรูปมาใช้อย่างเดียว
สำหรับบทความนี้ตอนนี้ก็เริ่มยาวแล้วเลยขอจบไว้เพียงเท่านี้ก่อนนะครับ ถ้าเพื่อนๆ พี่ๆ น้องๆ ท่านใดมีคำถามหรืออยากจะแลกเปลี่ยนความรู้กันก็ยินดีมากๆ ครับ และถ้าใครสนใจอยากลองทำงานใน environment แบบนี้ ก็ติดต่อมาได้ที่ careers@doppiotech.com ได้เลย เรายังรับ Full stack QA automation engineer อีกหลายตำแหน่งจ้า วันนี้ลาไปก่อน ขอบคุณที่ติดตามคร้าบ
