บันทึกประสบการณ์ QA Meet up 2024 ณ LSEG
สวัสดี สวัสดี สวัสดี :)
กลับมาพบกันอีกครั้งกับบทความสรุปงาน QA Meetup ที่เราได้มีโอกาสไปมา โดยงานในครั้งนี้เกิดขึ้นด้วยการจับมือกันของสมาคมโปรแกรมเมอร์ไทย × LSEG x Doppio Tech ณ ตึกอื้อ จือ เหลียง เมื่อวันที่ 28 พ.ค 2024 ที่ผ่านมา
ที่ต้องขอออกตัวก่อนว่านี่เป็นครั้งที่ 3 ที่ได้มีโอกาสมางาน QA Meetup ซึ่งตอนนี้เราพอมีประสบการณ์ในสายงานนี้ในระดับลูกเจี๊ยบที่พอจะเดินเป็นบ้างแล้ว ( ถึงจะเดินแบบเตาะแตะก็ตาม 🤣 ) ทำให้เราเห็นภาพ เข้าใจ และอินกับเรื่องราวต่าง ๆ ได้ดีขึ้นมาก ๆ เลยนับจากการไปงาน Meetup ครั้งแรก
ทำให้เรามีหัวข้อที่เราสนใจ จนอาจทำให้การสรุปตกหล่นไปในส่วนที่เราไม่ได้โฟกัสบ้าง ซึ่งเพื่อน ๆ สามารถไปดูไลฟ์ย้อนหลังได้ที่นี้โดย Agenda ก็มีตามนี้เลย
เมื่อฉันโดนบังคับให้ทำ Accessibility
ยอมรับตรงนี้เลยว่าเราไม่เคยรู้จักคำว่า session นี้จึงเปิดโลกเรามากทีเดียว โดย Accessibility คือการแนวทางการออกแบบให้ ‘ทุกคน’ สามารถเข้าถึงผลิตภัณฑ์ และบริการของเราได้ รวมถึงผู้มีความบกพร่องทางสายตา การได้ยิน การเคลื่อนไหว หรือการสื่อสาร
พี่แบงก์ และพี่ทอมจาก LSEG ได้ออกมาแชร์ว่า WSO ( The World Stroke Organization : องค์การอัมพาตโลก ) ได้เผยข้อมูลว่าผู้บกพร่องมีจำนวนมากถึง 16% หรือ 1 ใน 6 ของประชากรทั่วโลกทีเดียว
ดังนั้นทาง LSEG จึงมีเป้าหมายที่อยากจะพัฒนาด้าน Accessibility ให้สำเร็จภายใน 2 ปี แต่ก็ไม่ใช่เรื่องง่ายเนื่องจากองค์ประกอบหลาย ๆ อย่างที่จะทำให้สำเร็จนั้นมีข้อจำกัดอยู่มาก
โดยเราจะขอแบ่งตามความเข้าใจ ดังนี้
1. เรื่อง Requirement
พี่ ๆ ทาง LSEG ยังไม่สามารถหา User ที่บกพร่องทางด้านต่าง ๆ เพื่อพูดคุย ทำความเข้าใจ และสกัดออกมาเป็น Requirement ที่ชัดเจนได้จริง ๆ จึงต้องแก้ปัญหาด้วยการสมมติบทบาทตัวเองว่าเป็นผู้บกพร่องแทน
2. เรื่อง Technical
ส่วนใหญ่การทำ Accessibility จะเป็นการทำตามหลัง หรือแก้ไขเพิ่มเข้าไป หากเป็นการแก้ที่ไม่กระทบกับโค้ดหลักก็ดีไป เช่น เมื่อคลิก Input จะต้องมีเสียงอ่านออกมาเพื่อผู้พิการทางสายตา แต่เพื่อตอบโจทย์กับผู้บกพร่องทางการรับรู้อาจนะต้องรื้อ Layout หน้าใหม่หมดทั้งหน้าเลยก็เป็นได้
3. เรื่อง Testing
ในการเทสเกี่ยวกับ Accessibility ส่วนมากแทบจะใช้ Automate Test ไม่ได้ เนื่องจากยังไม่มี Tool ที่ตอบโจทย์ได้มากพอ เช่น การคลิก Input และมีเสียง เราก็ยังจำเป็นต้องใช้คนมาฟังเพื่อเช็คว่าระบบสามารถออกเสียงมาได้ถูกต้องตามที่เราต้องการจริง ๆ
และพี่ ๆ ก็ได้มีการแชร์ Tool ที่ได้ใช้ในการพัฒนา ไม่ว่าจะเป็น Chrome Lighthouse , Axe , Apple VoiceOver และ NVDA screen reader
ก่อนจบ Session พี่ ๆ ปิดท้ายด้วย Quote จากซีรี่ย์ Sex Education Season 4 ไว้อย่างน่าสนใจและชวนฉุกคิดว่า
“I wish people understand that our problems come from barriers in society, not from our disabilities”
“ฉันหวังว่าผู้คนจะเข้าใจว่าปัญหานั้นเกิดจากกำแพงทางสังคม ไม่ใช่จากความบกพร่องของเรา”
ขยายความได้ว่าผู้บกพร่องไม่ได้เลือกได้ว่าตนอยากเป็นผู้บกพร่อง และผู้บกพร่องก็เป็นส่วนหนึ่งของสังคม ดังนั้นการทำให้ ‘ทุกคน’ ในสังคมได้รับผลิตภัณฑ์ หรือบริการเดียวกัน ก็เป็นส่วนที่สังคมจะต้องคำนึงถึงด้วย
Testing Transformation — จาก 3 สัปดาห์เหลือ 10 นาทีทำยังไง
“เขียน Automate มันไม่ยาก .. แต่เขียน Automate ที่มันสามารถนำไปใช้ได้จริง นั้นแหละยาก”
Session นี้พี่ณัฐจาก Doppio ได้มาแชร์ประสบการณ์การเปลี่ยนผ่านจาก Manual Testing ในการทำ Regression Test ที่ต้องใช้เวลา 3 อาทิตย์ ไปสู่การทำ Automate Testing ที่ใช้เวลาเพียง 10 นาทีในการปล่อยของขึ้นในแต่ละรอบ !!
โดยเราขอสรุปออกมาเป็นหมวก 3 ใบที่ QA ทุกคนจะต้องรู้จักใส่ และสลับสับเปลี่ยนให้เป็น ดังนี้
หมวกใบที่ 1 : หมวกของ Business
เรากำลังทำงานเป็นผู้ควบคุมคุณภาพ Software ให้กับธุรกิจใดธุรกิจหนึ่งเสมอ ดังนั้นเราจึงต้องมีมุมมองของทางฝั่ง Business แม้อาจจะขัดกับหลักการทำงานของเราบ้างก็ตามที
เป้าหมายของ Business คือการทำกำไรให้มากที่สุด คำถาม หากมีฟีเจอร์หนึ่งที่ถ้าปล่อยไปจะสามารถทำงานให้กับธุรกิจได้วันละ 300,000 บาท แม้ฟีเจอร์นั้นจะยังมี Bug อยู่เราควรปล่อยไปหรือไม่ ?
เชื่อว่าเพื่อน ๆ รู้คำตอบในใจอยู่แล้ว คีย์หลักของหมวกใบนี้คือ คิดอย่างเจ้าของธุรกิจ ชั่งน้ำหนักระหว่างผลได้ — เสียอยู่เสมอ ไม่ติดกับดักความ Perfect มากเกินไป
หมวกใบที่ 2 : หมวกของ Automate Tester
Automate Test ที่ดีควรจะเร็ว และเชื่อถือได้
สืบเนื่องจากหมวกใบแรกเราทำ Automate test เพื่อ “ลดระยะเวลา” ทำให้เราสามารถนำเวลาไปทำงานอย่างอื่นที่จะมีประโยชน์ต่อธุรกิจต่อได้ จะทำแบบนั้นได้ก็จะต้องเริ่มต้นตั้งแต่การวางแผน เตรียมการ ดำเนินการ และบำรุงรักษา
1 ) วางแผน
ตั้งเป้าหมายการทำ Automate Test ให้ถูกต้อง โดยพี่ณัฐได้แชร์ว่าให้เน้นไปที่ความเร็วของการรัน Automate มากกว่ามุ่งเป้าไปที่ Coverage เพราะเมื่อ Automate เร็ว ช่วยลดงาน ลดเวลาได้จริง การเขียนเพื่อให้ Coverage จะตามมาเอง
2 ) เตรียมการ
ในการทำให้ Automate Test สามารถทำงานได้เร็ว และมีความน่าเชื่อถือ ไม่ได้เกี่ยวกับตัวโค้ดที่เขียนอย่างเดียว แต่ Ecosystem ที่จะช่วยให้ Script ที่เราเขียนดำเนินต่อไปได้ก็สำคัญ เช่น การทำ Browser / mobile farm
3 ) ดำเนินการ
“เขียน Automate มันไม่ยาก .. แต่เขียน Automate ที่มันสามารถนำไปใช้ได้จริง นั้นแหละยาก”
เขียนโค้ดโดยคำนึงถึงความเสถียรในการรันเสมอ เช่น ระบบซื้อขายของ เรากดสั่งซื้อของชิ้นเดิมไปเรื่อย ๆ โดยไม่ได้มีการเติมสต็อคกลับ เมื่อถึงจุดที่ของหมดเทสเราก็จะตาย ทำให้ขาดความน่าเชื่อถือไป
4 ) บำรุงรักษา
ปัญหาใหญ่ของการทำให้ Automate ไม่สำเร็จ คือ เราปล่อยให้มันหมดความน่าเชื่อถือ และค่อย ๆ ตายไปในที่สุด ทางทีม Doppio ได้แก้ปัญหานี้ด้วยการทำ Dashboard เพื่อ Monitor Automate Test อยู่ตลอดเวลา เซ็ตเป้าในการตาย หากต่ำกว่าที่เซ็ตเป้าไว้ให้มีการ Alert และส่งคนมารักษาโค้ดให้สามารถใช้ได้ดีอยู่เสมอ
3. หมวกใบที่ 3 : หมวกของ Developer
สิ่งที่ทำให้การเปลี่ยนผ่านจาก 3 อาทิตย์ ไปสู่ 10 นาทีได้จริง คือการนำ Automate Test ที่ได้ทำไว้ไปขึ้น ci/cd ให้ได้ ทั้งนี้ก็ขึ้นอยู่กับแต่ละทีมว่าจะให้รันตรงจุดไหนบ้าง เช่น ก่อนขึ้น QA Environment ไหม? ก่อน merge แต่ละครั้งเลยไหม? หรืออื่น ๆ
ซึ่งก็จะย้อนกลับไปที่ข้อแรกว่าทำไม Automate ของเราจะต้องเร็ว เพราะหากการ Push โค้ดของ Dev แต่ละทีจะต้องมารอเป็นชั่วโมง ๆ Dev ก็คงจะไม่แฮปปี้ จนอาจมีการขอให้ยกเลิกใช้เลยก็เป็นได้
Automation showcase
ใน Session นี้พี่โอ Doppio ได้มาแชร์เคส ที่ทาง Doppio ได้ทำ Framework ต่าง ๆ เพื่อนำมาช่วยในการทำ Automate Test ให้ดำเนินไปได้ด้วยดี
ที่ต้องออกตัวก่อนเลยว่า .. ขออนุญาตไม่สรุปในหัวข้อนี้ เนื่องจากไม่ได้เก็บภาพมา และการเขียนบรรยายอย่างเดียวอาจไม่เห็นภาพมากพอ จนอาจทำให้เนื้อหาคลาดเคลื่อนได้ แต่ยังไงก็เชียร์ให้เพื่อน ๆ ไปรับชมย้อนหลังได้ที่นี้ในชั่วโมงที่ 1.40 –2.14
เพราะเชื่อว่าจะต้องมีบาง Framework ที่ทาง Doppio ได้ทำมา จะต้องจุดประกายไอเดียให้หยิบจับไปทำได้แน่ ซึ่งจะให้หัวข้อกว้าง ๆ ไว้ ดังนี้
1.Test automate for production monitor
2.Inhouse mobile farm
3.Camera mocking framework
4.SMS framework — OTP
5.Hardware integration automation
6.Dynamic mock
7.On demand performance test framework
Path to 6 digits in QA Career
แค่ชื่อ Session ก็กระตุ้นต่อมให้ตั้งใจฟังขึ้นมากแล้ว เราจะทำยังไงถึงจะสามารถเป็น QA ที่มีเงินเดือน 6 หลักได้บ้างนะ !?
โดย Session นี้เหมือนเป็นการล้อมวง แชร์ประสบการณ์การเดินทางของพี่ ๆ แต่ละท่านที่ได้พบเจอมา ตลอดหลักสิบปีที่ได้อยู่บนเส้นทาง QA โดยจะเน้นหนักไปที่การ Q&A
พี่ ๆ ที่ได้มาแชร์ประสบการณ์ใน Session มีดังนี้
พี่บอย QA Manager จาก LSEG
พี่ปลา CEO & Founder จาก Vas.up
พี้ก้อย Senior QA Manager จาก Agoda
พี่ณัฐ CEO จาก Doppio
คำถามข้อ 1 : จุดไหนที่คิดว่าเป็นจุดพลิกผัน หรือจุดก้าวกระโดด ใน career การทำงาน ?
A : พี่ก้อย — Agoda
จุดพลิกผันจาก Team Lead มาเป็น Manager ตอนแรกเป็น Team Lead จะมุ่งไปที่ Product โดยส่วนตัวไม่อยากจัดการคน แต่พอได้มาทำเงินก็เพิ่มขึ้น
A : พี่บอย — LSEG
การโปรโมทจาก Team Lead เป็น Manager โดยต้องคุมทีม Outsource ที่คุมยากกว่าทีมประจำ แต่ยังไงก็ดีความรับผิดชอบที่เพิ่มขึ้น ก็มาพร้อมกับรายได้ที่เพิ่มมากขึ้นด้วย
A : พี่ปลา — Vas.up
เดิมเป็น Outsource อยู่บริษัทแห่งหนึ่ง และเขาดึงตัวกลับ แต่อยากทำต่อ จึงเปิดบริษัท Outsource ของตัวเอง แต่จุดเปลี่ยนคือ บริษัทที่อยากทำมองว่าไม่จำเป็นต้องมี Tester ก็ได้
จึงต้องเอาตัวรอด ด้วยการทำตัวให้แตกต่างจาก Outsource เจ้าอื่น คือเข้าใจระบบ เข้าใจธุรกิจให้มากกว่า เพื่อแแบ่งเบาภาระ จนเขาขาดเราไม่ได้ ซึ่งในปัจจุบันก็ยังทำกับที่ ๆ เขาบอกว่าไม่ต้องการ Tester ได้อยู่
A : พี่ณัฐ — Doppio
เดิมโตเป็น Maneger จาก Thomson Reuters และมีเดินสายสอนบ้าง จนมีคนชวนไปทำ Agoda เห็นว่าเป็นงานที่แตกต่าง และน่าสนุก
คีย์คือเลือกงานที่จะทำให้โต มากกว่าเลือกงานที่ให้เงินสูงที่สุด เลือกงานที่เก็บสกิลก่อน เลือกทางเติบโตที่ไม่มีลิมิต
คำถามข้อ 2 : ต้องเป็น Manager อย่างเดียวหรือไม่ ถึงจะประสบความสำเร็จในสายนี้ ?
A : พี่ณัฐ — Doppio
พยายามชวนมองในมุมคนให้เงินเดือน
“เงินเดือน ให้กับคนที่สร้าง Value ได้เยอะ”
นั่นหมายความว่าถ้าเก่ง Technical จะได้ถึงจุดหนึ่ง แต่ถ้าเรา Manage ดี ปั้นคนให้เก่งได้ เรากำลังทวี Value ของเราผ่านคนอีก 10–30 คน มันคือการทวีคูณ Value ที่คุณมอบให้แก่บริษัทนั้น นั่นเป็นเหตุผลว่าทำไมสาย Manage ถึงมีค่าตัวที่สูง
A : พี่ก้อย — Agoda
จะไปสุดทาง Technical หรือ Manage ก็ได้
แต่ต้องเทพจริง ๆ ในด้านนั้น ๆ เช่น เป็น QA ที่เชี่ยวด้าน Mobile App รู้ ios ครบทุกซอกมุม ไม่ได้หมายถึงว่าเทพนะ ถ้าเทพจริง ต้องรู้ทุกอย่างของ Mobile App !!
อีกอย่างคือเราต้องเก่งขึ้นทุกปีด้วย เพราะบริษัทก็คาดหวัง Value ที่เราต้องมอบให้มากขึ้น จึงจะคุ้มกับการปรับเงินเดือน แม้จะยังอยู่ตำแหน่งเดิมก็ตาม
A : พี่ญัฐ — Doppio ( เสริม )
Hard และ Soft Skill ต้องไปด้วยกัน
โดยเฉพาะ Soft Skill เป็นสิ่งที่ทำให้เราโต
บางคนความรู้เต็มหัว แต่สื่อสารออกไปแล้วไม่เข้า ไม่เห็นภาพ คนไม่ทำตาม ก็จะไม่สามารถไดร์ฟอะไรออกมาได้ ซึ่งเป็นเรื่องน่าเสียดายมาก
คำถามข้อ 3 : ความท้าทายในแต่ละฝั่งทั้ง Manage และ Technical คืออะไร
A : พี่บอย — LESG
ด้าน Manage ต้องดีลกับคนเยอะ คนเยอะปัญหาก็เยอะ ไม่ว่าจะระหว่างทีม หรือในทีมด้วยกันเอง ต้องใช้ทักษะในการมอง คุย กับคนให้ขาด
“มองว่าคนคือ asset ที่มีคุณค่า” — พี่บอย LSEG
ส่วนด้าน Technical เทคโนโลยีเปลี่ยนไว เปลี่ยนบ่อย ต้องไล่ตามให้ทันเพื่อให้ใช้ใน Business และต้องทำให้ทีมมีความรู้ทัดเทียมกันด้วย
คำถามข้อ 4 : ตอนเป็น Team Lead พี่ ๆ มีวิธีดูแลน้องอย่างไร ?
A : พี่ณัฐ — Doppio
แชร์คุณสมบัติ Leader ในมุมมองของพี่ณัฐไว้ว่า
Hard skill — มี Skills พาเราไปถูกทาง สอนเราได้
Soft skill — พาเราไปแล้วสนุก ไม่เครียด ให้คำปรึกษาได้
A : พี่ก้อย — Agoda
ชวนมองให้หลายมิติมากขึ้น โดยแบ่งเป็นหมวกต่าง ๆ ที่สวม
หมวก Professional — งานคืองาน ตาม Policy
หมวก พี่และน้อง — ความไว้ใจคือสิ่งที่ต้องสร้าง และใช้เวลา โดยสิ่งที่ทำให้เกิดความไว้ใจได้คือต้องมี Skill ที่ชัดมาก และมีศิลปะในการคุย
คำถามข้อ 5 : การจะ Mentor คนหนึ่งคนมีวิธี และวัดผลอย่างไร ?
A : พี่บอย — LSEG
ลองดูก่อนว่าเราต้องการอะไรจากเขา มีทาง เครื่องมือ และจะวัดผลเขายังไง เขาต้องการ Mentor ไหม แต่ทั้งนี้ต้องไม่ประคบประหงมแบบต้องพาจับมือทำ ต้องให้เขาสามารถเติบโตด้วยตัวเองได้
A : พี่ก้อย — Agoda
พี่ก้อยแชร์ในกรณีเมื่อรับคนใหม่
1. คุยความคาดหวัง ให้เคลียร์กันทั้งสองฝ่าย ว่าต้องการอย่างไร เท่าไหน ในระยะเวลาเท่านี้
2. หาวิธีวัดผลที่สามารถ”วัดผลได้จริง ๆ” ไม่ใช้ความรู้สึก
3. ติดตามผลความคืบหน้า อาจด้วย meeting 1–1 หรืออะไรก็แล้วแต่
4. Feedback ทำดีชม ทำแย่บอกถึงวิธีการปรับ .. Feedback ให้เป็น ไม่ใช่แค่บอกว่าไม่ดี แล้วไม่บอกว่าสิ่งที่ต้องการคืออะไร
5. Support และช่วยกันไปให้ถึงความคาดหวังที่คุยกันให้ได้ ถ้าไม่ได้จริง ๆ ค่อยปล่อยมือกัน
“อย่างนึงที่พี่ไม่ชอบเลยคือ โดนว่าทำได้ไม่ดี แต่ไม่รู้เลยว่าฉันทำอะไรได้ไม่ดี” — พี่ก้อย Agoda
คำถามสุดท้าย : Recap สั้น ๆ 1 นาทีทำยังไงให้เป็น QA เงินเดือน 6 หลัก ?
A : พี่บอย — LSEG
พัฒนา ประเมิน Value ของตัวเองแล้ว
อย่าลืมดูบริษัทด้วย ว่าจ่ายเราไหว
A : พี่ปลา — Vas.up
พัฒนาตัวเอง หาความรู้ทั้งมุมกว้าง และลึก
A : พี่ก้อย — Agoda
- อัพ Techniical Skill
- อัพ Soft Skill
- ขอความช่วยเหลือให้เป็น ไม่รู้ให้ถาม
A : พี่ณัฐ — Doppio
แชร์เรื่อง “Market Value” และ “Paid Value”
หน้าที่เราคือพยายามทำให้ตัวเองเกินกว่า Market Value อยู่เสมอ ไม่งั้นพอถึงจุด ๆ หนึ่งเราจะรู้สึกตัน
ส่วนตัวเราชอบ Session นี้มาก เพราะให้แง่คิดอะไรหลายอย่างมากก ที่เราสามารถนำไปปรับใช้กับตัวเองได้ ไม่ว่าจะอยู่ใน Level ไหนก็ตาม
และ QA Meetup 2024 ก็ได้ปิดฉากลงด้วยการถ่ายรูปรวมผู้เข้าร่วมงานในครั้งนี้ สุดท้ายขอขอบคุณทางสมาคมโปรแกรมเมอร์ไทย LSEG และ Doppio ผ่านทาง Blog นี้ ที่ได้จัดงานดี ๆ ให้ความรู้แบบฉ่ำ ๆ ของกินแบบจุก ๆ แบบนี้นะครับ
ขอบคุณครับ 😄
