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