รายการตรวจสอบการทดสอบข้ามเบราว์เซอร์ที่ใช้งานได้จริง
เลย์เอาต์อาจดูสมบูรณ์แบบในเบราว์เซอร์หนึ่ง แต่อาจพังในอีกเบราว์เซอร์หนึ่งได้ โทรศัพท์ Android รุ่นประหยัดที่มีหน้าจอแคบ หรือแล็ปท็อปเครื่องเก่าที่ตั้งค่าซูมไว้ 125% สามารถทำให้ดีไซน์ของคุณพังได้
อย่ามองว่าการทดสอบเป็นเพียงขั้นตอนสุดท้ายที่ทำแบบผ่านๆ แต่จงปฏิบัติกับมันในฐานะรายการตรวจสอบ (checklist) ที่เฉพาะเจาะจง
มุ่งเน้นไปที่ส่วนที่มีความเสี่ยงสูง:
- ฟอร์มและช่องกรอกข้อมูล (Forms and inputs)
- เมนูนำทาง (Navigation menus)
- การขยับของเลย์เอาต์ (Layout shifts)
- การโหลดฟอนต์ (Font loading)
- การโต้ตอบด้วย JavaScript (JavaScript interactions)
เลิกพยายามทดสอบทุกเบราว์เซอร์ที่มี เพราะนั่นเป็นการเสียเวลา ให้ใช้รูปแบบเมทริกซ์ที่กระชับแทน:
- เบราว์เซอร์ Chromium หนึ่งตัวบนเดสก์ท็อป
- สภาพแวดล้อม Safari หนึ่งชุด
- สภาพแวดล้อม Firefox หนึ่งชุด
- โทรศัพท์ Android หนึ่งเครื่อง
- iPhone หนึ่งเครื่อง
วางแผนการทดสอบให้สอดคล้องกับวิธีที่ผู้คนใช้งานผลิตภัณฑ์ของคุณจริงๆ หน้าเว็บไม่จำเป็นต้องดูเหมือนกันทุกที่ แต่ต้องใช้งานได้ อ่านง่าย และมีความเสถียร
รายการตรวจสอบของคุณควรประกอบด้วย:
- เบราว์เซอร์และระบบปฏิบัติการ (OS)
- ความกว้างของ Viewport
- ระดับการซูม
- ขั้นตอนการใช้งานของผู้ใช้ (user flows) ที่เฉพาะเจาะจง
ทำรายการให้สั้นเข้าไว้ หากการทดสอบหนึ่งครั้งต้องใช้เวลาถึงครึ่งวัน ทีมของคุณจะข้ามมันไป การตรวจสอบอย่างรวดเร็วที่ดีควรใช้เวลาน้อยกว่าหนึ่งชั่วโมง
เริ่มต้นที่โครงสร้าง ตรวจสอบหน้าโฮมเพจ หน้าเนื้อหา และฟอร์มต่างๆ ลองปรับขนาดหน้าต่างจากความกว้างเดสก์ท็อปเป็นความกว้างมือถือ ลองซูมเข้า และคอยสังเกตปัญหาเหล่านี้:
- ปุ่มที่ตัดบรรทัดอย่างผิดปกติ
- หัวข้อที่ถูกตัดขาด
- การเลื่อนในแนวนอน (Horizontal scrolling)
- แถบเมนูด้านบน (Sticky headers) ที่บังเนื้อหา
- หน้าต่างป๊อปอัป (Modals) ที่บังปุ่มควบคุมที่สำคัญ
ต่อไป ให้ทดสอบการโต้ตอบ (interactions) เบราว์เซอร์แต่ละตัวจัดการฟอร์มแตกต่างกัน ให้ทดสอบช่องกรอกข้อความ, ตัวจัดการรหัสผ่าน, ตัวเลือกวันที่ และการอัปโหลดไฟล์ ตรวจสอบดูว่าระบบเติมข้อมูลอัตโนมัติ (autofill) ส่งผลต่อเลย์เอาต์ของคุณอย่างไร
ทดสอบส่วนประกอบที่ใช้ JavaScript หนักๆ เช่น แท็บ (tabs), อะคอร์เดียน (accordions) และการแนะนำคำค้นหา (search suggestions) หน้าเว็บอาจไม่แสดงข้อผิดพลาดในคอนโซล (console) แต่ปุ่มอาจจะยังใช้งานไม่ได้
สุดท้าย ให้ทำ Stress Test เว็บไซต์ของคุณ:
- จำกัดความเร็วเครือข่าย (Throttle your network speed)
- ปิดการใช้งานแคช (Disable your cache)
- ใช้ข้อความที่ยาวมากในช่องกรอกข้อมูล
- โหลดรายการให้มากกว่าปกติเพื่อตรวจสอบการล้นของเนื้อหา (overflow)
รายการตรวจสอบที่ดีที่สุดคือรายการที่น่าเบื่อ มันควรเป็นรายการที่ระบุแค่ "ผ่าน" หรือ "ไม่ผ่าน" อย่างง่ายๆ ใช้มันทุกครั้งที่คุณปล่อยเวอร์ชันใหม่ เมื่อมีบั๊กหลุดไปถึงขั้นตอนการใช้งานจริง (production) ให้เพิ่มความล้มเหลวเฉพาะจุดนั้นลงในรายการตรวจสอบของคุณ
รายการตรวจสอบจะมีประโยชน์ก็ต่อเมื่อมันช่วยจดจำในสิ่งที่ทีมของคุณลืมไป
ที่มา: https://dev.to/graceholloway_/a-practical-cross-browser-testing-checklist-1p6a