Testing Doesn't Finish…It's Just STOP!
Test Efficiency Vs Test Effectiveness ความแตกต่าง และ การวัดค่า
หลังจากที่ได้อ่านบทความของ K.Nutdanai เรื่อง “จะรู้ได้ยังไงว่าเราทำ Test ได้ดีพอรึยัง วิธีง่ายๆในการวัด Effectiveness และ Efficiency ของการ Test” แล้ว ครั้งแรกที่ได้อ่านก็ไม่ได้คิดสงสัยอะไรค่ะ แต่เมื่อจะลองนำมาใช้งานจริงแล้วก็ ทำให้เกิดความสงสัยอันมากล้นบวกกับการคุยกันในทีมแล้วพบข้อสงสัยจนยากจะยุติลงได้(เกริ่นซะเว่อร์กันทีเดียว) เมื่อเป็นเช่นนั้นแล้ว คงไม่มีวิธีใดจะดีกว่าการได้รับข้อมูลเพิ่มเติมค่ะ
ทั้งนี้ จึงขออนุญาตตั้งหัวข้อเรื่องใหม่เลยก็แล้วกันนะค่ะ เพื่อที่จะเป็นอีกส่วนนึงที่จะอธิบาย / ขยายความเพิ่มเติม รวมทั้งอาจเป็นที่แชร์ประสบการณ์ สำหรับหลาย ๆ ท่าน ที่ได้ลองนำไปใช้จริงกันแล้วว่ามีความคิดเห็นกันประการใดนะค่ะ
Test Effectiveness
DDP (Defect Detection Percentage) เป็นการวัดประสิทธิภาพในการหา Bug ของ Tester เทียบกับจำนวน Bug ทั้งหมดที่มีใน Software
สูตรง่ายๆ ของวิธีการวัด DDP
[ จำนวน Bug ที่ Tester หาเจอในโปรเจคก่อน Release / (จำนวน Bug ที่ Tester หาเจอในโปรเจคก่อน Release + จำนวน Post Release Bug ที่ลูกค้ารีพอร์ตเข้ามา) ] * 100
ตัวอย่าง
ในโปรเจคหนึ่ง Tester เจอบั๊ก 10 ตัว และหลังจากที่ Release Product ออกไปหกเดือน ลูกค้ารีพอร์ต Bug เข้ามา 5 ตัว ฉะนั้นค่า
DDP = [10/(10+5)]*100 = 66%
จากการคำนวณ Test Effectiveness นี้ จำนวน Bug ที่นำมาใช้ในการคำนวณนั้น จะไม่ได้มีการแบ่งระดับความรุนแรงของ Bug แต่ละข้อ ซึ่งทำให้
- Project A :-
พบ Defect ดังนี้ High 2 , Meduim 3 , Low 5
DDP = [5/(10+2)]*100 = 41.66%
- Project B :-
พบ Defect ดังนี้ High 5 , Meduim 2 , Low 5
DDP = [5/(12+0)]*100 = 41.66%
จากข้างต้นจะพบว่า Tester ทั้ง 2 คน มี Test Effectiveness เท่ากัน แต่ทางผู้เขียนเอง มีแนวคิดว่า หากสามารถทราบได้ด้วยว่า Test Effectiveness นั้น เมื่อนำมาเปรียบเทียบกับความรุนแรงของ Defect ที่พบแล้วเป็นอย่างไรบ้าง คงจะดีไม่น้อยค่ะ
Test Efficiency
วิธีการคำนวณ
Test Efficiency = Effort ที่ใช้ทั้งหมดในการทำเทส / จำนวนของ Bug ที่ Tester พบ
อยากให้อธิบายเพิ่มเกี่ยวกับ “Effort ที่ใช้ทั้งหมดในการทำเทส” ด้วยค่ะ ว่าในส่วนนี้เริ่มนับตั้งแต่เมื่อใด นำเวลาในการทำงานส่วนใด หรือ Phase ไหนมาคิดบ้างค่ะ
อย่างไรก็ดี รบกวนทุก ๆ ท่าน พี่ ๆ น้อง ๆ ชาว We Love Bug ช่วยแนะนำ้ หรือ แชร์ประสบการณ์กันได้เลยค่ะ ฝากทิ้งท้ายบทความนี้ ด้วยข้อความนึง
Efficiency แปลว่า ประสิทธิภาพ = Doing the thing right
Effectiveness แปลว่า ประสิทธิผล = Doing the right thingเครดิต : K. รถร่วม
| Print article | This entry was posted by Bugz Bunny on April 21, 2009 at 8:07 pm, and is filed under Software Testing. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |

about 1 year ago
จริงๆ แล้วเอาตามความเข้าใจของตัวเองนะคะ
1. Develop Test Plan คือ การวางแผนการทดสอบ ซึ่งใน Test Plan จะมีองค์ประกอบหลายส่วน
1. Test Schedule
2. Test Strategy
3. Risks and Assumption
2. Developt Test Script/Test Case
Test Script จะกำหนดขั้นตอนและลำดับการทดสอบ รวมถึงกำหนด Scenario
Test Case เป็น Subset ของแต่ละ Scenario อีกที ซึ่งโดยปกติ Test Case ที่ทำจะระบุ Test Data ที่จะใช้ Input เข้าไปเพื่อทดสอบระบบด้วยค่ะ
แต่สิ่งที่อยากได้ คือ อยากดูตัวอย่างทั้ง Test Plan & Test Script ที่องค์กรอื่นเค้าทำงานกันค่ะ เพราะเกิดความไม่แน่ใจในเอกสารที่ทำงานอยู่ในปัจจุบัน ว่าถูกต้องหรือไม่ค่ะ
ขอบคุณ K. Natdanai มากๆ นะคะ
about 1 year ago
ตามสัญญา เขียนบทความเกี่ยวกับ Test plan กับ Test script ไปแปะไว้ให้แล้วนะครับ เข้าไปดูที่หน้าแรกได้เลยครับ
about 1 year ago
ไม่แน่ใจว่าเข้าใจถูกหรือเปล่า แต่ถ้าพูดถึง Test Plan กับ Test Script เนี่ยเป็น document คนละประเภทกันเลยนะครับ ถ้าเป็นไปได้ช่วยระบุหน่อยครับว่าอยากได้ตัวอย่างหรือข้อมูลด้านไหน
คิดว่าหัวข้อต่อไปที่จะเขียนอาจจะเขียนอธิบายว่า Test plan คืออะไร ตามstandard แล้วประกอบด้วยข้อมูลอะไรบ้างดีมั๊ยครับ อาจจะมีเสริมๆด้วยว่า Test script คืออะไร test condition คืออะไร test case คืออะไร เพราะคิดว่าน่าจะมีสับสนกันบ้างหล่ะสำหรับนิยามของคำศัพท์กลุ่มนี้
about 1 year ago
K. Nutdanai มีตัวอย่างการทำ Test Plan / Test Script มั้ยคะ
about 1 year ago
thanks for good article
about 1 year ago
ขอขอบคุณ K. Nutdanai มาก ๆ ค่ะ ถามปุ๊บ ตอบปั๊บ กันเลยทีเดียวค่ะ ได้คำอธิบายที่ชัดเจน แถมช่วยเพิ่มเรื่อง DM Rate มาให้ด้วย ขอบคุณมาก ๆ ค่ะ … *v*
about 1 year ago
ลืมบอกไปว่า DM Rate ย่อมาจาก Defect Measure Rate ครับ
วันนี้ค่อนข้างเบลอๆ อาจจะเขียนแล้วงงๆไปบ้าง ถ้าอ่านแล้วสงสัยตรงไหนก็ถามกลับมาได้เลยนะครับ แฮ่ะๆ
about 1 year ago
มาต่อกันเรื่อง Test efficiency นะครับ จริงๆแล้วจะนำ effort ส่วนไหนมาคิดคำนวนบ้างเนี่ยค่อนข้างจะยืดหยุ่นขึ้นอยู่กับว่าเราอยากจะ Focus ทางด้านไหนนะครับ แต่โดยปกติจะนำ effort ที่เกี่ยวข้องกับ test team ทั้งหมดมาคิดนั่นคือ Test plan + Test design&Preparation + Test execution ครับ ที่เคยทำมาเนี่ยจะไม่นับ effort ส่วนที่ developer ใช้ในการ fix bug นะครับ เพราะเราต้องการดู efficiency ของ test team ว่าเราลงทุนลงแรงไปเท่าไหร่ แล้วได้รับผลกลับมาเท่าไหร่ หรือดูว่าลงแรงไปกี่ชั่วโมงกว่าจะเจอบั๊กซักตัวนั่นเอง
ทีนี้มันจะมีเมตริกอีกตัวที่ชื่อ DM Rate ครับ สามารถนำมาประยุกต์ใช้ด้วยกันได้ ถ้าสนใจอยากเอา severity ของบั๊กเข้ามาเกี่ยวข้องด้วย
สูตรของ DM Rate คือ DM = 10*H+5*M+L
DM Rate = DM/Hours of test effort
ตัวเลข 10, 5, xx พวกนี้สามารถปรับได้นะครับ พูดง่ายๆคือเรามีการให้ wage กับความรุนแรงของบั๊กที่เจอด้วย เพราะ efficiency คือการดูความคุ้มค่า ฉะนั้นความคุ้มค่าก็จะเกี่ยวเนื่องกับ cost ที่กล่าวไปข้างต้น ดังนั้นก็ควรจะให้เครดิตกับการเจอบั๊กที่มีความรุนแรงมากเป็นพิเศษเพราะช่วยให้ save cost of low quality ได้เยอะครับ
about 1 year ago
ยินดีที่บทความที่เขียนไว้กระตุ้นความสงสัยจนมากล้นครับ
เลยลองมาตอบคำถามบวกกับเพิ่มความคิดเห็นส่วนตัวให้ดังนี้ครับ
ขอเริ่มตอบจาก DDP ก่อนแล้วกันครับ
อย่างแรกเลย ต้องทำความเข้าใจก่อนว่า DDP นั้นจริงๆแล้วไม่ได้มีจุดประสงค์ในการวัดประสิทธิภาพในการทำงานของ Tester เอง แต่เพื่อใช้วัดในระดับองค์กรว่า มีความสามารถในการตรวจเจอบั๊กก่อนที่จะส่งมอบโปรแกรมให้ลูกค้ามากหรือน้อยแค่ไหน ดังนั้น severity ของบั๊กจึงไม่ได้ถูกนำมา focus มากนักเนื่องจากเรามองในภาพของจำนวนบั๊กทั้งหมดใน product
ถ้ามองในมุมของ severity เข้ามาเกี่ยวข้องเนี่ย น่าจะเกี่ยวข้องกับมุมของ cost effectiveness ด้วยมากกว่าหน่ะครับ เพราะว่าถ้าเราเจอบั๊กที่มี severity สูง นั่นหมายความว่าโอกาสที่ลูกค้าจะไม่เจอบั๊กที่ส่งผลกระทบกับ production ของเค้าก้อมีมากขึ้นด้วย ฉะนั้น cost of low quality ทั้งในแง่ของเราและลูกค้าก็จะต่ำ ยกตัวอย่าง cost of low quality ของเราก็อย่างเช่น การเสียชื่อเสียงขององค์กร หรือในบางกรณีถ้าโปรแกรมของเรามีบั๊กประเภทรุนแรง เราอาจจะโดนปรับด้วยถ้ามีการระบุไว้ในสัญญา
ทั้งหลายทั้งปวงนี้ก็ขึ้นอยู่กับว่าเราอยากจะใช้ DDP เพื่อเอาไว้บ่งชี้อะไร ถ้าให้แนะนำคือนับ High severity กับ Medium severity รวมกันไปเลยแล้วตัด Low severity ออก แต่ที่สำคัญที่สุดคือ เรานับอันไหนของ System test ก็ต้องนับของที่ลูกค้าแจ้งเข้ามาให้เหมือนกัน อย่างเช่นถ้าของ system test นับเฉพาะ high & medium ของ post release ที่ลูกค้าแจ้งเข้ามาก็ต้องนับเฉพาะ high & medium เหมือนกันครับ