เทคนิคการประมาณค่าการทดสอบในการทดสอบซอฟต์แวร์
โธมัส แฮมิลตัน
⚡ สรุปอย่างชาญฉลาด
เทคนิคการประมาณการการทดสอบซอฟต์แวร์เป็นการประมาณว่าการทดสอบจะใช้เวลานานเท่าใดและมีค่าใช้จ่ายเท่าใด กระบวนการสี่ขั้นตอน ได้แก่ การแบ่งงาน การมอบหมายผู้รับผิดชอบ การประมาณการความพยายาม และการตรวจสอบความถูกต้องกับผู้มีส่วนได้ส่วนเสีย จะเปลี่ยนกรอบเวลาที่ไม่ชัดเจนให้เป็นแผนงานที่สามารถพิสูจน์ได้และได้รับการอนุมัติจากฝ่ายบริหาร
การประมาณการทดสอบซอฟต์แวร์คืออะไร?
การประมาณการทดสอบซอฟต์แวร์ การประเมินระยะเวลาและค่าใช้จ่ายในการทดสอบ เป็นกิจกรรมการจัดการที่ประมาณการว่างานทดสอบจะใช้เวลานานเท่าใดและมีค่าใช้จ่ายเท่าใด การจัดทำประมาณการการทดสอบที่น่าเชื่อถือเป็นหนึ่งในความรับผิดชอบที่สำคัญที่สุด การจัดการทดสอบ เพราะมันมีผลต่อการตัดสินใจเรื่องกำหนดการ งบประมาณ และการจัดสรรทรัพยากร
เหตุใดการประมาณการทดสอบจึงมีความสำคัญ
ลูกค้ามักถามคำถามสองข้อก่อนอนุมัติการทดสอบเสมอ:
สำหรับโครงการขนาดเล็ก คำถามเหล่านี้ตอบได้ง่าย แต่สำหรับโครงการขนาดใหญ่ เช่น การทดสอบ Guruเว็บไซต์ 99 Bank — คุณต้องใช้เทคนิคที่เป็นระบบเพื่อสนับสนุนคำตอบ
จะประมาณค่าอะไร?
- แหล่งข้อมูล: บุคลากร อุปกรณ์ สถานที่ เงินทุน และสิ่งอื่นใดที่จำเป็นต่อการดำเนินงานให้สำเร็จลุล่วง
- เวลา: ทรัพยากรที่มีค่าที่สุดในทุกโครงการ — ทุกการปล่อยเวอร์ชันใหม่ย่อมมีกำหนดเวลา
- ทักษะด้านมนุษยสัมพันธ์: ความรู้และประสบการณ์ของทีม ทีมทดสอบที่มีประสบการณ์มากกว่าจะทำงานเสร็จเร็วกว่าทีมที่มีประสบการณ์น้อยกว่า
- ค่าใช้จ่าย: งบประมาณโครงการ — จำนวนเงินที่ต้องใช้ในการดำเนินการทดสอบตามแผนที่วางไว้
วิธีการประมาณการ
เทคนิคการประเมินผลการทดสอบซอฟต์แวร์ที่ใช้กันทั่วไป ได้แก่:
- โครงสร้างการแบ่งงาน (Work Breakdown Structure - WBS)
- การประมาณค่าแบบสามจุด
- เดลฟีแบบไวด์แบนด์
- การวิเคราะห์จุดฟังก์ชันหรือจุดทดสอบ
- วิธีการ Use-Case Point
- การกระจายตามเปอร์เซ็นต์
- วิธีการเฉพาะกิจ
กระบวนการสี่ขั้นตอนด้านล่างนี้เป็นการผสมผสานเทคนิคหลายอย่างเพื่อให้ได้การประมาณการที่น่าเชื่อถือ ตัวอย่างนี้ใช้... Guruกรณีศึกษาธนาคาร 99
ขั้นตอนที่ 1) แบ่งโครงการทั้งหมดออกเป็นงานย่อย
ใช้ โครงสร้างการแบ่งงาน เทคนิคในการแบ่งโครงการที่ซับซ้อนออกเป็นโมดูล โมดูลย่อย และท้ายที่สุดคือภารกิจที่เล็กที่สุดที่มีความหมาย การประมาณการจะน่าเชื่อถือมากกว่าเมื่อพิจารณาจากโครงการที่มีหัวข้อหลักไม่ชัดเจน
ใช้เทคนิคนี้เพื่อทำลาย Guruแบ่งโครงการ 99 Bank ออกเป็นห้าภารกิจย่อย:
จากนั้นแต่ละงานจะถูกแบ่งออกเป็นงานย่อย จนกระทั่งทุกบรรทัดมีรายละเอียดเพียงพอสำหรับการประเมิน
| งาน | งานย่อย |
|---|---|
| วิเคราะห์ข้อกำหนดซอฟต์แวร์ | ตรวจสอบรายละเอียดข้อกำหนด |
| สัมภาษณ์นักพัฒนาและผู้มีส่วนเกี่ยวข้องอื่นๆ เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับเว็บไซต์ | |
| สร้างข้อกำหนดการทดสอบ | ออกแบบสถานการณ์ทดสอบ |
| สร้างกรณีทดสอบ | |
| Revตรวจสอบและแก้ไขกรณีทดสอบ | |
| ดำเนินการกรณีทดสอบ | สร้างสภาพแวดล้อมสำหรับการทดสอบ |
| ดำเนินการทดสอบตามกรณีต่างๆ | |
| Revดูผลลัพธ์การดำเนินการทดสอบ | |
| รายงานข้อบกพร่อง | สร้าง ข้อบกพร่อง รายงาน |
| รายงานข้อบกพร่อง |
ขั้นตอนที่ 2) มอบหมายงานแต่ละอย่างให้สมาชิกในทีมแต่ละคน
มอบหมายงานย่อยแต่ละงานให้ผู้รับผิดชอบที่เหมาะสมที่สุด
| งาน | เจ้าของ |
|---|---|
| วิเคราะห์ข้อกำหนดซอฟต์แวร์ | สมาชิกทีมทุกคน |
| สร้างข้อกำหนดการทดสอบ | ผู้ทดสอบ / นักวิเคราะห์การทดสอบ |
| สร้างสภาพแวดล้อมการทดสอบ | ผู้ดูแลระบบทดสอบ |
| ดำเนินการกรณีทดสอบ | ผู้ทดสอบ, ผู้ดูแลการทดสอบ |
| รายงานข้อบกพร่อง | Tester |
ขั้นตอนที่ 3) การประเมินปริมาณงานสำหรับแต่ละภารกิจ
เทคนิคเสริมสองอย่างนี้ใช้ได้ผลดีในขั้นตอนนี้:
- วิธีการวัดจุดฟังก์ชัน (Function Point Method)
- การประมาณค่าแบบสามจุด
วิธีที่ 1) วิธีจุดฟังก์ชัน
ผู้จัดการทดสอบจะประเมินขนาด ระยะเวลา และค่าใช้จ่ายสำหรับแต่ละงาน
ขั้นตอน ก) ประเมินขนาดของงาน
ลองพิจารณาโจทย์ “สร้างข้อกำหนดการทดสอบ” ขนาดของข้อกำหนดนี้ขึ้นอยู่กับขนาดฟังก์ชันการทำงานของระบบที่กำลังทดสอบ ยิ่งมีฟังก์ชันมากเท่าไหร่ ระบบก็ยิ่งซับซ้อนมากขึ้นเท่านั้น โดยทั่วไปแล้ว คะแนนฟังก์ชันจะถูกจำแนกออกเป็นสามกลุ่ม ได้แก่ ซับซ้อน ปานกลาง และง่าย
โปรแกรมจัดการการทดสอบจะกำหนดน้ำหนักให้กับแต่ละฟังก์ชันพอยต์โดยพิจารณาจากความซับซ้อน:
| บัญชีกลุ่ม | การถ่วง |
|---|---|
| ซับซ้อน | 5 |
| กลาง | 3 |
| ง่าย | 1 |
การขอ Guruเว็บไซต์ของ 99 Bank แบ่งออกเป็น 12 ส่วนการทำงาน ความซับซ้อนของแต่ละส่วนสรุปไว้ด้านล่างนี้
| # | โมดูล | บทบาทที่เกี่ยวข้อง | Descriptไอออน | การถ่วง |
|---|---|---|---|---|
| 1 | สอบถามยอดคงเหลือ | ผู้จัดการฝ่ายลูกค้าสัมพันธ์ | ลูกค้า: ดูเฉพาะยอดคงเหลือในบัญชีของตนเองเท่านั้น ผู้จัดการ: ตรวจสอบยอดคงเหลือของลูกค้าทุกรายที่อยู่ภายใต้การดูแล |
3 |
| 2 | การโอนเงิน | ผู้จัดการฝ่ายลูกค้าสัมพันธ์ | ลูกค้า: โอนเงินจากบัญชีของตนเองไปยังปลายทางใดก็ได้ ผู้จัดการ: โอนเงินจากแหล่งใดก็ได้ไปยังปลายทางใดก็ได้ |
5 |
| 3 | คำชี้แจงขนาดเล็ก | ผู้จัดการฝ่ายลูกค้าสัมพันธ์ | รายการธุรกรรม 5 รายการล่าสุดของบัญชี ลูกค้า: ดูได้เฉพาะบัญชีของตนเองเท่านั้น ผู้จัดการ: ดูบัญชีใดก็ได้ |
3 |
| 4 | คำชี้แจงที่กำหนดเอง | ผู้จัดการฝ่ายลูกค้าสัมพันธ์ | กรองรายการธุรกรรมตามวันที่หรือมูลค่า ลูกค้า: เฉพาะบัญชีส่วนตัวเท่านั้น ผู้จัดการ: บัญชีใดก็ได้ |
5 |
| 5 | เปลี่ยนรหัสผ่าน | ผู้จัดการฝ่ายลูกค้าสัมพันธ์ | ลูกค้า: เปลี่ยนรหัสผ่านของคุณเอง ผู้จัดการ: เปลี่ยนรหัสผ่านของคุณเอง (ไม่ใช่รหัสผ่านของลูกค้า) |
1 |
| 6 | ลูกค้าใหม่ | ผู้จัดการ | เพิ่มและแก้ไขรายละเอียดลูกค้า (ที่อยู่ อีเมล เบอร์โทรศัพท์) | 3 |
| 7 | บัญชีใหม่ | ผู้จัดการ | บัญชีออมทรัพย์และบัญชีเดินกระแส; ลูกค้าสามารถมีบัญชีแต่ละประเภทได้หลายบัญชี ผู้จัดการจะเพิ่มบัญชีใหม่ให้กับลูกค้าปัจจุบัน | 5 |
| 8 | แก้ไขบัญชี | ผู้จัดการ | แก้ไขรายละเอียดของบัญชีที่มีอยู่แล้ว | 1 |
| 9 | ลบบัญชี | ผู้จัดการ | ลบบัญชีผู้ใช้ที่มีอยู่ของลูกค้า | 1 |
| 10 | ลบลูกค้า | ผู้จัดการ | ลบข้อมูลลูกค้าเฉพาะเมื่อไม่มีบัญชีลูกค้าที่ใช้งานอยู่แล้วเท่านั้น | 1 |
| 11 | เงินฝาก | ผู้จัดการ | ฝากเงินสดเข้าบัญชีใดก็ได้ที่สาขา | 3 |
| 12 | การถอน | ผู้จัดการ | ถอนเงินสดจากบัญชีใดก็ได้ที่สาขา | 3 |
ขั้นตอน ข) ประเมินระยะเวลาที่ใช้ในการทำงาน
เมื่อกำหนดระดับความซับซ้อนแล้ว ให้ประเมินระยะเวลาที่จำเป็นในการทดสอบแต่ละกลุ่ม
- ความพยายามโดยรวม: ทุ่มเทความพยายามอย่างเต็มที่เพื่อทดสอบทุกฟังก์ชันของเว็บไซต์
- คะแนนรวม: จำนวนโมดูลทั้งหมดของเว็บไซต์
- ประมาณการต่อ Function Point: ความพยายามโดยเฉลี่ยต่อคะแนน ขึ้นอยู่กับประสิทธิภาพการทำงานของทีม
สมมติว่าทีมประเมินต้นทุนต่อฟังก์ชันพอยต์ไว้ดังนี้ 5 ชั่วโมง/จุดความพยายามทั้งหมดสำหรับ Guruตัวอย่างของธนาคาร 99 คือ:
| บัญชีกลุ่ม | การถ่วง | จุดฟังก์ชัน | รวม |
|---|---|---|---|
| ซับซ้อน | 5 | 3 | 15 |
| กลาง | 3 | 5 | 15 |
| ง่าย | 1 | 4 | 4 |
| ฟังก์ชั่นคะแนนรวม | 34 | ||
| ประมาณการต่อจุด | 5 | ||
| ปริมาณงานที่คาดว่าจะต้องทำทั้งหมด (ชั่วโมงต่อคน) | 170 | ||
ระยะเวลาโดยรวมในการดำเนินการ "สร้างข้อกำหนดการทดสอบ" นั้นใช้เวลาประมาณ 170 ชั่วโมงต่อคนเมื่อทราบปริมาณงานแล้ว คุณสามารถจัดสรรทรัพยากรเพื่อกำหนดระยะเวลาและค่าใช้จ่ายได้
ขั้นตอน ค) ประเมินค่าใช้จ่ายสำหรับงานต่างๆ
ขั้นตอนนี้เป็นการตอบคำถามข้อที่สองของลูกค้า — “ค่าใช้จ่ายเท่าไหร่?” สมมติอัตราค่าบริการเฉลี่ยของทีมงานอยู่ที่ $ 5 ชั่วโมง /งานข้างต้นใช้เวลา 170 ชั่วโมง ดังนั้นค่าใช้จ่ายคือ 170 × $5 = $850นำวิธีการคำนวณเดียวกันนี้ไปใช้กับทุกงานในโครงสร้างการแบ่งงาน (WBS) เพื่อให้ได้งบประมาณของโครงการ
ยิ่งการประมาณการแม่นยำมากเท่าไหร่ คุณก็จะยิ่งบริหารงบประมาณของโครงการได้ดีขึ้น และมั่นใจได้ว่าทุกบาททุกสตางค์จะคุ้มค่า
วิธีที่ 2) การประมาณค่าแบบสามจุด
การประเมินค่าแบบสามจุด (Three-Point Estimation) เป็นเทคนิคที่มีโครงสร้าง โดยที่ผู้จัดการทดสอบจะระบุค่าสามค่าต่อภารกิจ — ในแง่ดี, มากที่สุดและ พูดในแง่ร้าย ความพยายาม — ขึ้นอยู่กับประสบการณ์เดิมหรือการคาดเดาที่ดีที่สุด
สำหรับหัวข้อ “สร้างข้อกำหนดการทดสอบ” ค่าทั้งสามอาจเป็นดังนี้:
- กรณีที่ดีที่สุด: ใช้เวลาทำงาน 120 ชั่วโมง (ประมาณ 15 วัน) โดยทีมงานที่มีประสบการณ์และเชี่ยวชาญ
- มีความเป็นไปได้มากที่สุด: 170 ชั่วโมงต่อคน (ประมาณ 21 วัน) โดยใช้ทีมงานและทรัพยากรตามปกติ
- กรณีที่เลวร้ายที่สุด: ใช้เวลาทำงาน 200 ชั่วโมง (ประมาณ 25 วัน) กับทีมงานที่มีประสบการณ์น้อย และต้องแก้ไขงานเพิ่มเติม
คำนวณค่าเฉลี่ยถ่วงน้ำหนักโดยใช้สูตรแบบ PERT:
มูลค่า E คือ ถัวเฉลี่ยถ่วงน้ำหนัก — ค่าประมาณหัวข้อข่าวสำหรับ “สร้างข้อกำหนดการทดสอบ”
เพื่อแสดงความมั่นใจเกี่ยวกับ Eคำนวณค่าเบี่ยงเบนมาตรฐาน:
สำหรับ Guruตัวอย่างธนาคาร 99 แห่ง การประมาณการคำนวณได้ดังนี้ 166.6 ± 13.33 ชั่วโมงต่อคน — อยู่ในช่วง 153.33 ถึง 179.99 ชั่วโมงต่อคน
ขั้นตอนที่ 4) ตรวจสอบการประมาณค่า
รวบรวมประมาณการงานทั้งหมดจาก WBS และส่งแผนงานให้คณะกรรมการบริหาร (ซีอีโอ ผู้จัดการโครงการ ผู้มีส่วนได้ส่วนเสียหลัก) ตรวจสอบและอนุมัติ
อธิบายรายละเอียดการประเมินราคาให้คณะกรรมการฟังอย่างมีเหตุผล เพื่อให้พวกเขาเข้าใจถึงข้อสมมติฐาน เทคนิคที่เลือกใช้ และแผนสำรองที่คุณได้กำหนดไว้
แนวปฏิบัติที่ดีที่สุดสำหรับการประมาณการทดสอบ
เพิ่มเวลาบัฟเฟอร์
แผนงานมักไม่สามารถคงอยู่ได้เมื่อเผชิญกับความเป็นจริง — สมาชิกในทีมลาออก การทดสอบใช้เวลานานกว่าที่คาดไว้ ความสัมพันธ์ระหว่างงานต่างๆ เปลี่ยนแปลงไป ควรเผื่อเวลาไว้ในประมาณการทุกครั้ง เพื่อให้ตารางเวลาสามารถรองรับความประหลาดใจเล็กน้อยได้
วางแผนความพร้อมของทรัพยากร
ควรคำนึงถึงการลาตามแผน การฝึกอบรม และการเข้าเวร การประมาณการที่ไม่ได้คำนึงถึงความพร้อมใช้งานอาจดูดีบนกระดาษ แต่จะผิดพลาดเมื่อนำไปใช้จริง
ใช้ประสบการณ์ในอดีตเป็นข้อมูลอ้างอิง
ข้อมูลในอดีตจากโครงการที่คล้ายคลึงกันนั้นมีค่าอย่างยิ่ง หากคุณเคยทดสอบเว็บไซต์ที่เทียบเคียงได้เมื่อปีที่แล้ว จงเรียนรู้จากผลลัพธ์ที่เกิดขึ้นจริง ปัญหาที่พบ และวิธีแก้ไขที่ช่วยกอบกู้สถานการณ์ไว้ได้
ยึดตามประมาณการไว้ แต่ควรกลับมาทบทวนอีกครั้ง
การประมาณการไม่สอดคล้องกันtracts; พวกมันเป็นเพียงการคาดเดาที่ดีที่สุด Revตรวจสอบแผนงานเป็นระยะๆ ตามเป้าหมายที่กำหนดไว้ และปรับเปลี่ยนเฉพาะเมื่อข้อกำหนดเปลี่ยนแปลงไปอย่างมีนัยสำคัญ หรือเมื่อมีข้อมูลใหม่เข้ามาเปลี่ยนแปลงสถานการณ์ เจรจาการเปลี่ยนแปลงใดๆ กับลูกค้าอย่างโปร่งใส
เทมเพลตการประมาณการทดสอบซอฟต์แวร์
ดาวน์โหลดไฟล์ Excel สำหรับประเมินผลการทดสอบซอฟต์แวร์ (.xlsx)
เทคนิคการประมาณค่าอื่นๆ
นอกเหนือจาก WBS, Function Point และการประเมินแบบสามจุดแล้ว ยังมีเทคนิคอื่นๆ อีกหลายเทคนิคที่ใช้กันอย่างแพร่หลาย:
- เดลฟีแบบไวด์แบนด์: การประเมินฉันทามติแบบวนซ้ำโดยคณะผู้เชี่ยวชาญ
- วิธีการพิจารณากรณีการใช้งาน: ความพยายามจะขึ้นอยู่กับจำนวนและความซับซ้อนของกรณีการใช้งาน
- การกระจายตามเปอร์เซ็นต์: จัดสรรสัดส่วนคงที่ของความพยายามทั้งหมดในโครงการให้กับการทดสอบ
- วิธีการเฉพาะกิจ: การตัดสินใจโดยผู้เชี่ยวชาญเมื่อขาดข้อมูลในอดีต
การประมาณค่าแบบจากล่างขึ้นบน เทียบกับการประมาณค่าแบบจากบนลงล่าง
มุมมองเชิงปฏิบัติเกี่ยวกับการประมาณการยังสามารถแบ่งออกเป็นสองกลยุทธ์ที่เสริมซึ่งกันและกัน:
- การประเมินจากล่างขึ้นบน: อิงตามภารกิจในระดับต่ำสุดของ WBS ผู้มีส่วนได้ส่วนเสียหลายฝ่าย พนักงานที่มีประสบการณ์ และผู้มีส่วนร่วมจะนำตัวเลขของตนมารวมกันเพื่อให้ได้ผลรวมที่ถูกต้อง เหมาะอย่างยิ่งเมื่อเข้าใจงานนั้นเป็นอย่างดี
- การประเมินจากบนลงล่าง: จำแนกโครงการตามขนาดและความซับซ้อน และเปรียบเทียบกับโครงการที่เสร็จสมบูรณ์แล้วที่มีลักษณะคล้ายคลึงกัน นอกจากนี้ยังใช้ค่าเฉลี่ยของความพยายามต่อโครงการด้วย กรณีทดสอบ และปรับขนาดตามจำนวนเคสที่คาดการณ์ไว้ มีประโยชน์ในช่วงเริ่มต้นโครงการเมื่อรายละเอียดมีจำกัด
ทีมส่วนใหญ่จะผสมผสานทั้งสองวิธีเข้าด้วยกัน คือใช้ข้อมูลจากบนลงล่างเพื่อให้ได้ตัวเลขสำคัญ และใช้ข้อมูลจากล่างขึ้นบนเพื่อสร้างความมั่นใจ จากนั้นจึงนำผลลัพธ์ไปซ้อนทับกับแบบจำลองที่ซับซ้อนเมื่องบประมาณเอื้ออำนวย
