จะรู้ได้ยังไงว่าเราทำ Test ได้ดีพอรึยัง วิธีง่ายๆในการวัด Effectiveness และ Efficiency ของการ Test
QA หลายๆคนคงเคยมีคำถามว่า เราจะรู้ได้ยังไงว่าสิ่งที่ทำไปอยู่ทุกวันเนี่ย มันดีแล้วรึเปล่า ทำงานได้ Effective รึยังน้อ จะคุ้มเงินค่าจ้างที่เค้าให้เรามามั๊ยนะ (อันนี้อาจจะไม่ค่อยได้คิดกัน)
เรื่องนี้แม้แต่ผู้บริหาร หรือ QA Manager หลายๆท่านที่เคยได้เข้า class ที่ผู้เขียนสอน ก็มักจะมีคำถามว่า เราจะมีวิธีวัดประสิทธิภาพ และประสิทธิผลของการทำเทสยังไงได้บ้าง
จริงๆแล้วการวัด Effectiveness & Efficiency นั้นมีหลากหลายวิธีด้วยกัน แต่ขอเริ่มจากอันง่ายๆ ที่เคยเห็นเคยใช้มาก่อนแล้วกันนะครับ
เริ่มกันจาก 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%
จะเห็นได้ว่าตามวิธีนี้ เราassumeว่า บั๊กทั้งหมดที่มีใน software คือ บั๊กที่ Tester และลูกค้าตรวจพบรวมกัน ทีนี้จากค่า DDP ทำให้เรารู้ว่า Tester มีความสามารถในการตรวจจับ bug เป็น % เท่าไหร่ของจำนวน bug ทั้งหมดที่มีนั่นเอง เพราะฉะนั้นค่า
DDP ที่ดีที่สุดที่ทุกคนอยากได้คือ 100% (ซึ่งจะเกิดขึ้นในวันแรกที่ Release) หลังจากนั้นค่า DDP จะลดลงเรื่อยๆ ตามจำนวน bug ที่ลูกค้ารีพอร์ตเข้ามา
ในแต่ละทีม แต่ละองค์กร ควรจะกำหนดระยะเวลาที่จะ Monitor ค่า DDP อย่างเช่นตั้ง Target ไว้ว่า DDP ในช่วง 6 เดือนแรก ไม่ควรต่ำกว่า 70% เป็นต้น
ข้อควรระวังสำหรับการ Monitor ค่า DDP
ถ้าจำนวน Bug ทั้งหมดที่เจอน้อยเกินไป อย่างเช่น เราเจอ 1 ตัว ลูกค้าเจออีก 1 ตัว จะเห็นว่าค่า DDP จะเท่ากับ 50% เท่านั้น แต่ถ้าย้อนกลับมาดูภาพรวมแล้วจะเห็นว่ามี Bug ใน Software แค่2ตัวเท่านั้น ดังนั้นค่า DDP ที่จะนำมาพิจารณาควรจะมาจาก Product ที่มีจำนวน Bug รวมของทั้งที่ Tester และ ลูกค้าเจอเป็นจำนวนมากพอสมควรด้วย
ทีนี้เราลองมาดู Test Efficiency กันบ้างการวัด Test Efficiency นั้นมีหลากหลายวิธีอีกเช่นกัน แต่ที่ง่ายที่สุดและทำให้เห็นภาพรวมของความคุ้มค่าในการทำเทสที่เคยใช้มาน่าจะเป็นสูตรนี้ครับ
Test Efficiency = Effort ที่ใช้ทั้งหมดในการทำเทส / จำนวนของ Bug ที่ Tester พบ
ตัวอย่าง
ในการเทสหนึ่งโปรเจค Tester ทั้งหมดใช้ Effort 200 ชั่วโมง หา Bug เจอ 25 ตัว ดังนั้น
Test Efficiency = 200 / 25 = 8 Hrs/Bug
นั่นคือ Tester ใช้ Effort 8 ชั่วโมง กว่าจะหา Bug เจอ 1 ตัว
พอได้ข้อมูลมา แต่ละองค์กรคงต้องหาทางทำให้ Tester ใช้ Effort น้อยลงในการหา Bug หรือไม่ก็ ให้สามารถหา Bug ได้มากขึ้นโดยใช้ Effort เท่าเดิม วิธีง่ายๆ ก็อย่างเช่นการใช้ Test Automation การใช้ Testing Technique ต่างๆในการทำเทสครับ
ขอเปิดบทความแรกไว้เท่านี้ก่อนละกันครับ ไว้จะพยายามหา Topic มานำเสนออีก หรือไม่ก็อาจจะเพิ่มวิธีวัด Effectiveness & Efficiency มาเพิ่มเติมให้ครับ






นึกว่าใครมาเขียน พี่นัทนี่เอง หุหุ
เข้าไปตอบให้ในอีกหัวข้อแล้วนะครับ
http://www.welovebug.com/software-testing/test-efficiency-vs-test-effectiveness-difference-kpi/comment-page-1/#comment-417
ขอถามเพิ่มเติมค่ะ :-
Test Efficiency = Effort ที่ใช้ทั้งหมดในการทำเทส / จำนวนของ Bug ที่ Tester
ในส่วนของ “Effort ที่ใช้ทั้งหมดในการทำเทส” นี่ หมายถึงในช่วงการเทสใช่หรือป่าวค่ะ Effort ในส่วนอื่น ๆ เช่น ในการทำ Design , ฯลฯ นั้น จะไม่นำมานับรวมใช่หรือป่าวค่ะ ขอบคุณมากค่ะ
หืม ได้ความเข้าใจ เลยครับ ว่าระดับความสามารถของ tester เค้าวัดกันอย่างนี้เอง ดีมากเลยครับ แต่ก็นิดนึงครับ จะเอามาว่า tester อย่างเดียวเลยก็ไม่ถูก ขออนุญาต ปะ link เพื่อให้มันสอดคล้องกันครับ
http://www.welovebug.com/software-testing/software-testing-tester-5classic-problems-in-software-development-process/
ขออนุญาติช่วยจัด Layout ของบทความคุณนัทละกันนะครับ
เป็นความรู้ใหม่ที่ดีมากๆ เลยค่ะ
เพราะกำลังหาวิธีวัดประสิทธิภาพในการทำงาน
ของพนักงานเทสแต่ละคนอยู่พอดี ซึ่งวิธีนี้
ก็สามารถนำมาประยุกต์ใช้กับงานที่ทำอยู่ได้ดีเลยทีเดียว
ขอบคุณมากๆค่ะสำหรับข้อมูลดีดีแบบนี้
เป็นการเริ่มเกริ่นเกี่ยวกับ test matrix ที่ดีครับ น่าติดตามๆ นี่ถือเป็นคำถามยอดฮิตเลยครับ ว่าลงทุนไปกับ testing แล้วจะวัดยังไงว่าคุ้มไม่คุ้ม do we pay too much for cost of quality and what’s the balance? Keep it coming krub Nutdanai.