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