FastAPI ออก 3 รุ่นเปลี่ยนกติกาฟอร์ม ช่องว่างอาจใช้ค่าเริ่มต้นหรือส่งไม่ผ่าน

FastAPI ออก 3 รุ่นที่มีการเปลี่ยนพฤติกรรมซึ่งอาจกระทบระบบเดิมในวันที่ 19–20 ตุลาคม 2026 ตามบันทึกการออกรุ่น ได้แก่ 0.148.0, 0.149.0 และ 0.150.0 โดยเปลี่ยนวิธีจัดการค่าเริ่มต้น ช่องข้อความว่าง และช่องอัปโหลดที่ไม่ได้เลือกไฟล์ (FastAPI Release Notes) เรื่องนี้เกี่ยวกับคนกรอกฟอร์มสมัครสมาชิก คนดูแลแบบฟอร์มร้านค้า และทีมที่ทำหน้าส่งสลิป เพราะหลังอัปเกรด การเว้นช่องไว้เฉย ๆ อาจให้ผลต่างจากเดิมได้

ประเด็นที่ควรจำคือ ช่องว่างอาจถูกนับว่า “ไม่ได้ส่งข้อมูล” แทนที่จะเป็น “ส่งข้อความว่างมาแล้ว” หากเป็นช่องบังคับ ระบบจะรายงานว่าข้อมูลไม่ผ่านการตรวจสอบ แต่ถ้ามีค่าเริ่มต้นก็จะใช้ค่านั้น ส่วนไฟล์ที่มีชื่อแต่มีขนาดศูนย์ไบต์ยังรับได้ตามกติกาใหม่ (GitHub: 0.149.0, GitHub: 0.150.0) ดังนั้น ก่อนทีมเว็บอัปเกรด ผมอยากให้ลองกดส่งฟอร์มแบบที่ผู้ใช้ไม่ได้กรอกครบด้วยครับ

สรุป 30 วินาที: เกิดอะไรขึ้น

FastAPI เป็นเฟรมเวิร์ก หรือเครื่องมือพื้นฐานสำหรับสร้างส่วนรับส่งข้อมูลของเว็บ ข่าวรอบนี้มีคำว่า breaking changes ซึ่งหมายถึงการเปลี่ยนที่อาจทำให้ระบบซึ่งอาศัยพฤติกรรมเดิมต้องปรับตาม ทั้งสามรุ่นถูกจัดไว้ในหมวดนี้ในบันทึกการออกรุ่น (FastAPI Release Notes)

• 0.148.0 วันที่ 19 ตุลาคม: เมื่อผู้ใช้ไม่ได้ส่งค่าบางช่องมา ค่าเริ่มต้นที่ระบบเติมให้จะไม่ถูกถือว่าเป็นข้อมูลจากผู้ใช้ และจะไม่ถูกตรวจสอบโดยอัตโนมัติ เว้นแต่เปิด validate_default=True ซึ่งเป็นตัวเลือกให้ตรวจค่าเริ่มต้นด้วย (FastAPI Release Notes)
• 0.149.0 วันที่ 19 ตุลาคม: ข้อความว่าง "" ในช่องฟอร์มที่รับค่าเดี่ยวผ่านแบบจำลองข้อมูล จะถือว่าขาดข้อมูล ช่องบังคับจึงเกิดข้อผิดพลาด ส่วนช่องที่มีค่าเริ่มต้นจะใช้ค่าเริ่มต้นนั้น (GitHub: 0.149.0)
• 0.150.0 วันที่ 20 ตุลาคมตามบันทึกการออกรุ่น: ช่องอัปโหลดที่ไม่มีทั้งชื่อไฟล์และเนื้อหา จะถือว่าไม่ได้ส่งไฟล์มา ช่องบังคับจึงเกิดข้อผิดพลาด ส่วนช่องที่มีค่าเริ่มต้นจะใช้ค่านั้น (FastAPI Release Notes)

หน้า PyPI ซึ่งเป็นแหล่งเผยแพร่แพ็กเกจ Python ระบุรุ่นล่าสุดเป็น 0.150.0 และกำหนดให้ใช้ Python ตั้งแต่ 3.10 ขึ้นไป ข้อมูลชุดนี้จึงเป็นเรื่องที่ผู้ดูแลระบบควรเช็กทั้งรุ่นของ FastAPI และสภาพแวดล้อมที่ใช้รันก่อนเปลี่ยนรุ่น (PyPI)

ทำไมเรื่องนี้เกี่ยวกับคุณ

สำหรับผู้ใช้ทั่วไป ผลที่ควรทำความเข้าใจคือ “ปล่อยว่าง” อาจมีความหมายต่อระบบมากกว่าที่หน้าจอแสดง หากเว็บไซต์ใช้ฟอร์มตามกรณีที่เปลี่ยนใน 0.149.0 ช่องที่บังคับกรอกและได้รับข้อความว่างจะไม่ผ่านการตรวจสอบ ส่วนช่องที่เตรียมค่าเริ่มต้นไว้จะเลือกใช้ค่านั้น (GitHub: 0.149.0) ลองนึกถึงแบบฟอร์มสมัครสมาชิกหรือแบบฟอร์มร้านค้าเป็นตัวอย่างประกอบ ไม่ได้หมายความว่ามีบริการเหล่านี้เสียแล้วตามข่าว

สำหรับเจ้าของร้านหรือคนดูแลงานเอกสาร ผมแนะนำให้คุยกับทีมเว็บให้ชัดว่าแต่ละช่องต้องการอะไร ช่องที่ผู้ใช้จำเป็นต้องตอบควรมีพฤติกรรมที่เข้าใจตรงกัน ส่วนช่องที่ปล่อยให้ระบบเลือกค่าให้ควรตรวจว่าค่าที่เลือกนั้นเหมาะกับงานจริงหรือไม่ คำแนะนำนี้มาจากผลของกติกาใหม่ที่แยกช่องบังคับออกจากช่องที่มีค่าเริ่มต้น (FastAPI Release Notes)

สำหรับคนทำระบบอัปโหลดสลิปหรือเอกสาร กรณีที่ควรลองคือกดส่งโดยไม่ได้เลือกไฟล์ เพราะเบราว์เซอร์ หรือโปรแกรมเปิดเว็บ สามารถส่งส่วนข้อมูลไฟล์ที่ชื่อว่างและเนื้อหาว่างมาได้ รุ่น 0.150.0 จะตีความกรณีนี้เป็นไม่ได้ส่งไฟล์ (GitHub: 0.150.0) นี่เป็นสถานการณ์ที่ควรทดสอบกับหน้าจอจริงของงาน โดยยังไม่มีข้อมูลในแหล่งข่าวว่าบริการใดในไทยได้รับผลกระทบแล้ว

ทำงานยังไง

เริ่มจากคำว่า ค่าเริ่มต้น หรือ default ก่อนครับ นี่คือค่าที่ผู้พัฒนากำหนดไว้ให้ใช้เมื่อข้อมูลไม่ถูกส่งมา ส่วน ตัวตรวจสอบข้อมูล หรือ validator คือกติกาที่ใช้ตรวจค่าก่อนนำไปทำงาน รุ่น 0.148.0 เปลี่ยนให้ค่าเริ่มต้นของข้อมูลที่ไม่ได้ส่งมาไม่ถูกถือว่าเป็นข้อมูลจากผู้ใช้ และไม่ถูกตรวจสอบ เว้นแต่เปิดการตรวจค่าเริ่มต้นไว้ (FastAPI Release Notes)

ขอบเขตที่บันทึกระบุมี Query ซึ่งเป็นข้อมูลประกอบในคำขอเว็บ, Header ซึ่งเป็นข้อมูลกำกับคำขอ, Cookie ซึ่งเป็นข้อมูลที่เบราว์เซอร์ส่งประกอบกลับมา, Form ซึ่งเป็นข้อมูลจากแบบฟอร์ม และช่องข้อมูลในโมเดล คำว่าโมเดลในที่นี้คือแบบจำลองที่กำหนดว่าระบบจะรับข้อมูลช่องใดและตรวจอย่างไร (FastAPI Release Notes)

เปรียบกับ พนักงานรับใบสมัคร ที่เคยถือว่าช่องว่างคือ “ตอบว่าว่าง” ตอนนี้ถือว่า “ไม่ได้ตอบ” ถ้าช่องนั้นต้องตอบก็ส่งกลับให้แก้ ถ้ามีกติกาให้ใช้คำตอบเริ่มต้นก็เติมตามกติกา จุดสำคัญคือการมีคำตอบที่พนักงานเติมให้ ไม่ได้แปลว่าผู้สมัครเป็นคนเขียนคำตอบนั้นเอง การเปรียบเทียบนี้ช่วยอธิบายทั้งเรื่องช่องว่างและการแยกค่าเริ่มต้นออกจากข้อมูลที่ผู้ใช้ส่ง ซึ่งเป็นแกนของการเปลี่ยนรอบนี้ (FastAPI Release Notes)

ในรุ่น 0.149.0 เบราว์เซอร์ส่งช่องข้อความที่ไม่ได้กรอกเป็นข้อความว่าง "" FastAPI จะถือข้อความว่างในช่องค่าเดี่ยวของ form model ว่าไม่ได้ส่งค่า โดย form model คือการรวมช่องฟอร์มไว้ในแบบจำลองข้อมูลเดียว พฤติกรรมนี้ทำให้ตรงกับการรับ Form ทีละช่องที่มีอยู่แล้ว (GitHub: 0.149.0) เอกสาร Form Models อธิบายว่า FastAPI ดึงข้อมูลแต่ละช่องจากฟอร์มเข้ามาเป็นโมเดล Pydantic ซึ่งเป็นเครื่องมือกำหนดและตรวจรูปแบบข้อมูล (FastAPI Form Models)

คำว่า “ค่าเดี่ยว” สำคัญ เพราะข้อความว่างที่อยู่ข้างในรายการหลายค่ายังถูกเก็บไว้ และช่องบูลีน หรือค่าที่มีสองสถานะคือจริงกับเท็จ ที่ไม่ได้ส่งมายังกลายเป็น False หรือเท็จตามเดิม การเปลี่ยนนี้ไม่ได้ครอบคลุมคำขอ JSON ซึ่งเป็นรูปแบบข้อมูลที่โปรแกรมใช้ส่งหากัน และไม่ได้เปลี่ยนการตรวจ Pydantic โดยตรง (GitHub: 0.149.0) จึงไม่ควรสรุปว่าข้อมูลว่างทุกแบบในระบบจะถูกจัดการเหมือนกันทั้งหมด

ส่วนรุ่น 0.150.0 แยก “ไม่ได้เลือกไฟล์” ออกจาก “เลือกไฟล์ที่ไม่มีเนื้อหา” โดยกรณีแรกต้องมีทั้งชื่อไฟล์ว่างและเนื้อหาว่างจึงถูกถือว่าขาดข้อมูล ถ้าเป็นรายการไฟล์ ช่องที่ไม่ได้เลือกจะถูกละไว้ แต่ไฟล์ที่มีชื่อและขนาดศูนย์ไบต์ยังรับได้ (GitHub: 0.150.0) การรับได้ตามข้อนี้หมายถึงพฤติกรรมของ FastAPI ที่ระบุในข่าว ส่วนไฟล์นั้นใช้ทำงานของร้านหรือองค์กรได้จริงหรือไม่เป็นสิ่งที่ทีมต้องกำหนดและตรวจเอง

จุดหักมุม: มีค่าแล้ว แต่ยังนับว่าไม่ได้กรอก

รายละเอียดที่ทีมพัฒนาไม่ควรมองข้ามคือ ระบบอาจมีค่าใช้งานแล้ว แต่ช่องนั้นยังไม่ถูกนับว่าผู้ใช้ส่งมาเอง รุ่น 0.148.0 ระบุว่าในโมเดลของข้อมูลคำขอ การเติมค่าเริ่มต้นจะไม่ทำเครื่องหมายว่าช่องนั้นถูกกำหนดมาอย่างชัดเจน และรุ่น 0.149.0 ก็ระบุพฤติกรรมนี้สำหรับช่องฟอร์มว่างที่ได้รับค่าเริ่มต้นเช่นกัน (FastAPI Release Notes)

ผลจะเห็นเมื่อใช้ model_dump(exclude_unset=True) ซึ่งเป็นวิธีนำข้อมูลออกจากโมเดลโดยเว้นช่องที่ไม่ได้ถูกกำหนดมา ช่องที่มีเพียงค่าเริ่มต้นจึงไม่ติดออกไปด้วยตามกรณีข้างต้น แม้ระบบจะมีค่านั้นให้ใช้งานอยู่แล้วก็ตาม (FastAPI Release Notes) สำหรับทีมที่ใช้ข้อมูลชุดนี้ส่งต่อไปยังขั้นตอนบันทึกหรือปรับข้อมูล ผมแนะนำให้ตรวจผลที่ออกมาจริงด้วย การทดสอบเพียงว่าฟอร์มส่งผ่านอาจยังตอบไม่ครบว่าข้อมูลที่ส่งต่อมีอะไรบ้าง

แต่ช่องบูลีนที่ไม่ได้ส่งมาเป็นข้อที่ต้องแยกไว้ รุ่น 0.148.0 ย้ำว่ายังคงได้ False และนับว่าเป็นค่าที่กำหนดมาอย่างชัดเจน ขณะที่รายละเอียดของ 0.147.0 อธิบายว่าเป็นการทำให้ตรงกับช่องทำเครื่องหมาย HTML ที่ไม่ได้เลือก (FastAPI Release Notes) ดังนั้น อย่าใช้ข้อสรุปเรื่องค่าเริ่มต้นกับทุกช่องโดยไม่ดูชนิดข้อมูล

อีกจุดคือ default factory หรือฟังก์ชันที่สร้างค่าเริ่มต้นเมื่อจำเป็น รุ่น 0.148.0 ระบุว่าจะทำงานครั้งเดียว และข้อความผิดพลาดจากการตรวจข้อมูลจะไม่รวมค่าเริ่มต้นที่ระบบเติมเข้าไปเป็นข้อมูลขาเข้า (FastAPI Release Notes) หากทีมเคยอาศัยรายละเอียดเหล่านี้ตรวจเหตุขัดข้อง ก็ควรอ่านผลลัพธ์หลังอัปเกรดใหม่ครับ

เรื่องเงิน / ผลกระทบ

แหล่งข่าวไม่ได้ระบุตัวเลขความเสียหาย รายได้ที่หายไป หรือค่าใช้จ่ายในการปรับระบบ จึงยังบอกเป็นจำนวนเงินไม่ได้ สิ่งที่ยืนยันได้คือฟอร์มช่องบังคับที่ส่งข้อความว่าง และช่องไฟล์บังคับที่ไม่ได้เลือกไฟล์ จะเกิดข้อผิดพลาดตามเงื่อนไขใหม่ ขณะที่ช่องซึ่งมีค่าเริ่มต้นจะใช้ค่าเริ่มต้นนั้น (GitHub: 0.149.0, GitHub: 0.150.0)

ในมุมงานประจำวัน ผมประเมินว่าต้นทุนที่ควรเตรียมคือเวลาตรวจฟอร์ม เวลาปรับข้อความแจ้งผู้ใช้ และเวลาตรวจข้อมูลที่ถูกส่งต่อ นี่เป็นการประเมินจากพฤติกรรมที่เปลี่ยน ไม่ใช่รายงานว่ามีธุรกิจเสียเงินแล้ว หากฟอร์มเป็นส่วนหนึ่งของการรับคำสั่งซื้อหรือส่งเอกสารประกอบการชำระเงิน ก็ควรจัดลำดับการทดสอบตามความสำคัญของงานนั้น

อีกเรื่องที่อาจมองข้ามคือความหมายของการล้างช่อง สมมติทีมหน้าจอออกแบบให้ข้อความว่างหมายถึงผู้ใช้ต้องการลบค่าเดิม ควรทดสอบเจตนานี้โดยตรง เพราะในช่องค่าเดี่ยวของ form model ข้อความว่างจะถูกตีความเป็นขาดข้อมูล และอาจใช้ค่าเริ่มต้นแทนตามกติกาใหม่ (GitHub: 0.149.0) ตัวอย่างนี้เป็นกรณีให้ทีมตรวจ ไม่ใช่ข้อยืนยันว่าระบบเก็บข้อมูลทุกแห่งจะลบหรือไม่ลบด้วยวิธีเดียวกัน

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

วันที่ของ 0.150.0 มีข้อมูลต่างกัน บันทึกการออกรุ่นบนเว็บไซต์ FastAPI ระบุวันที่ 20 ตุลาคม 2026 แต่ข้อมูลวันที่ที่แนบมากับหน้ารีลีส GitHub ระบุ 19 ตุลาคม 2026 และไม่มีเวลาให้เทียบ จึงยังสรุปไม่ได้ว่าความต่างนี้เกิดจากเขตเวลาหรือสาเหตุใด บทความนี้ใช้วันที่ตามบันทึกการออกรุ่นเมื่อเล่าลำดับรุ่น (FastAPI Release Notes, GitHub: 0.150.0)

ส่วน PyPI ให้เวลาอัปโหลดเป็น UTC จึงแปลงเป็นเวลาไทยได้ชัดเจน: รุ่น 0.148.0 อัปโหลดวันที่ 19 ตุลาคม เวลา 19:26:03 น., รุ่น 0.149.0 วันที่ 20 ตุลาคม เวลา 00:22:27 น. และรุ่น 0.150.0 วันที่ 20 ตุลาคม เวลา 05:39:42 น. โดยแสดงถึงระดับวินาที (PyPI) เวลาอัปโหลดนี้ควรอ่านแยกจากวันที่หัวข้อในบันทึกการออกรุ่น ไม่ควรนำมารวมแล้วเดาว่าข้อมูลใดผิด

ยังไม่มีข้อมูลผลกระทบในไทย แหล่งข้อความที่ให้มาไม่ได้ระบุชื่อองค์กรไทย จำนวนเว็บไซต์ที่เจอปัญหา หรือรายการระบบที่ได้รับผลกระทบ จึงบอกไม่ได้ว่าเว็บที่คุณใช้อยู่เกี่ยวข้องหรือไม่ ธุรกิจในไทยที่ใช้ FastAPI ควรให้ผู้ดูแลตรวจรุ่นและรูปแบบการรับข้อมูลของตัวเองก่อนสรุป

ไม่มีข้อสรุปเรื่องช่องว่างทุกชนิด ข้อความของรุ่น 0.149.0 กล่าวถึงข้อความว่าง "" ไม่ได้อธิบายรายละเอียดของข้อความที่มีอักขระเว้นวรรคอยู่ข้างใน และย้ำว่าข้อความว่างในรายการยังคงถูกเก็บไว้ (GitHub: 0.149.0) จึงไม่ควรขยายความว่าอะไรก็ตามที่ตาเรามองว่าว่างจะถูกจัดการเหมือนกัน ควรทดสอบกรณีที่หน้าจอของคุณส่งจริง

ข่าวนี้ยังไม่ใช่หลักฐานความเสียหายด้านความปลอดภัย แหล่งหลักอธิบายการเปลี่ยนการตรวจข้อมูลและการรับฟอร์ม โดยไม่ได้ให้เหตุการณ์โจมตีหรือยอดข้อมูลรั่ว การอ่านข่าวนี้จึงควรเน้นความเข้ากันได้ของระบบและความถูกต้องของข้อมูลตามขอบเขตที่ประกาศ (FastAPI Release Notes)

แล้วเราควรทำอะไร

ผู้ใช้ทั่วไปและคนกรอกฟอร์ม

1. หากช่องบังคับส่งไม่ผ่าน ให้ดูข้อความแจ้งแล้วกรอกข้อมูลหรือเลือกไฟล์ตามที่งานต้องใช้ อย่าเพิ่งสรุปว่าอุปกรณ์เสีย เพราะกติกาใหม่มีกรณีที่ช่องว่างและการไม่เลือกไฟล์ทำให้ไม่ผ่านการตรวจสอบอยู่แล้ว (GitHub: 0.149.0, GitHub: 0.150.0)
2. ถ้าเคยส่งแบบเดิมได้แต่ตอนนี้ส่งไม่ได้ ผมแนะนำให้แจ้งผู้ดูแลว่าปล่อยช่องใดว่างหรือไม่ได้เลือกไฟล์ช่องใด เพื่อให้ทีมลองสถานการณ์เดียวกันได้ โดยยังไม่จำเป็นต้องรู้ว่าเว็บไซต์ใช้ FastAPI หรือไม่

เจ้าของร้าน ผู้ดูแลงาน และผู้รับผิดชอบเว็บไซต์

1. ให้ทีมตรวจว่าใช้ FastAPI รุ่นใด และมีแผนอัปเกรดผ่านสามรุ่นนี้หรือไม่ ผมแนะนำให้ตรึงรุ่น หรือ pin version ซึ่งคือกำหนดรุ่นที่ใช้ให้แน่นอน ระหว่างเตรียมทดสอบ เพื่อให้รู้ว่ากำลังตรวจพฤติกรรมของรุ่นไหน
2. ตกลงเป็นรายช่องว่าปล่อยว่างแล้วต้องแจ้งเตือนหรือให้ระบบใช้ค่าเริ่มต้น โดยยึดความต้องการของงานเป็นหลัก เพราะผลของสองกรณีนี้ต่างกันในกติกาที่ประกาศ (FastAPI Release Notes)
3. ให้คนที่ใช้ฟอร์มจริงลองงานสำคัญก่อนนำรุ่นใหม่ขึ้นใช้งาน ผมแนะนำให้รวมทั้งการไม่กรอกช่อง การไม่เลือกไฟล์ และการตรวจข้อมูลหลังส่ง เพื่อยืนยันว่าจบงานได้ตามที่ตั้งใจ

นักพัฒนาและทีมดูแลระบบ

1. อ่านบันทึก 0.148.0–0.150.0 เป็นชุด แล้วแยกรายการตรวจเป็นค่าเริ่มต้น ข้อความว่าง และไฟล์ที่ไม่ได้เลือก เพราะแต่ละรุ่นแก้คนละส่วนของการรับข้อมูล (FastAPI Release Notes)
2. ตรวจตัวตรวจสอบข้อมูลที่เคยคาดว่าจะทำงานแม้ผู้ใช้ไม่ได้ส่งค่า หากยังต้องการตรวจค่าเริ่มต้น เอกสารระบุให้ใช้ Field(validate_default=True) สำหรับช่องในโมเดล หรือ Query(validate_default=True) เป็นตัวอย่างสำหรับข้อมูลที่รับแยกทีละตัว และระบุว่า Body(validate_default=True) ซึ่งใช้กับเนื้อหาคำขอมีผลแล้วด้วย (FastAPI Release Notes)
3. เพิ่มชุดทดสอบฟอร์มที่แยกช่องค่าเดี่ยวแบบบังคับ ช่องมีค่าเริ่มต้น และช่องมีฟังก์ชันสร้างค่าเริ่มต้น ตรวจทั้งผลการรับข้อมูลและผลของ model_dump(exclude_unset=True) เพราะการมีค่าในโมเดลกับการถูกนับว่าส่งมาเป็นคนละเงื่อนไข (GitHub: 0.149.0)
4. แยกทดสอบข้อความว่างในรายการ ช่องบูลีนที่ไม่ได้ส่ง คำขอ JSON และการตรวจ Pydantic โดยตรง เพื่อยืนยันว่าทีมไม่ได้เผลอเปลี่ยนความคาดหวังของกรณีที่เอกสารระบุว่ายังคงเดิม (GitHub: 0.149.0)
5. ทดสอบช่องไฟล์บังคับ ช่องไฟล์ที่มีค่าเริ่มต้น รายการไฟล์ที่บางช่องไม่ได้เลือก และไฟล์มีชื่อแต่ศูนย์ไบต์ กรณีสุดท้ายควรแยกจากการไม่ได้เลือกไฟล์ เพราะ FastAPI ยังรับไฟล์ดังกล่าวตามประกาศ (GitHub: 0.150.0)
6. คุยกับทีม frontend หรือทีมทำหน้าจอ ว่ามีช่องใดตั้งใจส่ง "" เพื่อสื่อความหมายเฉพาะ แล้วตกลงผลลัพธ์ให้ชัด ผมแนะนำให้ทดสอบจากหน้าจอจริงร่วมกับชุดทดสอบฝั่งรับข้อมูล เพื่อให้สิ่งที่ผู้ใช้ทำกับสิ่งที่ระบบเข้าใจตรงกัน

ผมมองว่า…

ผมมองว่า ในความเห็นของผม การเปลี่ยนครั้งนี้ ไม่ใช่แค่เรื่องช่องว่าง แต่คือข้อตกลงว่าผู้ใช้ได้ตอบอะไรจริง ๆ เมื่อระบบแยกค่าที่ผู้ใช้ส่งจากค่าที่เติมให้อัตโนมัติ ทีมก็ต้องตัดสินใจให้ชัดว่าข้อมูลแบบใดควรผ่าน แบบใดควรให้กลับไปแก้ และแบบใดควรถือว่ายังไม่ได้ตอบ ความเห็นนี้ตั้งอยู่บนรายละเอียดเรื่องค่าเริ่มต้นและการนับช่องที่กำหนดมาในบันทึกการออกรุ่น (FastAPI Release Notes)

ผมเห็นว่าการทดสอบฟอร์มตอนกรอกครบยังจำเป็น แต่ควรเพิ่มเวลาสำหรับตอนกรอกไม่ครบด้วย ผู้ใช้ไม่ได้ทำงานตามชุดข้อมูลตัวอย่างของทีมเสมอไป การตรวจให้เห็นทั้งสิ่งที่หน้าจอส่ง สิ่งที่ระบบรับ และสิ่งที่ถูกส่งต่อ จะช่วยให้ตัดสินใจก่อนอัปเกรดได้จากพฤติกรรมจริง มากกว่าดูเพียงเลขรุ่น

ปิดท้าย: สิ่งที่ต้องจับตา

จุดที่ควรติดตามหลังปรับรุ่นคือช่องที่เคยเก็บข้อความว่างยังได้ผลตรงตามงานหรือไม่ ค่าเริ่มต้นที่จำเป็นต้องตรวจถูกเปิดการตรวจไว้แล้วหรือยัง และหน้ารับไฟล์แยกกรณีไม่ได้เลือกออกจากไฟล์มีชื่อแต่ไม่มีเนื้อหาได้ตามที่ทีมต้องการหรือเปล่า ทั้งหมดนี้สอดคล้องกับสามส่วนที่ FastAPI ประกาศเปลี่ยนในรอบนี้ (FastAPI Release Notes)

สำหรับคนทั่วไป สิ่งที่ควรได้กลับไปคือความเข้าใจว่าข้อความแจ้งให้กรอกหรือแนบไฟล์อาจเกี่ยวกับกติกาของแบบฟอร์ม ส่วนทีมเว็บควรมีคำตอบจากการทดสอบว่าช่องว่างแต่ละช่องหมายถึงอะไร ก่อนปล่อยให้ผู้ใช้เป็นคนค้นพบคำตอบระหว่างทำงานครับ

Recap

• รู้ว่ารุ่น 0.148.0–0.150.0 เปลี่ยนเรื่องค่าเริ่มต้น ข้อความว่าง และไฟล์ที่ไม่ได้เลือก
• ตรวจรุ่นที่ใช้อยู่และตรึงรุ่นระหว่างเตรียมทดสอบการอัปเกรด
• แยกความต้องการของช่องบังคับออกจากช่องที่ให้ใช้ค่าเริ่มต้น
• ตรวจว่าตัวตรวจสอบข้อมูลจำเป็นต้องทำงานกับค่าเริ่มต้นหรือไม่
• ทดสอบข้อความว่างในช่องค่าเดี่ยวแยกจากข้อความว่างในรายการ
• ตรวจข้อมูลที่ส่งออกเมื่อเว้นช่องที่ไม่ได้ถูกกำหนดมา
• ทดสอบการไม่เลือกไฟล์แยกจากไฟล์มีชื่อแต่ขนาดศูนย์ไบต์
• คุยกับทีมหน้าจอเรื่องช่องที่ตั้งใจส่งข้อความว่าง แล้วลองจากฟอร์มจริง