ลองนึกภาพว่าซอฟต์แวร์ที่สำคัญที่สุดของบริษัทเกิดขัดข้องขึ้นมาอย่างกะทันหัน จะเกิดอะไรขึ้น คำสั่งซื้ออาจสูญหาย กำหนดเวลาอาจพลาดไป แต่ลูกค้าจะบ่นอย่างแน่นอน
คุณสามารถหลีกเลี่ยงสถานการณ์ที่เลวร้ายนี้ได้ด้วยการใช้กระบวนการทดสอบที่ต่อเนื่องและเข้มงวด ซึ่งจะตรวจพบปัญหาต่างๆ ก่อนที่จะก่อให้เกิดความวุ่นวาย แต่การใช้กระบวนการดังกล่าวในองค์กรนั้นพูดง่ายกว่าทำ
เอกสารนี้จะแสดงทุกสิ่งที่คุณต้องพิจารณาเมื่อเริ่มต้นใช้งานการทดสอบในบริษัท รวมถึงวิธีที่คุณจะได้รับประโยชน์จากการทดสอบในระยะยาว
แนวทางปฏิบัติแนะนำในการทดสอบสำหรับทีมผลิตภัณฑ์
ส่วนแรกของเอกสารนี้จะครอบคลุมกระบวนการเริ่มต้นใช้การทดสอบในเวิร์กโฟลว์
สร้างวัฒนธรรมการทดสอบในทีม
การนำการทดสอบมาใช้ในทีมให้ประสบความสำเร็จนั้นต้องอาศัยให้ทุกคนมีแนวคิดที่เหมือนกันและมองว่าคุณภาพไม่ใช่ภาระ แต่เป็นการลงทุน ซึ่งเป็นกระบวนการที่ต้องใช้เวลาและความสม่ำเสมอเช่นเดียวกับการเปลี่ยนแปลงทางวัฒนธรรมอื่นๆ
สิ่งหนึ่งที่จะช่วยสร้างวัฒนธรรมนี้ได้คือการประชุมเป็นประจำเพื่อพูดคุยเกี่ยวกับข้อบกพร่อง ผลกระทบที่เกิดขึ้น ต้นเหตุ และสิ่งที่ต้องทำเพื่อแก้ไขข้อบกพร่อง ซึ่งจะช่วยสร้างความตระหนักถึงเหตุผลที่ควรป้องกันข้อบกพร่องดังกล่าวตั้งแต่แรก
การมีบุคคลที่ทุ่มเทในทีมเพื่อดูแลและขับเคลื่อนความพยายามนี้จะช่วยเพิ่มโอกาสประสบความสำเร็จได้อย่างมาก บุคคลที่กำหนดหลักเกณฑ์ของทีมหรือแม้แต่ทั้งองค์กร รวบรวมแนวทางปฏิบัติแนะนำ แชร์แนวทางปฏิบัติแนะนำ และสนับสนุนความพยายามในทุกระดับ
อีกวิธีที่มีประโยชน์คือการหมุนเวียนบทบาทการสนับสนุนผลิตภัณฑ์ การได้รับข้อมูลเชิงลึกโดยตรงและไม่ผ่านการกรองจากลูกค้า รวมถึงการเรียนรู้เกี่ยวกับปัญหาที่ลูกค้าพบเจอในแต่ละวันเมื่อใช้ผลิตภัณฑ์ของคุณจะเป็นประสบการณ์ที่มีคุณค่าสำหรับผู้จัดการผลิตภัณฑ์ นักออกแบบ และนักพัฒนาซอฟต์แวร์
เป้าหมายคือให้ทุกคนในทีมเข้าใจว่าคุณภาพคือฟีเจอร์ที่มีความสำคัญไม่แพ้ฟังก์ชันการทำงานอื่นๆ ที่คุณสร้างขึ้นสำหรับผลิตภัณฑ์ เมื่อทุกคนมีแนวคิดดังกล่าวแล้ว การเข้าใจว่าการทดสอบก็เป็นฟีเจอร์อย่างหนึ่งจึงเป็นเรื่องที่เกิดขึ้นตามมาโดยธรรมชาติ เนื่องจากการทดสอบเป็นสิ่งที่รับประกันคุณภาพของผลิตภัณฑ์ที่เผยแพร่
กระบวนการทดสอบแบบทีละขั้นตอน
เมื่อทีมต่างๆ ที่เกี่ยวข้องกับการพัฒนาผลิตภัณฑ์มีความเข้าใจตรงกันแล้ว คุณสามารถกำหนดให้มีการทดสอบและการใช้งานการทดสอบอย่างเป็นทางการมากขึ้นได้
กำหนดให้การทดสอบเป็นส่วนหนึ่งของ "Definition of Done"
การเพิ่มการทดสอบเป็นข้อกำหนดของฟีเจอร์จะระบุว่าฟีเจอร์ยังไม่พร้อมเผยแพร่จนกว่าจะได้รับการทดสอบอย่างเหมาะสมและโดยอัตโนมัติ
ทำการทดสอบเป็นประจำ
เมื่อใช้แล้ว การทดสอบอัตโนมัติจะเป็นตัวช่วยที่สำคัญในทุกขั้นตอนของกระบวนการพัฒนา โดยไม่จำเป็นต้องมีการแทรกแซงจากมนุษย์ และสามารถดำเนินการได้ในทุกขั้นตอนที่สำคัญของไปป์ไลน์การพัฒนา เช่น
- ในทุกการคอมมิต
- ในทุก Pull Request
- หลังจากการเผยแพร่แบบเต็มหรือการเปลี่ยนแปลงสภาพแวดล้อมทุกครั้ง
หากคุณใช้บริการของบุคคลที่สามในสภาพแวดล้อมฮาร์ดแวร์และซอฟต์แวร์ การทดสอบกับสภาพแวดล้อมฮาร์ดแวร์และซอฟต์แวร์อาจเป็นเรื่องสมเหตุสมผลด้วยซ้ำ เพื่อให้มั่นใจว่า API ของบุคคลที่สามทำงานตามที่คาดไว้
กำหนดและรวบรวมเมตริก
การกำหนดชุดเมตริกเป็นสิ่งสำคัญเพื่อวัดประสิทธิภาพของการทดสอบและผลกระทบของเวิร์กโฟลว์การทดสอบต่อธุรกิจ ตัวอย่างเมตริกที่คุณใช้ได้มีดังนี้
- การเผยแพร่ต่อเดือน: จำนวนการเผยแพร่ต่อเดือนที่มากขึ้นอาจบ่งบอกถึง กระบวนการพัฒนาที่คล่องตัวมากขึ้น การทดสอบอัตโนมัติมีบทบาทสำคัญในที่นี้ด้วยการทำให้มั่นใจว่าการเผยแพร่จะดำเนินการต่อไปได้อย่างมั่นใจ
- รายงานข้อบกพร่อง: แนวโน้มที่ลดลงของรายงานข้อบกพร่องอาจเป็นสัญญาณที่ดี ว่าการทดสอบ (และกระบวนการพัฒนา) มีประสิทธิภาพ
- ความครอบคลุมของการทดสอบ: แม้จะไม่ใช่เมตริกที่แม่นยำ แต่ความครอบคลุมก็เป็นตัวบ่งชี้ที่ดี ว่าคุณกำลังทดสอบกรณีการใช้งานที่สำคัญอย่างละเอียดเพียงใด
โปรดทราบว่าเมตริกเหล่านี้ได้รับอิทธิพลจากปัจจัยอื่นๆ ด้วย ซึ่งอาจทำให้เมตริกคลาดเคลื่อน เช่น จำนวนการเผยแพร่ของคุณอาจลดลงในช่วงเทศกาลวันหยุด ในขณะที่รายงานข้อบกพร่องเพิ่มขึ้น ดังนั้นอย่าพึ่งพาเมตริกเพียงไม่กี่รายการ และตรวจสอบว่าได้เปรียบเทียบเมตริกเหล่านั้นกับข้อมูลอื่นๆ ที่ทีมของคุณมี
เมื่อคุณใช้ขั้นตอนเหล่านี้กับทีมได้สำเร็จ สุขภาพของผลิตภัณฑ์จะได้รับประโยชน์ในระยะยาวอย่างแน่นอน แต่คุณยังทำได้มากกว่านี้
แนวทางปฏิบัติแนะนำในการทดสอบสำหรับผู้ดูแลระบบ
ทีมผลิตภัณฑ์ไม่สามารถทำงานได้ด้วยตัวเอง ทีมต้องพึ่งพาฮาร์ดแวร์ เครื่องมือ และโครงสร้างพื้นฐานที่ผู้ดูแลระบบดูแล แม้ว่าโดยปกติแล้วผู้ดูแลระบบจะไม่ได้มีส่วนร่วมโดยตรงในการพัฒนาผลิตภัณฑ์ แต่ก็ยังสามารถส่งผลต่อเวิร์กโฟลว์การพัฒนาในทางที่ดีได้ เช่น การจัดการเวอร์ชันเบราว์เซอร์ที่กลุ่มผู้ใช้บางกลุ่มในบริษัทใช้
ส่วนที่ 2 ของบทความนี้จะอธิบายวิธีการทำงานนี้โดยใช้เวอร์ชันที่เผยแพร่ของ Chrome และนโยบายขององค์กร
เวอร์ชันการเผยแพร่ของ Chrome
มีเวอร์ชันการเผยแพร่ 4 เวอร์ชัน ได้แก่ เสถียร เบต้า ที่กำลังพัฒนา และ Canary
ดูข้อมูลเพิ่มเติมได้ที่ เวอร์ชันการเผยแพร่ของ Chrome
การใช้เวอร์ชันในองค์กรตัวอย่าง
โครงสร้างของทีมผลิตภัณฑ์จะแตกต่างกันไปในแต่ละองค์กร เนื่องจากไม่มีแนวทางเดียวที่เหมาะกับการพัฒนาซอฟต์แวร์ทุกรูปแบบ ตัวอย่างเช่น เราจะสมมติว่ามีทีมที่มีบทบาทต่อไปนี้ ได้แก่ การจัดการผลิตภัณฑ์, UX และ UI, วิศวกรรม, การดำเนินงาน และการสนับสนุน
สำหรับองค์กรเช่นนี้ คุณสามารถพิจารณาการแบ่งเวอร์ชันดังนี้
- การจัดการผลิตภัณฑ์: โดยปกติแล้ว PM จะใช้เวอร์ชันเสถียร เพื่อใช้เวอร์ชันเดียวกับผู้ใช้ส่วนใหญ่ บางครั้งอาจใช้เวอร์ชันเบต้าหรือที่กำลังพัฒนา หากกำลังทำงานกับฟีเจอร์ที่ต้องใช้ API ที่ยังไม่ได้เปิดตัว
- วิศวกรรมและ UX: สมาชิกบางส่วนของทีมเหล่านี้อาจใช้เวอร์ชันที่กำลังพัฒนา เพื่อให้เข้าถึงฟีเจอร์ล่าสุด เช่น การเปลี่ยนมุมมอง ได้ก่อนที่จะมีในเวอร์ชันเสถียร
- การดำเนินงาน: อาจใช้เวอร์0}เบต้า เพื่อคาดการณ์การขัดข้องที่จะส่งผลต่อผู้ใช้ ในอนาคต
- การสนับสนุน: สามารถใช้เวอร์ชันเสถียร ต่อไปเพื่อให้แน่ใจว่าทีมสนับสนุนจะโต้ตอบกับผลิตภัณฑ์ด้วยเบราว์เซอร์เดียวกับลูกค้าส่วนใหญ่
ใช้นโยบายขององค์กรเพื่อจัดการเวอร์ชัน
นอกจากการให้คำแนะนำและปล่อยให้ผู้ใช้ตัดสินใจว่าจะใช้เวอร์ชันใดแล้ว Chrome ยังมีเครื่องมือสำหรับองค์กรและการดูแลระบบเพื่อจัดการอย่างจริงจังว่าผู้ใช้แต่ละรายจะใช้เวอร์ชันใด ซึ่งเป็นประโยชน์เนื่องจากจะเพิ่มพื้นผิวการทดสอบจากผู้ใช้เพียงไม่กี่รายเป็นชุดผู้ใช้ที่กำหนดได้ทันที ซึ่งจะช่วยระบุการขัดข้องได้เร็วที่สุดและในลักษณะที่ติดตามได้
หากต้องการใช้การควบคุมระดับนั้น เราขอแนะนำการกำหนดค่าต่อไปนี้
- พนักงาน (ผู้ใช้แอป): พนักงานส่วนใหญ่ควรใช้เวอร์ชัน เสถียร ซึ่งได้รับการทดสอบอย่างสมบูรณ์โดยทีมทดสอบของ Chrome เพื่อลดความเสี่ยงที่จะเกิดการหยุดชะงัก นอกจากนี้ ผู้ใช้บางส่วน (5-10%) อาจใช้เวอร์ชันเบต้า เวอร์ชันนี้จะแสดงตัวอย่างเวอร์ชันเสถียรในช่วง 4-6 สัปดาห์ และช่วยให้ผู้ดูแลระบบค้นพบปัญหาที่อาจเกิดขึ้นกับการเผยแพร่ ทำให้มีเวลามากขึ้นในการแก้ปัญหาก่อนที่จะเปิดตัวให้ผู้อื่นใช้งาน
- แผนกไอที: สมาชิกของแผนกไอที รวมถึงผู้ดูแลระบบ เอง อาจใช้เวอร์ชันเบต้า หรือที่กำลังพัฒนา เพื่อดูตัวอย่างสิ่งที่จะมีใน Chrome เวอร์ชันเสถียรในช่วง 4-6 หรือ 9-12 สัปดาห์
เวอร์ชันการเผยแพร่ระยะยาว
การพัฒนาผลิตภัณฑ์อาจไม่รวดเร็วตามที่วางแผนไว้ และจังหวะการเผยแพร่ของ Chrome ทุกเดือนอาจถี่เกินไป สำหรับกรณีการใช้งานนี้ Chrome มีเวอร์ชันเสถียรเพิ่มเติมที่ช่วยให้คุณได้รับการอัปเดตฟีเจอร์น้อยลง แต่ยังคงได้รับการแก้ไขด้านความปลอดภัย เวอร์ชันนี้จะอัปเดตทุก 8 สัปดาห์
แผนผังต่อไปนี้แสดงให้เห็นว่าเหตุการณ์สำคัญต่างๆ ดำเนินการผ่าน เวอร์ชันการเผยแพร่ต่างๆ ของ Chromeอย่างไร
- ทั้งเวอร์ชันเสถียรและเวอร์ชันเสถียรเพิ่มเติมจะเผยแพร่เวอร์ชันเดียวกันในช่วง 4 สัปดาห์แรก หลังจากนั้นทั้ง 2 เวอร์ชันจะแตกต่างกัน
- ไม่มีเวอร์ชันเบต้าเพิ่มเติม แต่จะใช้รอบเบต้ามาตรฐาน 4 สัปดาห์เพื่อทำให้ทั้งเวอร์ชันเสถียรและเวอร์ชันเสถียรเพิ่มเติมมีความเสถียร องค์กรที่เลือกใช้เวอร์ชันเสถียรเพิ่มเติม 8 สัปดาห์ควรใช้เวอร์ชันเบต้าต่อไปเช่นเดียวกับที่ใช้ในปัจจุบัน เพื่อระบุปัญหาที่อาจส่งผลต่อสภาพแวดล้อมของตนเองในเชิงรุก
ความสำคัญอย่างต่อเนื่องของเวอร์ชันที่กำลังพัฒนาและเวอร์ชันเบต้าสำหรับผู้ใช้เวอร์ชันเสถียรเพิ่มเติม
แม้ว่าเวอร์ชันเสถียรจะเร่งรอบการเผยแพร่เป็น 2 สัปดาห์ และองค์กรของคุณจะใช้รอบเวอร์ชันเสถียรเพิ่มเติม 8 สัปดาห์เพื่อให้มีเวลาทดสอบมากขึ้น แต่การใช้เวอร์ชันที่กำลังพัฒนาและเวอร์ชันเบต้าก็ยังคงมีความสำคัญ ไม่มีเวอร์ชัน "ที่กำลังพัฒนาหรือเบต้าเพิ่มเติม" แยกต่างหาก แต่จะใช้เวอร์ชันที่กำลังพัฒนาและเวอร์ชันเบต้ามาตรฐานเพื่อทำให้ทั้งเวอร์ชันเสถียรและเวอร์ชันเสถียรเพิ่มเติมมีความเสถียร
การใช้เวอร์ชันที่กำลังพัฒนาและเวอร์ชันเบต้าต่อไปจะช่วยให้องค์กรสามารถระบุปัญหาที่อาจส่งผลต่อสภาพแวดล้อมของตนเองในเชิงรุก เวอร์ชันที่กำลังพัฒนาและเวอร์ชันเบต้าจะแสดงตัวอย่างเวอร์ชันเสถียรที่จะเผยแพร่ในอีก 4 สัปดาห์ สำหรับผู้ใช้เวอร์ชันเสถียรเพิ่มเติม หน้าต่างตัวอย่างนี้มีความสำคัญอย่างยิ่งในการค้นพบและแก้ไขการขัดข้องที่อาจเกิดขึ้นล่วงหน้าก่อนการอัปเดตฟีเจอร์ 8 สัปดาห์
โดยพื้นฐานแล้ว เวอร์ชันที่กำลังพัฒนาและเวอร์ชันเบต้าจะทำหน้าที่เป็นระบบเตือนล่วงหน้าหลักสำหรับการเปลี่ยนแปลงที่จะเกิดขึ้นในสภาพแวดล้อมเวอร์ชันเสถียรเพิ่มเติม 8 สัปดาห์ เพื่อให้มั่นใจว่าแอปขององค์กรจะยังคงใช้งานร่วมกันได้ ผู้ดูแลระบบสามารถกำหนดกลุ่มผู้ใช้ขนาดเล็กที่กำหนดได้ (เช่น ผู้ใช้แอป 5-10%) ให้ใช้เวอร์ชันที่กำลังพัฒนาและเวอร์ชันเบต้าต่อไปเพื่อเพิ่มประโยชน์สูงสุด
บทสรุป
การทดสอบเป็นส่วนสำคัญของบริษัทพัฒนาซอฟต์แวร์เพื่อให้มั่นใจในคุณภาพของผลิตภัณฑ์ และยังเป็นขั้นตอนสำคัญสำหรับผู้ดูแลระบบในการให้พนักงานขององค์กรเข้าถึงซอฟต์แวร์คุณภาพสูงและหลีกเลี่ยงการหยุดชะงักของกระบวนการทางธุรกิจ
เพื่อให้ประสบความสำเร็จเมื่อใช้เวิร์กโฟลว์การทดสอบภายในองค์กร ทุกคนควรมีแนวคิดที่เหมือนกันว่าคุณภาพและการทดสอบจึงเป็นฟีเจอร์อย่างหนึ่ง
ในเอกสารนี้ เราได้ตรวจสอบวิธีต่างๆ ในการผสานรวมแนวทางปฏิบัติแนะนำในการทดสอบ เข้ากับองค์กรของคุณ หากต้องการดูเครื่องมือทดสอบที่มีอยู่ โดยละเอียด โปรดดูบทความ เครื่องมือจาก Chrome สำหรับการทดสอบอัตโนมัติที่ราบรื่น
หากต้องการคำแนะนำในการทดสอบตั้งแต่ต้นจนจบ โปรดดูหลักสูตร Learn Testing ล่าสุดและแนวทางปฏิบัติแนะนำในการทดสอบอัตโนมัติ ใน web.dev