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