👻❌ เคยเจอผีหลอกตอนรัน Automation Test กันมั้ยคะ
รันบนเครื่องตัวเองกี่รอบก็ผ่านหมด ผ่านตลอด ผ่านทุกครั้ง ไม่เคยติดปัญหาอะไร
แต่พอเอาขึ้นไปรันรวมกับ Regression Test เท่านั้นแหละ
พังยับ!!!
แล้วเราเอามาลองรันบนเครื่องตัวเองหลังจากเห็นมันพัง
เอ้า ก็ผ่าน
สุดท้ายนั่งกุมหัว ไม่รู้จะทำยังไง 🤦♀️
แค่นั้นยังไม่พอ พอเป็นแบบนี้บ่อยๆ กลายเป็น Automation Test ที่ไม่ stable และไม่มีใครเชื่อมันซะงั้น
สุดท้ายกลับมานั่งเช็ค manual เหมือนเดิม เพราะผล Automation Test มันเชื่อไม่ได้
อวสาน QA ร่างทอง
Test ที่รันอยู่ก็ไม่มีใครเชื่อ
ทีมก็ไม่แบ่งเวลาให้เขียน Automation Test เพราะไม่เห็นประโยชน์
สุดท้ายก็รัน Manual เหมือนเดิม
…
ยังค่ะ ยังไม่จบแค่นี้ เราไม่อวสานกันง่ายๆ แบบนี้หรอกนะคะ
วันนี้พี่กิ่งจะพามาเจาะลึก “หนึ่งปัญหาสำคัญ” ที่ทำให้เกิดเหตุการณ์แบบนี้ได้ค่ะ
บางทีมันไม่ได้เกิดจากเขียนโค้ดไม่ดี หรือระบบมีบั๊กเยอะอะไรเลยค่ะ
แต่มันอาจจะเกิดจากปัญหาง่ายๆ จากสิ่งที่เรียกว่า “Test Data” ของเรา ที่มันไม่ independent
คือไม่เป็นอิสระต่อกัน และยังต้องพึ่งพาข้อมูลหรือผลลัพธ์จากส่วนอื่นๆ
.
💡 ลองดูตัวอย่างสถานการณ์นี้นะคะ
สมมติว่าเรากำลังทดสอบระบบเว็บช็อปปิ้ง ในส่วนฟีเจอร์ Add Product ที่เป็นการเพิ่มสินค้าใหม่เข้าไปในระบบ
แล้วเราก็กำลังทำ Automation Test Case สำหรับกดเพิ่มสินค้าใหม่ แล้วก็เช็คว่าสินค้านั้นถูกเพิ่มเข้าไปได้สำเร็จ
❌ Average QA
Test Case ถูกทุกอย่าง แต่ตั้งชื่อสินค้าแบบ Fix ไปเลยว่า “กระเป๋าสะพาย 1”
1. เปิดไปที่หน้า Add Product
2. เพิ่มสินค้า ชื่อ: กระเป๋าสะพาย 1, ราคา: 399
3. Verify ว่ามี “กระเป๋าสะพาย 1” อยู่ในระบบ
ก็เหมือนจะไม่มีอะไรใช่มั้ยคะ ลองจินตนาการต่อไปอีก
วันที่ 1: เขียนเคสนี้เสร็จ รันผ่าน เยี่ยม! ✅
วันที่ 2: Test พัง! ทั้งๆที่ไม่ได้แก้อะไรเลย
แต่มันพังเพราะไม่สามารถเพิ่มสินค้าชื่อซ้ำได้ ก็เลยบอกว่า Test นี้เฟล ทั้งๆที่จริงๆมันควรจะผ่าน
.
หรืออีกหนึ่งตัวอย่างที่อาจจะเจอกันบ่อยๆ แต่ไม่รู้ตัว
วันที่ 1: เขียนเคสนี้เสร็จ รันผ่าน เยี่ยม! ✅
วันที่ 2: มีการ Deploy เวอร์ชั่นใหม่ที่ไปทำให้ส่วนนี้พัง ทำให้ Add Product ไม่ได้
แต่… Regression เราก็รันผ่านเหมือนเดิม แล้วเราก็ไม่รู้ว่ามันพัง จนกระทั่ง user มาบอก
ทำไมเป็นแบบนั้น…
เพราะมันไปเจอ “กระเป๋าสะพาย 1” ที่เราเพิ่มไว้ตั้งแต่วันก่อน แล้วก็บอกว่าผ่าน
.
Test ที่ดี นอกจากจะต้องคอยดูให้ Regression มันรันผ่านตลอดแล้วเนี่ย
มันควรจะต้องเฟลด้วย เวลาที่มีบั๊กเกิดขึ้นจริงๆ
แต่เคสนี้มันไม่เฟล! เพราะมันดันไปเจอข้อมูลเก่าที่เคยใช้ไปแล้ว
และสิ่งนี้จริงๆคือสิ่งที่สำคัญที่สุดเลยใช่มั้ยคะ
เรามี Regression Test เพื่อให้มั่นใจว่าของเดิมมันไม่มีอะไรพัง
และเมื่อไหร่ที่มันพัง เราควรจะต้องรู้ให้เร็วที่สุด
แต่ตอนนี้มันบอกไม่ได้ ก็ถือว่าเป็น Automation Test ที่ใช้ไม่ได้
.
🛡️ 3 หลักการจัดการ Test Data ฉบับ “QA ร่างทอง”
ถ้าอยากให้ Script ของเรา stable สุดๆ เชื่อได้ทุกครั้งที่กดรัน
เราก็ต้องอัพเกรดการจัดการ Test Data ของเราให้ร่างทองไปด้วยค่ะ
.
1️⃣ Static Data ใช้ให้ถูกงาน
พวกข้อมูลที่ Fix ตายตัว เช่น User Role, ประเภทสินค้า อะไรที่เรารู้แน่นอนว่ามันจะไม่เปลี่ยนแปลง ใช้ data ที่กำหนดตายตัวได้เลยค่ะ เช่น keyword สำหรับ search
✅ ใช้ได้เมื่อ test ไม่ต้องการ uniqueness (ที่ต้องไม่ซ้ำกับใคร)
เช่น ค้นหาด้วย keyword “กระเป๋า” ไม่ว่าจะรันกี่ครั้ง ก็ใช้คำเดิมได้
❌ ห้ามใช้เด็ดขาด ถ้า data ต้องเป็นของใหม่ทุกครั้ง
เช่น สร้าง account, สร้างสินค้า ถ้าใช้ชื่อเดิมซ้ำ Test จะไม่รู้ว่า data นี้มาจากไหน
.
2️⃣ สร้าง unique data ทุกครั้ง
ทุกครั้งที่รัน ก็ให้มันสร้าง Test Data ใหม่ไปเลยแทนที่จะ hardcode เอาไว้
ใช้พวก Library Faker ช่วยสุ่มชื่อ หรือ Timestamp จะช่วยได้เยอะมากค่ะ
เช่น แทนที่จะใช้ “กระเป๋าสะพาย 1”
เราก็ใช้ กระเป๋าสะพาย + timestamp (เช่น กระเป๋าสะพาย + dayjs().format('YYYYMMDDHHmmss')
ก็จะได้ “กระเป๋าสะพาย 202605261914” มาใช้แทน
หรือจะใช้ร่วมกับ Faker ที่ช่วยสุ่มชื่อก็ได้
faker.commerce.productName() + moment().format('YYYYMMDDHHmmss')
เราก็จะได้ “Soft Gloves 202605261914” มาใช้ ก็จะบอกได้เลยว่า data นี้เพิ่งสร้างจริงๆ
.
3️⃣ แยก Data Layer ออกจาก Action Layer
Action Layer คือพวก command ที่บอกว่าเราจะทำอะไรกับแอพของเรา
ถ้าเราทำเป็น Page Object Model ส่วนใหญ่ก็จะเป็น function ที่อยู่ใน Page Class ของเรานั่นเองค่ะ
❌ ซึ่งเราไม่ควรสร้างหรือเตรียมข้อมูลในนี้เด็ดขาด เพราะหน้าที่ของ Page Class คือจัดการกับสิ่งที่ทำได้ในหน้านั้นเท่านั้น
มันไม่จำเป็นต้องรู้เรื่อง Test Data เลย เราไม่ควรเอา Logic ไปปนกัน
เพราะจะทำให้ reuse ยาก และ ทำความเข้าใจยากขึ้นด้วยค่ะว่า Test นั้นใช้ data อะไร
✅ วิธีที่ควรทำคือ จัดการ data ทั้งหมด ใน Steps Definition ค่ะ หรือ layer ที่เป็น Test Case ของเราจริงๆ
แล้วค่อย pass ข้อมูลที่เราจะใช้ส่งเข้าไปเป็น parameter แทนค่ะ วิธีนี้จะทำให้โค้ดของเรา maintain ง่ายขึ้นมาก และ Test Case ก็จะอ่านรู้เรื่องขึ้นด้วยค่ะ
.
Automation Test ที่ดี ไม่ใช่แค่เทสผ่าน เขียวตลอด
แต่ต้องเป็น Test ที่เชื่อได้ว่า “ถ้าผ่าน คือผ่านจริง” และ “ถ้าไม่ผ่าน คือพังจริง”
และต้องให้ผลเหมือนเดิมทุกครั้งที่รัน (Determinism)
ไม่ใช่ต้องคอยสวดมนต์ให้มันผ่าน หรือกด rerun ซ้ำๆ จนกว่าจะผ่าน
เขียน Script เป็น ใช้ Tool เป็น มันแค่จุดเริ่มต้นค่ะ
🥇 QA ร่างทอง คือคนที่เขียน Automation Test ที่ทุกคนเชื่อมั่นและมีคุณค่าต่อทีมอย่างแท้จริง
และTest Data ที่ดีก็เป็นส่วนหนึ่งในนั้นค่ะ
ตอนนี้ใครเจอปัญหาเรื่อง Test Data แบบไหนอยู่บ้าง มาร่วมแชร์ร่วมบ่นกันได้ในคอมเม้นเลยนะคะ