ข้อสังเกตว่าการยุบทีม QA อาจเป็นการตัดสินใจที่ผิด

 (davidkcaudill.medium.com)
5 คะแนน โดย GN⁺ 2023-12-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การยุบทีม QA อาจเป็นการตัดสินใจที่แย่จริง ๆ

  • ส่วนที่ช้าที่สุดของการปล่อยซอฟต์แวร์คือการทดสอบ เหตุผลที่มีการ deploy อย่างต่อเนื่องก็เพราะการทดสอบ ดังนั้นการที่สิ่งนี้กลายเป็นคอขวดจึงถือว่าเป็นสภาพที่ถูกปรับให้เหมาะสมแล้ว
  • นิสัยและพฤติกรรมที่เน้นการเพิ่มประสิทธิภาพทำให้อุตสาหกรรมมีแนวโน้มมองทีม QA เป็นคอขวดและพยายามกำจัดมัน ส่งผลให้ความเคารพต่อบทบาท QA ลดลง และก่อให้เกิดปัญหาในการผลิตซอฟต์แวร์ที่มีคุณภาพ
  • นักพัฒนาเองก็ยังไม่เข้าใจการจัดการคุณภาพซอฟต์แวร์อย่างถูกต้อง หลายองค์กรไม่รู้ว่าความรับผิดชอบด้านคุณภาพซอฟต์แวร์ควรอยู่ที่ใคร และแม้แต่องค์กรที่ยังคงมีฟังก์ชัน QA อยู่ก็ยังลำบากในการหาตำแหน่งที่เหมาะสมให้กับบทบาทนี้

สิ่งที่ต้องทำเพื่อจัดการคุณภาพในการปฏิบัติด้านซอฟต์แวร์

  • การติดตามข้อบกพร่อง: ต้องมีวิธีให้ผู้ใช้ส่งข้อมูลเกี่ยวกับบั๊ก และให้นักพัฒนาบันทึกบั๊กได้
  • Triage: Bug triage คือกระบวนการจัดการการมอบหมายบั๊ก การจัดลำดับความสำคัญ การจัดระเบียบ การจัดหมวดหมู่ และการลบรายการซ้ำ
  • การตรวจสอบข้อบกพร่อง: การทำให้บั๊กเกิดซ้ำได้เป็นส่วนสำคัญของการจัดการบั๊ก และต้องใช้ความพยายามเชิงวิศวกรรมเพื่อระบุปัญหาที่แท้จริงและแก้ไขมัน
  • การโฟกัส: บริษัทควรมีคนที่โฟกัสเรื่องคุณภาพ และจำเป็นต้องมีผู้ที่คอยเป็นกระบอกเสียงให้คุณภาพเพื่อสร้างสมดุลระหว่างคุณภาพกับความเร็ว
  • การทดสอบแบบ end-to-end: ปัญหาเรื่องความเป็นเจ้าของระบบเกิดขึ้นจากสถาปัตยกรรมที่ซับซ้อน และนำไปสู่การขาดการทดสอบการใช้งานจริงก่อนเปิดตัวผลิตภัณฑ์

ความเห็นของ GN⁺

  • การยุบทีม QA เป็นความผิดพลาดด้านการจัดการที่อาจส่งผลร้ายแรงต่อคุณภาพซอฟต์แวร์ในระยะยาว
  • การประกันคุณภาพเป็นงานสำคัญในกระบวนการพัฒนาซอฟต์แวร์ และทัศนคติที่เพิกเฉยหรือมองข้ามเรื่องนี้ในที่สุดอาจนำไปสู่ความล้มเหลว
  • บทความนี้ชวนให้กลับมามองความสำคัญของ QA ในอุตสาหกรรมซอฟต์แวร์อีกครั้ง และเน้นย้ำถึงความจำเป็นของความเข้าใจที่เหมาะสมด้านการจัดการคุณภาพและการแบ่งบทบาทภายในองค์กร

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-15
ความคิดเห็นจาก Hacker News

  • ช่วงปลายทศวรรษ 1970 เคยทำงานด้านการรับประกันผลิตภัณฑ์ที่ IBM และรับผิดชอบการเขียนโค้ดทดสอบกับประกอบฮาร์ดแวร์สำหรับผลิตภัณฑ์ที่ดูแล (ระบบประมวลผลคำ) โดยไม่ได้เปิดเผย test case แบบละเอียดให้ทีมพัฒนา แต่แจ้งเพียงปัญหาในภาพรวมเพื่อกระตุ้นให้แก้บั๊ก ความคลาดเคลื่อนระหว่างบั๊กที่พบด้วยวิธีนี้กับบั๊กที่ทีมพัฒนาแก้ไข ทำให้สามารถคำนวณประมาณการจำนวนบั๊กที่ยังเหลืออยู่ได้ในเชิงสถิติ

  • ในองค์กรที่ไม่มีทีม QA มีการนำแนวคิดที่เรียกว่า "sniff test" มาใช้ ซึ่งเป็นเซสชันที่ทุกคนในบริษัทช่วยกันทดสอบฟีเจอร์ใหม่อย่างเข้มข้นในช่วงเวลาสั้น ๆ (ปกติ 1 ชั่วโมง) และส่งผลให้เกิดบั๊กทิคเก็ตจำนวนมาก การทดสอบง่าย ๆ มักทำให้เกิดปัญหาบ่อย แต่ตอนนี้ก็ไม่ใช่เรื่องน่าแปลกใจอีกแล้ว

  • สองบริษัทที่เคยทำงานด้วยเมื่อ 15-20 ปีก่อน ลงทุนกับทีม QA ระดับแนวหน้า และทีมเหล่านี้มีความสามารถโดดเด่นในการหาบั๊กที่นักพัฒนาคาดไม่ถึง ทีม QA มีอำนาจตัดสินใจขั้นสุดท้ายว่าผลิตภัณฑ์จะปล่อยได้หรือไม่ ปัจจุบันหลายบริษัทคิดว่าการให้นักพัฒนาเขียน automated test และใช้เวลากับ code coverage มาก ๆ เป็นวิธีที่ดีกว่า แต่ก็เห็นผลิตภัณฑ์จำนวนมากที่ใช้งานจริงไม่ได้ ประเด็นไม่ใช่ว่า automated test ไม่ดี แต่เป็นการตั้งคำถามต่อการยกเลิก human QA tester

  • พนักงานที่มีความรับผิดชอบต่อองค์กรมากที่สุด มักเป็นคนที่ไม่พอใจมากที่สุดด้วย พวกเขามองเห็นปัญหาคุณภาพและพยายามแก้ไข แต่กลับไม่ได้รับการยอมรับ และเมื่อพูดเรื่องคุณภาพก็มักถูกมองว่าเป็นคนที่พยายามทำให้งานช้าลง ขณะที่คนประเภท "move fast and break things" ยังได้รับรางวัลต่อเนื่อง พวกเขาจึงทั้งโกรธที่ต้องตามเก็บกวาด และรู้สึกว่าการใส่ใจจริงจังในองค์กรอาจเป็นผลเสียต่ออาชีพตัวเอง

  • QA มักถูกมองโดยฝั่งธุรกิจและผู้บริหารระดับสูงว่าเป็น "cost center" มีสมมติฐานว่าควรหลีกเลี่ยงการทำงานในแผนกที่ถูกมองเป็น "cost center" เพราะค่าตอบแทนและการยอมรับมักตกไปอยู่กับคนที่สร้างรายได้เสมอ QA ต้องทำงานมากขึ้นด้วยคนน้อยลง ถูกตำหนิเมื่อเกิดความล้มเหลว และเมื่อธุรกิจต้องทำให้ lean ขึ้น ก็อาจเป็นแผนกแรก ๆ ที่ถูกปลด

  • วิศวกร QA มีทักษะด้านการดีบักที่ยอดเยี่ยม พวกเขาทำงานกับทุกแง่มุมของแอปพลิเคชัน ไม่ว่าจะเป็น pipeline, source code, test directory และอื่น ๆ และบ่อยครั้งก็พบว่าวิศวกรซอฟต์แวร์ไม่อ่านข้อความผิดพลาดจาก pipeline มองข้ามปัญหาพื้นฐาน และเสียเวลาเป็นวันไปกับการเดาวิธีแก้ การดูแคลนวิศวกร QA ไม่ได้ถูกพูดเกินจริงในบทความ และเพราะองค์กร QA มักไม่ได้มีขั้นตอนสัมภาษณ์ที่เข้มงวดเท่าองค์กรวิศวกรรม จึงทำให้วิศวกร QA ถูกมองว่าด้อยกว่า

  • จากประสบการณ์ส่วนตัว ไม่เคยพบทีม QA ที่เขียนการทดสอบเพื่อรองรับงานวิศวกรรมจริง ๆ ทีม QA ส่วนใหญ่เพียงรัน "test plan" แบบแมนนวล หรือไม่บ่อยนักก็ผ่านการทดสอบ browser/device แบบอัตโนมัติ การทดสอบประเภทนี้มีคุณค่า แต่ไม่เทียบเท่า "unit test" หรือ "integration test" ในโมเดลนี้ ทีมวิศวกรรมจึงเป็นฝ่ายทำหน้าที่ QA ที่แท้จริงมากกว่า ส่วนทีม QA มักลดคุณค่าของตัวเองด้วยการรายงานสิ่งที่ไม่ใช่บั๊กว่าเป็นบั๊ก

  • Microsoft หลังยุบทีม QA ไปแล้ว ก็พบว่า Windows และผลิตภัณฑ์คลาวด์มีบั๊กเพิ่มมากขึ้น