หยุด!! บอกแค่ว่า “มันพัง” แต่ต้องบอกให้ได้ว่า “พังท่าไหน” ด้วย API Response Code

คิดว่าทุกคนต้องเคยเป็นแบบนี้ เราเทสงานอยู่ดีๆ หน้าจอก็ขึ้น loading ไม่หยุด
หรือไม่ก็มี error ตัวแดงเด้งขึ้นมา แล้วทุกอย่างก็ระเบิด เทสต่อไม่ได้ 

แล้วสิ่งแรกที่เราทำก็คือ วิ่งไปโวยวายกับ Dev (หรือทัก slack) แล้วก็บอกว่า 

“หน้า xxx มันพังค่ะพี่”

ทีนี้เราอาจจะได้คำถามกลับมาจาก Dev ว่า 

“พังยังไง”
“หน้าจอโชว์อะไร”
“ใส่ data ไม่ถูกรึเปล่า”

แล้วเราก็ได้แต่ทำตาปริบๆ ไม่รู้จะตอบยังไง
สุดท้ายก็ต้องรอให้ Dev มาเช็คให้ เสียเวลาทั้งคู่

ตรงนี้แหละ คือเส้นแบ่งระหว่าง QA ทั่วไป กับ QA ที่ดี QA ร่างทองที่เราอยากจะเป็นกัน
QA ที่ดี จะไม่ทำแค่รายงานว่าของพัง แต่เราต้องช่วย “วินิจฉัยโรค” เบื้องต้นได้ด้วย

สิ่งแรกที่จะช่วยเราได้คือ API Response Code นี่แหละค่ะ

หรือบางทีเราก็เรียกมันว่า Status Code

วิธีที่เราจะดูมันได้เนี่ย อย่างแรกเลย เวลาเทสงาน ให้เราเปิด Dev Tools หน้า Network Tab ทิ้งไว้เสมอ

ใครยังไม่รู้ว่าเปิดยังไง ใน Chrome เราสามารถเปิดได้หลายวิธี เช่น… 

• กด F12 -> แล้วเลือก Network
• คลิกขวาที่จอ -> เลือก Inspect -> แล้วไปที่ Network
• คลิกที่เมนูสามจุด -> เลือก More Tools -> เลือก Developer Tools -> แล้วไปที่ Network

ในนี้เราจะเห็นหมดเลยว่าแอปที่เรากำลังเทสอยู่ มันวิ่งไปเรียก API อะไร แล้ว API นั้นตอบอะไรกลับมาบ้าง

และขั้นตอนแรกที่เราจะเช็คได้ง่ายที่สุดก็คือ Status Code ที่พ่นออกมา
ถ้าเราสังเกตเลขตรงนั้นดู ก็จะรู้ว่ามันมีความหมายซ่อนอยู่ค่ะ
ขั้นต้นเรายังไม่ต้องจำทั้งหมดก็ได้ เอาแค่เลขตัวหน้าก่อน

ถ้าเห็นขึ้นต้นด้วย 2 ก็สบายใจได้ API ทำงานสำเร็จเรียบร้อยดี

อันนี้สำคัญมาก ส่วนใหญ่ถ้าขึ้นต้นด้วยเลข 4 มักจะแปลว่า Request ที่ส่งไป
มันมีอะไรบางอย่าง “ผิด” ถ้าอยากเจาะลึกลงไปอีก แต่ละเลขก็จะมีความหมายของมันอยู่ เรามาดูเลขที่เจอบ่อยๆกัน

• 400 Bad Request: ส่งข้อมูลไปผิดท่า เช่น บอกให้ส่งเป็นเลข แต่เราส่งตัวอักษร หรือ เป็น required field แต่เราไม่ได้ส่ง
• 401 Unauthorized: ยังไม่ได้ Login, Token ไม่ถูก หรือลืมใส่ Token
• 403 Forbidden: มีสิทธิ์เข้าถึงแอปแล้ว (login แล้ว) แต่ไม่มีสิทธิ์ทำตรงนี้หรือกดปุ่มนี้ (ไม่มี permission)
• 404 Not Found: หา endpoint นี้ไม่เจอ หรือ หา resource นั้นๆไม่เจอ เช่น URL ผิด อาจจะยังไม่ได้ deploy หรือ ใส่ user id ผิด

Tips: ถ้าเจอ error ขึ้นด้วยเลข 4 ให้ลองเช็คดูก่อนว่าฝั่งเราส่งอะไรไปผิดมั้ย
หรืออาจจะเป็นว่าหน้า UI ส่งไปหา backend ไม่ถูกก็ได้ ซึ่งก็จะช่วยให้ Dev หาปัญหาได้ง่ายขึ้น

ถ้าขึ้นเลข 5 แปลว่าหลังบ้านมีปัญหาแน่ๆ
ซึ่งตรงนี้ อาจจะเป็นได้ทั้งตัวโค้ดของ service นั้นๆ หรือ Infrastructure อย่างเช่น Server ล่ม Database พัง ก็ได้

• 500 Internal Server Error: หลังบ้านระเบิด Logic พัง อาจจะลืม handle อะไรบางอย่างจนทำให้ service นั้นแตก
• 503 Service Unavailable: อันนี้ส่วนใหญ่คือ Server ล่ม, Deploy แล้วแตก, Database พังจนตอบกลับมาไม่ได้

Tips: ถ้าเจอ error ขึ้นด้วยเลข 5 เรา Capture Network Tab พร้อม Request/Response ส่งให้ Dev ได้เลย ไม่ต้องรอ ทีมจะได้รีบเช็คต่อว่าเกิดอะไรขึ้น

เอาง่ายๆแค่นี้ แค่เราบอกได้ว่าพังเพราะ 4xx หรือ 5xx ก็เป็นการทำ Root Cause Analysis (RCA) เบื้องต้นแล้วค่ะ เราจะกลายเป็น QA ที่ช่วยสโคปปัญหาให้ทีมได้

แทนที่จะโยนลงไปเฉยๆว่า “มันพัง” แต่ถ้าเราบอกได้ว่า
“มันพัง เพราะ API ตอบ 400 กลับมา คิดว่า frontend น่าจะลืมส่ง field user id ไปนะคะ” 

เราจะกลายเป็น QA ที่ได้รับความเชื่อใจจากทีมมากขึ้นแบบ 1000%

แค่เราดูเพิ่มอีกนิดเดียว แต่ผลลัพธ์กลับต่างกันแบบมหาศาล
การจะเป็น QA ร่างทองตัวเทพ ไม่ได้หมายความว่าเราต้องเขียนโค้ดเก่งเท่า Dev
แต่หมายถึงการเข้าใจ “ภาษา” ที่ระบบใช้คุยกัน 
และเราก็จะสามารถไปคุยกับ Dev ด้วยภาษาที่เค้าเข้าใจได้ 
และก็จะช่วยนำทางให้ทีมไปถึงจุดหมายได้เร็วขึ้นตามไปด้วย

“Quality starts with how you think (and how you check the Network tab!)”

ใครยังไม่ได้เปิด Network tab ก็เริ่มเลยนะคะ
หรือใครยังไม่รู้จักความแตกต่างของ Status Code วันนี้เราก็รู้แล้วนะคะ
แล้วหลังจากนี้เราจะคุยกับ Dev ได้ง่ายขึ้นเยอะ!!

ลองดูแล้วเป็นยังไง อย่าลืมมาเล่าให้ฟังด้วยนะคะ 
หรือใครเจออะไรแปลกๆ Status Code แปลกๆ ก็ลองมาแชร์กันได้เลย