ขี้เกียจ Manual test จัง! มาทำ UI Automate test แบบ Sexy ด้วย Playwright กัน! ภาค 1

สวัสดีมิตรรักนักอ่านทุกท่านค่ะ หัวข้อในวันนี้ก็ยังวนเวียนอยู่กับการหา bug ให้ developer ปวดสมองเล่นกันอยู่นะคะ โดยพระเอกของเราในวันนี้คือ Tool ที่มีชื่อว่า Playwright ค่ะ สำหรับภาคนี้จะเป็นภาคเกริ่นนำและวิธี Setup project นะคะ ถ้าพร้อมแล้วก็ไปลุยกันเลย!

P.S. ภาษาที่ใช้สำหรับซีรี่ย์นี้จะเป็น Typescript ทั้งหมดนะคะ และจะเน้นไปที่การเขียนเทสเคสที่ฝั่ง Front-End เป็นหลักค่ะ

source: Playwright logo

ทำไมต้อง Automate test ? 🤨

ในระหว่างพัฒนา Website หรือ Mobile Application ขึ้นมาตัวหนึ่ง สิ่งที่จะขาดไปไม่ได้เลยใน Process คือการ Test โดย QA (Quality Assurance) ค่ะ โดยสิ่งที่ QA จะต้องทำแบบคร่าวๆ คือ

1. วิเคราะห์ Requirements
2. คิด Scenario และเขียน Test cases
3. ไล่ Test แต่ละเคสอย่างใจเย็น (?)
4. เมื่อเจอ bug ก็จะทำการเปิด Issue เพื่อรอให้ Dev แก้ต่อไปค่ะ (และตี Dev?)

จุดเจ็บปวดคือถ้า QA มานั่ง Manual test อยู่ทุกครั้งที่มี Features ใหม่ๆ เข้ามาเท่ากับว่า QA จะต้องใช้เวลาเพิ่มขึ้นเรื่อยๆ จากการต้องมานั่ง Recheck cases เดิมๆ ที่เคยผ่านไปแล้ว + Test cases ใหม่ๆ ที่เพิ่มมาพร้อม Features ค่ะ

อาจมีคนสงสัยว่าแล้วทำไมต้องกลับมา Recheck ด้วยล่ะ? เหตุผลเพราะว่า Features ใหม่ๆ ที่เข้ามานั้นอาจส่งผลกระทบต่อ Features เก่าๆ ที่เคยผ่านไปแล้วนั่นเอง ซึ่งการทำ Automate test จะมาช่วยลดเวลา และลด bug ในจังหวะนี้นี่เองค่ะ

ช่วงขาย Playwright 😏

ในโลกนี้มี Tools มากมายที่เอาไว้ใช้ทำ Automate test ค่ะ แต่ในวันนี้เราเลือก Playwright มานำเสนอ เพราะว่าตัว Playwright มีข้อดีหลายอย่างที่ชนะ Tools เจ้าอื่นๆ ไปอย่างสวยงามค่ะ

Support ในหลายสถานการณ์

Playwright ถือว่าเป็น tools ที่ยืดหยุ่นมากตัวหนึ่งเลยค่ะ ทั้ง Support browsers ที่หลากหลาย (Google Chrome, Firefox, Safari, etc.) บน Virtual device ที่หลากหลาย (Android, iPhone, etc.) ไหนจะยัง Support การเขียน Test case เพื่อ API อีก แถมยังรองรับภาษา Programming ที่หลากหลายอีกด้วยค่ะ (JavaScript, TypeScript, Python, GO, etc.)

Report สุดสวย หลายหลาก Format

การทำ Automate test หลายๆ ครั้งก็จำเป็นที่จะต้องมีการเก็บผลรายงานกับทีมเพื่อ Review steps ที่ทำไป เป็นการยืนยันผลและตัวการันตีว่า App ของเรานั้นปลอด bug ค่ะ โดยเจ้าตัว Playwright นี้ ก็รองรับการเก็บผลในหลากหลาย Format มากๆ ค่ะทั้งแบบ HTML, JSON, blob, etc. [ดูเพิ่มเติม]

HTML reporter example

UI สวยๆ พร้อมกับ scenario แบบ Step-by-Step

Playwright ยังมี Build-in UI สวยๆ ให้เราสามารถดู​ Step การทำงานของแต่ละ Test case ได้อย่างละเอียด ง่ายดาย อีกทั้งเห็น Error หรือ bug ไปพร้อมๆ กับการทำงานของมันอีกด้วย

Playwright built-in UI example

และอีกเยอะแยะมากมาย

นอกจากน้ำจิ้มข้างบนแล้ว Playwright ยังมีของเจ๋งๆ ที่ Support อีกเยอะแยะมากมาย ทั้ง Extension ใน VSCode เอย Functions สำหรับการเขียนเทสเคสที่สุดแสนจะง่ายดายเอย ไหนยังจะสามารถ run ใน GitHub Workflows เพื่อเก็บ Report ได้อีก… เยอะแยะไปหมดค่ะ และที่สุดของที่สุดคือ documentation ของเขาทำมาดี 10/10 เลยค่ะ (ปาดน้ำตา) ถนัดภาษาโปรแกรมมิ่งภาษาไหนก็ไปตำภาษานั้นกันได้เลย~

เพื่อไม่ให้เป็นการเสียนาฬิกา มาเริ่มกันเลย! 🔥

1. เริ่มจากการ Init project ด้วย Command lines

mkdir playwright-demo && cd playwright-demo
npm init playwright@latest

แล้วตามด้วยการเลือกภาษา TypeScript ค่ะ ที่เหลือก็เลือกตาม Default ทั้งหมดได้เลยค่ะ

2. เมื่อ Init project เสร็จแล้ว เราจะเห็น Directory ประมาณนี้ค่ะ

Playwright initial directory

คร่าวๆ เลยคือเราจะเขียน Test cases ใส่ไว้ใน Directory tests และเราสามารถ Config ค่าต่างๆ เช่น Report output, Support browser, Support device, etc. ใน file playwright.config.ts ได้ค่ะ

3. ลอง Run test cases จาก Example กันด้วย Command

npx playwright test // สำหรับแสดงผลใน terminal เลย
or
npx playwright test --ui // สำหรับแสดงผลใน built-in UI

Playwright built-in UI

4. ดู Report กันด้วย Command

npx playwright show-report

Note: ค่าเริ่มต้นของ report จะเป็นการแสดงแบบ HTML หากต้องการแก้ไขการแสดง report ให้ไปแก้ไขใน playwright.config.ts ที่ชื่อ reporter นะคะ

ยินดีด้วยค่ะ! ตอนนี้ก็ถือว่าทุกคนที่ผ่านมาอ่านบทความนี้ได้ก้าวเท้าข้างหนึ่งเข้าสู่การเป็น Automate tester แบบ Sexy กันแล้วค่ะ เย้~

พักยกกันก่อน 🥵

และบทความนี้ก็ขออาศัยจังหวะชุลมุนนี้ตัดฉับลง ณ​ ตรงนี้เลยค่ะ (ฮา) ขอเก็บความ Sexy ไว้แชร์ต่อไปบทความถัดไปโดยจะเจาะลึกถึงวิธีการคิด และการเขียน Test cases ให้มากขึ้น รวมไปถึงประสบการณ์ต่างๆ เกี่ยวกับการทำ Automate test ด้วยค่ะ

Inspiration ของมหากาพย์นี้ จะเกิดขึ้นไม่ได้เลยถ้าหาก QA ผู้ขยันขันแข็งของเราไม่เจอ bug ใน Features เก่าๆ ที่เคยเทสผ่านไปนานแล้ว สรรเสริญ พี่กอล์ฟ คุณ Aris K. ทีม QA ผู้ไม่หลุดลอดเคสเล็กๆ น้อยๆ ที่ Dev เข็มขัดสั้น (คาดไม่ถึง ผ่าม!) และ น้องพร๊อมพ์ทีม Dev นักป้ายยาตัวเย็นที่ป้ายยา Tools เจ๋งๆ อย่างไม่หยุดยั้งมา ณ​ ที่นี้ค่ะ

ขอตัวไปสัมภาษณ์(คาดคั้น?)ชาว QA ก่อนนะคะ แล้วพบกันใหม่ในบทความหน้าค่ะ บะบายยย~