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

 (davidkcaudill.medium.com)
5 คะแนน โดย GN⁺ 2023-12-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังลดคอขวดของรีลีส การดีพลอย การจัดการอิมเมจ และการโรลแบ็กด้วยการเพิ่มประสิทธิภาพแบบ DevOps แล้ว จุดที่ช้าที่สุดในการส่งมอบซอฟต์แวร์ยังคงเป็น การทดสอบ
  • อุตสาหกรรมเริ่มมองว่าไม่ใช่การทดสอบเอง แต่เป็น ทีม QA ที่เป็นคอขวด ขณะที่ความคาดหวังต่อบทบาทเพิ่มขึ้น แต่กลับตามมาด้วยการลดคุณภาพการจ้างงาน การเปลี่ยนเป็นสัญญาจ้าง การย้ายงานไปต่างประเทศ และการลดการจ้างงาน
  • การยุบองค์กร QA บั่นทอนกำลังใจของบุคลากร QA ที่มีประสบการณ์ และเมื่อฝั่งนักพัฒนาไม่ได้รับงานด้านคุณภาพไปทำอย่างเป็นธรรมชาติ ปัญหา ซอฟต์แวร์คุณภาพต่ำ ก็ยิ่งรุนแรงขึ้น
  • การจัดการคุณภาพคือชุดงานจริงที่ต้องมีการตั้งชื่อและมอบหมาย เช่น การติดตามข้อบกพร่อง การจัดหมวดหมู่ การสืบสวน การเป็นผู้ผลักดันคุณภาพ และ การทดสอบแบบ end-to-end
  • หากไม่จัดระบบงานด้านคุณภาพ คนที่ค้นพบและคอยเก็บกวาดปัญหาจะไม่ได้รับผลตอบแทน ขณะที่คนที่ทำของออกมาเร็วแล้วปล่อยให้พังกลับได้รับรางวัลซ้ำแล้วซ้ำเล่า

คอขวดที่ยังเหลืออยู่หลังการเพิ่มประสิทธิภาพแบบ DevOps

  • ผู้ปฏิบัติงาน DevOps นำ Theory Of Constraints มาปรับใช้เพื่อเพิ่มประสิทธิภาพไปป์ไลน์และแนวปฏิบัติในการส่งมอบซอฟต์แวร์อย่างหนัก
  • การจัดการรีลีสแบบแมนนวล การดีพลอย การจัดการอิมเมจ และการโรลแบ็กโปรดักชัน กลายเป็นเป้าหมายของระบบอัตโนมัติ
  • ในกระบวนการตั้งแต่ product backlog ไปจนถึงโค้ดไปถึงมือลูกค้า กิจกรรมที่มี มูลค่าต่ำ ถูกกำจัดออกหรือถูกมองเป็นคอขวดที่ต้องเพิ่มประสิทธิภาพ
  • ผลคือส่วนที่ช้าที่สุดในการส่งมอบซอฟต์แวร์ยังคงเป็น การทดสอบ
    • การทดสอบก็เป็นเหตุผลหนึ่งที่ทำให้มี continuous delivery อยู่ด้วย
    • เราสามารถทำให้การทดสอบเร็วขึ้น ทำให้เป็นอัตโนมัติ และทำแบบขนานได้
    • หากกิจกรรมที่มีคุณค่ามากที่สุดในแนวปฏิบัติใดกลายเป็นคอขวด ก็อาจแปลว่าเราเข้าใกล้สภาวะที่เหมาะที่สุดแล้ว

อุตสาหกรรมที่มองว่าทีม QA คือคอขวด

  • นิสัยการเพิ่มประสิทธิภาพขยายจากตัวการทดสอบเองไปยังบทบาท QA ด้วย
  • มีความพยายามลดการทดสอบแบบ integration และ end-to-end ให้เหลือเป็น unit test เพื่อให้รันแบบขนานได้
  • ในระดับบุคลากร ก็เกิดการผลักคนที่ถูกตัดสินว่าเขียนโค้ดไม่ได้ออกไปอยู่ตามหน้าที่แยกย่อยด้วย
  • อุตสาหกรรมเริ่มมองว่า ไม่ใช่การทดสอบ แต่ทีม QA ต่างหากที่เป็นคอขวด
    • ความคาดหวังต่อบทบาท QA สูงขึ้น
    • เงินเดือนลดลงหรือไม่เพิ่มขึ้นเมื่อเทียบกับบทบาทอื่น
    • บทบาทถูกเปลี่ยนเป็นงานสัญญาจ้างและย้ายไปต่างประเทศ
    • มีการตัดสินใจลดการจ้าง QA engineer อย่างต่อเนื่อง

วงจรเลวร้ายที่เกิดจากการลดบทบาท QA

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

“ไล่ tester ออก” ไม่ใช่คำตอบ

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

งานที่จำเป็นต่อการจัดการคุณภาพซอฟต์แวร์

  • การติดตามข้อบกพร่อง

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

  • การคัดแยกและจัดลำดับความสำคัญ

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

  • การสืบสวนข้อบกพร่อง

    • การทำให้เกิดซ้ำได้เป็นส่วนที่ สำคัญ ของการจัดการบั๊ก
    • ต้องมีใครสักคนแปลงรายงานอย่าง “พยายามซื้อตั๋วหนังแล้วซื้อไม่ได้” ให้เป็นรูปแบบอย่าง “ปัญหา character encoding สำหรับลูกค้าที่มีอักขระนอกภาษาอังกฤษในชื่อ ทำให้ขั้นตอนการซื้อพัง”
    • คำถามอย่าง “ปัญหานี้เกิดขึ้นกี่ครั้ง” หรือ “มีผลกระทบต่อผู้ใช้อย่างไร” จำเป็นต้องมีคนจริง ๆ ใช้เวลาเพื่อตอบ
    • การสืบสวนข้อบกพร่องคือการนำ ความเข้มงวดแบบวิศวกรรม มาใช้กับ backlog ของบั๊ก

  • บทบาทที่โฟกัสเรื่องคุณภาพ

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

  • การทดสอบแบบ end-to-end

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

ปัญหาเชิงองค์กรที่เกิดขึ้นเมื่อมองข้ามงานด้านคุณภาพ

  • อาจมีปฏิกิริยาแบบ “เรา agile, lean และ dynamic ดังนั้นไม่จำเป็นต้องทำเรื่องพวกนี้”
  • แต่ถ้าดูให้ละเอียด งานเหล่านี้ก็น่าจะเกิดขึ้นอยู่แล้วภายในองค์กร เพียงแต่ทำกันอย่าง ย่ำแย่
  • ในสาขาอื่นอย่างรถยนต์ ธนาคาร หรือแพทย์ การได้ยินคำว่า “เราไม่ทำ quality assurance” ไม่ใช่ประสบการณ์ที่ดีเลย
  • หากไม่รับรู้งานด้านคุณภาพและไม่จัดมันให้เป็นระบบ สถานการณ์ที่แย่มากจะตามมา
  • พนักงานที่มีจิตสำนึกมากที่สุดจะกลายเป็นคนที่ขมขื่นที่สุด
    • มองเห็นปัญหาคุณภาพและลงมือแก้บ่อยครั้ง
    • แต่ไม่ได้รับการยอมรับสำหรับสิ่งนั้น
    • เมื่อยกความกังวลเรื่องคุณภาพขึ้นมา ก็ถูกมองว่าเป็นคนที่พยายามทำให้ช้าลง
    • เห็นคนที่ “เดินให้เร็วแล้วทำพัง” ได้รับรางวัลซ้ำแล้วซ้ำเล่า
    • รู้สึกว่าตัวเองเป็นคนคอยเก็บกวาดความเละเทะของคนอื่นอย่างหงุดหงิด
  • ในองค์กรแบบนี้ การใส่ใจจริงจังกลับกลายเป็น โทษต่อเส้นทางอาชีพ

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

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

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

  • ช่วงต้นอาชีพในปลายทศวรรษ 1970 เคยทำงานในทีม Product Assurance หรือก็คือทีม QA ที่ IBM Hursley Park ตอนนั้นสร้างทั้งโค้ดและฮาร์ดแวร์เพื่อทดสอบระบบประมวลผลคำที่รับผิดชอบ และรัน test case กับระบบเป้าหมาย
    ปัญหาที่พบจะส่งให้ทีมพัฒนาแบบอธิบายกว้าง ๆ เท่านั้น เป้าหมายคือเพื่อให้ทีมพัฒนา แก้บั๊ก แทนที่จะทำให้ผ่าน test case เฉพาะจุด ผลคือถ้าเราเจอบั๊ก 3 ตัวในส่วนการตัดคำด้วยไฮเฟนและการลบด้วย backspace ทีมพัฒนาจะไปแก้บั๊กในบริเวณนั้น 4 ตัว แต่จากที่เราพบจริงอาจถูกแก้แค่ 2 ตัว ทำให้สามารถประเมินจำนวนบั๊กจริงที่เหลืออยู่ในเชิงสถิติได้
    ในองค์กรที่ไม่มีทีม QA มีแนวคิดที่เรียกว่า sniff test โดยทั่วไปคือให้คนในบริษัทหรือในแผนกไหนก็ได้มาลองกดเล่นฟีเจอร์ใหม่ราว 1 ชั่วโมง แม้ฟีเจอร์จะถูกมองว่าสร้างเสร็จแล้ว แต่เงื่อนไขขอบเขตมักพังแทบทุกครั้ง แค่ใส่ "" ลงในทุกช่องแล้วกดส่ง, ลองนำทาง UI ด้วยคีย์บอร์ดอย่างเดียว, หรือใช้เงื่อนไขง่าย ๆ อย่างฟอนต์ใหญ่หรือซูมเบราว์เซอร์ 110% ก็เจอปัญหาได้บ่อย และตอนนี้ก็แทบไม่รู้สึกแปลกใจแล้ว

    • ที่บริษัทเราเรียกแบบนั้นว่า bug bash และโดยทั่วไปมันให้ผลดีมากในแง่จำนวนข้อบกพร่องที่ค้นพบ
      ระหว่างพัฒนาฟีเจอร์เล็ก ๆ ปกติมักมีแค่โปรแกรมเมอร์ที่ลองทดสอบ แต่รูปแบบนั้นอาจต่างจากวิธีใช้งานจริงของผู้ใช้ปลายทาง จึงมีประโยชน์มากเป็นพิเศษ
    • กลยุทธ์ที่ซ่อนที่มาของ automated test จากนักพัฒนาน่าสนใจดี ดูเหมือนจะช่วยให้โฟกัสที่การแก้ปัญหาจริง แทนที่จะไปปิดการทำงานของเทสต์หรือเขียนให้แค่ผ่านเทสต์ได้
    • สมัยก่อนที่ Microsoft ก็เรียกสิ่งนี้ว่า bug bash และสตาร์ตอัปของฉันก็รับไอเดียนี้ต่อมา เราสนับสนุนให้ทั้งบริษัทกันเวลาช่วงบ่ายมาเข้าร่วม และยังมีรางวัลให้บั๊กที่ส่งผลกระทบมากที่สุดหรือบั๊กที่น่าสนใจที่สุดด้วย
    • สงสัยว่าการสร้างบั๊กทิกเก็ต 100 ใบในหนึ่งชั่วโมงมีประโยชน์กับใครจริง ๆ ถ้ามีรายการซ้ำเยอะ แค่บั๊กต่างกัน 10 ตัวก็น่าจะพอชี้ได้แล้วว่าฟีเจอร์นั้นแย่มาก หลังจากนั้นก็เหมือนแค่คอยทุบซากเดิมต่อไป
    • วิธีมี test case ฝั่ง QA ที่ชัดเจน แต่ให้คำอธิบายกำกวมกับนักพัฒนานั้นฉลาดมาก เพิ่งเคยเห็นแนวทางแบบนี้ครั้งแรก และก็น่าประทับใจที่มันช่วยประเมินจำนวนบั๊กที่เหลือได้

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

    • องค์กร QA/QE ที่ยอดเยี่ยมก็คล้ายกัน สายการบังคับบัญชาที่ตัดสินใจว่าจะรับรอง production release หรือไม่แยกจากฝั่งพัฒนา และโครงสร้างแรงจูงใจก็ต่างกันด้วย
      ทีม QE ที่บริษัทล่าสุดที่ฉันอยู่เขียนโค้ดจำนวนมหาศาลเพื่อทำการทดสอบ ถึงขั้นมีจำนวนบรรทัดมากกว่ามอดูลที่เป็นเป้าหมายของการทดสอบและการรับรองเสียอีก
    • code coverage ไม่สามารถหาบั๊กที่เกิดจาก โค้ดที่ไม่ได้เขียนแต่ควรถูกเขียน ได้ coverage เป็นเพียงหนึ่งในหลายตัวชี้วัดเท่านั้น และการปฏิบัติกับมันเหมือนเป็นเกณฑ์เดียวถือว่าโง่มาก
      ถึงอย่างนั้นก็เคยได้ยินผู้จัดการการทดสอบของบริษัทซอฟต์แวร์ใหญ่ที่ทุกคนรู้จักประกาศว่าทีมทดสอบจบภารกิจแล้วเพราะทำ coverage ได้ 100%
    • แค่มีคำสั่งว่าฝั่ง QA มีอำนาจตัดสินใจสุดท้ายยังไม่พอ ต้องมี วัฒนธรรม QA ด้วย
      ต่อให้มีอำนาจนั้น ถ้า QA ส่วนใหญ่เป็นพนักงานสัญญาจ้างค่าแรงต่ำและทำแค่ตามที่สั่ง บริษัทก็ยังเละเทะเหมือนเดิม
    • เคยเห็นนักพัฒนาที่เขียนเทสต์แบบไม่มี assertion หรือมีแค่ assertTrue(true) เท่านั้น ทุกอย่างเขียวหมดและ coverage ก็ 100%
      คนกลุ่มเดียวกันนี้มักถามว่าถ้าสร้างฟีเจอร์ใหม่ได้ แล้วจะเขียนเทสต์ไปทำไม จากนั้น senior QA ก็เข้ามาแล้วทำให้ทุกอย่างพัง ครั้งหนึ่งเคยพบบั๊กว่าแค่กด F5 50 ครั้งใน 1 นาที backend ก็จะปั่น database request จนตายด้วย outOfMemory
    • ฉันชอบ QA ที่ละเอียดรอบคอบมาก การที่ฉันเป็นนักพัฒนาแล้วหวังพึ่งว่าพวกเขาจะจับสิ่งที่ฉันพลาดเสมอถือเป็น anti-pattern แต่ในเวลาที่ฉันยังกลัวแม้แต่จะรันโค้ดตัวเอง 1 นาที พวกเขากลับสนุกกับมัน
      พวกเขาภูมิใจกับการหาว่า เงื่อนไขขอบเขต ไหนที่เกินกว่าสเปกมาก และคุณค่านั้นก็คุ้มจริง ๆ เหมือนที่ type system ที่ดีช่วยสร้างความมั่นใจในการเปลี่ยนแปลง QA ที่ยอดเยี่ยมก็ช่วยสร้างความมั่นใจให้กับนักพัฒนาเช่นกัน โดยเฉพาะแอปที่มีปฏิสัมพันธ์สูงอย่างเกม ซึ่งยากที่จะครอบคลุมพื้นที่พารามิเตอร์ทั้งหมดด้วยแค่ unit test และ integration test

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

    • ก็แค่กระโดดหนีออกจากเรือลำนั้น แล้วปล่อยให้บริษัทพังไป การทำให้มันพังเร็วขึ้นยังดีกว่า และเมื่อไม่ฝืนประคองบริษัทแย่ ๆ ไว้ สิ่งดี ๆ ก็จะเกิดขึ้นได้
    • วิธีที่ฉันคิดว่าบทลงโทษจะย้อนกลับมาคือ สร้างเองก็ต้องดูแลรันเอง ถ้าไม่อยากให้ on-call pager ดัง ก็อย่าสร้างสิ่งที่จะทำให้มันดัง
    • สุดท้ายแล้วมันขึ้นอยู่กับลูกค้า ว่าจะยอมเลิกใช้เพราะบั๊กและระบบล่ม หรือจะอยู่ต่อเพราะฟีเจอร์ใหม่ที่ดูแวววาว
    • QA และการทดสอบสำคัญก็จริง แต่ไม่รู้ว่าจะโน้มน้าวคนที่มองแต่กำไรได้หรือไม่ เพราะการแจกจ่ายผ่านอินเทอร์เน็ตมันง่ายเกินไป ทำให้แนวคิด “รีลีสให้เร็วแล้วค่อยแพตช์ทีหลัง” น่าจะยังอยู่ต่อไป
      ตรรกะคือถ้าผู้ใช้รายงานบั๊กได้และรับอัปเดตผ่านอินเทอร์เน็ตได้ ก็ไม่มีเหตุผลจะต้องเสียเงินและเวลาเยอะ ตั้งแต่เกมและซอฟต์แวร์เปลี่ยนจากสื่อกายภาพมาเป็นการดาวน์โหลดเป็นหลัก การแพตช์ก็ดูเหมือนถูกกว่าจริง ๆ แน่นอนว่ามันนำไปสู่ปัญหาความปลอดภัยที่เลวร้ายและประสบการณ์ผู้ใช้ที่แย่ แต่ตราบใดที่คนข้างบนยังเพิ่มกำไรได้สูงสุด พวกเขาก็ไม่ค่อยสนใจ
    • วิศวกรที่มีมโนธรรมไม่ได้ถูกเสมอไป ยังต้องมีบริบทและความสมดุล บางครั้งเขาอาจถูกแต่สื่อสารพัง บางครั้งก็แค่อยู่ผิดที่เท่านั้น
      ถ้าคุณกำลังสร้าง ผลิตภัณฑ์ SaaS แบบ POC ก็ไม่จำเป็นต้องมีคุณภาพระดับไมโครคอนโทรลเลอร์สำหรับอากาศยาน ทุกการแลกเปลี่ยนมีทั้งความเสี่ยงและต้นทุน และวิศวกรที่ดีควรรู้ความแตกต่างนั้น

  • ปัญหาหลักของทีม QA ก็คล้ายกับทีม IT หรือองค์กรฝ่ายบริหาร คือถ้าทำงานได้ดี มันจะดูเหมือนไม่ได้ทำอะไรเลย
    เลยทำให้บ่อยครั้งต้องอยู่ในสถานการณ์ที่ต้อง “พิสูจน์ความชอบธรรม” ของงานตัวเอง ซึ่งมักมาจากการพึ่งพาตัวชี้วัดมากเกินไป เหมือนกฎของ Goodhart คือไม่เข้าใจว่าตัวชี้วัดนั้นเป็นค่าตัวแทนของอะไร และเป้าหมายที่แท้จริงของงานคืออะไร
    ทีม QA ที่แย่มักจับผิดเกินเหตุเพื่อให้ดูเหมือนมีอะไรจะพูด ส่วนทีม QA ที่ดีจะทั้งตรวจสอบคุณภาพและฝึกให้พนักงานสร้างงานที่มีคุณภาพสูงขึ้นด้วย
    รู้สึกว่าโดยรวมแล้วบุคลากรยัง ขาดการฝึกฝน กันมาก ไม่นานมานี้โพสต์ “95เปอร์เซ็นไทล์ก็ไม่ได้สุดยอดขนาดนั้น” ที่ขึ้นหน้าแรก(https://news.ycombinator.com/item?id=38560345) ก็พูดถึงว่า การขึ้นไปอยู่ใน 5% แรกของแทบทุกสาขานั้นง่ายกว่าที่คิด เพราะคนส่วนใหญ่ไม่ได้ฝึกอย่างจริงจังหรือรับฟีดแบ็กเชิงรุก
    บริษัทน่าจะต้องฝึกกันต่อเนื่องเหมือนทีมกีฬาอาชีพ ไม่ใช่ทีมสมัครเล่น และการจ้างงานก็ควรมองจาก “เราทำให้คนนี้กลายเป็นผู้ทำผลงานระดับท็อปได้ไหม” มากกว่า “เขาเป็นคนผลงานระดับท็อปอยู่แล้วหรือเปล่า” ความสำเร็จในสภาพแวดล้อมก่อนหน้ามีความหมายไม่มากอย่างที่คิด ถ้าสภาพแวดล้อมใหม่ต่างออกไปมาก

    • มีโอกาสที่ 95เปอร์เซ็นไทล์จะไม่ได้มาจากความพยายามมหาศาล แต่เป็นผลจากการ ลดความผิดพลาดที่ไม่จำเป็น ทว่ากลับมีมีมทางวัฒนธรรมที่แพร่หลายว่ามันเป็นเรื่องยากลำบากมาก
      ในบทความเกี่ยวกับคุณภาพซอฟต์แวร์แทบทุกชิ้น มักมีคอมเมนต์ที่มองความไม่ใส่ใจอย่างกว้างขวางของวิศวกรเป็นเรื่องปกติ แม้แต่ละสถานการณ์จะต่างกัน แต่ผู้คนก็ดูโอเคกับการไหลไปตามจุดเหมาะที่สุดเฉพาะหน้าในองค์กรของตัวเอง และสละความเป็นเจ้าของไป ไม่ใช่ความผิดของพวกเขาทั้งหมด แต่ก็ไม่ใช่ว่าไม่มีส่วนผิดเลย
    • เห็นแพตเทิร์น “ต้องพิสูจน์ความชอบธรรมของงาน” นี้ตลอดในทีม DevOps ปกติแล้วคนดูแลระบบที่อาวุโสหรือได้เงินเดือนสูงที่สุด มักใช้เวลาไปกับการดับไฟที่เกิดจากความไร้ความสามารถหรือความผิดพลาดของตัวเอง เลยดูเหมือนกำลังทำอะไรอยู่
      ถ้ากำจัดงานซ้ำ ๆ ด้วยระบบอัตโนมัติ ตำแหน่งของคนนั้นก็จะหายไป แต่ถ้าทำให้ถูกต้อง ผู้จัดการก็จะคิดว่าคนนั้นนั่งเฉยทั้งวันและไม่ทำอะไร จึงแทบไม่มีแรงจูงใจให้ทำในทางที่ถูก
    • เวลาได้ทำงานกับนักพัฒนาใหม่ ๆ แค่ทดสอบพื้นฐานอย่างการดับเบิลคลิก ช่องว่างด้านหน้า หรือปุ่มย้อนกลับของ Android ก็ทำให้พลาดกันได้บ่อยแล้ว พอโดนตีกลับไปไม่กี่ใบก็จะเรียนรู้เรื่องพวกนี้ และหลังจากนั้นก็มักไม่ค่อยเกิดปัญหาเดิมอีก
      เพราะไม่ได้ถูกประเมินจากจำนวนบั๊กที่พบ จึงไม่มีแรงกดดันให้ต้องยัดเยียดหาบั๊กงี่เง่าเพื่อปั่นตัวเลข
    • ได้ยินคำพูดว่า “ถ้าฝึกเขาแบบนั้น เดี๋ยวเขาก็ได้เงินมากขึ้นแล้วลาออกไปที่อื่น” มาแทบทุกบริษัท การฝึกที่มีความหมายนั้นเป็น uphill battle มาโดยตลอด
      การฝึกที่ดีต้องมีคนเก่งที่กว้างพอและดีพออยู่ในสายงานเทคนิค ไม่จำเป็นต้องรู้ทุกเทคโนโลยีล่าสุด แต่ต้องจับพิรุธและชี้ให้เห็นเรื่องพูดมั่วได้ FAANG ก็ไม่ใช่ข้อยกเว้น

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

    • แม้จะเป็นนักพัฒนาแอปมือถือ ก็ควรระวังไม่ไปรับงานที่มีลักษณะเป็น งานของหน่วยงานต้นทุน
      accessibility, observability, logging ที่ดี, การปรับปรุง test infrastructure, การปรับ CI/CD, ความเสถียร, linting ที่ดีขึ้น และปัญหาเกี่ยวกับ analyzer ล้วนสำคัญ แต่คนจะได้รางวัลจากการปล่อยฟีเจอร์ให้เร็ว
      ปีนี้ผมใช้เวลากับงานพวกนั้นมากเกินไปเพราะคิดว่าทีมและแอปต้องการ และตอนนี้ก็เริ่มกังวลเรื่องประเมินผลงานปลายปีแล้ว ตอนนี้เข้าใจแล้วว่าทำไมคนอื่นถึงเลี่ยงงานแบบนี้ ปีหน้าคิดว่าจะโฟกัสไปที่การปล่อยฟีเจอร์ที่มองเห็นได้ชัดมากกว่า ต้องขอโทษเรื่องบั๊กในแอปด้วย แต่ถ้าจะผ่อนบ้านก็ต้องมีงานทำ
    • เห็นด้วยกับความรู้สึกเรื่องเป็นหน่วยงานต้นทุน แต่จากประสบการณ์มันมีรายละเอียดมากกว่านั้นนิดหน่อย
      บางองค์กรให้คุณค่ากับสิ่งที่ QA/QC นำมาอย่างจริงใจ เรื่องนี้เห็นชัดในภาคการผลิตมากกว่าซอฟต์แวร์ ซึ่งเดาว่าเพราะซอฟต์แวร์เป็นนามธรรมกว่าโดยธรรมชาติ และติดตามความสูญเปล่าได้ยากกว่า
      QA ที่ยอดเยี่ยมจริง ๆ ไม่ใช่คนที่มองหาทางง่าย แต่เป็นคนที่เชื่อใน ภารกิจของ QA สุดท้ายแล้วสิ่งที่สร้างคุณค่าคือองค์กรและตัวบุคคลยอมรับจิตวิญญาณของ QA อย่างจริงจังหรือไม่ และหลายที่ก็ทำแค่ตามพิธี
    • อยู่ทีมแพลตฟอร์มฟรอนต์เอนด์ ทำทั้งการปรับปรุงประสิทธิภาพ ออกแบบ CI และ process engineering แต่ก็ยากกว่ามากที่จะได้รับการยอมรับและเลื่อนตำแหน่ง เมื่อเทียบกับคนที่ปล่อยฟีเจอร์ที่เปลี่ยนเป็นเงินเข้าบัญชีได้โดยตรง
      แต่ก็ไม่เป็นไร ผมสนุกกับการทำให้สิ่งต่าง ๆ ดีขึ้นและแข็งแรงขึ้น และมันทำให้สบายใจขึ้น งานทำพังปล่อยให้คนชอบถากถางไปทำก็แล้วกัน
    • ผมทำงานอยู่ในหน่วยงานต้นทุนมาแทบทั้งชีวิต แต่ก็ไม่อยากแลกกับอย่างอื่น
      ต่อให้โบนัสหรืออะไรทำนองนั้นไปอยู่กับกลุ่มอื่นก็ไม่เป็นไร งานสายเทคนิคก็จ่ายดีพออยู่แล้ว และงานที่ทำเงินพวกนั้นหลายตำแหน่ง ต่อให้ผมทำได้ดีจริง ก็คงทำให้ผมไม่มีความสุขมาก
    • เพราะงั้นผมเลยไม่ทำงานในแผนก IT ของธุรกิจแบบดั้งเดิม

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

    • การมองว่าสตาร์ตอัปอาจมีผลิตภัณฑ์ที่ดูแลต่อไม่ได้ในอีก 5 ปี ก็อาจเป็นท่าทีที่สมเหตุสมผล เพราะสตาร์ตอัปส่วนใหญ่ไปไม่รอดถึง 5 ปีและล้มเหลว
      ถ้าอีก 5 ปีแล้วยังอยู่รอดทั้งที่มี technical debt มาก สำหรับสตาร์ตอัปจำนวนมาก นั่นอาจเป็นปัญหาที่ดีเสียด้วยซ้ำ เพราะอย่างน้อยก็แปลว่าอยู่รอดมาได้ 5 ปีแล้ว

  • วิศวกร QA มักจะเก่งเรื่องดีบักมากด้วย แตะทั้ง pipeline, source, ไดเรกทอรีทดสอบ และเกี่ยวข้องกับแทบทุกด้านของการพัฒนาและการ deploy แอปพลิเคชัน
    ตอนที่ฉันเป็น QA lead ฉันเห็นวิศวกรซอฟต์แวร์ที่ไม่ยอมแม้แต่อ่านข้อความ error ของ pipeline แต่กลับมาบ่นใน Slack ทุกวันอยู่บ่อย ๆ แม้ตอน optimize pipeline ก็ยังเมินปัญหาต้นตอ แล้วพยายามแก้อาการที่เกิดจากต้นตอนั้นด้วยการเดาอยู่หลายวัน ราวกับเป็นปัญหาลึกลับที่ไม่มีทางเข้าใจได้
    การดูแคลนวิศวกร QA ที่พูดถึงในบทความนี้ไม่ได้เกินจริง บริษัทที่มีองค์กร QA อยู่หลายแห่งก็มักไม่มีขั้นตอนสัมภาษณ์ที่เข้มงวดแบบองค์กรวิศวกรรม ทำให้วิศวกร QA ถูกประเมินค่าต่ำ
    SWE ที่ให้ความเคารพ QA มีแต่คนที่เคยทำงานใน QA มาก่อนเท่านั้น การดูแคลนมันแพร่หลายมากจนสุดท้ายฉันกลับไปอยู่ฝั่งองค์กรวิศวกรรม และพยายามใช้ความอาวุโสระดับ principal engineer กับบทบาทผู้จัดการเพื่อเปลี่ยนแปลง แต่ก็ไม่สำเร็จ ฝั่งวิศวกรรมมองไม่พ้นความหยิ่งผยองของตัวเอง และผู้นำก็ไม่ได้ช่วยอะไร
    CTO คนใหม่ของบริษัทที่ฉันทำงานอยู่ก่อนถูกเลิกจ้างบอกว่าสามารถทำให้ความจำเป็นของ QA หายไปได้ด้วย automation แต่ไม่ได้ยกตัวอย่างเลยสักอย่างว่าหมายถึงอะไร ระดับความเคารพจากเบื้องบนต่อการสร้างซอฟต์แวร์ที่ดีมีอยู่แค่นั้นเอง

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

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

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

    • สำหรับฉัน คุณค่าของ QA คือ ความคุ้นเคยกับผลิตภัณฑ์ QA ที่ดีรู้ดีที่สุดว่าผลิตภัณฑ์ทำงานจริงอย่างไร
      พวกเขารู้ระบบทั้งหมดในมุมที่ผู้ใช้มองเห็นได้ครอบคลุมกว่า PM หรือฝ่ายขาย หรือแม้แต่ทีมพัฒนาส่วนใหญ่ และบอกได้อย่างแม่นยำว่าถ้ากดปุ่มไหนจะเกิดอะไรขึ้น QA แย่ ๆ ก็เป็นแหล่งกำเนิดของเสียงรบกวนจริง แต่ก็ไม่ต่างจากนักพัฒนา ผู้ดูแลระบบ หรือทีมซัพพอร์ตระดับ 1/2 ที่แย่ ๆ
    • QA ที่ดีมีบทบาทต่อวิศวกรซอฟต์แวร์เหมือนที่บรรณาธิการที่ดีมีต่อนักเขียน มองผลงานที่คุณทุ่มเทสร้างมาอย่างเยือกเย็นและวิจารณ์แบบไม่ไว้หน้า
      ตอนโดนมันน่าหงุดหงิดมาก แต่คุณภาพของผลลัพธ์จะดีขึ้นมาก
      QA สมัยก่อนมักไม่ได้เขียนเทสต์ แต่จะทดสอบโค้ดด้วยมือ และลองทำพฤติกรรมแปลก ๆ ทุกอย่างที่คุณหวังว่าผู้ใช้จะไม่ทำ พวกเขาหาปัญหาและบั๊กที่ยากจะจับด้วยเทสต์ทั่วไปได้
      ตอนนี้เราโยน QA ไปให้ผู้ใช้แทน เวลาได้ทำงานกับนักพัฒนารุ่นใหม่จะรู้สึกว่าแนวคิดเรื่อง QA เองกำลังกลายเป็นของแปลกขึ้นเรื่อย ๆ เวลาเจอบั๊กหลุดขึ้น production แล้วถามว่า “ตอนลองเล่นบน local มันเป็นยังไงบ้าง” ก็มักได้สีหน้างง ๆ กลับมา เหมือนคิดว่าแค่ผ่าน type checker แล้วจะไม่ปล่อยได้ยังไง
      ทุกวันนี้ประสิทธิภาพของโปรแกรมเมอร์ถูกวัดด้วยจำนวน PR ต่อนาที ดังนั้นการใส่บั๊กเข้าไปไม่ใช่ปัญหา กลับเป็นเรื่องดีเสียอีก เพราะถ้าใครไปเจอใน production ก็ออก PR มาแก้อีกฉบับได้ในอีกไม่กี่วัน ถ้ามี QA อยู่ก็คงมาทำลายกระแสนี้เสียหมด
    • ฉันเป็น QA ที่เขียนเทสต์ให้วิศวกรรม และตำแหน่งที่ถูกต้องคือ SDET ไม่ได้ดูแค่แผนทดสอบ แต่ดูทั้ง test framework, infrastructure และการทำ automation ให้กับแผนทดสอบเหล่านั้น
      แต่ละบริษัททำฟังก์ชัน QA ต่างกัน บางที่โยนให้ลูกค้า บางที่ให้ฝั่งนักพัฒนา ฝ่ายสนับสนุนลูกค้า QA แบบแมนนวล หรือ SDET ทำ สุดท้ายแล้วมันขึ้นอยู่กับว่าผู้นำให้ความสำคัญกับคุณภาพมากแค่ไหน และมอง QA อย่างไร
      ถ้ามีทีม QA ฉันคิดว่าพวกเขาจะมีโอกาสสำเร็จมากที่สุดเมื่อได้เข้าไปมีส่วนร่วมตั้งแต่ต้นของกระบวนการ QA ที่ดีควรหาบั๊กได้ก่อนที่โค้ดจะถูกเขียนเสียอีก ยิ่งเข้ามาช้าก็ยิ่งพบบั๊กช้า และยิ่งถูก squeezed หนักขึ้นระหว่าง “โค้ดเสร็จแล้ว” กับการปล่อยรีลีส ทีม QA ต้องมีความสามารถด้าน automation เพื่อจะได้ใช้เวลากับ test case ใหม่ แทนที่จะทำ manual test ซ้ำ ๆ
      บทความนี้แทงใจพอสมควร QA บางครั้งถูกปฏิบัติเหมือนพลเมืองชั้นสอง และถูกกันออกจากวงสนทนาที่ให้บริบทที่จำเป็นต่อการทำงานให้ดีได้ พอคนเก่ง ๆ ย้ายไปฝั่งพัฒนาหรือ product management มันก็ยิ่งแย่ลง และวงจรขาลงแบบนี้มีอยู่จริง
    • เพราะไม่มีวิธีการอย่างเป็นทางการในการบริหารองค์กร QA คนจำนวนมากจึงถูกจ้างเข้ามาแล้วได้ยินเพียงว่า “ลองจัดการกันเอาเอง” จากนั้นองค์กรอื่น ๆ ก็ไม่เข้าใจว่าทำไมต้องมี QA เลยเลือกจะมองข้าม
      สิ่งที่อธิบายมาทั้งหมดนี่คือ ปัญหาของผู้นำ ไม่ใช่ปัญหาว่า QA มีประโยชน์หรือไม่
    • ในโมเดลคลาสสิก องค์กร QA ส่วนใหญ่มักเดินเครื่องเหมือนหน่วยงานลูกที่ไร้ประโยชน์ ทั้งในเชิงโครงสร้างและเพราะเมื่อการพัฒนาล่าช้า QA มักเป็นฝ่ายที่ถูกเบียดออกไป
      QA ใช้เวลาไปกับการสร้าง test infrastructure และแผนทดสอบโดยไม่ได้ถูกรวมเข้าตั้งแต่ต้น แล้วสุดท้ายก็ได้รับโค้ดก้อนโตกับตารางอนุมัติภายใน 48 ชั่วโมง และต้อง sign-off ภายใต้ความกดดันอย่างหนัก
      แต่บางครั้งก็เจอองค์กร QA ที่เข้าใจ problem domain อย่างลึกซึ้งและเป็นฝ่ายขับเคลื่อนการพัฒนาจริง ๆ พวกเขาเดินขนานกับการพัฒนาตั้งแต่ต้นจนจบ ไม่เพียงยกระดับคุณภาพ แต่ยังช่วยประหยัดเวลาของทุกคนด้วย

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