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