Mindset

หลายๆทีมคงเป็นแบบนี้กันอยู่ใช่มั้ยคะ ไม่ว่าจะ Dashboard ที่โชว์ ranking ตามจำนวนบั๊กที่หาได้ หรือ KPI ที่วัดจากจำนวน Ticket ที่เปิด 😅กลายเป็นเราวัดผลงานของ QA กันด้วยจำนวนบั๊กที่หาเจอ แต่ลองมาคิดดูอีกทีนะคะ ถ้าทีมส่งมอบ product ออกไปโดยที่ไม่มีบั๊กเลยQA ในทีมนั้นหาบั๊กได้ 0 ตัว แปลว่าเขาทำงานได้ดีที่สุด หรือ แย่ที่สุด บั๊กน้อย อาจไม่ได้แปลว่า QA ทำงานน้อยนะคะแต่อาจจะแปลว่า QA เข้าไปช่วยทำให้งานมีคุณภาพมากขึ้น และป้องกันได้ดีตั้งแต่ต้น ลองเปรียบเทียบสองทีมนี้ดูนะคะ ทีม A 👉 QA รอของมา -> เข้าไปเทส -> เจอบั๊ก 20 ตัว👉 แล้วก็ส่งกลับไปให้ Dev แก้ 👉 แก้เสร็จเรียบร้อย -> ส่งกลับมาให้เทส -> QA เจอบั๊กอีก 5 ตัว ->

ไหน ใครเป็นมือใหม่บ้างคะ บางทีตอนที่เราเป็น QA แรกๆ เนี่ย เราไม่รู้หรอกว่าสิ่งที่เราทำไปมันดีหรือไม่ดียังไงวันนี้เลยอยากจะมาแชร์ 5 ข้อ ที่มักจะเห็นคนพลาดกันบ่อยๆ (และตัวพี่กิ่งเองก็เคยผ่านมาทุกข้อเลย 😅) ลองมาดูกันนะคะ ว่ามีตรงไหนที่เราสามารถทำให้ดีขึ้นได้บ้าง ❌ เทสทุกอย่างให้ครบก่อน✅ เทสให้ตรงจุดก่อน เทสครบก็ควรจะเป็นเรื่องดีไม่ใช่เหรอ แต่จริงๆ การที่เราจัดลำดับไม่ถูก แล้วพุ่งไปเทสเคสยิบย่อยก่อน เพราะอยากเทสให้ครบทุกอย่าง ก็อาจจะทำให้เราเจอบั๊กที่สำคัญจริงๆ ช้ากว่าที่ควรจะเป็นนะคะ ลองถามตัวเองว่า “ตรงไหนที่สำคัญสำหรับ User” แล้วเริ่มจากตรงนั้นก่อนถ้ามีบั๊ก เราจะได้แก้จุดที่สำคัญก่อนค่ะ ❌ รอ dev ส่งงานแล้วค่อยเทส ✅ คุย requirement ก่อน dev เริ่มโค้ด บั๊กที่เจอหลังจากเขียนโค้ดเสร็จแล้ว กับบั๊กที่เจอตั้งแต่ก่อนเริ่มโค้ด ราคาต่างกันมหาศาลค่ะแค่นัดคุย scenario กับ dev ก่อนจะเริ่มงานนั้นๆ ก็ช่วยให้ประหยัดเวลาได้เยอะ และคุณภาพของงานก็ดีขึ้นตามไปด้วย ❌ เขียน test case เยอะ = QA ที่ดี ✅

เชื่อว่าหลายๆทีมคงจะเคยเจอโมเมนต์ที่กด deploy ขึ้น productionแล้วทุกคนนั่งจ้องหน้าจอ ไม่กล้าลุกไปไหน เอาแต่จ้อง slack รอดูว่าจะมีอะไรระเบิดมั้ย บางทีเราก็อาจจะต้องรอ deploy ดึกๆ เพราะกลัวจะไปพังตอนลูกค้าใช้อยู่บางทีก็ต้องมีคนอยู่เวรเฝ้าหลังจากนั้นอีก อยู่ยาวกันจนตีสามตีสี่หรือบางที เราก็กังวลเวลาที่แก้บั๊กช่วงใกล้ๆ release จนต้องเร่ง retest ทุกอย่างซ้ำจนดึกดื่น เพราะไม่มั่นใจว่าที่แก้ไปจะไปทำอะไรพังบ้าง ถ้าทีมของคุณเป็นแบบนี้อยู่ อยากบอกว่า มันไม่ใช่เรื่องที่ต้องทนนะคะ และมันแก้ได้ ‼️ 🙏 ทำไม deploy ทีไรต้องสวดมนต์ตลอด ส่วนใหญ่ไม่ได้เกิดจากทีมเราเขียนโค้ดไม่ดีค่ะ และ ไม่ได้เกิดจากเทสไม่ละเอียดพอด้วยแต่มันมักจะเกิดจากการที่ทีมไม่รู้ว่า “สิ่งที่แก้ไปจะกระทบอะไรบ้าง”และไม่มั่นใจว่า “ที่เทสไปนั้นครอบคลุมพอหรือยัง” ลองดูเหตุการณ์นี้นะคะ แต่พอ deploy เท่านั้นแหละ 💥 โค้ดที่แก้ดันไปกระทบส่วนที่ตรวจสอบ promo code ได้ยังไงก็ไม่รู้ กลายเป็นลูกค้าใช้ส่วนลดไม่ได้ และเราก็ไม่รู้เรื่องนี้จนลูกค้าไปเจอนั่นแหละ เพราะไม่มีใครคิดถึง scenario นี้ตั้งแต่แรก นี่คือตัวอย่างคลาสสิคของการที่ทีม “เทสผ่าน” แต่ก็ไม่ทำให้มั่นใจอยู่ดีค่ะ เพราะเทสที่ทำไปไม่ได้ครอบคลุม scenario ที่อาจจะกระทบทั้งหมด 🤔 แล้ว QA จะมาช่วยตรงนี้ได้ยังไง??? เรามาลองดูว่า

“It’s not a bug, It’s a feature”“ไม่ใช่บั๊กนะ มันเป็นฟีเจ้อ” คลาสสิค!! เป็นประโยคที่ QA ทุกคนเคยได้ยินกันมาแน่ๆ ใช่มั้ยคะ 😅 บางทีเราแน่ใจสุดๆ ว่ามันพังแน่ๆ กด reproduce ซ้ำได้ทุกรอบแต่พอ report ไปปุ๊บ โดนสวนกลับทันที “อันนี้ตั้งใจทำแบบนี้แหละ” แล้วเราจะทำยังไงต่อดีล่ะ!?. ก่อนอื่นเลย อยากให้ทุกคนเข้าใจก่อนนะคะ ว่าเราไม่ได้จะมาหาว่าใครผิดใครถูก ไม่ได้จะบอกว่าใครดีกว่าใครเพราะ “Bug” หรือ “Not a Bug” มันมี grey area อยู่เยอะมาก ลองนึกตามดูค่ะ ใครเคยเจอสถานการณ์เหล่านี้บ้าง ❌ Requirement ไม่ได้เขียนไว้ชัดเจนระบบทำงานตรงตาม spec แต่ user งงมาก แบบนี้เป็นบั๊กมั้ย? ❌ Dev กับ QA ตีความ Requirement ต่างกันบางทีอาจจะมี edge

มีใครคิดว่าซอฟท์แวร์ที่ดีต้อง “Zero Defect” บ้างคะ ระบบที่ดีที่จะเอาขึ้นได้ต้องเพอร์เฟค 100% ถ้าเจอบั๊กแม้แต่นิดเดียว ก็ต้องรีบขวางไว้ทันที ผลคืออะไรรู้มั้ยคะ กลายเป็นเราทำงานเครียด รู้สึกต้องสู้ ต้องไฟท์ตลอดเวลา อยากให้ทุกอย่างออกมาสมบูรณ์แบบที่สุด แต่พอเราเติบโตขึ้น ก็ทำให้รู้ค่ะว่า เราไม่ควรหมกมุ่นกับความสมบูรณ์แบบที่จับต้องไม่ได้ แต่เราจะต้องทำงานแบบมีกลยุทธ์ คิดถึงRisk และ Cost ที่จะเกิดขึ้นเสมอ ลองมาดูสถานการณ์ตัวอย่างกันค่ะ ว่าแบบไหนเราปล่อยได้ แบบไหนปล่อยไม่ได้ แล้วเราจะจัดการกับมันยังไง 🚨 เมื่อ Business Deadline สำคัญกว่า Minor Bug ลองคิดดูว่าถ้าพรุ่งนี้บริษัทจะต้องปล่อยแคมเปญใหญ่ (เช่น 11.11) ที่ใช้งบการตลาดมหาศาล ฟีเจอร์ที่กำลังจะออกมีมูลค่าสูงมากต่อยอดขาย แต่ดันมาเจอบั๊กในนาทีสุดท้าย แล้วเราจะทำยังไงกับบั๊กพวกนั้นดี ถ้าแก้ก็อาจจะต้องมาเร่งเทสฟีเจอร์นั้นใหม่อีกรอบ แล้วอาจจะทำให้ปล่อยฟีเจอร์นี้ไม่ทัน ขั้นแรกเราต้องประเมินก่อนค่ะว่าบั๊กนี้ “ร้ายแรง” แค่ไหน โดยอาจจะคุยกับฝั่ง Business หรือ PO เพื่อตกลงร่วมกันด้วยก็ได้ ถ้าบั๊กที่เจอเป็น Minor Bug เช่น “ปุ่มแชร์ลง Social

ตลาดหาแต่ Automation… แล้ว Manual แบบเราล่ะเอาไงดี ใครเป็น Manual QA บ้าง เปิดเว็บหางานทีไร เจอแต่คำว่า “Must have Cypress/Playwright experience”, “Experience in Selenium or Automated Testing Frameworks”… อ่านแล้วก็อดใจสั่นไม่ได้ใช่มั้ยคะ เชื่อว่าหลายคนคงจะเกิดอาการ Imposter Syndrome กำเริบจนแทบจะหมดสิ้นแพชชั่น และแอบตั้งคำถามกับตัวเองว่า “แล้วถ้าเรายังเขียนสคริปต์ไม่คล่อง เราจะรอดมั้ย” แต่ความจริงที่หลายๆคนมักไม่ได้พูดถึงคือ “ก่อนที่เราจะเขียน Automation ได้ระดับเซียน เราก็ต้องมี เซนส์ของการเป็น QA ที่ดี ให้ได้ก่อนค่ะ” เครื่องมือ Automation มันฉลาด และทำงานไวก็จริง แต่มันไม่สามารถแยกให้เราได้ค่ะว่า Test Case ที่สำคัญ หรือ Test Case ที่มีคุณค่าต่อ Business นั้นอยู่ตรงไหนบ้าง มันแค่รันตามสิ่งที่เราเขียนสคริปต์สั่งไว้ ถ้าเรากระโดดไปเขียน

เจอ Bug ทีไร สงครามบังเกิดทุกที!ทีมไหนเป็นแบบนี้ยกมือค่ะ เดี๋ยวเรามาดูกันว่าจะทำยังไงได้บ้าง เรื่องนี้เป็นอีกเรื่องที่พี่กิ่งพูดกับทีมบ่อยมากๆนะคะในฐานะ QA หนึ่งในหน้าที่ของเราคือการหาข้อผิดพลาดให้เจอ การเดินไปบอกทื่อๆ ว่า “โค้ดเธอพังนะ” ถ้าสื่อสารไม่ดี จากที่จะช่วยกันแก้ Bug อาจจะกลายเป็นสร้างกำแพงใส่กันแทนก็เป็นได้ จริงๆ แล้ว หนึ่งในทักษะที่สำคัญไม่แพ้การเขียน Test Script ก็คือ Soft Skill นี่แหละค่ะและเป็นอีกหนึ่งเรื่องที่สามารถแยกได้เลยนะคะ ว่า QA คนนี้ร่างทอง ตัวเทพ จริงมั้ย ถ้าใครยังไม่รู้จะเริ่มยังไง วันนี้มาลองดูวิธีการแจ้ง Bug ให้ทีมฟังแล้วไม่เกิดสงครามกันค่ะและวิธีนี้ยังช่วยทำให้ความสัมพันธ์ในทีมดีขึ้น คุยกันง่ายขึ้น งานก็เดินมากขึ้นตามไปด้วย Bug ในระบบแก้ได้ด้วยโค้ด แต่ถ้าเกิด Bug ที่การสื่อสารระหว่างทีม ก็ต้องแก้ด้วยการสื่อสารและการทำความเข้าใจนะคะลองทำไปเรื่อยๆ เดี๋ยวก็จะติดเป็นนิสัยไปเอง ใครมีเทคนิคลับอื่นๆ เวลาคุยเรื่อง Bug หรือคุยปัญหากับทีม Dev สามารถแชร์กันได้นะคะ หรือส่งต่อให้เพื่อนในทีมมาร่วมวงกันได้เลยค่ะ

เคยมั้ยคะ รอ Dev ทำฟีเจอร์ให้เสร็จพร้อมเทสมาเป็นอาทิตย์ พอได้มาเทสจริงๆ ปุ๊บ… แค่กดปุ่มแรกไป หน้าจอก็หมุนไม่หยุด หรือ Error แดงเถือก! แล้วเราก็จะรู้สึกว่า “ให้ฉันรอแล้วได้อะไร” ในเมื่อของก็ยังพังอยู่แบบนี้แล้วชั้นจะเทสยังไงไหวพอไปบอก Dev ก็อาจจะได้คำตอบว่า เดี๋ยวต้องไปแก้ Logic หลังบ้านก่อน แล้วต้องแก้ UI ให้รับค่าใหม่ด้วย สรุป… ต้องรอต่อไปอีก 2 วันเพื่อให้ระบบพร้อมเทส (อีกรอบ) นี่แหละค่ะคือความเจ็บปวดของการทำ UI-Heavy Testing หรือที่บางคนอาจจะเคยเห็นชื่อ “Ice Cream Cone Testing” 🍦 คือการทำเทสผ่านหน้าจอ (Layer บน) เยอะๆ แต่ฐานข้างล่างอย่าง API หรือ Unit Test กลับกลวงโบ๋ กลายเป็นสามเหลี่ยมกลับหัวที่ฐานไม่แน่น พร้อมล้มตลอดเวลา วันนี้พี่กิ่งจะมาแชร์ให้เห็นภาพชัดๆ ค่ะว่าการมี API First Mindset จะช่วยให้เราเป็น “QA ร่างทอง” ที่เจอบั๊กไวกว่า

เปิดโพย 3 คำถามกันตายตอน Refinement เคยมั้ย ที่เรานั่งอยู่ในประชุม Refinement (หรือ Grooming) เพื่อพูดคุยเกี่ยวกับ Requirement กัน Dev ก็คุยกันเรื่อง Logic วุ่นวาย PO ก็อธิบาย Flow งานมารัวๆ ส่วนเราที่เป็น QA ก็ได้แต่นั่งฟัง แล้วก็จด Requirement ตามเงียบๆ “เดี๋ยว Dev โค้ดเสร็จส่งของมาให้แล้วค่อยเอามาเทสแล้วกัน” ตัดภาพมาที่อีก 1 อาทิตย์… Dev ส่งของมาให้และเราก็กำลังจะเริ่มเทส “อ้าว ถ้า User กดปุ่ม Back ตอนจะจ่ายเงินล่ะ” “แล้วถ้ากรอกตัวเลขติดลบตรงนี้ จะพังมั้ย” “ทำไมตรงนี้ไม่ได้ทำ ไม่มี Requirement บอกไว้เหรอ” แล้วยังไงต่อล่ะทีนี้… สุดท้ายเราก็จะเดินไปบอกทีมว่า “ยัง Deploy ไม่ได้นะคะ ยังมีบั๊กที่ต้องแก้เต็มเลย” 🛑แต่มาลองคิดดู จริงๆเราสามารถช่วยทีมได้ตั้งแต่ก่อนจะเริ่มเขียนโค้ดอีกนะ! ถ้าเราอยากจะเป็น