💻 คัมภีร์ QA: มัดรวม 13 ศัพท์ที่ต้องรู้ ถ้าอยากอยู่รอดในทีมไอที!
เนื่องจากมีคนขอมา วันนี้เลยมัดรวมคำศัพท์คีย์เวิร์ดสำคัญๆ ที่คนทำงานสาย Software Tester (QA) ต้องเจอในชีวิตจริงมาให้ถึง 13 คำเน้นๆ ย่อยมาให้สั้น กระชับ อ่านจบเข้าใจกระบวนการทำงานทันที เซฟเก็บไว้ดูด่วน!!!
หมวดที่ 1: ขั้นตอนเตรียมงานก่อนเทส (Planning & Design)
1. Requirement (ความต้องการระบบ): บรีฟหรือเอกสารอธิบายว่าฟีเจอร์นี้ต้องทำอะไรได้บ้า ง QA ต้องใช้สิ่งนี้เป็นที่อ้างอิงหลักในการเช็กงานค่ะ
2. Test Case (เคสเทส): ตารางหรือคู่มือที่เราเขียนขึ้นมา ว่าเราจะลองกดแอปหรือเว็บยังไงบ้าง เพื่อใช้เป็น Step เช็กว่าระบบทำงานถูกต้องตาม Requirement ไหม
3. Positive Case (เคสปกติ): การเทสในกรณีที่ยูสเซอร์ใช้งานแบบคนปกติทั่วไป เช่น กรอกรหัสผ่านถูกต้องแล้วต้องเข้าสู่ระบบได้สำเร็จ
4. Negative Case (เคสไม่ปกติ): การเทสในกรณีที่ยูสเซอร์กดแปลกๆ หรือตั้งใจใส่ข้อมูลผิดๆ เพื่อลองการทำงานระบบ เช่น กรอกเบอร์โทรศัพท์เป็นตัวอักษร เพื่อดูว่าจะเอ๋อหรือเปล่า
5. Error Case (เคสที่ระบบทำงานผิดพลาด): การเทสเพื่อเช็กว่าเวลาระบบทำงานพลาด ต้องจัดการตัวเองยังไง เช่น ลองปิดเน็ตระหว่างกดโอนเงิน ดูว่าแอปจะเด้งข้อความแจ้งเตือนผู้ใช้อย่างถูกต้องไหม ไม่ใช่ค้างหน้านั้นไปเลย
หมวดที่ 2: ขั้นตอนการรันงานเทสจริง (Test Execute)
6. Smoke Test (สม็อกเทส): การ "เทสแบบด่วนๆ" เพื่อรีบเช็กฟังก์ชันหลักหลังจากเดฟส่งงานมา เมคชัวร์ว่าระบบใช้งานได้เปิดติด ไม่พังยับเยิน ถ้าผ่านค่อยลุยเทสละเอียดต่อค่ะ
7. Sanity Test (ซานิตี้เทส): การเทสเจาะลึกเฉพาะจุดที่มีการแก้ไขโค้ดหรือแก้บั๊ก เพื่อดูว่าจุดที่เคยพังนั้นถูกแก้ไขเรียบร้อยดีแล้วหรือยัง
8. Regression Test (รีเกรสชันเทส): งานช้างประจำสัปดาห์! คือการกลับไป "ตรวจซ้ำระบบเดิมทั้งหมด" เพื่อให้มั่นใจว่าโค้ดใหม่หรือฟีเจอร์ใหม่ที่ใส่เข้ามา มันไม่ได้ไปแอบทำให้ระบบเดิมพังนั่นเองค่ะ
9. Exploratory Testing (เทสแบบอิสระ): การเทสแบบสุ่มๆ กดไปเรื่อยๆ ตามสัญชาตญาณโดยไม่มีการเขียน Test Case ล่วงหน้า เพื่อหาบั๊กแปลกๆ ที่เราอาจจะคาดไม่ถึง
หมวดที่ 3: จัดการบั๊ก เทสระบบรวม และส่งงาน (Defect & Deployment)
10. Bug / Defect (บั๊ก): ข้อผิดพลา ดของระบบ อะไรก็ตามที่ทำงานไม่ตรงตามบรีฟ เช่น กดปุ่มชำระเงินแล้วแอปเด้ง หรือหน้าจอเบี้ยว ปุ่มกดไม่ได้
11. SIT (System Integration Testing): การเทสระบบเวอร์ชันภาพใหญ่ เพื่อเช็กว่าพาร์ทต่างๆ หรือระบบย่อยๆ พอเอามารวมกันและเชื่อมต่อข้อมูลกันแล้ว ยังทำงานร่วมกันได้ถูกต้อง
12. UAT (User Acceptance Testing): การเทสรอบสุดท้ายโดยให้ผู้ใช้งานจริง ลูกค้า หรือทีม BA/PM มาลองกดใช้งานเพื่อคอนเฟิร์มว่าระบบทำงานได้ถูกต้องและพร้อมเอาไปใช้งานจริง
13. Deployment / Go-Live (เดปลอย): การเอาโค้ดขึ้นระบบ ถ้าเดฟบอกว่า "กำลัง Deploy นะครับ" แปลว่าเราต้องเตรียมตัวสวมวิญญาณนักสืบลุยเทสได้เลย! หรือถ้าเดฟบอกว่าจะ Go-Live แปลว่าระบบกำลังจะเปิดให้ผู้ใช้จริงเล่นแล้วค่ะ
💡 ทริคเด็ดสำหรับมือใหม่/ย้ายสาย:
มือใหม่หรือย้ายสายมาแรกๆ ไม่ต้องท่องจำหมดในวันเดียวนะคะ ให้เน้นทำความเข ้าใจ Step จำเป็น: รับ Requirement -> เขียน Test Case -> ลุยเทส (หา Bug) -> ส่ง Bug ให้เดฟ -> เดฟแก้เสร็จแล้ว Deploy กลับมา -> เราทำ Regression Test ตรวจซ้ำ วนลูปอยู่แค่นี้เลยค่ะ ทำบ่อยๆ เดี๋ยวก็คล่องและคุยกับทีมรู้เรื่องเอง
ใครกำลังศึกษาอยู่แล้วเจอคำไหนนอกเหนือจากนี้ที่อ่านแล้วงงอีก แวะมาคอมเมนต์ทิ้งคำถามไว้ได้น้า เดี๋ยวเข้ามาตอบให้ค่าา
#Lemon8ชวนเล่า #กว่าจะมีวันนี้ #แชร์ประสบการณ์ #ติดเทรนด์ #workfromhome
จากประสบการณ์ส่วนตัวเมื่อต้องเริ่มทำงานในสาย QA พบว่าการเข้าใจคำศัพท์พื้นฐานเหล่านี้เป็นกุญแจสำคัญที่ช่วยให้การทำงานกับทีมเดฟและโปรดักท์ราบรื่นขึ้นมาก อย่างเช่นคำว่า Requirement ที่เป็นเหมือนแผนที่ชี้ชัดว่าเราต้องทดสอบอะไรบ้าง หรือ Test Case ที่ทำหน้าที่เหมือนแผนปฏิบัติการเทสที่ชัดเจน การแยก Positive และ Negative Case ช่วยให้เราคิดกรณีทดสอบที่ครอบคลุมทั้งพฤติกรรมปกติและผิดพลาดที่ผู้ใช้จริงอาจทำได้ ในขั้นตอนรันเทสจริง การทดสอบ Smoke Test และ Sanity Test ช่วยคัดกรองปัญหาเบื้องต้นและตรวจสอบการแก้ไขโค้ดอย่างรวดเร็ว ซึ่งทำให้ประหยัดเวลามากเมื่อเทียบกับการใช้เวลาเทสดีเทลตั้งแต่แรก การทำ Regression Test เป็นสิ่งจำเป็นเพื่อป้องกันบั๊กใหม่ๆ ที่อาจเกิดจากการเปลี่ยนแปลงโค้ด อีกทั้ง Exploratory Testing ก็ช่วยเปิดมุมมองใหม่โดยไม่ยึดติดกับ Test Case ที่เขียนไว้ ส่วนการจัดการบั๊กและส่งงาน SIT และ UAT เป็นขั้นตอนที่สำคัญมากเพราะช่วยทดสอบระบบในภาพรวมและให้ผู้ใช้งานจริงยืนยันความถูกต้องก่อนการปล่อยใช้งานจริง รวมถึงการเข้าใจคำว่า Deployment หรือ Go-Live ทำให้เรารู้ว่าเมื่อไหร่ที่ต้องเตรียมตัวลุยเทสหนักๆ หรือเตรียมความพร้อมระบบ สำหรับมือใหม่ แนะนำว่าไม่ต้องรีบจำทุกคำแต่ให้วางใจทำความเข้าใจขั้นตอนหลักๆ และวนลูปทำซ้ำๆ โดยเริ่มจาก Requirement -> เขียน Test Case -> เทสหา Bug -> ส่งบั๊กให้เดฟ -> สังเกต Deployment และทำ Regression Test เป็นวงจร ทำบ่อยๆ จะเห็นภาพงานชัดขึ้นและพร้อมสื่อสารในทีมได้ดีขึ้นครับ
Regression ไม่จำเป็นต้องตรวจซ้ำทั้งหมดงับ แต่ควรดึงฟีเจอร์หรือ case นั้นที่คิดว่า impect มาทำซ้ำ ถ้าทำทั้งระบบ มันจะเปน automate ทำ ส่วนถ้า manaul tc ควรเอาเคสที่คิดว่ากระทบมาทดสอบซ้ำ qa/tester ถ้าระดับ mid-senior จะต้องรู้ตรงนี้ได้ แต่หากระบบเรากระทบหมดละมี timeline กับ resource มากพอก็สามารถทดสอบได้ทั้งระบบเลย (แต่ส่วนมากไม่ทำกัน ตีเปน automate ไป