Technical

Test Suite ที่รันผ่านมาทั้งอาทิตย์ อยู่ๆ ก็มีสีแดงโผล่ขึ้นมาไม่รู้เลยว่าแอปพัง หรือ script เราพังเอง เห็นแล้วก็งงไปหมด ไม่รู้จะเริ่มจากตรงไหน. เป็นสิ่งที่พี่กิ่งเห็นซ้ำๆ ในคนที่เพิ่งเริ่มโดดเข้ามาทำ automation เลยค่ะพอ test แดง ก็ไม่รู้จะทำอะไร เลยไปไล่เปิดโค้ดดูทีละบรรทัดหรือไม่ก็ส่งให้เดฟดูเลย โดยที่ยังไม่ได้เช็คดูให้แน่ใจก่อน . Tutorial ส่วนใหญ่มันสอนเราแค่เขียน test ให้ผ่านค่ะแทบไม่มีใครสอนว่า ตอนมันไม่ผ่านนี่เกิดจากอะไรได้บ้าง แล้วต้องเช็คอะไรก่อน พอเป็นแบบนี้หลายคนเลยโดดลงไปไล่โค้ดเลยทั้งๆ ที่มันเป็นสิ่งที่ไว้ทำหลังสุดได้เลยค่ะ . ก่อนอื่นเราต้องเข้าใจก่อนว่า เป้าหมายของเราคืออะไรถ้าเรากำลังรัน automation test ชุดนี้ เพื่อเช็คของก่อน releaseก็แปลว่า สิ่งที่ควรทำก่อนคือเช็คให้แน่ใจว่า release นี้พร้อมมั้ยไม่ใช่ไปนั่งไล่โค้ด เพื่อดูว่า test มันพังตรงไหนจนทำให้ release ออกไม่ทัน . 📌 ครั้งต่อไปที่เห็นสีแดง ลองเริ่มแบบนี้ค่ะ 1️⃣ ลองกด manual ดูก่อนTest ข้อไหนพัง ก็ไปลองกดมือดูเลยค่ะ ว่ามันผ่านมั้ย

Hotfix งอก ต้องออกให้ได้ภายในวันนี้แล้วทุกคนก็หันมาถาม QA ว่า จะเทสเสร็จกี่โมง . เป็นเรื่องที่เจอกันบ่อยจนกลายเป็นเรื่องปกติไปแล้วค่ะไม่ใช่แค่ hotfix ด้วยบางทีก็เจอว่างาน delay จนของมาถึง QA ช้าไปหลายวันแต่ release date ก็ยังต้องเป็นวันเดิม เวลาเทสน้อยลงแต่งานที่ต้องเทสมันก็ยังเท่าเดิม . ที่เป็นแบบนี้ ไม่ใช่เพราะทีมทำงานไม่ดีแต่เพราะงานเทสมันมักจะอยู่ท้ายสุดพอมีจุดไหนช้า มันก็สะสมมา จนไหลมากองที่ QA ทุกที และที่เจอบ่อยคือ เราก็จะพยายามเทสทุกอย่าง โดยที่เวลาเหลือน้อยลงสุดท้ายก็ได้แต่เทสไปแบบไม่มั่นใจแล้วก็แบกความเสี่ยงเอาไว้เงียบๆ คนเดียว . 💡 อย่างนึงที่ช่วยได้คือ risk-based testingไม่ใช่เทสน้อยลง แต่เราเลือกว่าควรเทสอะไรก่อน 👉 แก้อะไรไปบ้าง และมันกระทบส่วนไหนบ้าง👉 ถ้าจุดนั้นพัง กระทบอะไรบ้าง หนักแค่ไหน สมมติว่า hotfix นี้ แก้การคำนวณคูปองส่วนลด ✅ สิ่งที่เลือกเทส: การคำนวณยอดรวม ส่วนลด และ การจ่ายเงิน❌ สิ่งที่ไว้ทีหลังได้: หน้าโปรไฟล์ ประวัติออเดอร์ การแสดงสินค้า

เดฟแก้แค่ format ของ email ยืนยันออเดอร์แต่เราจะเช็คทีนึงต้องเริ่มตั้งแต่ต้น เลือกของลงตะกร้า จ่ายเงิน เช็คเมลวนไปของที่อยากเทสจริงๆ ใช้เวลาไม่ถึงนาที แต่กว่าจะมาถึงเสียเวลาไปไม่รู้เท่าไหร่ . เราคุยกันถึงเหตุการณ์นี้ ในคลาสวันเสาร์อาทิตย์ที่ผ่านมาค่ะถ้าเรารู้ว่าระบบมี API สร้างออเดอร์ไว้ให้ใช้อยู่แล้วหรือไปขอให้เดฟช่วยทำเพิ่มไว้ให้สำหรับเทส ก็จะข้ามทั้งตะกร้าสินค้า และการจ่ายเงินไปได้เลยยิง API ปุ๊บ เช็คเมลได้ทันที พูดง่ายๆ คือเป็นช่องทางที่ไปสั่งระบบหลังบ้านได้โดยตรงโดยที่ไม่ต้องกดหน้าจอทั้ง flow แล้วก็มีคนในห้องถามต่อว่า“จะรู้ได้ยังไงว่าควรขอ API จุดไหนจากเดฟ” . คำตอบมันไม่ได้อยู่แค่เรื่อง API เลยค่ะแต่มันอยู่ที่ว่าเรารู้มั้ยว่าระบบทำงานยังไง เชื่อมต่อกันยังไง และก็มีหลายทีมที่ QA ไม่เคยมีคนพาเข้าไปดูตรงนี้เลยเห็นแค่หน้าจอที่กด เหมือน user เห็นเราเลยนึกไม่ออกว่าจะไปขอตรงไหน . 💡 ย้อนกลับมาที่ email ยืนยันออเดอร์ เรารู้ว่าควรไปขอ API สร้างออเดอร์ เพราะรู้ว่า email จะถูกส่งไปตอนออเดอร์ถูกสร้างส่วนการเลือกของลงตะกร้า กับการจ่ายเงิน มันเป็นแค่ทางผ่านเพื่อให้เราไปถึงจุดที่เราอยากเทส ถ้ารู้แบบนี้ เราก็จะรู้ทันทีว่าควรไปขออะไร ✅ พอจะมี API

ดู Tutorial มาก็หลายรอบ เปิด Youtube หลายคลิปอยากจะเริ่มเขียน Automation Testตอนเปิดดูก็เข้าใจทุกอันเลยแต่พอเริ่มทำเองตั้งแต่ต้น ก็ไม่รู้จะเริ่มยังไงอยู่ดี . แล้วเราก็คิดว่า เพราะยังจำ syntax ไม่ได้ก็เลยไปหาดูคลิปเพิ่มอีกสุดท้ายก็งงกว่าเดิม . เสาร์-อาทิตย์ ที่ผ่านมา สอน Automation รุ่น 2 ไปค่ะพี่กิ่งถามในห้องว่าใครเป็นแบบนี้บ้าง แทบทุกคนตอบว่า “ใช่เลย” . มันแปลว่าเราไม่เก่งรึเปล่าคะ ถ้ามีคนเป็นเหมือนเราหลายคน? จริงๆ ที่เราเริ่มไม่ได้ ไม่ใช่เพราะไม่เก่ง หรือยัง syntax ไม่ได้หรอกค่ะแต่เพราะไอ้ที่เค้าสอนๆ กัน มักจะสอนเราแค่วิธีทำค่ะเค้าบอกเราหมดแล้วว่าจะเทสอะไร เริ่มตรงไหน ต้องเช็คอะไรบ้าง แล้วก็ไม่มีใครสอนเราว่า “เพราะอะไร” ถึงต้องทำแบบนี้เราเลยเห็นแต่ปลายทางที่เสร็จแล้ว แต่ไม่รู้ว่าระหว่างทางเกิดอะไรขึ้นบ้าง . เหมือนที่ Sean D’Souza สอนวาดปลาวาฬในหนังสือ Suddenly Talented เลยค่ะ(พี่กิ่งเคยโชว์รูปปลาวาฬไปในโพสก่อนๆ ลองหาดูได้นะคะ) Sean บอกเราง่ายๆ เลยว่า ขั้นที่ 1

กว่าจะเจอว่ามันพัง ก็เทสไปจนเกือบเสร็จแล้วแล้วก็ต้องวนกลับไปแก้ใหม่อีกรอบจนได้ . แล้วมันก็เป็นแบบนี้ทุกที ไม่รู้ทำไมบั๊กมันงอกมาตอนท้ายทุกทีทั้งๆ ที่มันน่าจะเจอเร็วกว่านี้ได้นะ แล้วเราก็เริ่มคิดว่า หรือควรจะมี unit test เพิ่มตรงนี้หน่อยดีมั้ยนะแต่ก็ไม่รู้จะเดินไปคุยกับ dev ยังไง เพราะเคยเกริ่นๆ ไปแล้ว แต่ทีมบอกว่ามันทำไม่ได้ . วันนี้สอนคลาส Automation วันแรกไปค่ะแล้วก็มีคำถามเรื่อง unit test เข้ามาพอดีซึ่งจริงๆ พี่กิ่งเจอคำถามนี้ซ้ำๆ มาหลายปีเป็นหนึ่งในปัญหาสำคัญที่ต้องเข้าไปช่วยแก้ให้ในงานที่ทำในช่วงที่ผ่านมาเลยค่ะ . แต่รู้อะไรมั้ยคะ หลายๆ ครั้ง มันไม่ใช่ว่า “dev ไม่ยอมทำ” แบบที่เราคิดเสมอไปเค้าไม่ได้กำลังปฏิเสธเรานะคะ แต่เค้ายังไม่เคยเห็นภาพว่าเทสมันควรเข้าไปเช็คอะไรบ้างหรือบางทีมันก็มีปัญหาเรื่อง architecture ที่ลึกไปกว่านั้น (ที่เราจะยังไม่แตะวันนี้นะคะ) เพราะฉะนั้น การที่เราเดินดุ่มๆ ไปบอก dev ว่า ทำ unit test เพิ่มให้หน่อยมันเหมือนเราไปเพิ่มงานให้เค้า โดยที่ไม่มีไกด์ไลน์อะไรให้เลย . ลองคิดถึงพวก field validation ทั้งหลายที่เรามักจะต้องเทสกันดูค่ะ เว้นว่างกรอกค่าติดลบกรอกตัวอักษรในช่องที่เป็นตัวเลขกรอกค่าที่มากเกิน maximumกดซ้ำสองรอบ หรือ

คำถามนึงที่ QA แบบเราเจอประจำ“แล้วมันพร้อม release พรุ่งนี้มั้ย” เราก็ตอบไปว่า “น่าจะโอเคค่ะ” ทั้งๆ ที่เพิ่งทำ Test Report ส่งให้ทีมเมื่อวานใช้เวลาทำอยู่ครึ่งวัน มีตาราง กราฟ ตัวเลขอีกหลายชุดแล้วทำไมเรายังต้องเป็นคนตอบคำถามนี้อยู่ดีที่สำคัญคือ ทำไมเราถึงตอบได้แค่ “น่าจะ” . ไม่ใช่ว่าเราไม่รู้นะคะ ว่าเรามั่นใจในคุณภาพของสิ่งที่เราเทสได้แค่ไหนเทสมากับมือ เรารู้ดีกว่าใครอยู่แล้ว ตรงไหนเสี่ยง ตรงไหนปล่อยได้ แต่ทำไมสิ่งที่อยู่ใน report มันตอบคำถามนั้นไม่ได้ หรือเพราะไม่เคยมีใครบอกเราว่า report มันมีไว้ทำอะไรเราก็เลยทำตาม template ที่ได้รับต่อๆ กันมาซึ่งมันทำหน้าที่แค่บันทึกว่าเราทำอะไรไปบ้างแต่ไม่ได้ช่วยให้ทีมตัดสินใจได้ดีขึ้น . ❌ Release นี้ มี Test Case 300 ข้อ รันไปทั้งหมด 270 ข้อ เจอบั๊ก 45 ตัว ปิดไปแล้ว 43 ตัวเหลือบั๊ก medium อยู่ 2 ตัว อ่านจบแล้ว

“อย่างสีเขียว”ไม่ได้แปลว่าเทสนี้ใช้ได้เสมอไป . ใครเขียน Automation Test มาซักพักน่าจะเริ่มชอบสีเขียวขึ้นมาอย่างบอกไม่ถูกใช่มั้ยคะเวลาเห็น test รันผ่านฉลุย เขียวหมดแล้วมันรู้สึกว่า test ของเรานี่มันช่างเริ่ดจริงๆ เราเขียน test เอาไว้จับว่าระบบมันทำงานถูกมั้ยแล้วมีใครเคยเช็คมั้ยคะ ว่า test ของเราทำงานถูกจริงรึเปล่า? ส่วนใหญ่เห็นสีเขียว แล้วก็รู้สึกสบายใจ ปิดจ๊อบ จบงานแต่ไม่มีใครถามต่อว่า ถึงเวลาที่มีบั๊กขึ้นมาจริงๆ test นี้จะจับมันได้มั้ย 🟢🟢🟢 พี่กิ่งอยากมาแชร์ประสบการณ์ตรงเลยค่ะหลายปีมาแล้วตอนที่ไปสัมภาษณ์กับ Googleมีรอบนึง คุยกันเรื่อง unit test ค่ะเป็น technical interview ที่คุยกันแค่เรื่อง unit test เลย พี่กิ่งก็คุยไปโดยเข้าใจว่า unit test ที่ว่า คือ ส่วนที่เทสระบบของเรา ที่ปกติ dev เขียนนั่นแหละค่ะ ปรากฏว่าคุยกันจนจบ เค้าถึงบอกว่า ที่คุยกันทั้งหมด เค้าหมายถึง unit test ของ Automation Test

เขียน Automation Test ไป รันผ่านแบบมั่นใจ เขียวทุกเคสแต่พอขึ้น Production ปุ๊บ ลูกค้าเจอบั๊กปั๊บ ที่น่ากลัวกว่าเทสพังคือการที่เราไม่รู้ด้วยซ้ำว่าผิดตรงไหน . เรามักจะวัดว่าตัวเองเก่ง หรือ ไม่เก่ง จากตัวเลขอะไรพวกนี้ใช่มั้ยคะจำนวนบั๊กที่หลุด ยิ่งน้อย ยิ่งรู้สึกเก่ง ยิ่งเยอะ ยิ่งรู้สึกแย่จำนวน test case ที่จับบั๊กได้จริง ยิ่งเยอะ ก็ยิ่งรู้สึกเก่ง แต่พอมีบางข้อที่หลุด ลืมนึกถึง ก็รู้สึกแย่อีก แต่พี่กิ่งว่าสิ่งที่สำคัญกว่าตัวเลขคือตอนที่พลาด เรารู้ตัวแค่ไหน . ช่วงนี้พี่กิ่งอ่านหนังสือ Suddenly Talented อยู่ค่ะ เลยจะเอามาแชร์บ่อยหน่อยนะคะ ในหนังสือเล่มนี้จะมีบทนึงที่บอกเอาไว้ว่าเราสามารถแบ่งระดับความผิดพลาดออกเป็น 3 แบบค่ะ . ❌ Level 1: ผิดแล้วไม่รู้ตัวว่าผิดเขียน test case แล้วบอกแค่ว่า “กด submit แล้ว success”แต่ไม่ได้เช็คอย่างอื่นเลย เทสไปยังไงก็ผ่าน เพราะเราอาจจะนิยามคำว่า success ผิด พอมีบั๊กหลุดก็กลับมาแก้แต่เราไม่รู้ตัวด้วยซ้ำว่าจริงๆ

“เขียนโค้ดไม่เป็น จะเรียนได้มั้ยคะ”“ไม่มั่นใจว่าจะทำได้”“เรียนแล้วจะเอาไปใช้จริงได้มั้ยคะ” ทุกรอบที่เปิดคอร์ส Automation Testingจะได้รับคำถามประมาณนี้ตลอดเลยค่ะ มันคือความรู้สึกที่หลายคนมีร่วมกันค่ะ “เราพร้อมจริงรึเปล่า” . วันนี้เลยอยากชวนมาเช็คกันตรงๆ ค่ะเพราะคำว่า “พร้อม” ไม่ได้หมายความว่าเขียนโค้ดเป็นแค่อย่างเดียวจริงๆ แล้วเราไม่ต้องเขียนโค้ดเป็น ก็สามารถเริ่มเรียน Automation Test ได้ค่ะ มาลองเช็คไปด้วยกันเลยดีกว่า ว่าเราต้องการอะไรบ้าง . ✅ เจอ Requirement ที่เขียนมาไม่ชัด แล้วกล้าถามให้ชัดเจนก่อนเทส ไม่เดาเอง👉 ถ้าใครยังไม่รู้จะถามยังไง ลองถามโดยยกตัวอย่างง่ายๆ ว่า “ถ้า input เป็นแบบนี้ output ควรเป็นแบบไหน” ✅ ปล่อยบั๊กหลุดแล้วไม่ปล่อยเบลอ กลับไปดูว่าพลาดตรงไหน👉 ถ้าใครยังไม่เคยกลับไปดู ลองถามตัวเองดูค่ะว่า ทำไมมันถึงหลุดไป มี test case ไหนที่ขาดไป ✅ เข้าใจ test case แต่ละข้อชัดเจน มี objective อะไร ต้องทำ action อะไร

หยุดเดา แล้วมาเริ่ม Query กันดีกว่า ใครเป็นแบบนี้บ้างเจอบั๊กตัวนึง แล้ว reproduce ไม่ได้ หรือ เป็นบ้างไม่เป็นบ้างก็เดาไปเรื่อยไปเปื่อยว่าจะเกิดจากอะไรได้บ้างลองเปิดตรงนั้น ปิดตรงนี้ กดไปเรื่อยๆ บางทีคำตอบมันอาจจะนอนรอเราอยู่ที่ซัก table นึงใน database นั่นแหละแต่เราไม่เคยรู้ว่ากดเข้าไปดูได้ . หลายคนคิดว่าจะเริ่มไปดู database ได้ ต้องเขียน SQL เป็นก่อนเลยผัดไปเรื่อยๆ คิดว่าต้องไปเรียนให้เป็นก่อนค่อยลอง แต่จริงๆ มันเริ่มง่ายกว่านั้นมากเลยค่ะ ให้ลองคิดว่า UI คือหน้าร้าน ที่ลูกค้าเห็น สิ่งที่เราเข้าไปกดเทสทุกวันส่วน Database คือ โกดังหลังร้าน ที่เก็บของและข้อมูลต่างๆ เอาไว้ในนั้น เราไม่จำเป็นต้องรู้ทุกซอกทุกมุมก็ได้ค่ะแค่เดินเข้าไปหาของที่เราอยากได้เป็นก็พอแล้ว . ถ้าใครอยากลองเริ่มทำความรู้จักกับ database แต่ไม่รู้จะเริ่มยังไงลองเริ่มจากสเต็ปง่ายๆ ที่เราทำได้เลย แบบนี้ดูก่อนค่ะ 👉 Step 1: ใช้ Tool ช่วยไปเลย! ลองดูว่าทีมเราใช้ database ตัวไหน แล้วมี tool