เขียน Code เก่ง ใช่ว่าจะทำ Test Automation ได้ดี
บทความนี้เขียนสำหรับน้องๆสาย Automation หรือน้องๆที่กำลังศึกษาเพื่อก้าวเข้ามาในสาย Test Automation นะครับ เท่าที่เห็นส่วนใหญ่ๆเวลาเริ่มศึกษาหรือทำงานไปซักพัก เราจะ focus อยู่แค่ ใช้ framework อะไร ใช้ภาษาอะไรเขียน แล้วก็ไปเรียนการเขียนภาษานั้นๆ พอเรียนพอฝึกไปซักพัก เขียนได้คล่องก็ อุ๊ย เก่งแล้วเรา เขียน Automate ได้หล่ะ ของ web หรือ mobile app ผมได้หมด ส่งงานมาเลยพี่ ผมพร้อม!
เอาจริงๆ ถ้ามาได้ถึงขั้นนี้ ก็ควรภูมิใจจริงๆหล่ะนะ แต่ว่า ถ้าหยุดอยู่แค่นี้ เราก็ทำได้เหมือนคนอีกหลายพันหลายหมื่นคน (และคนหลายพันหลายหมื่นคนที่ทำระดับนี้ได้ กำลังเพิ่มขึ้นเรื่อยๆทุกวัน) จากประสบการณ์ที่เห็นมา คนที่ทำ Automate ได้เจ๋งเนี่ย เขียน code/script automate ได้ คือ พื้นฐานที่จำเป็นต้องมี แต่บทความนี้จะพยายามเล่าถึงส่วนอื่นๆที่จะทำให้เราก้าวไปอยู่ในระดับถัดไปได้ให้ฟังละกันนะครับ
ยกตัวอย่าง ถ้าเรามี website ซื้อของ online ตัวนึง ซึ่งระบบหลักๆคือ 1. ตัว Web หน้าบ้านให้ลูกค้าซื้อของได้ และมี 2.ระบบหลังบ้านที่ให้พนักงานของ web นั้นสามารถ process order จากหน้าบ้าน และ support ลูกค้าได้ จากตัวอย่างนี้ เรามาลองจัดกลุ่ม level การทำ automation ในแต่ละระดับกันดูเนอะ
Level 1 : Automation ฝึกหัด
เป็นระดับเบื้องต้น ถ้าจะเขียน Test ของหน้าบ้าน ก็จะเขียน UI test (จะใช้ robot framework, selenium, cypress หรืออะไรก็แล้วแต่) เพื่อ simulate customer flow/scenario ไปเรื่อยๆ โดยส่วนใหญ่จะเขียน step ตาม test case manual ที่มีคนคิดมาให้แล้ว ส่วนใหญ่ใน level นี้จะเขียน test เพื่อ validate flow การทำงานต่างๆของระบบ แต่มีการทำ data validation ได้แค่ระดับเบื้องต้นเช่น เช็คว่า ราคาที่โชว์ในหน้าต่างๆบน web นั้นมีค่าเท่ากันก็จะประมาณนี้
Level 2 : Automation ใช้งานได้
คนกลุ่มนี้จะสามารถแปลง test case manual มาเป็น test automation scenario/flow ได้ ทำให้เป็น data driven test ได้ เขียน script น้อยลง test coverage มากขึ้น และ test script maintenance ง่าย นอกจากนี้ ยังสามารถคิด flow ของ automate ให้สามารถไปดึงข้อมูลจากที่ต่างๆมา validate data ที่ display บน application ได้ เช่น ไปยิง api หรือไป query database เพื่อเอาข้อมูลมาเทียบว่า ราคา หรือ promotion ที่มา display หน้าบ้านนั้น เอาค่าที่ถูกต้องมา display รึเปล่า
Level 3: Automation มากประสบการณ์
พวกนี้ส่วนใหญ่เจ็บมาเยอะ ก็เลยจะมีประสบการณ์ว่า การทำ test automation ไม่ใช่แค่เขียน script เสร็จแล้วจบ งานยากจริงๆ ของ Test automation คือการ maintain มัน ไม่ใช่การเขียนขึ้นมาตอนแรก
คนที่ทำ automation มาซักพักจะได้ยินคำว่า Test flakiness จนอยากจะร้องไห้ สำหรับมือใหม่อธิบายง่ายๆ Test flakiness (flaky test) คือ อาการประมาณว่า Test fail แต่ไม่ใช่จาก bug ของ software ที่เรากำลัง test นะ แต่เกิดจาก test เอง ไม่ว่าจะเพราะ test environment, test script หรืออะไรก็แล้วแต่สารพัดสารเพ สรุปคือ ถ้ามี test flakiness เยอะๆ automate test ของเราก็จะไร้ค่า เพราะเป็นสิ่งที่พอ run แล้ว fail จะไม่มีใครคิดว่าเจอ bug จริงๆแต่จะ assume ว่าเป็นที่ test พังเอง ก็สั่ง rerun หรือเลิกใช้ไป (ทั้งๆที่อุส่าห์สร้างมาตั้งนาน)
ทีนี้ พวกคนที่ทำ automation มากประสบการณ์เนี่ย พอเจ็บกับเรื่องพวกนี้เยอะ ถ้าเรียนรู้และหาทางแก้ไขได้ก็จะเข้ามาอยู่ในกลุ่มนี้ ความแตกต่างคือ จะเป็นคนที่เริ่มตั้งแต่การ design test architecture ให้ดีก่อนเริ่มเขียน code ถ้าจะเจ๋งคือแบ่ง level test ให้ได้ตามหลัก test pyramid เอา test logic ส่วนใหญ่ และพวก negative test ไปอยู่ใน unit test (ให้ test level นี้เยอะสุุด, ทำ test api เช็ค function เยอะรองลงมา เหลือ test UI ให้น้อยๆ อันนี้ไปหาอ่าน test pyramid เอานะ น่าจะมีคนเขียนเยอะหล่ะ) พอแบ่ง test level เสร็จ ตัวร้ายสุดคือ UI test เนี่ย ก็ต้องแบ่งให้ดี ถ้าสามารถแบ่งเป็นข้อสั้นๆ independent ในตัวได้ (ข้อดีคือ ยิ่งสั้น โอกาส flaky ยิ่งน้อยและสามารถ execute test parallel ได้ด้วย) แต่ก็ต้องมีข้อ flow ยาวๆ บ้างเพื่อ check end to end customer experience
คนกลุ่มนี้ถ้าเจ๋ง จะสามารถเขียนดัก exception ต่างๆ ของ failure เพื่อทำ auto retry ได้ (อันนี้ที่เคยทำช่วยได้เยอะ คือแบบ ถ้า exception แบบนี้ คือพังเพราะ test แน่ๆ สั่ง auto retry ให้เลยในข้อนั้นๆ เช่น พวก web driver ตาย ประมาณว่าใส่ whitelist ของ error ไว้ให้) นอกจากนี้ คนกลุ่มนี้ยังสามารถคิดมุขต่างๆเพื่อช่วย stability ของ test environment ได้ด้วยเช่นการเอา dynamic mock framework ต่างๆมาใช้ หรือถ้าเป็นเทพด้าน dev ops ด้วยก็สามารถก้าวไปเล่นกับ environment on demand เช่น docker / k8s framework ต่างๆได้
ระดับนี้จะเห็นว่า ก้าวกระโดดจากสองระดับแรกค่อนข้างเยอะนะ คือเป็นกลุ่มคนที่ ถ้าบริษัทไหนเจอ แล้วมีตังค์ก็จ้างเหอะ เก่งและหายากทำงานได้แน่นอน และทำงานออกมาแบบใช้ได้ยาวๆ ส่วนถ้าใครทำได้ระดับนี้ก็เลือกงานได้สบายๆ เป็นตัว top ของ market หล่ะ แต่เอ๊ะ มันยังมีขั้นกว่าอีกเหรอนะ?
Level 4: Automation เทพ อันนี้อธิบายยาวหน่อย จริงๆอ่านแค่ย่อหน้าแรกให้เห็น idea ก็พอที่เหลือคือแค่พยายามยกตัวอย่างให้เห็นภาพ
คนกลุ่มนี้ ต้องทำระดับก่อนหน้าได้หมด และสิ่งที่เพิ่มเข้ามาคือ strategy ในการ ออกแบบ framework กับ flow เพื่อให้สามารถ implement automation ออกมาได้โดยใช้เวลาน้อยที่สุด หรือก็คือการ design framework/flow ให้ efficient นั่นเอง (Level ก่อนหน้าจะเห็นว่า หลักๆคือ optimize เพื่อความ effective ให้ automation ทำงานได้ดีเป็นหลัก โดยไม่ได้พูดถึงการทำให้ efficient มากนัก)
อธิบายยากหน่อย แต่จะพยายามค่อยๆยกตัวอย่างนะ อย่างโปรดัคล่าสุดที่พยายามทำ automation เนี่ย ซึ่งในกรณีนี้ไม่สามารถ control dev ให้เขียน unit test ได้ เลยต้องทำ test ในเลเวลสูงๆเยอะหน่อย ซึ่ง automation ฝั่ง customer facing เนี่ยง่าย ก็ design UI automation ให้มีทั้งข้อสั้น(เยอะๆ) และข้อยาว(น้อยๆ) ทำ framework ให้ run parallel เพื่อลดเวลา มีการ query data จาก db และ api มา validate data ปกติทั่วไป
ความยากมันอยู่ที่ตัว product หลังบ้านที่ operation team ใช้ คือมันต้องรองรับ scenario หลากหลายจากหน้าบ้านและ operation หลากหลายหลังบ้านเช่น ถ้าลูกค้าซื้อมาด้วย flow นี้แล้วจะ cancel order ซึ่งการ cancel ก็ทำได้หลายจุด ก่อนส่ง หลังส่ง ตอนส่ง บลาๆ สรุป ออกมาร่วมร้อย scenario แค่นั้นยังไม่พอ แต่ละ scenario ต้องมีการเช็ค report หลากหลายทั้ง PDF และ Excel ซึ่งเมื่อคูณจำนวน scenario ออกมาแล้วก็ออกมาร่วมๆ 500 report ได้ (ทุก report มีความ unique ของตัวเองในแต่ละ scenario ที่เกิดขึ้น) ฟังๆดูก็ปกติเนอะ ทุกๆระบบก็ต้องทำงี้แหล่ะ ก็ทำ automation implementation plan มา ใช้เวลาเขียนประมาณ 6–7 เดือน… พอเห็นเวลา หัวหน้าบ้าบอคนนึงก็พูดขึ้นมาว่า รอ 6 เดือนไม่ได้อ่ะ ทำยังไงให้ได้ใน 2–3 อาทิตย์มั่ง ทีนี้ก็มา brainstorm ไอเดียกันว่าจะไปท่าไหนได้มั่ง ฝั่ง create order จากหน้าบ้าน (ให้มองเป็น test input ของการ test product หลังบ้าน) เนี่ยง่ายหน่อย ก็ยิง api สร้าง order เอาเลยแทนการเขียน UI create order จากหน้าบ้านร้อยกว่า scenario
ส่วนการ test web หลังบ้าน หลักๆเปลี่ยนมา test ด้วย api level แทน ui (เหลือ ui ไว้ สิบกว่าข้อเพื่อ ensure integration ระหว่าง api กับ ui) ทีนี้การทำ api test เพื่อ drive flow แต่ละข้อเนี่ยตกออกมาข้อละประมาณ 60 steps ของทั้ง post/get ซึ่งอันนี้คืองานช้าง เพราะจะเช็คว่าข้อมูลที่ระบบ response กลับมาในทุกๆ field มันถูกรึเปล่าเนี่ย งานถึกมหาศาล ให้ ลองมโนตามนะ สมมติ test case ข้อนึงคือ ซื้อสินค้าเนื้อไก่ 1.25 กิโล (ซึ่งชั่งเป็นกิโล) และ มาม่า หนึ่งแพค จ่ายเงินด้วย credit card แล้วลูกค้ามา return สินค้าตอนส่งของ ซึ่งสิ่งที่ return คือ เนื้อไก่ 0.65 กิโล ซึ่งการ return นี้เกิดขึ้นจาก application ที่ให้คนขับรถส่งของใช้ เอาง่ายๆแค่นี้ซึ่งจะต้องมี operation จำนวนนึง ที่เกิดขึ้นบน application มีการ click โน่นนี่เพื่อ return และส่งไป flow ถัดไป และข้อมูลมากมายบนหน้าจอที่ต้อง validate เช่นจำนวน return ถูกรึเปล่า ราคาใหม่หลัง return ถูกมั๊ย ต้องคืนเงินลูกค้าเท่าไหร่ vat คำนวนใหม่มั๊ย มี point ต้องคืนหรือตัดเพิ่มเท่าไหร่อะไรพวกนี้ แค่ข้อเดียวก็ดูตาลายตอน test manual ซึ่งของพวกนี้ถ้าทำ automate ui ก็ไล่เช็คไป ทุกค่าที่ display บน screen ต้องใส่สูตรคำนวณให้ถูกด้วยนะ (เหมือนเขียน app เองงิ) พอคูณจำนวนข้อก็จะได้ effort ครึ่งปีในการทำ ถึงจะเช็คใน level api แทน UI ก็ต้อง validate ค่าต่างๆเยอะแยะมากมายอยู่ดี
ในส่วนนี้ เราก็คิด solution ขึ้นมาได้อันนึงคือ เทียบไฟล์ response ที่ได้จาก api เอาเลย ก็คือ รันเทส manual ก่อนรอบนึง เช็คทุก detail ว่าถูกต้องหมด แล้วเก็บ file response นั้นเป็น benchmark จากนั้นเขียน script replace dynamic data ต่างๆพวก order id, date, time ให้เป็นของ update ในแต่ละรอบของการรัน แล้วเวลารันเทสก็ compare ข้อมูลผลเทส กับ benchmark เลยจ้าา ด้วยวิธีนี้ ลดเวลา implement ลงมาได้ ประมาณ 3 เดือนใช้เวลาเขียนสคริปตัด xml กับ json นิดหน่อยเพื่อ manage value ที่เป็น dynamic ต่างๆ
งานช้างถัดไปคือ report ทั้ง excel และ pdf คร่าวๆคือ ใช้มุขเดียวกัน แทนที่จะเขียน automate มาอ่านค่าแต่ละ field แล้วคำนวณ หรือใส่ condition ว่าค่าต่างๆควรเป็นอะไร ซึ่ง report 500 กว่าอันมีค่าต่างกันหมดตาม scenario ที่ทำ test สิ่งที่เราทำคือ generate report ที่ถูกต้องมาหนึ่งรอบ เก็บเป็น file benchmark (500 files) คือค่าต่างๆใน report ของ แต่ละ test case จะเท่ากันหมดทุกครั้งที่ run เพราะเรา create order ด้วย automate และ drive action (เช่น cancel, return, etc) ด้วย automate ก็คือการทำซ้ำๆ ส่วนที่ต่างคือค่า dynamic บางค่าเช่น order id, date, time ซึ่งก็เขียน script มา handle พวกนี้เอา ในส่วนของ pdf เนี่ย ก็ convert เป็น excel ใช้ script กับ framework เดียวกันจัดการได้เลยเย่ สรุป งาน 6 เดือน น่าจะเสร็จด้วยเวลา 2-3 อาทิตย์
อันนี้ก็บอกไม่ได้หรอกว่ามันคือ best solution เพราะมันคงมีวิธีที่ดีกว่านี้แหล่ะ แต่มันก็เป็นสิ่งที่ลดระยะเวลาจาก 6 เดือน เหลือ 3 อาทิตย์ได้ซึ่งเป็นผลลัพย์ที่ amazing เลยหล่ะ เอาจริงๆแล้วมันก็คงมี level ที่สูงกว่านี้อยู่หลายระดับ แต่คือ ตอนนี้เห็นอยู่แค่นี้อ่ะ 5555 เอาเป็นว่า บทความนี้มาจากความเห็นและประสบการณ์ส่วนตัวล้วนๆ มิได้มีหนังสือหรือบทความอันใดมารองรับ
สรุป ลองดูนะว่ายิ่ง level สูงๆ skill การเขียน code ไม่ได้เป็นจุดหลักอีกต่อไป แต่คือ skill ในการคิดวาง strategy, flow, architecture ของ automation ต่างหากที่จะใช้มากขึ้น
สำหรับน้องๆ Automation ฝึกหัด การฝึกเขียน code ให้ดีก็ยังสำคัญอยู่นะ แค่อยากจะบอกว่าให้ฝึกเปิดมุมมองด้านอื่นไว้ด้วย จะได้ก้าวไปเป็น Automation มากประสบการณ์ หรือเทพ ได้เร็ว
Doppio Tech: We Build and Serve Expertise
