ตลาดหาแต่ Automation… แล้ว Manual แบบเราล่ะเอาไงดี
ใครเป็น Manual QA บ้าง เปิดเว็บหางานทีไร เจอแต่คำว่า
“Must have Cypress/Playwright experience”,
“Experience in Selenium or Automated Testing Frameworks”…
อ่านแล้วก็อดใจสั่นไม่ได้ใช่มั้ยคะ
เชื่อว่าหลายคนคงจะเกิดอาการ Imposter Syndrome กำเริบจนแทบจะหมดสิ้นแพชชั่น
และแอบตั้งคำถามกับตัวเองว่า “แล้วถ้าเรายังเขียนสคริปต์ไม่คล่อง เราจะรอดมั้ย”
แต่ความจริงที่หลายๆคนมักไม่ได้พูดถึงคือ
“ก่อนที่เราจะเขียน Automation ได้ระดับเซียน เราก็ต้องมี เซนส์ของการเป็น QA ที่ดี ให้ได้ก่อนค่ะ”
เครื่องมือ Automation มันฉลาด และทำงานไวก็จริง
แต่มันไม่สามารถแยกให้เราได้ค่ะว่า Test Case ที่สำคัญ
หรือ Test Case ที่มีคุณค่าต่อ Business นั้นอยู่ตรงไหนบ้าง
มันแค่รันตามสิ่งที่เราเขียนสคริปต์สั่งไว้
ถ้าเรากระโดดไปเขียน Automate โดยที่ยังขาด Testing Technique ที่ดี
มัวแต่ออกแบบ Test Case แบบจุกจิกยิบย่อยไปหมดทุกเรื่อง
เราอาจจะได้ Automated Test 100 ข้อที่ไม่มี Business Value
แถมยังใช้เวลานาน และพังง่าย ต้องมาคอยนั่งแก้สคริปต์กันรายวัน
แต่ถ้าเรามีพื้นฐาน Test Design ที่แน่น รู้ว่า Objective ของการเทสคืออะไร
รู้ว่า Core Business Requirement อยู่ตรงไหน
โค้ด Automate ที่เราเขียนออกมาถึงจะกลายเป็น “เกราะป้องกัน” ที่มีคุณค่าอย่างแท้จริง
🚨 โค้ดรันผ่านฉลุย… แต่เจอ Production Bug ยับ
มาดูตัวอย่างกับระบบ Promo Code กันเหมือนเดิม
ลองจินตนาการตามดูนะคะ ถ้าเราเป็นคนที่เขียนสคริปต์ได้พริ้วมาก ทำ Automation Test 100 ข้อได้ภายใน 1 วัน
เราอาจจะเขียนสคริปต์ให้กรอกโค้ด SALE50 -> กดปุ่ม Aply -> ใส่ Asset เช็คว่ายอดเงินลด 50 บาทจริงๆ
สคริปต์รันปุ๊บ เขียว สวยงาม บอกทีมว่า Pass เอาขึ้น Production ได้เลย
ปรากฏว่า (เหตุการณ์สมมตินะคะ)
❌ ลูกค้ากดปุ่ม Apply ส่วนลดซ้ำ ระบบก็ Apply ส่วนลดเบิ้ลให้
❌ ใส่โค้ดส่วนลดไปแล้ว ลูกค้าลบของออกจากตะกร้า แต่โค้ดยังอยู่ ยอดรวมติดลบซะงั้น
❌ ลูกค้าพิมพ์ส่วนลดแล้วเผลอใส่ Space bar “SALE50 “ แล้วหลังบ้านล่มเพราะหาโค้ดไม่เจอ
กลายเป็นว่า Automation Test รันผ่าน 100%
แต่บั๊กยุบยับไปหมด อาจจะเจอลูกค้าหัวหมอกดใส่โค้ดซ้ำๆ จนกระทบกับผลกำไรบริษัท
ที่เล่ามาไม่ได้บอกว่า Automation Test ไม่ดีนะคะ
แต่พี่กิ่งกำลังจะบอกว่า ต่อให้เรามีเครื่องมือที่ดีแค่ไหน เร็วแค่ไหน
แต่ถ้าคนใช้ไม่มีความเข้าใจอย่างแท้จริง ไม่ได้มองภาพรวมของ Business
หรือ ไม่ได้คิดถึง Edge Case ต่างๆ เอาไว้ เครื่องมือก็อาจจะแค่ช่วยให้เราปล่อยบั๊กออกไปได้เร็วขึ้นเท่านั้นเอง
แต่ในขณะเดียวกัน ถ้าเราเป็น Manual QA ที่เทพมาก สามารถคิดเคสได้ครอบคลุม 100% ไม่มีหลุด
แต่ไม่สามารถใช้ Automation Test ในการช่วยทุ่นแรงได้ อาจจะต้องใช้เวลา 2 สัปดาห์ในการเทสทุกเคส
แทนที่จะใช้สคริปต์รันแค่ 10 นาที แบบนั้นสุดท้ายเราก็จะกลายเป็นคอขวดของทีมในที่สุด
แล้ว QA ร่างทอง ควรจะอยู่ตรงไหน
เราจะต้องไม่ใช่คนที่เก่งโค้ดจนทิ้งสกิล Manual และ ก็ไม่ใช่คนที่เก่ง Manual แต่ไม่เคยแตะโค้ดค่ะ
แต่เราต้องเป็นคนที่ Balance สกิลทั้ง 2 ให้ไปด้วยกันให้ได้
❌ Manual QA สายชะล่าใจ: คิดว่าตัวเองออกแบบ Test Case เก่งแล้ว เข้าใจ Business แล้ว
ยึดติดกับการเทสแมนวลแบบเดิมๆ ไม่เปิดรับ Tool ใหม่ๆ สุดท้ายก็จะทำงานช้ากว่าสปีดของทีม และถูกเทคโนโลยีทิ้งห่างไปเรื่อยๆ
✅ QA ร่างทอง เส้นทางสู่ Full Stack QA: คือคนที่เอา Quality Mindset ที่ถูกต้อง มาติดปีกด้วยความไวของ Automation
รู้ว่าเคสไหนควรใช้สคริปต์รันไปแบบถึกๆ เคสไหนควรใช้มนุษย์ตรวจสอบ เพื่อให้งานออกมาเร็วและมีคุณภาพที่สุด
🚀 ถึงเวลาเร่งเครื่อง: ห้ามชะล่าใจเด็ดขาด!
มาถึงตรงนี้ ใครที่เป็น Manual QA และมั่นใจว่าสกิลการเทสของตัวเองนั้นดีอยู่แล้ว ก็อย่าเพิ่งหยุดพัฒนาตัวเองนะคะ
การเขียน Automate มันเป็น Hard Skill ที่เลี่ยงไม่ได้แล้วในยุคนี้
ยิ่งเรามีพื้นฐานการเทสที่แน่นปึ้กเป็นทุนเดิมอยู่แล้ว ถ้าบวกสกิล Automate เข้าไป รับรองว่าจะกลายเป็น “ของแรร์” ที่ใครๆ ก็ต้องการตัวแน่นอน
การเขียนโค้ดก็เหมือนการหัดขับรถนะคะ แรกๆ อาจจะเกร็งๆ งงๆ ต้องหมุนพวงมาลัยทางไหน ใช้ syntax อะไร
แต่ทำซ้ำๆ ฝึกบ่อยๆ กล้ามเนื้อสมองมันจะจำได้เอง
อย่าปล่อยให้ความกลัวคิดไปเองว่าทำไม่ได้ มาบล็อกการเติบโตของเราเด็ดขาด
เอาความเข้าใจ Business Logic และ Mindset ที่เรามี ไปเป็นรากฐานของการเขียน Automation Test ที่ดีกันค่ะ
เพราะ Quality starts with how you think