QA ที่เก่ง เป็น A player และ QA Career path จากมุมมองของพี่

Doppio_Tosty-Admin

Uncategorized

March 24, 2026

Table of Content

สวัสดีพี่น้องชาว QA และ หลายๆคนที่อยากเปลี่ยนสายมาเป็น QA นะครับ Blog นี้อาจจะยาวหน่อยนะ ตอนแรกกะว่าจะเขียนเป็น post ธรรมดาในห้อง QA & Testers Thailand แต่เขียนไปเขียนมามันย๊าวยาวเลยเอามาแป่ะไว้ใน medium ดีกว่า เริ่มจากมีน้องๆหลายคนถามมาหลังไมค์ว่า ทำยังไงผมถึงจะเป็น QA ที่เก่ง ผมต้องไปเรียนอะไร ผมต้องทำยังไงดี ผม progress กับ careers นี้ต่อไม่ได้ผมต้องทำยังไงดี พี่เลยรวมๆเอามา share ใน blog นี้ละกันนะ หลักๆคือเรื่อง QA ที่เก่งที่เป็น A player (ในมุมมองของพี่) คืออะไร และทำยังไงถึงจะรอดถึงจะไปต่อกับ career path ทางนี้ของตัวเองได้

อย่างแรก QA ที่เก่งสำหรับพี่ หรือเวลาที่พี่มองน้องซักคนแล้วรู้สึกว่าไอ้คนนี้เจ๋ง เก่ง ไปได้ไกลเนี่ย มันประกอบไปด้วยหลายๆอย่าง อย่างแรกที่ขาดไม่ได้จริงๆ คือต้องเป็นคนที่รู้ลึกรู้จริง เกี่ยวกับ product ของตัวเอง รู้ทั้งมุมกว้างและมุมลึก รู้ตั้งแต่มุมว่าลูกค้าใช้ product เรายังไง (ลูกค้าส่วนใหญ่ใช้งานยังไงนะ ซึ่งเป็นคนละเรื่องกับการรู้ว่า feature ต่างๆของ product เราทำอะไรได้บ้างนะ) จนถึงการเข้าใจว่า business ของ product เราคืออะไร ทำเงินยังไง เป้าหมายคืออะไร เช่น เน้นขายของได้กำไร หรือเน้นหาลูกค้าใหม่ๆเข้ามา ให้คนมาใช้ platform เยอะๆ กำไรไม่เน้นทดไว้ก่อน (เอาจริงๆทาง business เนี่ย หาน้อง QA ที่เข้าใจน้อยมากๆ แต่ถ้าเราเป็นคนที่เข้าใจเราจะเป็น QA อีกประเภทที่มีแต่คนอยากได้ไปร่วมงานเลยนะ) จนถึง Architecture ของระบบว่า ระบบเราไปดึง หรือไปรับข้อมูลมาจากระบบไหนบ้าง และส่งต่อข้อมูลไประบบไหนบ้าง จากประสบการณ์ของตัวพี่เองสมัยทำงานตอนเป็นเด็กๆ พี่เป็น QA ที่รู้จักระบบหลังบ้านของพี่ดีสุดจนเป็นคนไปสอนระบบพวกนั้นให้เจ้าของระบบเอง แล้วมันทำให้พี่ทำงานง่ายมาก เห็น change หรือปัญหาอะไรเกิดขึ้นก็เชื่อมโยงกันได้หมด การไหล flow ของ data เป็นยังไง ไปลงปลายทาง database ไหน ใครจะเอาข้อมูลพวกนี้ไปใช้ต่อ ใช้ยังไง พวกนี้สำคัญมากนะ แต่เอาจริงๆไม่ค่อยเห็น QA มากนักที่รู้และเข้าใจเรื่องพวกนี้

สรุปให้เห็นภาพง่ายๆ ถ้าเราเป็น QA ที่ Product owner หรือ Dev วิ่งมาหาแล้วถามว่าจะเค้าจะ implement feature นี้ เค้าต้องระวังอะไรบ้าง ต้องคิดถึงอะไรบ้าง นั่นแหล่ะ เราเป็นคนที่เข้าใจ Product เรามากพอแล้วระดับนึง ลองคิดดูนะ ใครจะทำอะไร หรือติดปัญหาอะไรก็ต้องมาถามเราอ่ะ มันเจ๋งนะ และทำงานสนุกมากด้วย พี่จำได้พี่เคยบอก CEO พี่ว่า I think implement the feature this way is a stupid idea (ไม่ได้อยากจะ inspire ให้ไปพูดแบบนี้กับ CEO ในบริษัทนะ 555) แล้วพี่ก็เถียงกับ CEO กับ Dev manager จนสุดท้ายทุกคนก็เห็นตรงกับพี่ว่ามันต้อง implement แบบอื่น ตอนนั้นสนุกมากคือเรารู้จริงจนเถียงและนำพาใครก็ได้ การเป็น QA ที่เข้าใจ product ของตัวเองจริงๆ พี่คิดว่าสำคัญมาก และสำคัญที่สุดในการก้าวสู้ step ต่อไป และเราสามารถทำแบบนี้ได้ตั้งแต่เราเป็น Junior เพิ่งเริ่มทำงานด้วยซ้ำ ถามเยอะๆ พยายามเข้าใจมันจริงๆ กระโดดเข้าไป investigate หรือพยายามช่วยแก้ปัญหาทุกๆอย่าง ถึงแม้ว่ามันจะไม่ใช่งานของเราก็ช่วยให้เราพัฒนาด้านนี้ได้เยอะ

อย่างที่สอง QA ที่เจ๋งต้องพูดจารู้เรื่อง คือ communication เป็นเรื่องสำคัญ จริงๆไม่ใช่แค่กับ QA แต่กับทุก Role แต่พี่เน้นไว้ให้ตรงนี้เพราะเห็นว่าเป็นสิ่งที่หลายๆคนขาด และทำให้ก้าวต่อไปข้างหน้าไม่ได้ คือเอาจริงๆ Skill การพูดคุย การทำงานร่วมกับคนอื่นเป็นสิ่งสำคัญ เพราะว่าปัจจุบัน มันไม่มี software เล็กๆแบบที่เราทำงานคนเดียวได้อีกต่อไป ส่วนใหญ่ต้องทำงานกับทีมทั้งนั้น ไม่ว่าจะเป็น QA ด้วยกันเอง หรือกับ Dev ก็ตาม พี่เห็นบ่อยๆ น้องบางคนรู้ลึกรู้จริงรู้ทุกสิ่ง แต่ communication เข้าขั้นแค่ คือ มีสองแนว แบบแรกติ้สๆไม่ชอบพูดไม่ชอบอธิบาย กับอีกแนว คือ พูดไม่เป็นขาด skill ไม่ว่าจะแบบไหน น้องๆที่ communicate ไม่ได้ ลดแสงออร่าของตัวเองไปเยอะเลย คือ จากที่เป็นเด็กเก่ง รู้ทุกสิ่ง ทำงานได้ดี แทนที่จะเป็น super star ก็กลายเป็นเด็กที่ทำงานได้ในระดับกลางๆ เพราะไม่สามารถ bring value ของความรู้ตัวเองออกมาได้ หรือไม่ก็กลายเป็นคนที่ทำงานไม่ได้ ทำงานแย่ไปเลย เพราะทำงานกับคนอื่นไม่ได้ ขั้นแรกอยากให้น้องๆใส่ใจกับความสำคัญของ skill นี้ก่อน ถ้าใส่ใจแล้วเดี๋ยวเราก็จะหาทางฝึกมันได้เอง พี่ให้ technique ไว้สองสามอย่าง อย่างแรกคือเวลาเรา communicate อะไรให้คิดถึงหลักว่ามันต้อง Short, Sharp, Clear (กระชับ ตรงประเด็น และ ชัดเจน) จะได้ filter ความเยิ่นเย้อ ที่เราอาจจะมีหรือติดนิสัยมาโดยไม่รู้ตัวได้ (พูดเยอะไปก็ใช่ว่าดี) แล้วก็ นอกจาก short, sharp, clear แล้ว ฝากไว้อีกอย่างเป็น technique ขั้นสูงขึ้นมาอีกนิดคือ technique การหว่านล้อมให้คนอื่นเห็นตรงกับเรา What in it for them ไปอ่านกันได้ในนี้ WHAT IN IT FOR THEM

อันดับสาม พี่เรียกรวมๆว่า Technical skill ละกันนะ ซึ่งขอแยกออกจาก Automation skill นะ คือด้วยตัวงาน Software QA เนี่ย มันคืองาน Tech ดังนั้นมันจะมี Tool ต่างๆที่เราต้องรู้จัก ต้องใช้เป็น และที่สำคัญที่สุด เราต้องเป็นคนที่จะสามารถไปเรียนรู้การใช้ Tool ใหม่ๆได้ด้วยตัวเอง (Research skill) คือบางทีไม่ต้องไปคิดอะไรให้ลึกให้มากมาย พวกของ basic เช่น Postman หรือ skill การยิง API ด้วย tool ต่างๆ ความเข้าใจใน structure ของ data ต่างๆ การ Query ข้อมูลจาก Database หรือ Queue platform ประเภทต่างๆ การดักจับหรือ check data จาก network อะไรพวกนี้ เป็น Skill ที่ QA เก่งๆควรมี และบางทีถ้าเราไม่รู้ในบางเรื่อง แต่เรารู้ตัวหลักๆมากพอ และเราเป็นคนที่สามารถ research อะไรต่างๆเองได้ หาวิธีใช้จาก Google เองได้ นั่นก็เป็นสิ่งที่ดีเช่นกัน ดังนั้นฝึกใช้ tool ต่างๆพวกนี้ด้วยนะ อ่อ พวก Tool ที่ใช้ในการทำ Load/performance test ก็เป็นสิ่งสำคัญและเป็นการติดอาวุธให้เราเป็นอย่างดีนะ อย่าลืมไปศึกษาด้วยเน้อ เพิ่มให้อีกหน่อย QA ต่างชาติ โดยส่วนใหญ่จะค่อนข้างเก่งเรื่องพวกนี้ ใช้ tool เป็น technical ดี แต่ว่า area อื่นๆก็ไม่ได้เด่นกว่าคนไทยมากนะ นอกจากพวก Tool ต่างๆแล้ว ขอพูดถึง Technical skill อีกอย่างคือ เรื่องของ Testing Technique อันนี้ใน blog ต่างๆของพี่พูดถึงเยอะแล้ว ขอพูดถึงสั้นๆไว้ตรงนี้ว่า ถ้าอยากเป็น A Player ใช้มันเถอะ มันดี มันทำให้เรา โคตรเจ๋ง ตามไปอ่านเพื่อหา inspiration ได้ที่ มาใช้ Testing Technique กันเถอะ

อันดับสี่เนี่ย พี่ใส่ไว้อันดับสี่เลยนะ คือไม่ใช่ว่าไม่สำคัญ แต่เอาจริงๆสำคัญน้อยกว่า อันดับ 1–3 แต่คนชอบคิดว่าสำคัญสุด แบบถ้าชั้นอยากเป็น QA ชั้นต้องไปหาเรียน ไปทำอันนี้ให้ได้ คือเรื่องของ Test Automation ยอดนิยมนั่นเอง คือที่พี่บอกว่าสำคัญแต่ไม่จำเป็นเพราะว่า มันคือ skill การเขียน code เพื่อมา execute test แทนเรา ซึ่ง activity การ execute test เนี่ย เป็นแค่หนึ่งใน activity ที่ QA ต้องทำ คือถ้าไม่เข้าใจ product, คุยกับคนอื่นไม่รู้เรื่อง ใช้ Tool หรือ Query database ยังไม่เป็น แต่เขียน Automate code ได้ ก็ไม่เรียกว่าเป็น QA นะ ทีนี้มาว่าถึงความสำคัญของมันกันบ้าง พี่ว่า Automate Test skill คือ skill ที่ทำให้เรากลายเป็น QA A player หรือเป็น QA ตัว Top ได้เพราะว่าเราจะกลายเป็นคนที่ทำได้ทุกอย่าง ตั้งแต่ออกแบบ test case ที่เจ๋ง ทำงานกับคนอื่นได้ ใช้ Tool เป็น (ตามข้อ 1–3) แล้วเรายังสามารถ เขียน code ให้ machine มัน execute test แทนเราได้ด้วย ซึ่ง automate ในปัจจุบันเป็นสิ่งสำคัญ เพราะการ develop software ในปัจจุบันแข่งกันด้วยความเร็ว ถึงจะใช้เวลาในการเขียน automate เยอะ แต่ว่าพอมีมันแล้ว เราแตก thread ให้มันไปรันหลายสิบหลายร้อย thread พร้อมๆกันได้ ทำให้ย่นเวลาการ execute test จากหลายวันมาเป็นหลักนาที มันเลยเป็นสิ่งสำคัญสำหรับโลกสมัยใหม่ขึ้นมา ทีนี้ course automate ต่างๆ สมัยนี้หาเรียนตาม YouTube ได้เยอะแยะ ดูจาก channel Doppio Tech ก็ได้ เอาจริงๆเลยนะ การฝึกให้เขียน automate เป็นเนี่ยใช้เวลาแค่หลักอาทิตย์ ซึ่งใช้เวลาน้อยกว่าการฝึกข้อ 1–3 เป็นสิบเท่า คือมันไม่ได้ยากขนาดนั้น เอาจริงๆแล้วดังนั้นไม่ต้องกลัวแล้วหาโอกาสฝึก automate กันด้วยเน้อ

อันดับห้า สั้นๆสำหรับคนที่อยากก้าวไปข้างหน้าจนสุดทาง คือ skill ในการ Coaching หรือการสอนคนอื่น อันนี้พี่คิดว่าเป็น skill เสริมละกัน บางคนไม่ได้ฝึกหรือ focus กับเรื่องพวกนี้เลย รู้ตัวอีกที ถึงจุดที่อยากก้าวไปข้างหน้าไปเป็น senior เป็น lead เป็น manager แต่ติดตรงนี้ ต้องมาเริ่มฝึก skill นี้ใหม่ พี่เลยเอามาแป่ะไว้เป็นอันดับสี่ในนี้ เตือนใจให้ฝึกให้คิดถึง skill นี้ตั้งแต่เริ่มทำงานเป็น Junior กันเลย การนำพา การสอนคนอื่นนั้น เริ่มจากการสอนเพื่อน หรือแม้แต่สอนพี่ๆ คนใหม่ที่เข้ามาร่วมทีมก็ได้ การสอน product ของเราอะไรแบบนี้ ถ้ามีโอกาส กระโดดไปทำ ไปฝึกทำซะจะได้สั่งสม skill พวกนี้ไว้ตั้งแต่เริ่มทำงาน

มาถึงเรื่องสุดท้ายที่อยากคุยสั้นๆใน post นี้ คือเรื่อง Career Path (อาจจะเป็นเรื่อง sensitive แต่ใครอ่าน blog นี้เราจะไม่ดราม่ากันนะ) คืออยาก share ให้พอเห็นภาพ เพราะน้องหลายคน ทำงานอยู่ หรืออยากเปลี่ยนสายแต่มองไม่เห็นภาพ และกำลังคิดว่าไปต่อ หรือพอแค่นี้ มีคนถามเยอะมากเลย สายงานนี้ไปได้ไกลมั๊ย คือ คำว่าไกลคนเราอาจจะไม่เท่ากันแต่พี่บอกได้ว่า QA ที่เงินเดือน 100k — 200k up เป็นเรื่องธรรมดา (ส่วนน้อยที่จะไปถึง แต่ถ้าวัดเป็นจำนวนคนก็เยอะอยู่) การก้าวขึ้นไปที่ 200k — 500k เป็นเรื่องเป็นไปได้ (แต่เท่าที่เห็นก็น้อยหน่อยถึงน้อยมาก) ทั้งนี้ทั้งนั้นคนที่ค้างเติ่งอยู่ที่ 30k-50k แล้วถึงจุดตันไปไหนต่อไม่ได้ก็มีเยอะมากๆๆๆๆ เช่นกัน ฝากไว้ตรงนี้ว่า QA เป็นอาชีพที่ในแง่ของ compensation หรือเงินเนี่ย ไปได้ไกลนะ แต่ว่าถ้าเราจะไปถึงตรงนั้นได้ เราต้องทำตัวให้เป็น A player ให้เป็นกลุ่มคนที่เก่งที่สุดในสายอาชีพนี้จริงๆ เพราะว่าไม่งั้นเราจะค้างเติ่งติดอยู่ตรงจุดตันไปไหนต่อไม่ได้ แนะอีกอย่างจากประสบการส่วนตัวคือ ช่วง 3–5 ปีแรกของการทำงาน ให้เน้น invest กับความเก่งของตัวเอง หางานกระโดดไปทำงานที่ทำให้เราได้เก่ง อย่าเพิ่งกระโดดไปหาเงินเดือน แล้วพอเราเก่งแล้ว เดี๋ยวเงินมันตามมาเองแบบแซงไปข้างหน้าและไม่มีจุดตัน

หวังว่าจะพอเป็นแนวทางให้น้องๆได้เน้อ ทั้งนี้ทั้งนั้น ทุกสิ่งใน blog นี้เป็นความเห็นส่วนตัวของพี่ที่ทำงาน junior QA มาตั้งแต่เรียนจบ สร้างทีม QA ในบริษัทใหญ่จาก 5 คนเป็นเกือบ 200 คนที่ mix กันระหว่างคนไทยกับต่างชาติ และปัจจุบันทำบริษัทของตัวเองที่รับทำ service เกี่ยวกับ QA และ Automation ล้วนๆ

Doppio Tech — We Build And Serve Expertise

Related Blog

Uncategorized

Bug นั้นสำคัญไฉน

อาจจะยาวหน่อยนะครับ ไม่ได้เขียนมานาน วันนี้จะมาเล่าประสบการณ์จริงกับการเชือดบั๊กไปประมาณสองพันตัวในระยะเวลาประมาณ 2 ปีให้ฟังกันเน้อ เริ่มปู background หน่อยละกันครับ เหตุการณ์ในเนื้อเรื่องเริ่มขึ้นตั้งแต่เมื่อประมาณ 7–8 ปีที่แล้ว ก็ทำงานเป็นหัวหน้าทีม QA มีลูกน้องร้อยกว่าคน ทุกคนมี mindset ของ Quality for business ดังนั้นเวลาเจอ bug กับ feature ใหม่ๆเนี่ย เราก็จะคิด เอ๊ะ severity ของ bug ตัวนี้คืออะไร แล้วก็จะมี practice ในการคิดว่าถ้าไม่ได้เป็น bug ตัวใหญ่มากๆ ถ้าเรา log bug ไว้แล้วแก้ตามหลังเนี่ย feature นี้ถ้าออกวันนี้จะทำเงินได้เพิ่มหนึ่งล้านต่อวัน (สมมติ) ส่วน bug ตัวนี้ถ้าเราปล่อยไปอาจจะสร้างความเสียหายได้มากสุดสองหมื่นบาทต่อวัน แทนที่จะรอ fix bug สามวัน เราsign-off ไปก่อนแล้วค่อย fix ตามหลังได้ ได้มากกว่าเสียเห็นๆ…

Uncategorized

ว่าด้วยเรื่องของ Regression Test การจัดการ มุมมอง และสิ่งต้องระวัง

Blog นี้คุยกันเรื่อง Regression Test นะครับ เนื่องจากที่สัมผัสมา แต่ละที่มีนิยาม สิ่งที่มีอยู่ และการจัดการกับ Regression Test ไม่เหมือนกันเลย เกริ่นไว้ก่อนว่า สิ่งที่จะเขียนต่อไปนี้ มิได้มีหนังสืออะไรมารองรับ มาจากประสบการณ์และมุมมองส่วนตัวเป็นหลักละกันนะ เรามาเริ่มจาก Regression Test คืออะไรก่อนละกันครับ ตามนิยามแล้ว Regression Test คือการ Test เพื่อหา Impact หรือ Side effect จาก Change ซึ่งคำว่า Change เนี่ย สามารถเป็นได้ทั้งการ Change ที่ตัว Software ของเราเอง หรือแม้แต่การ Change ของ component/system รอบข้างมัน หรือแม้แต่ Environment หรือ Platform ที่ตัว Software รันอยู่นะ ถ้ามองแบบนี้ก็จะเห็นภาพง่ายขึ้น ก็คือ มี…

Other

Shared library คืออะไร และทำไมเราจึงควรใช้ในทีมและองค์กร วันนี้อยากจะมาเล่าเรื่อง Doppio Common Library

สวัสดีครับ บทความนี้อยากจะมาแชร์ไอเดียซึ่งหลายๆ คนอาจจะมีประสบการณ์กับอะไรพวกนี้มาอยู่แล้ว แต่มือใหม่ในด้าน Automation หลายๆ คน อาจจะยังไม่รู้จัก หรือยังไม่เข้าใจว่ามันคืออะไร บทความนี้ผมจะมาอธิบายให้ฟังกันครับ จุดเริ่มต้น หลายๆ คนที่ทำ automation อาจจะเคยประสบพบเจอกับเหตุการณ์ว่า พอเราย้ายไปทำโปรเจค automation อันใหม่แล้วบางทีเราก็มักจะเจอกับสิ่งที่เราเคยทำไปแล้ว ยกตัวอย่างเช่น และเหตุการณ์อื่นๆ ในลักษณะคล้ายกัน คือ เรา หรือเพื่อนร่วมทีมของเราที่อาจจะอยู่คนละโปรเจคหรือคนละทีม ได้เจอโจทย์คล้ายๆกันมาบ้างแล้ว และสิ่งที่เราต้องการในสถานการณ์นี้ก็คือ ทำยังไงให้เราสามารถสิ่งที่เราหรือใครสักคนในองค์กรเราเคยทำมาแล้ว ให้ได้เร็ว ไม่ต้องไปเสียเวลาเหมือนทำใหม่อีกรอบ ณ จุดเริ่มต้น (แบบตั้งไข่เลยนะ) เรามักจะมีประโยคคลาสสิคที่เราส่งไปให้เพื่อน “เฮ้ยๆ ขอโค้ดหน่อยดิ” , “เฮ้ยๆ ไป copy ได้ที่ repo ไหนบ้าง” ประมาณนี้ ทีนี้ถามว่ามันก็ตอบโจทย์ที่เราต้องการได้นะ ก็คือ ไม่ต้องเสียเวลาไปทำใหม่ แต่มันก็มีข้อเสียที่ยิ่งใหญ่อยู่ก็คือการที่เราจะต้อง copy กันต่อๆ ไปเรื่อยๆ มันจะมีปัญหาว่า Solution จากปัญหาข้างต้นของการ copy โค้ดไปมา…