QA ต้องไม่กลัวที่จะคุยกับคน และมีมนุษยสัมพันธ์ที่ดี

ผมมาทำงานที่ Seven Peaks ได้สามเดือนและเพิ่งผ่านโปรมาสดๆ ร้อนๆ เลย แต่ถ้าพูดถึงประสบการณ์การทำงานด้านการประกันคุณภาพซอฟต์แวร์ หรือ QA เนี่ย ปีนี้คือปีที่ 16 แล้ว จึงอยากแชร์เรื่องราวของผมให้ทุกคนได้อ่านกันครับ

จุดเริ่มต้นของการเป็น QA

จะว่าไปก็เหมือนเป็นโชคชะตาที่จับพลัดจับผลูให้ผมมาเริ่มเป็น QA นะ เนื่องจากมีบริษัทเข้ามารับสมัครงานที่มหาวิทยาลัยที่ผมเรียนอยู่ คือที่ลาดกระบัง สาขาวิชาวิทยาการคอมพิวเตอร์ คณะวิทยาศาสตร์ บริษัทนั้นเปิดรับอยู่สองตำแหน่งคือ developer กับ QA ซึ่งการสอบเป็น developer ต้องใช้ภาษา Java แต่ด้วยความที่ตอนนั้นผมเขียน Java ไม่คล่อง เลยไปทำข้อสอบ QA แทน ปรากฏว่าสอบผ่าน

หลังจากจบปริญญาตรีผมก็เลยทำงานเป็น QA ที่นั่นไปได้สองปี จากนั้นก็ไปเรียนต่อโทด้าน Business IT ที่สกอตแลนด์อยู่ปีหนึ่ง แล้วก็กลับมาทำงานที่บริษัทเดิมอีกครั้ง 

ความรู้สึกต่องานนี้

พอได้ทำงานไปได้สักพัก ผมก็รู้สึกว่า QA มันตรงกับบุคลิกของผมเหมือนกัน เพราะผมมีความเป็น perfectionist อยู่ เห็นอะไรที่ไม่เป๊ะมันก็จะรู้สึกหงุดหงิด เหมือนเวลาเห็นประตูปิดไม่เรียบร้อยก็อยากจะไปปิดให้สนิท และผมจะหงุดหงิดเวลาใช้งานแอปฯ อะไรส่วนตัวแล้วมีปัญหาหรือเจอบั๊ก ผมจะคิดในใจว่า 

“โอ้โห! ปล่อยแอปฯ ออกมาแบบนี้ได้ยังไง QA กับ tester มัวทำอะไรอยู่”

เวลาทำงานก็จะพยายามให้มันออกมาเนี้ยบที่สุด รู้สึกภูมิใจเวลาลูกค้าตรวจงานแล้วชมเราว่างานเราเรียบร้อย ใช้แอปฯ แล้วเสถียรดี ไม่มีปัญหา ผู้ใช้รู้สึกพึงพอใจ พอเห็นว่างานที่เราทำไปมันมีผลกระทบต่อผู้ใช้จริง สิ่งเหล่านี้มันเติมเต็มผมได้ดีมากๆ ไม่ใช่แค่ว่าทำงานเสร็จ พอสิ้นเดือนรับเงิน แค่นั้น

มันจึงตรงกับคุณสมบัติของ QA ที่ต้องการความเป๊ะ พอผลงานออกมาได้รับฟีดแบ็กที่ดีด้วย ก็เลยรู้สึกว่าเราทำงานนี้ได้ดี เลยทำต่อมาเรื่อยๆ ตั้งแต่ junior มาเป็น senior จนถึงทุกวันนี้ที่เป็น Head of QA

ความเชี่ยวชาญในแต่ละสายงานของ QA

ถ้าถามว่าผมเชี่ยวชาญสายอะไรมากที่สุดของ QA ผมคงตอบไม่ได้ เพราะอะไรรู้ไหม?

ก่อนที่จะลงรายละเอียด ผมขออธิบายก่อนว่า QA กับ tester มันจะมีความแตกต่างกันอยู่นิดหน่อย เป้าหมายของ tester คือการหาบั๊กให้ได้ละเอียดที่สุด พอเจอบั๊กแล้วก็ส่งให้ developer แก้ไขให้หมด พอแก้หมด ลูกค้าได้โปรดักต์ที่ไม่มีบั๊ก เขาก็พอใจ 

ในขณะที่ QA จะมีเป้าหมายคือการป้องกันไม่ให้เกิดบั๊ก จึงต้องไปร่วมมือกับ developer ในการวางแผนว่าควรเขียนโค้ดอย่างไรจึงจะออกมามีคุณภาพดีที่สุด เพราะบางที developer ก็ไม่รู้ว่าพอเขียนโค้ดเสร็จแล้วจะโดนทดสอบที่จุดไหนบ้าง แต่ไม่ว่าอย่างไร QA ก็ยังต้องทำ test ด้วย เรียกว่า manual testing เป็นการเขียน test case ตามโปรดักต์ที่ออกมา มีการรัน test ตามที่ตกลงกันไว้ปิดท้ายเพื่อดูว่ามีอะไรผิดปกติบ้าง ซึ่งผมโตมากับสาย manual testing แบบนี้

ทีนี้มันก็จะมีอีกสายแยกย่อยออกมาคือ automation testing สมมติว่าคุณทำแอปฯ สำหรับธนาคารแห่งหนึ่ง ซึ่งอาจจะมีมานานหลายปีแล้ว แล้ววันหนึ่งออกฟีเจอร์ใหม่มา ซึ่งสำหรับการพัฒนาซอฟต์แวร์นั้นจะมีกฎมาตรฐานอย่างหนึ่งคือ “ถ้าออกฟีเจอร์ใหม่ ของเดิมห้ามพัง”

ดังนั้น ถ้าโปรดักต์นี้ออกมาหลายปีแล้ว ย่อมมีฟีเจอร์เก่าเยอะมาก ก็ต้องทำ regression test เพื่อดูว่าของเดิมยังใช้งานได้ไหม ซึ่งอาจต้องใช้เวลาประมาณ 5 วัน โดยระดมคนจำนวนมากมาทำ test พอมีฟีเจอร์ใหม่ทีก็ต้องทำ test เหมือนเดิมอีกรอบ มันเริ่มมีรูปแบบซ้ำๆ ใช้ทรัพยากรตั้งเยอะ เลยมีคนคิดขึ้นมาว่า “เราเขียน automated script ให้คอมพิวเตอร์ทำการทดสอบแบบอัตโนมัติได้ไหม?” อันนี้เรียกว่า automation testing

สายที่สามคือ performance testing อธิบายง่ายๆ เช่น เวลาเราเปิดแอปฯ อย่าง Facebook ขึ้นมาแล้วมันใช้เวลานานเกินสิบวินาทีกว่าจะโหลดข้อมูลเสร็จ ผู้ใช้ก็คงปิดแอปฯ ไปใช้แอปฯ อื่นดีกว่า ดังนั้น งานสายนี้คือการตรวจสอบตามมาตรฐานว่าพวกเว็บไซต์หรือแอปฯ ควรจะตอบสนองภายในกี่วินาที หรือสายการบินจะปล่อยโปรโมชั่นตั๋ว 0 บาทพรุ่งนี้ พอเที่ยงคืนก็จะมีคนไปรอกดจองที่หน้าเว็บไซต์ แต่พอกดจองปุ๊บเว็บล่ม แบบนี้ QA ก็จะต้องกำหนดมาตรฐานไว้ เช่น เว็บไซต์ต้องรองรับคนได้ไม่ต่ำกว่า 1,000 คนในเวลาเดียวกัน และเว็บไซต์ต้องทำงานได้รวดเร็วตามปกติด้วย

สามสายงานที่ว่ามาจะอยู่ในฝั่ง technical ซึ่งเป็นสิ่งที่ QA จะเรียนรู้มาตั้งแต่ตอนเป็น junior จนเติบโตขึ้นมาเรื่อยๆ แต่ตัวผมเป็นเป็ด คือทำได้ทุกอย่าง เพราะโตมาจาก manual testing แต่ก็เป็นคนขี้เกียจ มีครั้งหนึ่งเคยไปร่วมเล่นเกมชิงโชคแล้วต้องกรอกรายละเอียดส่วนตัวที่หน้าเว็บไซต์ ยิ่งกรอกมากยิ่งมีโอกาสมาก แต่ต้องกรอกข้อมูลเยอะ เลยเขียน automated script เพื่อกรอกข้อมูลอัตโนมัติแทนตัวเอง เลยพบว่า automation testing ก็ดีนะ มันสามารถทำงานแทนเราในสิ่งที่เราขี้เกียจทำได้ ก็เลยเริ่มสนใจทางด้านนี้

ส่วนเรื่องการทำ performance testing นี่มาจากเหตุการณ์ที่คนอื่นๆ เขาเห็นว่าผมทำ automation testing ได้ เขาก็เลยให้ลองทำ performance testing ดู ผมจึงได้เรียนรู้ทักษะนี้ไปด้วย 

ปกติแล้วคนที่ทำงาน QA จนเป็น senior เขาก็จะเลือกเส้นทางว่าอยากโตไปในสาย management หรือสาย technical ซึ่งทีแรกผมก็ไปในสาย technical พอทำไปสักพัก บริษัทที่ทำอยู่ตอนนั้นเขาหาคนที่ทำได้ทั้งสองฝั่งไม่ได้สักที ผมเลยต้องไปช่วยดูเรื่องการบริหารคนด้วย เลยกลายเป็นโตขึ้นมาแบบก้ำกึ่งทั้งสองสาย

แต่ถ้าถามว่าชอบอันไหนมากที่สุด ผมคงตอบว่าสาย automation testing เพราะตั้งแต่ขึ้นมาทำงานเป็น Head of QA แล้ว ต้องดูเรื่องของ ROI (Return on Investment) มากขึ้น เวลาที่ให้น้องๆ ในทีมทำงานต่างๆ ถ้าหากเราต้องนั่งทำแบบแมนวลไปตลอด สุดท้ายแล้วมันจะใช้ต้นทุนมากเกินไป เช่น ยิ่งเราอยากอัปเดตฟีเจอร์ใหม่บ่อยๆ ยิ่งต้องทำ regression บ่อยๆ แทนที่จะต้องใช้เวลาทำสามวัน ทำ automation testing แค่คืนเดียวก็จบ เช้ามานั่งดูผลลัพธ์ ถ้าผ่านแล้วก็ส่งลูกค้าได้เลย

ดังนั้น องค์กรที่ต้องการเติบโตอย่างรวดเร็วก็ต้องเน้นเรื่อง automation testing ตั้งแต่ผมมาอยู่ที่ Seven Peaks ผมก็เลยพยายามกระตุ้นให้ทีมมีทักษะการทำ automation testing มากขึ้น 

การ disrupt ของ automation testing

หากถามว่าในอนาคต automation testing จะมาแทน tester โดยสมบูรณ์ได้ไหม ขอตอบเลยว่า “ไม่ได้” เพราะอย่างไรเสียก็ต้องมีคนมาคอยควบคุมแบบแมนวลอยู่ รวมทั้งคนที่ถนัด manual testing เองก็จะค่อยๆ พัฒนาทักษะของตัวเองในการทำ automation testing ขึ้นมาด้วย 

ดังนั้น คนที่จะโดน disrupt จริงๆ คือคนที่ทำเป็นแค่ manual testing อย่างเดียว จริงๆ แล้ว ต่อให้เขียน automation testing ไม่ได้ อย่างน้อยที่สุดก็ควรกดรันเป็น หรือแก้ไขอะไรบางอย่างได้ คนที่ทำ manual testing อาจจะพออยู่ได้บ้าง แต่อุตสาหกรรมนี้มันจะค่อยๆ เล็กลงตามเทรนด์ที่เน้นไปทาง automation testing 

ถ้าเป็นบริษัทที่หัวก้าวหน้าหน่อย เขาจะเขียน automation test เอาไว้ก่อน manual test หรือเขียนโค้ดด้วยซ้ำ เรียกว่า BDD หรือ behavior-driven development สมมติว่า developer เขียนโค้ดเสร็จ เขาก็จะเอา test case นี้ไปรันเลย ถ้ารันไม่ผ่านก็กลับไปแก้โค้ดใหม่ พูดง่ายๆ ก็คือ “test first” ไม่ใช่ว่าเขียนโค้ดให้เสร็จแล้วค่อยมาทำ test case ตามหลัง ซึ่งมีบางบริษัทที่ใช้แนวทางนี้แล้ว

แต่อย่างไรก็ตาม manual testing ก็ยังอยู่ หลายๆ องค์กรยังรู้สึกว่าการทำ automation testing นั้นไม่คุ้ม เช่น สมมติว่า QA 1 คนอาจจะรับมือการทำ test ให้กับ developer ได้ 4 คน แต่พอมี automation มันก็เหมือนมีงานเพิ่ม เพราะหลังจากที่ทำ manual testing เสร็จ ก็ต้องมาทำ automation ด้วย ซึ่งอาจจะต้องมี QA 2 คน คือ คนที่ทำ manual เสร็จ ก็ส่งให้คนที่ทำ automation ทำ 

บางบริษัทก็เลยใช้วิธีจ้าง manual tester เต็มไปหมดเลย เป็นเอาต์ซอร์สด้วยซ้ำไป แค่ให้ทำ manual testing ตาม test case ที่มีอยู่ วันๆ ทำแค่ regression อย่างเดียวก็มี พอเจอบั๊ก ก็ log ไว้ ซึ่งเขามองว่าแบบนี้มันคุ้มกว่า จนถึงจุดหนึ่งที่คิดว่าไม่คุ้มแล้ว เขาถึงจะเปลี่ยนมาเป็น automation testing ดังนั้น บริษัทที่ต้องใช้ automation จริงๆ คือเขาทำ regression เองซ้ำๆ ไม่ไหวแล้ว

อนาคตของการทำ QA

สิ่งสำคัญที่จะเปลี่ยนไปคือ QA สมัยก่อนจะเน้นการทำ test แต่ QA ในยุคต่อไปต้องสามารถเพิ่มคุณค่าให้กับทีมได้ คอยคุมว่าทุกอย่างมีคุณภาพ ยกตัวอย่างเช่น เวลาคุณซื้อบ้าน ก่อนที่จะได้บ้านมาก็ต้องไปตรวจบ้าน ก็อาจจะจ้างบริษัทตรวจบ้าน บริษัทนี้ก็เปรียบเสมือน tester พวกเขาก็จะทำ test แบบกระหน่ำเลย เจอ defect เต็มบ้านไปหมด แล้วส่งให้ผู้รับเหมาไปแก้ ซึ่งผู้รับเหมาก็เปรียบเสมือน developer เขาก็ไปแก้ไขมา จนบ้านเรียบร้อย ไม่มีบั๊ก ลูกค้าแฮปปี้ แต่มันเสียเวลา เพราะต้องเข้าไปเช็กบ้าน แล้วก็แก้ไข แล้วมา test ใหม่ ถ้ายังแก้ไม่หมดก็ต้องไปแก้แล้วกลับมา test อีกที วนลูปอยู่แบบนี้ กว่าจะได้บ้านมา แต่ถ้าเป็น QA เขาจะคอยตรวจสอบว่าผู้รับเหมาทำงานเรียบร้อยทุกอย่างตั้งแต่ต้นทางหรือเปล่า 

ซึ่งคำว่าต้นทางไม่ใช่แค่การเขียนโค้ดบรรทัดแรก แต่เริ่มตั้งแต่ requirement เลย ซึ่งหมายถึงทางฝั่ง busniess อาจจะปิ๊งไอเดียว่าเขาจะทำโปรดักต์ออกมา คิดว่ามันจะต้องตอบโจทย์ลูกค้าแน่ๆ และเขาจะคิดเวิร์กโฟลว์ออกมาว่าจะต้องครอบคลุมอะไรบ้าง ตรงนั้นเรียกว่าเฟสของ business requirement 

QA จึงมีหน้าที่ต้องไปตรวจ requirement ว่าลืมอะไรไปบ้างไหม หรือไอเดียที่คิดมามันเวิร์กกับลูกค้าจริงไหม เป็นต้น ก่อนที่จะแปลงมาเป็น technical requirement เนื่องจาก developer ไม่สามารถเขียนโค้ดจาก business requirement ได้โดยตรง ต้องแปลงเป็น technical requirement ก่อน จากนั้นตัดแบ่งออกเป็นก้อนเล็กๆ แล้วก็เขียนโค้ดทีละก้อน 

ดังนั้น คนที่จะมากำกับคุณภาพในขั้นตอนดังกล่าวก็คือ QA เพราะบ่อยครั้งที่ได้ requirement มา พอเอาไปทำ test case หน้างานจริงๆ ปรากฏว่าหลุด case บางอย่างไป ต้องวิ่งกลับไปหา product manager ว่าลืม case นี้ไป ก็เสียเวลาต้องมาแก้ปัญหาอีก แทนที่จะได้ส่งมอบงานใน sprint นั้นๆ อาจจะหลุดไปอีก sprint หนึ่ง

หมายความว่า QA ต้องก้าวเข้าไปอยู่ในฝั่ง business มากขึ้น ซึ่งพอ QA มาทำงานในส่วนของ business requirement เยอะขึ้น จะช่วยประหยัดเวลาในตอนทำงานแต่ละ sprint ได้ การทำงานกับ developer อาจจะเปลี่ยนไป เพราะพวกเขาต้องดูแลคุณภาพของโค้ดเองมากขึ้น อาจจะมี test case ให้ทำตาม แล้ว QA มาเก็บงานอีกทีตอนท้าย จะไม่ใช่รูปแบบเดิมที่ developer เขียนโค้ดมาแล้ว QA test ให้อีกต่อไป

ความรับผิดชอบของ Head of QA แตกต่างจาก QA อย่างไร

หน้าที่สำคัญของ Head of QA คือการวาง direction ให้ชัดเจนว่าหน่วยงานของ QA ต้องก้าวไปในทิศทางไหน 

ซึ่งมันไม่ได้เคลื่อนที่ไปแค่ฝั่งของ QA อย่างเดียว แต่ต้องสอดคล้องกับแผนกอื่นๆ ด้วย เช่น ต้องฝึกทักษะของทีม QA ให้สามารถทำงานร่วมกับทีมโปรดักต์ได้ เพื่อให้งานไปในทิศทางเดียวกัน ถ้า QA จะใช้เวลาในแต่ละ sprint น้อยลงเพื่อไปทำงานร่วมกับทีมโปรดักต์ ก็ต้องมาเตรียมพร้อมในฝั่ง developer ว่าพวกเขาต้องมีทักษะอะไรเพิ่มขึ้นบ้าง

ดังนั้น Head of QA ต้องรู้ว่าปลายทางเราต้องการอะไร และระหว่างทางจะมี milestone อะไรบ้าง แต่ละ milestone มีใครเกี่ยวข้อง ถ้าตรงไหนยังขาดคน ก็ต้องจ้างเพิ่ม หรือเพิ่มทักษะให้กับทีมงานในการทำหน้าที่ตรงนั้นให้ได้ เช่น ถ้ายังขาดเรื่อง automation testing ก็ต้องฝึกให้คนในทีมทำเรื่องนี้ได้

หน้าที่อีกอย่างคือการหาคนเพิ่มในฝั่งหลังบ้าน อย่างการที่ผมเข้ามาเป็น Head of QA ที่ Seven Peaks ในแผนของผมมีการเพิ่มตำแหน่งใหม่ขึ้นมาคือ SDET หรือ Software Development Engineer in Test ซึ่งในปัจจุบันตำแหน่งนี้มีในอุตสาหกรรมไอทีอยู่แล้ว แต่ยังไม่แพร่หลาย 

ลองนึกภาพว่า QA มีหน้าที่ทำ test แต่อาจยังขาดทักษะในการทำ automation testing ซึ่งไม่ใช่เรื่องง่าย เพราะต้องเข้าใจสถาปัตยกรรมของมัน รวมถึงการติดตั้งโค้ดต่างๆ การมี SDET ทำให้ QA ทำงานง่ายขึ้น ไม่ต้องไปยุ่งกับเรื่องเหล่านั้น ทำงานในส่วนของ application level อย่างเดียว อะไรที่ยุ่งยากซับซ้อนในทางเทคนิคจะถูกเตรียมไว้เป็นไลบรารีเรียบร้อยแล้ว นอกจากนี้ยังทำให้ QA สามารถทำ automation testing หรือ performance testing หนักๆ ได้ราบรื่นขึ้นด้วย 

สัดส่วนการจ้างคนที่มีความรู้เรื่อง automation หรือ performance จากที่ต้องการความรู้ขั้นต่ำถึง 70% อาจจะเหลือแค่ 50% ก็พอแล้ว ทำให้หาคนได้ง่ายขึ้น หรือถ้าต้องเพิ่มทักษะของทีมงาน ก็ไม่ต้องเพิ่มขึ้นไปให้ถึง 70% เพราะมันจะยิ่งยาก และมีต้นทุนสูงขึ้น

ในด้านการให้คำปรึกษาคนในทีม สำหรับที่นี่ผมไม่ได้อยู่สูงส่งกว่าคนอื่นๆ ยังมีการกระโดดลงไปทำงานเองด้วยในบางครั้ง

อีกอย่างคือ หากต้องการสร้างความเปลี่ยนแปลงในองค์กร ต้องมีกระบวนการที่ชัดเจน ไม่อย่างนั้นมันจะกลายเป็นการจับปูใส่กระด้ง เนื่องจากเราไม่ได้มีโปรดักต์ที่มีแนวทางเดียวกันหมด แต่เราทำงานตามความต้องการของลูกค้าที่แตกต่างกัน ถ้าเราไม่มี core standard ของตัวเอง เวลาลูกค้าต้องการอะไร เราก็ทำตามเขาไปหมด เวลาที่คนของเราเปลี่ยนโปรเจกต์ก็จะมีปัญหา เพราะสิ่งที่เคยทำในโปรเจกต์ A เอามาใช้กับโปรเจกต์ B ไม่ได้

แถมเรายังทำตามหลักการ time and material ด้วยการบันทึกชั่วโมงในการทำงานว่า แต่ละวันเราทำงานให้โปรเจกต์ไหน กี่ชั่วโมง ในเรื่องอะไรบ้าง สมมติว่าผมทำงานให้ลูกค้าเจ้าหนึ่ง แล้ว log เวลาว่าวันนี้ทำงานให้เขา 8 ชั่วโมง ลูกค้าจะเชื่อได้อย่างไรว่าทำจริง เราก็ต้องมีหลักฐานว่า นี่ไง ผมทำ test ไป มีผลลัพธ์ให้ดู หลักฐานทั้งหมดก็จะเกี่ยวข้องกับกระบวนการว่า ในการทำ test เราต้องให้อะไรลูกค้าเป็นหลักฐานบ้าง ต้องเขียน test case แบบไหน ต้อง snapshot อย่างไร 

อีกอย่างที่ Head of QA ต้องทำคือการวัดผล เพราะถ้าไม่มีไม้บรรทัดมาคอยวัดว่าองค์กรเราทำได้ดีแค่ไหน เราใช้แค่ความรู้สึกว่าทำ test แล้วก็น่าจะโอเคนะ ลูกค้ายังไม่ด่า แบบนี้ก็ไม่ได้ เพราะมันจับต้องไม่ได้ สิ่งที่จับต้องได้ เช่น ดูว่ามีบั๊กเกิดขึ้นใน production กี่ตัว หรือจากปีที่แล้ว แต่ละเดือนเราเจอบั๊กประมาณ 5 ตัว พอมีการนำกระบวนการใหม่มาใช้ ปรากฏว่า แต่ละเดือนเจอบั๊กแค่ตัวเดียว ก็แสดงว่ากระบวนการนี้ได้ผล เป็นต้น ซึ่งจริงๆ มันมีวิธีการวัดผลอีกหลายอย่างมาก

ประสบการณ์ด้านอื่นๆ

นอกจากเรื่อง QA แล้ว ผมก็พอมีประสบการณ์ทำอย่างอื่นบ้าง เช่น เป็น Acting Lead อยู่นานพอสมควร และได้ทำเรื่อง DevOps มาบ้างในตำแหน่ง Software Development Manager ซึ่งต้องดูแลทั้งทีม DevOps และ QA

สำหรับคนที่ไม่คุ้นเคยกับคำว่า Acting Lead ผมขออธิบายว่า สมมติตำแหน่ง Senior QA คือคนที่หยิบงานมาดูแลเองได้ หรือคอยให้คำปรึกษาน้องๆ ได้ แต่พอเป็น Acting Lead หรือ Lead แล้ว เราจะต้องคิดเผื่อทีมมากขึ้น บางทีต้องคิดข้ามทีมด้วย ไม่ใช่แค่ทีมตัวเอง เช่น ไม่ได้ดูแค่ backend แต่ต้องครอบคลุมไปถึง frontend ด้วยว่าเขามีปัญหาอะไรหรือเปล่า ต้องเข้าไปช่วยดูเรื่อง assignment รวมถึงการประสานงานกับผู้มีส่วนได้ส่วนเสียด้วย

อุปสรรคสำคัญที่เจอ

กับดักสำคัญที่ผมเคยเจอคือเรื่อง scalability สมมติว่าเราจะออกโปรดักต์เวอร์ชันใหม่ให้ลูกค้า มันก็ต้องมีการทำ test ซึ่งถ้าผมทำอยู่แค่คนเดียว ผมอาจจะทำ test ได้ดีมาก สามารถควบคุมผลงานได้ แต่พอขึ้นมาดูแลภาพใหญ่ขึ้น มีอยู่ 15 โปรดักต์ ถ้าอยากให้มันเนี้ยบทั้ง 15 โปรดักต์ ผมจะใช้เวลาเพิ่มขึ้นอีก 15 เท่าก็เป็นไปไม่ได้ จริงไหม แล้วมันต้องทำอย่างไรเพื่อให้คนในทีมสามารถทำได้เท่าที่ผมทำ

ไม่ได้หมายความว่าผมเก่งที่สุดนะ แต่ต้องตั้งมาตรฐานไว้ว่าต้องทำอะไรให้ได้แค่ไหน ไม่อย่างนั้น ทุกสิ่งทุกอย่างจะวิ่งมาหาผมหมด เนื่องจากบางครั้งพอให้น้องในทีมไปทำ เขาเก็บรายละเอียดงานได้ไม่หมด ผมก็ต้องลงไปช่วยดู จากงานที่ถ้าทำเองเสร็จภายในสองชั่วโมง แต่พอให้น้องทำ แล้วต้องมานั่งแก้ไข อาจจะใช้เวลารวมแปดชั่วโมง แล้วเราจะทำอย่างไรเพื่อแก้ปัญหานี้

เปรียบเทียบง่ายๆ เช่น ถ้าผมเป็นชาวนา หน้าที่ผมคือต้องปลูกข้าว แต่พอจะออกจากบ้านปรากฏว่าอุปกรณ์พัง ต้องไปนั่งซ่อม ก็จะไม่ได้ไปโฟกัสกับสิ่งที่เป็น core value จริงๆ แบบนี้มันก็ scale ไม่ได้ เป้าหมายที่ต้องการจะไปให้ถึง มันก็ไปไม่ถึงสักที ถ้าต้องมาลงมือเองทุกโปรเจกต์ ก็จะไม่มีเวลาวาง direction ไม่มีเวลาไปร่วมมือกับทีมอื่นๆ เป็นต้น 

ซึ่งวิธีแก้คือ ต้องเปลี่ยน mindset ให้ได้ว่า นี่ไม่ใช่ธุรกิจที่ผมสามารถทำได้คนเดียว ต้องเชื่อใจคนในทีมว่าเขาสามารถทำได้ และต้องฝึกให้เขาทำได้ สนับสนุนเขาให้พร้อมลุยงาน ถ้าเขามีปัญหาอะไร เขามีผมอยู่ข้างหลังที่สามารถเข้าไปช่วยได้เสมอ 

ดังนั้น ต้องทำงานอย่างเฉลียวฉลาดมากขึ้น ชีวิตนี้เราไม่สามารถทนทำงานหนักได้อย่างเดียว

ฝึกฝนทักษะการทำงานจากใครบ้าง

ผมได้ฝึกฝนทักษะการทำงานมาจากหลายๆ คน ซึ่งขอแบ่งเป็น 2 กลุ่ม กลุ่มแรกคือพวกที่ตั้งใจมาสอนงานเลย เช่น เวลามีประชุม 1 on 1 ก็จะได้ปรึกษา manager ซึ่งเป็น mentor โดยตรงของผมเลย เขาก็จะรู้ว่าตรงไหนเป็นจุดอ่อนของผม เขาก็พยายามหาทางปรับปรุงให้

ตอนเด็กๆ ผมเคยไปยืนนำเสนองานหน้าห้อง มีคนแค่ 10 กว่าคนก็สั่นแล้ว ทำอะไรไม่ถูก พอเรียนจบมาใหม่ๆ เขาให้ไปนำเสนองานต่อหน้าลูกค้าต่างชาติที่เมืองนอก ลูกค้าประมาณ 30 กว่าคน ต้องแบกชื่อเสียงของบริษัทไป แล้วต้องนำเสนองานเพื่อสอนลูกค้า แม้ว่าจะมีความรู้ในเรื่องเหล่านั้นอยู่แล้ว แต่ไม่สามารถสื่อสารออกมาได้ ทำได้แค่ 10-20% ของสิ่งที่รู้ ลูกค้าก็ยิ่งงงเข้าไปใหญ่

พอ manager เขารู้ว่าผมมีจุดอ่อนแบบนี้ เขาก็อธิบายว่าต้องทำยังไง ตอนหลังๆ เขาเลยให้ผมนำเสนอหัวข้อต่างๆ ให้คนในทีมแทบทุกอาทิตย์ ต้องไปหาหัวข้อมาว่าจะพูดเรื่องอะไรดี ทำให้ได้เรียนรู้สองอย่าง อย่างแรกคือผมได้ศึกษาเรื่องพวกนั้นเพิ่มเติม อย่างที่สองก็คือได้ฝึกทักษะการนำเสนอด้วย เลยได้พัฒนาเรื่องนั้นมาจนทุกวันนี้ ล่าสุดได้นำเสนอใน Engineering Hours ของบริษัทมา ต่อหน้าคนเกือบร้อยคน ก็พูดได้สบาย หรือให้ผมไปนำเสนองานกับลูกค้า ผมก็ทำได้

กับอีกกลุ่มที่ผมใช้วิธีครูพักลักจำเอาจากคนที่รู้ และผมไม่อายที่จะถามในสิ่งที่ผมไม่รู้ กล้าถามแม้กระทั่งลูกน้องตัวเอง ต้องยอมรับว่าเด็กรุ่นใหม่ทุกวันนี้เขาเก่งกว่าเรา เขาอาจต้องเรียนรู้ประสบการณ์จากเรา แต่หลายอย่างเราต้องไปเรียนรู้จากเขา แค่เรากล้าถามเขาก็กล้าสอน พอเราทำเป็น หลังจากนั้นก็สบาย

สิ่งสำคัญที่ได้เรียนรู้ตลอดประสบการณ์ 16 ปี

ผมว่า soft skill เป็นสิ่งสำคัญมาก โดยเฉพาะเรื่องมนุษยสัมพันธ์ เพราะเราไม่ได้ทำงานคนเดียว และเราไม่ได้ทำงานทีมเดียว แต่มีผู้เกี่ยวข้องในงานของ QA เต็มไปหมดเลย ต้องคุยกับ product manager,  scrum master, และ developer เป็นต้น 

การสร้างความสัมพันธ์ที่ดีไม่ใช่การบอกว่า เราเป็นเพื่อนรักกันนะ แต่มันคือการให้ความร่วมมือกัน มีความเชื่อมั่นในทีมและการสื่อสารกัน

งานหลายอย่างแค่นั่งคุยกันนิดเดียว งานก็เดินไปได้แล้ว แต่บางครั้งเราไม่คุยกัน เหมือนบางคนกลัวที่จะคุยกัน เลยใช้วิธีสื่อสารผ่าน ticket แทน แล้วใส่คอมเมนต์ไป ซึ่งมันเสียเวลากว่างานจะเดิน บางครั้งคนในทีมเข้าใจไม่ตรงกัน ถ้าอย่างนั้นก็พาคนเหล่านั้นมานั่งเคลียร์กันในห้องเลย แล้วเราก็อธิบายว่าเรื่องมันเป็นอย่างนี้นะ ต้องทำงานแบบไหน 

ซึ่งเรื่องมนุษยสัมพันธ์เนี่ยมันไม่ได้จำกัดแค่ในแวดวง QA นะ แต่มันใช้ได้กับทุกๆ ธุรกิจเลย

การรับมือกับการเติบโตทางหน้าที่การงาน

เมื่อก่อนที่ผมอยากมุ่งไปในด้าน technical ส่วนหนึ่งก็เพราะว่าผมไม่อยากคุยกับคน เพราะผมเป็นคนขี้เกรงใจ ไม่ค่อยดุ ใครจะว่าอย่างไรก็เออออตามเขาไป ประนีประนอม แต่พอมาทำงาน management มากขึ้น จะรู้ว่าเวลาทีมงานสองฝั่งมีความเห็นไม่ตรงกัน ถ้าเราโอ๋ทั้งสองฝั่งจะเหนื่อยมาก เลยหนีไปอยู่ด้าน technical 

แต่ผมกลับพบว่า ไม่ว่าอย่างไรเราก็หนีการทำงานกับคนไม่พ้น เช่น สมมติว่าผมไปทำเรื่อง technical ยากๆ มา ซึ่งสิ่งที่ศึกษามาก็ต้องมีคนนำไปใช้ต่อ สิ่งที่ผมต้องทำคือการไปสอนคน ซึ่งมันจะเกี่ยวข้องกับกระบวนการวางแผน ต้องมีทักษะการบริหารจัดการโปรเจกต์ ต้องรู้ว่างานแต่ละชิ้นต้องไปคุยกับใคร และใครเป็นผู้มีส่วนได้ส่วนเสีย

นอกจากนี้ยังต้องมาดูแลน้องๆ ในทีมด้วย ซึ่งไม่ใช่แค่ช่วยสอนงานหรือแก้ไขปัญหาให้พวกเขา แต่ยังมีการทำ performance evaluation และการมอง career path ให้เขาด้วย เช่น ถ้าเขาสนใจที่จะเติบโตไปในสายงานหนึ่ง เราจะสนับสนุนเขาได้อย่างไร มีจุดด้อยตรงไหนที่สามารถปรับปรุงได้บ้าง กลยุทธ์เป็นแบบไหน เช่น เน้นเพิ่มจุดเด่น ไม่ต้องสนใจจุดด้อย หรือแก้ไขจุดด้อยเพื่อให้สมบูรณ์แบบมากขึ้น ซึ่งมันจะใช้ทักษะการวางแผนคนละอย่าง ปวดหัวคนละแบบ

เมื่อเข้าใจแล้วว่าการทำงานต้องเกี่ยวข้องกับคน ก็ยินดีทำงาน management มากขึ้น

บรรยากาศการทำงานที่ Seven Peaks

ผมรู้สึกว่าอะไรหลายๆ อย่างมันเปลี่ยนจากที่เคยเจอเยอะ เพราะว่า business model ของบริษัทเก่ากับที่นี่มันคนละแบบกัน ที่เก่าเขาจะมีโปรดักต์ของตัวเอง แต่ที่นี่จะเป็นการตอบสนองความต้องการของลูกค้า มีความหลากหลายสูงมาก ซึ่งเป็นความท้าทายที่สนุกนะ ว่าเราจะทำอย่างไร ซึ่งอย่างที่บอกคือ เราควรจะมี core standard อยู่ตรงกลางที่สามารถปรับใช้กับโปรเจกต์หลากหลายแบบได้ แม้ว่าจะไม่มีอะไรที่สามารถตอบโจทย์ได้ทุกอย่าง แต่ก็ควรจะสร้างมาตรฐานนี้ขึ้นมาก่อน

อีกอย่างที่ผมชอบ คือที่นี่เขาเปิดกว้างทางความคิด ใครคิดอยากทำอะไร ก็สามารถเดินไปคุยกับผู้บริหารคนอื่นๆ ได้เลย เช่น ผมอยากทำเรื่องนี้ มันจะมีประโยชน์อย่างไรบ้าง เขาก็พร้อมจะสนับสนุน ตราบใดที่สิ่งนั้นฟังดูสมเหตุสมผล และผมทำการบ้านมาดีพอ

คนที่ย้ายจากสาย technical มา management ควรเตรียมตัวอย่างไร

ผมเชื่อว่าหลายๆ องค์กรมีความ healthy นะ เลยอยากฝากว่า อย่ากลัวที่จะคุยกับคน ขอแค่คุณเปิดใจ ทุกคนเขาพร้อมที่จะช่วยเหลือและให้การสนับสนุนคุณ แค่คุณชัดเจนว่าต้องการอะไร แผนคืออะไร สิ่งที่คนในทีมต้องทำคืออะไร เขาช่วยเราได้มากน้อยแค่ไหน scope คืออะไร timeline เป็นอย่างไร ซึ่งจริงๆ มันมีหลักการสามเหลี่ยมของการบริหารจัดการโปรเจกต์ หรือ project management triangle อยู่ พอเรานำแผนไปคุยกับเขา เขาก็ยินดีที่จะช่วย

ผมเข้าใจดีว่าคนที่เก่งด้าน technical มักจะอยู่กับตัวเอง การวางแผนอาจจะไม่ถนัด พอต้องไปเจรจากับคนอื่นๆ หรือทีม management ถ้าเราเข้าไปคุยแบบงงๆ แผนก็จะไปต่อไม่ได้ อาจจะมีคนที่บ่นว่าแผนของคุณไปส่งผลกระทบต่อพวกเขามากเกินไป ถ้าเอาไปคุยกับหัวหน้า เราก็โดนด่ากลับมา 

จนทำให้บางคนกลัวการทำงาน management และคิดว่ามันเป็นเรื่องยากเกินไป แต่จริงๆ แล้วคุณแค่ไม่ได้เตรียมตัวให้พร้อมก่อน แรกๆ เราอาจจะไม่รู้ต้องเตรียมตัวอย่างไร แต่ถ้าทำการบ้านเยอะๆ วางแผนบ่อยๆ ครั้งเข้า มันก็จะง่ายขึ้น และคุ้นเคยกับรูปแบบที่ควรจะทำไปเอง รู้ว่าเดี๋ยวจะมีคำถามอะไรกลับมา ซึ่งเราเตรียมเอาไว้หมดแล้ว มันก็จะผ่านไปได้

ฝากถึงคนที่อยากเป็น QA

ในอดีต คนที่เป็น QA มักจะคนที่กลัวการเขียนโค้ด จนมีคนพูดว่า “ไม่อยากเขียนโค้ดเหรอ มาเป็น QA สิ” แต่ปัจจุบัน ถ้าคุณคิดแบบนั้น คุณจะโดน disrupt เพราะทุกวันนี้ ChatGPT ก็รอ disrupt คุณอยู่ เทรนด์ธุรกิจก็จะไปทาง automation มากขึ้น ที่ของ manual testing มันเล็กลงเรื่อยๆ นอกจากนั้นผลตอบแทนก็สู้คนที่ทำ automation ไม่ได้ เพราะมันกำลังฮิต

ดังนั้น อย่ากลัวที่จะเขียนโค้ด ขอแค่ลองเปิดใจ เพราะการเขียนโค้ดมันก็ไม่ได้ยาก มีเครื่องมือช่วยเราอยู่ตั้งหลายอย่าง ในหลายๆ องค์กรก็มีตำแหน่ง SDET อย่างที่ผมเล่าไปเพื่อคอยช่วยเหลือ QA ในทางเทคนิค ถ้าคุณพร้อมและเปิดใจ career path ของคุณมันจะเปิดกว้างได้อีกเยอะมาก ขอให้โชคดีครับ

คุณฮิล พัฒนพงศ์ ศรีสุชาญเจริญ, Head of QA ที่ Seven Peaks คุณฮิลมีประสบการณ์การทำงานในสาย QA มามากกว่า 16 ปี และเคยขยายขอบเขตงานไปถึงฝั่ง DevOps ด้วย ทำให้เขาเข้าใจในทุกมิติของ QA ซึ่งจากประสบการณ์ที่ต้องทำงานกับคนหลายๆ ฝ่าย ทำให้เขาสามารถทำความเข้าใจและสื่อสารได้เป็นอย่างดีกับทั้งฝั่ง business และฝั่ง technical ซึ่งจะช่วยตอบโจทย์และแก้ปัญหาให้ลูกค้าได้ดี