มีใครเป็น QA คนเดียวในทีม แล้วรู้สึกเครียดมั้ยคะ
งานเทสปกติก็ต้องทำ automation test ก็ต้องเขียน
แล้วก็กลัวว่าจะไม่รอด จะเขียน automation test ยังไงให้ทันเวลา
จริงๆ เราไม่ได้แพ้เพราะเราเขียนโค้ดไม่เร็วหรอกค่ะ
แต่มันมักจะเป็นเพราะเราเลือก test case ผิดตั้งแต่แรก
พอเลือกผิดตั้งแต่ต้น ยิ่งขยันเท่าไหร่ก็ยิ่งช้า ทำไปเท่าไหร่ก็ไม่พอ
เขียนไปเป็นร้อยข้อ แต่ก่อนขึ้น production ก็ไม่มั่นใจ ต้องมาไล่เทสมือทุกรอบอยู่ดี 😮💨
.
ถ้าเราเป็นคนนั้นอยู่ เป็นคนที่มีเวลาเขียน automation test แค่สัปดาห์ละไม่กี่ชั่วโมง
ไม่มีคนช่วยรีวิวโค้ด ไม่มีทีมมาช่วยแบ่งงาน การทำให้ “ครบ” อาจจะเป็นไปไม่ได้เลยค่ะ
สกิลที่สำคัญกว่านั้นคือ “การเลือกให้คุ้ม”
📌 เกณฑ์ที่ใช้ตัดสินใจ
ถ้ายังไม่รู้จะตัดสินใจยังไง ลองดู 3 เรื่องนี้ก่อนค่ะ
รันบ่อยแค่ไหน x พังแล้วเจ็บแค่ไหน x นิ่งหรือยัง
- รันบ่อย: เคสที่ต้องกดซ้ำทุกรอบ ทุก sprint คือเคสที่มี automation แล้วจะคืนเวลาให้เรา
- พังแล้วเจ็บ: ถ้ามีบั๊กหลุดไปแล้วเสียหาย กระทบเงิน หรือ core หลักของระบบ ต่อให้ทำยากก็ต้องมี
- นิ่งหรือยัง: ของที่ยังเปลี่ยนทุก sprint ถ้าเวลาน้อย ต้นทุนที่ต้องใช้ดูแลอาจจะยังไม่คุ้ม
ลองเอามาดูพร้อมกัน ไม่ใช่ทีละตัว
เคสที่พังแล้วเจ็บหนัก แต่มีลูกค้าใช้ปีละครั้ง ก็อาจจะไม่ใช่เคสแรกที่ควรเลือกมาเขียน
.
✅ เคสที่ควรเริ่มก่อน
👉 Smoke test เช็คเร็วๆ ก่อน deploy: ไม่ต้องเทสละเอียด แค่เช็คเร็วๆ ก่อน เราต้องรู้ให้เร็วที่สุดว่าของที่จะเอาขึ้นไปยังใช้งานได้อยู่มั้ย คุ้มมาก เพราะจะได้รันทุกครั้งที่ deploy
👉 Regression ที่ต้องรันซ้ำทุกรอบ: เคสที่ต้องกดซ้ำบ่อยๆ ทุก sprint ทุกอาทิตย์ (หรืออาจจะบ่อยกว่านั้น) ยิ่งเราเห็นเคสไหนแล้วถอนหายใจว่าอีกแล้วเหรอ ก็อันนั้นแหละค่ะ
👉 เทสที่ต้องเช็คหลายอย่างพร้อมกัน: งานที่คนทำแล้วเหนื่อย พลาดง่าย เพราะมีหลายเงื่อนไขที่ต้องจำ ใช้ script ทำได้ดีกว่าเราแน่นอนค่ะ
👉 Flow ที่ stable แล้ว: ของที่ไม่ค่อยเปลี่ยน เขียนแล้วไม่ต้องเปลืองแรงมาดูแลเยอะ
.
❌ เคสที่เอาไว้ทีหลังดีกว่า
👉 เทสที่ทำครั้งเดียวจบ: งาน migration ที่ทำรอบเดียว กดมืออาจจะเสร็จก่อนเขียนโค้ดอีก
👉 Edge case ที่นานๆ เกิดที: อาจจะรู้สึกว่ามันควรมี จะได้ไม่หลุด แต่ผลตอบแทนที่ได้ต่อเวลาที่ลงไปอาจจะต่ำที่สุดก็ได้ค่ะ ถ้าต้องเลือก ก็เอาเคสแบบนี้ไว้ทีหลังดีกว่า มีเวลาค่อยกลับมาทำต่อ
👉 Feature ที่ยังเปลี่ยนบ่อย: เขียนวันนี้ พรุ่งนี้ต้องแก้อีกแล้ว เอาไว้ทำทีหลังดีกว่า
👉 Exploratory testing: tool ที่ช่วยได้ก็มีอยู่นะคะ แต่แก่นของมันคือความสงสัยของคนเทส ซึ่งยังเขียนเป็น script แทนไม่ได้ ถ้าเวลาน้อย อันนี้เลยยังไม่ใช่อันแรกที่ควรลงแรง
.
สังเกตดู พี่กิ่งใช้คำว่า “เอาไว้ทีหลัง” ไม่ใช่ “ไม่ควรทำ”
เพราะจริงๆ ทุกเคสเราสามารถทำ automation test ได้ทั้งหมดอยู่แล้วค่ะ
แต่จะคุ้มรึเปล่า ก็ต้องมาเลือกดูอีกที
ถ้าทีมเรา mature และมีเวลาพอ ก็อาจจะทำทั้งหมดได้
แต่ก็ควรเลือกอันที่คุ้มกว่ามาทำก่อนอยู่ดีค่ะ
.
✅ ลองเอาไปทำเลย
ถ้าใครไม่รู้จะเริ่มจากตรงไหน ลองเปิด test case ที่มีอยู่
แล้วเลือกมา 5 ข้อที่ตรงกับเคสที่ควรเริ่มก่อน แล้วก็เริ่มเลยค่ะ
เราควรจะเริ่มจากเคสที่ง่ายที่สุดก่อน ไม่ใช่เคสที่ยากที่สุด
หลายคนพลาดตรงนี้ เพราะรู้สึกว่าเคสยากๆ ควรทำก่อน แล้วก็ติดอยู่ตรงนั้นสามวัน
แทนที่เราจะทำเคสง่ายๆ ที่ทำได้ 5 ข้อในหนึ่งวัน แล้วเราก็ได้เทสที่มาช่วยเราเช็คได้ตั้งแต่วันแรกเลย
มันก็จะช่วยลดเวลาให้เราไปมีเวลาทำอย่างอื่นเพิ่มอีกค่ะ
ลองเลือกกันดู แล้วก็ทำเลยนะคะ
เป้าหมายของเราไม่ใช่ coverage 100%
แต่คือเทสที่เอาไปใช้รันได้จริง และช่วยลดเวลาให้เราได้จริง
.
การเลือกไม่ทำบางอย่าง ไม่ได้แปลว่าเราทำงานไม่ครบ
แต่มันแปลว่าเรารู้ว่าควรใช้เวลาที่มีอยู่อันน้อยนิดของเรา ไปกับตรงไหน