MS Dashboard (@Demo) - v125.2.1
QA 2.0: เมื่อบริษัทต่างๆ เลิกใช้ QA บทบาทใหม่ก็เพิ่มขึ้น — สถาปนิกด้านคุณภาพ
ในอุตสาหกรรมเทคโนโลยี มีการเปลี่ยนแปลงอย่างเงียบๆ เกิดขึ้น บทบาทด้านการรับรองคุณภาพ (QA) กำลังหายไปจากตารางขององค์กร วิศวกร QA กำลังถูกปลดออก ทีม QA ทั้งหมดถูกดูดซับเข้าสู่สายงานวิศวกรรมหรือยุบรวมไปทั้งหมด ชื่อตำแหน่งเช่น "นักวิเคราะห์ QA" หรือ "ผู้ทดสอบซอฟต์แวร์" กำลังหายไปจาก LinkedIn และถูกแทนที่ด้วยคำศัพท์เฉพาะด้านระบบอัตโนมัติและภาษาที่เน้นนักพัฒนา
ทำไม? เพราะวัฒนธรรมการพัฒนาสมัยใหม่ทำให้บริษัทต่างๆ เชื่อว่านักพัฒนาสามารถและควรเป็นเจ้าของการทดสอบ และเพื่อความยุติธรรม พวกเขาไม่ได้คิดผิด
แต่พวกเขากำลังทำผิดพลาดร้ายแรง: พวกเขาสับสนระหว่างการทดสอบกับคุณภาพ
เมื่อ QA หายไป คุณภาพกลายเป็นปัญหาของทุกคน-
แต่เมื่อนักพัฒนาเป็นผู้รับผิดชอบการทดสอบ ใครคือผู้เป็นเจ้าของคุณภาพที่แท้จริง?
ใครเป็นผู้สร้างกลยุทธ์ จัดการความเสี่ยง และมองเห็นภาพรวม?
การทดสอบคือภารกิจ คุณภาพคือวัฒนธรรม
บ่อยครั้ง QA มักถูกมองว่าเป็นเพียงการทดสอบด้วยตนเอง การคลิกผ่าน UI หรือการตรวจสอบการแก้ไขจุดบกพร่อง แต่แนวคิดดังกล่าวล้าสมัยและลดทอนประสิทธิภาพลง QA เกี่ยวข้องกับการจัดการความเสี่ยง ความเห็นอกเห็นใจของผู้ใช้ การคิดแบบระบบ และวงจรข้อเสนอแนะ การทดสอบเป็นเพียงส่วนหนึ่งของปริศนาที่ใหญ่กว่ามาก
บางคนแย้งว่าเราไม่ควรต้องมีบทบาทเฉพาะทางเลย พวกเขาบอกว่า “เราทุกคนล้วนเป็นวิศวกร” และแม้ว่าความร่วมมือจะเป็นสิ่งสำคัญ แต่บทบาทต่างๆ ก็มีไว้เพื่อให้เกิดความมุ่งเน้นและความลึกซึ้ง
ผู้จัดการผลิตภัณฑ์ให้ความสำคัญกับวิสัยทัศน์ นักพัฒนาให้ความสำคัญกับการสร้างสรรค์ วิศวกร QA ให้ความสำคัญกับการที่ทุกอย่างจะดำเนินไปภายใต้แรงกดดันและความรู้สึกของผู้ใช้
หมวกคนละใบ แต่ภารกิจเดียวกัน
อย่างไรก็ตาม ขอให้ชัดเจนว่านักพัฒนาควรเขียนการทดสอบ
การทดสอบยูนิต การทดสอบบูรณาการ สัญญา API เป็นส่วนหนึ่งของงาน การทำงานอัตโนมัติไม่ใช่ทางเลือกอีกต่อไป แต่การทดสอบเพียงอย่างเดียวไม่สามารถรับประกันได้ว่าซอฟต์แวร์จะดี การทดสอบจะช่วยรับประกันว่าโค้ดจะทำงานตามที่บอก ไม่ใช่ว่าจะทำตามที่ผู้ใช้คาดหวังหรือไม่ ซึ่งตรงนี้เองที่ QA ไม่เคยเป็นเพียงการทดสอบเท่านั้น
- วิศวกร QA จะคิดถึงระบบ ไม่ใช่แค่ฟังก์ชั่นเท่านั้น
- พวกเขาถามว่า มีความเสี่ยงอะไรบ้าง?
- พวกเขาดูที่พฤติกรรมของผู้ใช้ ไม่ใช่แค่สาขาของโค้ดเท่านั้น
- สร้างความมั่นใจ ไม่ใช่แค่ความครอบคลุม
เมื่อ QA หายไป ชั้นคุณภาพที่มองไม่เห็นเหล่านี้ก็มักจะหายไปด้วย และทันใดนั้น ข้อบกพร่องก็เกิดขึ้นกับการผลิต ไม่ใช่เพราะไม่มีใครทดสอบ แต่เพราะไม่มีใครคิดเหมือน สถาปนิกด้านคุณภาพ
จะเกิดอะไรขึ้นเมื่อนักพัฒนาเป็นเจ้าของการทดสอบ?
ข้อผิดพลาดที่บริษัทต่างๆ ทำไม่ใช่การมอบความรับผิดชอบในการทดสอบมากขึ้นให้กับนักพัฒนา แต่เป็นการเชื่อว่าการลบ QA ออกไปก็หมายความว่าไม่จำเป็นต้องมีการคิดเชิงคุณภาพอีกต่อไป
การย้ายการทดสอบไปให้นักพัฒนาสามารถปรับปรุงความเร็วและความรับผิดชอบได้ แต่ก็สร้างความท้าทายใหม่ ๆ ขึ้นมา:
1. อคติต่อเส้นทางแห่งความสุข: นักพัฒนามักจะทดสอบสิ่งที่พวกเขาสร้าง ไม่ใช่ทดสอบว่ามันพังอย่างไร
2. วิสัยทัศน์แบบอุโมงค์: หากไม่มีเลนส์องค์รวมของ QA กรณีขอบและความล้มเหลวในระดับระบบก็จะลอดผ่านได้
3. การสูญเสียการทดสอบเชิงสำรวจ: ระบบอัตโนมัติไม่สามารถแทนที่ความอยากรู้อยากเห็นของมนุษย์ได้อย่างสมบูรณ์ ผู้ใช้จริงทำสิ่งที่คาดไม่ถึง ดังนั้น QA จึงควรทำเช่นกัน
4. ไม่มีเวลาสำหรับกลยุทธ์: นักพัฒนามักถูกกดดันให้ต้องส่งมอบผลงาน การเขียนและบำรุงรักษาการทดสอบเป็นเพียงหนึ่งในลำดับความสำคัญหลายประการเท่านั้น กลยุทธ์ด้านคุณภาพมักไม่ได้รับการเน้นย้ำเท่าที่ควร
คำถามก็คือ ถ้าทุกคนเป็นเจ้าของการทดสอบ แล้ว ใครเป็นเจ้าของคุณภาพ ?
เข้าสู่: สถาปนิกคุณภาพ
บางครั้งทีมงานอาจติดกับดักของการพยายามทดสอบให้ครอบคลุม 100% หรือการทำให้ทุกอย่างเป็นอัตโนมัติ แต่ QA ตัวจริงเข้าใจ:
“ไม่ใช่ว่าทุกสิ่งที่สามารถทดสอบได้ก็ควรได้รับการทดสอบ ไม่ใช่ว่าทุกสิ่งที่สามารถทำงานอัตโนมัติได้ก็ควรทำงานอัตโนมัติเช่นกัน”
มันเกี่ยวกับมูลค่ามากกว่าปริมาณ
เครื่องมืออย่าง Cypress, Playwright และ Jest นั้นยอดเยี่ยมมาก แต่ต้องใช้อย่างมีกลยุทธ์และจุดประสงค์ที่ชัดเจนเท่านั้น Dropbox เน้นย้ำเรื่องนี้โดยเน้นที่การเขียนการทดสอบที่มีคุณค่าและบำรุงรักษาได้แทนที่จะเพิ่มจำนวนการทดสอบเพียงอย่างเดียว
ในขณะที่บทบาท QA แบบดั้งเดิมค่อยๆ หายไปจากแผนภูมิองค์กรของบริษัท บทบาทแบบผสมผสานรูปแบบใหม่จึงเกิดขึ้น ไม่ใช่ QA, ไม่ใช่ผู้ทดสอบ, ไม่ใช่ผู้พัฒนา แต่เป็นผู้คนที่เข้าใจทั้งสองโลกและสามารถเชื่อมช่องว่างระหว่างโค้ดกับความมั่นใจได้
เราเรียกพวกเขาว่า สถาปนิกคุณภาพ
นี่ไม่ใช่คนๆ หนึ่งที่จะคลิกปุ่มหรือเขียนกรณีทดสอบ แต่เป็นคนที่วิศวกรไว้วางใจในระดับขนาดใหญ่ ด้วยการออกแบบระบบ ไม่ใช่แค่สคริปต์เท่านั้น
ความรับผิดชอบของสถาปนิกคุณภาพจะเป็นดังนี้:
🎯 กลยุทธ์และสถาปัตยกรรมคุณภาพ
- กำหนดและพัฒนากลยุทธ์คุณภาพแบบ cross-stack จากหน่วยงานไปสู่ UI, e2e ไปจนถึงการติดตามการผลิต
- จัดการแนวทางการทดสอบตามความเสี่ยง: มุ่งเน้นที่ผลกระทบ ไม่ใช่แค่การครอบคลุมเท่านั้น
- ออกแบบสถาปัตยกรรมการทดสอบอัตโนมัติ: เลเยอร์อัตโนมัติ โครงสร้างที่เก็บข้อมูล สภาพแวดล้อม ไปป์ไลน์
- ให้คำแนะนำแก่ทีมงานในการรักษาสมดุลของระบบอัตโนมัติที่เหมาะสม (ต้องทดสอบอะไร ไม่ควรทดสอบอะไร ทำไม และอย่างไร)
- ขับเคลื่อนการทดสอบความสามารถในการปรับขนาด ความสามารถในการบำรุงรักษา และประสิทธิภาพการทำงานทั่วทั้งโครงการและบริการ
🧠 ความร่วมมือข้ามฟังก์ชั่น
- ร่วมมือกับผลิตภัณฑ์ การออกแบบ และวิศวกรรม เพื่อระบุความเสี่ยงในระยะเริ่มต้น ก่อนที่จะเขียนโค้ดแม้แต่บรรทัดเดียว
- ฝังความคิดเชิงคุณภาพลงในแผน การปรับปรุงงานค้าง และการอภิปรายการออกแบบ
- เชื่อมช่องว่างการสื่อสารระหว่างบทบาทต่างๆ เพื่อให้แน่ใจว่าประสบการณ์ของผู้ใช้ ฟังก์ชันการทำงาน และความน่าเชื่อถือมีความสอดคล้องกัน
💬 โค้ชชิ่งและความเป็นผู้นำด้านวัฒนธรรม
- สอนถึงเหตุผล “เหตุใด” จึงต้องปฏิบัติในด้านคุณภาพ ไม่ใช่แค่เพียงวิธีทดสอบเท่านั้น แต่ทำไมการทดสอบจึงมีความสำคัญ
- เป็นที่ปรึกษาให้กับนักพัฒนาเกี่ยวกับกลยุทธ์การทดสอบและวิธีการจัดสรรคุณภาพที่เหลือในเวิร์กโฟลว์ของพวกเขา
- สนับสนุนแนวคิดคุณภาพร่วมกัน ช่วยให้ทีมมองเห็น QA เป็นพันธมิตรเชิงกลยุทธ์ ไม่ใช่แค่เพียงช่วงหนึ่ง
- ทำให้การปฏิบัติต่างๆ กลายเป็นมาตรฐาน เช่น การทดสอบเชิงสำรวจ การทดสอบ UX และการกำหนดลำดับความสำคัญตามความเสี่ยง
🤖 เครื่องมือและการเปิดใช้งาน AI
- เป็นผู้นำการประเมินและการนำเครื่องมือทดสอบที่ขับเคลื่อนด้วย AI มาใช้ (เช่น การสร้างการทดสอบ การตรวจจับเกล็ด การวิเคราะห์)
- กำหนดการกำกับดูแลสำหรับโค้ด/การทดสอบที่สร้างโดย AI เพื่อให้แน่ใจว่าผลลัพธ์มีความน่าเชื่อถือ ตรวจสอบได้ และบำรุงรักษาได้
- เพิ่มประสิทธิภาพสภาพแวดล้อมการทดสอบและข้อมูลเพื่อรองรับระบบอัตโนมัติที่ชาญฉลาดและมีเสถียรภาพ
📊 ตัวชี้วัด การสังเกต และวงจรข้อเสนอแนะ
- ติดตามตัวชี้วัดคุณภาพที่สำคัญ: อัตราการหลบหนีของข้อบกพร่อง ความน่าเชื่อถือของการทดสอบ คุณภาพการครอบคลุม เวลาในรอบการทำงาน ฯลฯ
- สร้างแดชบอร์ดและการแสดงภาพเพื่อให้มองเห็นคุณภาพด้านสุขภาพและความเสี่ยงได้ชัดเจน
- บูรณาการวงจรข้อเสนอแนะจากการผลิต (เช่น บันทึก ความผิดพลาด ตั๋วการสนับสนุน) เข้ากับกลยุทธ์การทดสอบในอนาคต
- 🔍 เชื่อมโยงจุดต่างๆ ระหว่างจุดบกพร่อง ประสบการณ์ของผู้ใช้ ผลกระทบต่อธุรกิจ และการบำรุงรักษาในระยะยาว
🧩 การเปิดใช้งานสถาปัตยกรรมคุณภาพ
- กำหนดโครงสร้างที่เก็บข้อมูลทดสอบ ประเภทอัตโนมัติ (หน่วย, API, E2E) และรูปแบบความเป็นเจ้าของ
- สร้างกรอบงานและเครื่องมือที่ทำให้ผู้พัฒนาสามารถทดสอบได้อย่างมีประสิทธิภาพ โดยไม่ทำให้การทำงานช้าลง
- จัดเตรียมรูปแบบที่ปรับขนาดได้สำหรับการรวม CI/CD การดำเนินการคู่ขนาน และการจัดการข้อมูลการทดสอบ
โดยสรุป สถาปนิก QA ไม่ได้อยู่ที่นี่เพื่อเขียนการทดสอบทุกครั้ง แต่พวกเขาอยู่ที่นี่เพื่อออกแบบระบบที่ทำให้คุณภาพเป็นไปได้ในระดับขนาดใหญ่
พวกเขาคือ:
- 🧠 พันธมิตรเชิงกลยุทธ์
- 🧑🏫 นักการศึกษา
- 🧪 นักคิดเชิงระบบ
- 💬 ผู้สนับสนุนด้านคุณภาพ
- 🤖 ตัวช่วย AI
- 🔍 ผู้พิทักษ์ความไว้วางใจของผู้ใช้งาน
มันเป็นบทบาทที่เน้นที่ประสบการณ์ ความเห็นอกเห็นใจ และการตัดสินทางวิศวกรรม และเป็นสิ่งที่วิศวกร QA พร้อมที่จะพัฒนาไป
แต่ความจริงก็คือ การโอนการทดสอบไปให้ผู้พัฒนาไม่ได้หมายความว่าจะต้องยุติ QA แต่หมายความว่าเราต้องกำหนด QA ใหม่ และยิ่งไปกว่านั้น เราต้องให้ความรู้แก่ทีมงานด้วย เพราะเราทุกคนกำลังมุ่งหน้าไปในทิศทางเดียวกัน นั่นคือการส่งมอบผลิตภัณฑ์ที่ดีกว่า การทำงานซ้ำได้เร็วขึ้น และลดความเสี่ยง ไม่ใช่แค่ตอบสนองต่อความเสี่ยงเท่านั้น
เราไม่สามารถบรรลุเป้าหมายได้หากถือว่า QA เป็นเพียงช่องกาเครื่องหมายหรือสิ่งที่คิดขึ้นภายหลัง เราต้องสร้างความเป็นเจ้าของคุณภาพแบบข้ามฟังก์ชัน โดยมีสถาปนิกคุณภาพเป็นศูนย์กลาง คอยกำหนดกลยุทธ์ ยกระดับมาตรฐาน และตรวจสอบให้แน่ใจว่าคุณภาพจะขยายตามฐานโค้ด
นั่นหมายความว่าบทบาทของ QA กำลังพัฒนา ทักษะหลัก การคิดวิเคราะห์ ความอยากรู้อยากเห็น และแนวคิดของระบบมีความเกี่ยวข้องมากกว่าที่เคย สิ่งที่จำเป็นคือการเปลี่ยนแปลงตัวตน
บทสรุป
QA 2.0 จะเน้นไปที่การยกระดับคุณภาพให้กลายเป็นวินัยและการเปลี่ยนวิศวกร QA ให้กลายเป็นผู้นำ นักวางแผนกลยุทธ์ และ สถาปนิก เนื่องจากอนาคตของคุณภาพไม่ได้ขึ้นอยู่กับบทบาทใดบทบาทหนึ่ง แต่เป็นหน้าที่ของผู้กล้าที่จะเป็นเจ้าของมัน
คุณภาพเป็นความรับผิดชอบของทุกคน แต่ยังมีบางคนที่ต้องสร้างสถาปัตยกรรมที่ทำให้คุณภาพสามารถปรับขนาดได้ ยั่งยืน และเป็นจริง นั่นคือจุดที่ สถาปนิกด้านคุณภาพ เข้ามามีบทบาท ไม่ใช่เพื่อเฝ้าประตู แต่เพื่อนำทางการเดินทาง
ใช่ นักพัฒนาควรทดสอบ แต่ที่สำคัญกว่านั้น ทุกคนควรใส่ใจเรื่อง คุณภาพ เริ่มมองว่ามันเป็นกาวที่ยึดเกาะกัน จากวิสัยทัศน์สู่การปฏิบัติ จากโค้ดสู่ความมั่นใจ และจากทีมสู่ผู้ ใช้ ในขณะที่การทดสอบยังคงเปลี่ยนแปลงไป เราต้องแน่ใจว่าคุณภาพจะไม่ตกหล่น ไป
แล้ววิศวกร QA ล่ะ พวกเขาไม่ได้ถูกผลักออกไป พวกเขาถูกเรียกตัวมาเพื่อเป็นผู้นำ เพื่อกำหนดกลยุทธ์ เพื่อเป็นกระบอกเสียงให้กับผู้ใช้ในห้องที่เต็มไปด้วยผู้รับผิดชอบ แต่ทีมงานต้องเปิดใจรับฟังเสียงเหล่านี้
ดังนั้นหากตำแหน่งงานของคุณกำลังจะหายไป อย่าเพิ่งตกใจ ให้พัฒนาตนเองต่อไป
จะเป็นสถาปนิกคุณภาพ
เพราะคุณภาพยังคงเป็นสิ่งสำคัญและมีใครสักคนต้องเป็นเจ้าของมัน
อ่านเพิ่มเติม: https://medium.com/@marinacruzjordao/qa-2-0-as-companies-kill-qa-a-new-role-is-rising-the-quality-architect-044d43cda2a8
ข้อความล่าสุดจาก
