การวัดประสิทธิภาพการทดสอบ / ทดสอบที่ดีคืออะไร?


11

ฉันกำลังจะเข้าร่วมการสนทนากับฝ่ายบริหารเกี่ยวกับการวัดประสิทธิภาพการทดสอบของเราในฐานะองค์กร QA เหตุผลหลักที่อยู่เบื้องหลังคือว่าทีมงานของเราครึ่งหนึ่งถูกทำสัญญาและธุรกิจของเราต้องการที่จะให้ข้อมูลบางอย่างเกี่ยวกับประสิทธิภาพและประสิทธิภาพของเราดังนั้นเราจึงมีข้อมูลพื้นฐานที่จะเจรจาต่อรองพารามิเตอร์สัญญากับข้อตกลงการบริการของผู้รับเหมาของเรา .

ฉันแหย่ไปรอบ ๆ เล็กน้อยและส่วนใหญ่ของความเห็นที่ฉันได้พบในเรื่องนี้เกี่ยวกับประสิทธิภาพของนักพัฒนา: บรรทัดของรหัสจุดเรื่องราวส่งมอบข้อบกพร่องแนะนำ ฯลฯ

แต่แล้วผู้ทดสอบล่ะ การทดสอบของเรานั้นเป็นไปตามความต้องการเป็นส่วนใหญ่และการทดสอบด้วยตนเองกึ่งอัตโนมัติและการทดสอบอัตโนมัติ (ไม่ใช่เพราะเราไม่ได้มีระบบอัตโนมัติทุกอย่าง แต่เนื่องจากบางสิ่งไม่สามารถทำงานได้อัตโนมัติในระบบทดสอบของเรา)


1
stevemcconnell.com/ieeesoftware/bp09.htmอาจมีประโยชน์ในทางใดทางหนึ่ง

มันแปลก ๆ. หากคุณทดสอบ gmail.com แล้วพบข้อบกพร่องเดียวคุณคิดว่าคุณล้มเหลวหรือไม่ หากคุณเขียนกรณีทดสอบมากกว่าหนึ่งล้านชิ้นสำหรับเรื่องเล็ก ๆ น้อย ๆ คุณคิดว่ามันประสบความสำเร็จหรือไม่? มองหา Defect Leakage ซึ่งหมายถึงข้อบกพร่องที่ไม่ปรากฏใน SIT และเล็ดรอดผ่าน UAT มีวิธีอื่น ๆ QA เพิ่มมูลค่าให้กับ SDLC โดยรวม

คำตอบ:


8

จำนวนการทดสอบที่เขียนนั้นไม่มีประโยชน์และพบข้อบกพร่องจำนวนมากสามารถเป็นตัวชี้วัดของการพัฒนาที่ไม่ดีมากกว่าการใช้ QA ที่มีประสิทธิภาพ

การวัดอัตโนมัติ (การครอบคลุมโค้ด, การครอบคลุมคุณสมบัติ ... ) ทำได้ดี แต่ฉันคิดว่าพวกเขาช่วยพัฒนาได้มากกว่า (ในฐานะนักพัฒนาฉันจะรู้ได้หรือไม่ว่าฉันทำอะไรผิดพลาด) กว่าลูกค้า (ฉันต้องการทำเช่นนั้นและ มันไม่ทำงาน)

นับตั้งแต่ที่มีคุณภาพเป็นสิ่งที่ดีถ้าลูกค้าไม่พบปัญหาจึงเป็นมาตรการที่ดีของความมีประสิทธิภาพ (ไม่ได้อย่างมีประสิทธิภาพ) จากทีมงานประกันคุณภาพและกระบวนการเป็นตัวชี้วัดของข้อบกพร่องที่พบจากลูกค้าที่ยังไม่ได้รับการค้นพบโดย QA

ปัญหาหลักของตัวชี้วัดนั้นคืออาจมีความล่าช้ามากระหว่างงานที่ทำและเมื่อคุณเริ่มมีตัวเลขที่มีความหมาย


1
ในที่สุด +1 ความพึงพอใจของลูกค้าเป็นตัวชี้วัดหลักสำหรับทีมทั้งหมด
jk


6

มีการวัดสองสามอย่างที่เราใช้ในงานล่าสุดของฉันเพื่อประเมิน QA:

  • จำนวนข้อบกพร่องที่พบ ฉันเกลียดอันนี้ มันเหมือนกับ "จำนวนบรรทัดของโค้ดที่เขียน" สำหรับนักพัฒนา
  • จำนวนกรณีทดสอบอัตโนมัติที่ผลิต
  • ร้อยละของการใช้งานทั้งหมดที่ครอบคลุมในการทดสอบการทำงาน
  • จำนวนข้อบกพร่องที่พบในการจัดเตรียมการผลิต

ในท้ายที่สุดงานของทีมงาน QA ของคุณคือการค้นหาข้อบกพร่องก่อนที่พวกเขาจะออกไปในป่า ตัวชี้วัดของพวกเขาควรอยู่บนพื้นฐานของการบรรลุเป้าหมายนั้นจริง หากมีความครอบคลุมต่ำของกรณีทดสอบจำนวนการทดสอบอัตโนมัติน้อยที่สุดและอัตราการผลิตที่สูงของข้อบกพร่องแสดงว่าพวกเขาไม่ได้ทำงานที่ดี อย่างไรก็ตามหากพวกเขามีประวัติที่ดีในการค้นหาข้อบกพร่องนานก่อนที่พวกเขาจะตีแยงตัวชี้วัดของพวกเขาควรจะค่อนข้างสูง


3
เพียงหมายเหตุ: สามข้อแรกคือตัวชี้วัดการจัดการซึ่งหมายความว่าผู้จัดการผู้รับเหมาควรพยายามปรับให้เหมาะสมในระยะเวลาอันใกล้ (รายเดือนหรือรายไตรมาส) อย่างไรก็ตามมีเพียง 4 คนมีผลกระทบทางธุรกิจที่แท้จริงและควรจะใช้เป็นแต่เพียงผู้เดียวเป็นพื้นฐานสำหรับการต่ออายุสัญญา (ผู้จัดการที่ไม่ดีอาจทำคะแนนได้ดีมากในสามตัวชี้วัดแรกโดยขยายตัวเลข แต่ก็ยังปล่อยให้แมลงจำนวนมากรั่วไหลออกสู่สาธารณะ) โชคไม่ดีที่อันดับ 4 มีรอบการรวบรวมข้อมูล 2-3 ปี

การทดสอบการทำงานควรเป็นการทดสอบกล่องดำหรือฉันผิด
BЈовић

"จำนวนข้อผิดพลาดที่พบ": ควรใช้การวัดกับนักพัฒนา ยิ่งกว่านั้นหากในฐานะผู้ทดสอบที่ฉันได้รับตัวบ่งชี้นี้ฉันจะกลายเป็นเพื่อนกับนักพัฒนาที่ยินดีแนะนำข้อบกพร่องในรหัสที่ฉันทดสอบ
mouviciel

3

ควรตรวจวัดคุณภาพด้วยสองตัวชี้วัดหลัก: มีข้อบกพร่องกี่ข้อที่จะได้รับ QA ที่ผ่านมาในฟิลด์ ความรุนแรงของพวกเขาคืออะไร?

คุณอาจจะสามารถ ding QA สำหรับการค้นหาข้อบกพร่องที่รุนแรงใกล้กว่าที่จะปล่อยกว่า dev-complete คุณอาจสามารถ ding QA สำหรับการไม่ทำการทดสอบตามวันที่เสร็จสมบูรณ์โดยประมาณ (ต่อคุณสมบัติ)

แม้ว่าในท้ายที่สุดฉันกลัวว่าคุณจะใช้จ่ายเงินมากขึ้นในการวัดประสิทธิภาพของพนักงานที่ทำสัญญาของคุณมากกว่าการประหยัดที่ได้รับจากการใช้พนักงานที่ทำสัญญา ...


0

บริษัท ที่ฉันทำงานอยู่ใช้ตัวชี้วัด QA จำนวนหนึ่ง

สิ่งที่ฉันรู้สึกว่าเกี่ยวข้องมากที่สุดคือการครอบคลุมโค้ด เครื่องมือเช่นEMMA ใช้งานได้ดีในขณะที่พวกเขาเขียนการทดสอบอัตโนมัติอย่างละเอียดนอกเหนือจากการทดสอบด้วยตนเอง

ไม่ว่าคุณจะทำอะไรอย่ามุ่งเน้นไปที่จำนวนการทดสอบ มันมีประโยชน์มากเท่ากับ LOC ต่อวัน


-1

หลายวิธีในการวัดประสิทธิภาพในการพัฒนาและทดสอบเฟสในระหว่างการดำเนินโครงการ เราใช้มาตรการด้านล่างในโครงการของเรา ประสิทธิภาพการพัฒนาวัดโดยตัวชี้วัดรหัสยอดนิยม 4 รายการ (ดัชนีการบำรุงรักษา, ความซับซ้อนของ Cyclometric, ความลึกของการสืบทอด, ข้อต่อระดับ) สำหรับ C # จะได้รับใน Microsoft Visual Studio สำหรับการครอบคลุมการทดสอบ Ncover / Ndepend มีประโยชน์มาก ประสิทธิภาพการทดสอบที่วัดได้โดยไม่มีการพัฒนาบั๊ก - วิ่งผ่าน 4 sprints ที่ผ่านมาข้อบกพร่องในการทดสอบระบบหมุนไป 4 sprints ล่าสุด ไม่มีการทดสอบระบบอัตโนมัติที่ส่งผ่านโดยเฉพาะในคุณสมบัติ / การส่งมอบ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.