Mindset

ได้โจทย์มาว่า “ต้องทำ Automation เป็นนะ”แต่ยังไม่รู้เลยว่าต้องเริ่มจากตรงไหน . ประโยคข้างบนพี่กิ่งไม่ได้คิดขึ้นมาเองนะคะแต่เป็นฟีดแบ็คที่ได้มาจากคลาสเรียน Automation รุ่นล่าสุดที่เพิ่งจบไปจากคำถามที่ถามว่า “ก่อนเรียนกังวลเรื่องอะไรมากที่สุด” . แล้วพอมาไล่ดู คำตอบของคนอื่นๆ ก็คล้ายๆ กันหมดเลยค่ะ 💬 “กลัวว่าจะยากเกินไป”💬 “เรื่องการทำ automation ยังเริ่มไม่ถูก”💬 “มีความกังวลเพราะไม่เคยใช้”💬 “กังวลว่าเรียนแล้วจะเอาไปใช้ได้จริงไหม” . ที่น่าสนใจคือ ไม่มีใครกังวลเรื่องจำ syntax ไม่ได้หรืออะไรแบบนี้เลยแต่ส่วนใหญ่จะติดอยู่ที่เดียวกัน คือ “ไม่รู้จะเริ่มยังไง” . สิ่งที่พี่กิ่งเห็นซ้ำๆ มาตลอด คือ คนส่วนใหญ่เริ่มเรียน Automation จาก tutorialตอนทำตามก็ทำได้หมด แต่พอไปทำจริงกลับไม่รู้ว่าจะเริ่มยังไง เพราะส่วนใหญ่ tutorial มักจะสอนว่าทำยังไง บอกคำสั่งให้ทำตามแต่ไม่ค่อยได้เล่าที่มาที่ไป ว่าสิ่งที่กำลังทำอยู่นั้น ทำไปเพื่ออะไรพอเราไม่เข้าใจ เราก็ได้แต่จำคำสั่งไป แล้วพอไปเจองานจริงที่หน้าตาไม่เหมือนในตัวอย่างก็เลยไม่รู้ว่าจะเอาไปใช้ยังไง แล้วก็ทำให้รู้สึกว่าการทำ Automation Test มันยากกว่าที่เป็นจริงๆ . 💡 อย่างเช่นเรื่อง POM (Page Object

หลายคนคิดว่าทำ Automation แล้ว งาน QA จะน้อยลงแต่ทีมที่ทำ Automation จนอยู่ตัวแล้ว งานไม่ได้น้อยลงเลยค่ะมันแค่ย้ายไปอยู่อีกที่นึง . อะไรบ้างที่มันหายไป? ทีมที่ mature แล้ว จะมี automation test รวมทั้ง unit test ที่รันเป็นประจำอยู่แล้วทำให้บั๊กง่ายๆ ถูกกรองออกไปตั้งแต่ก่อนจะมาถึงมือ QAอย่างเช่น ปุ่มกดไม่ได้ กรอกค่าไม่ตรง formatหน้าเดิมที่เคยทำงานได้ปกติ แต่พังเพราะมีตัวอื่นมากระทบ ของต่างๆ เหล่านี้ มันโดน automation test ดักไว้ให้หมดแล้ว . เราเลยได้เวลาที่เคยใช้เช็คเรื่องเล็กๆ พวกนี้คืนมาแล้วเวลาพวกนั้นก็ถูกย้ายไปอยู่กับงานที่ automation ทำแทนไม่ได้ . 💡 จากที่พี่กิ่งเคยเห็น เวลาที่ได้กลับมา มันมักไปอยู่กับอะไรพวกนี้ . ✅ เอาไปใช้ทำความเข้าใจ requirement ได้มากขึ้นตั้งแต่แรกจากเดิมที่กว่าจะได้เริ่มดู ก็ตอนที่ของมาถึงมือ กำลังจะเริ่มเทสแล้วแต่ตอนนี้มีเวลานั่งคุยตั้งแต่ยังไม่มีใครเริ่มเขียนโค้ด . ✅ เตรียม scenario ไว้ทำ

Ticket ใบเดิม ส่งกลับไปกลับมาระหว่าง QA กับ dev มาสามรอบแล้วรอบที่สามก็ยังไม่ผ่าน แล้วก็โดนถามว่าจะปิดได้วันไหน . รอบที่ 1: ส่งมาแล้วเจอบั๊กหนึ่งตัว เลยส่งกลับไปรอบที่ 2: แก้ของรอบที่ 1 มาแล้ว แต่ไปเจอที่อื่นพังเพิ่มอีกรอบที่ 3: แก้ตรงนั้น ไปพังตรงอื่นอีก แล้วเราก็เลยตั้งใจเขียนให้ละเอียดขึ้นอีกส่งไปทีเดียวสิบกว่าปัญหา จะได้ไม่ตกหล่นอีก . แล้วส่วนใหญ่ มันก็มีรอบที่สี่มาอีกอยู่ดี . บางคนเรียกอะไรแบบนี้ว่าปิงปองค่ะเหมือนตีโต้กันไปมา ไม่จบไม่สิ้นซักที ซึ่งอาการนี้มันเกิดได้จากหลายสาเหตุแล้วที่พี่กิ่งเจอบ่อยๆเนี่ยมันไม่ใช่เพราะ dev ไม่ตั้งใจ หรือ QA เทสไม่ดีพอ แต่เป็นเพราะ ticket มันใหญ่เกินไปค่ะ . ticket ใบเดียว ข้างในมี requirement ย่อยๆ อีกเป็นสิบข้อมีหลายอย่างที่ต้องทำ หลายอย่างที่ต้องเทสมีหลายจุดที่เชื่อมต่อกันใหญ่จนไม่มีใครเห็นภาพได้ครบทั้งหมด . บางบั๊กที่เกิดขึ้น ก็เกิดจาก requirement บรรทัดนึงในนั้นที่มีคนเข้าใจไม่ตรงกันที่แก้ตรงนั้น แล้วไปพังตรงนี้ หลายครั้งก็เกิดจากบรรทัดนึงที่มีคนอ่านข้ามไป เราก็ต้องไล่แก้ไปทีละชิ้น เหมือนไล่จับบั๊กไปทีละตัว

เป็น Manual QA ที่อยากจะไปต่อทาง Automationแต่ทีมที่ทำอยู่ก็มีแต่งาน Manual แล้วเราจะทำยังไงดี??? . เวลาพี่กิ่งสัมภาษณ์คนเข้าทีม แล้วถาม candidate ว่าอยากไปทางไหนต่อหลายๆ คนที่ทำ manual อยู่ มักจะตอบว่า อยากไปทาง automation แต่พอถามต่อว่า แล้วเคยลองทำอะไรมาบ้างมั้ยส่วนใหญ่จะได้คำตอบว่ายังไม่เคยเพราะงานที่ทำอยู่มีแต่ manual บ้างทีมไม่มีเวลาให้บ้างหรือบางที่ก็มีทีม automation แยกออกไปต่างหากอยู่แล้ว . เหตุผลพวกนี้ก็จริงทั้งหมดเลยนะคะ พี่กิ่งเชื่อว่าทุกคนพูดจริง ไม่ใช่ข้ออ้างหลายๆ ที่ก็เป็นแบบนี้จริงๆ งานเข้ามาเพิ่มตลอด แค่เทสให้ทันก็เหนื่อยจะแย่แล้วถ้าทีมไม่ได้วางแผนเรื่อง automation ไว้ให้ แทบจะไม่มีทางให้เราไปทำได้เลยค่ะ . จริงๆ แล้วเวลาพี่กิ่งหาคนเนี่ยส่วนใหญ่ก็ไม่ได้เจาะจงว่าต้องเป็นคนที่เคยทำมาเท่านั้นหรอกค่ะสิ่งที่ดูมากกว่าคือคนที่มี QA mindset ที่ดี และ มีแววที่จะ build automation skill ต่อได้ . ปัญหาคือ คำว่า “อยากทำ” มันไม่ได้ช่วยตอบคำถามทั้งสองข้อเลยค่ะเพราะทุกคนก็ตอบว่าอยากทำ automation กันทั้งนั้นพอเราไม่ได้เคยลองทำมาบ้าง มันเลยทำให้คำตอบของเราไม่ต่างกับคนอื่นซักเท่าไหร่ .

ทีมที่ดีที่สุดที่พี่กิ่งเคยอยู่คือทีมที่ QA แทบไม่ได้เปิด bug ticket เลย . ไม่ใช่เพราะไม่มีบั๊กนะคะ ก็เจอบั๊กเหมือนปกตินั่นแหละแต่เจอปุ๊บ ทัก dev ปั๊บ แล้วก็แก้กันตรงนั้นเลยคุยกันจบใน Slack ไม่ได้เปิด ticket แล้วไปต่อคิวรอ dev แก้ . เพราะทีมนั้นทำ shift left กันสำเร็จจริงๆ ค่ะdev กับ QA ทำงานเป็นทีมเดียวกันไม่ใช่ “dev ทำเสร็จแล้ว ส่งให้ QA ไปเทสต่อ” . พอกลับไปลองแกะดูว่าตอนนั้นเกิดอะไรขึ้นคิดว่ามี 3 อย่างที่ทำให้มันเป็นไปได้ . [1] เจอเร็ว ตั้งแต่ของยังอยู่ใน branch เพราะ QA เทสบน feature branch ได้เลยมี env ให้เลือก deploy branch ที่อยากเทสได้เองไม่ต้องรอ merge เข้าของกลางก่อนของใน

เครื่องเดฟผ่าน เครื่องเราพังแล้วใครถูกกันแน่? . เคยเป็นมั้ยคะเจอบั๊ก ก็เปิด ticket เขียนอธิบายไปอย่างดีส่งไปให้เดฟได้แป๊บนึงได้ ticket คืนมา พร้อมคอมเม้นว่า “It works on my machine” . เราก็เอากลับมาลองอีกรอบ ก็ยังเป็นอยู่ดีแล้วความรู้สึกแรกในใจของเราเป็นยังไงคะ“มันก็เห็นกันชัดๆ อยู่เนี่ย ทำไมไม่เจอนะ” . ก็เลยแปะ log แปะ screenshot เพิ่มลงไปแล้วก็ส่งกลับไปอีกรอบแป๊บเดียวก็เด้งกลับมาอีกในใจก็คิดว่า อีกฝั่งไม่ได้ตั้งใจดูรึเปล่าทำไมส่งกลับไปกลับมาแบบนี้ แล้วผ่านไปซักพัก ก็เริ่มเกิดสงครามย่อมๆ ขึ้นมา . แต่รู้มั้ยคะว่า ที่พี่กิ่งเห็นซ้ำๆ ในเคสแบบนี้คือทั้งสองฝั่งตั้งใจดูจริง และไม่มีใครผิดเลยค่ะ . เพราะต่างคนต่างก็พูดจริงทั้งคู่เดฟเอาไปลอง ก็ไม่พังจริงๆQA ลองบนเครื่องตัวเอง ก็พังจริงๆ จริงๆ นี่เป็นสัญญาณบอกเราแล้วนะคะว่าบั๊กมันซ่อนอยู่ที่ “ความต่าง” ตรงไหนซักที่ . ที่เจอบ่อยๆ เลยเนี่ยก็เรื่อง Test Dataบั๊กบางตัว มันโผล่มาแค่กับ data บางแบบเช่น account เก่าที่สร้างไว้ก่อนฟีเจอร์ใหม่จะออกแล้ว QA

เป็น QA มาได้ 2-3 ปีแล้ว งานก็ทำได้ เขียนเทสเคสครบ หาบั๊กเจอแต่ก็ยังไม่แน่ใจอยู่ดีว่าที่ทำอยู่ถูกจริงมั้ย . ช่วงที่ผ่านมามีหลายคนเข้ามาถามคล้ายๆ กันค่ะงานก็ทำได้นะ รับ requirement มา เขียน test caseรันเทส หาบั๊ก เขียน report ทำได้หมด แต่ลึกๆ ก็รู้สึกไม่แน่ใจว่าที่ทำอยู่ถูกจริงมั้ย ทำให้ไม่ค่อยมั่นใจตามไปด้วย . ถ้าลองนึกดูดีๆ ในงานจริงมันมักจะเป็นแบบนี้ทีมมี test case ที่ส่งต่อๆ กันมา มี template ไว้อยู่แล้วTest report ก็มีไว้อยู่แล้ว หรือบางคนก็อาจจะไม่ต้องเขียนเทสเสร็จ ส่งไป release ของออกไปปกติดี แล้วก็ไม่มีอะไรเกิดขึ้น แล้วก็ผ่านไปแบบนั้นแบบไม่มีใครบอกว่าตรงนี้ดี ตรงนี้ควรปรับพอเป็นแบบนี้นานๆ เราก็เริ่มสงสัยตัวเองว่า จริงๆ แล้วเราเก่งพอมั้ย . สิ่งที่พี่กิ่งเห็นคือ ความไม่แน่ใจแบบนี้ มันไม่ได้มาจากความเก่งของเราเลยค่ะแต่เพราะ ทำได้ กับ รู้ว่าแบบนี้ถูก มันเป็นคนละเรื่องกันทำได้ เพราะเรามี

บั๊กหลุดขึ้น production ทีไรคำถามแรกมาทุกที “QA เทสรึยัง?” . พี่กิ่งเจอคำถามนี้มาบ่อยเลยค่ะเจอบั๊กหลุด คำถามมันมักจะลอยมาใส่ QA ก่อนเป็นอย่างแรก “เทสรึยัง”“ได้เทสเคสนี้มั้ย”“ทำไมถึงหลุด” แล้ว QA ส่วนใหญ่ก็มักจะมี reaction กันอยู่ไม่กี่อย่าง ก้มหน้ารับกรรมไปหรือไม่ก็ รีบอธิบายว่า เทสแล้วนะ แต่ทำไมไม่เจอก็ไม่รู้ ไม่ว่าจะเลือกแบบไหน บั๊กก็ยังหลุดขึ้นไป production อยู่ดี . เวลามีน้องในทีมมานอยใส่เวลาทำบั๊กหลุดขึ้นไป (หรือ มาร้องไห้ใส่ก็เคยมีค่ะ 555) พี่กิ่งจะบอกเสมอว่า การเป็น QA ยังไงก็ต้องมีเรื่องนี้เกิดขึ้นให้เราทำใจเอาไว้เลย ว่ายังไงก็ต้องเจอ และการที่บั๊กมันหลุดขึ้นไปได้เนี่ยมันมักจะเกิดจาก ความผิดพลาดเล็กๆ น้อยๆ ที่บังเอิญเกิดพร้อมกันพอดีค่ะ จริงๆ แล้ว กว่าบั๊กตัวนึงจะหลุดไปถึงมือลูกค้าได้เนี่ยมันต้องผ่านหลายด่านมากเลยค่ะ Requirement → Design → Code → Code Review → Unit Test → QA →

มีน้องคนนึงตอบว่า “ไม่รู้” ในห้องสัมภาษณ์แต่สุดท้ายได้ offer . คนส่วนใหญ่มักจะทำตรงข้าม พอไม่รู้ก็ไปต่อไม่ถูกเงียบไปแค่สามวิ แต่ยาวนานเหมือนสามชั่วโมงสุดท้ายก็เลยเลือกเดาอะไรซักอย่างออกไป เพื่อไม่ให้มันเงียบ . ในฐานะที่พี่กิ่งนั่งฝั่งคนสัมภาษณ์มาหลายรอบอยากจะบอกตรงๆ เลยว่า ส่วนใหญ่ดูออกค่ะว่าคำตอบไหนเดา หรืออันไหนจำมาแบบไม่เคยทำจริงเคยมีครั้งนึง ถึงกับต้องบอก candidate เลยว่า“ขอคำตอบจริงๆ แบบที่ไม่ได้จำมาได้มั้ย” . แล้วอีกอย่างที่หลายคนไม่รู้คือ พอดูออกว่าเดาไปแล้วข้อนึงคนสัมภาษณ์ก็จะเริ่มกลับไปสงสัยอย่างอื่นด้วยว่า ตกลงอันไหนรู้จริงบ้าง . น้องคนที่พูดถึง เป็นน้องในทีมเก่า ที่เพิ่งมาปรึกษาพี่กิ่งเมื่อไม่นานนี้ค่ะสัมภาษณ์ไม่ผ่านซักที จนหมดความมั่นใจในตัวเอง คุยกันไปซักพัก เลยแนะนำไปว่า “ถ้าไม่รู้ ก็บอกไปเลยว่าไม่รู้”ตอนนั้นเค้าก็ยังกังวลว่า แบบนั้นจะดูไม่ดีรึเปล่า ทำให้เราดูไม่เก่ง แต่พอลองเอาไปปรับจริง ก็ผ่านเข้ารอบลึกๆ หลายที่สุดท้ายต้องมานั่งเลือกว่าจะรับ offer ที่ไหนดี . 💬 ส่วนใหญ่คนสัมภาษณ์ไม่ได้หาคนที่รู้ทุกอย่างหรอกค่ะเขาหาคนที่รู้ว่าตัวเองรู้อะไร และไม่รู้อะไร บางทีพี่กิ่งก็ถามไปเพราะอยากเห็นว่าจะตอบยังไง สื่อสารได้มั้ย จัดการกับปัญหายังไงมากกว่าที่จะหาว่าจำคำตอบเรื่องนี้ได้มั้ย . เพราะเรื่องพวกนี้มันเป็นสิ่งสำคัญสำหรับ QA เลยค่ะ QA ที่บอกว่า “ตรงนี้มีความเสี่ยงนะ เพราะยังไม่ได้เทส” จะช่วยให้ทีมตัดสินใจได้ง่ายขึ้นQA ที่บอกว่า

บ่ายวันอังคาร ใน slack ของทีม “ตกลง requirement นี้เอาแบบ B ใช่มั้ย ตามที่คุยกันอาทิตย์ที่แล้ว”“เดี๋ยวนะ เราไม่ได้คุยกันไว้แบบนี้นี่”“เห้ย แบบนี้แหละ จำได้ ที่คุยกันไว้” แล้วสรุปว่าใครผิดก็ไม่รู้ค่ะต่างคนก็จำได้คนละแบบ ไม่มีใครโกหกเลย แต่ปัญหาอาจจะแค่เพราะ ไม่มีใครจดเอาไว้และสมองของเราก็ไม่ได้ถูกออกแบบมาให้ลืมเก่งซะด้วย . พี่กิ่งไปเจอคอนเซปต์เรื่อง second brain มาค่ะ วันนี้จะยังไม่ลงรายละเอียดเรื่องนี้กันแต่มีอย่างนึงที่น่าสนใจคือ เค้าบอกว่าสมองเราไม่ใช่ hard drive ที่จะเซฟทุกอย่างเอาไว้ได้และมันทำงานคล้าย RAM มากกว่า เก็บได้ชั่วคราว และจะถูกเคลียร์ทิ้งเวลามีข้อมูลใหม่เข้ามาแทนที่ . บางทีเราเคลียร์ requirement กันปากเปล่า ใน standup หรือ planningหรืออาจจะคุยผ่านแชทกันระหว่างที่กำลังเขียนเทสเคสอยู่ แล้วก็ไม่มีใครจดเอาไว้ว่าเราได้ข้อสรุปอะไรมาสุดท้ายมันก็หลุดออกจากหัวเราไป ไม่ใช่เพราะเราไม่ตั้งใจฟังซักนิดแต่เพราะสมองคนไม่ได้ถูกออกแบบมาให้จำค่ะ มันถูกออกแบบมาให้ลืม(แต่เรื่องบางคนทำไมมันลืมยากจังก็ไม่รู้นะคะ) . ลองคิดภาพตามดูค่ะ 👉 ใน Sprint planning คุยกันไว้ว่า edge case นี้ ข้ามไปก่อน รอบนี้ยังไม่ต้องทำก็ได้