Test efficiency กับ Regression Testing
กลับมาพบกันอีกครั้งแล้วนะค่ะ ช่วงนี้อากาศค่อนข้างเย็น และ ฝนตกพร่ำ ๆ ตลอดทั้งวัน หรือบางวัน ยังกับฟ้ารั่วกันทีเดียว อย่างไร ก็รักษาสุขภาพกันด้วยนะค่ะ ด้วยความห่วงใยค่ะ
เข้าเรื่องกันต่อ จากบทความก่อนหน้านี้เกี่ยวกับ Test Efficiency ที่ได้ K.Nutdanai มาอธิบายความหมาย วิธีการคำนวณ รวมถึงการนำไปใช้นั้น ไม่ทราบว่า เหล่าสมาชิก Welovebug แต่ละท่าน ทั้งที่เคยใช้ Test Efficiency อยู่แล้วจนเชี่ยวชาญ หรือ ผู้ที่เพิ่งเริ่มจะมีการคำนวณ Test efficiency นั้น ลองนำไปคำนวณดูกันแล้ว ได้ผลเป็นอย่างไรกันบ้างค่ะ หวังว่าจะมาบอกกล่าว เล่าให้ฟังกันบ้างนะค่ะ
ในส่วนของผู้เขียนเอง ได้ลองนำไปใช้แล้ว พบปัญหาจึงมาขอถามเพื่อไขข้อข้องใจไว้แล้วในเรื่อง “Test Efficiency Vs Test Effectiveness ความแตกต่าง และ การวัดค่า” และหลังจากที่ได้รับการขยายความพร้อมคำแนะนำดี ๆ จากคุณ Nutdanai แล้ว อยากจะขอสืบต่อจากบทความที่แล้วขึ้นไปอีกค่ะ ทั้งนี้ทั้งนั้น ขออนุญาตนำข้อความจากคุณ Nutdanai มาขยายความต่อและเป็นแหล่งอ้างอิงของบทความนี้อีกทีนะค่ะ
จากบทความที่แล้ว ซึ่งมีรายละเอียดดังนี้
Bugz Bunny: “Effort ที่ใช้ทั้งหมดในการทำเทส นั้น เริ่มนับตั้งแต่เมื่อใด นำเวลาในการทำงานส่วนใด หรือ Phase ไหนมาคิดบ้าง”
K. Nutdanai: “จริงๆแล้วจะนำ effort ส่วนไหนมาคิดคำนวนบ้างเนี่ยค่อนข้างจะยืดหยุ่นขึ้นอยู่กับว่าเราอยากจะ Focus ทางด้านไหนนะครับ โดยปกติจะนำ effort ที่เกี่ยวข้องกับ test team ทั้งหมดมาคิดนั่นคือ Test plan + Test design&Preparation + Test execution“
เมื่อผู้เขียนนำข้อมูลที่ได้ข้างต้นมาลองคำนวณแล้ว พบว่า มีตัวเลขที่เห็นได้อย่างชัดเจนที่เดียวค่ะ แต่ในกระบวนการทดสอบ (Test Process) นั้น จะไม่ได้จบที่ Test Execution เท่านั้น ยังคงจะต้องดำเนินการต่อไปยังกระบวนการที่เรียกว่า Regression Testing (ทั้งนี้ ทางทีมงานของผู้เขียนเองมีการแยก Phase ของการดำเนินงานออกเป็น Test Exceution (System Testing , Performance Testing) และ Regression Testing ออกจากกันนะค่ะ) ทำให้ พบรายละเอียดเพิ่มเติมดังนี้ค่ะ
- ในการที่ทำการทดสอบใน Regresion Testing Phase นั้น ยังพบ Defects ที่เกิดขึ้นใหม่
- ปัญหาที่พบใน System Testing นั้น ยังพบปัญหาอยู่ (Reopen)
- การทำงานแทนกันในทีมงาน โดยที่ Tester A เป็นผู้เปิด Defects แต่ Tester B เป็นผู้ Regression
ไม่ทราบว่า ในกรณีข้างต้น ไม่ทราบว่า มีการนำมาคำนวณ Test efficiency บ้างหรือป่าวค่ะ และมีการคำนวณอย่างไรค่ะ
ท้ายนี้ อยากให้บทความนี้ เป็นอีกหนึ่งบทความในการแบ่งปันประสบการณ์ และ ความคิดเห็นในแง่มุมต่าง ๆ กันบ้างนะค่ะ
about 1 year ago
ขอบคุณทั้ง Bugz Bunny และคุณ Nutdanai ครับ
สำหระับข้อมูลดีดี
แอบนึกอะไรเล่นๆ ว่า จัดงานกันแบบสบายๆ มานั่งเสวนากันดีไหม
about 1 year ago
ขอขอบคุณมากมายเลยค่ะ สำหรับคำตอบเพื่อไขข้อข้องใจ รวมถึงคำแนะนำต่าง ๆ ที่ K. Nutdanai มาให้ความรู้กันแบบชัดเจน อีกแล้วค่ะ รวมถึง รวดเร็วทันใจสุด ๆ ค่ะ ขอบคุณมาก ๆ นะค่ะ หากชาว Welovebug ท่านใด มีข้อเสนอแนะ หรือ จะมาเล่ามาแชร์อะไรในแง่มุมต่างๆ เกี่ยวกับเรื่อง Test efficiency ก็ขอเชิญนะค่ะ หรือสนใจเรื่องอื่น ๆ ก็แวะกันเข้ามาค่ะ *v*
about 1 year ago
เสริมคำศัพท์น่ารู้ให้นิดนึงครับ
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 เพิ่มก็ลุยโลด
about 1 year ago
คุณ Bugz Bunny มีคำถามชวนคิดมาให้สนุกอีกแล้วนะครับ ชอบจัง
ขอตอบในมุมมองของตัวเองก่อนนะครับ วานกูรูทั้งหลายช่วยเสนอแนะเพิ่มเติมกันหน่อย
ในส่วนของ Regression จริงๆแล้วผมมองในมุมเดียวกับ System testing หรือ Functional testing อื่นๆเลยครับ คือ มองในมุมที่ว่าเราจะตรวจพบ Bug ที่มีในโปรแกรมทั้งหมดได้มากน้อยเท่าไหร่ เพราะถ้ามองในมุมของลูกค้าแล้วเนี่ย ลูกค้าโดยส่วนใหญ่คงไม่สนใจว่าเป็นบั๊กที่เกิดจาก regression test หรือ เป็นบั๊กที่ตรวจพบจาก phase ไหนของการทำงานภายในของเรา ทีนี้ถ้ามองในมุม effectiveness & efficiency เนี่ย มองในภาพรวมของทีมครับ ฉะนั้นถ้าเป็นการทำงานของ Test team ทีมเดียวกัน ถึงแม้ว่าจะเป็นเทสเตอร์คนละคน ก็ควรจะนับจำนวน defect รวมกับ phase test execution ไปเลย
ทีนี้มาลองเข้าถึงคำถามสามข้อของคุณ Bugz Bunny บ้างครับ
แต่ในมุมมองของ SDLC โดยรวมคงต้องไปวิเคราะห์กันว่าทำไม function เก่าที่เคยใช้งานได้ถึงมีผลกระทบ ในกรณีนี้ถ้าเป็นผม จะนับตัวเลขทุกอย่างของ efficiency&effectiveness รวมไปกับ phase ก่อนหน้าที่ test team เป็นคนทำเลยครับ
- ในการที่ทำการทดสอบใน Regresion Testing Phase นั้น ยังพบ Defects ที่เกิดขึ้นใหม่
Nutdanai: เป็นเรื่องปกติครับ ถือเป็นเรื่องดี (สำหรับมุมมองของ tester) ด้วยซ้ำที่เราลงแรงเทสไปแล้วเจอผลลัพธ์ บรรลุ objective ของการทำเทส
- ปัญหาที่พบใน 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 ตามจำนวนที่เค้าเจอเลย
about 1 year ago
this is the case with junior programmers