ซอร์สโค้ด QA: ไม่ใช่แค่สำหรับนักพัฒนาอีกต่อไป

20 ปีที่แล้ว ตอนที่ฉันทำงานในอุตสาหกรรมยานยนต์ ผู้อำนวยการโรงงานแห่งหนึ่งมักจะพูดว่า "เรามีเวลาหนึ่งวันในการสร้างรถ แต่ลูกค้าของเรามีเวลาทั้งชีวิตในการตรวจสอบ" คุณภาพมีความสำคัญสูงสุด อันที่จริง ในภาคส่วนที่เติบโตเต็มที่ เช่น อุตสาหกรรมยานยนต์และการก่อสร้าง การประกันคุณภาพเป็นข้อพิจารณาหลักที่บูรณาการเข้ากับกระบวนการพัฒนาผลิตภัณฑ์อย่างเป็นระบบ แม้ว่าสิ่งนี้จะได้รับแรงผลักดันจากแรงกดดันจากบริษัทประกันภัยอย่างแน่นอน แต่ก็ถูกกำหนดด้วย—ดังที่ผู้อำนวยการโรงงานระบุไว้—โดยอายุขัยของผลิตภัณฑ์

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

กำหนด “คุณภาพ”

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

กล่าวอีกนัยหนึ่ง ซอร์สโค้ดที่มีคุณภาพใช้ข้อกำหนดด้านการทำงานของผลิตภัณฑ์อย่างถูกต้อง ตรงตามข้อกำหนดที่ไม่ได้ใช้งาน รับรองความพึงพอใจของผู้บริโภค ลดความปลอดภัยและความเสี่ยงทางกฎหมาย และสามารถรักษาและขยายเวลาได้ในราคาไม่แพง

ด้วยการกระจายซอฟต์แวร์อย่างกว้างขวางและรวดเร็ว ผลกระทบของข้อบกพร่องของซอฟต์แวร์อาจมีนัยสำคัญ ปัญหาต่างๆ เช่น ข้อบกพร่องและความซับซ้อนของโค้ดอาจส่งผลเสียต่อผลกำไรของบริษัทโดยการขัดขวางการนำผลิตภัณฑ์ไปใช้และเพิ่มต้นทุนการจัดการสินทรัพย์ซอฟต์แวร์ (SAM) ในขณะที่การละเมิดความปลอดภัยและการละเมิดการปฏิบัติตามใบอนุญาตอาจส่งผลต่อชื่อเสียงของบริษัทและทำให้เกิดข้อกังวลทางกฎหมาย แม้ว่าข้อบกพร่องของซอฟต์แวร์จะไม่มีผลลัพธ์ที่ร้ายแรง แต่ก็มีค่าใช้จ่ายที่ปฏิเสธไม่ได้ ในรายงานปี 2018 บริษัทซอฟต์แวร์ Tricentis พบว่าซอฟต์แวร์ล้มเหลว 606 รายการจาก 314 บริษัท คิดเป็นมูลค่าการสูญเสียรายได้ 1.7 ล้านล้านดอลลาร์ในปีที่แล้ว ในรายงานที่เพิ่งเปิดตัวในปี 2020 CISQ ระบุว่าต้นทุนของซอฟต์แวร์คุณภาพต่ำในสหรัฐฯ อยู่ที่ 2.08 ล้านล้านดอลลาร์ และอีกประมาณ 1.31 ล้านล้านดอลลาร์ในอนาคตที่เกิดจากหนี้ทางเทคนิค ตัวเลขเหล่านี้สามารถบรรเทาได้ด้วยการแทรกแซงก่อนหน้านี้ ต้นทุนเฉลี่ยในการแก้ไขปัญหาระหว่างการออกแบบผลิตภัณฑ์นั้นต่ำกว่าการแก้ไขปัญหาเดียวกันระหว่างการทดสอบอย่างมาก ซึ่งน้อยกว่าการแก้ไขปัญหาหลังการปรับใช้

การจัดการกับมันฝรั่งร้อน

แม้จะมีความเสี่ยง แต่การประกันคุณภาพในการพัฒนาซอฟต์แวร์จะได้รับการปฏิบัติทีละน้อย และมีลักษณะเฉพาะโดยใช้วิธีการเชิงรับ มากกว่าที่จะใช้วิธีเชิงรุกในอุตสาหกรรมอื่นๆ ความเป็นเจ้าของคุณภาพซอร์สโค้ดขัดแย้งกัน เมื่อมองว่าเป็นความรับผิดชอบร่วมกันของฟังก์ชันต่างๆ ผู้จัดการผลิตภัณฑ์ต้องมองว่าคุณภาพเป็นคุณลักษณะที่มีผลกระทบมากกว่าค่าใช้จ่าย ผู้บริหารควรใส่ใจกับสถานะคุณภาพและลงทุนในคุณภาพ และหน้าที่ด้านวิศวกรรมควรต่อต้านการปฏิบัติต่อการทำความสะอาดโค้ดเหมือน "มันฝรั่งร้อน"

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

พิจารณาบทบาทของผู้จัดการผลิตภัณฑ์

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

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

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

การใช้กระบวนการ 7 ขั้นตอน

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

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

1. การจับคู่ระหว่างผลิตภัณฑ์กับโค้ด: การติดตามคุณลักษณะของผลิตภัณฑ์กลับไปยังฐานโค้ดอาจดูเหมือนเป็นขั้นตอนแรกที่ชัดเจน แต่เมื่อพิจารณาจากอัตราที่ความซับซ้อนของการพัฒนาเพิ่มขึ้น ไม่จำเป็นต้องทำได้ง่ายๆ ในบางสถานการณ์ รหัสของผลิตภัณฑ์จะถูกแบ่งระหว่างที่เก็บต่างๆ ในขณะที่ในที่อื่นๆ ผลิตภัณฑ์หลายรายการจะแบ่งใช้ที่เก็บข้อมูลเดียวกัน การระบุตำแหน่งต่างๆ ที่มีส่วนเฉพาะของรหัสผลิตภัณฑ์เป็นสิ่งที่จำเป็น ก่อนจึงจะสามารถทำการประเมินเพิ่มเติมได้

2. การวิเคราะห์สแต็คเทค: ขั้นตอนนี้คำนึงถึงภาษาการเขียนโปรแกรมและเครื่องมือการพัฒนาต่างๆ ที่ใช้ เปอร์เซ็นต์ของความคิดเห็นต่อไฟล์ เปอร์เซ็นต์ของโค้ดที่สร้างโดยอัตโนมัติ ต้นทุนการพัฒนาโดยเฉลี่ย และอื่นๆ

เครื่องมือที่แนะนำ: cloc

ทางเลือกอื่น: Tokei, scc, sloccount

3. การวิเคราะห์เวอร์ชัน: จากผลของการตรวจสอบส่วนนี้ ซึ่งเกี่ยวข้องกับการระบุเวอร์ชันทั้งหมดของโค้ดเบสและการคำนวณความคล้ายคลึงกัน เวอร์ชันต่างๆ สามารถผสานและขจัดความซ้ำซ้อนได้ ขั้นตอนนี้สามารถใช้ร่วมกับการวิเคราะห์จุดบกพร่อง (ฮอตสปอต) ซึ่งระบุส่วนที่ซับซ้อนของรหัสที่มีการแก้ไขบ่อยที่สุดและมีแนวโน้มที่จะสร้างต้นทุนการบำรุงรักษาที่สูงขึ้น

เครื่องมือที่แนะนำ: cloc, scc, sloccount

4. การตรวจสอบโค้ดอัตโนมัติ: การตรวจสอบนี้จะตรวจสอบโค้ดเพื่อหาข้อบกพร่อง การละเมิดแนวทางปฏิบัติในการเขียนโปรแกรม และองค์ประกอบที่มีความเสี่ยง เช่น โทเค็นฮาร์ดโค้ด วิธีการแบบยาว และการทำซ้ำ เครื่องมือที่เลือกสำหรับกระบวนการนี้จะขึ้นอยู่กับผลของสแต็คเทคโนโลยีและเวอร์ชันที่วิเคราะห์ข้างต้น

เครื่องมือที่แนะนำ: SonarQube, Codacy

ทางเลือกอื่น: RIPS, Veracode, Micro Focus, Parasoft และอื่นๆ อีกมากมาย อีกทางเลือกหนึ่งคือ Sourcegraph ซึ่งเป็นโซลูชันการค้นหาโค้ดสากล

5. การวิเคราะห์ความปลอดภัยแบบคงที่: ขั้นตอนนี้หรือที่เรียกว่าการทดสอบความปลอดภัยของแอปพลิเคชันแบบคงที่ (SAST) จะสำรวจและระบุช่องโหว่ด้านความปลอดภัยของแอปพลิเคชันที่อาจเกิดขึ้น เครื่องมือที่มีอยู่ส่วนใหญ่จะสแกนโค้ดเทียบกับปัญหาด้านความปลอดภัยที่เกิดขึ้นบ่อยครั้งซึ่งระบุโดยองค์กร เช่น OWASP และ SANS

เครื่องมือที่แนะนำ: WhiteSource, Snyk, Coverity

ทางเลือกอื่น: SonarQube, Reshift, Kiuwan, Veracode

6. การวิเคราะห์ส่วนประกอบซอฟต์แวร์ (SCA)/การวิเคราะห์การปฏิบัติตามใบอนุญาต: การตรวจสอบนี้เกี่ยวข้องกับการระบุไลบรารีโอเพนซอร์สที่ลิงก์โดยตรงหรือโดยอ้อมกับโค้ด สิทธิ์การใช้งานที่ปกป้องแต่ละไลบรารีเหล่านี้ และการอนุญาตที่เกี่ยวข้องกับสิทธิ์การใช้งานเหล่านี้

เครื่องมือที่แนะนำ: Snyk, WhiteSource, Black Duck

ทางเลือกอื่น: FOSSA, Sonatype และอื่นๆ

7. การวิเคราะห์ความเสี่ยงทางธุรกิจ: การวัดผลขั้นสุดท้ายนี้เกี่ยวข้องกับการรวมข้อมูลที่รวบรวมจากขั้นตอนก่อนหน้านี้ เพื่อทำความเข้าใจผลกระทบทั้งหมดของสถานะคุณภาพซอร์สโค้ดที่มีต่อธุรกิจ การวิเคราะห์ควรส่งผลให้เกิดรายงานที่ครอบคลุมซึ่งให้ผู้มีส่วนได้ส่วนเสีย ซึ่งรวมถึงผู้จัดการผลิตภัณฑ์ ผู้จัดการโครงการ ทีมวิศวกรรม และผู้บริหาร C-suite พร้อมรายละเอียดที่จำเป็นในการชั่งน้ำหนักความเสี่ยงและตัดสินใจเกี่ยวกับผลิตภัณฑ์อย่างมีข้อมูล

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

การเลือกเครื่องมือที่เหมาะสม

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

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

เดินหน้าต่อไป

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

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