ความเป็นจริงที่เราไม่ได้เรียนรู้วิธีพัฒนาซอฟต์แวร์คุณภาพสูง

การขาดการสอนเรื่องวิธีสร้างคุณภาพซอฟต์แวร์

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

วิธีที่บริษัทต่าง ๆ ปล่อยสินค้าให้ทันเวลา

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

วิธีออกจากวงจรเดิม ๆ

• ต้องใช้เวลาหลายปีกว่าจะสะสมประสบการณ์และความมั่นใจมากพอที่จะพูดถึงมาตรการ QA ที่ขาดหายไปในโครงการ
• เราได้เจอกับปัญหาอย่างการค้นพบว่าขาดการมอนิเตอร์ หรือระบบ production ล้มเหลว
• หากไม่ลงมือใช้มาตรการ QA ก็จะเกิดปัญหาว่าเราไม่ได้เรียนรู้มันอย่างถูกต้องจริง ๆ

การพูดถึงเรื่องเงิน

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

ปริมาณที่ให้ผลขั้นต่ำ

• ไม่ควรออกแบบมาตรการ QA มากเกินไปจนขัดขวางความก้าวหน้าของโครงการ
• สิ่งสำคัญคือการทดสอบฟังก์ชันหลักของแอปพลิเคชันและยืนยันว่ามันทำงานตามที่คาดหวังเสมอ
• ใช้แนวคิด 'Minimum Effective Dose' (MED) โดยเริ่มจากส่วนที่สำคัญที่สุดก่อน

สิ่งที่ควรพิจารณาอย่างรอบคอบ

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

ประโยชน์ต่อโครงการ

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

วิธีปรับปรุงโครงการ

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

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

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

[GN⁺]

ความคิดเห็นจาก Hacker News

• วิศวกรรมซอฟต์แวร์มักไม่ใช่หัวข้อแกนหลักของวิทยาการคอมพิวเตอร์ (CS) แต่ถูกสอนในสาขาอื่น หรืออยู่ในรูปแบบวิชาเลือกหรือหลักสูตรวิศวกรรมซอฟต์แวร์

  ที่ CMU มีหลักสูตรปริญญาโทและเอกด้านวิศวกรรมซอฟต์แวร์ และสอนหัวข้อที่หลากหลายรวมถึงสิ่งที่กล่าวถึงในบล็อกโพสต์

• มีประสบการณ์ว่าการทำงานร่วมกับคนที่จบวิทยาการคอมพิวเตอร์นั้นง่ายกว่า เพราะคนกลุ่มนี้เข้าใจความสำคัญของอัลกอริทึมที่ดี และจะไม่พยายามลงมือเขียน parser หรือระบบเข้ารหัสขึ้นเอง

  มีการชี้ให้เห็นว่าในสายวิศวกรรมซอฟต์แวร์ยังขาดกระบวนการแก้ความคิดแบบไร้เดียงสาเกี่ยวกับการทำงานเป็นทีมและคุณภาพ

• การพัฒนาซอฟต์แวร์คุณภาพสูงสามารถเรียนรู้ได้จากบริษัทที่มีประสบการณ์มาก

  ในอดีตอาจเป็นบริษัท FAANG แต่ปัจจุบันสามารถเรียนรู้ได้จากบริษัทอย่าง TailScale โดยไม่หมกมุ่นกับ microservices, Docker, การจัดการ JSON แบบไร้สาระเกินไป และใช้ QuickCheck, การทดสอบสมมติฐาน, fuzzing เป็นต้น เพื่อยกระดับคุณภาพ

• ข้ออ้างว่าต้องปล่อยซอฟต์แวร์ที่ไม่มีบั๊กให้ทันเวลานั้นเป็นสมมติฐานที่ไม่เหมาะจะใช้เริ่มต้นบทความเกี่ยวกับซอฟต์แวร์คุณภาพ

  การเชื่อว่าสามารถ deploy โค้ดที่ไม่มีบั๊กได้เป็นความคิดที่ห่างไกลจากความเป็นจริง

• มีมหาวิทยาลัยที่เน้นหลักสูตรวิศวกรรมคอมพิวเตอร์ รวมถึงการฝึกงานและภาคปฏิบัติ

  ภาควิชา CS ของหลายมหาวิทยาลัยแตกแขนงมาจากภาควิชาคณิตศาสตร์และจึงเน้นทฤษฎี มหาวิทยาลัยไม่ใช่แค่โรงเรียนฝึกอาชีพ แต่เป็นสถานที่ฝึกความสามารถในการทำความเข้าใจเนื้อหาที่ซับซ้อน

• ข้ออ้างว่ามหาวิทยาลัยสอนการสร้างซอฟต์แวร์สำหรับอุตสาหกรรมนั้นเป็นการพูดเกินจริง

  ในปัจจุบันที่ continuous deployment pipeline กลายเป็นเรื่องทั่วไปแล้ว การให้แผนกประกันคุณภาพตรวจหาบั๊กด้วยมือถูกมองว่าเป็นวิธีที่ล้าสมัย

• ตรรกะที่ว่าซอฟต์แวร์จะ 'เสถียรกว่า' หรือ 'ดูแลรักษาง่ายขึ้น' ไม่ใช่สิ่งที่โน้มน้าวคนที่ไม่ได้ลงมือทำงานกับ codebase โดยตรง

  นักพัฒนาควรพูดถึงต้นทุนของการไม่ทำประกันคุณภาพ (QA) เพราะนี่คือภาษาที่ธุรกิจและผู้จัดการเข้าใจ

• คุณสามารถเลือกได้สามอย่างจากสี่อย่าง: คุณภาพ เวลา ความซับซ้อนของการสื่อสาร และต้นทุน

  วิศวกรรมซอฟต์แวร์เป็นกีฬาประเภททีมที่ยากจะนำกระบวนการแบบโรงงานมาใช้ จึงควรให้ความสำคัญกับการทำงานเป็นทีมและการเติบโตของแต่ละคน

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

  ในที่ทำงานส่วนใหญ่ ความเห็นของนักพัฒนาซอฟต์แวร์มักถูกมองข้ามเป็นส่วนใหญ่

• คุณภาพเป็นคุณสมบัติที่ในความเป็นจริงแล้วเรียนรู้ได้ผ่านการฝึกฝนเท่านั้น

  ความสามารถในการสร้างผลลัพธ์คุณภาพสูงเกิดขึ้นจากการฝึกซ้ำอย่างต่อเนื่อง