ใครเป็น Manual QA อยู่บ้างคะ
อยากเริ่ม Automation Testing มานานหลายเดือน หลายปี
แต่ก็ไม่รู้จะเริ่มยังไง แค่ลองเปิดขึ้นมาดู แล้วก็ไม่รู้จะไปไหนต่อ
สุดท้ายก็เลยไม่ได้เริ่มซักที
.
มีคำถามยอดฮิตหนึ่งข้อ ที่พี่กิ่งได้รับทุกๆ ครั้งที่เปิดรับสมัคร Automation Testing the Right Way
“ถ้าเขียนโค้ดไม่เป็น จะเรียน Automation Testing ได้มั้ย”
ได้ค่ะ ได้ ได้แน่นอน!!!
รู้อะไรมั้ยคะ ใน Automation Testing เนี่ย
การเขียนโค้ดคือสิ่งที่เรียนรู้ได้ง่ายที่สุดเลยค่ะ
แล้วสิ่งที่ยากมันคืออะไร เดี๋ยวจะเล่าให้ฟัง
.
ก่อนอื่นมาเริ่มจากว่า Automation Testing มันคืออะไรกันแน่?
สมมติว่าเรามี test case ของฟีเจอร์ login ที่เราเขียนไว้ประมาณนี้
- เปิดหน้า Login
- กรอก email ที่ register ไว้แล้ว
- กรอก password ที่ถูกต้อง
- กดปุ่ม login
Expected: เข้าหน้า Dashboard ได้ และเห็นชื่อ user ถูกต้อง ที่มุมขวาบน
.
ถ้าเราเอาไปเขียน Playwright ก็อาจจะได้หน้าตาประมาณนี้ค่ะ
await page.goto(‘/login’);
await page.getByLabel(‘Email’).fill(‘nopnapa@gmail.com’);
await page.getByLabel(‘Password’).fill(‘Test1234’);
await page.getByRole(‘button’, { name: ‘Sign In’ }).click();
await expect(page).toHaveURL(/dashboard/);
await expect(page.getByTestId(‘user-name’)).toHaveText(‘Hello Nopnapa’);
.
ถ้าลองไล่ทีละบรรทัด
มันก็คือ test step แต่ละขั้น ที่เราเอามาแปลให้ Playwright เข้าใจเฉยๆ
ไม่มีบรรทัดไหนเลย ที่เราไม่รู้ว่ามันทำอะไรใช่มั้ยคะ
เพราะเราคิดไว้ตั้งแต่ตอนทำ test case แล้ว
เพราะฉะนั้น สิ่งที่เราต้องเรียนเพิ่มในที่นี้
คือ “วิธีบอกว่าจะทำยังไง”
ไม่ใช่ “จะเทสอะไร”
.
📌 แล้วถ้าอยากเรียน “วิธีบอก” จะต้องทำอะไรบ้าง
✅ ภาษา (Coding Language): เลือกตามที่ต้องใช้เลยค่ะ ทีมใช้ตัวไหน ก็เรียนอันนั้นได้เลย ถ้าใครไม่รู้จะเริ่มยังไง ก็เลือก Javascript ไว้ก่อนก็ได้ เพราะเป็นภาษาที่เรียนง่าย แล้วคนใช้เยอะ และที่สำคัญ เราแค่เข้าใจว่ามันคืออะไรก็พอค่ะ ไม่ต้องรู้ทั้งหมดแบบ 100% เพราะส่วนใหญ่มันจะมีของที่เตรียมเอาไว้ให้เราเรียกใช้ได้ง่ายอยู่แล้ว
✅ วิธีหา element (Locator): ก่อนเราจะสั่งมันได้ เราต้องรู้ก่อนว่า “ปุ่ม login อันนั้น” คือปุ่มไหน มันจะมีวิธีที่ชี้บอกให้โค้ดเข้าใจว่าเรากำลังจะพิมพ์ที่ไหน จะกดปุ่มไหน
✅ วิธีจัดโครงสร้าง: ช่วงแรกๆ อาจจะยังไม่ต้องก็ได้ค่ะ แต่เมื่อไหร่ที่เราเริ่มมี test เยอะๆ เป็นสิบเป็นร้อยข้อ ถ้าไม่มีโครงสร้าง มันอาจจะกลายเป็นภาระที่เราต้องมาคอยดูแลได้ค่ะ และนี่ก็เป็นสาเหตุหลักที่ Automation Test ของหลายๆ ที่ ทำมาแล้วก็ไม่ได้ใช้ต่อ แต่ตอนเริ่ม เรายังไม่ต้องสนตรงนี้ก็ได้ค่ะ เอาแค่รันผ่าน 1 ข้อแรกก่อนก็พอ
.
📌 แล้วส่วนที่ยากของ Automation Testing ที่พูดถึงตอนต้นมันคืออะไร?
ลองกลับไปดูบรรทัดสุดท้ายของ test case ตัวอย่างนะคะ
เป็นการเช็คว่า test case นี้ผ่านหรือไม่ผ่านใช่มั้ยคะ
ซึ่งเราบอกว่า การที่มันจะ login ได้เนี่ย เราต้องเห็นหน้า dashboard และ ชื่อ user ขึ้นถูก
ถามว่าเรารู้ได้ยังไงคะว่าต้องเช็คอะไร?
เพราะมันอาจจะมาจาก requirement หรือ มาจาก behavior ของระบบที่เรารู้อยู่แล้ว
ลองคิดดูว่า ถ้าเรา verify แค่ว่า URL เปลี่ยนเป็นหน้า dashboard แต่ไม่ได้เช็คข้อมูลอื่นเลย
แต่จริงๆ ระบบไปดึงข้อมูลของ user มาไม่ได้ ทำให้โชว์เป็นค่าว่างๆ หมดเลย
กลายเป็น test รันผ่าน เขียวหมด ทั้งๆ ที่จริงๆ ระบบพังไปแล้ว
ต่อให้เขียนโค้ดได้เทพแค่ไหน แต่ถ้าออกแบบ test case มาไม่ดีพอ
ก็อาจจะได้ test ที่ไม่มีประโยชน์มาอยู่ดี
.
แล้วเรื่องนี้มันเป็นสิ่งที่ไม่ได้จะบอกกันได้ใน 2 ชั่วโมง
แต่มันเกิดจากการนั่งเทสของจริงมาเป็นปี เจอบั๊กหลุดมานับไม่ถ้วน
จนรู้ว่าจุดไหนควรจะโฟกัส จุดไหนปล่อยผ่านได้
และการเป็น manual QA มันทำให้เราได้ฝึกเรื่องพวกนี้มาอยู่แล้ว
นี่คือของดีที่ทุกคนมีอยู่ในมืออยู่แล้วค่ะ
ส่วนการเขียนโค้ด กับ syntax ต่างๆ มันเป็นส่วนที่หาเรียนได้ง่าย และ ฝึกได้ง่ายกว่า
ถ้าเราทำบ่อยๆ เราก็จะคล่องขึ้นได้แน่นอน
.
📌 ถ้าใครยังกลัวอยู่ ลองเริ่มดูง่ายๆ ก่อนได้เลย
ลองหยิบ test case ที่ง่ายที่สุด ที่เราต้องเทสซ้ำบ่อยๆ อย่างเช่น login ก็ได้ค่ะ
แล้วเอามาดูว่า
👉 เรามี Step ที่ชัดเจนพอรึยัง ว่าต้องการทำอะไร กับ test data แบบไหน
👉 Expected Result วัดได้จริงมั้ย ว่า pass หรือ fail หน้าตาเป็นแบบไหน ไม่ใช่แค่ “ระบบทำงานได้ถูกต้อง”
ถ้ามีแล้ว แปลว่าเรามี Automation Test ไปครึ่งนึงแล้ว
ส่วนที่เหลือคือเอาไปแปลให้เป็นโค้ดที่คอมพิวเตอร์เข้าใจ ซึ่งส่วนนั้น เราเรียนเพิ่มได้ค่ะ