คิดและเลือก automation framework อย่างไรในปี 2023
จริงถึงแม้จะจั่วหัวไว้ว่าเป็นปี 2023 แต่จริงๆหลักการนี้ใช้ได้ทุกปีแหละครับ แหะๆ ซึ่งบทความนี้ได้แรงบันดาลใจจากที่ว่า ช่วงนี้น้องๆ หลายคนที่เคยทำงานด้วยกัน ทักมาปรึกษาโน้นนี่นั่นกันอยู่เป็นระยะๆ หลายๆครั้งมีน้องบางคนเข้าไปทำงานในบริษัทที่ยังไม่มี Automation เลย พูดง่ายๆ คือการเข้าไปเริ่มตั้งไข่ให้เองนักเลงพอ และหลายคนจะกลับมาถามคำถามเดียวกัน (คำถามเดียวกันจริงๆนะ) บทสนทนาจะเป็นประมาณนี้
น้อง : พี่โอ ว่างไหมพี่
โอ : ครับ
น้อง : สบายดีนะครับ
โอ : สบายดีครับ เราล่ะเป็นไงบ้าง
น้อง : พี่โอ cypress นี่ดีไหมครับ (ไม่พูดพร่ำทำเพลง get to the point ดีมาก)
พอคุยไปคุยมา เรามักจะได้คำตอบว่า น้องได้รับมอบหมายว่าให้เริ่มต้นทำ Automation โดยเริ่มตั้งแต่เลือก Framework ไปจนถึงวาง Project structure วันนี้เลยอยากจะมาลองแชร์ว่า ปกติเวลาเราจะเลือก Framework มาใช้เนี่ยเราควรดูอะไรบ้าง แต่ก่อนจะเข้าเรื่องบอกก่อนเลยว่า มันไม่มีคำว่า “ดี” หรือ “ไม่ดี” มันมีแค่คำว่า “เหมาะ” หรือ “ไม่เหมาะ” กับ context ของเราเท่านั้นเอง
หลักๆ เวลาที่ผมเลือก Automation framework สักอันหนึ่งมาใช้ผมมักจะมองเป็นสามมุมดังนี้ครับ
- Product under test และ ลักษณะของ Test cases เป็นยังไง
- Test script contributor / implementer คือใคร
- Automation test ที่กำลังจะทำขึ้นมา เราให้ความสำคัญกับอะไรเป็นหลัก
Product under test คืออะไร
เริ่มจากอันง่ายๆ กันก่อน ส่วนใหญ่ หลายคนก็เริ่มคิดจากอันนี้แหละ เช่น ชั้นจะต้องทำ automate web ชั้นจะใช้อะไรดีนะ Cypress, Playwright, Selenium หรือพวก Puppeteer ดีนะ ถ้าจะต้องทำ Mobile ก็จะคิดว่า เราจะใช้ Appium, Espresso หรือพวก XCUITest ดี หลักๆการเริ่มแบบนี้คือถูกต้องแล้วครับ แต่สิ่งหนึ่งที่เรามักจะลืมมองไปคือ เวลาเราพูดถึง Product under test เนี้ยเราควรจะมองให้ครบทุก system ที่เราต้องไปแตะด้วย นอกเหนือจาก main product เคยมีน้องคนนึงมาถามผมว่า พี่ครับๆ ผมใช้ cypress ทำ automate มาได้ประมาณ 10–15% ของเทสเคสที่ต้องทำแล้ว แต่ตอนนี้เจอเคสเพิ่มเติมว่าประมาณ 20%-30% มีต้องทำ action บนหน้าเว็บ หลังจากนั้นก็ต้องไปเปิดตัว iOS Application แล้วเช็คว่า ค่าที่แสดงบนหน้า Application ถูกไหม อันนี้ทำได้ไหมพี่ ถ้ามาแบบนี้ แปลว่า ตอนเราเริ่มเลือก Framework มาใช้เราไม่ได้มองให้ครอบคลุมว่า เทสเคสของเราและ Product under test ของเรานั้นต้องการอะไร และ Framework ที่เราเลือกมาใช้นั้นมันจะตอบโจทย์ไหม และ ตอบโจทย์ง่ายหรือยากยังไง (บางทีมันทำได้แหละ แต่มันไม่ใช่ท่าปกติที่คนส่วนใหญ่ทำกัน) เพราะงั้นก่อนจะเลือก Framework อะไรสักอย่างมาใช้ มองให้รอบ มองให้ไกล มองให้ทั่ว ว่าเทสเคสทั้งในปัจจุบัน และอนาคต มันดูจะต้องไปเกี่ยวข้องกับอะไรบ้าง
Test script contributor / implementer คือใคร
อันนี้หลายๆคนชอบลืมคิด คือเราไปมองแต่ข้อแรก กับฟีเจอร์ของตัว framework ซะจนเราลืมสนว่า แล้วใครจะเขียนฟะ เช่น สมมติบริษัทเรามีนโยบายว่า QA กับ Developer จะเป็นคนช่วยทำ Automate ให้เกิดขึ้น โดย Effort dev 70% , QA 30% โดย Developer ส่วนใหญ่เชี่ยวชาญ Javascript เป็นหลัก ถ้าในกรณีนี้เราบอกว่า เราเลือก Python หรือ Robot framework มาเป็นภาษาหลักในการเขียน Automate ดีกว่า สุดท้ายมันอาจจะไม่ match กับคนที่จะมา contribute หรือกรณีคลาสสิค คือ องค์กรที่อยากจะ transform จาก manual approach to automation approach โดยก็อยากจะ keep manual QA ปัจจุบันของตัวเองไว้ พร้อมกับค่อยๆ transform ให้พวกเขาเหล่านี้ซึ่งมี product knowledge เยอะมาก ค่อยๆมาทำ automation ได้ โดยที่บางครั้ง พวกเขาเหล่านี้อาจจะไม่ได้เชี่ยวชาญ หรือ specialize ด้านการ coding มากนัก รวมถึงห่างหายจากการ coding มานาน ถ้าเราเลือก Framework หรือภาษาที่ค่อนข้างยากต่อการเรียนรู้ เช่น Playwright + TypeScript + Pattern การเขียนแบบ Promise บางทีอาจจะไม่เหมาะกับคนที่จะเข้ามาเป็น contributor ทำให้ไม่เกิดผลลัพธ์ กับเผลอๆ คนในทีมถอดใจลาออกกันไปหมด และอีกเรื่องที่คนมักจะลืมคือ ทีมของเรามันไม่ได้จะหยุดอยู่แค่เท่าที่มี อนาคตมันจะต้องมีคนเพิ่ม มีคนเข้า มีคนออก ถ้าจะ scale/replace team จะ scale/replace ได้ง่ายหรือยากแค่ไหน เคยมีน้องคนนึงมาติดต่อผมแล้วบอกว่า อยากจะหาคนเข้าไปช่วยทีม automate ของเค้าหน่อย เค้าหามาหลายที่แล้ว ผมเลยถามว่า require experience หรือ skill แบบไหน เค้าก็บอกชื่อ Framework มาตัวนึง (ซึ่งผมฟังแล้วก็ไม่รู้จัก ไม่เคยได้ยินชื่อ) ก็เลยไม่แปลกใจว่า ทำไมถึงหายาก เพราะ ในไทยไม่ค่อยมีใครนิยมใช้กัน
Automation test ที่กำลังจะทำขึ้นมา เราให้ความสำคัญกับอะไรเป็นหลัก
บางครั้งเวลาเราเลือก framework เรามักจะไปสนใจกับฟีเจอร์ทั้งหลายของมัน จนบางทีลืมสนใจสิ่งที่เราอยากจะให้ความสำคัญกับมันจริงๆ เช่น บางทีเราเห็นว่า framework นี้มีฟีเจอร์จำลอง network ได้ด้วยนะ simulate ว่ามันเป็น 3G, 4G ,5G , etc ได้ จัดการกับ Shadow dom ได้ด้วย และความเร็ว เร็วกว่า framework คู่แข่งตั้ง 10–15% แหน่ะ จนบางทีเราจะรู้สึกว่า ว้าว นี่มันสุดยอดไปเลยนิหว่า (โดยเฉพาะคนที่ tech guy หน่อยจะชอบเป็น เพราะผมก็เป็น) ตาลุกวาว แล้วรู้สึกว่า นี่แหละ the new future of industry มัน cool มันล้ำ มันมีฟีเจอร์ chic chic มากมาย จนหลายครั้งที่ผมกำลังตาลุกวาวอยู่แล้วโดนถามว่า “แล้วไงนะ ได้ใช้เหรอ” หรือว่า “แล้วไงนะ แล้วพี่หรือบริษัทหรือ ลูกค้าจะได้อะไรจากสิ่งนี้นะ” สุดท้ายสิ่งที่เราต้องคิดจริงๆ คือ ถ้าเราเป็นเจ้าของบริษัท หรือถ้าเราเป็นคนที่จ่ายเงินให้โปรเจคนี้ เราอยากได้อะไร ถ้าเราลองเอาตัวเองสวมหมวกของการเป็นเจ้าของหรือคนจ่ายเงิน เราจะคิดแค่ว่า มันมี “business value” อะไรในเชิงธุรกิจ มันจะลดเวลา manual ลงได้มากน้อยแค่ไหน มันจะต้องใช้ effort ในการ maintain สูงแค่ไหน ถ้าต้อง scale ทีมเพิ่ม ต้องเอาคนใหม่ๆ เข้ามาฝึกเรียนฝึกใช้ มันใช้ระยะเวลา on board นานแค่ไหน เพราะทุกอย่างคือ cost ที่ต้องจ่าย สุดท้ายเจ้าของบริษัทไม่ได้อยากได้ framework cool cool ไว้ตั้งโชว์บน git ไม่ได้อยากได้ automation ที่รันเร็วที่สุดในตลาด แต่หาคนมา maintain หรือหาคนมาทำต่อไม่ได้ เพราะฉะนั้น เวลาจะต้องเลือกอะไร ลองใช้หลักการง่ายๆ “ถ้าชั้นเป็นเจ้าของบริษัท/คนจ่ายเงิน ชั้นอยากจะได้อะไรจากการจ่ายเงินจำนวนนี้”
สุดท้ายอย่างที่เกริ่นมาตั้งแต่ต้นว่า บทความนี้คงไม่ได้มาบอกว่าอะไรดี อะไรไม่ดี หรือแม้แต่ว่า อะไรเหมาะกับคุณ หรือไม่เหมาะกับคุณ ทุก framework ทุก stack มีข้อดีข้อเสีย ขึ้นกับ situation / context ในการนำไปใช้ สุดท้ายสิ่งสำคัญที่เราจะต้องคิดในการเลือกใช้อะไรสักอย่าง มันคือเรื่องของการ balance หลายๆ แกนที่กล่าวไปข้างต้น ให้มันสร้าง business value ได้สูงที่สุด ในมุมขององค์กร หรือ คนจ่ายเงิน หวังว่าบทความนี้จะเป็นประโยชน์ไม่มากก็น้อยกับ เพื่อนๆ พี่ๆ น้องๆ ที่กำลังนั่งกุมขมับอยู่ว่าใช้ไรดีว้าครับ สุดท้ายตำแหน่งงาน automation qa ในบริษัทยังเปิดรับสำหรับคนที่มีใจอยากเก่ง อยากเป็น A Player ใน area นี้อยู่นะครับ (โฆษณาแบบดื้อๆเลย) ใครสนใจก็ลองส่ง resume มาสมัครได้ที่ careers@doppiotech.com นะค้าบ
