สำหระับข้อมูลดีดี

แอบนึกอะไรเล่นๆ ว่า จัดงานกันแบบสบายๆ มานั่งเสวนากันดีไหม

Confirmation test หรือ Re-Test = การเทสเพื่อคอนเฟิร์มว่า defect (bug) ที่เคยตรวจพบ ถูกแก้ไปเรียบร้อยแล้ว (จาก package test ที่กำลังเทสอยู่) แปลง่ายๆ ก็คือ การทำเทสเลียนแบบ (reproduce) การทำงานที่เคยเจอปัญหานั่นแหล่ะครับ เพื่อคอนเฟิร์มว่าบั๊กหายไปแล้วนั่นเอง

Regression test = การเทสเพื่อทำให้มั่นใจว่า change หรือการเปลี่ยนแปลงต่างๆที่เกิดขึ้นในโปรแกรม ไม่ว่าจะเกิดจากการ fix bug หรือการเพิ่ม feature ใหม่ๆเข้าไป ไม่ส่งผลกระทบต่อ function การทำงานที่เคยใช้งานได้อยู่นั่นเอง ดังนั้นถ้าถามว่า regression test ที่ดีที่สุดในแง่ quality คือทำยังไง ก็คงต้องบอกว่า คือการ run ทุกๆฟังก์ชั่นที่มีของโปรแกรมนั้น (ดีที่สุดในแง่ quality เพราะเทสหมดทุกฟังก์ชั่น) แต่การทำอย่างนั้นเป็นการทำให้ efficiency ของ tester น้อยที่สุดด้วยนะครับ ถ้าให้แนะนำคือ ควรมีการวิเคราะห์ก่อนว่า การ change ที่เกิดขึ้นมีโอกาสส่งผลกระทบกับฟังก์ชั่นไหนบ้าง แล้วค่อยเลือก regression test case มาเพื่อ run test
ทั้งนี้ทั้งนั้น ถ้า regression test ที่มี เป็น automation ทั้งหมด ก็คนละเรื่องกันครับ ถ้ารันหมดแล้วไม่เสีย effort เพิ่มก็ลุยโลด

ในส่วนของ Regression จริงๆแล้วผมมองในมุมเดียวกับ System testing หรือ Functional testing อื่นๆเลยครับ คือ มองในมุมที่ว่าเราจะตรวจพบ Bug ที่มีในโปรแกรมทั้งหมดได้มากน้อยเท่าไหร่ เพราะถ้ามองในมุมของลูกค้าแล้วเนี่ย ลูกค้าโดยส่วนใหญ่คงไม่สนใจว่าเป็นบั๊กที่เกิดจาก regression test หรือ เป็นบั๊กที่ตรวจพบจาก phase ไหนของการทำงานภายในของเรา ทีนี้ถ้ามองในมุม effectiveness & efficiency เนี่ย มองในภาพรวมของทีมครับ ฉะนั้นถ้าเป็นการทำงานของ Test team ทีมเดียวกัน ถึงแม้ว่าจะเป็นเทสเตอร์คนละคน ก็ควรจะนับจำนวน defect รวมกับ phase test execution ไปเลย

ทีนี้มาลองเข้าถึงคำถามสามข้อของคุณ Bugz Bunny บ้างครับ
- ในการที่ทำการทดสอบใน Regresion Testing Phase นั้น ยังพบ Defects ที่เกิดขึ้นใหม่
Nutdanai: เป็นเรื่องปกติครับ ถือเป็นเรื่องดี (สำหรับมุมมองของ tester) ด้วยซ้ำที่เราลงแรงเทสไปแล้วเจอผลลัพธ์ บรรลุ objective ของการทำเทส แต่ในมุมมองของ SDLC โดยรวมคงต้องไปวิเคราะห์กันว่าทำไม function เก่าที่เคยใช้งานได้ถึงมีผลกระทบ ในกรณีนี้ถ้าเป็นผม จะนับตัวเลขทุกอย่างของ efficiency&effectiveness รวมไปกับ phase ก่อนหน้าที่ test team เป็นคนทำเลยครับ

- ปัญหาที่พบใน System Testing นั้น ยังพบปัญหาอยู่ (Reopen)
Nutdanai: ขึ้นอยู่กับว่าปัญหาที่พบใน System testing นั้นถูกคอนเฟิร์มจากทาง Developer ว่า fix ไปหรือยัง ถ้ายังไม่ได้ตกลงกันว่าจะ fix ไม่ควร log defect เพิ่มครับ แต่ถ้า developer confirm ว่า fix แล้ว ควรจะนับเป็น defect เพิ่มเติมที่ tester ตรวจพบครับ ส่วนเรื่องการ manage defect flow ว่าจะเป็น re-open หรือเป็น defect ใหม่ก็แล้วแต่ process ขององค์กรนะครับ ในที่นี้แค่บอกว่าควรจะนับจำนวนเพิ่มตอนนำมาคิด efficiency & effectiveness

- การทำงานแทนกันในทีมงาน โดยที่ Tester A เป็นผู้เปิด Defects แต่ Tester B เป็นผู้ Regression
Nutdanai: ไม่แน่ใจว่า สถานการณ์คือ Tester A เป็นคน log defect แต่ Tester B เป็นคน run regression test แล้วเจอปัญหายังไม่ถูกแก้รึเปล่าครับ เดาว่าลิ้งค์จากข้อข้างบนละกันเนอะ ถ้าเป็นไปตามสมมติฐานนั้น ก็คิดค่าเท่าเดิมเลยครับ ไม่ว่าใครจะเปิดหรือปิดก็ตาม ถ้าจะดู efficiency&effectiveness กันเป็นทีมแล้วเนี่ย นับที่ตอนเจอรวมไปได้เลย ส่วนถ้าจะแยกการวัดเป็นรายบุคคล (จริงๆแล้วไม่ค่อยแนะนำครับ) ก็นับจำนวนแยกตอนเจอ defect เลยครับ ใครเจอเท่าไหร่ก็ให้ credit ตามจำนวนที่เค้าเจอเลย